I’m still working on development of an FPGA-based disk controller card for the Apple II – Yellowstone. Over the past couple of months, I spent a long while analyzing the design of the UDC disk controller. The UDC supports all three major types of Apple II disk drives, making it a promising place to begin learning. After that I spent a long while more exploring how I might squeeze the UDC’s 8K of ROM and 2K of RAM into the limited resources of Yellowstone’s FPGA. Just recently I finally finished up those investigations and returned to actively building and testing the Yellowstone card. Unfortunately it still doesn’t work.

I built a second Yellowstone prototype, identical to the original except for selecting a Lattice MachXO2-2000 FPGA instead of a MachXO2-1200. This new chip is just barely large enough to hold the necessary ROM and RAM for my UDC pseudo-work-alike Verilog code. I’m not sure if I’ll use this solution for the final edition of Yellowstone, or if I’ll use a smaller MachXO2 version paired with a separate ROM or RAM, but at least I’m up and running again.

The card seems to work as expected when I probe its memory space from the Apple II monitor. I can access all 8K of ROM via its custom bank-switching logic, and its 2K of RAM also through bank switching. I can probe its soft-IWM and watch the disk I/O lines change. Everything looks OK. But when I try to actually boot a 5.25 inch disk, it just freezes the computer.

It’s not completely dead; it does do *something*. The disk drive turns on and spins. Using a logic analyzer, I can see some brief activity on the disk I/O lines that I interpret as “hello, are you a 3.5 inch drive?” before it goes silent. If I then reset the Apple II and examine some memory locations where I know the UDC store status info, I can see that it detected one disk drive. But why didn’t it boot? More importantly, why did it freeze?

If this were a normal software program, I could use a debugger to interrupt the program and see where it’s frozen. That alone might be enough to reveal what’s wrong. If not, I could restart the program from the beginning, and step through it line-by-line until I found the problem. But nothing like that is possible here. There’s no facility for Apple II breakpoints or single-stepping through code that’s in ROM, and even if there were, the I/O code is timing-dependent and would likely break when run in the debugger. The poor man’s debugger is printed log messages, flashing LEDs, and similar indicators, but even that will be difficult. I can’t easily add or edit code in the UDC ROM, because it contains lots of absolute address references as well as implicit assumptions about certain chunks of code and data avoiding page boundaries.

I wish I still had my old HP 1631D logic analyzer. Then I could hook up 24 probes to the Apple II’s address bus and data bus and then let the computer run, examining the logged CPU cycles afterwards using the HP’s state listing view. My Saleae logic analyzer is nice for many tasks, but even if it had 24 probes, it’s basically only designed for timing / waveform views. I guess not many people look at parallel busses anymore.

Today I’m excited to introduce a major new feature update for the BMOW Floppy Emu Disk Emulator. The latest firmware for use with Apple II computers adds the three most frequently requested new features: writeable WOZ and NIB disk images, formattable disk images, and dual 5.25 inch floppy drive emulation. Each of these three was tricky to implement, and I’ve lost track of how many times I said these things were too complex or the hardware couldn’t support it. Forget all that, because here it is! This is the biggest set of changes to the firmware in the whole history of the Floppy Emu, requiring some extensive rework under the hood. I hope the results are worth it.

The new firmware is version 0.2Q-F29. You can download the latest firmware here: firmware

 
WOZ and NIB disk images are now writeable!

This is great for copy-protected programs that need to save some information to the disk, like your Print Shop printer settings or your Castle Wolfenstein game progress. While the sector-oriented disk image types like .PO, .DO, and .DSK have supported writes since day one, the bitstream disk images (WOZ and NIB) typically used for copy-protected programs were previously treated as read-only by the emulation engine. No more. Your Wolfenstein games will now be safely saved.

Getting this to work was challenging, because the Floppy Emu wasn’t originally designed to handle raw bitstreams. A few simplifying assumptions were made in order to bridge the gap. It’s possible a few programs may cause trouble if they perform writes in a very non-standard way, though I haven’t yet found any real-world examples. The firmware doesn’t make assumptions about sector sizes or layouts or headers, so it should work OK even if the written data doesn’t look like standard DOS/ProDOS sectors. For example, Wolfenstein writes sectors whose data header begins with the bytes D5 DA AD instead of the normal D5 AA AD.

WOZ disk images contain a read-only flag in their header. Writing to the disk image will be disabled if this flag is set.

 
You can format 5.25 inch disks!

This is great when making disk copies, or if you need to create a save disk from within a game like King’s Quest. In-emulator disk formatting makes life much more convenient when copying or saving data. I have striven to make formatting a feature that “just works” as much as possible, but there are a few important details to know.

Successful formatting is dependent on the write caching behavior of your SD card. If the card introduces too many long delays during writes while it flushes its internal cache, the format may fail. In most cases you can just try again and it’ll work. If the format keeps failing, try a different SD card.

Many disk duplication tools do a simultaneous format and write of the target disk. Some will also do a bit-level copy, attempting to duplicate hidden details of copy-protected source disks. Cracking tools like Copy II+ may not work correctly when the target disk is a Floppy Emu disk image. Use DOS 3.3’s COPYA or ProDOS’s Duplicate Disk utility, both of which work fine.

Formatting is also dependent on the type of disk image used, and potentially also on the disk image’s metadata. In short: if you need to format a disk, use this Blank.woz disk image and you’ll be fine. Only NIB and WOZ disk image types support true formatting. All other types will retain standard DOS/ProDOS sector layouts and volume number 254 regardless of how you attempt to format them. NIB disk images have tracks that are about 4% bigger than normal, which is sort of like a disk drive that spins 4% too slowly. DOS 3.3 still formats a NIB just fine, as will games using normal RWTS routines, but ProDOS will complain the drive is too slow. Formatting WOZ disk images is more reliable, but it must be a WOZ image of a normal disk with normal track lengths and track layouts. If you just grab some copy-protected WOZ disk image and try to format it, it may fail. The provided Blank.woz should format nicely using most Apple II programs.

 
Dual 5.25 inch drive emulation is here!

Now the Emu hardware can emulate two 5.25 inch drives at once, which is great for two-disk games and for reducing disk swapping. This feature is available on the Floppy Emu Model C, so you may wish to consider an upgrade if you have an older model and frequently use 5.25 inch floppy emulation. Dual 5.25 emulation mode is compatible with any Apple II computer or 5.25 inch disk controller with a 19-pin D-SUB (DB-19) connector, except the Apple IIc. The IIc and the rectangular 10×2 pin disk connector both lack the necessary disk I/O signal for controlling a second drive. Both could theoretically be supported in the future with some kind of Y-cable adapter that plugs in to two separate disk connectors. Coming soon, maybe?

Don’t use Dual 5.25 mode in combination with the optional BMOW Daisy Chainer or A/B Switch. It will cause disk errors and could damage the Floppy Emu or your daisy-chained 5.25 inch drive.

Dual 5.25 mode emulates two daisy-chained 5.25 inch drives on a single Floppy Emu board. When using this mode, care must be taken to avoid accidentally creating a forked daisy chain with two branches. This could cause the Floppy Emu and another daisy-chained or A/B-connected 5.25 inch drive to fight with each other, possibly damaging them both. To avoid this, select single 5.25 inch emulation mode when using the Daisy Chainer or A/B switch.