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.