Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!munnari.oz.au!uhccux!uhheph.phys.hawaii.edu!ralph From: ralph@uhheph.phys.hawaii.edu (Ralph Becker-Szendy) Newsgroups: comp.os.cpm Subject: 3.5inch HD disk formats: Why not 11*1024 Summary: It should be legal Message-ID: <11344@uhccux.uhcc.Hawaii.Edu> Date: 6 Feb 91 22:04:15 GMT Sender: news@uhccux.uhcc.Hawaii.Edu Organization: U of Hawaii High Energy Physics Lines: 109 I just found this message I always wanted to post but never got around to. I think it was posted to the INFO-CPM side, but never made it to comp.os.cpm. So here we go: 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 with the 2797 actually used in our controller board), 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) is 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) -- Ralph Becker-Szendy UHHEPG=24742::RALPH (HEPNet,SPAN) 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