bigmessowires
Well-known member
After a lot of tinkering, my Macintosh 400K/800K floppy emulator is finally ready! Yesterday I got read-only floppy emulation working from an SD card, in a rough approximation of the originally intended design. That makes it possible to download disk images of classic Mac software from the web, copy them to an SD card, and load them onto a Mac Plus or other Macintosh using the Floppy Emu.
You can use the emulator to boot a Mac, or boot from a normal disk and then mount the emulated floppy to copy files from it. I even copied an emulated disk using Disk Copy 4.2 on a Mac Plus, and explored all the sectors using FEdit, so I'm pretty confident that it's working right.
Unlike other floppy emulators that I know of, Floppy Emu uses an on-the-fly sector retrieval technique instead of a track-at-a-time technique. This technique only requires a single 512 byte buffer, enough for one sector. After the data bytes from a sector have been sent to the Mac, the microcontroller loads the next sector from the SD card, which takes about 2 milliseconds. On a real floppy the sector-to-sector padding is only about 0.25 milliseconds, but it turns out that the Mac is tolerant of much longer inter-sector delays as long as you keep sending it $FF sync bytes between sectors.
In its current form, Floppy Emu appears 3x slower than a real floppy disk, but I think that's due to a bug rather than the SD card overhead. Using Disk Copy 4.2, I was able to read an entire 800K floppy in 41 seconds, and an emulated version of that same floppy in 2 minutes 10 seconds. As best as I can tell, the difference is due to some kind of bug that’s triggering the Mac’s retry mechanism. The display screen shows the emulated active track and side in real-time, so I can see that after every few tracks read during disk copying, the drive seeks down to track 0, then all the way back up to the track where it left off. This looks like some kind of mechanism for coping with unexpected data: the Mac concludes the drive isn’t where it thought it was, so it resyncs by returning to a known location (track 0) and then continuing.
My next steps are to pretty this up a little, add some basic UI for selecting disk images from the SD card, and fix the bug that's causing the retry slowdowns. After that, implementing write support for emulated floppies will be the next task. That will require a different micontroller and different technique than the one used currently.
More details are on my blog if anyone's interested.
/edit/ Also available: the development thread, Design ideas for a floppy drive emulator. - Bunsen /
Question to the 68kmla.org community? How important do you think write support is for something like this? I plan to implement it eventually, but it may be a big challenge. Is there enough value in a read-only floppy emulator?
You can use the emulator to boot a Mac, or boot from a normal disk and then mount the emulated floppy to copy files from it. I even copied an emulated disk using Disk Copy 4.2 on a Mac Plus, and explored all the sectors using FEdit, so I'm pretty confident that it's working right.
Unlike other floppy emulators that I know of, Floppy Emu uses an on-the-fly sector retrieval technique instead of a track-at-a-time technique. This technique only requires a single 512 byte buffer, enough for one sector. After the data bytes from a sector have been sent to the Mac, the microcontroller loads the next sector from the SD card, which takes about 2 milliseconds. On a real floppy the sector-to-sector padding is only about 0.25 milliseconds, but it turns out that the Mac is tolerant of much longer inter-sector delays as long as you keep sending it $FF sync bytes between sectors.
In its current form, Floppy Emu appears 3x slower than a real floppy disk, but I think that's due to a bug rather than the SD card overhead. Using Disk Copy 4.2, I was able to read an entire 800K floppy in 41 seconds, and an emulated version of that same floppy in 2 minutes 10 seconds. As best as I can tell, the difference is due to some kind of bug that’s triggering the Mac’s retry mechanism. The display screen shows the emulated active track and side in real-time, so I can see that after every few tracks read during disk copying, the drive seeks down to track 0, then all the way back up to the track where it left off. This looks like some kind of mechanism for coping with unexpected data: the Mac concludes the drive isn’t where it thought it was, so it resyncs by returning to a known location (track 0) and then continuing.
My next steps are to pretty this up a little, add some basic UI for selecting disk images from the SD card, and fix the bug that's causing the retry slowdowns. After that, implementing write support for emulated floppies will be the next task. That will require a different micontroller and different technique than the one used currently.
More details are on my blog if anyone's interested.
/edit/ Also available: the development thread, Design ideas for a floppy drive emulator. - Bunsen /
Question to the 68kmla.org community? How important do you think write support is for something like this? I plan to implement it eventually, but it may be a big challenge. Is there enough value in a read-only floppy emulator?