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.

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.

As of today, the BMOW Floppy Emu disk emulator now offers two different firmware versions for Apple II users: a normal version and a Smartport daisy chain version. You’ll find them both in the Firmware Downloads section of the Floppy Emu project page. Most people should use the normal firmware version, and it’s the default for newly-purchased hardware. The Smartport daisy chain firmware version is only needed in uncommon situations when:

If in doubt, get the normal version. You can switch freely between versions as needed. There’s no harm in using the “wrong” version, but some details may not work as expected, and the normal version offers a higher level of ID-10T proof robustness. If you don’t care about the gory details, then just install the version you need, and have a nice day. But if you enjoy learning about low-level disk voodoo, read on. Here be dragons.

 
Why Two Firmware Versions?

Why are there two different firmware versions? Why not have one version, with some kind of user-selectable option for Smartport daisy-chaining? That would surely be more convenient, but it wouldn’t do the job that’s required here. The essential difference between these two firmware versions is the default power-up configuration of Floppy Emu’s CPLD chip, before the Emu’s on-board code has even begun to run. By the time that code could check a user option and decide how to change the configuration, the critical moment where the configuration is relevant would have already passed.

The difference is specific to a disk I/O signal named SELECT. With the normal firmware, SELECT is always configured as a CPLD input, and an external measurement will appear to show a floating voltage. But if using the Smartport daisy chain firmware, SELECT is initially configured as a pull-down: an output driving a logical zero value. It’s later reconfigured as an input, or not, depending on the Floppy Emu’s selected emulation mode. This is necessary in order to support detection of daisy-chained Smartport and Unidisk 3.5 devices, when other devices of the same type check for daisy-chaining at power-up. This scenario is fairly rare: it only happens when two intelligent Smartport devices are daisy-chained together, and Floppy Emu is the second device. That’s what conditions 1 and 2 above mean. When Floppy Emu is the sole Smartport device, or its selected emulation mode is 3.5 inch or 5.25 inch floppy rather than Smartport, then the normal firmware is the way to go.

 
The Tale of SELECT

What’s all this business with SELECT? Isn’t it a bad idea to dynamically reconfigure an input as an output? I agree it seems dubious, but that’s Apple’s design. I discussed the mechanism in more detail a few years ago here. In brief, SELECT is an input for dumb 3.5 inch floppy drives, used to select between the two sides of the disk. For 5.25 inch drives, the same pin is a 5 volt power connection. But for intelligent Smartport and Unidisk 3.5 drives, the SELECT pin is hardwired to ground inside the drive. The SELECT pin on the Unidisk 3.5’s rear daisy chain port is connected internally to an RS latch. The latch is cleared during power-up, but if SELECT ever goes high the latch will be permanently set. So in order to convince the Unidisk 3.5 that the next daisy-chained drive is another Unidisk 3.5 or similar intelligent Smartport device, SELECT must be held continuously low from the first moment of power-up. The BMOW Daisy Chainer uses the same technique to detect the selected emulation mode of the Floppy Emu that’s plugged into it.

To meet that requirement of “continuously low from the first moment of power-up”, the Floppy Emu CPLD’s default configuration must pull SELECT low, even before the code on Floppy Emu’s microcontroller has begun to run. But if a pulldown isn’t wanted at power-up, a different default CPLD configuration is needed. That’s why this requires two different firmware versions for these two different behaviors.

All this input/output direction switching for SELECT can be problematic. We can blame Apple for this. Floppy Emu includes an inline protection resistor between SELECT and the CPLD, to guard against possible signal contention if the computer tries to drive a signal on SELECT at the same time the Floppy Emu activates the SELECT pull-down for daisy chaining.

What happens if you use the normal firmware in a setup with two daisy-chained Unidisk 3.5’s or other Smartport devices? Nothing harmful, but the second Smartport device (which in this case is a Floppy Emu) won’t be recognized correctly. The first Unidisk 3.5 drive will think the Floppy Emu is some other type of drive, and won’t pass along the required I/O signals during Smartport activity. This is also exactly what happens with some other vendors’ Apple II disk emulators: they don’t pull down SELECT correctly, so they don’t support Smartport daisy-chaining. Maybe you never noticed. This little detail is one important piece of giving Floppy Emu maximum compatibility.

 
Microamps and Milliamps

So what happens if you use the Smartport daisy chain firmware in a setup where it’s not actually needed? Why not just always use that firmware? That’s actually exactly what all prior versions of the Floppy Emu firmware have done since 2019. Though I never used the term before, all prior firmware versions were essentially Smartport daisy chain versions, and it worked fine. But a recent analysis convinced me it’s better not to include the SELECT pulldown behavior of the Smartport daisy chain firmware if it’s not actually needed.

The issue is the current that’s present on SELECT when the pulldown is active but the computer is trying to drive the signal high. The Floppy Emu’s inline resistor limits the current, and this seems to be exactly how Apple intended things to work. The Apple IIgs and the (dumb) Apple 3.5 Drive both include an inline resistor on the SELECT output for the same reason. But it’s still not good practice, and it creates a burst of comparatively high current (compared to the other disk I/O signals) whenever it happens. This may create EM noise and minor signal integrity problems elsewhere. Over the long term it may also start to degrade the silicon structures in the CPLD’s input; a milder form of the same concern I previously described here. This SELECT pulldown current can happen by mistake, when the Floppy Emu is configured for Smartport emulation mode but is connected to a Disk II Controller Card or other controller that doesn’t support Smartport. Or it can happen briefly during normal use, either during power-up or when multiple drives of different types are daisy chained, each one using SELECT in a different way.

To be clear, there is no extra current present on SELECT when Floppy Emu’s emulation mode is configured as Smartport or Unidisk 3.5, and it’s daisy-chained to the rear of another Unidisk 3.5 or the BMOW Daisy Chainer. That’s exactly how the pull-down is intended to be used. Nor is there any extra current in typical scenarios where Floppy Emu is configured as Smartport or Unidisk 3.5 and plugged into the disk port of an Apple IIc or IIgs. No issues there.

I may be overly paranoid and this extra current may be just a nuisance or totally harmless. Experience from the past few years says it’s a minor issue at best, but nevertheless I want to eliminate it where I can. Because the SELECT pulldown is only needed in uncommon cases when two Smartport devices are daisy-chained, I feel better having the default firmware just disable the pulldown completely, to get the most robust possible behavior. Those few people who need the Smartport daisy-chaining support can use the alternative firmware version where the SELECT pulldown is enabled as needed. Everyone can be happy.

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.

 
Testing

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?

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 retrocomputing.stackexchange.com 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.