Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!gatech!mcnc!thorin!hatteras!mueller From: mueller@hatteras.cs.unc.edu (Carl Mueller) Newsgroups: comp.sys.amiga Subject: Re: Mac and Amiga floppy sizes Message-ID: <17722@thorin.cs.unc.edu> Date: 21 Nov 90 20:02:05 GMT References: <3242@ns-mx.uiowa.edu> Sender: news@thorin.cs.unc.edu Reply-To: mueller@hatteras.cs.unc.edu (Carl Mueller) Distribution: usa Organization: University Of North Carolina, Chapel Hill Lines: 119 In article <3242@ns-mx.uiowa.edu> bheil@umaxc.weeg.uiowa.edu (Brian Heil) writes: >Can somebody explain quickly and briefly why Macs use that weird variable >speed deal on the floppies? I remember it was supposed to be to get more >stuff stored on the disk, but seeing as my amiga claims 880K (amigados info) >or 837K (SKsh info) and all I can get on the Mac disk is about 780K (730K >usable) this seems to be unreasonable. I suspect a marketing ploy. The Mac and the Amiga use radically different techniques to obtain their higher data capacity on 3.5" disks. I don't really think you can put the blame on any marketing ploys, though, since Apple has been using their variable speed drive since prior to 1984 (when the Mac came out) and has been using GCR recording since the Apple Disk II came out in ~1978. When the Mac first came out, hardly anybody was using 3.5" disks. Amigas weren't even seen in public until the following year (?). A (long) explanation of the technologies: A disk lets you store magnetic signals. When you design a drive system, you have to determine how you are going to encode the bytes into signal and then how you put this signal on the disk. There are a couple of fundamental problems you must overcome in doing this. The signal can be looked at as digital data (bits). However, it's not quite so simple: this signal is coming at a continuous rate as the disk spins. All disk drives do not turn at exactly the same rate, so the first problem is detecting when the bits start and end. Once you have the bits, you need to know where the bytes start and end, and then you have blocks.... Let's look at the first problem, of identifying the bits. What is needed is a method of synchronization, and this can be obtained by looking for transitions in the digital signal. Each transition tells where a bit boundary is, so the disk controller can synchronize with the media by timing these. Problems can occur when you try to write too many contiguous 1's or 0's - you will have no transitions and thus the controller may become out of sync. There are different methods of overcoming this problem, and some are known as FM, MFM, and GCR. FM inserts a sync bit between every bit of data (simple, but inefficient). MFM uses slightly more intelligence, and I forget the details, but it still operates on the 'bit stream' principle. GCR (group-code recording) uses a different approach. Instead of looking at individual bits, it looks at groups of bits. Suppose you look at all the 'legal' 8-bit combinations which can appear on a disk (the ones without too many contiguous like bits). There may turn out to be about 70 or so (again, I forget the details). This is enough to encode a 6-bit number and have a few left over. So you can break your data up into 6-bit chunks, use a lookup table to encode these into the 8-bit sequences which you then write out to disk. That's GCR. With the extra 8-bit combinations you have left, you can mark the beginning of sectors and other such goodies. Now, going back to the fundamental problem of applying the signal to the disk. There is a maximum density at which you can write on the disk. As the disk spins, this means that you can write the signal out only so fast. Most disk drives spin at a constant rate, and most disk controllers write data at a constant write. The upshot of this is that data is written more densely on the smaller inner tracks than on the longer outer tracks. Several people saw that the outer tracks weren't being used to their optimal capacity. What was needed was a way to write more data to the outer tracks than the inner ones. There are two ways to do this: either slow down the disk or speed up the controller. Apple took the former approach since it let them keep the same controller design at the expense of needing a custom, variable-speed drive, which SONY was happy to make for them. So how did Commodore store more data on a constant speed, MFM drive? They did so by looking at another disk drive problem: data sectoring (or 'blocking' since block and sector are about equivalent terms). This is more of a software issue, but still tied in to the hardware in some cases (if GCR is done in hardware, for instance). For a variety of reasons, computers like to deal with data in nice, small blocks of 256, 512 (most common), or 1024 bytes. Most disk systems are designed to read and write single blocks at a time. With disks, you have to be careful as you write out a block so that you don't overwrite the beginning of a subsequent block (once again, this problem is due to each drive not turning at exactly the same speed). To this end, there are gaps written out between blocks. Note that useful data could have been written where the gaps are if you didn't have to worry about them. Commodore saw this and basically did away with physical blocking. Instead of writing 9 or so individual blocks along with 9 gaps, they write one big block with only 1 gap. Area that was previously used for gaps is now used for data, and thus you can store more bytes. The disadvantage of this method comes when you look at performance. You can no longer read and write a block at a time. Each time you want to read or write a logical block, you must read or write the entire track. Track buffers are also necessary, since writing means you must first read the track, modify the buffer, then write the track. Commodore did incorporate several optimizing techniques, though, to help things. For instance, instead of waiting for the beginning of the track to spin around and start reading from there, one can start reading immediately and continue for an entire revolution. The software can then figure out where the start of the track is. So, in summary: (the number in parens is # sectors/track) IBM PC: MFM, constant speed, sector-based (9): 720K MAC: GCR, variable speed, sector-based (varies): 800K AMIGA: MFM, constant speed, track-based (11): 880K Higher density disks (1.4M) are just that - higher density. They use a more precise read/write head, lower current, and more sensitive media. There! That's all I plan to say for now. I hope I haven't bored you or made too many mistakes. Perhaps someone who is more of an expert on this can correct me or fill in the details. -Carl (mueller@cs.unc.edu)