BMOW title
Floppy Emu banner

MOOF disk image support for Floppy Emu

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. has a collection of MOOFs at

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’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’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.

Read 3 comments and join the conversation 

3 Comments so far

  1. John+Payson - December 5th, 2022 10:11 am

    Would the signalling in this mode be compatible with an Apple IIc if boot code is written with an extra zero inserted before each bit to yield a 250kpbs data rate, and the boot code switches the IWM to 500kbps before reading everything else? Are there any limits to the number of consecutive zero bits? If not, assuming the same 9216 raw byte/track limit, I think I could design a read track/sector routine for the Apple //c which could read and decode 7,168 bytes of arbitrary data from a track, starting anywhere on its rotation, in about 150ms. Setting aside some low-numbered tracks for “half-density” boot code, that would leave space for about 1MB of data in an image, allowing many multi-disk games that were adapted to use this format to fit within a single MOOF file.

    Also, I’m curious what the practicality would be of a read-only high-density mode which would stream data continuously from the SD card? SD write performance can be at times unpredictable, but I think the read performance would be predictable and consistent if, when loading a MOOF file, you located for each track the cluster holding the first block of associated data, so reading each 512 bytes of data would require at most two sector reads from the SD card–one to retrieve the data itself, and one after reading the last sector of each cluster to retrieve the cluster’s associated sector of the FAT so as to find the next cluster. The Woz and MOOF formats can accommodate an almost unlimited amount of data, and streaming direct from the SD-card would avoid the need to impose constraints smaller than that.

  2. Steve - December 8th, 2022 2:58 pm

    John you’re probably better off waiting for WOZ 3.5 support. It would be difficult to use a Macintosh drive (or Floppy Emu emulating one) on an Apple II computer, since they handle some I/O pins differently. Streaming directly from SD isn’t practical because the hardware is single-threaded and can’t easily do simultaneous SD transfers and disk emulation.

  3. firebottle - December 6th, 2022 1:37 am

    Incredible! Thanks for doing this!

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