BMOW title
Floppy Emu banner

4th Quarter Fumble

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.

Read 10 comments and join the conversation 

10 Comments so far

  1. Matt - August 26th, 2021 7:19 am

    You’ve referenced 2-layer boards a few times now as causing (or contributing to) various difficulties. At one point you also said (IIRC) that your license for the layout software you use only allows 2-layer boards. Given that you’re running a business on this, and thus have a revenue stream, would it make sense to bite the bullet and switch to 4-layer boards for your next project?

    I’ll grant that I don’t have any visibility into your situation and the affordability of a license upgrade, but the layer limitation seems to come up frequently enough that I thought I’d ask.

  2. Steve - August 26th, 2021 12:30 pm

    4-layer PCB would make sense for future products, but it’s probably too late to change that now for Yellowstone without creating more new challenges than it would solve.

    I’ve made a change to the firmware that should prevent unintentional Smartport resets due to PHASE0, PHASE1, and PHASE2 temporarily transitioning during 3.5 inch drive access, and it seems to work. So I’m optimistic that a hardware modification may not be needed here.

    But along the way, I discovered an unrelated bug with Smartport writes that looks serious. After many (all?) Smartport writes, Yellowstone goes into a cycle of repeatedly resetting and reinitializing the Smartport 10+ times. Eventually it succeeds, but the state of other drives gets screwed up. Even if there are no other drives, you can still see the pattern of repeated resets. Saving a BASIC file to a Smartport ProDOS disk actually crashes into the monitor, which I know was working at one point in the past. I’m not sure what’s happening, but there’s a definite feeling here of one step forward, two steps back.

  3. Vincent - August 26th, 2021 1:49 pm

    Not trying to be over familiar, but You can do it Steve! I’ve watched this over XX years and you are almost there – Don’t get disheartened now at the last hurdle!

    The V1.0 of anything always has ‘features’, just put them on the backlog for V2.0. Suggest a first test batch of V1.0 and if you get too many tech support issues, decide then whether its worth it to continue with V1, develop V2 or stop.

  4. Steve - August 26th, 2021 2:25 pm

    Thanks. All I can say is thank god for revision control. I was able to go back about five weeks and find a version where saving a BASIC file to a Smartport ProDOS disk worked OK. Now it’s just a matter of finding where and how I broke it.

  5. Chris M. - August 26th, 2021 5:35 pm

    If anything this fumble led to finding a pretty serious bug. So, time not wasted.

  6. Steve - August 27th, 2021 12:17 pm

    Hah, it seems to be turtles all the way down to the bottom. I think I have a work-around for the original problem of accidental Smartport resets and enables, and I’ve also fixed the second problem that I encountered while debugging the first, where it would crash when saving a BASIC file to a Smartport disk. But I discovered a third Smartport problem while debugging that one, and then a fourth problem in the course of debugging the third.

    This all points to a need for more careful low-level testing. Until now my tests had all been something like: connect drive A and drive B, boot the computer with a few different disks, copy some files, and declare success if there are no obvious errors. But now I see there are sometimes soft errors occurring that are invisible without a logic analyzer or other low-level instrumentation. Drives will do unnecessary recalibrations and seeks, or Smartport devices will be reset at unexpected times (real resets, not accidental ones due to PHASE usage). These are probably caused by automatic failure-retry mechanisms built into the firmware, or into ProDOS and GS/OS.

  7. Merlin - August 27th, 2021 4:41 pm

    Steve, what I’d like to know is how Apple expected this mess to work together in the first place? Were they just “winging it”?!?

  8. Chris M. - August 27th, 2021 5:26 pm

    They weren’t winging it, just restricted how the drives could be connected up. SmartPort was clearly designed to take 5.25″ drives on the chain into account by using implausible phase line combinations to “overload” a storage device protocol over a floppy interface. Later on, the daisy chain board in the Apple 3.5″ drives sorted out a lot of the mess of mixing drives on the same chain.

  9. Merlin - August 27th, 2021 6:36 pm

    And then Steve comes along and tries by himself to sort out this incredible mess that Apple created? Wow! Steve, my hat’s off to you!

  10. Steve - August 28th, 2021 7:25 am

    Apple’s scheme is awkward and was obviously developed piecemeal as new types of drives were invented over the years, but it works OK for their specific usage cases. My “fumble” problem arises from having two separate Smartport-capable disk connectors with the I/O signals in parallel, which is something that Apple never did. I’ve created a firmware work-around that should resolve it without PCB changes. The later Smartport write bugs that I discovered aren’t related to the parallel signals, but are just weird bugs in the Yellowstone firmware and FPGA logic.

Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.