4 ms·

Context, since it's not spelled out with a lot of background in the article: most floppy drives spin at a fixed RPM, which is referred to as a Constant Angular

by mjg59 6y ago

Context, since it's not spelled out with a lot of background in the article: most floppy drives spin at a fixed RPM, which is referred to as a Constant Angular Velocity (CAV: ie, no matter how far out on the disk you are, the disk rotates by a constant angle per second). This means that towards the outer edge of the disk more magnetic media is passing under the head per second than towards the inner edge of the disk (with a larger circumference, a constant angle will represent a longer chunk of media). If you're writing the same number of bits per second, this means each bit takes up a larger amount of magnetic media at the outer edge compared to the inner edge. If, instead, the drive spins at a Constant Linear Velocity (CLV: ie, the same amount of magnetic media passes under the head per second no matter where on the disk you're accessing[1]), each bit can take up the same amount of magnetic media, which means you can store more bits per track towards the outer edge of the disk. Macs did this in order to increase the amount of data you could store, at the cost of additional complexity in the drive to support spinning at different rates. It also means that 800K Mac disks (the largest format which used variable rates) can't be read on normal PCs, which lack support for variable rates. FluxEngine works at a lower level than the standard PC floppy interface - it allows the OS to look at the actual magnetic flux data on the disk, whereas the standard PC floppy interface will only pass back the interpreted bits. Even if the disk is spinning at a constant RPM, knowing where the head is located allows that magnetic flux data to be turned back into the appropriate bitstream (or vice versa for writing) and allows handling CLV disks even though they're in a CAV drive. [1] Except it doesn't actually do that - there's only 4 different speeds, as you can see in https://github.com/davidgiven/fluxengine/blob/7eaf3de5723436c748a6cc700fbde7848898be92/arch/macintosh/encoder.cc#L21 https://github.com/davidgiven/fluxengine/blob/7eaf3de5723436... .

Someone 6y ago
“at the cost of additional complexity in the drive to support spinning at different rates” I don’t think there was that much extra hardware in the drive, originally. Bytes read from a buffer at every horizontal scan line controlled the speed of the drive through PWM (http://www.mwftr.com/416F20/Apple%20macintosh%20BYTE1984.pdf http://www.mwftr.com/416F20/Apple%20macintosh%20BYTE1984.pdf. That probably changed later, as that method doesn’t cater for multiple floppy drives, and created a hard link between screen resolution and controlling floppy disk speed (the hardware driving the screen also processed the PWM bytes that controlled disk speed (and the bytes that produced audio output. 370 scan lines times 60Hz gives you 22,2 kHz)) And nitpick on note [1]: that code shows 5 different speeds (four if statements and one ‘otherwise’ return value)

by mjg59 6y ago

Someone 6y ago

“at the cost of additional complexity in the drive to support spinning at different rates” I don’t think there was that much extra hardware in the drive, originally. Bytes read from a buffer at every horizontal scan line controlled the speed of the drive through PWM (http://www.mwftr.com/416F20/Apple%20macintosh%20BYTE1984.pdf http://www.mwftr.com/416F20/Apple%20macintosh%20BYTE1984.pdf. That probably changed later, as that method doesn’t cater for multiple floppy drives, and created a hard link between screen resolution and controlling floppy disk speed (the hardware driving the screen also processed the PWM bytes that controlled disk speed (and the bytes that produced audio output. 370 scan lines times 60Hz gives you 22,2 kHz)) And nitpick on note [1]: that code shows 5 different speeds (four if statements and one ‘otherwise’ return value)