BMOW title
Floppy Emu banner

Archive for the 'Yellowstone' Category

Off to the Fab!

The Yellowstone 2.0 disk controller PCB has been sent to the fab. Now we wait. It took longer than I planned to finish it, first because I wasted a couple of days trying to shrink the board by 7 mm, then because I was obsessing over tiny layout tweaks. Now I can breathe a sigh of relief… except for the bad news. And the problem. And the other bad news.

Bad news #1 isn’t really a surprise. Thanks to the global IC shortage, the prices of components have increased. When I compare the IC prices from 2017’s Yellowstone 1.0 bill of materials to today’s prices, they’re up anywhere from 15 to 300 percent. Doh! I’m hoping this won’t affect the retail price too much, since the cost of materials is only one element of the total, along with cost of assembly, programming and testing, parts shipping, and general business costs like order fulfillment and customer support and other overhead.

The second problem is also cost-related. The twin DB-19 female adapters and cables for connecting the two disk drives are going to be more expensive than I’d like. The raw parts cost for a Yellowstone board with two DB-19F adapter cables is like 60 percent more than just the Yellowstone board alone! How can that be? Mechanical parts like connectors and cables just seem to be inexplicably expensive compared to most ICs except the FPGA. The worst offender is the DB-19 female, which isn’t manufactured anymore and is only available as new-old-stock from surplus suppliers.

As a result, I’m seriously considering selling Yellowstone in two versions: one that’s the board alone, and another that’s the board plus DB-19F adapter cables. With the board alone you can attach Floppy Emus, or Disk II drives, or internal Macintosh drives, or anything else with a ribbon cable and rectangular connector. But you’ll need DB-19F adapter cables if you want to connect drives like the Apple 3.5 or Unidisk.

Bad news #2 is my biggest concern now. The supply of the FPGA chip that I selected has shrunk dramatically in just a few weeks. I assume this is also due to the global IC shortage. It’s close to the point where I wouldn’t be able to manufacture any boards even if I wanted to. Only a few weeks ago, several different suppliers each had thousands of parts available, but as of today only a few hundred remain. I’m strongly considering buying them all right now, even though I don’t need them yet and the board design isn’t even finalized, just so I’ll have something on hand to do at least an initial run of manufacturing.

Read 2 comments and join the conversation 

Yellowstone 2.0 Layout and Route

It took longer than expected, but the PCB layout is finished for version 2.0 of the Yellowstone disk controller. Phew! There’s still a bit of cleanup work to be done before I send the board for manufacturing. Hopefully I can finish that off within the next few days. I think it’s getting close.

Quite a lot has changed from version 1.0. The board now has two disk ports instead of one, with some DIP switches to control how they’re used. A 32KB RAM is now paired with the FPGA, reducing the amount of internal block RAM that’s needed and hopefully (to be confirmed) enabling me to use a lower-end member of the FPGA family that’s cheaper and more widely available. Level shifters and open drain buffers are now present on all of the disk I/O signals. In normal use none of the FPGA’s pins will be directly connected to anything off-board, which should improve robustness. The 3.3V regulator is now rated for 800 mA instead of 300 mA. I’m not convinced this was really necessary, but it’s something many people suggested upgrading from the 1.0 design. All of the chips except the FPGA are now using SOIC packages with 1.27 mm pin spacing, to make soldering easier and reduce the chances of assembly problems. Version 1.0 mostly used TSOP packages with a much finer 0.55 mm pin spacing.

Too bad there are no 5V FPGAs anymore. Half the chips here are dedicated to level shifting, and could disappear if the FPGA used the same voltage as the disks and computer.

The board routing is improved too, although you can’t tell from looking at the image. The edge connector on Apple II peripheral cards only has one pin for each power supply voltage, including ground, so it’s important to make those PCB traces nice and wide and to minimize the number of vias between the supply and the load. Yellowstone version 1.0 did a poor job of this.

I added a very simple bus sense input that could be used to support batch testing. It’s just a voltage divider connected to the 12V supply. If the FPGA sees this input high, it can assume the card is installed in an Apple II. If it’s low, it can assume it’s on a test bench and alter its behavior accordingly. I’ll figure out the rest later.

I can’t resist looking into the future and observing that chips U1 through U7 could be used as-is for many purposes other than disk control. Those chips form a generic design of an FPGA plus 32K RAM with level shifters connected to the Apple II bus. Only chips U8 and U9 are really specific to being a disk controller, because they determine the direction and I/O voltage of the signals on the disk ports.

Parts availability may be a problem here. Most readers have probably heard about the global IC shortage that’s affecting everybody right now, and BMOW is no exception. The prices of many ICs have increased significantly, and some types of ICs have become difficult or impossible to find anywhere.

A question for PCB designers and assemblers: when a board like this one has dozens of passive components, how do you decide on a numbering scheme? Is it better to number them in order according to their physical location on the board, making them easier to locate quickly? So for example the column of resistors on the right could be numbered consecutively R1 through R11. Or is it better to number them so that components with the same values/types have consecutive numbers, regardless of where they are on the board? So for example R1 through R6 might be all the 10K resistors, then R7-R10 could be all the 6.8K resistors, and so on.

Read 9 comments and join the conversation 

Yellowstone Reprogramming and Testing

I’m working on the hardware design for version 2.0 of Yellowstone, my FPGA-based universal Apple II disk controller. Most of it is going well, but I’m facing two major challenges I’m unsure how to solve: how to support user reprogramming, and how to batch test newly-made boards. I’m feeling blocked by both of these important questions.

User Reprogramming

The board is based on an FPGA, which contains the disk controller logic design as well as 8 KB of synthetic ROM. There’s a JTAG header on the board which can be used to program the FPGA after assembly. But what happens after I’ve shipped the Yellowstone board to a customer, and then I fix a bug or add a new feature? Most people don’t have a JTAG programmer, so how will the customer install the new firmware?

In an ideal world, the Yellowstone board would have some kind of USB port or memory card slot for installing updates. But I’m reluctant to include additional hardware for the sole purpose of future firmware updates. It’s both a cost concern, and a “I really just want to finish this design” concern.

An alternative might be to implement reprogramming from within the Apple II itself, using a custom software program. But how, exactly? The Apple II bus isn’t connected to the JTAG header. Maybe I could create a connection with the addition of an extra buffer chip, but my enthusiasm for working on that idea is low. After nearly four years of development, I prefer to focus on getting the core functions of the card debugged and working, and call it done.

The solution I’m leaning towards is to simply avoid user reprogramming for all but the most advanced users. For people who own a JTAG programmer (or a Bus Pirate or Arduino with appropriate sketch loaded) and are familiar with the software for using it, they could still update the FPGA if needed, but for everyone else it would be a fixed-function device. The Daisy Chainer adapter that I developed for Floppy Emu faced the same issue surrounding updates and used the same non-solution, and it’s worked out fine. Unless I can think of another simple solution for reprogramming, I’ll probably go with this answer.


This is a complex board; probably the most complex I’ve ever designed. Let’s say I’ve just assembled 100 of them, or paid a manufacturer to assemble 100 for me: now what? How do I quickly and reliably test them to confirm they work? It’s unrealistic to put each one in my Apple IIe slot 6, connect a bunch of different disk drives, boot some disks, play Oregon Trail… it would take far too much time, and rapidly wear out my equipment. Nor could I expect a manufacturer to do that kind of test for me. It would be prohibitively expensive, if they’d be willing to do it at all.

Some kind of self-test capability would be great, but my options are limited. Without actually connecting something to the drive connectors, I couldn’t verify that they’re working. And unlike most of my other projects, Yellowstone doesn’t have any CPU or microcontroller that could be used to run self-test code. It’s just a big pile of logic circuits and memory that’s normally controlled by the Apple II.

What I should really do is create an external testing apparatus for the Yellowstone card: something the card plugs into, which then quickly exercises all the card’s hardware and flashes a green light if everything’s OK. That’s what I did with the pogo pin test board for testing the USB Wombat.

But here’s the problem: designing an external tester is a big project that needs a lot of time, and the very thought of it makes me collapse into a puddle on the floor whining like a two-year-old who needs his nap. I just don’t want to do it. I designed an external tester for the Wombat, and the effort took at least several weeks. A Yellowstone tester would be even more complex. I’ve simply run out of patience for further scope creep on this project, testing be damned.

So I’ve been bargaining with myself, trying to imagine what kind of limited testing I could do to get the best bang for the buck. What testing would catch the most problems or the most common types of problems, with the least amount of additional engineering work and the least time per test? How far could I get by confirming the FPGA programmed successfully, and doing a visual inspection of the assembled board, without further testing? Is it the difference between 99 percent and 99.99 percent reliability? What number should I be aiming for?

Read 15 comments and join the conversation 

Fixing Laser’s Bugs

Last week I wrote about some test results from Yellowstone, my FPGA-based universal Apple II disk controller based on the Laser UDC design. I described two especially worrisome problems: one with 5.25 inch disks on an Apple IIGS at “fast” CPU speed, and the other with 3.5 inch disks under GSOS. I think I’ve fixed both problems, or at least found work-arounds, but it’s raised a new concern. Both issues look like serious problems in the original Laser UDC ROM code, rather than anything related to my Yellowstone re-implementation. And if the UDC shipped with those bugs, I’m wondering how many other problems it may also have. I don’t want to build a new project on a shaky foundation.

GSOS and 3.5 Inch Disks

In last week’s Yellowstone tests, I discovered that 3.5 inch floppy drives weren’t working under GSOS. They caused an error during booting: Unidisk3.5 requires a driver. Install UniDisk3.5 driver on boot disk and re-boot system. A stock UDC card with the version 4.0 ROM was found to have the same problem. The strange thing was the error mentioning UniDisk3.5 when the drive wasn’t a Unidisk 3.5, but an Apple Disk 3.5. An actual UniDisk 3.5 worked fine. Installing the requested driver didn’t help: the same error still appeared.

After doing some poking, it seemed that the problem was related to the Device Information Block returned in response to a status call. There must be some critical DIB difference between the drives that work and the drives that generate an error. Because the UniDisk 3.5 is an intelligent device, DIB requests are handled by the drive itself. But the Apple Disk 3.5 is a dumb drive, and the Yellowstone firmware (ROM code) must handle DIB requests on its behalf. Presumably GSOS didn’t like something about the DIB response for the Apple Disk 3.5, resulting in that driver error message. I did some testing with various disk controllers and drives, and checked the type and subtype fields in the resulting DIB:

DISK CONTROLLER   DRIVE                          DIB TYPE/SUBTYPE 
IIgs built-in     Apple Disk 3.5                      01/C0
IIgs built-in     Unidisk 3.5 (real drive)            01/00
Yellowstone       Apple Disk 3.5                      01/00
Yellowstone       Unidisk 3.5 (Floppy Emu emulated)   02/20

The Yellowstone firmware, following the example of the UDC firmware, returned the same type/subtype for an Apple Disk 3.5 as the IIGS built-in disk controller does with a real Unidisk 3.5. That probably explains why the error message mentioned UniDisk3.5, but not why there was an error in the first place.

Changing the firmware to return 01/C0 instead of 01/00 changed the error message’s text to AppleDisk3.5, but didn’t help the underlying problem of the disk not working. My guess is GSOS sees the 01/00 or 01/C0 type IDs, and then based on that, it tries to make some extended status or control calls it expects those types of drives to support. But Yellowstone / UDC doesn’t handle those calls as expected, causing GSOS to complain about needing a driver. I’m not sure if Laser never tested the UDC with GSOS and 3.5 inch drives? Or maybe GSOS didn’t exist when the UDC was originally released?

My fix was to change Yellowstone’s type/subtype ID for the Apple Disk 3.5 to 02/00, which should indicate a general removable Smartport hard disk. This eliminated the errors under GSOS, and everything seems to work OK. I’m unsure if this change may create any new problems, however. A floppy disk isn’t the same thing as a removable hard disk, but maybe it doesn’t matter as long as the firmware knows how to read and write the disk. I’ll keep testing.

IIGS Fast Mode and 5.25 Inch Disks

After a closer look at many 5.25 inch disks, I realized that all DOS-based 5.25 inch disks failed to boot properly on a IIGS with the CPU speed set to “fast”. This included the DOS 3.3 System Master disk, Bank Street Writer, Donkey Kong, Choplifter, and many others. But 5.25 inch disks based on ProDOS all seemed OK, including the ProDOS System disk and others like Shrink It. Very strange.

I examined the disk I/O signals with a logic analyzer. For the DOS-based disks, after the initial drive recalibration and loading of sector 0, it looked like all the drive operations were happening about 2.5x too fast. This is roughly the speed difference between code running on a IIGS in fast mode versus normal mode. So for reasons unknown, the disk code wasn’t being automatically slowed to normal 1 MHz speeds as is required for 5.25 inch disk compatibility.

The Yellowstone firmware slows the IIGS to 1 MHz whenever one of Yellowstone’s disk API functions is called, and restores it to the previous speed when the function exits. For ProDOS-based software, I think all the disk I/O happens through the API, so the IIGS speed is adjusted as needed and everything works.

But for DOS-based software, only the loading of sector 0 is directly handled by Yellowstone firmware. After that, DOS’s RWTS routines bypass the Yellowstone firmware and directly control 5.25 inch drives through memory-mapped I/O registers. If the RWTS code runs at “fast” speed, then you get the behavior I observed, and disks won’t boot properly.

This explains why Yellowstone wouldn’t work for DOS-based 5.25 inch disks, but then how do other disk controller cards work? Why doesn’t a Disk II controller card have the same problem on a IIGS at fast speed?

Motor-On Detector Voodoo

Bits 0-3 at address $C036 on the IIGS are used to enable motor-on detection for a Disk II controller card in slot 4 through 7. It’s a nifty feature. Each bit enables motor-on detection for a different slot. When enabled, the IIGS attempts to keep track of the motor-on state for a Disk II controller card in that slot, by watching for memory accesses to $C0x9 (on) and $C0x8 (off), where ‘x’ depends on the slot number. When motor-on detection is enabled and the motor is on, the IIGS is automatically slowed to 1 MHz to ensure that disk-related code works as expected. Thanks to the folks at for clearing this up.

Now why does motor-on detection work for a real Disk II controller card, but not for Yellowstone? I’m not certain, but I suspect the IIGS firmware scans the installed peripheral cards during boot, and checks each card’s ROM signature to see if it’s a Disk II controller. If it is, the IIGS enables motor-on detection for that slot. But Yellowstone has a different ROM with a different signature, so it doesn’t get detected, and motor-on detection remains disabled.

The solution is for Yellowstone’s initialization code to manually enable motor-on detection, but this is trickier than it sounds, and it appears Laser themselves screwed this up. I’m working off UDC ROM version 2.3, which makes no attempt to enable motor-on detection. Patching it won’t be simple, because it’s a massive block of absolute address references with almost no free bytes where a patch could be inserted. UDC ROM version 4.0 was a major rewrite from v2.3, and it enables motor-on detection for ALL of slots 4-7, regardless of which slot the card is actually installed in. This is wrong, and potentially interferes with the operation of other cards in those slots that might use $C0x9 and $C0x8 for unrelated purposes. For now I’ve implemented a temporary “fix” that confirms motor-on detection will solve the problem with DOS-based disks, but my fix breaks other things. I’m still searching for a better solution.

One interesting side-effect of this motor-on detection mechanism is that IIGS disk controllers in slots 4-7 work differently than slots in 1-3. There is no motor-on detection for slots 1-3, so if you install a Disk II controller there, or any other disk controller that relies on motor-on detection, it won’t work for DOS-based 5.25 inch disks when the IIGS speed is set to fast. You can test this yourself. Install a Disk II controller in slot 4, and enable the card in the GS Control Panel. Try booting a DOS 3.3 disk and confirm it works. Now move the Disk II controller to slot 2 and try again, and watch the drive loop endlessly between tracks 0 and 2.

Read 7 comments and join the conversation 

Testing Yellowstone

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?

Read 3 comments and join the conversation 

Yellowstone 3.5 Inch Drive Support!

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.

Read 11 comments and join the conversation 

Older Posts »