Newsgroups: comp.sys.apple2 Subject: Re: Apple2 disk controller questions From: dempson@actrix.gen.nz (David Empson) Date: Thu, 13 May 1999 06:58:01 +1200 Message-ID: <1drq2mt.3ynral1xmdhteN@dempson.actrix.gen.nz> References: <7h9d7i$f3k$1@news.cict.fr> <19990512013929.16539.00000804@ng-fz1.aol.com> <7hb9gl$dkg$1@news.cict.fr> <19990512044938.14706.00000065@ng-fk1.aol.com> Organization: Empsoft X-Newsreader: MacSOUP 2.3 NNTP-Posting-Host: 202.49.157.176 X-Trace: 13 May 1999 06:55:50 NZST, 202.49.157.176 Lines: 234 Path: news1.icaen!news.uiowa.edu!NewsNG.Chicago.Qual.Net!128.174.5.49!vixen.cso.uiuc.edu!arclight.uoregon.edu!logbridge.uoregon.edu!ihug.co.nz!news.iprolink.co.nz!news.actrix.gen.nz!dempson Xref: news1.icaen comp.sys.apple2:147675 Supertimer wrote: > "Fabrice Frances" wrote: > > >there's still something confusing me... > >It seems 343 GCR-encoded bytes are transfered through the > >disk controller for a single 256-bytes sector... I would say > >GCR efficiency lies between FM (512) and MFM (256), > >am I wrong ? > > Come to think about it, you are right. It must be the variable > spin drives that give Apple 3.5" disks the extra 80k, but GCR > is probably a little less efficient. Allow me to step up on the soapbox for a few minutes. First: rotation speed and capacity issues. The 800K 3.5" disks get extra capacity due to varying rotation speed. It isn't actually "constant linear velocity", but gets reasonably close to it. There are five speed bands, each of which contains 16 tracks. Each speed band has one more sector per track (per side). The inner tracks have 8 sectors and the outer tracks have 12. All sectors are 512 bytes, plus a small header area which isn't used on the Apple II. Apple II 5.25" drives have a constant rotation speed, so the bits are physically longer on the outer tracks, and all tracks have the same number of sectors (ignoring copy protection schemes and older formats): 16 sectors, each of which holds 256 bytes. The raw data transfer rate for the 3.5" drive is 500 kilobits per second (2 microseconds per bit). The 5.25" drive is half this: 250 kilobits per second (4 microseconds per bit). I'll ignore the 3.5" drive for most of the rest of this message. The 5.25" drive has a nominal rotation speed of 300 rpm, which is 5 revolutions per second. At 4 microseconds per bit, this works out to about 50000 raw data bits per track. Second: data encoding (FM vs MFS vs GCR) FM uses a simple clock/data scheme, where data bits may be written as either 0 or 1, but must be interleaved with clock bits (always 1, ignoring synchronization issues). All bits are regularly spaced. Given the Apple II 5.25" drive characteristics, a totally packed track recorded in FM would be able to fit 25000 bits, which is 3125 bytes. This drops considerably if sectoring is used. I have a page from an Intel disk controller data sheet here, which shows the standards as either 18 or 16 128 byte sectors per track (2.5KB at best, for a full 35 track disk capacity of 87.5KB per side). There is no FM standard format with 256 bytes per sector quoted here, but the ones with 512 bytes, 1KB, 2KB or 4KB per sector are able to fit 4KB onto the track. I suspect these are actually for an 8 inch disk, or possibly a 5.25" disk rotating slower (perhaps with double density media). MFM varies the recording format in two ways: 1. Clock bits can be omitted with certain combinations of data bits, e.g. two adjacent 1 bits. 2. The bit cell timing is adjusted to allow bits to be recorded in twice as many potential positions (i.e. 2 microsecond resolution for bit cell positioning), but adjacent cells cannot contain 1 bits. This means that the 1 bits are always at least 4 microseconds apart on the disk, which is sufficient for single density media. In combination, these changes allow MFM to record exactly twice as many bits per track as FM on the same media. "Double density" media may allow more reliable operation, but isn't essential. The standard MFM format on a 5.25" disk has 9 sectors of 512 bytes per track, which is 4.5KB. (The theoretical limit without sectoring would be 7250 bytes.) Now lets look at GCR, as implemented in the Apple II. Bits are written in regularly spaced 4 microsecond cells, like FM. GCR doesn't use clock bits, but instead relies on using a limited subset of the 8-bit values which can be reliably written to a disk, based on bit patterns. For the Apple II 16 sector format, the rules used to pick the valid disk bytes are: 1. Every byte must have bit 7 set. (This is actually a limitation of the Apple II disk controller, not the GCR format. If this limitation was removed, a few more byte values might be made available, but it would complicate things considerably.) 2. The byte must not contain more than two adjacent zero bits. 3. There can be at most one pair of adjacent zero bits in each byte. (This is not actually necessary, but reduces the number of valid bytes to a convenient power of two plus a couple of spares.) The end result is 64 valid disk bytes values plus one (0xD5 = 11010101) which is reserved for use in address and data marks. The Apple II uses a 6-and-2 encoding scheme, in which each data byte is broken up into 6-bit and 2-bit fields. The 6-bit value is used as an index into the lookup table to get the corresponding valid disk byte. The 2-bit leftover is combined over three bytes to get another 6-bit number which is used similarly. (The data corresponding to the leftover bits is written at the end of the sector.) When reading, the process is reversed. A valid disk byte is used to look up another table (which has unusued positions corresponding to illegal disk bytes) to produce a 6-bit value. This is combined with the 2-bit residue from the decoded data at the end of the sector to form an 8-bit data byte. Right. That's the guts of how the data in each sector is encoded. With a 6-and-2 split, there are (256 + roundup(256 / 3)) = 342 data bytes written for each sector. So, for a 256 byte sector: FM needs to write 512*8 = 4096 bits GCR needs to write 342*8 = 2736 bits MFM needs to write 512*8 = 4096 potential bits, but in half the space, so it only counts as 2048 bits. The data header and trailer on the Apple II is seven disk bytes (D5 AA AD at the beginning, checksum and three trailer bytes at the end, with the third being a "slip" byte). The address marks are actually recorded in FM to speed up processing, so they need two disk bytes for each 8-bit data value. They require fourteen disk bytes in total (D5 AA 96, two bytes for volume, two bytes for track, two bytes for sector, two bytes for checksum, DE AA EB). There are also gaps between the address and data marks. These are made up of self-sync bytes, which are 10 bits instead of 8. GAP1 (before first sector) is typically 40 to 128 sync bytes. GAP2 (between address and data marks) is typically 5 to 10 sync bytes. GAP3 (between sectors) is typically 14 to 24 sync bytes. So, adding everything up, we could theoretically have: 128 * 10 + 16 * ((10 + 24) * 10 + (14 + 342 + 7) * 8) = 1280 + 16 * (340 + 2904) = 53184 bits per track Dividing by 8 gives 6648 raw disk bytes per track. In another posting in this thread, Fabrice Frances wrote: > It seems the .nib format used for Apple II disks holds 6656 bytes per track, > or 70 phases every 3328 bytes... Either one of these 300 rpm, 250 kbps, > 6656 bytes/track cannot be exact... so ? I imagine the 6656 is to allow for a little safety margin. A real disk on a drive which is running slow might be able to fit more bytes per track, but a normal speed drive can't anywhere near fit this many. Getting back to SuperTimer's article: > What I don't understand is the high density 3.5" Apple II > format. Like the Mac, high density 3.5" Apple II disks are > 1.44MB MFM. The 3.5" disk effectively has twice the density of a corresponding 5.25" disk, and bit cells are twice as fast: 2 microseconds for single/double density instead of 4 microseconds. MFM on a double density 3.5" disk (720KB format) is able to use 1 microsecond positional resolution for its bits, but must keep a gap of at least 2 microseconds between bits. GCR sticks to 2 microseconds per bit cell, and Apple squeezes more data on by varying the rotation speed (as mentioned earlier). If they didn't do this, and the disk rotated at the same speed as in a PC, I suspect it would only hold 640KB (8 sectors per track), since MFM can squeeze more data onto the track than GCR. This assumes that the innermost (fastest) band is the same rotation speed as the PC 3.5" drive. I don't have the rotational specifications for the PC 3.5" drive, so I can't check this detail. According to its manual, the Apple 3.5" Drive rotates at 394 to 490 rpm. A high density 3.5" disk doubles the bit cell density again. MFM uses 1 microsecond cells with 0.5 microsecond positional resolution. (An aside: the high density 5.25" drive doubles the track density as well as almost doubling the number of bits that can be recorded per track. The high density 3.5" drive has the same track density as the double density drive, probably to allow better compatibility with double density media than you typically get with 5.25" drives.) Apple didn't bother to use GCR on high density 3.5" disks, however... > However, there is a special 1.6MB GCR format that is used by AE's driver > for the IIGS. I'm not sure how the AE driver squishes those extra few > kilobytes into the disk. Now I'm going into speculation territory. Given that the high density disk holds twice as many bits per track as the double density one, and the drive mechanism supports 1 microsecond bit cells for MFM, all that AE needed to do was to be able to transfer data twice as fast and use the same GCR encoding and variations in rotation speed. The problem is that the IWM controller chip in the IIgs only supports 2 or 4 microseconds per bit cell (and the main CPU can't possibly keep up with reading or writing a byte every 8 microseconds anyway - assuming no accelerator). To get around this, I expect the AE 1.6MB drive has internal RAM to buffer data, in a similar manner to the UniDisk 3.5. It probably uses a proprietary transfer protocol to take advantage of the 2 microsecond mode in the IWM. (It could use the SmartPort protocol, but this slows the transfer down to 4 microseconds per bit cell.) This means that you can fit twice as much data on an AE 1.6MB HD disk, but the transfer rate will be approximately the same as an 800KB disk. On the other hand, a 1.44MB HD disk with a SuperDrive card is able to transfer data twice as fast as a 720KB DD disk (the SuperDrive card has a SWIM chip and a faster CPU). If the SuperDrive card supported the 1.6MB format, then it would also get double the data throughput compared to an 800KB disk. Here endeth the lesson. -- David Empson dempson@actrix.gen.nz Snail mail: P.O. Box 27-103, Wellington, New Zealand