Lisa Native Floppy Emulation
Lisa floppy drive emulation with Floppy Emu is a success! Begone, evil rotational disk drives, with your failure-prone gummed-up mechanisms. The age of SD card Lisa floppy emulation is here!
After a lot of tinkering, it’s now working on both the Lisa 2/5 and 2/10, and for both Lisa-format and Mac-format disks. I’m able to boot the Lisa from the emulated floppy drive, and use it to install Lisa Office System and other apps to the HD, and copy apps and data files from the Lisa HD to the emulated floppy drive. It also works for Mac-format disks, when running the Lisa under Macworks.
The final hurdle was realizing that the custom adapter I’d built to simultaneously connect a 400K floppy drive and a Floppy Emu was causing problems. After getting rid of the adapter and connecting the Emu directly to the Lisa, in place of the normal floppy drive, it’s now working perfectly.
Disk Copy 4.2 Format
From the previous Lisa firmware that I described in an earlier post, the last big piece of the puzzle was adding support for “tags”. On a Lisa floppy disk, a sector consists of 512 bytes of data and 12 bytes of tags. Raw disk image files don’t save the tag info – they’re just a byte-by-byte copy of the 512 data bytes from each sector. So in order to correctly emulate Lisa-native disks, it was necessary to use a disk image format that preserves tags: Disk Copy 4.2 images, the format I love to hate.
Floppy Emu already supported DC42 format image files for use with the Macintosh, but they were treated as read-only disks by the emulator firmware. The problem with tagged DC42 images is that the logical sector data isn’t aligned in the image file, nor in the FAT32 filesystem of the SD Card, and the sector tags are stored separately from the sector data. So to load a single sector of the emulated floppy (512 bytes data plus 12 bytes tags), it’s necessary to load three or sometimes four 512 byte sectors from the SD card, depending how the data and tags for that particular sector are aligned. It’s a pain in the butt.
Writing DC42 images is more complicated still, which is why previous firmware treated DC42 images as read-only. To perform the unaligned writes, the firmware must read a sector from the SD card, modify part of it, then write the modified version back. Again, this can involve three or four SD card sectors in order to write a single emulated floppy sector. SD cards really don’t like this pattern of read-write-read-write for single random-access sectors, so performance suffers a bit. But the new firmware code does its job, and writing to DC42 disk image files is now possible.
Checksums
The last unsolved item is DC42 file checksums. A DC42 image file contains a 32-bit checksum of all the data, and a separate 32-bit checksum of all the tags. If you attempt to load an image file with invalid checksums in Disk Copy 4.2, it will refuse to open it. Floppy Emu doesn’t care about the checksums, but there can be a problem if you copy a modified DC42 image file off your SD card, and try to use it with Disk Copy 4.2 or another utility that does care about checksums.
What’s the best way to make sure the checksums are kept up to date, when the DC42 image file is modified? Now that I know the checksum algorithm, I can recompute the checksum easily enough, but when should I do it?
- It’s impractical to recompute and save a whole-disk checksum, every time any sector is modified.
- I can update the checksum when the disk image is ejected, but that’s dangerous because ejection is very often a prelude to auto power-off a moment later. It takes about 2 seconds to recompute the checksum for a 400K disk, and 4 seconds for an 800K disk. Usually the time between ejection and shutdown is less than that. If the Floppy Emu loses power while it’s writing the new checksum value, the SD card could become corrupted.
- I might recompute the checksum when the disk image is inserted, but that’s unintuitive. Re-insert the disk image, in order to fix its checksums? And for systems like the Mac that write the last mount time whenever a disk is inserted, the checksum would still always be wrong.
- I might add some new Floppy Emu menu option or feature to recompute the checksum on demand. But that’s a strange special case I’d like to avoid, and doesn’t feel like the right solution.
- I could do nothing, and let people fix up the checksums with an offline tool if they ever need to copy them off the SD card and reimport them to Disk Copy 4.2. This is my solution for now.
Try It
If you’ve got a Lisa and a Floppy Emu, you can try the new firmware yourself. I’ve named this firmware version lisa-emu-1.0S6-F11, and it contains all the changes needed to emulate Lisa-format and Macintosh-format floppies on the Lisa computer, and to boot a Lisa from the Floppy Emu board. 1.0S6-F11 contains some changes that aren’t compatible with early Macintosh models, so while you won’t hurt anything by trying it on a Mac system, it may not work. For best results, use the normal Mac firmware for Floppy Emu with Macintosh computers, and use 1.0S6-F11 only when working with a Lisa system.
Read 9 comments and join the conversation9 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
Just tried the new firmware with My Lisa 2/10 running LOS 3.0.
Works like a charm!
I don’t have a lisa but am really happy you figured it out. I totally knew you were going to tackle it.
u is da man!
Funny what you think of Disk Copy 4.2… A good friend of mine, Byron Han, wrote the software for Apple when he was still working as a contractor in Honolulu. We had a small Apple programming club that consisted of me, Byron, a couple of guys who worked on “Final Fantasy,” and a few other Apple programmers. The only thing we really did was hold dinner meetings at various Thai restaurants. Byron used to be a frequent guest on my Apple/Mac radio show in the late 1990s, and we talked in great detail about Disk Copy. I should have a digital recording of the show somewhere. If I ever find it, I’ll upload it to YouTube or the like.
As for the Lisa support, I’ll have to try it. I’ve been running my IDEFile Profile emulator that replaced the hard drive in my Lisa 2/10. Like you, my keyboard needs some major work, so it’ll be awhile before I can start running the Lisa once again.
Congratulations Steve!
Regarding checksum calculations, this is all performed on the Floppy Emu correct?
A software solution would be to start calculating a checksum when disk access is idle (perhaps after some timeout) with the ability to interrupt calculation if there is new disk access. If you have enough free time to calculate and save, great! If you are interrupted, just start over next time it goes idle.
A hardware solution to ensure complete calculation when ejecting would be to add an appropriately-sized electric double layer capacitor (a.k.a. Supercap) that allows 8+ seconds of operation after power is removed. You would need a circuit to prevent overloading the +5V from the Mac/Lisa when charging and a way to flag the Floppy Emu that is is time to hurry up!
Thanks for the ideas! I considered the checksum-while-idle solution, and I think it’s a good approach except for one thing: when you shutdown the computer, it very often does one last disk write to mark the disk as unmounted, immediately before it ejects, immediately before it powers off. So there’s still a risk of being in the middle of writing a new checksum to SD card when the power goes off.
A large capacitor and a low-voltage interrupt should work. I really don’t want to modify the hardware for this, though – and most people will be using the new Lisa firmware with pre-existing Floppy Emu hardware anyway.
It miiiiiight be possible to calculate the effect of one changed sector on the pre-existing disk checksum, instead of recomputing the entire disk checksum. I need to think about the checksum algorithm more to see if that’s really possible. But even if it is, it’s borderline unacceptable anyway because it would add yet another read-write to the SD card for every emulated floppy sector write, slowing things down a bit more. And I would worry about the longevity of the SD card, if I were constantly rewriting the same one sector on the card.
It feels like there should be a good answer to this somewhere, but I’m not able to think of one. I’m probably going to change the behavior to do write a zero checksum the first time a write is performed, and leave it at that. At least that way, some hypothetical future disk archivist can tell that the checksum was intentionally zeroed out, instead of wondering if the disk image is corrupted.
Is the write to mark the disk unmounted at a predictable location? If so, you could preemptively calculate the checksum with it always set to unmounted, and then there is no need to re-calculate when that last write to unmount comes through (assuming you had enough idle time before that happens).
Ouch, the DC42 checksum function is nonlinear enough that you can’t compute a partial checksum for each sector and recombine them again later? (After looking at how it works I can see how that’s probably the case. That’s unfortunate, most of the standard 32-bit checksums don’t have that limitation.)
Another way to make it should be to allow checksum modification when emu is idle of course but to cancel it immediately when it receives eject command so a shutdown won’t corrupt the SD card. In order to save the SD card, a timer (something between 10 to 30s of emu idle time) after a disk write should be added before writing the computed checksum to the SD.