BMOW title
Floppy Emu banner

Archive for the 'Yellowstone' Category

Yellowstone Goes Open Source

Happy birthday and merry Christmas, Apple II collectors! I’ve decided to make a gift of my design for an FPGA-based disk controller card, and release it under a Creative Commons – BY-SA license. This means anyone else is welcome to use it, modify it, build it, or sell it. And I hope they will! This mostly-finished design has languished for so long on my workbench, I finally decided it was better to let others take advantage of it than for it to gather dust forever. I know there’s economic value in what I’m giving away here today, but that value is only theoretical while I sit idle. It’s been almost a year since I last worked on the project, and almost two years since I began work on the design, and that’s too long. So here you go!

The only restrictions are on the terms “Yellowstone”, “BMOW”, and “Big Mess o’ Wires”. They’re not covered by this license, and are reserved for my exclusive use. If you build something based on this design, don’t use any of those words. You’ll need to pick a new name like Turbo-Disk Mega Ultra Elite.

You can download the design data here: FPGA disk controller Github repository

 
Ground Rules

Please don’t send me detailed questions and requests for help with this design, or expect me to be your engineering consultant. I’m releasing the design to the community because I don’t have time to pursue it myself. That means I can’t work on it for you, either. The design is released as-is, with no promise of technical support. I may be able to answer general questions, but the rest is up to you.

 
What is This?

Yellowstone is the code name for an Apple II disk controller card that’s based on an FPGA, rather than using discrete logic chips and ROM chips. By reprogramming the FPGA, the card can be made to emulate various other disk controller cards made by Apple in the 1980s and 1990s. The work so far has focused on emulating an Apple Liron disk controller card, but it would also be easy to emulate a Disk II controller card. It’s theoretically also possible to emulate a Disk 3.5 controller card, though this possibility has not been explored in detail.

 
What’s Liron?

The Liron disk controller was introduced by Apple in 1985. More formally known as the Apple II UniDisk 3.5 Controller, it’s designed to work with a new generation of “smart” disk drives more sophisticated than the venerable Disk II 5.25 inch floppy drive. The smart disk port on the Liron is appropriately named the Smartport, and it can communicate with block-based storage devices such as the Unidisk 3.5 (an early 800K drive) and Smartport-based Apple II hard drives.

Why care about the Liron? The Apple IIc and Apple IIgs have integrated disk ports with built-in Smartport functionality, but for the earlier Apple II+ and IIe, the Liron is the only way to get a Smartport. For owners of the BMOW Floppy Emu disk emulator, having a Liron card makes it possible to use the Floppy Emu as an external hard drive for the II+ and IIe. Unfortunately finding a Liron is difficult, and although they occasionally turn up on eBay, they’re quite expensive. That makes cloning the Liron a desirable goal.

 
How it Works

The FPGA disk controller card is little more than an FPGA, a voltage regulator, and a set of level-shifting bus transceivers. The FPGA replaces all of the 7400-series discrete logic chips typically found on a disk controller card. Verilog (hardware description language) replacements for all of the 7400-series parts and other logic were written and programmed into the FPGA. This also includes a full Verilog implmentation of the Apple IWM chip.

The FPGA also replaces the ROM chip containing the boot code for the card. The Apple II executes this code during power-up, and the code knows how to find and load sector 0 from the attached disk drive. The code was obtained from a ROM dump from a real Liron card.

The prototype card also includes a footprint for an 8-pin SPI flash memory chip. It is not used by the current FPGA code, and the chip can be omitted. The idea was that a small number of disk images could be stored in SPI flash memory, so the card could function both as a disk controller and as a disk emulator, but this was never implemented.

The card has a standard 10 x 2 pin disk connector on board. It can be connected directly to a BMOW Floppy Emu disk emulator, using a standard ribbon cable. But for a full Liron clone and connecton to a Unidisk 3.5, a DB-19 female connector is required. A design for a DB-19F adapter PCB is included here, and the adapter can be connected to the disk controller card with a short ribbon cable. The DB-19F is still available from surplus electronics suppliers in small quantities.

 
Project Status

See here for a complete history of work involving the FPGA disk controller.

The FPGA disk controller card was designed by Steve Chamberlin at Big Mess o’ Wires during the summer of 2017, but the first prototype card wasn’t built and tested until January 2018. The version 1.0 card had errors with the wiring for the output enable signal on one of the bus transceiver chips, and it required a few hand-soldered path wires to fix. After further development, the prototype card was demonstrated to work as a Liron clone, in both an Apple IIe enhanced computer and an Apple IIgs. It worked for controlling a real Unidisk 3.5 drive, as well as a BMOW Floppy Emu disk emulator configured for Smartport emulation mode.

Later testing discovered that the FPGA disk controller card worked reliably when it was the only card installed, but other cards were also present, it sometimes malfunctioned. The more other cards present, the worse the rate of errors became. This was diagnosed as a likely termination or contention problem on the Apple II data bus, and various fixes were tried unsuccessfully. After March 2018, I lost interest in researching the problem further, and no more work has occurred since then.

The design provided here is version 1.1, and it fixes the output enable problem from version 1.0.

 
Where to Start

  1. Open the FPGA disk controller design (Liron clone) in EAGLE. Export Gerber files and send them to your favorite PCB fabricator. If desired, do the same for the DB19F adapter design.
  2. Purchase the chips and other parts listed in the BOM.
  3. Assemble the card. I did it by hand, you can do it too. A syringe of solder paste and a hot plate or toaster oven works nicely.
  4. Get a Lattice JTAG programmer or appropriate clone. Some clones don’t handle 3.3V logic correctly. Maybe spend the extra money for a genuine Lattice programmer.
  5. Install the Lattice Diamond software.
  6. Apply 5V power to the card at jumper J4. Do not insert the card into your Apple II yet.
  7. Program the FPGA with the bitstream for the Liron clone design – liron_fpgatop.jed
  8. Insert the card in your Apple II. Remove any other cards that are present.
  9. Connect a Smartport-compatible disk drive, such as a BMOW Floppy Emu disk emulator that’s configured for Smartport emulation mode, or an Apple Unidisk 3.5 drive.
  10. Turn on the Apple II. It should boot from the attached drive.

 
Next Steps

The bus termination or bus contention problem must be solved, in order to get a robust card that works smoothly when other cards are also present. See the blog posts from February-March 2018 for more details about what was already tried. A solution will require a person who’s experienced at electronic design, and has appropriate test equipment such as an oscilloscope and logic analyzer.

The current design uses a Lattice MachXO2 1200HC FPGA, and a Lattice JTAG programmer (or compatible) is required for programming it. The XO2-1200HC has more logic resources than are actually necessary for the Liron clone design. The cheaper XO2-640 or XO2-256 could be substituted instead. They are mostly or entirely pin-compatible with the XO2-1200HC.

Programming the FPGA with a JTAG programmer is fine for development use, but end users are unlikely to have one. If reprogramming by the end user is desired (say to switch between Liron and Disk 3.5 emulation behaviors), a different method of FPGA programming will need to be developed.

Read 4 comments and join the conversation 

Garbage In, Garbage Out

I’m beginning to suspect there’s something subtly wrong with my Apple IIe, which might explain a lot of strange intermittent errors I’ve recently observed with Yellowstone and Floppy Emu development. It’s hard to know what to conclude, but when you can’t trust your test equipment, it’s impossible to trust the validity of your test results.

Recently I used this Apple IIe to test my new Floppy Emu OLED prototype board. When connected to a standard Apple Disk 5.25 controller card, everything worked fine initially. But when I tried doing some ProDOS file copy operations, the Floppy Emu spontaneously reset to the happy face / self-test screen. DOH! I tried it twice, and the Emu reset itself during the copy operation both times. I concluded there must be something wrong with the prototype board.

Then I tried the copy test two more times, and got different results. The Emu prototype didn’t reset itself, but the OLED display went blank several times during the copy operations. Hmmm.

So then I tried a plain vanilla Floppy Emu Model B, the same hardware and firmware that I’ve been using successfully for more than a year. I found that when trying to boot the Apple IIe from a ProDOS v1.9 disk image, the Model B’s LCD went blank several times during booting. Huh? This happened in two consecutive test runs, but then mysteriously stopped happening. I also tried the same file copy operations I’d done with the OLED prototype board, and saw a similar behavior where the LCD went blank a few times during the copy. But as before, after reproducing the bug twice in a row, it stopped happening.

Finally I went back to the OLED prototype board, and this time everything worked fine. No more unexplained resets or display blank-outs.

Maybe there’s something wrong with the Apple IIe’s power supply, or some problem where it needs to warm-up for a while before it works reliably? My first OLED prototype board tests were the first time I’d powered on the Apple IIe in several days, so it was cold. During an hour of testing, the strange Floppy Emu problems I’d observed gradually disappeared. It doesn’t really make sense to me, but it’s the best explanation I can think of. This might also explain some strange unexpected resets of the Floppy Emu last month, when I tested it with the Yellowstone card. In fact, it casts doubt on all of my Yellowstone testing.

Read 9 comments and join the conversation 

More Yellowstone Trouble

I did some surgery on the Yellowstone board, in an attempt to address major problems with power supply noise and data bus overshoot, previously discussed here and here. I replaced the 74LVC245 that drives the data bus with a 74LVC8T245. That’s a dual-supply chip that some readers suggested earlier: it ensures the bus outputs will drive all the way up to 5V, while hopefully reducing any noise coupled to the 3.3V supply, and avoiding the possible violation of limiting values with the 74LVC245 that I mentioned in my last comment to the previous blog post. The Yellowstone board still mostly works with the 74LVC8T245, but now the data bus overshoot climbs to a whopping 9 volts! Arrrrgh.

Channel 1 (yellow) is a copy of the Apple II slot’s /IOSELECT signal, passed through the FPGA. When it goes low, it means the Apple II wants the card to drive the bus.
Channel 2 (light blue) shows D0 on the data bus, with a nasty overshoot.
Channel 3 (pink) is an internal active-high debug signal from the FPGA that shows when it’s outputting a value for the 74LVC8T245 buffer. This is a sanity check on what’s happening.
Channel 4 (dark blue) shows the Yellowstone card’s ground, with respect to the Apple II system ground. Note there’s about 1V of peak-to-peak ground noise.

Something is badly wrong, and I can’t find it. I could design a new board with some series termination resistors, as a few people suggested, but my intuition is that isn’t really the main problem. None of the other Apple II cards I’ve examined appear to use any termination at all. 9V is a massive overshoot. And termination issues wouldn’t explain the problems observed on the card’s 3.3V power and GND supplies. I feel like I’m headed down the wrong path.

I’ll probably ice this project for a while, since enthusiasm for further debugging has run out. On to something else…

Read 9 comments and join the conversation 

Yellowstone Arrgh

I’m still struggling with these Yellowstone card electrical problems, but getting nowhere. Very frustrating. I’ve focused my attention on the large amount of overshoot on the data bus, and the power supply fluctuations, under the theory that minimizing those will eliminate all the functional glitches and failures I’ve experienced.

The FPGA has eight bidirectional pins that are connected to one side of a 74LVC245 buffer. The other side is connected to the data bus. The buffer’s direction is controlled directly from the CPU’s R/W signal, and the buffer’s output enable is controlled by FPGA logic. The FPGA pins direction are controlled by separate FPGA logic. See the schematic here.

The image above shows the moment when the card starts to drive a value on the data bus.

Channel 1 (yellow) is a copy of the slot’s /IOSELECT signal, passed through the FPGA. When it goes low, it means the Apple II wants the card to drive the bus.
Channel 2 (light blue) shows D0 on the data bus. Notice how it climbs from 0 to 2V, retreats back to near 0, shoots up to 4.6V (a good trick for a 3.3V chip), and finally settles at 3.3V? Yuck.
Channel 3 (pink) is an internal active-high debug signal from the FPGA that shows when it’s outputting a value for the 74LVC245 buffer. This is a sanity check on what’s happening.
Channel 4 (dark blue) shows the Yellowstone card’s ground, with respect to the Apple II system ground. Note the scale: it doesn’t look like much, but there’s almost 1V of peak-to-peak ground noise.

Besides the data bus overshoot, there’s also something odd with /IOSELECT on channel 1. Because there’s no convenient place for me to physically probe the actual /IOSELECT signal, I used an FPGA debug output pin to mirror /IOSELECT and capture it with the scope. The result should look identical to the actual /IOSELECT, except shifted to 3.3V logic levels rather than 5V, and with a few nanoseconds of extra delay. But why is there 1V of undershoot on the scope when /IOSELECT first goes low? The scope is capturing a debug output that’s just a two-inch trace on the Yellowstone card, with no other load except the scope probe. I was not expecting to see any undershoot or overshoot on these debug signals, and the channel 3 (pink) debug signal doesn’t show any.

As bad as that scope trace looks, this one looks worse:

This looks like some kind of glitch, because the FPGA is only outputting for about 60ns, but a normal output lasts about 500ns. /IOSELECT starts to fall, but then goes back up, and shoots up to 5.0V (remember this is an output from a 3.3V chip). The data bus voltage spikes to 6.6V, and the Yellowstone ground reaches 2.0V relative to Apple II ground. Arrgh!

In an effort to troubleshoot this glitch further, I switched channel 2 (light blue) to show the direction of the Apple II motherboard’s data bus buffer, which should (I think) simply be the CPU’s R/W signal. This was the result:

It appears that the glitch occurs just before the end of a CPU write, when the direction switches from low to high. Assuming that’s the CPU R/W signal, that means the glitch starts during a time when R/W is 0, which should be impossible. Here’s the Verilog equation for the channel 3 (pink) signal:

assign isOutputting = (rw && ~_romoe);

If R/W is zero, then isOutputting must also be zero, but from the scope trace it’s obvious that’s false. There’s something happening here that I don’t understand. Maybe the Apple II motherboard’s data bus buffer direction isn’t driven from the CPU’s R/W, but from some other buffered or computed signal.

When I rearranged some things in an attempt to investigate the glitch further, it disappeared. I was never able to find an explanation.

 
Head Scratching

There are so many strange unexplained problems, it’s a miracle that the card actually works most of the time!

So what causes big overshoots and supply fluctuations? I can think of a few possibilities:

1. 3.3V voltage regulator can’t meet the instantaneous demand for current
2. Insufficient bypass capacitors on the card
3. 5V and GND connections from the card to the slot are too wimpy, and can’t carry enough current without significant resistive loss
4. Impedance mismatch on the data bus, signal reflections, etc.

Considering each of these in turn:

1. There’s a 300 mV LDO on the card, which I’ve calculated should be enough for the average demand. Brief spikes in demand should be satisfied by the capacitors. What’s the behavior of a typical LDO when it’s overtaxed? Does the regulated voltage drop, or does ground get pulled up, or both? If I make another revision of the Yellowstone board, I’ll substitute a larger regulator just to rule out this possibility.

2. My intuition pointed to this explanation first, but it hasn’t been confirmed by experiments. You can see all the bypass capacitors in the schematic: at least one 0.1 uF ceramic cap for the power supply on each chip, plus others recommended by the FPGA and LDO datasheets. I tried jury-rigging additional capacitors at various points on the board, but they didn’t make an observable difference in the signals as viewed on the scope. And even if this were the problem, I could imagine it causing the overshoot seen on the databus, but I can’t see how it would cause Yellowstone’s ground to rise to 2.0V relative to Apple II ground.

3. I tried connecting some extra jumper wires from ground points on the card to ground points on the Apple II motherboard. It didn’t make an observable difference in the signals as viewed on the scope. But maybe 5V has a problem?

4. An impedance mismatch could be part of the problem, but what would I do about it? The Apple II bus can contain anywhere from zero to six other cards of assorted types, so it’s not clear what impedance I should try to match. And all the vintage 1980’s cards I’ve observed don’t appear to have any termination resistors or other obvious impedance matching circuitry – they just connect a 74LS245 or similar buffer chip directly to the bus.

For clarity, I don’t think Yellowstone’s use of a 3.3V 74LVC245 is a problem, at least not in the way suggested by some commenters. Yes, this chip can only drive to 3.3V, but that’s plenty high enough to register as a logical high for the 74LS series logic used elsewhere in the Apple II. And the scope traces clearly show that the data bus voltages are high enough. If the 74LVC245 is causing a problem, it must be some less-obvious mechanism like coupling noise to the 3.3V supply, or maybe a too-fast slew rate.

I’ve pounded my head long enough, and am running out of ideas. Debugging is hugely impeded by the absence of any place to physically probe many of the bus signals, and by a scope with only four analog channels. The scope also has a 70 MHz bandwidth, which might be a factor. I feel too much like I’m scratching randomly in the dark, rather than making systematic progress towards narrowing down the causes of the problems.

My temptation is to design a new revision of the card, and include some speculative changes that might help. I could substitute a beefier LDO, add more capacitors, make the power connections extra-robust, and include additional debug headers for probing bus signals. It can’t hurt, but realistically it probably won’t help either. I could also try adding some termination resistors, but that just seems wrong somehow, given that no other Apple II cards appear to use them.

Electronics can be hard. In the 10 years I’ve been writing this blog, I’ve never encountered a problem that had me so completely stalled as this one.

Read 16 comments and join the conversation 

Apple II Card Electrical Woes

The digital abstraction of zeroes and ones is lovely, but electronics debugging often requires a deeper look into the realm of analog signals. That’s the story of my Yellowstone FPGA-based disk controller for Apple II, and it’s slowly driving me crazy. Those nice clean zeroes and ones are gone, and instead I’m struggling with voltages, logic thresholds, capacitance, and power in an attempt to explain what’s going wrong.

This story begins 12 days ago, the first time I successfully booted my Apple II using the Yellowstone card. With Yellowstone configured to clone a Liron disk controller, I was able to boot from a Unidisk 3.5 drive as well as from a Floppy Emu in Smartport emulation mode. Success! But the excitement was short-lived: it only worked when Yellowstone was the only card installed in the Apple IIe. With another card present, the computer would crash into the system monitor during power-up about 90% of the time. With more investigation, I gathered these clues:

  • it didn’t matter what the other cards were
  • it didn’t matter what slots the cards were in
  • the crash occurred even when no disk drives were attached – so it’s unrelated to the drive or the disk contents
  • the crash occurred in an Apple IIe and an Apple IIgs
  • in the Apple IIgs, crashes were more likely to occur as the number of other cards increased

Based on this, I suspected some kind of electrical problem as opposed to a logic design problem. More cards means more capacitance on the data bus: maybe the Yellowstone output driver wasn’t able to switch the bus signals fast enough? More cards also means more load on the data bus: maybe the Yellowstone output driver wasn’t able to source or sink enough current to maintain a valid logic high or low voltage?

With a logic analyzer, I examined the pattern of card accesses during good and bad power-up sequences. During a normal boot, there’s a 93ms period of near-continuous Yellowstone ROM access, which is probably running the ROM code to look for an attached drive. During a boot-up where the computer crashes, this ROM access lasts a much shorter random-seeming amount of time. I measured times of 0.19ms, 1.57ms, and 28.5ms. From this I concluded that the crash is happening during execution of the Yellowstone ROM code, rather than the Yellowstone card somehow causing an error with another card or with the Apple II itself.

Some hardware background: shown above is a simplified schematic of the card (click for a hi-res version). The FPGA runs at 3.3V, powered from a Micrel MIC5504-3.3YM5-TR LDO regulator. A set of four 74LVC245 chips provide 5V to 3.3V level translation. Three of the chips are configured for unidirectional signals like the address bus and control signals, and the fourth is bidirectional for the 8-bit data bus. Each 74LVC245 has a 0.1 uF ceramic bypass capacitor about 2 mm from its VCC pin. The FPGA has twelve 0.1 uF ceramic bypass capacitors for each of its power/ground pin pairs, and its 3.3V supply is isolated from the rest of the board’s 3.3V supply with a ferrite bead, as recommended in the FPGA datasheet. There are also 10 uF ceramic capacitors on the input and output of the LDO.

So… where to begin troubleshooting? Based on suggestions from helpful commenters on a previous post, I used a scope to measure the Yellowstone card’s GND and 3.3V relative to a ground point on the Apple IIe motherboard. They both looked pretty noisy, with peak-to-peak oscillation of 680 mV for Yellowstone’s ground and 460 mV for 3.3V, at the moment Yellowstone begins to drive the data bus. But surprisingly I also observed virtually the same oscillation when Yellowstone was *not* driving the data bus and the Apple II was idle – shown in the trace above where where light blue is GND and pink is 3.3V. Then for comparison I examined a standard Disk II controller card, when Yellowstone wasn’t installed in the computer. On the Disk II card, while the Apple II was idle, I measured 600 mV of oscillation on GND and 280 mV on 5.0V. I’m not sure how to explain all this, except to note that Yellowstone’s supply oscillations don’t seem dissimilar to other cards.

At this point I tried a few quick experiments:

  • Adding a 47 uF electrolytic capacitor across the Yellowstone card’s 3.3V and GND supplies didn’t make any noticeable difference.
  • Connecting an extra ground wire between the Yellowstone card and a ground point on the motherboard helped a lot. The frequency of crashes after reset dropped from 90% to 20%. Hmmm.

To check the data bus voltage levels and timings, I used a 4-channel scope:

  • Channel 1 (yellow) – /IOSELECT – Asserted when the Apple II wants the card to drive ROM data onto the bus.
  • Channel 2 (light blue) – Phi 1 – 6502 clock signal.
  • Channel 3 (pink) – Phi 0 – 6502 clock signal. A read operation terminates at the rising edge of Phi 0.
  • Channel 4 (dark blue) – A bit on the data bus, either D0 or D7 depending on the test.

/IOSELECT was measured at the card. Phi 0 and 1 were measured directly on the 6502. The data bus was measured at the motherboard’s 74LS245 buffer, chip UB2 on the Apple IIe motherboard.

To make a long story short, everything looked mostly fine, and I’m stumped as to why Yellowstone crashes when other cards are present. Here’s a selection of scope traces.

As a starting reference, the trace above shows a real Liron card with no other cards installed. When /IOSELECT is asserted, D0 goes high about 64 ns later. It overshoots to 4.7V before settling back to 3.8V. After the rising edge of Phi 0 and /IOSELECT is deasserted, the data bus stays high for 270 ns more. I suspect this is bus capacitance holding the old value while nothing is actively driving the bus, as opposed to the Liron card actually driving the bus beyond when /IOSELECT is deasserted.

Here’s the Liron card driving a logic low voltage on D7. The signal timing is the same as for the logic high on D0. The low voltage is about 80 mV.

I repeated both of these tests with a Liron and a Disk II card both present, and the results looked basically the same.

Here’s the Yellowstone card, with no other cards installed. The signal timing looks the same as with the real Liron card, including the 270 ns “hold period” after /IOSELECT is deasserted. D0 shows a large overshoot to 5.7V before settling back to 3.4V, which is about what I’d expect from a 3.3V card. While that’s a lower voltage than seen from the Liron card, it’s still well above the logic high threshold of 2.0V for the Apple IIe’s 74LS245 buffer.

Yellowstone driving a logic low. There’s some significant undershoot, then the voltage goes to 0V, and timing looks OK.

Now comes the interesting part: the trace above shows the Yellowstone card with a Disk II card also installed. This is the case that doesn’t work, where the computer crashes during power-up. I expected to see something wrong on the scope trace, but I didn’t. It looks very similar to previous test with Yellowstone by itself. The signal timing is the same. The high voltage overshoots to 5.4V before settling back to 3.3V.

Finally, here’s the Yellowstone card with a Disk II card also installed, driving a logic low. The bus voltage goes to 0V. It looks the same as the case when no other cards are installed.

So what now? The only thing that looks maybe concerning in these traces is the large amount of overshoot from Yellowstone when driving a logic high voltage. But the overshoot is actually less severe when a second card is installed, not more severe, which doesn’t fit the pattern of more cards leading to more crashes.

Maybe the bus voltages are only bad at certain moments, when a specific value is driven onto the bus, or some particular combination of control signals occurs? That’s possible, as my test was only able to capture the very first access to card ROM during a boot-up. If there are bad voltages appearing later, I wouldn’t have seen them.

Maybe the problem isn’t bad voltages driven on the data bus by Yellowstone, but bad voltages received by Yellowstone from the data bus and from control signals? If the Yellowstone card’s ground were pulled above the Apple IIe’s ground, it would have the effect of raising the voltage threshold for Yellowstone to receive a logic high, and cause it malfunction if signals were received incorrectly. This might explain why attaching an extra ground wire seemed to help. But from what I’ve seen of the logic signals from the Apple IIe, they’re in the 3.8V and above range, which is significantly higher than the 2.0V threshold of Yellowstone 74LVC245 buffers, even when allowing for a few hundred millivolts of ground differential.

Maybe I’m wrong about this being an electrical problem at all, and despite the circumstantial evidence, it’s actually some kind of logic bug?

Read 36 comments and join the conversation 

Yellowstone Bugs

I’ve discovered a troubling problem with the Yellowstone disk controller for Apple II, and I’m unsure how to debug it. When it’s functioning as a Liron clone, Yellowstone isn’t playing nicely with other cards like a stock Disk II controller card. While booting from a Prodos 1.9 disk image using a Disk II controller in slot 6, Prodos crashes midway through booting if the Yellowstone card is present in slot 5. This happens even if there aren’t any drives connected to the Yellowstone card. It’s not 100% reproducible, but happens maybe 90% of the time. Yet everything works fine if I repeat the test with a real Liron controller card instead of the Yellowstone card. That means it’s my problem, and not the Liron designer’s.

I believe what’s happening is this: the Apple II scans the slots beginning with slot 7, and moving towards slot 1, looking for cards with a bootable ROM. It finds the Disk II card in slot 6, and jumps to its ROM code. That code loads sector 0 from the Prodos disk, displaying the splash screen shown in the photo. Then before Prodos has finished fully loading, the Apple II resumes the scan and jumps to the Yellowstone ROM code for slot 5. This code should look for attached Smartport devices, find that there aren’t any, and return. But somewhere during the execution of that ROM code, or during execution of the Prodos code just afterwards, something goes wrong. The Apple II stops and displays a system monitor prompt. Crash.

Where do I begin, with a bug like this? I don’t really know anything about the inner workings of Prodos, or even about the ROM code on the Yellowstone card, since I simply copied it verbatim from the Liron card without really studying it. That means I can’t easily figure out what the computer is trying to do at the moment it crashes.

My first guess is that I’m experiencing data bus contention, and the Yellowstone card is interfering with the Disk II card. The Disk II controller card and the Yellowstone card might both be attempting to put data on the bus at the same time, interfering with each other, and causing wrong values to be read from ROM code. But it’s hard to imagine how Yellowstone could be driving the bus at the wrong time. The output enable logic is pretty simple, and the Apple II already provides each slot with its own fully-decoded enable signals /DEVICE and /IOSELECT. There is a region of the Apple II address space that’s shared by all cards, and that uses a shared /IOSTROBE enable signal, but the Disk II card doesn’t use that address space.

My second guess is the reverse of the first: the presence of the Disk II card is somehow interfering with the Yellowstone card, exposing a flaw in the Yellowstone design that doesn’t appear when Yellowstone is the only card present. Maybe it’s somehow causing Yellowstone to malfunction. But I can’t really imagine what could cause that.

A third possibility is a problem caused by Prodos itself, rather than by the Disk II card. Maybe the first portion of Prodos alters some memory locations or sets some interrupt timers, or changes the system state in other ways that cause the Yellowstone boot ROM to fail. But it’s unclear why such an issue wouldn’t also affect a real Liron controller card in the same way.

A final possibility: maybe there’s a hardware problem with my Apple IIe, and there’s not enough juice to power two cards simultaneously, or the logic board is flakey. In the past on this same computer, I’ve occasionally seen similar crashes to the system monitor while booting Disk II software, long before Yellowstone even existed. Coincidence, or clue?

I’m scratching my head, trying to think what I could do to help troubleshoot this further, but I don’t have any great ideas.

Read 43 comments and join the conversation 

Older Posts »