BMOW title
Floppy Emu banner

UDC: The Next Generation

I’m still working on development of a disk controller card for the Apple II. As part of that effort, I’m still trying to understand the design of the UDC disk controller. My hope is to combine what I learn about the UDC, the Liron disk controller, and the standard Disk II controller in order to build something with the best qualities of all three. But for now I’m deep in the weeds with the UDC, and today I was pleased to finally confirm my long-held theory about UDC support for intelligent Smartport drives!

In the Apple II world, there are three primary types of disk drives: 5.25 inch drives, dumb 3.5 inch drives, and intelligent drives using the Smartport protocol. The best-known example of an intelligent Smartport drive is the Unidisk 3.5, but others include Floppy Emu’s emulated Smartport Hard Disk.

For quite a while now, I’ve been chasing after this question of whether the UDC supports intelligent Smartport drives. The two available UDC manuals are slightly vague, but could be interpreted as saying there’s no support. Several sources on the web say Smartport drives aren’t supported, and you’ll damage your drive or UDC card if you try. But a contemporary print ad for the UDC advertises Unidisk 3.5 compatibility. I looked at ROM dumps from several different UDC versions, and found what looked like Smartport-related code in some older ones but not in newer ones. It’s all very confusing.

Fun With ROM Hacking

After a month of theory and research, I finally got to try some hands-on tests. The original UDC card is called the “long” version, and the follow-up card with a custom ASIC is the “short” version. I’ve been unable to find anyone with a long UDC (call me!), but I was able to borrow a short UDC. I spent a while mapping all the connections on the card and constructing a schematic, until I was satisfied there were no lurking dangers from merely connecting a Smartport drive to it. I connected a Floppy Emu configured for Smartport emulation mode, booted it up, and… it did nothing. Then I connected a Unidisk 3.5 and tried again, and it also did nothing. Blah.

This UDC short card came with version 4.0 of the ROM, which I’d previously analyzed and concluded didn’t contain any code for Smartport drive support. So it’s not surprising that it didn’t work, but I’d hoped maybe I’d missed something in my ROM analysis. My earlier analysis of ROM version 2.3 from the long UDC found that it did contain code for Smartport drives. I strongly suspect the short UDC is functionally identical to the long, despite its different physical appearance. So what happens if you take ROM 2.3 from a long UDC, and stick it in a short UDC card? Let’s find out!

The ROM is stored in a 27C64 EPROM and is socketed, so no modifications were necessary on the UDC card. I used a 28C64 EEPROM as a drop-in replacement, and programmed it with ROM version 2.3 using my EasyPro universal programmer. (Coincidence: this EasyPro 90B programmer was first mentioned on this blog precisely 13 years ago today. I feel very, very old.) I unsocketed the original ROM chip, popped in the new one, booted up, and… it did nothing. Worse than nothing, it actually froze up the computer. I checked the disk I/O signals with a logic analyzer, and there was no activity at all. Blah again.

Feeling disappointed, I gave up. The next morning, I noticed that the logic analyzer wasn’t actually connected. Oops.

After I’d fixed that, I could clearly see evidence of a Smartport reset and initialization sequence on the disk I/Os, but it still wasn’t working. Eventually I concluded that the code in the ROM was crashing or getting stuck in an infinite loop somewhere. But where, and why? I would have tried single-stepping through the code, but quickly discovered that’s extremely difficult for code in ROM on an Apple IIe.

By carefully comparing the ROM 4.0 and ROM 2.3 code, eventually I was able to guess the problem. A key feature of the UDC is that it sometimes pulls the 6502’s RDY input low to temporarily halt the CPU. This is a sort of flow control mechanism, and happens whenever the code tries to read a byte from the disk, but a new byte isn’t available yet. It appears that the details surrounding use of RDY changed between the long and short UDC, and the short version will halt the CPU on reads to some memory locations that the long UDC ignores. By comparing the two ROMs and making some educated guesses, I was able to modify the version 2.3 ROM so that it no longer caused the short UDC to freeze the computer. But it still didn’t work. Blah for a third time.

After more tinkering and head-scratching, I disconnected the Floppy Emu and tried the Unidisk 3.5 again. I was amazed when it booted right up! But now I had a new puzzle to solve, to explain why the Unidisk 3.5 worked but Floppy Emu’s Smartport emulation didn’t, even when using the exact same disk.

The logic analyzer eventually revealed the answer. Something like 5-10% of the data packets from the Unidisk 3.5 were NAK’d by the UDC card, forcing them to be retransmitted. Some packets had to be retransmitted multiple times. In all my time tinkering with the Smartport protocol over the years, I’ve never before seen a NAK of valid data, and Floppy Emu doesn’t even implement retransmitting a packet in case of a NAK. I implemented the missing retransmit logic, and the Floppy Emu worked! Hooray!

The mystery still wasn’t completely solved, however. What was causing some packets to be NAK’d, from both the Floppy Emu and a real Unidisk 3.5? The NAK rate was also much higher with the Floppy Emu than with the Unidisk 3.5, approaching 30-50%. Acting on a hunch, I experimented with small changes to the Floppy Emu’s bit rate, and found that it caused some changes in the NAK rate, but the results weren’t conclusive.

The “correct” bit rate is either one bit every 4.0 microseconds, or every 3.96 microseconds, depending on your reference source and your assumptions. Floppy Emu with the latest firmware does one bit every 3.95 us. I found that at 4.2 us I got a 100% NAK rate, but at 4.1 us the NAK rate suddenly dropped to about 10%, and at 4.05 us and 4.0 us the NAK rate grew worse again. That doesn’t really make sense, and I didn’t repeat the tests enough times to be very confident in those results. My suspicion is that either the UDC short card is very sensitive to small changes in bit rate, or else that substituting the long UDC ROM is negatively affecting the behavior somehow. I’m not sure it’s worth chasing this mystery further, since it’s quite possibly caused by my weird hybrid card setup.

So the $64000 question is finally answered, sort of. The standard short UDC card does not support Smartport drives, but connecting one won’t damage anything. But it does support Smartport drives when using an appropriately hacked-up ROM, proving that it’s entirely a question of software rather than hardware. As for the long UDC, I still can’t say for certain without examining one directly, but all the evidence points to it supporting Smartport drives.

Where to Next?

This probably marks the end of my very long detour into “how does the UDC work?” and a return to actual development on my disk controller card. Next step: see if I can duplicate the UDC behavior (or something close to it) with my FPGA-based approach.

Read 7 comments and join the conversation 

7 Comments so far

  1. Hugh Hood January 16th, 2021 7:24 pm

    Man, you’re a thorough guy! Nice work.

    For those of us with the ‘short’ UDC’s, will you consider offering for sale your modified ROM so that we could use the Floppy EMU with them?

  2. Steve January 16th, 2021 8:57 pm

    I’d be happy to share the modified ROM data with anyone who wants it. I can email it or link it here. But it breaks the short UDC’s support for 5.25 inch and 3.5 inch drives, so it’s not exactly an upgrade. It might be useful for someone who only cares about Smartport drives. For use with the Floppy Emu, it also requires the firmware change I mentioned about retransmitting after a NAK, which still needs more testing before I can release it.

  3. Steve January 17th, 2021 1:59 pm

    Sorry, I forgot to mention I also added a small translator circuit between the Floppy Emu and the UDC. The UDC has an unusually strong pull-up resistor on one of the disk I/O signals, and Floppy Emu can’t normally pull it low enough for the UDC to detect a logical zero. The disk controller I’m designing won’t have this problem, but it means even if you use my modified ROM the Floppy Emu still won’t work with the UDC in Smartport mode. The Unidisk 3.5 will work, however.

  4. groinksan January 19th, 2021 9:07 pm

    I’m curious at to why no one is willing to loan you a long UDC card. My presumption is that the owners of these cards are attempting to basically protect their investment in the card, and to keep the value of their card high, so that when they’re through with the card they can sell their cards and get most or all of their money back. Which makes me wonder if there are people invested in rare cards are against reverse engineering and producing peripherals that are not just low cost, but also available in large numbers, thereby destroying the value of their collections.

  5. Chris M. January 20th, 2021 7:24 am

    I’m guessing the “long” card is uncommon enough that one just hasn’t popped up to loan out yet. Judging by the broken firmware, its likely Vtech/Laser abandoned Smartport support due to not figuring out how to get it to work. Now I’m curious how/if the Laser 128 computers handle it!

    Speaking of machines that handle 3.5″ drives. Someone has documented the “MIG” chip in the Apple IIc+:

    It may not be suitable for FPGA implementation though since it needs some RAM and appears fairly complex (its compliments the IWM).

  6. Steve January 20th, 2021 9:30 am

    Yeah I think the long UDC just isn’t very common, and the few people who still have one either don’t read this blog or aren’t comfortable loaning it out. That’s fine, since I don’t think I’ll need a long UDC to finish my project. I’m just curious more than anything – it would be nice to definitively answer the question of Unidisk/Smartport support with original hardware and firmware.

  7. Mac January 24th, 2021 12:46 am

    Sorry if you have found this information already. But it might be helpful. Is f you decide to implement DMA in your card.
    Thanks for keeping the retro computer Apple II alive.
    My only thought while reading your posts. What about a separate, quick mode for floppy, smart hard drive or port?

Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.