Good news for Apple II fans: there’s a new Apple II firmware update for the BMOW Floppy Emu Disk Emulator. This update introduces substantial emulation enhancements for copy-protected Apple II software on 5.25 inch floppy disk images. Though Floppy Emu is designed for standard non-protected disks, most copy-protected games and utilities should now work too, including most disks from the WOZ-a-Day collection.

The new firmware is version 0.2N-F26 or 0.2N-F27, depending on the model of your Floppy Emu board. You can download the latest firmware here: firmware

 
Background

Disk images of copy-protected Apple II software normally must use raw bitstreams, rather than using any high-level data representation like sectors. The NIB and WOZ disk image formats are both raw bitstreams, and the WOZ format has grown increasingly popular for this purpose over the past couple of years.

The BMOW Floppy Emu has supported both NIB and WOZ formats for some time. But even when the disk images could be read, the games didn’t necessarily always run correctly, because they sometimes attempted weird non-standard things with the disk drive. The Floppy Emu hardware didn’t always respond to these attempts as the games expected. The focus of this firmware update has been addressing a handful of edge cases and uncommon behaviors to satisfy most copy-protection schemes, enabling more copy-protected games to work with the Floppy Emu.

Thank you to Nick Bauer, who provided me with a carefully-researched list of several dozen copy-protected WOZ games that weren’t working correctly with the previous Floppy Emu firmware. Nick documented the behavior of each game on two different Apple II models, as well as with MAME, which was a tremendous help. After a few weeks of R&D when the new firmware was ready, Nick tested it with 350+ disk images from his collection.

So what changed?

 
SD Card I/O Rate

The most significant change is a doubling of the data rate when communicating with the Floppy Emu’s SD memory card, from 5 Mbps to 10 Mbps – the maximum rate supported by the hardware. The data rate has been 5 Mbps since the earliest days of the Floppy Emu, because 10 Mbps didn’t appear to be necessary, and because higher data rates increase the chances of signal errors due to analog signal effects. But at least one copy-protected game wouldn’t run correctly without the higher data rate – the Floppy Emu simply couldn’t fetch data fast enough from the SD card to keep the game satisfied. So 10 Mbps it is.

The data rate was increased in order to help 5.25 inch floppy disk emulation, but it also affects Apple II 3.5 inch floppy disk and Smartport hard disk emulation. This is the change I’ll be watching most closely for user feedback. If there’s already some source of electrical signal degradation in the system, like a noisy power supply, then the increased data rate may result in an unacceptable number of SD card read/write errors. In my testing, it worked smoothly with three different Apple II computers, five different Floppy Emu boards of various generations, and three different SD cards. But one of my earliest hand-soldered Floppy Emu prototypes did report errors at 10 Mbps, so I’ll be keeping an eye on this.

The SD card data rate can be reduced to the old rate of 5 Mbps by holding down Floppy Emu’s PREV button during power-up. In this case, a small number of copy-protected games including Hard Hat Mack may not run correctly, but most software will be unaffected.

 
Disk Bit Rate

Floppy Emu’s interface with the Apple II computer lies at the opposite end of the data funnel from the SD card. To the computer’s disk controller, the Floppy Emu looks like a standard 5.25 inch floppy drive, with a standard data rate of one bit every 4 microseconds. Except that some copy-protected software violates this standard. The new Floppy Emu firmware changes the bit rate from a fixed rate of 4 microseconds per bit to a variable rate that depends on the disk image, helping games with non-standard bit rates to run correctly.

How does this work? A 5.25 inch floppy disk spins at 300 RPM, which is one rotation every 200 milliseconds. A normal floppy disk has 50000 bits evenly spaced around each circular track, resulting in a rate of one bit per 4 microseconds. But some disks squeeze 51000 or 52000 bits into a track, which produces a bit rate closer to one bit per 3.9 microseconds.

The Floppy Emu’s hardware design makes it difficult to compensate for this, and the previous firmware didn’t even try. The 4 microsecond number is baked into the logic of Floppy Emu’s CPLD chip, ensuring that the rate never wavers even if the microcontroller is servicing an interrupt or is otherwise busy. While this is very helpful for normal disk images, it means that the bit rate can’t be adjusted on the fly. In practice this was rarely a problem, and most games with a 3.9 microsecond bit rate still worked just fine at 4.0 microseconds, but a few did not.

After some experimentation, I settled on a new CPLD design that allows for on-the-fly selection of a few different fixed bit rates. While this isn’t quite as flexible as a fully-adjustable bit rate, it satisfies nearly all of the copy-protected games I tested without requiring any Floppy Emu hardware changes.

 
Cross-Track Synchronization

Some copy-protected games rely on the relative spatial orientations of adjacent tracks on the disk. The WOZ disk image format encodes this information, and the old Floppy Emu firmware was already maintaining this cross-track synchronization. Frogger uses a track synchronization technique called Spriadisc, and it worked nicely on the Floppy Emu. But deeper investigation revealed there were still some cases where cross-track sync wasn’t being handled properly. The details depended on what method the software used to verify the track synchronization: counting disk bytes, measuring time, or some hybrid method.

There are several sources of potential synchronization error. Whenever the CPLD bit rate doesn’t exactly match the original disk’s bit rate, the behavior in the time domain will be slightly off. An entire track’s worth of bytes will be transmitted in slightly less or slightly more than 200 ms. With the old firmware, this type of error was most evident for games using cross-track synchronization and that had a number of bits significantly different from 50000. This error is mostly eliminated now that the bit rate is changeable.

A second source of error appears when games verify track synchronization through byte counting, if the SD card can’t load the track data quickly enough. A game might read sector 0 from track 0, then immediately step to track 1, and then count how many bytes pass by before sector 0 appears on the new track. If track 1’s data isn’t finished loading from the SD card yet, the Floppy Emu will insert a continuous series of special 10-bit timing bytes into the bitstream, until the real track is ready. This results in the software counting a different total number of bytes until sector 0 appears. Increasing the SD card data rate helps, by loading the track data faster, and reducing or eliminating the time period where the game sees 10-bit timing bytes instead of the track’s data bytes.

 
Weak Bits

Another common copy-protection scheme involves regions of the disk where there’s no magnetic flux. Due to the design of the floppy drive hardware, these will appear as random data when read. A new random-looking value will be read each time the empty region of the disk is accessed. Copy-protected software can test for this, and confirm that the data really is changing randomly and isn’t some fixed random-looking pattern, such as would be produced by Copy II+ or other disk copying software.

Floppy Emu already supported weak bits, and automatically substituted random “fake bits” in their place. All of the weak bits examples in the WOZ disk image reference set were working fine. But as with cross-track synchronization, a closer look found there were still some minor problems. It appears that the random fake bits supplied by Floppy Emu weren’t quite random-looking enough for some copy-protected software. This was hard to pin down, and I experimented with longer and shorter random sequences, as well as changing the sequence length. What seemed to help most was changing the distribution of random values, so that 0 bits were more likely to appear than 1 bits. The WOZ reference actually mentions this, but I’d tried it once earlier and it seemed to actually make things worse. It remains something of a mystery, but is working OK now with the disk image test suite.

 
Other Fixes

Aside from the interesting copy-protection stuff, this new firmware update also includes some basic bug fixes. I found two cases where track-to-track stepping movements of the disk were being misidentified or missed altogether, resulting in the Floppy Emu moving to the wrong track of the disk. Neither of these cases ever appeared with normal software, but they sometimes happened with copy-protected games that used custom code to directly control the stepper motors. A small fraction of WOZ disk images were also being misidentified as DSK images, causing errors when attempting to use them.

Oh yeah, one more thing: the new firmware also includes a menu usability enhancement for SD cards with deeply-nested directories of disk images. When exiting a subdirectory and returning to the parent directory, the selected menu item will now be the item for the subdirectory that was just exited, instead of the first menu item. This makes it easier to navigate into and out of subdirectories without getting confused and lost.