Good news! Today’s BMOW Floppy Emu firmware update brings support for the Macintosh MOOF disk image format. MOOF is a new disk image format for 3.5 inch Macintosh floppy disks, designed by John K. Morris, with the goal of capturing all the low-level disk information needed for copy-protected software. It’s the Macintosh equivalent of a WOZ disk image for Apple II computers. With a MOOF, you can use original floppy disks exactly as they came from the publisher, with copy protection still intact, instead of relying on cracked or modified versions. Although media-based copy protection was never as common in the Mac world as it was for Apple IIs, there’s still a good amount of early software from the era of the Mac 128K, 512K, and Plus that’s copy-protected. Most of them are 400K disks, but there are some 800K ones too. Archive.org has a collection of MOOFs at https://archive.org/details/moofaday

 
Understanding MOOF

A regular Macintosh .dsk or .img disk image is a byte-level representation of the logical data contained in a disk. It’s all of the disk’s sector data concatenated together into one big file. It supports normal disk behavior that’s built around a typical ReadSector() and WriteSector() API. For an 800K floppy disk, the .dsk disk image is precisely 800K in size.

A MOOF disk image is a bit-level representation of the disk as it’s physically implemented in the floppy media. It’s everything on the physical disk, including the empty space between sectors, the headers and footers, and GCR 6&2 encoded data or whatever non-standard encoding the developer may have chosen. For a MOOF that’s created using John’s Applesauce hardware, it will also correctly preserve the relative angular positions of adjacent disk tracks, and areas of the disk where there are no bits, both of which are essential for some copy-protection schemes. For an 800K floppy disk, the MOOF image is typically about 1300K in size.

I don’t recommend rushing to re-encode all your Mac disks as MOOF. For the vast majority of disks, this is not only unnecessary, but counterproductive since MOOF images are larger and more difficult to use with common software tools. But for those few Mac disks with embedded media-based protection, a low-level MOOF image is just what’s needed.

 
MOOFing the Floppy Emu

When people asked me about MOOF in the past, I said it was impossible for Floppy Emu to support bit-level 3.5 inch disk images because there wasn’t enough RAM to store a complete track at the bit level. So what kind of black magic makes this possible now?

To make the data fit, the Floppy Emu firmware must depart slightly from the behavior of a real floppy disk. For a real 800K disk, there’s a small delay when switching between tracks, but switching between sides is instantaneous. For a normal .dsk disk image, the Emu can support this by storing track 0 side 0 and track 0 side 1 in RAM at the same time. There’s only a delay when new data is fetched from the SD card for the next track, which mimics the delay of a real floppy drive’s mechanical head stepping movement. But for 800K MOOF images, there isn’t enough RAM to store both sides. Only track 0 side 0 is stored in RAM and there’s a delay for SD card access when switching to track 0 side 1. In theory this might cause software errors or copy-protection failures, since there’s no equivalent delay with a real disk. But in practice, I don’t think it’s a problem.

This RAM-saving trick works for 400K and 800K MOOFs, but can only be extended so far. RAM limits are one of several reasons you’ll probably never see 1440K MOOF support on this hardware. But that’s no great loss since the era of media-based copy protection had mostly ended by the time 1440K disks were introduced. All of the MOOF examples in Archive.org’s Moof-A-Day collection are 400K and 800K disks.

This MOOF implementation for Floppy Emu is read-only. A few Moof-A-Day games require writing to the disk in order to play, so although they load and run, they’re not fully usable. A writable version of MOOF support is in the works. The rare MOOFs that use pure FLUX data are unsupported by the Floppy Emu, due to hardware limitations. The only example that I know is the game OIDS.

 
WOZ 3.5

The MOOF format is essentially identical to the 3.5 inch WOZ format for Apple II computers, just with different metadata. That means it’s theoretically possible to add 3.5 inch WOZ support to Floppy Emu too, and that’s my hope. But it’s unfortunately not as simple as just re-using the Macintosh MOOF code: the Apple II version of the firmware is substantially more complex than the Mac version, because it supports many more types of disk emulation and disk image formats, and it’s already pushing the limits of the microcontroller’s performance and memory, and the CPLD logic chip’s resources. It’ll be a major challenge to weave 3.5 inch WOZ support into this environment.

 
Moof-A-Day Known Issues

• Two titles still don’t pass the copy-protection check, for unknown reasons: The Ancient Art of War and The Surgeon. The Surgeon also fails its check with archive.org’s built-in MAME environment, so it’s not just Floppy Emu that has trouble with it.
• Mac Vegas will silently fail to write to the read-only disk, then restart or crash when you begin a mini-game.
• Some games have other requirements like only running properly on a Mac 512K, or only when the disk is in the internal drive, or they require two disk drives.

Please give this a spin, and let me know of any problems you find with MOOF support, or with other disk emulation features that might have broken accidentally.

Download the latest Floppy Emu firmware from the project page, or buy a new Floppy Emu Model C at the BMOW Store.