Here’s a brief follow-up about the classic Macintosh game Dark Castle, which I mentioned a few weeks ago in connection with some possible disk emulation bugs. This game originally shipped on two 400K floppy disks. At the intro screen shown above, the player is given a choice of doors, and some of the doors will ask the player to insert disk 2. But when loading the 400K game disk with a Floppy Emu disk emulator, the disk swapping doesn’t work. Disk 1 doesn’t get ejected, and if disk 2 is inserted, it will be ignored. A few weeks ago I speculated that this may be caused by a Floppy Emu bug, but I was wrong.

After a bit of research, I found that the problem is just another example of Games That Only Work In Drive 1. This is pretty common in the Apple II world, but not so common for Macintosh games. When Dark Castle tries to eject disk 1, it specifically tells drive 1 (the internal drive) to eject, regardless of which drive contains the disk. Then it checks the same drive for disk 2. Since Floppy Emu is normally connected to classic Macs as the external drive (drive 2), this doesn’t work. To confirm this behavior, I disassembled an old Mac and connected a Floppy Emu internally, in place of the built-in floppy drive. With this configuration, Dark Castle 400K worked fine.

BMOW’s Vintage Apple Software Collection SD Card has an 800K version of Dark Castle, where the contents of both 400K disks have been copied onto a single 800K disk. This avoids the need for disk swapping, so the game can be played normally from a Floppy Emu or other external floppy drive, but it requires a Macintosh model that’s compatible with 800K drives. The oldest Macintosh models are only compatible with 400K drives. For those models, playing Dark Castle will require connecting the Floppy Emu internally as I did, or copying the disk images from the Floppy Emu onto real 400K disk media for use in the internal floppy drive.

The Yellowstone Smartport problems that I discussed last week should all be resolved now. Small fixes to big problems. As usual the main challenge was determining exactly what the problem was and how to reproduce it. After that, the fix hopefully becomes clear. For those keeping score at home, here’s a recap:

3.5 Inch Disk Activity Caused Accidental Smartport Resets and Enables – This was the original topic of last week’s post. I’d somehow failed to consider what would happen if a 3.5 inch drive and an intelligent Smartport drive were attached on parallel drive connectors with shared I/O signals. Due to the complexities of Apple’s scheme for enabling different types of drives, with this drive setup it’s possible for normal 3.5 inch disk activity to also accidentally trigger a Smartport reset or to enable a Smartport drive. It turned out that Yellowstone was almost working despite this, which is why I hadn’t noticed any problems in my earlier tests. But once I knew what to look for, I was able to see evidence of problems and accidental resets during particular patterns of disk access.

The best solution to this problem would probably be eliminating parallel drive connectors with shared I/O signals, and using a single serial daisy-chain of drives instead, like Apple does. But that comes with its own set of limitations, and at this point Yellowstone is pretty well married to the parallel connectors idea.

My solution was to review the Yellowstone firmware, looking for specific places where 3.5 inch drive activity might cause accidental Smartport resets or enables. In theory there could be many places where it happens, but thanks to some very lucky coincidences, it’s actually quite rare. I only found one instance where an accidental reset would occur, and I was able to eliminate it by modifying the way Yellowstone accesses the internal registers of 3.5 inch drives. I wasn’t able to eliminate some places where accidental enables would occur, but after carefully reviewing everything, I concluded they were harmless.

 
Smartport Writes Caused Strange Behavior or Crashes – This took a very long time to isolate, because it displayed all sorts of odd behavior that was slightly different under GS/OS, ProDOS, and BASIC. Eventually I discovered that saving a BASIC file to a Smartport disk would outright crash 100 percent of the time, which made it easier to track down the issue. Thanks to revision control, I was able to dig back through weeks of prior changes and find one change from mid-July that subtly broke Smartport writes.

Yellowstone has a 32K SRAM, of which only 2K is used, and back in July I made some small changes to enable access to the remaining 30K for debugging purposes. While doing that, I confused two variables with similar names, with the surprising result that one byte of RAM would consistently be read incorrectly. This byte was normally only used for Smartport write buffering. Depending on what data was written to the Smartport disk, this may or may not have caused any immediate and obvious problems. Instead it caused subtle data corruption.

 
Unexplained Cycles of Repeatedly Resetting and Reinitializing the Smartport – Even after eliminating accidental Smartport resets caused by normal 3.5 inch disk activity, another similar problem remained. Very often I would see cycles where the Smartport was reset and reinitialized 10+ times, when using a Smartport drive in a mixed system along with other drive types. Unlike the original problem that began last week’s investigations, the logic analyzer showed these were genuine Smartport resets and not some accidental signal glitch.

The difficulty with this problem was finding a concise and coherent description of it. At first I thought it was a GS/OS problem, since I couldn’t initially reproduce it under ProDOS. Then I thought maybe it actually was a signal glitch, but of a different kind than I’d seen earlier. I had a theory it was related to earlier changes I’d made to the status handler for 3.5 inch disks. All of this was wrong.

After lots more testing, I was able to restate the problem description as this: after any 3.5 inch read or write operation, a Smartport reset and reinitialize would occur before the next Smartport communication. It didn’t seem to be something that was happening because of an error, but rather it looked like some state information was causing it to intentionally perform a reset and reinitialize.

Digging through the UDC ROM on which Yellowstone is based, I eventually found some code doing exactly that. If the most recently accessed drive was not a Smartport drive, then it would reset and reinitialize all the Smartport drives before the next Smartport communication. I don’t know why, but I’m guessing it may have been a flawed attempt to resolve the same issue I ran into with accidental Smartport resets and enables. Fixing accidental resets with intentional resets doesn’t seem like much of a fix to me. Since I already solved the accidental reset problem another way, I simply removed this bit of code, and the problem disappeared.

I’m hoping this is the end of mysterious Smartport problems, at least for a while. Now, where was I?

Whoops! I’ve discovered a basic flaw with the Yellowstone disk controller design: when an intelligent Smartport drive is connected in parallel with a 3.5 inch or 5.25 inch drive, the Smartport drive may be inadvertently enabled or reset as a side-effect of 3.5/5.25 inch disk activity. This isn’t just a mistake in my circuit, but a fundamental consequence of the way these drives work. I don’t know how I never realized it before. Just when I thought that Yellowstone development was nearly finished, here’s one last challenge.

This probably explains why there aren’t other Apple II drive controller cards that support intelligent Smartport drives and that have two parallel disk connectors, except for the long version of the UDC. It may also explain why Smartport support was dropped when the long UDC was redesigned into the short version.

 
Drive Enable Signals

When multiple drives are connected to a single controller, most of the I/O signals are shared between all of them. For Yellowstone and most other drive controllers that I’m familiar with, the common I/Os include the four PHASE control signals as well as all the read/write signals. Avoiding confusion and collisions on the shared signal lines requires a method of enabling one specific drive at a time. For 3.5 inch and 5.25 inch drives, simple /ENABLE and /EN3.5 signals are used to enable the desired drive. This works fine whether the drives are connected in series as a daisy-chain, or if they’re connected in parallel as Yellowstone does it.

But intelligent Smartport drives work differently. The don’t have normal /ENABLE signals. Instead, they’re enabled when PHASE1 and PHASE3 are high and PHASE2 is low. They’re reset when PHASE1 and 3 are low and PHASE0 and 2 are high. Here’s the relevant table from the Apple IIgs firmware reference:

But 3.5 and 5.25 inch drives use the PHASE signals for other purposes, not for enabling, which creates a problem. For 5.25 inch drives, the PHASE signals directly control a stepper motor. For 3.5 inch drives, the PHASE signals select one of sixteen drive registers. If normal disk activity with one of these drives just happens to involve a PHASE combination that resets or enables an intelligent Smartport drive on Yellowstone’s other drive connector, major problems could occur.

So why doesn’t this problem also appear with Apple-branded drive controllers or with the built-in drive controller of the Apple IIgs? The other drive controllers either don’t support this combination of drive types, or else they use daisy-chaining. With daisy-chaining, there’s an opportunity for the earlier drives in the chain to modify the PHASE signals that are passed through to later drives, and that’s exactly why Apple requires daisy-chained drives to be connected in a specific order. 3.5 inch drives must appear before Smartport drives, because when a 3.5 inch drive is enabled, it forces low all the PHASE signals for later drives. This prevents any daisy-chained Smartport drives from being unintentionally enabled or reset.

 
A Hardware Fix

A proper fix for this problem would require separating some of the common PHASE signals, so there are independent signals for drive connector 1 and connector 2. Having independent versions of PHASE0 and PHASE1 should suffice, since forcing both of these low would be enough to prevent Smartport enables and resets on a specific drive connector. In theory, if the controller knows that it’s communicating with a 3.5 inch or 5.25 inch drive at connector A, it could force low PHASE0 and PHASE1 at connector B.

In practice this wouldn’t be easy to do now. There aren’t any free pins on the output buffer chips where new PHASE signals could be added, so I’d need to add an additional chip in a section of the board where the trace routing is already very crowded. I’d need to route the new traces, and find new FPGA pins, when I’m already running up against the limits of a 2-layer PCB and my journeyman layout skills, not to mention my dwindling patience.

Even if the necessary hardware were in place, the software might also be tricky. I need to think about it more, but the drive connector number where a drive is attached may not always be the same as the logical drive number. For example, a DuoDisk might have drive 1 and drive 2, but the whole DuoDisk unit is still attached to drive connector 1. This could make it more difficult to know which disk connector’s PHASE signals should be altered.

 
Maybe… It’s Actually OK?

You’re probably wondering how this obvious of a problem was never discovered before. It’s true, I’ve tested intelligent Smartport drives on Yellowstone side-by-side with other drives many times, and never experienced an obvious problem related to this. It wasn’t until earlier today that I happened to notice that a Floppy Emu in Unidisk 3.5 emulation mode (a type of Smartport mode) underwent 10 or more unexpected resets while booting GS/OS from a 3.5 inch drive. Even then, it still worked OK. Miraculously, it looks like the problematic PHASE combinations rarely or never occur in real life.

First let’s look at 5.25 inch drives, where the PHASE lines directly control a stepper motor. It would never make sense for a 5.25 inch drive to energize PHASE0 and PHASE2 at the same time, or PHASE1 and PHASE3, because they would pull the motor in opposite directions and cancel each other out. Yellowstone’s 5.25 inch drive control logic never does this. Since the Smartport enable and reset PHASE combinations both require opposite PHASE pairs to be simultaneously high, these combinations can never happen during 5.25 inch disk activity.

Next let’s look at how 3.5 inch drive activity might trigger a Smartport enable. This would require PHASE1 and PHASE3 high and PHASE2 low. But for 3.5 inch drives, PHASE3 is almost always low, meaning this is very unlikely to happen. PHASE3 only goes very briefly high when the computer writes to a drive register. Following this rabbit hole further down, the only valid combination of 3.5 inch drive register number and value that could trigger an unwanted Smartport enable is writing 0 to the MOTOR_ON register. But what happens then? The Smartport drive will think it’s enabled, and start listening for a command, but won’t see one. Then an instant later when the MOTOR_ON write is completed, the Smartport drive will become disabled again without ever doing anything. This shouldn’t cause any problems for either drive.

The final case to consider is 3.5 inch drive activity that might trigger a Smartport reset. This will occur if PHASE1 and 3 are low and PHASE0 and 2 are high. Digging through the 3.5 inch drive register numbers, these correspond to a pair of registers related to SuperDrive / MFM disk operation – registers that Yellowstone never uses. This PHASE combination could also theoretically occur for some register writes, but in practice none of the problematic register/value combinations are ever used.

As far as I can tell, the only way an unwanted Smartport reset could occur for Yellowstone is when a 3.5 inch drive’s PHASE0, PHASE1, and PHASE2 are transitioning from one set of values to another (remember that PHASE3 is always low except for a register write strobe). The PHASE signals change one at a time under CPU control, so it’s possible they might briefly land on the problematic combination even if the CPU isn’t intentionally aiming for it. This suggests that Floppy Emu’s Smartport-based emulation modes could check the amount of time that the PHASE signals are in the combination for a reset, and ignore it if it’s below a certain threshold. A real Smartport reset lasts about 80 ms, which is much longer than most other disk I/O signal activity. But real Smartport devices like the Unidisk 3.5 can’t be modified – they will either work with Yellowstone or they won’t.

 
Next Steps

Ideally this problem should be solved through hardware, but I really don’t want to reopen that box and start major new changes to the Yellowstone PCB. It would set back my efforts by weeks, or maybe months, and I don’t have the appetite for it.

It seems like poor practice to rely on a software-driven “it works anyway” argument, but… it does seem to work. Obviously I’ll need to test this a lot more. But if the problem never occurs in the real world of Apple drives and Yellowstone’s drive control firmware, then I won’t be motivated to redesign the hardware just to earn a merit badge in thoroughness.

Yellowstone PCB version 2.2 is ready to be sent for fabrication. This is the fourth and hopefully finally PCB version, coming after 1.0, 2.0, and 2.1. But I also thought 2.1 would be the final version, so my powers of prediction are questionable. Here’s what’s new in v2.2:

• Manual -12V Supply Control – I’ve struggled for a while over how to handle the -12V supply on pin 9, which is required for some drives, ignored by others, and causes problems for few. The -12V supply is now enabled by a pair of DIP switches, one for each drive, so the choice is left up to the user. In 99 percent of cases -12V should be ON and the user should never need to touch it. I’ve also added a PTC resettable fuse to each -12V supply connection, which will limit the current to about 30 mA if there’s a misconfiguration.
• /EN3.5 for Drive 2 – The previous version didn’t provide the /EN3.5 signal to Drive 2, since I didn’t think it was needed. That pin was always low (asserted), making 3.5 drives think they were selected, and other types of drives ignore the signal. This worked OK, but it confused the Apple 3.5 Drive A9M0106 into thinking it was connected to a Macintosh, causing it to disable the manual eject button. Version 2.2 resolves this.
• Return of the Disk II Mode Switch – Yellowstone can optionally behave as a vanilla Disk II Controller Card, for maximum compatibility with copy-protected software. PCB version 2.0 enabled this mode with a switch, version 2.1 eliminated the switch in favor of a keyboard enable method, version 2.2 supports both the switch and the keyboard enable.
• Recovery Programming Enable – Version 2.1 supported recovery mode, a method for in-system programming of the FPGA even if it was misprogrammed or erased. Version 2.2 moves the recovery mode enable from a jumper to a DIP switch, since I was already adding a DIP4 package for the other items just mentioned.
• External Programmer Recovery Mode – A Schottky diode was added between the FPGA’s /SPI.CS pin and Yellowstone’s +12V supply. Normally this diode is reverse biased and does nothing, but the forthcoming tester board will be able to dynamically change the +12V supply to 0. This will provide a second way to enable recovery programming mode during manufacturing of Yellowstone boards, avoiding the need to touch the DIP switches and the potential for setting or leaving the switches in the wrong positions.

 
Tester Board with Blue Pill Brains

I’ve continued sketching out plans for the tester board, as initially described in my previous post. I’ve decided to build the tester around an STM32 Blue Pill, not because the Blue Pill is the absolute best tool for the job, but because it’s an adequate tool and also a helpful gateway to learning more about STM32 development.

The tester board will need a large number of I/Os. After a few hours of sketching, I think a microcontroller with 32 GPIOs will be enough, combined with a pile of port expander hardware. Not coincidentally, 32 GPIOs is exactly the number provided by the Blue Pill. If I get partway through the tester board design and discover that I need an extra I/O pin or two, it could be awkward. It looks like the two serial debug pins can be repurposed as GPIO if you’re not using them, as well as the BOOT1 pin, so it could possibly stretch as far as 35 GPIOs.

The basic design is this: Eight microcontroller pins are used for output, and are connected to four ‘373 transparent latches, providing a total of 32 controllable outputs. Eight pins are used for input, and are connected to four ‘244 buffers, providing a total of 32 inputs. Eight pins are used for bidirectional data bus communication, and the final eight pins are SPI and control signals for the buffers and latches.

During the course of testing, some inputs may also need to be pulled low. A ‘156 decoder will be used for this. The ‘156 can pull low any one of its eight outputs, using a three-bit selection input and an enable input.

One half of a second ‘156 decoder will be used to enable the desired input buffer from among the four possible buffers. Since a buffer is always enabled, this only requires two bits for the selection input, instead of four individual enable signals. This cuts down the number of control signals required from the microcontroller.

The design and programming of the Yellowstone tester board will be a significant engineering challenge in its own right. The proposed approach will require the STM32 Blue Pill mounted on a board with ten other support chips, three connectors, and close to 100 signals. Writing the code to program the FPGA and run/analyze the test vectors will be interesting. Kudos to people who design test fixtures for a living – this stuff isn’t glamorous, but it’s important to get right.

 
One More Problem – GS/OS and Drive 2

Yellowstone still has many smaller bugs and issues, but as far as I know there’s only one remaining major problem. It’s not even a Yellowstone problem per se, but it affects Yellowstone negatively. The issue is that GS/OS will not boot from Drive 2. It starts to boot, but then early in the boot process it unexpectedly tries to switch to Drive 1, and fails with the error “Unable to load START.GS.OS file”. As far as I can tell, this is a software limitation with GS/OS and not anything that Yellowstone is doing wrong. It shows the same behavior if GS/OS is loading from a 3.5 inch drive or from a Smartport hard disk.

Most other 3.5 inch and Smartport disk controllers will not even try to boot from Drive 2, which may explain why this GS/OS limitation isn’t well-known.

This behavior is similar to some 5.25 inch disk software that refuses to boot from Drive 2, even though there’s no technical reason for it. Such software is written with the assumption that the disk is in Drive 1, and fails if that’s not true. Bad programmer, no biscuit!

You may wonder why this is important. Can’t people just boot GS/OS from Drive 1? Yes they can, but that raises a new problem.

People who run GS/OS are probably booting it from some type of hard drive. If they’re using a Yellowstone card, that means a Smartport hard drive like Floppy Emu’s Smartport HD mode. But occasionally people will want to boot from a 3.5 inch or 5.25 inch disk instead, and they won’t want to unplug and reconnect drives in order to do this. Ideally they could connect a 3.5 or 5.25 inch drive to Yellowstone’s port 1, and a Smartport hard drive to port 2. Since D1 has boot priority, the computer would boot from D1 if there’s a disk there, otherwise it would fall back to booting GS/OS from D2. But since GS/OS won’t boot from D2, this setup isn’t possible.

I’m not sure there’s any great solution to this problem. A second Yellowstone card could do the job, but that’s not ideal. Possibly Yellowstone could show some virtual slot behavior, and act like two cards in different slots. But given my limited understanding of the UDC ROM code on which it’s based, and its overall brittleness and difficulty of making changes, this probably isn’t feasible.

The best idea I’ve come up with is logically swapping the drives, while leaving the physical connections unchanged. Users can attach a Smartport hard disk with GS/OS to Yellowstone’s port 1, and a 3.5 or 5.25 inch drive to port 2, and the computer will always boot from GS/OS on D1. But if a keyboard key is pressed during power-up, drives 1 and 2 will be logically swapped. The 3.5 or 5.25 inch drive on port 2 will behave as D1, and the computer will boot from a disk in that drive. It may be slightly confusing, but I think it will work and will provide maximum flexibility.

With Yellowstone hardware development hopefully approaching completion, I’ve started thinking more about the design for an automated tester. As long as I’m hand-assembling one board at a time, I can throw it in my Apple IIe and try exercising some disk drives to confirm everything’s working, but that won’t scale up to dozens or hundreds of boards. I need some kind of testing device where I can plug in a newly-assembled Yellowstone card, and have it power the card, program the FPGA, test all the I/Os, and report success or failure – all with the push of a single button.

This will be a custom-made tester board with a 50 pin edge connector socket, along with a pair of 10 x 2 pin rectangular connectors for disk cables. The new Yellowstone card will be inserted into the edge connector socket, and two ribbon cables will connect the card’s disk connectors to the tester board, providing full access to all the inputs and outputs of the Yellowstone card.

 
Microcontroller Brains

The tester board will be powered by a microcontroller, so I can write test routines in regular C code: set the inputs to a particular state, confirm the outputs are as expected, repeat a zillion times for all the different test cases. But what microcontroller to use, and how to incorporate it?

Since the tester board is essentially a one-off and I’ll only ever build two or three of them, there’s no reason to incorporate a bare microcontroller onto the board. Instead I plan to use a pre-made microcontroller module with DIP pins, like an Arduino or Teensy or STM32 “blue pill”, and plug it into a socket on the tester board. That way all the brains will be pre-made, and the tester board will only need to contain the necessary connectors, control buttons, LCD, and other support components.

Ideally I’d also like the tester board to include an SD card socket, for loading data like the bit file for FPGA programming, the expected value of Yellowstone ROM locations, and maybe even the set of test vectors. While some or all of this could probably be compiled directly into the microcontroller program, it will be easier to provide updates as files on an SD card. This is especially true if the test board is stored and used at some third-party PCB assembly facility where they might not have the tools or time to easily flash a new microcontroller program. The SD card socket could be part of the pre-made microcontroller module, or it could be something I build into the test board.

 
So Many Pins

The biggest challenge here is the number of I/O pins involved in testing. At the 50 pin card edge connector, there are 32 pins that must be tested (the other 18 aren’t used). Each of the 10 x 2 disk connectors has another 16 pins that require testing. Then there must also be about a dozen more pins for things like control buttons, the LCD display, and enable signals for I/O buffers on the test board. All together, I’m looking at about 70-80 I/Os, which is a lot!

Although there are a few microcontroller modules with 70-80 I/Os, I think a better path may be to use port expanders or shift registers with a smaller microcontroller. The sweet spot seems to be around 32-40 I/Os, and there are many microcontroller module options in this range. But some care will be required when deciding how to map I/O signals to the port expanders. It won’t be possible to change all the I/Os simultaneously, and some I/Os may briefly adopt wrong values while new values are loaded. I’ll need to make sure that this won’t cause any problems for Yellowstone, and that any critical signals are provided directly from the microcontroller if they must be glitchless.

 
The Paradox of Choice

Some leading candidates here would be the STM32 blue pill or black pill, or a Teensy. The Teensy 3.5 in particular has the advantages of 5V-tolerant inputs and a built-in SD card socket, as well as 40 GPIOs. The blue and black pills are cheap, have 32 GPIOs, and have an enthusiastic support community, but they don’t have an SD socket or 5V-tolerant I/O.

But there’s a secondary goal for this tester board, and that’s to get familiar with a modern 32-bit microcontroller I might someday incorporate into a future project. I could definitely see this happening with the blue or black pill, since STM32 is a popular platform, and it wouldn’t be difficult to incorporate another member of the STM32 family directly into a new BMOW gizmo. But the Teensy is based on a Freescale microcontroller that’s much less well-known. While it’s well-supported on a Teensy board and inside the Teensy development environment, my sense is that I’d be swimming upstream if I ever tried to incorporate a Freescale MK64FX512 directly into a future BMOW creation.

Honorable mention goes to the Atmel (now Microchip) ATSAMD51, included in some microcontroller modules like Adafruit’s Metro M4 Express and Grand Central M4 Express. These have the advantage of using the same development tools I’m already familiar with from doing 8-bit AVR work, and in fact I already have a Metro M4 Feat. But there doesn’t seem to be a big community around ATSAMD51 boards outside of these Adafruit examples. Adafruit says their Arduino board support package has “lots of stuff working” but they are primarily targeting CircuitPython.

For simplicity’s sake, I will probably be programming the tester board’s microcontroller with the Arduino IDE. Even though I sometimes dismiss Arduino as being for “noobs”, I don’t really need access to any fancy hardware features here. I just need a lot of I/O pins, a generous amount of RAM and ROM, and a decent clock speed. The last time I experimented with full C/C++ ARM development environments, I got so bogged down in installing and configuring IAR / Keil / CooCox / YAGARTO / Crossworks that it was no fun at all.

I’m leaning towards STM32 here, because I think it would be the most interesting and useful to me in the long-term. If not the blue or black pill, then perhaps one of ST’s own evaluation boards, or another STM32 board, as long as it’s well-supported in the Arduino IDE and has a good community that can help answer questions.

Ah, pin 9. I’ve written here about pin 9 problems several times already, but it’s still an ongoing source of trouble for my Yellowstone drive controller card. Depending on the specific model of disk drive used, pin 9 may be:

• The -12V supply input, required for the drive to work correctly
• Unconnected, but OK to provide -12V anyway
• A second +5V supply input, in parallel with pin 11
• A manual eject input that turns on the eject motor when it’s low

Yellowstone doesn’t have any way of knowing how the drive expects pin 9 to be used, and the wrong assumption may cause serious problems. In my earlier discussions about pin 9, I’d thought that the Disk II was the only drive that required -12V on pin 9, and I wasn’t aware that any drives used pin 9 for manual eject. Now I see that the situation is more complicated. Here’s a list of every disk drive that should be expected to work with Yellowstone, along with their usage of pin 9. Some of these I have directly examined, and others are inferred from their list of compatible computers.

Footnotes on the “probably” entries in the table:

Unidisk 5.25: manualzz says it requires -12V
Duodisk 5.25 and Disk IIc: manualzz says they’re not compatible with the IIe card for Macintosh LC. This card lacks -12V, so I assume the drives require -12V
M0131: is compatible with the Mac Plus, which provides -12V to external drives, and also compatible with later Mac models that don’t provide -12V
G7287: is compatible with the Mac Plus and Apple IIgs (for 400K/800K disks only), which provide -12V to external drives, and also compatible with Mac models that don’t provide -12V
bare 800K 3.5 drive, black label: works as an internal drive in the Mac Plus with a straight-through “red stripe” cable, where -12V is provided on pin 9, and works as an internal drive in the Mac SE, where -12V is not provided to internal drives

Almost all of the 5.25 inch drives appear to require -12V, so it’s important for Yellowstone to handle that well. On the other hand, the only drives that won’t work with -12V on pin 9 are bare/internal 3.5 inch drive mechanisms, and that’s going to be rare. Most people will be using a proper external drive like the M0131 or G7287. Even if there were no problems with -12V, using a bare/internal 3.5 inch drive on an Apple II wouldn’t be a great experience, because outside of GS/OS there’s no easy way to trigger a disk eject. This doesn’t seem like an important usage case.

Given this, I think a reasonable solution could be for Yellowstone to directly connect -12V to pin 9, and say that bare/internal 3.5 inch drives aren’t supported. Or going slightly better, say that bare 3.5 inch drives are supported but require a special cable where pin 9 is disconnected.

Another solution might be to put a pair of removable -12V jumpers on the Yellowstone PCB, one for each drive connector. The jumpers would normally be installed, but could be removed if using a bare 3.5 inch drive. Maybe I’ll do that, but I’m not a fan of manual configuration jumpers, because they create an opportunity for people to accidentally screw up and cause confusion or worse. Since -12V is either required or permitted in 99 percent of the disk drive setups people are likely to encounter, it seems more foolproof to design for that assumption, and require a special cable for the rare case of a bare 3.5 inch drive.

The gold-plated solution would be to automatically recognize whether -12V is needed, and programmatically enable -12V with a transistor. That should be theoretically doable, based on the existing drive detection logic, since only 5.25 inch drives require -12V. Yellowstone first searches for a 3.5 inch drive at each connector, and if it fails to find one then it searches for a 5.25 inch or Smartport drive. So it could begin with -12V disabled, and only enable -12V if it fails to find a 3.5 inch drive. But I’m almost certainly not going to do this, partly due to concerns that the drive type might be misdetected sometimes, but mostly due to being tired of this whole pin 9 saga. I would rather find a simple and reliable solution and move on, even if it’s not the most elegant.

The latest version of Yellowstone is v2.1, which has a 2.2K series resistor between the -12V supply and pin 9. I had convinced myself this would work for both the Disk II and for the bare manual-inject SuperDrive. Now that I see the full picture, I realize the resistor idea is garbage. So there will need to be a v2.2 PCB to fix this, plus at least one other hardware issue that I’ve identified with v2.1.