BMOW title
Floppy Emu banner

Yellowstone Testing With Real Drives

I’m still testing the latest prototype of Yellowstone, my FPGA-based universal disk controller for Apple II computers. After a great deal of poking and prodding, the disk controller is now mostly working with all of the Floppy Emu’s disk emulation modes and with a variety of real Apple II drives. Hooray! But there’s still so much more work to do.

This is version 2.0 of Yellowstone, and it hasn’t exactly been a smooth experience getting it working. First I discovered a layout blunder, where I ran a signal trace right through a power via. After patching that with a razor and some wire, I struggled with mysterious signal glitching in a different section of the board. Some minor changes to the FPGA design made the glitching disappear, but I’m not convinced it won’t return later. Then I discovered a design flaw which means certain types of drives will create a short circuit when plugged into the card’s second drive connector. I’ll fix that in the next revision. Eventually I got the Yellowstone card working with a Floppy Emu, but real drives wouldn’t cooperate. That ultimately proved to be an issue with the width of the read pulses from the drives – they were too narrow to detect reliably. I adjusted the FPGA design to compensate, and now I’m finally in business.

Current status: I’ve had success with an Apple IIe plus Yellowstone booting from a Unidisk 3.5, an Apple 3.5 drive, an Apple Disk 5.25, and a Floppy Emu in its 3.5, 5.25, Unidisk 3.5, and Smartport hard disk emulation modes. The Disk II and Duo Disk should also work, though I haven’t yet tried them. But this is just the very beginning of testing, with a single Yellowstone card in slot 6 and a single disk drive. I haven’t tried writing to the disk, or formatting a disk, or daisy-chaining drives, or using the second drive connector, or anything in the Apple IIGS.

I tried connecting a Macintosh floppy drive pulled from a Quadra 605, and the Apple IIe wouldn’t even turn on. I think I shorted the power supply somehow. This was supposed to work. I’ll look at it more closely later.

Something is still funky with the Apple 3.5 Drive support. Two of the 3.5 inch floppies I tried will boot reliably, but one won’t. But the same three floppies work fine in the Unidisk 3.5. I haven’t yet tried to troubleshoot this one.

It also appears that the behavior changes depending on whether my JTAG programmer is connected to the card, and sometimes it doesn’t work if the programmer is connected. That’s concerning. In the past, I saw something similar with earlier prototypes. I’m not sure if the programmer is holding the FPGA in a reset state, or if it’s an analog problem with the card that’s affected by the presence of the programmer. Another mystery to investigate.

The Apple 3.5 drive and Apple 5.25 drive both sound noticeably different when used with Yellowstone as compared to an Apple standard disk controller. While I haven’t yet determined why, I think this is benign and is due to differences in exactly when and how the disk controller moves the drive head. But when you’re accustomed to disk drives having a certain characteristic sound during I/O, it’s a little disconcerting. The Apple 3.5 drive sounds frenetic, and the 5.25 drive’s familiar buzz-buzz-buzz startup noise is completely different. This latter one bothers me enough that I may try to change it, even if it’s not causing any problems.


It’s hard to believe, but the Yellowstone project will celebrate its fourth birthday this summer. I have to admit I’ve taken on a bigger challenge than was probably wise, and I’m struggling. For me, this stuff is hard – much harder than the Floppy Emu’s development. It’s difficult to maintain motivation when I keep running into one major problem after another, with the goal of “finished” always far away. And the domain of possible problems is huge. One day I’m troubleshooting some software incompatibility with GS/OS, the next day I need to become an expert in FPGA in-system programming, and the day after I’m chasing signal integrity problems in the analog domain. It’s tiring.

There’s still lots to do. All the problems I mentioned above must be examined and fixed. Then there’s a whopping huge amount of testing needed, with a dizzying number of permutations of computers, cards, slots, drives, daisy chain configurations, boot priorities, and software disks. That’s practically guaranteed to turn up more thorny problems that will be difficult to solve. And then I still need to build solutions for in-system reprogramming of the FPGA by end users, and for fast and thorough automated testing during manufacturing. I have some plans for how to handle those, but haven’t yet started any work.

I’m hopeful that while the Yellowstone project isn’t yet “almost done”, it’s at least close to the point where the finish line is visible. I really want to wrap this up and get it out the door.

Read 3 comments and join the conversation 

3 Comments so far

  1. Nick - June 8th, 2021 4:32 pm

    The joys of prototyping. I’m by far from a coder, and only know hardware/circuit basics. But there have been several software projects where I’ve hit similar road blocks. As much as you want to power through and finish it, sometimes it helps to step back and work on something else. When you come back to the original project you have a fresh set of eyes that can lead to breakthroughs. Either way, you’ll get there. Your projects never fail to disappoint.

  2. Steve - June 8th, 2021 5:12 pm

    Thanks. At least one mystery seems to be resolved, I hope: the problem where sometimes things didn’t work if the JTAG programmer was connected. I think the programmer was providing a tiny amount of power to the Yellowstone card even when the computer was turned off, which was enough to retain the contents of the card’s SRAM. One of the things stored in SRAM is a warm-start marker that’s used to tell if the card is performing a cold boot or just a reset. So from a cold boot, the Yellowstone card thought it was doing a warm reset and it skipped a bunch of initialization stuff that should not have been skipped.

    I modified the FPGA logic so that for one specific SRAM address where the warm-start marker is stored, it doesn’t enable the SRAM, but instead reads or writes an internal memory register in the FPGA. I also modified the logic to clear this internal memory register whenever it sees the system reset signal. This effectively defeats the whole warm-start mechanism, which I’m unsure was ever really useful or a good idea.

  3. Keith - June 14th, 2021 1:45 am


    Here here is latest tool. Thanks to Adrian digital basement. The video on Adrian’s site was VIC 20 specific. But the Romulator is not limited to commodore computer.

    Newest tool for 6502. Might be able to help with your rom/ram space testing. Yes it uses a Raspberry Pi. And yes another device. But this would allow for memory inspection. And troubleshooting further the most system would allow for.

    When this becomes available again. Only 30.00. unless it’s increased.

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