BMOW title
Floppy Emu banner

Mac Floppy Disk Hardware

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!

Read 6 comments and join the conversation 

6 Comments so far

  1. gm - September 29th, 2011 7:17 pm

    >more difficult to support a multi-Mac replica that handles more than one original ROM type

    Do you have plans for this? I’d love to have a Quadra 950 on a FPGA, emulating a fast 040. That’d be awesome.

    Keep up the good work – it looks awesome so far.

  2. Steve - September 30th, 2011 6:24 am

    My goal is to replicate four different compact Mac models, from the Mac 128K through the Plus. Despite all my complaints about complexity, those systems are really just one step up from “dirt simple”. A Quadra 950 would be a whole different level of difficulty, but maybe someday!

  3. Dave - September 30th, 2011 1:46 pm

    It would be cool to replicate the IWM and floppy drive but it sounds like more work to me.

    You’re right that writing a custom device driver isn’t easy, but if you go with that approach you may be able to take advantage of work done by software based emulators. Mini vMac ( patches the rom with a floppy driver that allows you to use disk images of arbitrary size. See Mini vMac’s SONYEMDV.c.

  4. Steve - September 30th, 2011 2:00 pm

    Mini vMac is great, and I’ve been looking carefully through its replacement disk driver. Unfortunately it’s not easily usable for my needs, because most of the “driver” actually exists as C code in the emulator framework, and not as 68000 code within the emulated machine. The Mini vMac driver is able to do things that a real driver can’t, like magically fill an area of memory with data in zero time, and it can also side step most of the synchronous/asynchronous and interrupt issues I mentioned. It’s definitely the template I’d start from if I were making my own driver, though.

  5. Steve - September 30th, 2011 7:39 pm

    I made some more progress on the IWM/floppy tonight. The IWM is more-or-less done now, and the floppy provides a tachometer rotation speed pulse rate dependent on the current track, which makes the ROM routines happy. You can insert a “disk” containing all zeroes by pressing a button, and the Mac examines the disk, sees that it’s blank, and ejects it. That also replaces the flashing question mark with a flashing X for a moment. The next step is to start feeding it GCR encoded address and data for each disk sector. It should only take two sectors (1024 bytes) to produce a Happy Mac, and I can encode that data offline and store it in the FPGA. Assuming I can get that much working, then the final step will be to read the data from an SD card and encode it on the fly instead of doing it offline.

  6. Tom - October 1st, 2011 10:59 am

    Bonus points for the three consecutive homonyms.

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