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?