BMOW title
Floppy Emu banner

Archive for the 'Floppy Emu' Category

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

Floppy Emu and the Apple Pippin

Remember the Pippin, Apple’s ill-fated attempt to enter the video game market? The hardware was effectively a modified Macintosh, running a customized version of System 7.5. The Pippin lacks any standard floppy disk connector (internal or external), but it does have a proprietary PCI-based docking connector for expansion. 20 years after its release, Pierre Dandumont has developed an adapter for the Pippin’s docking connector, making it possible to attach a Floppy Emu disk emulator. And it works!

During the Pippin’s lifetime, Apple and Bandai sold a floppy adapter for the console, and many games can use it. Pierre describes the official accessories on his blog here (French language). These accessories are very rare. Working with a colleague, Pierre made a copy of the PCB inside the official adapter, which is now available on OSH Park.

Pierre has also been busy with other floppy hacking exploits. He successfully added a Floppy Emu to a first generation Bondi Blue iMac, which famously lacks a floppy connector – it was the first Macintosh without a floppy. Apple included an unpopulated connector footprint on the motherboard, so with a little bit of soldering and the proper ROM, the iMac can have a floppy drive where it never did before.

Here’s the explanation from Pierre:

I’m a big fan of Macintosh, and when I discovered the Floppy Emu, I decided to order one. I used it in old Macs to transfer some data, play Prince of Persia or retrieve data without going through a network. Like all buyers, I guess.

But on my blog, the Journal du Lapin (mostly in French, sorry), I like to show hacks, or curiosities. I had sent some of my tests to Steve and he offered to publish here.

 
The Pippin

For those who do not know the console of Apple and Bandai, it is a game console released in 1996, and very few copies were sold (about 40 000). Apple offered an optional floppy drive, which was to be placed under the console. It contains a simple PCB with a standard 20-pin connector. With a friend, we designed an adapter and then I plugged the Floppy Emu on the console. Some games allow you to save data on a floppy disk rather than on the internal flash memory (128 Kb). For example, it is possible to save images from a Dragon Ball Z game.

 
The iMac Bondi Blue

More amazing, the iMac. The first iMac (Bondi Blue, in 1998) did not officially have floppy drive, but Apple had left the traces of a connector on the motherboard. Obviously, the drive had been planned until a rather late date in the development of the iMac.

So I opened my iMac, soldered a 20-pin connector and connected the Floppy Emu. With the appropriate version of Mac OS, it works perfectly and it is possible to use the floppy drive with an iMac. In practice, it works with Mac OS 8.1 (the original system) and Mac OS 8.5, but not with Mac OS 8.6 or Mac OS 9 (and of course Mac OS X). Apple has actually blocked the floppy drive directly into the ROM from version 1.2. The iMac is the first Mac with a NewWorld architecture, that is, it uses a “ROM” that is loaded from the hard drive, while the previous Macintosh used a real ROM, that can not be easily updated. Since Mac OS 8.6 was delivered with a 1.4 ROM version, the floppy drive does not work with this version of the OS.

In both cases, the Floppy Emu perfectly replaces a conventional floppy disk drive and greatly simplifies testing. Thank you Steve for your work.

Great stuff!

Read 3 comments and join the conversation 

Unidisk Firmware Update for Floppy Emu

I’ve updated the BMOW Floppy Emu disk emulator firmware, adding new Unidisk and Smartport features for the Apple II family. After some quality hacking time with a Unidisk 3.5 drive and a logic analyzer, the hardware secrets were finally revealed! Thanks to Roger Shimada for providing the Unidisk to make this possible. Here’s a rundown of what’s new:

Unidisk 3.5 Emulation – The Floppy Emu can now emulate an 800K Unidisk 3.5 drive. Because the Unidisk uses the Smartport communication protocol, this new mode is very similar to the existing Smartport hard disk mode, with a few key changes. Unidisk 3.5 mode disk images are always 800K. They can be selected from a menu and ejected when needed, just like the other floppy emulation modes.

Apple IIc owners will probably get the most benefit from Unidisk 3.5 mode, because it’s the only 800K drive type supported by that machine. Apple IIe owners with a Liron disk controller may find it useful too, as well as anyone with an Apple IIe PDS card for the Macintosh LC. Unidisk 3.5 mode also works on the Apple IIgs, but the existing 3.5 inch floppy mode for the IIgs offers the same functionality with faster i/o speed.

Unidisk 3.5 Daisy Chaining – The new firmware also enables a Floppy Emu to be daisy-chained behind a real Unidisk 3.5, when the Emu is in Smartport or Unidisk 3.5 emulation modes. Unfortunately, to gain the benefit of this change, an external hardware modification is also required. If you have an urgent need for Unidisk daisy chaining, see the cable-hacking suggestion in the comments of the linked post.

Unidisk/Smartport Cold Boot Speedup – The Floppy Emu initialization delay from power-on to ready has been dramatically improved for Unidisk 3.5 and Smartport emulation modes. This makes it possible to cold-boot an Apple IIe directly from an Emu attached to a Liron card. Previously it required a warm start or PR#7 command to reinitialize the Smartport once the Emu was ready, but that’s no longer necessary. This change may also help cold booting from Smartport on the Apple IIc+, which was hit-or-miss with the old firmware. I don’t have a IIc+, so please let me know how it fares with yours.

 
Get the Firmware

Firmware 0.1X contains all three new features described above. The Unidisk 3.5 emulation required major code changes which may have impacted other features, so if there’s a problem I’ve also included firmware 0.1V as an alternative and fallback. 0.1V contains only the daisy chaining and cold boot speedup features.

Floppy Emu Model A – apple-II-0.1X-F20
Floppy Emu Model B – apple-II-0.1X-F21-modelB

Try version 0.1V if you have trouble with 0.1X
Floppy Emu Model A – apple-II-0.1V-F20
Floppy Emu Model B – apple-II-0.1V-F21-modelB

Read 8 comments and join the conversation 

Unidisk 3.5 Daisy Chain, Sad Trombone

The Unidisk 3.5 is an 800K floppy drive for Apple II computers, using the Smartport protocol to communicate with the Apple II. The BMOW Floppy Emu disk emulator is also capable of emulating a Smartport disk, so in theory it should be possible to plug the Emu into the Unidisk’s daisy chain port, and use them both together. Unfortunately it doesn’t work, for reasons that weren’t clear until recently. The good news is I now understand what’s going on, but the bad news is it’s probably impossible to make it work without hardware modifications.

Smartport is a bus-based protocol. Each disk is assigned a unique address at startup, and it should only respond to commands for that address. The original Floppy Emu firmware for Smartport was intelligent enough to do that, but it contained some implicit assumptions that were wrong in a daisy chain situation with multiple Smartport drives present. Fixing those was the first task. For example, it would ACK the receipt of any Smartport command, even if it didn’t actually respond to it because it was for the Unidisk. It would also enable its output on the READ and HANDSHAKE lines whenever any Smartport drive was enabled, interfering with the Unidisk.

 
Address Assignment

After resolving those problems, daisy chaining still didn’t work. The logic analyzer showed that the Floppy Emu was never even assigned a Smartport address. Here’s the telltale trace:

The first set of squiggles there on WRDATA (channel 08) is the computer assigning address 1 to the Unidisk with an init command. The following squiggles on RDDATA (channel 07) are the Unidisk’s reply, which is “OK, and there are no more Smartport devices after me”. The next command on WRDATA is a request to read sector 0 from the Unidisk, so Floppy Emu was completely ignored.

Determining what those squiggles mean is a tedious process. I have to zoom in until I can see each positive and negative transition of WRDATA. Every 4 microseconds there will either be a transition (a logical 1 bit) or there won’t be any transition (a logical 0 bit). I have to write down the bit sequences, frame them properly into bytes, and then consult the Smartport spec to make sense of it all. Maybe someday I’ll write an automated tool to do all this, which would make the debugging process dramatically faster. For now I’m happy simply to graph all the signals, because there was a time when I didn’t have even that much.

So why doesn’t the Floppy Emu get assigned a Smartport address? If I were designing the Smartport protocol, I would probably have it send as many init commands as necessary to give addresses to all the drives. Just keep sending init commands, incrementing the address each time, until all drives have received an address and no more init responses are received. But Apple chose a different solution, where each Smartport device is expected to know definitively whether or not there are more Smartport devices behind it in the daisy chain.

 
Input Becomes Output

Apple used a sneaky trick to accomplish this. On the DB-19 connector, pin 16 is normally an input to the disk called HDSEL, which is used to control non-Unidisk 3.5 inch drives. But on the Unidisk 3.5 (and presumably other Smartport devices) pin 16 of the male connector is tied internally to ground. On the Unidisk’s daisy chain output connector, pin 16 has a 2Kohm pull-up resistor to 5V. Internal logic senses whether pin 16 on the daisy chain connector is low (another Unidisk or Smartport device is daisy chained, and its internal ground connection pulled pin 16 low) or high (no Smartport device).

Turning a disk input into a direct ground connection is dangerous. It means that if the computer tries to drive a high value on HDSEL, and a Unidisk 3.5 is connected, it will create a power to ground short and likely fry the disk controller. This will happen for certain if a Unidisk 3.5 is connected to a Macintosh. The Apple IIc and the Liron disk controller don’t connect anything to HDSEL, so they’re safe. The Apple IIgs does make use of HDSEL, but its schematics reveal a 470 ohm inline resistor to protect against a power to ground short. I’m not sure about other disk controllers like the Apple 5.25 controller or the Duo Disk controller. The Disk II controller has an incompatible 20-pin connector, but if you used the Floppy Emu’s adapter cable to connect a Unidisk 3.5 to a Disk II controller, it would directly connect +5V to ground. Ouch!

This kind of I/O switcheroo seems like a very bad idea to me. Ideally, you could plug any kind of 19-pin Apple drive connector into any kind of 19-pin controller, and the worst that would happen is it wouldn’t work. But Apple created a situation where you can actually destroy your equipment by doing this. It’s not the first time, either. Pin 4 was similarly repurposed, from a ground connection on Unidisk 5.25 and Unidisk 3.5, to a drive input signal on the Apple 3.5 drive. And pin 10 is a drive input for Macintosh and Lisa, but an output for Apple II drives.

 
An Unintended Voltage Divider

The Floppy Emu’s CPLD can be reconfigured to treat pin 16 as an output when in Smartport mode, with an output value of zero, to simulate a ground connection. Setting aside the potential for damage this presents to a Macintosh connection, it should get the Unidisk to recognize there’s another Smartport device on its daisy chain connector. Unfortunately it doesn’t work. Ironically it’s the CPLD protection resistors that were added in Floppy Emu Model B that cause the problem, by creating an unintentional voltage divider with the Unidisk’s pull-up resistor on pin 16.

All of the Model B’s CPLD inputs have a 1K series resistor to help protect against voltage spikes and static. This is fine when the inputs are actually inputs:

The CPLD input buffer draws only a few microamps of current. From V = IR, we can calculate that the voltage drop across the resistor will be a few microamps times 1K, or a few millivolts total. If the computer drives a 5V input signal, the CPLD will see something like 4.99 volts, which is fine.

Things are quite different when the input becomes an output, and that output has a relatively strong pull-up resistor:

Now there’s a path through the two resistors, from 5V to ground. From the voltage divider rule, we can calculate that the voltage at the point between the two resistors will be 1.66 volts. (I measured it at 1.55 volts experimentally.) That’s far too high to be recognized as a logical zero value; 0.8 volts is the maximum valid zero voltage for 5V TTL logic. So the Unidisk doesn’t think there’s a Smartport device on its daisy chain connector, and the Floppy Emu never gets a Smartport address.

I was able to get daisy chaining working by adding a small value resistor between HDSEL and ground, external to the Floppy Emu. But that’s not much help to anybody, and it also prevents the Floppy Emu from working correctly in 3.5 inch disk emulation mode.

 
Solution?

So what’s the answer here? I’m afraid there probably isn’t one, and Unidisk 3.5 daisy chaining just won’t work, wah-wah and sad trombone. But maybe a reader will have a clever suggestion.

Changing the Floppy Emu’s protection resistors to something less than 1K could help. My math says a resistor of 381 ohms or less would put the pin 16 voltage at a valid logical zero for 5V TTL. By combining an old Floppy Emu Model A (no resistors) with some manually-wired external resistors, I was able to directly confirm that 1K ohm protection resistors don’t work for Unidisk daisy chaining, but 330 ohm resistors do work. But dropping from 1K to 330 ohm would be a significant reduction in the amount of protection for the CPLD. I’m also reluctant to make any changes to the Floppy Emu hardware design, which has become like a supertanker that’s difficult to change course. Any changes now would cost lots of time and money, and wouldn’t help owners of existing hardware anyway.

Another possibility is some kind of external adapter, with a physical switch for shorting pin 16 to ground. That would work, but the time needed to design, build, and stock such an adapter would be too high relative to the importance of Unidisk 3.5 daisy chaining. It’s unlikely that many people would be interested in buying such an adapter.

Read 15 comments and join the conversation 

Liron Support for Floppy Emu

Great news for owners of the Apple II Liron disk controller card: the latest Floppy Emu disk emulator firmware adds Liron support. This means that for the first time, it’s now possible to emulate 32 MB hard disks on an Apple II+ or IIe with the Floppy Emu!

The Liron is a “smart” disk controller for the II+ and IIe, using the same Smartport protocol as the Apple IIc, IIc+, and IIgs. It was originally designed to work with the Unidisk 3.5 inch floppy drive, but other Liron-compatible third-party external hard drives were later developed. With this new firmware, the Floppy Emu is able to emulate one of these hard drives, bringing an exciting new capability to the II+ and IIe.

Smartport emulation with the Liron card works nearly identically to the IIc, IIc+, and IIgs, as described in section 10.4 of the Floppy Emu manual. Connect the Emu to the Liron card, use the Emu’s menus to select Smartport mode, and populate your SD card with up to four disk images. These will appear as four virtual hard drives connected to your II+ or IIe.

Depending on your Apple II model and its version of the autostart ROM, the Liron-connected disk may or may not automatically boot when the power is turned on. If you have an older model that doesn’t autostart the Liron, type PR#7 to get things started (or PR#N if your Liron card is in slot N).

This is new firmware, so your help with testing is appreciated. If you tried the new firmware and it worked fine, please let me know. If it didn’t work, definitely let me know. Try it in Smartport mode with the Liron of course, but also try it with the built-in Smartport of your IIc, IIc+, or IIgs to verify it still works there too, and doesn’t interfere with other types of drives that are also present in the daisy chain.

Download the new firmware here:

Floppy Emu Model A – apple-II-0.1T-F16
Floppy Emu Model B – apple-II-0.1T-F18-modelB

Read 26 comments and join the conversation 

Floppy Emu Back in Stock

After a few weeks of scarcity, more Floppy Emu hardware is again available at the BMOW store, hot off the courier truck. It’s always my goal to keep a steady inventory available, but that’s proven more difficult than I imagined. The trouble isn’t surges in demand, or assembly problems, but just managing the supplies of all the materials involved.

To sell one Floppy Emu, I obviously need to have a main board in stock. But I also need the DB19 adapter board, which is a separate part. And I need 20-pin ribbon cables. And SD memory cards. And acrylic cases from the laser cutter. And padded mailers, boxes, bubble wrap, and postage labels. Sales grind to a halt when I run short of any of those supplies. To get them at reasonable prices requires buying them in bulk, with delivery times ranging from a few days up to two months. I can’t just drop into the corner store to buy more when I run low.

Maintaining those supplies efficiently can be challenging, and it’s not something I do very well. Real companies have automated inventory management systems that automatically order more parts as needed. I just glance into a box now and then, and maybe order more supplies if the pile looks small and I’m not busy doing something else. In this case I didn’t begin the hardware assembly process soon enough to account for the long lead time. I still had lots of hardware on hand when I reordered more, but it was all gone two weeks before the order was fulfilled. It’s one more thing I need to learn to do better.

Read 1 comment and join the conversation 

Older Posts »