I’m developing an Apple II disk controller that’s based on the UDC disk controller design. The original UDC card had 8K of ROM and 2K of RAM, so it needs 10K of combined memory. The FPGA device I’m using for prototyping, a Lattice MachXO2-1200, has 8K of embedded block RAM and 1.25K of distributed RAM. It also has 8K of “user flash memory”. So will the UDC design fit? It’s close, but I think the answer is no.

At first I thought I could store the ROM data in the FPGA’s UFM section, but that doesn’t look promising. I can store the data there, but compared to embedded block RAM, accessing UFM is inconvenient and probably impractical for live execution of 6502 code. Accessing the UFM requires setting up a Wishbone interface in the FPGA’s Verilog code, starting a memory transaction, and reading out an entire page of flash (16 bytes). It’s also pretty slow. I don’t think it’ll be possible to read an arbitrary byte of UFM and return it to the CPU within ~500 ns, as would be required for directly executing code from it.

OK, so no UFM. Maybe I can store the 8K of ROM data in EBR, using RAM to hold what’s technically ROM? That would work, but it would leave only 1.25K of distributed FPGA RAM remaining to implement the required 2K of RAM for the disk controller. It’s 768 bytes short. No good.

I could switch to a larger FPGA with more memory, or add a separate RAM or ROM chip. But that would increase cost and complexity, and anyway wouldn’t help with my prototype board that’s already built.

 
Stupid Idea #1

From my analysis of the UDC ROM, I think the upper half of the card’s RAM is only used when communicating with Smartport drives. So I might be able to reduce the RAM from 2K to 1K, and at least I’d be able to test whether 3.5 inch and 5.25 inch drive support works. Using 8K of EBR and 1K of distributed RAM, I’d have a whopping 256 bytes of RAM left. Will it work? I think distributed RAM just means using the FPGA’s logic resources as RAM, so this approach would use 80% of the FPGA’s logic resources and only leave 20% remaining for the actual card functionality, like the IWM model and other logic. It might work, it might not.

 
Stupid Idea #2

The 8K of ROM isn’t one large chunk. It’s divided into 1K banks that can be mapped into a single 1K region of the computer’s address space. There’s already a small code routine to facilitate the bank switching. What if I could somehow make this routine copy the desired 1K block from UFM to EBR at the moment it’s needed? Then I’d have 8K in UFM, with a 1K cache in EBR, and the 2K of RAM also in EBR.

This would definitely fit, but there would be a delay every time code execution moved to a different 1K ROM page. How long does it take to move 1024 bytes from UFM to EBR? I’m not sure, but I’ll guess it’s tens to hundreds of microseconds. Will that cause problems? Maybe. Will this approach be a pain to implement? Definitely.

 
Stupid Idea #3

From what I’ve observed of the ROM code, bank 1 contains 5.25 inch functions plus 3.5 inch formatting. Bank 3 is exclusively for 3.5 inch stuff, and bank 7 is exclusively for Smartport drives. Maybe I could temporarily remove some parts of the ROM, in order to make it all fit? Then I might be able to test all the different types of supported disk drives, just not all at the same time.

 
Stupid Idea #4

Maybe I can modify the ROM code to use 2K of the Apple II’s own RAM instead of 2K of onboard RAM? Then everything would fit in the FPGA. But there must be a good reason the UDC designers didn’t do this. What 2K region of Apple II RAM is safe to use, and wouldn’t get overwritten by running software? I’m not sure.

 
Stupid Idea #5

Maybe I can modify the prototype board somehow, and graft an extra RAM or ROM chip on there for testing purposes? Maybe I can add a second peripheral card and somehow use its RAM or ROM? Now these ideas are getting crazy.

 
What’s the Long-Term Solution?

None of these ideas except #2 are workable as a long-term solution, if I eventually move ahead with manufacturing this disk controller card. So what path makes the most sense in the long-term?

Stepping up to the MachXO2-2000 would add about $2 in parts cost, which maybe doesn’t sound like much, but it’s significant. The XO2-2000 has 9.25K EB RAM and 2K distributed RAM, so the design should fit with a small amount of room to spare. That’s surely the least-effort solution.

I could keep the MachXO2-1200 and add a separate 2K RAM chip. The 8K of ROM would fit in the 1200’s EBR. The combined cost might be slightly lower than the MachXO2-2000, but the design and layout would become more complex, and I’m not sure it’s worth it.

I could step down to the MachXO2-640 (2.25K EBR, 640 bytes distributed RAM) and add a separate ROM chip. Total cost would be slightly less than a MachXO2-1200, and I’d also gain lots of extra ROM space for implementing extra features or modes. That would be great. Like adding a separate RAM chip, the extra ROM would make the board design and layout somewhat more complex. But the biggest drawback would be for manufacturing or reprogramming, because both the FPGA and the ROM would need to be programmed separately before the card could be used. Or maybe the FPGA could program the ROM somehow, but it would still be cumbersome and far less attractive than a single-chip programming process.

I never imagined a shortage of just 768 bytes could make such a difference. What an adventure!

Read 10 comments and join the conversation 

The Mac ROM-inator II is back in stock – get yours now at the BMOW Store. The ROM-inator II is a replacement ROM SIMM for Macintosh II series computers and the Mac SE/30, adding a bootable ROM disk, 32-bit cleanliness, HD20 hard disk support, and more. Read more about it at the project’s home page.

The instruction manual for the BMOW Floppy Emu disk emulator is now available in Japanese. Thanks to Kay Koba for the translation work. Floppy Emu is a floppy and hard disk emulator for classic Apple II, Macintosh, and Lisa computers. It uses an SD memory card and custom hardware to mimic an Apple floppy disk and drive, or an Apple hard drive. The Emu behaves exactly like a real disk drive, requiring no special software or drivers.

Be the first to comment! 

Today’s project: metal casting! I’d been wanting to try this for years, because who doesn’t love playing with molten metal? This was a single-sided open air sand casting process, which is about as simple as it gets. You basically just press an object into some densely-packed sand, remove the object, and pour metal into the resulting sand cavity. Humans have been doing this for thousands of years. Easy peasy, sort of.

This project was a long time coming. I discussed some metal casting ideas last year, and acquired some equipment. Then everything sat on a shelf gathering dust for 13 months.

I used pure bismuth for the casting: atomic number 83 on your periodic table. Bismuth has a pretty low melting point of 521 F / 272 C, easily reached with an electric heater. The objects here are a quarter, a silver dollar, a wire nut, a DB-19 connector, and a teddy bear pencil eraser. A major limitation of this particular process is that the object must have parallel or tapered sides so you can remove it from the sand without disturbing the cavity you just made. That’s why the teddy bear looks like it’s embedded in a rock: I had to dig it out of the sand instead of lifting it out cleanly. This process is also limited to making one-sided reliefs instead of full 3D objects, because the back is just a molten pool of metal directly exposed to the air as it cools.

Sand casting is probably better suited for making tools and gears and big stuff, as opposed to small detailed models like those here, but you can’t beat its simplicity. I made a huge number of mistakes, and the quality is pretty bad, but hey… it worked! Molten metal! Try something, learn something. The images from the coins came through much better than I’d expected, and the teddy bear is pretty neat. I feel like I’ve discovered some secret alchemy with this ancient process.

 
Sand Casting 101

The traditional sand casting technique uses something called green sand, which is a mix of regular sand, clay, and maybe a bit of other stuff, plus a small amount of water to help it stick together. I used something called Petrobond which is an artificial oil-bonded sand designed specifically for metal casting. When you pack it down tight, it’s very firm – a consistency similar to silly putty or a super dense cheesecake. Either way the grains are small enough to get pretty fine details. Petrobond advertises an average grain size of 0.07 mm.

I began by building a small wooden frame – a four-walled box with no top or bottom. I placed the frame onto a metal lid from a cookie tin to create a temporary floor, then arranged my reference objects inside the frame face-up. I think maybe you’re supposed to dust the objects and the “floor” with a releasing agent, but I didn’t have any, so I skipped this step.

Next, I packed sand into the frame, slowly burying the reference objects. You’re supposed to sift the stuff to break up the chunks and remove any foreign material. My wife vetoed using the kitchen colander or sifter, and my DIY sifter built from window screen failed miserably, so my Petrobond didn’t get sifted properly. I packed it in as tightly as possible with my hands, then rammed it down hard with the base of a heavy flashlight. The top surface of the sand was scraped level with the frame, using a metal ruler. I then carefully flipped over the frame and removed the cookie tin lid. Because the sand was packed very tightly, it did not fall out. I placed the inverted frame back onto the cookie tin lid, with the reference objects now exposed.

The objects were perfectly flush with the surface of the dense-packed sand. How do you remove them without disturbing the sand? There must be some secret method that I’ve yet to learn. I damaged the mold substantially in the process of removing the objects, and also spilled loose sand into mold cavities. There was a lot of swearing involved.

The final step was to melt the bismuth and pour it into the mold cavities. This was somewhat anti-climactic. I used an electric ladle to melt a one pound chunk of pure bismuth purchased from rotometals.com. It took a few minutes to melt, and smelled like a tire fire. I’m not sure if the smell came from the bismuth or from the ladle, but it was terrible and I feared my neighbors would complain. Once melted, I poured the bismuth into the molds like soup into a bowl. I let everything cool down for about an hour before digging the castings out of the sand.

 
Room for Improvement

I was happy to get “read the lettering on a quarter” level of detail in some areas, but the final casting results were mixed. I would have gotten better results and finer detail if I’d been more careful with removing the original coins from the mold, and poured the metal faster. You can see where the silver dollar partially cracked due to uneven cooling. This happened when I poured some bismuth into that mold, but not enough to fill it fully, and then waited a few seconds before pouring in the rest. I was trying to avoid overflowing.

Bismuth probably wasn’t the best material for this project. It has a low melting point and is comparatively non-toxic, but it’s brittle. Next time I may try pewter or another low temperature alloy that’s specifically intended for metal casting.

When you heat the bismuth, or most any other metal except gold, the surface of the molten metal reacts with oxygen in the air to create an oxide layer. You’re supposed to skim this off before pouring the metal into your molds. I forgot to keep skimming tools at the ready, so my oxide layer dregs went into the mold along with everything else.

The biggest improvement would be graduating to two-sided casting, using two sand frames that lock together. You can buy ready-made frame sets inexpensively. But even after reading several tutorials about the process, I still don’t really understand how the two-sided mold making works. I’m sure it’s very simple, but something about the geometry of it still escapes me.

Read 4 comments and join the conversation 

I concluded my last post about my Yellowstone disk controller for Apple II by saying I would probably support intelligent Smartport drives and 5.25 inch drives, but not 3.5 inch drives. But since then I’ve been busy investigating the possibility of a multi-purpose disk controller that could support all three drive types, by studying the Universal Disk Controller (UDC) that was marketed by Laser, VTech, and CPS. I’ve made some good progress, but big mysteries still remain.

There were two physical versions of the UDC: the original “long” version and the later “short” version. There were also at least four different firmware versions, and probably many more. The UDC’s capabilities may have changed substantially between versions. I have ROM dumps for firmware versions $21, $23, $30, and $40. Initially I thought these hex values for version number should be converted to decimal for interpretation, so for example $21 meant human-readable version 3.3. But it now seems more likely we’re intended to just put a decimal point between the two hex nibbles, and so I have firmware versions 2.1, 2.3, 3.0, and 4.0. The 2.x versions are from long UDCs and the 3.0 and 4.0 are from short UDCs.

 
ROM Spelunking

Unfortunately I don’t have any UDC cards! All of my investigation is based on analysis of these ROM dumps and contemporary documentation.

Making sense of the ROM is a slow and tedious task. It’s quite possibly the most time invested for the least reward of anything I’ve ever attempted. Running the ROM dump through a 6502 disassembler produces thousands of lines of output like this:

CF9B   AD CF CA   LDA $CACF
CF9E   C5 41      CMP $41
CFA0   F0 37      BEQ $CFD9
CFA2   90 42      BCC $CFE6
CFA4   E5 41      SBC $41
CFA6   8D DD CB   STA $CBDD
CFA9   A9 0B      LDA #$0B
CFAB   20 F8 C9   JSR $C9F8
CFAE   A9 0E      LDA #$0E
CFB0   20 F8 C9   JSR $C9F8
CFB3   BD 8D C0   LDA $C08D,X
CFB6   BD 81 C0   LDA $C081,X
CFB9   BD 8E C0   LDA $C08E,X
CFBC   10 F5      BPL $CFB3
CFBE   CE DD CB   DEC $CBDD
CFC1   D0 EB      BNE $CFAE
CFC3   AD C6 CA   LDA $CAC6
CFC6   29 20      AND #$20
CFC8   D0 0A      BNE $CFD4
CFCA   A9 01      LDA #$01
CFCC   20 02 CA   JSR $CA02
CFCF   BD 8E C0   LDA $C08E,X
CFD2   30 FB      BMI $CFCF
CFD4   A0 00      LDY #$00
CFD6   88         DEY
CFD7   D0 FD      BNE $CFD6
CFD9   A5 41      LDA $41
CFDB   8D CF CA   STA $CACF
CFDE   AC D4 CB   LDY $CBD4
CFE1   99 D2 CB   STA $CBD2,Y
CFE4   18         CLC
CFE5   60         RTS
CFE6   A5 41      LDA $41
CFE8   38         SEC
CFE9   ED CF CA   SBC $CACF
CFEC   8D DD CB   STA $CBDD
CFEF   A9 0F      LDA #$0F
CFF1   D0 B8      BNE $CFAB

It looks indecipherable. But I can replace a few known memory addresses with symbols, such as all the references to addresses in the $C08x range, which are IWM latch addresses on the Apple II. I can examine the subroutines that are called from JSR instructions, infer what some of the simplest ones are doing, and replace their addresses with symbolic names. The referenced memory locations like $41 and $CACF are clearly state variables of some kind. I can look for all the places where those locations are used or modified, and begin to guess what they’re used for, and give them symbolic names too.

Eventually some parts of the code will become more readable. This helps me to make better inferences about other code that references the newly-readable parts. This process repeats in a sort of recursive fashion, until after many many hours and thousands of lines of opaque code analysis, the code above is transformed into something like this:

; ROMFUNC 81 - Seek
; seek to track for 3.5 drive
L4CF9B   LDA CUR_TRK          ; current track 
         CMP WANT_TRK         ; desired track 
         BEQ L4CFD9
         BCC L4CFE6
         SBC WANT_TRK         ; subtract to get the number of tracks to step
L4CFA6   STA $CBDD            ; init the step counter
         LDA #$0B             ; write drive register 0100: step direction towards track 0
L4CFAB   JSR WRREG35
L4CFAE   LDA #$0E             ; write drive register 0001: perform step 
         JSR WRREG35
L4CFB3   LDA SENSE_ON,X
         LDA PH0_ON,X         ; redundant? PH0 was already on
         LDA WRITE_OFF,X      ; check if step is completed
         BPL L4CFB3           ; keep waiting if the step isn't yet completed
         DEC $CBDD            ; decrement the step counter
         BNE L4CFAE           ; loop back if there are more steps yet to be done
         LDA CUR_DRV_FLGS
         AND #$20             ; mask bit 5 of the drive flags (changed speed zones)
         BNE L4CFD4           ; skip ahead if flag is 1
         LDA #$01             ; read drive register 1110: READY flag
         JSR RDREG35	
L4CFCF   LDA WRITE_OFF,X
         BMI L4CFCF           ; keep waiting if the drive is not ready
L4CFD4   LDY #$00             ; busy loop delay
L4CFD6   DEY                  ; 256
         BNE L4CFD6           ; times
L4CFD9   LDA WANT_TRK
         STA CUR_TRK          ; update the current track number
         LDY DRV_NUM          ; maybe drive number?
         STA CUR_TRK_TAB,Y    ; set the current track number in the drive table
         CLC                  ; carry value 0 means OK/success
         RTS
L4CFE6   LDA WANT_TRK
         SEC
         SBC CUR_TRK          ; reverse subtract to get the number of tracks to step
         STA $CBDD            ; init the step counter
         LDA #$0F             ; write drive register 0000: set step direction towards track 79
         BNE L4CFAB

 
Intelligent Smartport Drive Support – The Phantom Feature

Firmware versions 2.1 and 2.3 from the long UDC are nearly identical. They contain support for intelligent Smartport drives, like Floppy Emu’s Smartport hard disk emulation mode, or the Unidisk 3.5 drive. I’ve looked at the Smartport support code in detail, and it seems correct and complete. And yet… there are many sources on the web saying the UDC doesn’t support intelligent Smartport drives, and connecting one will damage the drive or the card. Hmm.

The 2.x firmware versions don’t seem to have support for daisy-chained drives. That’s a big disappointment, since I would definitely like Yellowstone to support daisy-chaining if possible.

There are many things in this firmware that look “not quite right”. I see unnecessarily convoluted code, limitations, questionable assumptions, and possible bugs. It could be that I just don’t understand the code fully enough, but it really looks like it was written by somebody who didn’t totally understand what they were doing, or was in a rush, or was just not a very good programmer.

As best as I can tell, the long UDC corresponds to this version of the instruction manual, which says it supports up to two drives on two separate connectors. It’s sort of vague about intelligent Smartport or Unidisk 3.5 support.

Being somewhat disappointed in the 2.x firmware and its lack of daisy-chaining support, I began to analyze firmware 4.0. But after only a few hours I realized something terrible: it has no support for intelligent Smartport drives! And neither does firmware 3.0. The Smartport support that was there in firmware 2.x is gone.

Why, WHY would they remove previously-existing support for Smartport drives? It doesn’t make sense.

The short UDC appears to correspond to this version of the instruction manual, which says it supports daisy-chaining and up to four drives. Again, it’s sort of vague about intelligent Smartport support.

According to sources I’ve read, later models of the Laser 128 computer contain an integrated UDC as a floppy drive controller, and these computers do support intelligent Smartport drives. This Australian web page has some helpful info if you search for “UDC”, about halfway down the page. There’s also the Laser 128 manual, where the chapter on disk I/O has a detailed discussion about the different types of drives and specifically lists Unidisk 3.5 as one of the supported drive types for the Laser 128. Which UDC version is that?

 
Still Searching for Answers

So that’s where I am. I’d like to make a disk controller card that handles all three Apple II drive types, and daisy-chaining, similar to the Apple IIGS. UDC firmware 2.x seems to support Smartport drives (although there’s some question about this), but doesn’t support daisy-chaining, and overall looks a bit rough. UDC firmware 3.0 and 4.0 supports daisy-chaining, but support for Smartport drives was removed. And the Laser 128 contains an integrated UDC that reportedly supports Smartport drives, but its daisy-chaining capabilities are uncertain. Clear as mud. Where do I go next?

Maybe firmware 3.0 and 4.0 do contain support for Smartport drives, but it’s so cleverly obfuscated that I missed it? That seems very unlikely. Maybe I could take the code for Smartport drives from firmware 2.3 and somehow add it to firmware 4.0 to create a version that does everything? That sounds extremely difficult – even after my marathon code analysis, I don’t understand the details well enough to attempt something like that. Maybe I need a ROM dump from a Laser 128? Or maybe I should forget about the UDC altogether, and take up a new hobby? 🙂

Read 10 comments and join the conversation 

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