BMOW title
Floppy Emu banner

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

14 Comments so far

  1. Chris M. December 11th, 2020 10:57 am

    Apple managed to get Smartport and 5.25″ drives working on the same port with the IIgs and IIc. The latter’s hardware design would be a good idea of where to start. The IIc+’s disk electronics were available on card form, but details on if this thing was actually sold is scarce outside of the below photo of the “Universal Controller Card”.
    http://www.retro.co.za/ccc/apple2/disks-and-controllers/

    You will likely have to shadow the Disk II firmware in another slot as both of those machines did (the CFFA3000 does this too). Apple’s other 3.5″ drive controllers like the FDHD card only supported 3.5″ drives and SmartPort drives, no 5.25″ support. They also had a 65c02 on board to handle “raw” drives since the host machine wasn’t fast enough to handle the processing.

    The Laser UDC is notable in that it supported the Macintosh 800k drives without the daisy chain card. (it pre-dated the IIgs) I think it also supported 400k drives too! It does not support SmartPort devices though and will fry them when connected.

  2. Jeff December 11th, 2020 11:14 am

    Switch to a larger FPGA with an open source toolchain capable of hosting a small CPU in gateware. For updates, set a jumper for the board to come up as a USB device (see https://github.com/tinyfpga/TinyFPGA-Bootloader). Downside is the necessary level translators.

  3. Steve December 12th, 2020 8:25 am

    I’m not sure it would be necessary to shadow the Disk II firmware on another slot. The shadowing isn’t ideal, since it means you can’t put another card in the shadowed slot, so a solution that’s all in one slot would be nice. The UDC Introduction Guide implies it requires just a single slot, and my analysis of its ROM seems to confirm this.

    It looks like I was correct that 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 additional boot sectors. But this appears to be limited to a single ReadSector entry point at offset $5C. The UDC ROM has a compatible entry point at offset $5C, even though the implementation is totally different.

    The UDC documentation raises some confusing questions. I’m fairly certain the UDC doesn’t support intelligent drives like the Unidisk 3.5, and other sources say it will damage the drive and the card if you connect them. But the very first paragraph of the UDC introduction guide says “The UDC combines the power of Apple’s Unidisk 3.5 and standard floppy disk controllers into one slot.” And yet the Unidisk 3.5 isn’t listed as one of the supported drive types. It mentions “IIGS platinum drives” – not sure what that means.

    Also on page 2 in the section titled Connecting the Drives, the introduction guide says “you cannot use a daisy-chain connector even if the drive you are connecting has one.” It mentions this again in the last paragraph on page 2. But on page 4 of the UDC User’s Guide there’s a list of allowable drive configurations, many of which include daisy-chain connections.

    The User’s Guide says it supports up to a maximum of 4 disk drives, and recommends installation in slot 5. The Introduction Guide says a maximum of 2 disk drives, and recommends installation in slot 6.

    The Introduction Guide says it also supports Macintosh 400K/800K drives. The User’s Guide makes no mention of Macintosh drive support. Maybe they’re supported but not listed?

    These don’t seem to describe the same card. I’m not sure which version I’ve been analyzing.

  4. Steve December 12th, 2020 9:37 am

    Oooh, some very interesting updates on the UDC! This print ad very clearly states that it *does* support the intelligent Unidisk 3.5 drive, as well as Macintosh 400K/800K drives, and any 3.5 inch or 5.25 inch Apple-compatible drive with a DB-19 connector.

    This directly contradicts some other sources I’ve seen that claim a Unidisk 3.5 drive will fry a UDC card. But it seems the UDC went through several revisions of hardware (long card to short card) and the software in ROM, adding capabilities along the way.

    If this is correct, then later versions of the UDC represent the holy grail of disk controllers, and support all three types of Apple II compatible disk drives. In that case, I should scrap my plans and focus on building a work-alike UDC card. I really need to get my hands on one of those cards! Anyone have a UDC to loan or sell? 🙂

  5. Chris M. December 12th, 2020 3:16 pm

    I would confirm Unidisk 3.5″ compatibility. The manuals only state that the 3.5″ daisy chain drives work (aka the “IIgs platinum drive”/A9M0106 with the daisy chain port). There is a dump of the ROM. That would likely confirm that the card has SmartPort device support (the hardware protocol, not the software protocol).

  6. Steve December 13th, 2020 9:06 am

    I’ve spent a while examining the UDC ROM, and it definitely has support for intelligent Smartport drives like the Unidisk 3.5. Unless it’s non-functional code or there was some hardware design defect, I think the wisdom about UDC cards not working with the Unidisk 3.5 is wrong.

    At this point I think I understand enough about the UDC to attempt building a full work-alike with the Yellowstone hardware, even though I don’t actually have a UDC to experiment with.

  7. Alex B December 13th, 2020 11:20 pm

    Re: firmware updates — is the FPGA from the MachXO2 family? Those should be able to be program the internal flash memory while still running the user logic (from SRAM), i.e. while still being a disk controller. There should also be a way for user logic to access the internal flash, so that it could be written in some in-band way (e.g. extra Apple-accessible registers) without the additional JTAG connection.

    (same principles should work if the bitstream sits in an external flash chip, but easier).

  8. Alex B December 14th, 2020 12:01 pm

    Follow-up on above firmware updates post; references:

    “MachXO2 Programming and Configuration Usage Guide”, see “background programming”: http://www.latticesemi.com/dynamic/view_document.cfm?document_id=39085

    “Using User Flash Memory and Hardened Control Functions in MachXO2 Devices”: http://www.latticesemi.com/dynamic/view_document.cfm?document_id=39086

  9. James N December 16th, 2020 1:56 pm

    I have been searching, for YEARS literally, for an Apple II disk controller that will operate two standard 5.25″ drives and AT LEAST ONE 3.5″ drive (preferably two, and preferably Apple 3.5, but I would settle for even a single UniDisk 3.5) from a single slot, while avoiding any “phantom” slotting techniques that interfere with other peripherals in other slots. The goal in my head was to be able to access the enormous library of standard Apple II 5.25″-based software via a Disk II-compatible controller that would ALSO allow access to a 3.5″ drive – even if that 3.5″ access was just under ProDOS – without burning another entire slot for JUST that function (a la Liron).
    I have tried all of the reasonably available controllers, and even one UNreasonably available, and I am still short of that goal.

    I have one of the VTech UDCs, but it is *far* from an ideal solution, and IMO using it as a template to clone from without explicitly removing its shortcomings would be an unfortunate choice.
    – It DOES NOT support UniDisk 3.5 drives. At all. In fact, attaching a UniDisk 3.5 to it will DESTROY both the UDC AND the drive.
    – It also has serious limitations on HOW the drives are connected to it (you MUST put Apple 3.5s first, and you MUST split your devices 3-and-1 across its two ports, not 2-and-2).
    – Finally, it PRIORITIZES the 3.5 mechanisms, so if you install it in slot 6, your S6D1 device will always be one of the 3.5s connected, NEVER a 5.25. This makes it fundamentally useless for 5.25 compatibility, unless you maintain another entirely separate controller for the 5.25s, which defeats the original purpose. Or at least MY purpose: a single slot with a unified controller.

    The only controller that has succeeded for me is an OKS MultiKache card. It’s more of the “whole-computer-on-a-card” design, much like the SuperDrive controller, and it has lots of whiz-bag caching features that I really don’t need, but it WORKS. It successfully operates two 5.25″ drives, two UniDisk 3.5s, AND two Apple 3.5s. ALL SIX on a single DB-19 chain! It prioritizes the 5.25 mechanisms, and maps them to slot 6, and the 3.5s to slots 5 and 2 under ProDOS, all automatically and without quirks or complaints. It even has a 100%-Disk II-compatible mode invoked by “IN#6″ that deactivates ALL of its caching features and 3.5 capability temporarily for full backwards-compatibility with the original Disk II controller. Unfortunately, mine has developed some sort of problem, and the OKS cards are about as rare as winning lottery tickets and have a price tag to match.

    Steve, it’s clear to me that you know more about the various Apple II floppy disk subsystems than virtually anyone. It’s very likely that you’re the only person capable of making a controller to do what’s being talked about here. If you honestly want to press forward with this design, AND you reasonably expect you can do so avoiding/removing the shortcomings, I’d be happy to loan BOTH a UDC *and* an OKS MultiKache (in need of hopefully minor repair) to the project.
    All I would want to see materialize (and it FEELS like it should be a straightforward request, but what do I know?) is a single-slot Apple II disk controller that will:
    – Occupy a single slot, presumably 6
    – Operate two 5.25” drives from slot 6 as if it was a bog-standard bootable Disk II controller (without “bumping” the 5.25s and making the 3.5s take over as the slot 6 devices)
    – ALSO operate one or more 3.5 drives of either type (Unidisk 3.5/Apple 3.5), even if only under ProDOS
    – Not interfere with the operation of any peripherals in any other slots
    – SmartPort HD support or any other more advanced capability would be an unexpected, but happy bonus

    Is it possible the YellowStone could make this dream come true?

  10. Steve December 16th, 2020 4:25 pm

    The MultiKache sounds like a powerful card – I hadn’t heard of it before. I’m still inching forward on this, but there’s a long way to go, and I’m not sure if I’ll make it to the end. My focus now is to understand and duplicate the functionality of the UDC.

    I’m puzzled by the information about the UDC and Smartport drives like the UniDisk 3.5. The UDC ROM appears to have code for a full Smartport implementation, and I’ve examined it in detail. I’ll verify it if I ever get a functioning replica, but I expect it to work fine.

    Some things like the “must put Apple 3.5 first” rule are a result of how drive enabling works, and will be true of any disk controller. Because 5.25 inch drives were the first type designed for the Apple II, they don’t know anything about the possible existence of 3.5 inch drives. If you put 5.25 inch drives first, they will respond when the computer tries to communicate with the 3.5 inch drives. The 3.5 inch drives have 5.25-awareness, and will block signals from traveling downstream to any attached 5.25 inch drives when appropriate, hence they must come first.

    There were many different versions of the UDC card with different capabilities and behaviors. You can read the version number at address $Cs15, where s is the slot number. The ROM I’ve been examining is from version $23, or 35 decimal, which I think means it’s version 3.5.

    I rather like the UDC’s two-connector design, because it provides lots of options. If you want a big daisy chain of drives, you can hang them all off connector 1. If you want to connect two drives that don’t support daisy chaining, you can hang one off CON1 and the other off CON2. Only CON1 supports daisy chaining, so you can’t have a 2-2 split of drives on the connectors. If you look in detail at how the IWM’s sole disk selection signal is multiplexed between the connectors, you can see why this is necessary. Sure it would be great to have two full daisy chains, but no card that I know of offers that.

    I don’t think the UDC prioritizes 3.5 drives exactly, but it prioritizes connector 1 over connector 2, and it prioritizes the first drive in a daisy chain over later drives. The IIGS (and sounds like the MultiKache too) maps the 3.5 drives to slot 5, and the 5.25 drives to slot 6, so you can have two different drives both be drive 1 on their respective slot, and both bootable. The UDC seems to map everything to slot 6 in the normal case. The manual says the behavior is different if the card is installed in slot 5, but I’m not sure why.

    I’ll have to verify the behaviors about drive priority and drive/slot number mapping once I get something working. Those behaviors are mostly determined by the ROM code, and so would be more likely to differ between versions. With luck they can be modified or extended. I’m not sure where the limitation of 4 drives in the chain arises, but I think it’s also ROM code. The code I’ve been examining actually seems designed for a maximum of 5 drives.

    Some of your wish-list items may be mutually incompatible, if I’ve understood correctly. If the card is physically installed in slot 6, 5.25 inch drives are mapped to slot 6, and 3.5 inch drives are mapped to slot 5 or 2, doesn’t that interfere with other peripherals that may be in slot 5 or 2? I’m not sure it’s possible to have more than two disk drives on a single drive controller without somehow impacting other slots, since they have to get mapped somewhere. But maybe it’s possible with some magic ProDOS shadowing – I haven’t looked into this.

    Thanks for a thought-provoking question. Most of these issues are still well in the future. For now I’m still trying to get disk writes working for the Disk II controller mode, and hoping to get something concrete working for UDC emulation. We’ll see where it goes from there.

  11. James N December 16th, 2020 5:22 pm

    I’ve tried to reply to continue the conversation here three times now without success. Is there another forum where this discussion can continue? I would like to respond to your response with additional information.

  12. Steve December 16th, 2020 6:15 pm

    There’s a maximum length limit on comments that you may be hitting. Otherwise you’re welcome to contact me directly using the Contact link at top-right.

  13. Mac December 22nd, 2020 11:41 pm

    This may affect your bios. Timings and early 65816. Not my work. But may help in the iigs.
    Thank you for your wonderful work.

    http://forum.6502.org/viewtopic.php?f=4&t=5196

  14. Mac December 23rd, 2020 11:06 pm

    Here is a bit more on early 65816, more timing issues. Only on the earlier version.
    Not sure that you had seen this already.
    But a 250 ms wait? Oh oh

    http://forum.6502.org/viewtopic.php?f=4&t=5196

Leave a reply. For customer support issues, use the Contact page instead of comments.