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 disk emulation details may not work as expected, and the normal version offers a higher level of protection against misconfigured disk drives. 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.

 
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?