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?