FPGA-Based Disk Controller for Apple II
Apple II disk controller cards are weird, there are a crazy number of different types, and many are rare and expensive. Can an FPGA-based solution save the day for retro collectors? You bet! Nearly all the existing disk controllers connect the same 8-bit bus to the same 19-pin disk interface, so a universal clone is merely a question of replacing the vintage 80s guts of the card with a modern reprogrammable FPGA. This hypothetical universal controller card could connect to almost any Apple II disk drive, or a Floppy Emu. Here’s my first attempt.
An Idea Takes Root
This project has been nearly finished since August, but I’d hoped to delay announcing it until it was 100% done. Back in July there was a surge of interest in the Liron disk controller, when I updated the Floppy Emu firmware to add Liron support. For the first time, it was now possible to emulate a 32 MB Smartport disk on an Apple II, II+, or IIe with the Floppy Emu. But only Liron card owners could benefit, and the Liron card is fairly obscure and difficult to find. People started asking about the possibility of a Liron clone card, so I went to work.
Mapping out the complete schematic of the Liron took a couple of days. It’s a single IWM (the famous Integrated Wozniak Machine), combined with a small number of standard 7400-series logic chips, and a ROM to hold the boot code. Writing Verilog code for the FPGA to duplicate the 7400 chips’ functions was easy. Creating a Verilog reimplementation of the IWM was harder, but with the aid of the IWM spec and a logic analyzer I got it done. By selecting a moderately roomy FPGA, I was able to incorporate the boot ROM functionality too, so no actual ROM chips are needed. The entire design boiled down to some 3.3V level converters and a single FPGA, with a bunch of connectors and passive components. I realized the design wasn’t limited to being a Liron clone, but could also probably be a Disk 5.25 or Disk 3.5 controller with just a change of firmware. Maybe even a UDC controller. Ooh, the possibilities!
Hardware
I worked like mad to finish the design in late July, just before a trip to Yellowstone National Park, which gave this project its codename. The core of the prototype board is a Lattice MachXO2 FPGA, specifically the LCMXO2-1200HC. This 100-pin bad boy has 1280 LUTs for implementing logic, and 8 KB of embedded block RAM to serve as the boot ROM or for other functions. It also has some nice features like a built-in PLL oscillator and integrated programmable pull-up and pull-down resistors. Unlike some FPGAs, the MachXO2 family also has built-in flash memory to store the FPGA configuration, so it doesn’t need to be reloaded from an external source at power-up. The FPGA can be programmed through a JTAG header on the card.
The external disk is connected to the card with a standard 20-pin ribbon cable, just like what you’d find inside an Apple IIc, or on the Floppy Emu. In fact for the Floppy Emu, you can connect a 20-pin ribbon cable directly from the Emu to the FPGA card, with no DB-19 required. For other external disk drives, I built a small adapter that converts a short length of 20-pin ribbon cable to a DB-19 female connector.
Because the FPGA’s maximum supported I/O voltage is 3.3V, but the Apple II has a 5V bus, some level conversion is needed. I used four 74LVC245 chips as bus drivers. These chips operate at 3.3V but are fully 5V tolerant, and the Apple II happily accepts their 3.3V output as a valid logic “high”. One of the chips operates bidirectionally on the data bus, and the others handle the unidirectional address bus and control signals.
There’s a tiny 3.3V voltage regular on the board, which you can see at the lower-right at U3. It’s barely any bigger than a 0805 size SMD capacitor. Even with these small components, I was still able to solder the entire prototype board myself by hand.
Just for grins I added a 2 MB serial EEPROM to the board, which you can see at U2. 2 MB is enough to store 14 disk images of 5.25 inch disks, or a single larger disk image. It’s not central to the design, but if it works then the card could function as an all-in-one virtual disk like the CFFA3000, in addition to functioning as a disk controller for external drives. More options!
Status
Here comes the embarrassing part. After July’s spurt of activity, the PCBs and parts arrived in the mail. And then I did…. nothing. Finally in October I assembled one prototype board, stuck it in my Apple IIe, and played with it for a bit. But since that day I’ve done…. nothing. I’m struggling with some internal dilemma about the balance between a hobby and a business, and doing things because I want to or because I think I should want to. I’m hoping that by publishing this summary, I may spur myself into further action.
The prototype board works as far as I’ve tested it, but that’s not very far. I verified that I can program the FPGA via JTAG, and that it responds to address and data on the Apple II bus, but that’s about it. I haven’t yet looked at what it’s doing on the external disk interface, or tried connecting a real drive. My attention has just been focused on other things, and even though I always mean to return to this project “soon”, somehow I never do.
There’s at least one serious bug with JTAG programming that needs to be addressed. When the board is outside the Apple IIe and powered from a separate 5V supply, JTAG programming works fine. But when the board is actually inserted in the IIe and powered from the slot, JTAG programming doesn’t work. It always fails with a communication error. I thought this might be some kind of noise or poor signal integrity on the JTAG traces when the board is in the IIe, but the traces are quite short and don’t cross any other signal traces that might carry interfering signals. I also thought maybe I had power problems, and the IIe’s 5V supply was drooping briefly when I tried to program the FPGA via JTAG. But as far as I can tell with a logic analyzer’s analog functions, the 5V and 3.3V supplies remain stable. It’s a mystery that will require some better tools and more careful testing.
Next Steps
What’s next for this FPGA disk controller, assuming I ever finish it? Will it become a new product in the BMOW store? That was certainly my original plan, although my lack of motivation these past months has cast some doubt on that idea. I want to keep fun hobbies fun, and not have them become an obligation and a chore, which I fear is already happening with the other retro computer gizmos I’ve developed in the past few years. We’ll see how it plays out.
Assuming this eventually becomes a new product, how will users reprogram the FPGA in order to clone a different type of disk controller? It’s not reasonable to expect that everyone will own a stand-alone JTAG programmer and know how to use it. Unfortunately I can’t see any alternative solution that wouldn’t require extra hardware and complexity, and push up the cost of the board. I might add a microcontroller and an SD card socket for loading alternate firmware, but that would be a fairly ridiculous amount of extra baggage if it were used only for JTAG. Perhaps the Apple II itself could be used as a JTAG programmer, with some extra hardware that optionally bridged the data bus to the JTAG interface? Sounds complicated, and it would leave the question of how to get the firmware onto the Apple II first. Or maybe the user could choose between a few different built-in firmwares using a switch, but would be unable to load new ones? That sounds more plausible, but would mean a bug in the firmware couldn’t be easily fixed.
Fortunately those questions can wait. The first priority is to finish debugging the prototype, connect it to some real disk drives, and verify that it works. Maybe by Christmas…
Read 38 comments and join the conversation38 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
I know that feeling exactly. I have a hobby product on Tindie and have thought about it a lot and want to update it but have no motivation. I’ve also had long spurts where I don’t want to do any hobby electronics at home (my day job is EE). Eventually my desire to play with circuits comes back and I start something new. I wouldn’t force finishing the project. Your happiness is worth more than this project is to anyone out there. If you decide you don’t want to finish it, it would be nice to open source your efforts so maybe others can. In my experience, it’s not going to hurt your sales if you do come back and try to finish it someday (unless someone tries hard to make a business out of your product – but you can add a license to disallow that).
Any chance it will support 1.4MB high density Superdrives? The Apple II 3.5 Controller is ridiculously rare and expensive. The CFFA3000 has the ability to update its FPGA, but it already has an obvious storage location for the firmware files.
In theory it could clone the Apple 3.5 Superdrive controller, yes. It would be difficult though. I believe that card has an on-board 6502, so a soft-6502 would be needed in the FPGA. So far I’ve only looked at the Liron clone configuration in detail.
CFFA3000 is more similar to the Floppy Emu: both combine an Atmel microcontroller and a small Xilinx CPLD with a slot for modern SD card / CF card / USB storage. The Yellowstone card described here is quite different, and is a controller card for a real external disk drive. It doesn’t have any microcontroller or modern storage media connectors. The hardware design is much simpler, and it should cost less (assuming reasonable sales volume for economies of scale).
Maybe your JTAG issue is caused by a ground loop. Have you tried programming it with a laptop on battery?
Any chanch you could have these ready for KFEST? If you do, I want to buy one.
If you’ve got storage space for disk images it might be neat to have a way to directly read/cache a real disk into there and a mechanism to swap between real and virtual disks. That way if you like real disks, but have limited patience you can minimize swaps. When you want to use a program you could load the program in and then just swap once to a data disk.
Might also conveniently allow you to use 1 drive like 2 or 2 drives like 4. Is there any limit on the number of drives it can present. I thought regular controllers could only handle 2 drives per card?
I second Ferdinand Keil’s comment. With Yellowstone installed in the Apple IIe and the JTAG wires disconnected, what potential do you measure between the Apple IIe and JTAG grounds with everything powered on? I’ve run into a few odd grounding issues like this myself. You may need to the a USB isolator (http://www.linear.com/solutions/5123).
Also, I am assuming JTAG VCC is an input to the HW-USBN-2A. Looks like it is on the HW-USBN-2B.
Thanks for the suggestion. It could be a ground loop, but I’m a little bit skeptical. The Apple II and the PC with the JTAG programmer are both connected to the same wall outlet. I’ve had no problems using the same Apple II and PC with an AVR programmer for a Floppy Emu powered from the Apple II. But I will measure it to be sure. Yes, the VCC is an input to the JTAG programmer, it uses it to sense when there’s a device connected and to determine what voltage level to use for JTAG I/O.
I know that on desktop PCs the chassis, and in turn the USB shield, is connected to safety ground. If the IIe chassis is also connected to safety ground, you could have a situation like this even if you’re connected to the same outlet with any length of power cable (see first figure under “Sources of ground current”):
https://en.wikipedia.org/wiki/Ground_loop_(electricity)#Sources_of_ground_current
Placing the IIe on an isolation transformer would be a good data point to rule this out or not. I’ve also seen people float or remove safety ground pin all together, but I cannot condone that as a permanent solution.
Hi Steve!
This project is great! The possibility to add a Liron or a 3.5 floppy controller to an Apple II is something I’ve been wanting for a long time. I hope you find the motivation to finish it.
Thanks again for supporting the Apple II community.
nice project.thanks for sharing with us http://www.icartoonhd.com
This sounds fantastic! I have one FloppyEmu and considering buying another – flashing between my Apple //e and Mac Plus takes the fun out of it. This would seal the deal and I hope there’s a bundle to buy the card and an Emu. Best of luck solving your issues and if released I’m a buyer for sure!
I would definitely buy one if you make them, and I actually have a LIRON card. It seems like the perfect companion for my FloppyEmu, which I love, BTW.
I understand about finding time and motivation for hardware projects for retrocomputing. I also dabble in it a bit and I have several projects that are in various stages of completion that I need to finish up one of these days. I’m really more of a software guy, and you are way ahead of me as far as building hardware goes. I have a basic understanding of how to design stuff for Apple II, Arduino, etc., using basic TTL and CMOS devices. I’m currently learning how to lay out PCBs with modern software to get them fabbed. Once I get that down I will start learning how to create GALs as I already have a programmer that will do that (Minipro TL866CS). After that I want to get an FPGA dev kit and learn Verilog and/or VHDL. I’ve been looking at the Altera Cyclone IV or maybe the Xilinx Spartan 6. I’m leaning towards the Altera as it is less expensive and has a reputation of the software being easier for beginners.
Steve
What a great board and excellent idea, I know you talked about it not being fun and I hope this changes for you, I want you to know that you have made some amazing things that make it so people like myself get to relive our childhood enjoyment of these machine with a low cost and ease use. So be proud that made excellent things that have brought 100s of people great joy.
I will buy one of your cards in a second, I agree with Chris M. in the comment support for High Density would be amazing. In my case it’s an AE HD+.
If you get to implement the CFFA style image storage please talk to John Morris and make it so that it will support the new format that he is working on .WOZ.
I hope you find the happiness and motivation that you look for in this project and any others in live that bring you happiness.
Cooper
Nice work Steve 🙂
I’m wondering if you’ve ever had any thoughts about tackling the world of IIGS CPU accelerators?
Would be glad to be a beta tester…:p
Steve, I hope you find the motivation to finish this amazing project and the enjoyment of knowing how much you’ve helped the Apple II community already with your floppy emu and other gizmos. I know that you know how much everyone would love to see an alternative to the super rare and expensive Liron controller and to have support for other drives and all the other features you mentioned. Wow! I’d buy this card in a heartbeat. Thanks for all your efforts to help keep our hobby alive.
This is a great idea!
I like the idea of multiple firmwares that are switch (or software switch) selectable.
For instance, what’s sorely lacking in slotted Apple-II machines is a Smartport – something that you could plug an Apple 3.5, Unidisk 3.5 or other mass storage device into. The IIc and IIc+ have a smartport that’s awesome, but not the II+ and //e.
If I were to give my vote, it would be for a Disk-II / Liron / Universal Drive Controller (a-la Vtech’s) that could run any common physical disk drive. Plus added functionality for mass storage via SD-card or CF card volume images.
I’m sure I’ll make more progress on the prototype, hopefully soon. I’m less sure about turning it into a finished product, but we’ll see. As I mentioned above, my biggest concern is the lack of any simple way to update the firmware on the card. So it would either be non-upgradable (and pray there are no bugs in the 1st revision firmware), or would need extra microcontroller and SD hardware solely for firmware updates (increasing complexity and cost).
I have no problem with it requiring an extra programmer tool to update. I have a JTAG tool and a Minipro TL866CS which I can update to add an ICSP port and I’m thinking of buying an Altera Cyclone IV dev kit which includes a USB blaster… If I had to buy another tool it wouldn’t be the end of the world either.
It would be a shame given the scarcity of LIRON and UDC cards at least if this wasn’t released. Even if the only functionality was to act as a replacement for those it would be worth it. And if it can do more all the better. As I said before, this looks like pretty much the perfect complement to the FloppyEmu. If you make it I for sure will buy at least one, and I already have both a LIRON and a UDC.
If you wanted to make things more interesting… I don’t know how much space and pins you have left on that FPGA… but I think there would also be a demand for a WD17xxx compatible controller to handle PC and/or CP/M style floppy drives with the 34 pin interface.
Or another idea is 4 floppy ports like a Rana Systems controller… Probably of extremely limited utility these days, but I always liked those controllers (have one of those too).
No possibility of uploading firmware via the Apple slot then?
The firmware might be large enough that it would be hard to deal with on the Apple II side. Anything that won’t fit on a floppy may be difficult for some people to manipulate. I would guess that the image for an FPGA could be megabytes? Or am I way off?
I would say the majority of people would not have any issues loading a file size larger that 1mb….
Floppy EMU……or maybe this would give them a hint to pick one up….
Firmware flashing from inside the Apple II is theoretically possible, but would involve some difficulties as described in the post. The card would need additional hardware to somehow multiplex the data bus and the JTAG interface. Then once the user downloaded new firmware from the web, how would he get it onto his Apple II? He’d need to own some *other* disk solution already, like a Floppy Emu or CFFA3000. Then where would he store it? It’s about 350KB now, and will probably grow over time, so it’s too big for a floppy. But if you could overcome all that, and the cost of the extra hardware on the card, then you could probably write JTAG player software for the Apple II that would perform the firmware update.
Having thought about this some more, I don’t really like that approach because it seems so cumbersome. So the two most plausible approaches are:
1. Add an extra microcontroller and USB interface, purely for firmware updates.
2. Keep the JTAG interface as the only avenue for firmware updates. The typical user wouldn’t be able to perform firmware updates, so the card would effectively be a fixed-function device (maybe with a switch to select a few different functions).
But this is all getting ahead of myself, since I haven’t even proven that the card works yet. 🙂
I’d rather have the JTAG option than add a lot of extra complexity and price to the card. But that’s maybe just me. As I’ve said before I already have a JTAG programmer and if I needed to buy another programmer it wouldn’t be a big deal as long as it isn’t super expensive.
I think any generic JTAG programmer would work, or maybe even something like a Bus Pirate. I haven’t tried any non-Lattice programmers yet though.
The JTAG programmer I have is a very generic one sold for doing things like installing a bootloader on Arduinos. I think I paid under $10 for it. I don\’t know about the Lattice programmer, but the ones for Altera (USB Blaster) aren\’t very expensive, under $30. I just checked; the Lattice ones are around the same price range. Not out of line if I ever needed one and the one that I have didn\’t work for some reason.
why not just make it universal and make it an apron? inthink more people would have this than the jtag..
stupid autocorrect..
I meant to say why not make it universal and make it eprom? methinks more people would have this burner than the jtag….
I don’t think that will work. I have an EPROM programmer (Minipro TL866CS), and I don’t think it is compatible with an FPGA. I suppose you could put an EEPROM on the board and load the FPGA from that somehow, but that is just adding more components and complexity and cost to things.
You could still be having power problems even if the power supply is doing fine. The slot only has one pin for each voltage, including ground, and it’s not always enough. A sudden change in power consumption can raise the level of ground just as much as it could lower the level of a power rail and you might not even notice, depending on where you connected your probe. See IIgs technical note #68 under “ground noise” (even though it’s a GS tech note, it’s not a GS-specific problem).
It looks like the maximum size of the configuration data for this FPGA is about 40K, so it will fit into the memory of the Apple II. I would recommend using the Apple\’s GPIO port, I mean game port, to program the FPGA via SPI. You\’ll need a dip cable (digikey has these) and potentially another level shifter, but should still be less than a jtag programmer.
If I\’m dumb and for some reason the configuration data is bigger than I thought, according to the datasheet you can even reprogram the device while it\’s in use, so assuming it is working at all, you could conceivably have up to 800k of configuration data for it.
All this said, while it\’s obviously far more awesome to update the FPGA via the Apple if you can, a JTAG programmer only costs $20 on fleabay, and a bus pirate is only a little more. So there\’s no shame in asking your users to get one if that\’s what has to happen.
I prefer the JTAG approach to upgrading the firmware. I’ll go even one step further by suggesting a pogo stick pin approach to updating the firmware. Many projects now use this approach to update firmware. All you need to do is develop the adapter for those who want to update the firmware. Making the JTAG pads on the board costs zero.
I’m a happy FloppyEmu user and I’m just getting new interest in HW and fpgas while discovering the Apple //e internals that I ignored 32 years ago… Well i was 13 but I had “Assembly lines” on my bed side table 😉
So please forgive my question if this makes little sense…
Wouldn’t that design be a great base to do some kind of lower cost “carte blanche” ?
With an fpga solution like yours wouldn’t it be possible to reprogram the card to act like say a super serial ? Or a super super serial to allow greater speed and eventually allow DMA transfers ?
On the upgrade aspect if a lattice ispDownload programmer is $20 from china, it might not be worth the pain and time to embed all this logic on the board…
An idea for the firmware update from the A2. Without having any other solid state disk products: ADTPro’s virtual drive support. 800k floppy support, but it’s actually a file on a modern computer hooked up as the ADTPro serial server. Yes, additional, maybe, hardware is needed, but it’s still vintage gear, and may already be present and not needed to be bought, the Super Serial Card. I’d say most eventually get the ADTPro route working in order to bring disk images to thier real A2 floppies. So for firmware flashing through this route would have an upper limit of 800k of virtual disk space to work with. Just a thought.
I need this. Here we are in 2020 without any news. 🙁
https://www.bigmessowires.com/2019/01/28/yellowstone-goes-open-source/