BMOW title
Floppy Emu banner

Apple IIc+ is Weird


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.

Read 7 comments and join the conversation 

7 Comments so far

  1. Peter Lund - February 11th, 2016 9:56 am

    Using a polling loop and only react if the bits have been stable for a while wouldn’t work?

  2. Steve - February 11th, 2016 10:13 am

    That would work in theory, but I can’t implement that method with the current hardware. Only the CPLD chip has visibility to all 4 control lines, and it doesn’t have space left to implement that kind of timer logic. The AVR microcontroller only has visibility as to whether side 0 or side 1 was the most recently accessed side parameter, from a bit provided by the CPLD. This is what gets polled after each sector, in the new firmware.

  3. Peter Lund - February 11th, 2016 2:39 pm

    Ah, that makes sense. Thank you for the explanation.

  4. David Kuder - February 21st, 2016 8:29 am

    Any chance of a second 3.5 mode that simulates one removable smartport drive?

  5. Steve - February 22nd, 2016 7:09 am

    It might be possible. How would you use that differently than the existing 3.5 inch disk mode? I think accessing a 3.5 drive using the Smartport protocol would be slower than accessing it as a standard 3.5 floppy drive.

  6. David Kuder - February 23rd, 2016 6:11 am

    It is, but allows greater compatibility with the Apple IIe card for Mac, and probably the IIc.

  7. Maciek Nowacki - February 23rd, 2016 8:58 am

    This seems hard to cleanly solve unless you can derive timing somehow. That way, you could synchronize with the computer, and only read the control lines when they are known to be in a settled state. The SD card should presumably have no trouble keeping up in that case. But, I don’t know, I guess I am doing a lot of handwaving with “derive timing somehow”…

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