BMOW title
Floppy Emu banner

Yellowstone 2.2 First Look

Yellowstone version 2.2 is up and running! If you don’t remember what’s changed in v2.2, well… that makes two of us. Luckily we can both go read this August 20 post for a reminder. Hand assembly took about two hours, and this was the first time any of the Yellowstone prototypes have worked straight away without needing any troubleshooting or fixes. The board has only been through one superficial test so far, confirming the ROM contents and booting a 5.25 inch disk, but I’m feeling optimistic it’s a winner.

After going through board v1.0, v2.0, v2.1, and v2.2, I’m sincerely hoping that this will be the final hardware version. The return of the DIP switch is the most visible change here – now the much-discussed -12V supply can be manually enabled or disabled. Leaving it enabled will almost always be OK, but there are a couple of polyfuses to protect the hardware just in case. There’s also a fix in v2.2 for a minor problem that prevented an Apple 3.5 Drive’s eject button from working if the drive was plugged into Yellowstone’s connector #2.

There are still some software issues to clean up, but (crossing my fingers) I think I can see the finish line now.

Just for fun, here’s a shot of the new Yellowstone board along with all of the disk drives I’ve amassed for testing. All of these will work with Yellowstone, and many others too.

And a bonus feature: here’s a peek at a 50 pin Apple peripheral card breakout board that I whipped up. It has all the signals labeled, because I don’t trust myself while debugging. With this breakout board, it’s possible to run a peripheral card on a breadboard instead of inside the Apple II. That’s exactly what I’m doing with the work-in-progress version of the Yellowstone tester shown here.

Read 6 comments and join the conversation 

Testing For Short Circuits

I’m still working on the design for an automated Yellowstone tester. The general idea is to use an STM32 microcontroller that’s connected to all the Yellowstone board’s I/O signals, then drive the inputs in various combinations and verify the outputs. This should catch a lot of potential problems, including open circuits, missing components, and many instances of defective components. But what about short circuits on the Yellowstone board that’s being tested? These aren’t so simple to detect, and they can potentially damage the tester.

The trouble with short circuits is that they can’t really be tested by working with digital signals alone – they force the whole problem into the analog domain. Depending on what’s shorted, and the effective resistance of the short, the behavior can vary greatly. A direct +5V to ground short might blow a fuse, or prevent the tester from even initializing if it shares a common supply. Other shorts might occur between a signal and any supply voltage (+5, -5, +12, -12), or between two supply voltages, or between two signals. The shorted signals might be driven from the tester, or from a chip on the Yellowstone board, or one of each. A short might cause immediate failure somewhere, or it might just cause a signal’s voltage to get pulled down or up. Depending on the change in voltage, it might not be enough to flip a bit and create a detectable error. Lots of components can also likely survive a short circuit for a while, but they’ll get hot, and will probably fail later. How can the tester detect these?

Assuming there’s a fuse, what type should it be? A replaceable fuse will be annoying if boards with shorts are at all common, since the fuse will need replacement often while testing a batch of boards. A poly fuse is resettable, but it can take about an hour to cool down enough to reset, rendering the tester unusable during that time. Neither option seems great.

If there’s a fuse, what should be fuse-protected? A fuse on the board’s 5V supply won’t do anything if there’s a short between an input signal and GND, because the current will be sourced by the tester and not by the Yellowstone board. Nor will it do anything for shorts on the other supply voltages. A short between signal and supply or between two signals may or may not be protected by a fuse, depending on where the current is ultimately sourced.

What max current rating is appropriate for a fuse? The “safe” current level could vary widely depending on what supply or signal is considered, and the current state of all the I/O signals. Then there’s there the 3.3V regulator on the Yellowstone board, which has its own overcurrent protection mechanism. If there’s a short between 3.3V signals, the regulator will limit the current, and a fuse or other mechanism on the tester may not even realize that a short circuit occurred.

My head is spinning just trying to map out the possible short circuit cases, and how to detect and prevent them. At the same time, I’m trying to design a tester that strikes a good compromise between complexity and thoroughness. Maybe I could design a tester with a dozen different fuses and current-monitoring ICs and IR thermal sensors, and it would be great at detecting short circuits, but it would be too much complexity and effort for a small-scale hobbyist product. My goals are to avoid damaging the tester, and to detect a large majority of common board failures including short circuits, while recognizing that it will never be 100 percent perfect.

Read 16 comments and join the conversation 

Dark Castle Bugs

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.

Be the first to comment! 

Smartport Cleanup

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?

Be the first to comment! 

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 

PCB 2.2, Board Tester, And One More Problem

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.

Read 5 comments and join the conversation 

« Newer PostsOlder Posts »