Work continues on Yellowstone, my FPGA-based universal Apple II disk controller based on the UDC design. I’ve finished some initial testing, and while the results were mostly positive, a few problems may spell trouble.

First the good news: I’ve tested Yellowstone successfully with reading and writing 5.25 inch drives, 3.5 inch drives, and Smartport hard drives. I tried it with an Apple IIe as well as an Apple IIGS, and with a good variety of different disks. I tried GS/OS. I tested a whole pile of copy-protected 5.25 inch disk images. While not everything went smoothly, most of the results have been positive.

The majority of the testing has been with my BMOW Floppy Emu disk emulator rather than any real disk drives, because the current Yellowstone prototype is a 3.3V device without 5V-safe inputs. The next iteration of the prototype will add a 5V buffer for safety. The inability to test with real drives means I also haven’t yet tested daisy-chaining or dual-drive support. But before I realized the potential risk to the 3.3V hardware, I did try the card with a Unidisk 3.5 drive, and everything worked fine. Hopefully I didn’t damage anything.

I’ve also tested Yellowstone in a computer that’s stuffed with other cards in the peripheral slots, rather than just Yellowstone by itself. This was the downfall of my original efforts on this project, a couple of years ago: the card didn’t work when too many other cards were also present, but I couldn’t determine why, and I eventually gave up. That problem seems to be resolved now. I tried the updated card in both the IIe and the IIGS with all slots filled but one, and everything looked good – almost. I did experience one intermittent error on the IIGS with the slots filled, but I think it was a coincidence and the cause of that error is probably unrelated. I wasn’t able to reproduce it after more attempts.

Now for the bad news:

 
Bad Status Codes in Smartport Request

When booting GS/OS 6.0.2 from a Smartport HD disk image with Yellowstone, twice it failed part-way through the boot sequence with a “status code 0A” error on the Floppy Emu’s display. This means Floppy Emu received a status request of type $0A, which is undefined (valid values are $00 through $03). But it worked normally on about a dozen other attempts, and I wasn’t able to find any pattern to explain what might cause this. The correct behavior would be for Floppy Emu to return a response $21 meaning ‘invalid status code error’ instead of aborting, so I can try this if it happens again. But I’m not sure why it happens at all.

 
Troublesome 5.25 Inch Disks

A few 5.25 inch disks don’t work. Three of these are copy-protected WOZ disk images that don’t work very reliably on standard disk controllers either, so I’m not too upset, but the behavior is worse with Yellowstone. They freeze during booting or the disk just isn’t recognized at all. These are probably caused by limitations of the Floppy Emu’s WOZ support interacting with Yellowstone. Fortunately it was only three out of my collection of 56 most troublesome disks that had any issues.

Two other 5.25 inch disks crash into the Apple II monitor immediately upon booting with Yellowstone: Anti-M (a pre-boot disk to defeat some copy-protections) and Copy II+. I looked at the source code for Anti-M, and its boot sequence copies and patches the code from the disk controller card’s built-in ROM. It appears to assume the disk controller is a standard Disk II controller, or else one of a few other known types, so it’s doubtful this will ever work without patches to Anti-M. I’m guessing Copy II+ is something similar.

In the next version of Yellowstone, I plan to add a switch to select ‘pure Disk II mode’ for disks like these. When it’s on, this switch will disable Yellowstone’s other behaviors and use a vanilla Disk II controller card ROM image. This will hopefully be enough to get those outlier disks working, though I haven’t yet confirmed this.

 
IIGS Fast Mode and 5.25 Inch Disks

When the IIGS is running at system speed ‘fast’ (the default), I found two 5.25 inch disk images that wouldn’t boot. Both of them cycle repeatedly between track 0 and track 2. I’d probably be willing to write this off as a known-incompatibility, except one of the disks is the DOS 3.3 System Master! When the system speed is changed to ‘normal’ (meaning slow), those disks load normally.

This is unexpected, because the code in Yellowstone’s ROM specifically sets the IIGS system speed to normal whenever it’s doing disk I/O. What’s more, a real UDC card boots these disks just fine at fast speed. I’m not sure exactly what’s wrong, but it’s probably some interaction between my IWM model and the IIGS fast speed for code that bypasses the Yellowstone ROM and directly controls the IWM. This may be difficult to resolve, but I’m optimistic I can figure it out.

 
IIGS and 3.5 Inch Disks

3.5 inch disk emulation appears to work fine on the Apple IIe, and on the IIGS with 800K disks like ProDOS and ADT Pro. But when attempting to boot GSOS from a 3.5 inch disk, it reports an error: “Unidisk3.5 requires a driver. Install UniDisk3.5 driver on boot disk and re-boot system.” GSOS 5.0.4 and 6.0.1 report the same error. Changing the system speed has no effect. It doesn’t matter whether the drive is a Floppy Emu in 3.5 inch floppy emulation mode, or a real Apple 3.5 Drive.

The kicker here is that a real UDC card triggers the same error. And if I boot GSOS from the built-in disk controller, and attempt to access Yellowstone or the UDC as a secondary controller with a 3.5 inch disk, I still get the same error as soon as it attempts to access the 3.5 inch disk. So as it stands now, Yellowstone is completely useless as a 3.5 inch disk controller on the IIGS if you’re running GSOS.

This bug is the worst of the bunch, because I have no idea what causes it or how to go about fixing it, and it appears to be a fundamental problem with the UDC design rather than some flaw with my Yellowstone implementation. As far as I know, there was never any driver that shipped with the UDC. I’m not sure why GSOS is even complaining about the ‘Unidisk3.5’ driver when I’m connecting an Apple 3.5 Drive rather than a Unidisk. But if Laser / V-Tech never fixed this incompatibility between the UDC’s 3.5 inch floppy support and GSOS, then I don’t think I’ll be able to either.

I do have one small clue: back in 2015 when I was first implementing Floppy Emu’s 3.5 inch floppy drive emulation for the Apple II, I remember seeing this same error from GSOS. I don’t recall precisely what caused it, but I think it was due to the drive responding in unexpected ways to the disk enable signals. This may be GSOS’s generic error message for “something unexpected happened with your disk” rather than a true need for a driver. Has anyone else ever seen this error, or have any thoughts on where to begin troubleshooting?

Success! My Yellowstone disk controller card for the Apple II now works with 3.5 inch floppy drives! Along with the previously-implemented 5.25 inch floppy and Smartport HD support, this completes the triumvirate of Apple II disk drives. While it’s still very rough around the edges, I now have a working universal disk controller for Apple II that can handle any type of disk drive. This is exciting, because existing disk controllers for two of the three drive types are rare, expensive, or both. After a very long period of slow progress, I feel that everything’s finally starting to come together.

I’m especially pleased to see 3.5 inch floppies working, because 1 MHz Apple II machines like my Apple IIe theoretically aren’t fast enough to keep up with the higher bit rate of 3.5 inch disks. There’s not enough time for the CPU to poll for a new byte, store it, and get ready for the next byte before it’s already passed by. The official 3.5 inch disk controller card from Apple solves this problem by placing an entire second computer on the disk controller, with its own 2 MHz 6502 CPU, RAM, and ROM. But Yellowstone uses some Very Special Tricks in hardware to achieve 3.5 inch floppy support on the 1 MHz CPU. It borrows a technique from the UDC disk controller, and forces the computer’s READY signal low to halt the CPU until a new disk byte is ready. This eliminates the need for software polling, and shaves just enough cycles to make everything work.

So now what? This is just the beginning; a proof of concept more than a finished project. I’ve only done the most cursory testing, and I’m sure there are many compatibility problems still to address, and devilish bugs to find and fix. I know about a few of them already. Here’s some of my planned testing:

• Test all disk types with more thorough read and write tests
• Try all the copy-protected 5.25 inch disks that rely on weird behaviors
• Test formatting disks
• Test with other cards installed in every slot
• Test with an NMOS 6502 CPU
• Boot from another disk controller and access Yellowstone as a secondary
• Use with Apple IIGS at fast speed
• Boot GSOS from 3.5 inch floppy and Smartport HD

Yay for testing. It’s important, but not very fun, and I may enlist some beta testers to help. The other big task still ahead is to design the second hardware version of the Yellowstone card. The current prototype has sprouted extra patch wires and even an extra chip glued to the board, but it’s still missing some key features. Here are some of the items on my to-do list:

• Remove SPI ROM
• Add external SRAM
• Add a second disk connector
• Add a switch to select between 2-port operation or daisy-chain 1-port
• Buffer to isolate FPGA from disk signals
• Connect Q3 and IOSTROBE to FPGA clock pins
• Connect the upper 4 address lines
• Connect RDY and PHI1
• Add output buffer for RDY
• Make better / wider GND connections
• Improve the bypass capacitors
• Allowance for in-circuit JTAG / SPI reprogramming
• Allowance for self-test or external test
• Add open-drain buffers or inline resistors for disk signals with multiple drivers
• Label all the unlabeled pins and ports on the card
• Switch to a bigger LDO voltage regulator
• Add more power and ground test points
• Round the corners on PCB

That ought to keep me busy for a while.

Way back in 2017, I began development of Yellowstone, an FPGA-based disk controller card for the Apple II. It’s hard to believe it’s been almost four years. Sometimes I feel like I’m moving inch by inch along a journey of a thousand miles. But today I made some significant progress, and a milestone of sorts.

My earlier efforts were focused on duplicating the functionality of the Liron disk controller card (for Unidisk 3.5 and Smartport hard drives), and separately on the Disk II controller card for 5.25 inch drives. More recently I’ve been working on mirroring the functionality of the UDC disk controller, because it supports all of those types of drives as well as standard 3.5 inch drives, and it can automatically detect drive types. Today’s good news: when configured as a UDC, Yellowstone is now able to auto-detect, read, and write Unidisk, Smartport, and 5.25 inch drives! That’s basically everything the UDC offers except for 3.5 inch drive support, which is my next goal. It may sound like I’ve merely duplicated what I had before, but the UDC works quite differently from other disk controllers, and reaching this point means I’m getting closer to unlocking the full potential of a “universal” disk controller.

I’ve discovered some interesting things along the way. Many readers probably know that the Disk II controller card was Apple’s first disk controller, designed by WOZ and built entirely from simple off-the-shelf parts. Later Apple developed the IWM or “Integrated Wozniak Machine”, which did everything the Disk II controller could do, all in a single chip. But the IWM wasn’t just a replacement for the Disk II circuitry; it modified and extended it in a backwards-compatible way. The differences are subtle, but important. For example, if you write a byte to the Disk II controller while the disk is turned off, it has no effect. But if you write a byte to the IWM while the disk is turned off, it updates a configuration register that controls some interesting extra features.

I had been working towards creating an accurate IWM model, but what I discovered is that the code in the UDC’s ROM doesn’t really work with an IWM. It expects to be paired with some custom logic whose behavior is much closer to the original Disk II controller. It does strange-seeming things, like reading and writing from Smartport hard drives without ever asserting the drive’s enable signal. And it leaves a few other mysterious behaviors where I must guess at what’s intended. I’ve had to modify my Verilog design, breaking some of the IWM behaviors in order to match the UDC expectations. That makes me a little uneasy; I don’t really want to maintain two different designs. Fortunately the differences aren’t extensive.

3.5 inch drive support is the next step, but there’s so much to do beyond that. The real UDC card supports two independent disk connectors, but Yellowstone only has one. Some later versions of the UDC also support daisy-chaining drives, which I’d love to get working for Yellowstone too. Unfortunately there are UDC versions with Smartport support, and versions with daisy-chaining support, but none with both. Combining the two may be a major challenge.

After Yellowstone is functionally complete, there will still be plenty more work to do. I need to redesign the board to better isolate the FPGA from any 5V signals, and generally make it as robust and foolproof as possible. I need to decide what I’m doing about the required DB-19 female connectors, which are stupidly difficult to find, though I do have some. I need to revisit all that ROM packing stuff I described here recently, to see if I can’t squeeze everything into a more common FPGA with a lower cost. I probably need to build some kind of end-user reprogramming capability too, to allow for bug fixes or new features. I’m using a JTAG programmer and the Lattice development software, but that’s not a user-friendly solution. That could become a major project in its own right. And finally I need to design a self-test capability, or an external testing rig, that can be used to verify large numbers of boards (relatively speaking) after they’ve been assembled. At the rate I’m going, I’ll be busy for a long time!

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.

 
……One More Thing

Effective immediately I’m cutting the price of the Floppy Emu Model C by $10 and the Floppy Emu Deluxe Bundle by $20. I’ve been testing these new prices for a little while now as a temporary sale, and based on the response I’ve decided to make the new prices permanent. This puts the Model C at $99 and the Deluxe Bundle at $119. I hope this helps to get hardware into a few more hands of vintage Apple enthusiasts.

Thanks for everybody’s support and enthusiasm over the years that I’ve been doing this. Sometimes the road is bumpy, but it’s always a pleasure hearing from people about the ways they’ve put their BMOW hardware to use. I’m happy to have contributed something to this hobby and its amazing community.