Floppy Emu Chameleon Firmware
Here’s a fun party trick: firmware for the Floppy Emu disk emulator that emulates a 5.25 inch floppy drive, but then reconfigures on the fly as a Smartport hard disk emulator. Why is this useful? It’s not obvious at first, but if you’re a Floppy Emu owner with an Apple IIgs and an Apple 3.5 inch floppy drive, read on. Or if you just like nifty hacks, this one’s for you.
The IIgs supports daisy-chaining up to six disk drives – a great feature. Unfortunately there are strict rules about what order the drives must appear in the chain, depending on their type, and there are further limitations on which drives can be used as boot drives. So there are some perfectly reasonable drive combinations that are impossible in practice.
The best example is a Floppy Emu configured for Smartport hard disk emulation mode, combined in a daisy chain with an Apple 3.5 inch floppy drive. IIgs owners want to boot from the Emu’s Smartport HD most of the time, but still want the flexibility of having a 3.5 inch drive for the occasional physical floppy. Apple says no. Drive ordering rules require the 3.5 inch drive to appear before any Smartport drives, and only the first drive in the chain can be used to boot the computer. The IIgs will always attempt to boot from the Apple 3.5 inch drive. So the desired configuration is impossible, and this is a limitation of the Apple IIgs design rather than anything specific to the Floppy Emu.
But wait… maybe there’s a hope. Eric Jacobs points out there’s a table that controls the boot priority of the drives in the daisy chain, located in Apple IIgs memory at address E10FC0. This table is initialized during a cold boot and gives the first drive first priority. If you edit the memory table and then restart with a warm boot, you can force the IIgs to boot from a different drive, like the Emu’s Smartport HD instead of the Apple 3.5 inch drive.
That’s good news, and it provides a theoretical solution, but the actual practice is lousy. You have to turn on the computer, interrupt the boot process with control-reset, enter the Apple II system monitor with CALL -151, and manually edit the memory table using arcane debug commands. Then you finish the process by forcing a jump to the warm start address. Several months ago I confirmed that this process works, but it’s not very user-friendly, so I dropped it.
Here’s where part two of this party trick comes into play. The IIgs also supports 5.25 inch floppy drives, which must be connected in the daisy chain after any 3.5 inch and Smartport drives, but nevertheless normally get a higher boot priority than the other drive types. I can leverage this fact to make the Floppy Emu appear as a 5.25 inch drive, which loads a small bootstrap program that edits the memory table. Then the Floppy Emu auto-reconfigures itself as a Smartport drive, and the bootstrap program performs a warm start of the IIgs.
Here’s the play-by-play process:
- Connect the Apple 3.5 inch drive to the Apple IIgs
- Connect Floppy Emu to the Apple 3.5 inch drive
- Turn on the Apple IIgs
- Floppy Emu configures itself as a 5.25 inch drive
- Floppy Emu provides a hard-coded disk image containing a bootstrap program
- Apple IIgs boots from the 5.25 inch bootstrap disk
- Bootstrap program displays a splash screen and modifies the IIgs memory table
- Floppy Emu reconfigures itself as a Smartport HD
- Bootstrap program performs a restart of the IIgs
- IIgs boots from the Floppy Emu’s Smartport HD
The net result is that it’s now possible to have an Apple 3.5 drive and a Floppy Emu Smartport HD in the same daisy chain, while booting from the Emu’s HD – something that was previously impossible.
Watch the video carefully, and you’ll see a text screen flash by that says “Big Mess o’ Wires, rebooting from smartport unit 2…” That’s the bootstrap program at work. Unfortunately my composite video to HDMI adapter creates ~5 seconds of blackness whenever the IIgs first powers on, or changes between text and graphics modes, so this isn’t the greatest video. The whole process from power on to Smartport HD boot only takes about 10 seconds, with no user intervention needed.
It works, but there are still some details to resolve. There’s a timing dependency between when the computer boots, when the Floppy Emu reconfigures as a Smartport HD, and when the bootstrap program restarts the IIgs. I used hard-coded delays that work on my system, but may not work for other people. Get these delays wrong, and the IIgs will fail to boot from the bootstrap disk, or will restart and try to boot from the Smartport HD before the Floppy Emu has reconfigured itself. A better solution would involve some kind of control signal between the IIgs and the Floppy Emu to orchestrate the timing, rather than relying on fixed delays with no feedback.
A second problem is that this trick is incompatible with my (yet to be released) Daisy Chain Adapter. The Daisy Chain adapter senses what type of disk the Floppy Emu is configured to emulate, and acts accordingly. It can’t support a Floppy Emu that suddenly transforms from a 5.25 inch drive into a Smartport HD in the middle of operation. There needs to be some way for it to detect that this has happened, or be notified that it’s happened, so it can reset its own internal state. But so far I’m lacking any practical ideas on how to do that. In the worst case I can simply warn users that this firmware trick is incompatible with use of the Daisy Chainer, but that would be a shame.
Read 5 comments and join the conversation5 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
As far as I understand, you \”only\” need a signal from the Apple to the Floppy Emu to switch from the 5.25\” bootstrap image to the Smartport HD emulation.
I assume that the bootloader does not need to write to its emulated disk, and that neiter the Apple nor the bootloader writes to the emulated disk.
So I would simply write to a (preferably unused) part of the emulated boot disk from the bootloader. The Floppy Emu knows that it is still simulating the special boot disk, does NOT change the disk image, but pretends it did a successful write. This write access would now switch the Floppy Emu to Smartport HD emulation.
Essentially, you would replace the delay in the Floppy Emu with something like this:
if (isInBootloaderMode && IsWriteAccess()) SwitchToSmartportEmulation();
And in the bootloader, replace the delay with a simple write access to the emulated boot disk.
Tux2000
Hi Tux, yes I think that could work for removing the hard-coded delays. I will look into the details. Thanks for the idea!
OK, I think I’ve successfully finished the “chameleon” firmware, which I’m calling “Smartport Unit 2 mode”. This mode loads a bootstrap program that causes the IIgs to attempt to boot from Smartport unit 2. New firmware release is pending soon.
This only works when a Floppy Emu is daisy chained to an Apple 3.5 drive. It doesn’t work if the Emu is chained to a Unidisk 3.5 drive, because the Unidisk 3.5 gets confused when the Floppy Emu magically transforms from a 5.25 inch drive into a Smartport drive. For the tiny number of people for whom this matters, it’s still possible to boot from a Floppy Emu in standard Smartport mode that’s daisy chained to a Unidisk 3.5, by manually performing the work of the bootstrap program. Power on the computer, and then type:
] CALL -151
* E1/0FC0: 02 01
* 00/C500G
Some funny things happen if you choose Smartport Unit 2 mode when there aren’t actually two smart devices present. If there are no smart devices, it just fails. If there is one smart device and one 5.25 inch floppy drive, the computer will attempt to address the 5.25 inch drive as if it were a Smartport device, which will write random garbage data to the floppy. Fortunately the Floppy Emu protects against this both for itself, and (with the Daisy Chainer) any daisy-chained drives behind it, but it’s a potential concern if you’re manually editing the E1/0FC0 table while using real floppy drives.
The Smartport Unit 2 mode behavior is now controlled by a signal from the bootstrap program, rather than hard-coded timing loops. The Daisy Chainer board also detects this same signal, and resets itself, so the board is compatible with this new emulation mode.
I’ve finished testing the Daisy Chainer board with these new changes, and on every other hardware combination I can think of, and it looks good. So watch for that product to appear in the BMOW store soon.
Very very cool!
I am very excited to see this firmware. Maybe I can finally copy a few disks to my Floppy Emu!