Ugh, I’ve been going around in circles trying to settle on the best way to add a floppy disk replica to Plus Too. I’ve been thinking about this way too much, and now I’ve got visions of sync bytes dancing in my head. Here are the two main options:

Replacement Disk Driver

I could create a new disk driver that replaces the one in the Mac’s ROM. The great thing about this approach is that the driver API is very straightforward: it receives requests to read/write X bytes from offset Y on the disk. This could be almost trivially mapped to a disk image in a separate ROM or on a SD card, without ever having to worry about the IWM, disk heads, tracks, sectors, encodings, sync bytes, or anything else. A custom driver would also make it possible to have more disk drives, and larger disk sizes that don’t correspond to any real floppy disk.

The big drawback of this approach is that writing a custom device driver isn’t easy! Unfortunately it’s not as simple as just processing those read/write requests. The driver must correctly handle synchronous and asynchronous calls, hook into the interrupt manager, and handle all manner of control and status requests in the same way as the original Sony floppy driver.  I’ve spent a substantial amount of time digging through the internals of the Sony driver, and it’s pretty complicated. I don’t think I’m really up for the challenge of writing a new driver in 68000 assembly, using MPW. Even if I did get something that mostly worked, it’s likely the kind of thing that would have subtle bugs that would cause all kinds of hard-to-find problems.

A secondary concern is how to actually replace the original disk driver. I could modify the ROM image before programming it to the ROM chip, but that seems a little heavy-handed, and would make it more difficult to support a multi-Mac replica that handles more than one original ROM type. It would be nicer if the replacement driver were overlaid onto the Mac’s memory map without physically modifying the original ROM. But where would the replacement driver code be stored– in some other ROM? Or in internal memory of the FPGA? This could be solved, but it feels yucky.

IWM and Floppy Replication

The alternative approach is to use the original ROM floppy driver, and make hardware to replicate the behavior of the IWM and floppy drive. This was my original plan, and after a detour to examine the replacement driver idea, I think I’m going to return to this one. The big advtange of this approach is that success or failure will be binary: it won’t work at all, until it works 100%. That’s a lot more appealing than endless chasing bugs in a custom driver. This approach doesn’t require any ROM patching, and would also be a good foundation for later building the external floppy emulator for real Macs that I’ve been talking about.

This method does have several drawbacks. Replicating all the behaviors of the IWM and the floppy won’t be easy, especially the floppy behaviors. I’ve more or less mapped out everything I need to know to do it, but it’s still going to be a large task. This method also limits Plus Too to two* 800K disks, just like a real Mac Plus. I’m also concerned about implementing disk writes with this method: when the IWM starts spitting random bytes at the disk interface, it will take some processing to work backwards and figure out what sectors the Mac was actually trying to update.

Neither approach really seems great, and both would be a substantial amount of work. My gut tells me that IWM and floppy replication is a big task I can succeed at, whereas a replacement disk driver is a big task with a high potential to veer off into a ditch and fail, but maybe I’m overly pessimistic. Here’s hoping I can get at least one of these approaches to work!

* all three homonyms of “to”, consecutively in a sentence… English is crazy!