WOOOOO! Floppy Emu’s last big goal has been reached, and 1.4 MB disk emulation is now working! The photo shows a Mac Classic, booted into System 7.0 from a 1.4 MB high-density disk image. Combined with other recent improvements, this means Floppy Emu now works for 400K, 800K, or 1440K disk images in raw .dsk or DiskCopy 4.2 .image format, on any Mac from the 128K to the Mac II series and beyond.

1.4 MB disk support proved to be very similar to 400K/800K support in concept, but completely different in details. Data on 400K/800K disks is stored using a technique called GCR, which dates all the way back to the Apple II. GCR defines how data is encoded as flux transitions on a magnetic disk (or an emulated version of one, like we have here). In contrast, 1.4 MB disks store data using a technique called MFM, which is used by PCs as well as other classic systems including the Amiga and Atari ST. While GCR and MFM serve the same purpose, they are quite different, so Floppy Emu’s microcontroller and CPLD software both had to be extensively modified to add MFM support. For the curious, this Atari ST page has an outstanding explanation of floppy data encoding and MFM, almost all of which is relevant to the Macintosh too.

Aside from the MFM encoding change, another big challenge was maintaining MFM’s higher data rate. A Macintosh 400K or 800K floppy sends bits to the floppy controller at 500 kHz, but a 1.4 MB floppy sends bits at 1 MHz! That means Floppy Emu’s AVR microcontroller and companion CPLD needed to work twice as fast as before to serve data to the Mac, or else an underrun error would occur. My first attempts resulted in something that was almost but not quite fast enough, leading to a maddening situation where data transfers seemed to work much of the time, but would flake out with seemingly random errors before an entire sector could be transferred. In the end I had to review the C compiler’s assembly output, and do some cycle counting by hand, in order to optimize the code to the point where it was fast enough to consistently meet the data rate demands.

Beyond the MFM differences, high density Mac disks also use a different signature than 800K disks for tagging sector address and data blocks, and use a different checksum algorithm. 800K disks use a near-incomprehsible checksumming algorithm that was probably invented by Woz himself, while HD disks use a standard CCITT-CRC16 algorithm. Then just for laughs, high density disks also use a 1-based numbering scheme for sectors, instead of 0-based. That little twist took me quite a while to recognize!

The last hurdle was related to the larger size of a high-density floppy track, and I still don’t have a perfect solution for it. For 800K disks, the number of combined sectors on both sides of a track is variable, but is never more than 24. With 512 byte sectors that’s 12K of data – small enough to fit into the microcontroller’s 16K of RAM with some room to spare. But for high-density disks, there are 36 sectors and 18K of data – it won’t fit! Instead of buffering an entire track in RAM, then, I had to fall back to the technique I originally used for 800K disks, and do SD card transfers on the fly at the instant the data is needed. It works well enough when reading the disk image, but when writing it’s very sensitive to the speed and variability of the SD card transfers.

There are still many little bugs to fix and things to polish, and a few other features I’d like to add, but with the addition of 1.4 MB support I think Floppy Emu is effectively finished. Or if not finished, at least worthy of a “1.0” version number release. My next plans are to polish up the code and documentation, squash a few more bugs, and then build some Floppy Emu units for those who want one. Happy hacking!