BMOW title
Floppy Emu banner

Archive for the 'Yellowstone' Category

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 

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 

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 

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 5 comments and join the conversation 

Yellowstone Back From the Dead

Remember the Yellowstone disk controller card that I designed back in 2018? It was an FPGA-based clone of the Apple II Liron controller, with aspirations to eventually become a universal reconfigurable disk controller. And it worked nicely when it was the only card installed in the computer, but things went haywire when too many other expansion cards were also present. I eventually gave up and abandoned the project, but now I think I’ve fixed it.

The symptoms were documented in a series of blog posts here, here, here, and here. The more expansion cards present along with Yellowstone, the more likely I was to see errors such as unexplained resets and lockups and drops into the Apple II system monitor. Investigation with an oscilloscope showed lots of nasty looking signals, huge over and undershoot on the data bus, and strange transients on the power supply during card I/O.

There were plenty of theories to explain the problem, and I received over 100 comments from helpful readers. Some theories put forward were: poor grounding, insufficient bulk capacitance, a too weak 3.3V regulator, impedance mismatch, bus fighting, failure to meet the minimum input high voltage, a too strong or too weak drive from the bus driver IC, wrong FPGA slew rate, bad scope probes, bad power supply in the Apple II, a race condition in the logic, and more. My own best guess was a combination of grounding and impedance problems. I spent many weeks chasing various theories without much success. I hacked the card and replaced its bus driver with one from a different logic family. I even started to wonder whether the whole problem lay with the computer rather than the card. By March 2018 I gave up in frustration.

 
Two and a Half Years Later

This past week I’ve been investigating ideas for an Apple II video card, and a reader pointed me to this tech note about Apple IIgs expansion card design. The point was to learn which signals were provided to the different slots, but my eye caught a different paragraph titled “Avoiding Bus Fights”. As the text described,

“To avoid potential (or actual) bus fights, it is helpful to avoid driving read data from an expansion card onto the bus immediately after PH0 rises. … If a card drives data onto the expansion slot data bus immediately after PH0 rises, there may be a bus fight between the expansion card trying to drive the bus, and the Apple IIGS (or Apple IIe) bus buffers, which may not have turned around yet. … Developers can avoid bus fights by simply using 74LS or 74HCT series parts and relying upon typical delay stackups to delay driving the data bus for approximately 30 nanoseconds. A more solid technique is using the first rising edge of the 7M clock, after PH0 rises.”

My card responds when the Apple II asserts the I/O SELECT signal for its slot, which happens at the same time as PH0 rising. What this paragraph says is that the card should intentionally wait at least 30 ns before responding, because the motherboard’s 74LS245 bus driver is still driving the data bus even after PH0 and the assertion of I/O SELECT!

At first glance this seems ridiculous. Why would the Apple II assert I/O SELECT for a card before it’s safe for the card to output data? But if you assume the card is built with 1978 vintage ICs that can’t respond very quickly anyway, it wouldn’t have been a problem. The trouble only appears when you use an FPGA and modern logic families like 74LVC with propagation delays of just a few nanoseconds. It becomes necessary to add an artificial output delay to avoid bus fighting.

Several readers had suggested more or less exactly this, including Fluffysheap who described it perfectly in the comments here. But I must have been too frustrated or too tired back then, and I never fully followed through on checking this theory.

Bus fighting almost perfectly explains the horrible signals I observed on the scope. For a few tens of nanoseconds at the beginning of my card’s data output, it was fighting with the motherboard’s bus driver, creating eight short circuits on the 8-bit bus. This caused a surge of current, resulting in horrible power supply transients and wild swings on the bus. From my scope observations this period seemed to last about 70-80 ns, rather than the 30 ns mentioned in the tech note. But the tech note described the Apple IIgs, not the Apple IIe that I used for my tests. Maybe the Apple IIe bus driver is slower to shut off.

One thing that bus fighting doesn’t seem to explain is why adding more peripheral cards would make the problem worse. It appears my card was engaging in a bus fight with the motherboard’s own bus driver, and the other cards were just innocent bystanders. The only affect of their presence would be to increase the bus capacitance. I may still be missing something here.

 
Testing It

Armed with this newfound knowledge, I went to edit the Yellowstone FPGA source to insert an intentional delay before enabling the card’s bus driver for output. Lo and behold, code for creating a delay was already there, but commented out. It was written by me. I can’t remember if I ever tested it back in 2018. Maybe I had the idea but never tried it, or maybe I tried it but something went wrong. Either way, I gave thanks to 2018-Steve and just reapplied the already-existing code.

At first there was some comedy, because I tried several different changes that appeared to have no effect. After half an hour, I realized I was rebuilding the FPGA configuration file after each change, but then programming the old configuration file from 2018. Oops.

What can I say, it works. I loaded up my Apple IIe with a sampler of six different expansion cards in different combinations, connected to a variety of Floppy Emus and real drives, including a Smartport-aware Unidisk 3.5 drive. Everything worked as expected, and there were no unexplained resets or other weird behavior.

I looked at the data bus and the power supplies on the scope, and everything appeared cleaner than before. The power supplies looked OK. There was still some overshoot on the databus when the card first started driving, but much less than before. Maybe this can be improved further by adding some small inline resistors on the next version of the card. I adjusted the output delay to about 120 ns, which is probably much longer than necessary, but it still leaves more than ample time for 2020-era logic chips to do their jobs.

 
One More Issue

Things look good with Yellowstone on the Apple IIe, but the IIgs is another story. I have to switch the IIgs to normal speed instead of fast, but then the card should work. A real Liron disk controller card works fine in a IIgs, as long as the system speed is changed, so there’s no fundamental incompatibility. Unfortunately the Yellowstone card just plain doesn’t work on the IIgs. At first I thought that was a result of my new output delay, but removing the delay didn’t help. Then I dug through all my notes from 2018 and concluded that the card never worked on the IIgs under any circumstances. So this isn’t a new problem – it’s an old problem I just hadn’t noticed because it was overshadowed by the bus fighting.

The sort-of-good news is that this failure of Yellowstone on the IIgs seems repeatable and debuggable. Instead of weird spurious resets and lockups like I was seeing two years ago, it looks like it’s just a communication error with the drive. The Yellowstone card firmware appears to be running OK, and I get reasonable error messages like “NO DEVICE CONNECTED”. With a Unidisk 3.5 drive attached, there’s no drive activity. With a Floppy Emu attached and configured for Smartport emulation, it reports a checksum error.

I suspect there’s another timing problem here, but this one relates to writes to the card instead of reads. Perhaps I’m not latching the data from the bus at the right time, and due to minor differences between the bus timing on the IIe and IIgs, it still works OK on the IIe but occasionally writes the wrong values to the IWM chip on the IIgs, or fails to write anything. That would cause garbled communication with the drive.

I’m calling a stop for the moment, feeling pleased with this new progress, and optimistic that I’ll eventually find an explanation for the IIgs behavior.

Read 4 comments and join the conversation 

FPGA Disk Controller Next Steps

After more than two years of sporadic effort, my Yellowstone FPGA-based disk controller card for Apple II is finally working. That means the fundamental disk control capabilities are there, but there’s still a great deal of work left to do. Now I’m at a crossroads, and must decide what else makes sense to add, and what I’m genuinely interested to pursue. So what’s next?

In its current state, the card can function in one of two modes. Mode one is a work-alike Apple Liron disk controller, which is compatible with intelligent disk drives like the Unidisk 3.5 and the BMOW Floppy Emu‘s Smartport hard disk emulation. The best use of Liron mode is probably adding 32 MB hard disks to an Apple II+ or IIe with a Floppy Emu.

Mode two has the functionality of the standard Disk II controller for 5.25 inch floppy drives. That’s maybe less exciting since virtually everyone already has one of these, but there are plenty of uses for a second 5.25 inch disk controller. eBay’s supply of original Disk II controllers is shrinking, and prices are climbing, so it’s helpful to have an alternative. There’s still some work remaining to finish Yellowstone’s support for 5.25 inch floppy writing (reading is finished), but I don’t anticipate any major difficulties there.

 
Electronics and Mechanics

My first task for version 2 is to address a lengthy list of board changes. Most of these won’t change the card’s behavior, but they’ll help it to work more reliably and safely, and provide for future improvements. These changes include things like adding termination resistors and bus drivers to isolate the FPGA, a bigger voltage regulator, test points for all the important signals, more capacitors in different places, improved power/ground routing, and adding a second disk connector.

Some helpful Apple II bus signals aren’t connected correctly, or aren’t connected at all, so I’ll need to fix that. A hardware solution for self-programming needs to be designed and added too. There’s lots of work to do in this category, and it could keep me busy for weeks. That’s frustrating when all I want to do is develop new features, but taking care of the card’s electronic fundamentals is important.

 
Drive Type Auto-detection

The two modes are selectable with a jumper on the card. It’s either a Liron or a Disk II controller. It would be nice to merge these somehow, and auto-detect the type of attached drives. A basic solution would auto-configure the card into one of the two modes. A more complex solution would create a hybrid mode that could support Smartport drives and 5.25 inch drives at the same time on different disk connectors.

I’m not sure how to do either of those, especially the hybrid mode, which I think would require some detailed research into how typical software boots and what assumptions it makes about the card it’s booting from. From what I’ve read, some software assumes it’s booting from a Disk II card, and jumps to specific addresses in the card’s onboard ROM to help load sectors during the early boot process. This won’t work if my card’s ROM contains some custom hybrid Liron/DiskII code. Hopefully there’s a clever solution to this, like retaining entry points for Disk II compatibility at a few key addresses in the ROM code.

 
Attaching Drives

What’s the best way to attach drives to this card? It might have a single DB-19 female connector, and support a daisy-chain of several drives, like the built-in disk connector on the Apple IIGS. Or it might have two 10×2 rectangular connectors for ribbon cables, like the connectors on the Floppy Emu and on the Disk II controller card. Or it might even have two DB-19 female connectors.

The 10×2 rectangular connector is probably the best option, simply because female DB-19 connectors are so hard to find. I have a small supply, which I use to manufacture the BMOW Daisy Chainer for Floppy Emu. But pretty soon those will all be gone, and then the DB-19F will be extinct unless somebody wants to spend $15000+ for a Chinese factory to make new ones.

A compromise solution would be to use 10×2 rectangular connectors on the card, but design an optional rectangular-to-DB19F adapter. That way a female DB-19 would only be used where it’s needed. At the moment, that’s only for connection to a Unidisk 3.5 drive or the slim 5.25 inch drives (I forget what these are called… also Unidisk?). Disk II drives and the Floppy Emu use the 10×2 rectangular connector and don’t require a female DB-19.

I mentioned daisy chaining, but I’m not sure how that would be implemented in software. From my work on Floppy Emu, I’m familiar with how daisy chaining is implemented electronically for the drives, but I don’t know how the card’s ROM code detects and keeps track of all the drives in the chain. Daisy-chaining also means moving away from the simple “Slot X Drive Y” scheme to an environment where a disk controller card can have more than two drives attached, which somehow get mapped to other virtual slots. Yes there’s documentation for this, but it’s just one more challenge added to the pile.

 
Firmware Updates

All the interesting parts of the Yellowstone card are implemented in an FPGA, and I expect the FPGA design will be updated over time to fix bugs and add new features. Ideally there should be a way to update the FPGA for a Yellowstone card that’s in the field, without requiring the Lattice design IDE and JTAG programming hardware.

I haven’t confirmed this, but I think there’s a way to export the FPGA firmware from the Lattice IDE as a JTAG player file – basically a sequential list of JTAG commands. Then a stand-alone third-party hardware/software solution should be able to update the FPGA. In this case, that solution could be the Apple II itself. I need to design a way to bit-bang the JTAG signals from the Apple II, possibly using the game port, or even just using the address and data bus. It may be very slow, but it should work. Unfortunately the FPGA can’t help with this, since it will be in the midst of being reprogrammed, and so I’ll probably need to include some additional hardware on the card to support this self-programming.

One drawback of a self-programming approach is that the entire FPGA player file must be small enough to fit entirely in the Apple II’s RAM. It can’t be loaded piecemeal from the disk, because the disk controller will be non-functional while it’s being reprogrammed. This problem could be circumvented by using a second disk controller, but that doesn’t seem very elegant.

 
Support for 3.5 Inch Drives

The biggest unknown is potential support for unintelligent (dumb) 3.5 inch floppy drives, like the Apple 3.5 Drive A9M0106. From a completionist point of view, this would be great, because it would bring Yellowstone support for all three major types of Apple II disk drives. But there are some good reasons to omit it. In brief, it would be very complex and not very useful.

What is useful? While it would be nice to have, I believe there isn’t a strong need for a dumb 3.5 inch floppy controller card like this. If the main audience for the Yellowstone card is the Apple II+ and IIe, there just isn’t very much II+/IIe software on 3.5 inch disks. And even where software is on 3.5 inch disks, it could already be supported using the Yellowstone card in Liron mode with the Floppy Emu in Unidisk 3.5 emulation mode. The only case where dumb 3.5 drive support would be needed is connecting a real Apple 3.5 Drive A9M0106 to a II+ or IIe.

I would add 3.5 support anyway if it were easy, but it’s not. The Disk II card is basically a proto-IWM, and fairly easy to replicate in an FPGA. The Liron card is a full IWM with some extra bits of address decoding and a larger ROM. But the Apple 3.5 Disk Controller is crazy complex with its own onboard 6502 CPU, 32K of onboard RAM, a SWIM, and gobs of programmable logic. I don’t want to attempt replicating something as difficult as that, and I don’t even have an Apple 3.5 Disk Controller to examine. So… no.

A slightly more plausible path would be to follow the example of the Universal Disk Controller (UDC) that was marketed by Laser, VTech, and CPS. The fundamental problem of 3.5 inch disk support on an Apple II+ or IIe is that a 1 MHz 6502 isn’t fast enough to keep up with the bit rate of a 3.5 inch disk. The Apple 3.5 Disk Controller solves this problem by essentially putting an entire second computer on the disk controller. The UDC takes a different approach, using the regular Apple II CPU, but halting it at key times with the RDY signal instead of expecting the code to do busy wait loops. The elimination of busy waiting saves just enough CPU cycles that the 1 MHz CPU can handle the faster bit rate – or so I understand.

The UDC is interesting in that it’s a hybrid 3.5 / 5.25 inch drive controller. But duplicating the UDC would be no simple task. There are two versions, one with a hairy mass of 7400-series logic and the other with a single ASIC. Here’s an image of the “long” version with the 7400-series logic:

I don’t have examples of either type, so my efforts would be limited to examining photos and reverse-engineering the card’s ROM. I spent some time examining the ROM code, and it’s very complex. It appears to be an 8-way bank-switched ROM, with 2-way bank-switched onboard RAM, and it makes extensive use of self-modifying code. Here be dragons.

Help! If anybody has a UDC card they’d be willing to lend or sell, please let me know!

So for the time being at least, Yellowstone will offer Liron support (intelligent Smartport / hard disk) and 5.25 inch floppy drive support. Dumb 3.5 inch floppy drive support might come later as a version 2.0 type of feature.

 
Next Steps

That’s the state of everything as of today. There’s still a tremendous amount of work to do, but I’m happy to be making forward progress again. Do you have any suggestions or advice on where to go next, or how to address some of the challenges I’ve mentioned here? I’d love to hear it – please leave your feedback in the comments.

Read 18 comments and join the conversation 

« Newer PostsOlder Posts »