Date : Mon, 08 Oct 1990 20:26:00 HST
From : Ralph Becker-Szendy <RALPH%UHHEPG.BITNET@CORNELLC.cit.cornell.edu>
Subject: 3.5inch HD disk formats: Why not 11*1024
Dear ol-time OS brethren,
A while ago there was a long discussion in this space about what the
maximum usefull capacity of a 3.5" disk in HD mode should be. I
remember Dave Goodenough claiming that he runs his with 10*1024+1*512
byte sectors per track, which Tilmann Reh found disgustingly
incompatible, therefore Tilmann uses 10*1024 and frowns on Dave.
Anyhow, we were just re-writing the formatting routines of my disk
controller. We came across something very strange. We claim that
11*1024 is legal ! Here's how the numbers work out:
A 3.5" HD drive is equivalent to a 8" DD drive (500kHz data rate MFM),
except that it spins at 300rpm instead of 360rpm. Lets express that as
saying that a 3.5" drive spins at 5rps. Therefore a track contains
500kHz / 5rps = 100000 bits = 12500 bytes, whereas a 8" track contains
10416 bytes. By the way, the data sheet for a Toshiba ND3561 drive and
for Mitsubishi 3.5" drives agree on 12500 bytes per track, whereas the
data sheets for 5.25" HD drives (which spin at 360rpm like 8" drives
when running in HD mode) say 10416 bytes, just as they should.
Now the overhead on each track. It consists of track header:
- Gap 4a: 80 bytes (content 4E)
- Sync: 12 bytes (content 00)
- Index mark: 4 bytes (3xC2, FC)
- Gap 1 50 bytes (content 4E)
then for each sector:
- Sync: 12 bytes (content 00)
- ID adress mark: 4 bytes (3xA1, FE)
- Sector ID: 4 bytes (Cyl, Head, Sect, Len)
- Sector ID CRC: 2 bytes
- Gap 2: 22 bytes (content 4E)
- Sync 12 bytes (content 00)
- Data mark: 4 bytes (3xA1, FB)
- Data: 1024 bytes
- Data CRC: 2 bytes
- Gap 3 n bytes (content 4E)
and after all sectors:
- Gap 4a: m bytes (content 4E).
This layout of a track was obtained from the data sheet of the WD 37C65
controller (which agrees with the 176x and 179x controller family, and
we assume also with the 2797 actually used in our controller board, but
we don't have a data sheet for it, since WD doesn't want to send me
one), and agrees with the ones listed in several different drive data
sheets.
Therefore, each sector occupies 1086 bytes (1024 net plus 62 bytes
overhead), and there is an additional track overhead of 146 bytes.
Now, we still have to calculate the lengths of Gap 3 and 4a, called n
and m so far. Gap 4a has to be at least 16 bytes, but most formats seem
to use at least 120 bytes, so we stick to just setting its minimum
length at 120 bytes. Now just take the total track length (12500),
subtract track overhead (-146), subtract the minimum length of Gap 4a
(-120), and subtract the space required for data sector (-11*1086).
That yields 12500-146-120-11*1086 = 288.
Now take these 288 bytes which are left, and distribute them evenly
over the 11 Gap 3s, making each 26 bytes long. In the 176x data sheets
a length of 24 bytes for gap 3 is recommended, so we are safely within
specs. Then the rest of the track (11x26 is a little less than 288 due
to rounding) is filled by letting Gap 4a get as long as it wants
(therefore in our case Gap 4a will be at least 120 bytes, usually a
little longer).
By the way, according to the 176x data sheet the limit of 24 bytes for
gap 3 (as indeed all gap lengths we used above) are already increased
above the functional limit to account for motor speed variation, PLL
lock up time, write splice area etc. Supposedly one can cut all gap
lengths in half (most gaps can theoretically be as short as 2 bytes)
and it would still work. So we seem to be far on the safe side.
Conclusion: 11x1024 is a legal format, and actually leaves a little bit
more safety margin than recommended in the controller data sheet. So,
why does nobody use it? And therefore, why should we be the first ones
to find that out?
Thanx for enlightenment, and don't start a religious war over this one.
Ralph Becker-Szendy and Christoph Tietz (visiting)
University of Hawaii RALPH@UHHEPG.PHYS.HAWAII.EDU
High Energy Physics Group RALPH@UHHEPG.BITNET
Watanabe Hall #203, 2505 Correa Road, Honolulu, HI 96822 (808)956-2931