Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

TRS80 Model 1/III Disk Layout

201 views
Skip to first unread message

Charles P. Hobbs

unread,
Nov 17, 1996, 3:00:00 AM11/17/96
to

Does anyone know how the Model 1/III disks are laid out (i.e
where is the directory track, etc.)?

Reason: I have two different emulators and they won't read each
others disk images, so I might write a conversion utility

Thanks in advance!

Frank Durda IV

unread,
Nov 18, 1996, 3:00:00 AM11/18/96
to

"Charles P. Hobbs" (tra...@primenet.com) wrote:
: Does anyone know how the Model 1/III disks are laid out (i.e

: where is the directory track, etc.)?
:

In late 1984, in response to massive problems with unreadable diskettes
coming from Tandys software duplicating facility, I did an analysis of
just about every media that Tandy was producing, even things like Model
2000 XENIX and Model 100/200 floppies. The goal was to detect flaws not
only in the format patterns the duplicating equipment at the factory was
using, but to detect errors in the FORMAT utilities of the operating
systems themselves. Both format programs and factory duplicators turned
out to be way out of spec in some critical areas. Plus, the factory had
some really lousy media they were trying to record data on.

We used to read the box art that said "Certified Error - Free" as
saying you got certified errors for free. :-)

I plan to put all of this up on my upcoming WWW site, but here is the part
about the Model III TRSDOS 1.3 low-level format. This should be more than
you ever wanted to know about these diskettes.

The Model I was not analyzed back then since Tandy was no longer duplicating
any significant quantity of Model I diskettes at this date. I could
probably do a Model I map if someone would send me two diskettes
of each format that needs analyzing. (If you are interested in doing
this, send me EMAIL *first* and I will give you some more details.)

- - - - - -

8. FORMAT PATTERN FOR TRSDOS 1.3 (Model III,4,4P,4D)

I. The Model III, 4 and 4P use the FD1793 controller
and the Model newer Model 4, 4D, and 4Ps use the
FD1773, which is compatible with the FD1793.

II. The format (produced by the system formatter) is:

Number of Bytes Value on Media Description
e. 64(32) 4E Gap Ia (Post Index)*
+-------------------------------------------------
f. | 8(12) 00 Gap Ib/IIIb(PLL sync)*
g. | 3 A1 Preset CRC
h. | 1 FE ID Address Mark
i. | 1 nn Cylinder # (0-39)
j. | 1 nn Side Number (0)
k. | 1 nn Sector Number (1-18)
l. | 1 nn Sector Length
m. | 2 nnnn Two byte CRC (id)
n. | 22 4E Gap IIa
o. | 12 00 Gap IIb (PLL sync)
p | 3 A1 Preset CRC
q. | 1 FB/F8 Data Address Mark
r. | 256 Data Data Sector
s. | 2 nnnn Two byte CRC (data)
t. | 24 4E Gap IIIa (Data gap)
+-------------------------------------------------
u. 898 4E Gap IV

64 + ((256 + 82) * 18) = 6,148 bytes + 16 Gap IV bytes = 6,164 bytes
This pattern is acceptable since 6,164 is less than 6,250.
(The 16 bytes of Gap IV is the minimum number of bytes allowed
in Gap IV. See section 3.)

[This is discussed in a different section, but 6,250 bytes is all
you can get on a diskette running at 300RPM in double-density mode.
That is where this number comes from and why it is important.]

* Although 8 bytes is the documented minimum for Gap IIIb, TRSDOS
1.3 uses 8 bytes for Gap Ib, which is incorrect. Gap Ib should
be 12 bytes (in front of first sector after Index).
Western Digital advises that both Gaps Ib and IIIb be kept at
12 bytes due to the Radio Shack hardware implementation. See
Section 3 for more information.

If Both Gap IB and IIIb are set to 12 bytes, the total track
length becomes 64 + ((256 + 86) * 18) = 6,220 bytes. After
adding a minimum of 16 bytes for Gap IV, 6,220+16 = 6,236 which
is below 6,250. However, this value is close to 6,250, and
requires that drives not be running at more than 300.67 RPM.
It is suggested that Gap I be shortened to 32 bytes, which would
allow the drive to be running at up to 302.2 RPM.

TRSDOS 1.3.2 and later implement all of the recommended changes.


III. TRSDOS 1.3.x has 18 sectors per track and number them
starting with 1 (1-18). Each sector contains 256 bytes.

IV. The Data Address Mark varies from track to track.
(On a normal disk, they vary on track boundaries and
indicate if the head is over the directory.) Standard
diskettes have F8 on all tracks except 17 (decimal),
which has FB. A duplicator must duplicate these fields
exactly as they appear on the master.

V. The Interleave for TRSDOS 1.3.x is 6:1. (See Section 5 for
the resulting sector ordering.)

VI. The Track Skew value for TRSDOS 1.3.x is 1 (none).

VII. TRSDOS 1.x only allows 40 tracks and does not support
two-sided operation. (It ignores the presence of Side 1.)


- - - - - -

[From Section 5]

The Interleave 6:1 is:
00,03,06,09,12,15,01,04,07,10,13,16,02,05,08,11,14,17

For TRSDOS 1.x. add one to each value since this operating system
numbers its sectors starting with 1.

[From Section 4]

I. Gap II, consists of lines n, o and p of the format.
Western Digital states "Gap II cannot be varied from the
IBM format." NEC does not allow the size of Gap II to
be changed either, and NEC does not provide any way for the
programmer to override the mandatory values.

II. NEC warns that Gap IIIa (t.) specified during a write sector
command must be shorter than the Gap IIIa (t.) value that
was specified during the format of the track. [The NEC '765 part
is not used in real Model III/4/4D/4P systems, but is what all
IBM PC floppy controllers are based on, so this may be of
interest to people working on Model III/4/4D/4P emulations. ]

Lines n, o and t are used for write-splicing and the sizes of these
areas are very important if the media is to be re-written after
initial formatting.


Frank Durda IV <uhc...@nemesis.lonestar.org>|"The Knights who say "LETNi"
or uhclem%nem...@rwsystr.nkn.net | demand... A SEGMENT REGISTER!!!"
|"A what?"
or ...letni!rwsys!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983
(c) 1996, ask before reprinting.


Tim Mann

unread,
Nov 18, 1996, 3:00:00 AM11/18/96
to Charles P. Hobbs

In article <328F89...@primenet.com>, you write:
>Does anyone know how the Model 1/III disks are laid out (i.e
>where is the directory track, etc.)?

Yes, I know that stuff, but it would take a long time to type it all
in! Here's a quick summary.

For LDOS and TRSDOS, other than Model III TRSDOS 1.3: On each track,
sector numbering starts at 0. Sectors are 256 bytes. Single-density
disks have 10 sectors, double-density have 18. Track numbering also
starts at 0. The directory is often on track 17, but not always.
Look at track 0, side 0, sector 0, byte 2 for the directory track
number. Directory sectors use a different data address mark, either
FA or F8, while data sectors use the normal FB.

Model III TRSDOS 1.3 was different. Frank Durda just posted a
detailed message about its low-level format. The main differences are
that it starts sector numbering at 1, and it uses F8 for data sectors
and FB for directory sectors.

Newdos-80 and other systems had many options for alternative formats.
I never looked into them -- I worked for the competition (LDOS), so I
didn't have time to spend on that.

>Reason: I have two different emulators and they won't read each
>others disk images, so I might write a conversion utility

What emulators do you have? I know the file format for disk images on
Jeff Vavasour's Model I and Model III/4 emulators. (They are
different and incompatible.)

Vavasour's Model I emulator just stores all the sectors in logical
order. The first 256 bytes of the file are track 0, sector 0; the
next track 0, sector 1, etc. The format can deal only with single
sided, single density, standard TRSDOS format, directory on track 17.

Vavasour's III/4 emulator includes documentation of the disk image
format in the printed manual. I won't repeat it here. It supports a
lot more than the Model I emulator, but still has some restrictions:
sectors must be 256 bytes, and you can't format a sector with an
incorrect track or side number. So it can't deal with all
"copy-protected" formats.

I also know of a Model III emulator by Vincent Van Den Berghe that has
disk emulation and makes disk image files. Unfortunately it has a bug
in the emulation that keeps LDOS from being able to format an emulated
disk. I haven't gotten as far as figuring out the disk image file
format, and probably won't bother due to the bug.

I've written my own disk emulation as an add-on to the xtrs TRS-80
Model I emulator, which runs on Unix with the X window system. (I
haven't released it yet, but I plan to.) My emulator can read and
write both of Vavasour's disk image formats. This is useful because I
emulate a Model I double density adaptor (Percom Doubler or Radio
Shack Doubler), so I need a format that supports double density. I
don't have a separate conversion utility between the two formats, but
you can copy images between them from within my emulator using the
normal TRSDOS/LDOS/whatever BACKUP or COPY programs.

--Tim
--
Tim Mann <ma...@pa.dec.com>
http://www.research.digital.com/SRC/personal/Tim_Mann/

Russ McElroy

unread,
Nov 18, 1996, 3:00:00 AM11/18/96
to

In article <56qjoe$9...@src-news.pa.dec.com>, Tim Mann <ma...@pa.dec.com> wrote:
>In article <328F89...@primenet.com>, you write:
>>Does anyone know how the Model 1/III disks are laid out (i.e
>>where is the directory track, etc.)?
>
>Yes, I know that stuff, but it would take a long time to type it all
>in! Here's a quick summary.

[concise summary deleted for brevity]

>
>Newdos-80 and other systems had many options for alternative formats.
>I never looked into them -- I worked for the competition (LDOS), so I
>didn't have time to spend on that.

NEWDOS/80 relies on the 5-sector granule as the disk
allocation unit and the directory position is determined
by the starting granule and the size by the number of
granules allocated to the directory.

Directories also always start on a "lump" boundary, and
the number of granules per lump can be varied for custom
disk formats.

One can set up a 720k diskette with a small directory which
is optimum for a small number of large files, or conversly
format a 180k diskette with a large directory to store lots
of little files.

The directory structure is quite similar to that given for
TRSDOS, though time has no doubt dimmed my memory of the
details.


>
>>Reason: I have two different emulators and they won't read each
>>others disk images, so I might write a conversion utility
>
>What emulators do you have? I know the file format for disk images on
>Jeff Vavasour's Model I and Model III/4 emulators. (They are
>different and incompatible.)

Yes, simply learning the layout of "physical" diskettes
may not help too much here..

R
--
Russ McElroy | VE7AJH | ru...@qb.island.net Qualicum Beach, BC, Canada #*#
Home page: http://qb.island.net/~russ/index.html

Shawn Sijnstra

unread,
Nov 19, 1996, 3:00:00 AM11/19/96
to

Actually you will need a lot more information than you think. It depends
on which DOS and what size disk it is emulating. I can probably tell
you most of them, but it would take a while. (If you want me to post
the details, tell me.) Does anyone here know how the .DSK files aÂü¡á³œ%œr es are
layed out? I would like to turn them back into TRS80 disks, and also put
soŸ–Ó%]me of those wacky autoboot disks into .DSK storage for archival
purposes. If I could do that on a TRS80 it would be easier because then I
know that my controller could do it. (I also don't own an MSDOS machine.)

Shawn


0 new messages