It’s time for more Apple II love from Floppy Emu! The newest Apple II compatible firmware, apple-II-0.1M, adds a few small but important improvements:

• Fixed Smartport hard disk timing problem when starting from a cold boot (Apple IIgs, IIc, IIc+)
• 3.5 inch disk emulation is now supported on the Apple IIc+
• Floppy Emu Model B can now be connected internally on the IIc+

For hardware Model B: apple-II-0.1M-F8
For hardware Model A: apple-II-0.1M-F6

Floppy Emu is a floppy and hard disk emulator for classic Apple computers. Read more about it at the product page.
The Quirky Apple IIc+

3.5 inch disk support for the Apple IIc+ was something that had eluded me for many months. Thanks to Jeremy Moskowitz for lending me a IIc+ machine, so I could finally do the necessary troubleshooting.

If you’re curious why 3.5 inch disk emulation didn’t previously work on the IIc+, the reason is probably not what you would have guessed. The IIc+ was originally conceived as a 1 MHz machine, like the IIc. The CPU wasn’t fast enough to handle the data transfer speeds of 3.5 inch disks, so a new coprocessor chip called the MIG was added, along with some high-speed cache memory. Later the design was revised, boosting the CPU speed to 4 MHz, and eliminating the need for the unique MIG and cache system. Yet the MIG and cache remained in the final product anyway. I was virtually certain the IIc+ issues with 3.5 inch disk emulation and Floppy Emu were related to the MIG and cache, but it turns out I was wrong.

The problem was actually a limitation of the Floppy Emu design that hadn’t caused trouble previously. In 3.5 inch emulation mode, there are four control lines from the computer. These lines determine which one of 16 state parameters is being read from the drive at any given moment – info like what kind of drive it is and whether it’s at track zero, as well as the instantaneous data bits flying by the drive head on sides 0 and 1 of the disk as it rotates.

There’s no clocking or synchronization on these control lines, so Floppy Emu doesn’t really know when the computer is reading a parameter, versus when it’s transitioning to a different set of control line states. Typically the control lines don’t all change state at precisely the same time, so if the computer was reading parameter 0000 and then wanted to read parameter 1111, the Emu might observe the control lines changing in quick succession in a series like 0000 -> 0100 -> 0110 -> 1110 -> 1111. Normally this doesn’t cause any problems. The Emu briefly emits the info for the phantom states 0100, 0110, and 1110, but the computer isn’t reading these values and ignores them.

The trouble arises with parameters 1000 and 1001, which are the instantaneous data from the disk read head on sides 0 and 1 of the disk respectively. If the Emu observes a read of parameter 1001, it tries to provide data from the sectors on side 1 of the emulated disk. If the side 0 sector data is currently loaded in the Emu’s memory, it dumps it and fetches the side 1 sector data from the SD card. This takes a few milliseconds, and interrupts the flow of data from the emulated disk.
Phantom Reads

As you can imagine, an accidental phantom read of the side 1 parameter during I/O on side 0 would cause major problems, and this is exactly what was happening on the IIc+ in 3.5 inch emulation mode. The computer was repeatedly switching between parameter 1000 (side 0 data) and parameter 1101 (drive ready flag), brushing past 1001 (side 1 data) every time and causing an unnecessary load of side 1 data from the SD card, followed by another load of side 0. The Emu was caught in a perpetual cycle of reloading data from the SD card, and could never get anything else done.

How do you fix a problem like this? If the Emu had enough on-board RAM to load the side 0 and side 1 data at the same time, then there would be no penalty for phantom side switching. This is theoretically possible on the Emu hardware, but only for some disk types, and it would require some big changes to the firmware design. Another approach would be to filter control line states in hardware, and only react to a side 0 or side 1 transition after the control lines had remained at 1000 or 1001 for a while without further changes. This could easily be done in the Emu’s CPLD chip, if there were any space left to implement additional logic. Sadly the CPLD is already near 100% full with the existing disk emulation logic.

The solution I settled on was to poll the CPLD for which side is active, after handling each sector, instead of treating side changes as an interrupt. It’s not the ideal way to handle the issue, but it works. The phantom transition through parameter 1001 still happens on the IIc+, but the Emu ignores it unless it happens to fall right at the moment of polling. This happens very rarely, and when it does happen the computer treats it as a glitchy read, and simply tries the sector again.

Interestingly, I wrote another post titled Phantom Reads here seven years ago, for totally unrelated hardware that shared a similar conceptual problem.