BMOW title
Floppy Emu banner

1.4 MB High Density Floppy Emulation

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!


Read 5 comments and join the conversation 

5 Comments so far

  1. Alexander - November 3rd, 2013 2:40 pm

    Wonderful to hear! I had already ordered the parts, and the board, when you only had 400k/800k support working, but this is a great addition, and will make it a snap to install Mac OS onto my 68k Macs.

  2. Dave - November 4th, 2013 7:43 am

    Is there any chance you could add support for bit-level GCR images? Would the hardware be capable of that? This would be useful for those programs with annoying copy protection schemes.

  3. Steve Chamberlin - November 4th, 2013 10:44 am

    Bit-level disk images should be theoretically possible, but a pretty major change to the current design. Maybe someday!

  4. Jose Ricci - November 9th, 2013 7:24 am

    What a fine peace of work you’ve done!

    I’ll order a couple of PCBs and components and will build it.

    Are you considering upgrading this design to emulate hard disks too? Like the apple HD20? It would be awesome to have v2.0 of the emulator to run an image of a 400kb floppy with the hd init and another image of a 20mb hard disk…

    Another improvement would be to add an image loader like the HxC floppy emulator for the Amiga and Atari ST. It makes life easier when you have a ton of images in the SD card.

    Anyway, congratulations for this awesome achievement for the vintage mac community.

  5. Steve Chamberlin - November 9th, 2013 7:46 am

    Although it’s physically attached to the floppy connector, the HD20 is a completely different animal. As far as I know, its interface was never publicly documented.

Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.