After a long delay, Floppy Emu is back in stock and available for sale now. It’s available with a built-in connector for placement at the rear of the Mac, or bundled with a three foot extension cable so you can place it anywhere on your desk. Beginning with this batch of hardware, the LCD backlight is now enabled by default too. Woot!

I’m having difficulty locating sources for the floppy connector, a DB-19 male D-SUB. These were common in the 80′s and 90′s, but the supply has dried up and they’re almost impossible to obtain now. I’m still chasing down possible sources and investigating alternatives. If I don’t find a good solution, this may be the last batch of Floppy Emu hardware for a while.

As a new option, I’m now offering an SD card preloaded with disk images of System software versions 1 through 7.5.3, as well as some classic software like MacPaint, Hypercard, After Dark, Kid Pix, and Fool’s Errand. Cases for the Floppy Emu are also available, in brown wood hardboard or clear acrylic.

For those who have waited patiently on the waiting list since mid-December, thank you. Happy emulation!

I’m still searching for a source of more DB-19 connectors, but so far I’ve been unsuccessful finding a single one. As a backup plan, I’m exploring building a DB-19 substitute using a PCB and 19 individual pins. The result won’t really be a proper D-SUB connector, because it won’t have a surrounding shield, but it will still fit a DB-19 female port. Add a standard IDC-20 connector to the back side of the same PCB, and it can make a strange but effective DB-19 to IDC-20 converter cable.

The first version of this PCB is shown above, and is based on an idea by Charles Phillips. It uses four sections of standard 0.1 inch (2.54 mm) pitch male header. That’s the wrong pitch – a D-SUB connector has a 2.77 mm pitch – but it’s close enough that short sections of 4 or 5 header pins can bend a little and still fit the D-SUB. The advantage of this version is that it’s cheap and easy to make, and should be no trouble for the board assembly shop. Reliability is a question, though. Slightly bent pins may not make good contact inside the female port, or there may be an issue with square header pins in round port holes. But the initial tests look promising.

The second version of the PCB is very similar to the first, except the pads are all on a 2.77 mm pitch D-SUB grid instead of a 0.1 inch (2.54 mm) pitch. And instead of using 0.1 inch male header, it uses 19 individual D-SUB crimp pins in a non-standard way: the pins are each soldered in place, and then the crimp sections are cut off. The advantage of this version is that the pin spacing is perfect, and the pins are round, so the fit in the female port should be perfect. But it would be a couple of dollars more expensive, and it’s something that would have to be done manually, without standard assembly tools or processes. I need to check with the board assembly shop I’m using to see what effect it would have.

Neither of these PCBs has a shield surrounding the 19 pins, so if somebody tried hard enough, they could insert the connector aligned incorrectly. With the whole unit offset by 1 pin horizontally or vertically, the connected electronics might get zapped with 12 volts on a signal pin. You’d have to try pretty hard to do this, though.

After days of fruitless searching, I finally found a shop in Macedonia with a stock of DB-19 male solder cup connectors. I bought them all! To be honest, I had to check a map to learn where Macedonia is, because it’s not exactly one of the top 10 most likely sources for electronic components. Total cost for 500 pieces including VAT and shipping was 27019 denar, or about $497 US dollars at current exchange rates, so that’s just under $1 per connector. Not bad, considering most other places wanted to charge $2 to $4 per connector, if they even had them in stock.

I may have to pay import duty tax. I’m not sure how that works, but I assume DHL or somebody will tell me what’s needed. The total price also includes about $50 in European VAT, which as a United States buyer I shouldn’t need to pay. Anyone have experience in getting VAT refunded? I presume there’s a form I need to send somewhere.

At almost the same time that I heard from Macedonia, I also got my first concrete response from a supplier in China about manufacturing new DB-19 connectors. We discussed two options: a soft tooling setup, with a lower initial setup fee but higher per-piece cost, or a hard tooling setup with the opposite cost balance. I asked for soft tooling. After many rounds of back and forth, I finally received a setup cost quote of (drum roll…) $11,185. They didn’t state what the per-piece cost would be after setup, but already it’s too expensive. Unless I could somehow band together with other DB-19 users in the Atari and Apple II communities for a large combined order of 10000+ pieces, it’s not practical.

I won’t rest easy until the package from Macedonia arrives. Even though they say they’re sending 500 pieces of DB-19P male solder cup connectors, and the photo on their web site looks right, I’ve found too many vendors whose web sites are out of date, or whose stock mysteriously disappears when you try to place an order. Or maybe they’ve got 500 DB-25 connectors in a mislabeled box, and will be sending those to me. I’m crossing my fingers in hopes that nothing will go wrong.

Floppy Emu demand has been widely variable, so I’m not sure if 500 pieces will be enough supply to last two years or only a few months. The Macedonian shop wasn’t sure if they could get more stock, so at some point I’ll likely run out of DB-19 connectors again. I’ll continue hunting for other sources and refining my DB-19 substitute designs.

Edit: I was just about to post this update, when I noticed the order confirmation page from the Macedonian shop says the order both was and wasn’t successful. So which is it? Ugh. The saga continues…

A few weeks ago I designed a right angle adapter PCB for the Floppy Emu. The idea was to make a little board that plugged into a standard Emu and converted it to right angle rear mounting, with the LCD and buttons facing outward, and the main board leaning against the back of the computer’s case. It’s possible to hack your Emu to do this, but I wanted a solution without needing to resolder or modify anything.

Unfortunately the geometry is wrong, and the adapter doesn’t fit. In order to plug into the computer’s floppy port, the DB-19 connector on the adapter board needs to extend about 1 cm behind the main Emu board. But as you can see in the photo, it doesn’t extend behind the main board at all. It’s not even close. So the main board just whacks into the Mac’s case and won’t let the adapter go any further.

I knew the geometry would be a problem even before I sent the adapter boards off to be made. I was hoping there would be enough flex or play in the connections that it would still fit, but no dice. Chalk this one up as a learning exercise!

Floppy Emu was originally developed to be purely a floppy disk emulator for the Macintosh. More recently, I added the ability to emulate a hard disk too, for those Mac models that support Apple’s original HD20 hard drive. This enabled the use of much larger disk images up to 2 GB, but it also enabled another feature that’s been unexplored until now: daisy chaining!

With a standard Macintosh floppy drive, there can only be one drive per floppy port. There’s only a single ENABLE signal at each port, and the Mac ROM only expects to find one drive on each port. So you can have one drive on the external floppy port (if the Mac has one), and one drive on the internal floppy port, and that’s all. If you somehow brewed up a custom splitter cable to connect two floppy drives to a single floppy port, it definitely wouldn’t work, and would cause electrical contention that might damage the drives or the Mac. This would be true whether you used Floppy Emus, or real floppy drives.

When Apple introduced the HD20 external hard drive in 1985, the situation changed. An often-overlooked feature of the HD20 is the floppy-out connector on the back of the drive. Combined with new HD20-aware code in the Macintosh ROM, this made it possible to daisy chain multiple drives together for the first time. Floppy drives were still “dumb” and didn’t understand daisy chaining, but you could build a chain of one or more HD20 drives, with an optional floppy drive at the end of the chain. Aha!

 
Signaling

To support daisy chaining multiple drives on a single port with a single ENABLE signal, Apple used a trick. The ENABLE signal from the Mac’s floppy port was connected to the first drive in the chain. That drive used internal logic to generate a new ENABLE signal, which it passed to the second drive in the chain. The second drive did the same for the third, and so on. As long as things worked correctly, only one drive at a time would ever see ENABLE asserted, so the drives could coexist happily on a shared port.

To select the next drive in the chain, the Mac asserted and then deasserted another signal called LSTRB, while keeping ENABLE asserted the whole time. The drive that believed it was currently enabled was supposed to see this, disable itself, and enable the next drive. When ENABLE was finally deasserted, all drives would disable themselves. When ENABLE was later asserted again, the first drive in the chain became enabled, and the process began anew.

This daisy chaining technique was mentioned in a dusty old HD20 document I found, but I was never able to get it to work as described in the document. Only after a lot of trial and error, and reverse engineering of the HD20 code in the Macintosh ROM, was I finally able to get daisy chaining working with the Floppy Emu.

 
Why?

Is daisy chaining actually useful for computer collectors in 2015, or just a novelty? I can see two scenarios where it would be helpful:

• With a Mac 128K or 512K, to use one Emu as a floppy source for loading Apple’s HD20 Init, and a second Emu in HD20 mode as a boot volume. Since the Mac 128K and 512K don’t have built-in ROM support for HD20, they normally can’t boot directly from an HD20 without a real floppy disk with the HD20 Init on it.
• With any Mac, to use one Emu in HD20 mode as a primary boot disk, and a second Emu in any mode as a tool for transferring files between Macs or between a PC and a Mac.

 
The Daisy Chain Board

To make daisy chaining easy, I designed the daisy chain adapter board pictured above. Plug the adapter into your Mac, either directly at the external floppy port, or with a cable to the internal floppy port. Then connect two drives to the DISK 1 and DISK 2 connections, and an extra wire to disk 1′s TP1 output, and you’ll be in daisy chaining heaven. Or link a second adapter board at DISK 2 to create an even longer daisy chain. Although it looks like a Y-splitter, topologically the enable signals form a daisy chain.

I was unsure how popular daisy chaining might be, so I only had a few samples of this board made. If you might be interested in buying a daisy chain adapter board, please let me know. If there’s sufficient interest, I’ll build more.

 
Maybe Don’t Try This At Home

Building your own daisy chaining setup requires some non-standard connections and custom wiring between two or more Emu boards. Damage to the Emus or the Mac is definitely possible if you botch this, so be extra careful to check your connections, and don’t proceed if you’re uncertain about your ability to do it correctly.

Briefly, all the drives should be connected as a shared bus, with the same floppy cable signals going to each one, except for the ENABLE signal. The ENABLE signal from the Mac should be connected to the ENABLE input of the first drive. The TP1 test point of the first drive should then be connected to the ENABLE input of the second drive. TP1 of the second drive should connect to the ENABLE input of the third drive, and so on.

You’ll find TP1 on your Floppy Emu board near the bottom left corner of the LCD’s overhang. It’s an unlabeled metal-ringed hole just below the 10×2 black plastic IDC connector.

If you’re building a custom cable using standard IDC-20 flat ribbon cable, ENABLE is on pin 14. Pin 1 on the cable is colored red, so start at the red end and count 14 wires to locate ENABLE. Count twice, cut once!

 
Important Notes

• Be sure you’re using the latest HD20-aware firmware for the Emu, which as of this moment is HD20-0.7A-F14.5. You can download the firmware here.
• The first Emu in the chain must be in HD20 hard disk emulation mode (or a real HD20 if you’ve got one). You can string together more HD20 mode Emus if you’d like. The chain can end with zero or one Emus in floppy mode, or a real floppy drive. If there is a floppy-mode Emu, it must be at the end of the chain.
• In order for daisy chaining to work, your Mac must have HD20 support in ROM, or boot from a disk that contains Apple’s HD20 Init. The supported machines are the Mac 128K and 512K (with HD20 Init), 512Ke, Plus, SE, Classic, Classic II, Portable, IIci, IIsi, and LC (but not LC-II or LC-III).
• The topology and total length of the daisy chain cables is important. Longer cables with forking paths will cause signal reflections and delays that may cause the Emus to work intermittently when daisy chained, or not at all.

I have the DB-19 connectors. They’re mine, all mine! MINE!! MWAAAHAHAHAHA!!!!!

*Cough* Sorry about that, I don’t know came over me. So the great DB-19 panic of 2015 has ended, and I’ve got 581 of these metal and plastic beauties. Of course there will probably be another DB-19 panic in 2016 when these ones run out, but hopefully I’ll have worked out another solution before then.

If you’re new to this discussion and wondering what a DB-19 is, it’s a D-SUB connector like the more familiar DB-9 serial or DB-25 parallel connectors used on many older computers. My main product is a disk emulator for 1980′s Macintosh computers, and those computers were built with a DB-19 floppy port, so my emulator board must have a DB-19 connector. The trouble is that nobody has manufactured DB-19 connectors since about 1990, as far as I can tell. Since then the small remaining demand has been slowly draining the surplus warehouses that still have DB-19′s. Last month, the supply at the few big warehouses that still had them all went to zero, and it became virtually impossible to buy them anywhere.

This touched off a crazed panic on my part, and I went digging under every rock from San Jose to Skopje to Kuala Lumpur to find these things. And when I found some, I bought them ALL. I even got a friend of a friend to hand carry some connectors from Malaysia to California for me! After two weeks of furious hunting, the hoard above is my result. I can say with pretty good confidence that this is the largest remaining stockpile of DB-19s in the world. If anybody has more, they’ve certainly made them so difficult to find and buy that they may as well not exist.

So what happens in 2016 when the supply runs out? Plan A is to find a D-SUB manufacturer with some old DB-19 molds who is willing to make more, or who can adapt their existing DB-25 process to make DB-19s too. I’ve received several quotes from D-SUB manufacturers, but unfortunately I probably can’t afford the setup costs to do this. I’ve contacted a few people in the Atari and Apple II worlds who also use DB-19 connectors, and if we pool our efforts and share the cost, it might work. I’m continuing to talk with D-SUB manufacturers in the hopes that we can find a solution that works for them and for me.

Plan B is to make a DB-19 substitute from a custom PCB and header pins. It wouldn’t really be a DB-19, but it would fit a DB-19 female socket, and could be manufactured fairly easily.

Plan C is the brute force solution: get a huge pile of DB-25 connectors, and cut each one with a band saw.

 
Footnote: Many people have written to me about DB-19 connectors they saw advertised for sale on the web. Thank you! Unfortunately, it’s very likely that the store does not actually have any DB-19 parts, and never will. It seems to be common practice for parts warehouses to list parts they don’t actually have available, and even for the web page to claim they’re in stock. Unless you hear directly from somebody at the store who can confirm they really do have DB-19 connectors, and how many they have, it’s probably just a phantom.

I’ve also found that many of the web-based parts warehouses are just alternate electronic storefronts for other warehouses, or aggregators for several other warehouses, but don’t actually have any inventory of their own. This makes it look like there are more people selling DB-19 connectors than there really are. Instead, it’s just different salesmen all selling the same stock.

A few months ago I added a hard disk feature to Floppy Emu: HD20-compatible disk emulation, with disk images up to 2 GB! Unfortunately many people didn’t see the news, and I continue hearing from folks who are unaware their Emu can do anything more than 800K or 1440K floppy images. If you’ve got a Floppy Emu board and a Mac 128K, 512K, 512Ke, Plus, SE, Classic, Classic II, Portable, IIci, IIsi, or LC: your machine supports HD20-compatible disks! Install the latest HD20 alternate firmware now, and start working with giant disk images large enough to hold your entire vintage software collection. You can download the alternate firmware from the Floppy Emu product page.

The HD20 alternate firmware also supports switching back to floppy emulation mode, for those times when you need it. Press the SELECT button while the Emu is displaying its version info on the LCD, and it will show a menu for choosing between hard disk and floppy emulation modes.

Happy hacking!

The Lisa computer was Apple’s precursor to the Macintosh, and it shared a lot of the same hardware and software. I’m going to look at adding Lisa support to my Floppy Emu disk emulator for Macintosh.

The Emu can already emulate a standard Sony 400K floppy drive, and the Lisa 2 aka Macintosh XL can use a standard Sony 400K floppy drive. (The relatively rare Lisa 1 used 5 1/4 inch Twiggy floppies.) So I *think* they should already be compatible at a low level, from an electrical and interface standpoint. That means the Lisa support could be added with just a firmware update, and no hardware changes necessary. My challenge is that I don’t actually own a Lisa! But with the assistance of a few kind Floppy Emu fans who are also Lisa owners, I’ve started getting closer.

The first obvious task is that the Emu firmware must be modified to support tag bytes. On both the Lisa and the Macintosh, a floppy sector’s data contains 12 bytes of tags, plus 512 bytes of normal data. On the Mac, the tags aren’t used for anything, and Floppy Emu just treats them as if they were always zero. Standard .dsk image files don’t even store the tag bytes, although Disk Copy 4.2 images do. But unlike the Mac, the Lisa needs those tag bytes in order for Lisa-formatted disk images to work correctly. So at a minimum, the firmware will need to fetch the tag bytes for each sector from the DC42 image file, instead of just pretending they’re zero.

 
Macintosh Emulation on the Lisa

But wait! Even without changing anything on the current Emu firmware, it should be possible to get it working on the Lisa under Macworks XL. Macworks is software for the Lisa 2 that basically turns the computer into an emulated Macintosh. After booting Macworks XL from a standard Lisa disk, you’ll then see the familiar Macintosh blinking question mark as it awaits a Mac boot disk. At that point, it should be possible to use a standard Floppy Emu and a Macintosh disk image to boot the Mac OS on the Lisa. Or boot into Mac OS with another disk, then use Floppy Emu to mount a second Macintosh disk. A helpful Lisa owner tried this exact experiment… and it didn’t work. The Lisa-as-Mac recognized that a disk was inserted, but complained that it wasn’t initialized, and offered to format it.

So why didn’t it work? I need to find the answer to that question before I even start worrying about tag bytes and other changes. My Lisa helper sent a few interesting screenshots, including the one above.

When booted using Macworks, the Mac OS on the Lisa includes a floppy control panel for something called the PFG, which I learned is the programmable frequency generator. Those control panel options look intriguing, but I’m not sure what they do. He tried normal and desperate modes with the same results.

From what little I could piece together, the PFG is an extra piece of hardware that not all Lisa 2′s have. If present, its purpose is to enable the Lisa to read floppies that were written in Macintosh II series computers that have three bit slip markers per sector. The bit slip marker is a special bit sequence on the floppy that helps the floppy controller get synchronized correctly. Apparently the Mac only needs 3 of them, although early Macs wrote 5 of them. The Lisa needs 5. With the Mac II series, the floppy logic was optimized to write only 3 bit slip markers, which made floppies written by those machines unreadable by the Lisa – hence the need for the PFG. I think.

The PFG shouldn’t be necessary when using a Floppy Emu, because the Emu sends at least 10 bit slip markers, and possibly as many as 55. So maybe there are too many, and that creates a problem? It shouldn’t be, given my knowledge of the Mac OS disk routines, if the Lisa is faithfully emulating a Mac.

 
Troubleshooting

To troubleshoot this, I need to find a way to get low-level floppy error data instead of just useless “this disk is not initialized” messages. Deep in the floppy routines, it knows if the read operation failed because it couldn’t adjust the drive speed properly, or couldn’t step to the desired track, or couldn’t find the sector on the track, or the sector checksum was wrong, or any of about 10 other possible failure reasons. There are a couple of ways I could do that:

1. I’ve already written a simple floppy testing program for the Mac. If I can get a Lisa with a hard drive and Macworks, I can copy the program onto the HD and run it from there. The trouble is, the generous soul who lives nearby and offered to lend me his Lisa doesn’t have an HD for it.

2. There’s a program called BLU (Basic Lisa Utility) that can be loaded from a floppy disk, and then used to run a variety of low-level tests, including floppy tests. The manual in appendix D shows the error info that’s provided, and it’s quite detailed. Unfortunately it’s sent to the serial port and not the screen, so I’d have to rig up a serial connection to another machine in order to see the output.

Without a hard disk, option 2 is really my only choice. But there’s another problem: I need a real floppy drive to load BLU from disk. But I need a Floppy Emu in order to test it. And the Lisa 2 only has a single floppy port. Hot swapping the drives is not an option. So I think what I’ll have to do is build a custom cable similar to my previous daisy chain adapter. This cable/adapter will allow the connection of two floppies drives to the same port, with both of them powered at the same time, and an external switch to control which one is enabled.

Other questions I’m unsure about:

• Does the Lisa have an IWM controller chip, like the Mac? I think it does. But possibly it’s clocked at a different speed.
• Is my understanding of the purpose of the PFG correct? Do all Lisas have one, or only some of them?

Assuming I can ever get this sorted under Macworks, then there are many other questions I’ll need to answer about tag bytes, the Lisa filesystem, and probably the DART disk image format. But getting Mac disks to work on the Lisa under Macworks is the first step.

Floppy Emu for Lisa progress report: I now have a firmware version that sort-of-works on the Lisa, when using Macintosh disk images, and running Macworks Plus on the Lisa. I can read from an emulated 400K Macintosh disk as well as write to it. From the limited testing I’ve done so far, it looks like the data is read and written correctly. But it’s not really usable as-is, and there are still some significant problems to overcome.

 
Bit Slip

The reason it wasn’t working yesterday appears to have been a problem with the way Floppy Emu generates something called bitslip markers. The data on a floppy disk is just one long string of bits, with no framing information to show where one byte ends and the next begins. The floppy controller only knows that disk bytes always have 1 as the MSB, so if it reads a byte where the MSB is 0, it means the framing must be wrong. It slips one bit, and tries again. To assist the floppy controller, disks normally contain a series of special 10-bit markers called bitslip markers, with the binary value 1111111100. After five consecutive bitslip markers, it turns out that the floppy controller will always end up with the correct framing, regardless of what framing it started with in the bit stream.

The trouble was that Floppy Emu wasn’t generating 10-bit 1111111100 markers, it was generating 8-bit 11111111 markers. This is one of those cases where you scratch your head and wonder how it ever worked at all, even on the Macintosh. Once I fixed the bitslip generation (I hope), Macintosh disk images started working on the Lisa under Macworks Plus. Woot!

 
Slowness

The biggest problem is that it’s slow. S… L…. O….. W…… After inserting a disk image through the Floppy Emu interface, it takes about 20-30 seconds before the disk icon appears on the desktop. And file copy operations take so long, you may as well go eat a sandwich while you’re waiting, even for files in the 10K size range. I’m guessing it’s still encountering a ton of low-level errors, causing the floppy controller to retry over and over, until it finally succeeds. So something is definitely still wrong.

I’ve been corresponding with a Lisa owner who’s got a Floppy Emu and Basic Lisa Utilities already set up, and he’s run a few tests for me. What’s strange is that this new firmware version is actually much worse than the old version, according to BLU. Despite the fact that this one actually works on the Lisa and the older one didn’t, this new version shows more disk errors in BLU, and more types of different disk errors. Hmmm.

 
Stepping Out

The other problem is that Floppy Emu on the Lisa is stepping to the wrong track for the desired sector… I think. On a 400K floppy, there’s only data on one side. There are 80 tracks, and each track has between 8 and 12 sectors. Each sector is 512 bytes. So 512 bytes per track times an average of 10 sectors per track times 80 tracks = 800 sectors and 400K. I’ve written a simple utility program where I can type in the sector number I want to read, and it fetches the data from the floppy and displays it, along with any error code returned by the read operation. With a 400K disk, if I request the last sector (number 799), it should step to the last track (track 79).

I can see the current track number on the Floppy Emu LCD, so I can verify whether it’s doing the expected thing. And when tested on a Mac Plus or a Mac SE, the Floppy Emu with a 400K disk image does what it should: it steps to track 79. But on the Lisa, under Macworks, when requesting sector 799 the Floppy Emu consistently steps to track 35 and returns bogus data. What the heck?

It turns out that track 35 is exactly where you’d expect to find sector 799, if the disk were a double-sided 800K disk. So maybe the Lisa is somehow confused, and thinks there’s a double-sided disk and drive present. But if this were the case, reading and writing files from the disk through the Finder shouldn’t work at all – it should be hopelessly broken. Yet as far as I can tell, it works, just very slowly. Could there be something about my testing program that’s flawed? I just don’t know.

It’s also possible this stepping weirdness is some kind of problem with the particular Lisa I’m using for testing. From what I’ve learned, the Lisa originally supported 400K floppies only. Later an 800K upgrade kit became available, which included a new 800K-compatible ROM chip for the Lisa’s IO board. I’m running Macworks Plus on the Lisa, which is supposed to make the Lisa act like a Mac Plus, which had an 800K drive. But if this Lisa doesn’t have the 800K ROM chip on its IO board, maybe using Macworks Plus will cause this kind of strange stepping problem.

 
Download

If you’ve got a Lisa and a Floppy Emu, and want to test this out, you can download a few different firmware variations here. There’s a single CPLD firmware file (firmware.xvf), and a few different AVR firmware files (femu.bin), each of which uses a slightly different strategy for bitslips. In my tests, the “address to data gap size 20″ AVR firmware doesn’t work, but all of the others one do. But they’re all very slow. If you try it, please let me know how this firmware works for you, as well as the details of your Lisa hardware and software configuration. Thanks!

I always operate my computer on a mahogany desk, while wearing a suit and tie. Don’t you?

There’s been no progress on the Lisa disk emulation itself since my last update, but I’ve spent some time getting the Lisa into a state where I can collect better floppy diagnostic information. The BLU Basic Lisa Utility seems to be the best tool available for this.

 
BLU Setup

BLU isn’t an application, but is a “bare metal” program that loads instead of the operating system. As I mentioned previously, the tricky part with BLU is that it needs to be loaded from a real floppy disk, but I also need to connect the Floppy Emu in order to run tests on it. The Lisa only has one floppy port, and I don’t want to hot-swap the drives.

I finally decided to install BLU to the Lisa’s hard drive. I’d been resisting that solution, since a BLU hard drive install wipes out anything else on the HD, which makes it impossible for me to run further Macworks tests. That’s not great, but because it would enable me to run BLU from the HD while testing a Floppy Emu on the floppy port, I decided it was the best option available. After reading the BLU documentation, I learned that the HD install option is in the “miscellaneous” sub-menu, accessed by pressing M from the main menu. But wait a second – the M key on the Lisa’s keyboard is broken! Argh! No HD install for me.

So instead of installing BLU to the hard drive, I switched to my backup plan and built a two port floppy drive adapter with an external enable switch. This adapter connects power and the computer’s floppy outputs to both drives, with a manual switch to control whether the computer’s enable output is connected to drive 1 or drive 2. The read lines from the floppy drives are connected together, but that should be OK since only one drive will be enabled at a time. That’s similar to how the external and internal floppy drives are connected on a Mac.

Not wanting to risk damaging the Lisa if the adapter was flawed, I tested the adapter on a Mac SE, with one 400K drive and one Floppy Emu. It mostly worked, and I could use the switch, and the computer would only see the drive that was enabled with the switch. But there were some weird problems too, like disks sometimes becoming unreadable or failing to eject. I had almost given up on the adapter, when I realized the problem was that I’d combined a real 400K drive with a Floppy Emu that acted like an 800K drive. So from the computer’s point of view, the type of drive would magically change when I flipped the switch, causing badness. After changing the Floppy Emu firmware to identify itself as a 400K drive, it worked fine.

Now I can use the adapter to connect both a 400K drive and a Floppy Emu to the Lisa, though only one drive can be used at a time. I can boot BLU from a real floppy disk, then switch over to the Floppy Emu to run tests. Great! Unfortunately I can’t actually see the results of BLU’s floppy tests. It sends the test results to the serial port, not the screen. I’ve ordered a DB-25 to USB serial cable, but it’ll be a couple of days before it arrives.

 
Binary Hacking

Meanwhile, about that broken M key… it turns out that I still need access to BLU’s (M)iscellanous menu in order to turn on verbose output from the floppy tests. And short of getting a new Lisa keyboard, the only solution was to patch BLU to use a different keyboard shortcut to access the menu.

BLU is distributed as a DiskCopy 4.2 image file. I opened the file in a hex editor under Windows, and found where the menu options were stored, and the table of keypress values for each option. I hacked the code to use B for the miscellaneous menu, instead of M, and saved my work. Success! Except now the checksum on the image file was wrong, and DiskCopy 4.2 refused to load it.

Undaunted, I searched the web for some existing tool that could fix DC42 checksums, or ignore the checksums, or at least tell me the values of the stored and computed checksums. I found nothing. I couldn’t even find a good explanation of the checksum algorithm, the only reference being a one-sentence description on the DiskFerret wiki. I finally gave up on finding an existing tool, and wrote my own program to compute DC42 checksums, experimenting with it until the values it computed matched the stored checksums in some known-good DC42 image files. I used my new program to manually fix the stored checksum in my patched version of the BLU image file, and all was well. There must have been an easier way to work around a broken M key!

 
Floppy Tester Tool

In addition to BLU, the other weapon in my arsenal is a Macintosh program I wrote during Floppy Emu’s original development, and which I described in my previous post. This testing program has a few problems on the Lisa, when running under Macworks. After some experiments, I learned that it doesn’t work on Macs with a 64K ROM (the Mac 128K or Mac 512K), nor on the Lisa with an emulated 64K Mac ROM using Macworks XL. The program opens, then immediately closes again, with no error message reported. More experiments showed that it worked fine with a 128K ROM (Mac Plus). When the Lisa was updated to use Macworks Plus with an emulated 128K ROM, the testing program worked. However, I suspect that the combination of Macworks Plus and 400K IO ROMs in the Lisa I’m using is causing some problems of its own. A much better solution would be to understand why the program doesn’t work with 64K ROMs, and fix it.

So why doesn’t it work? My best guess is that it’s some glue code being automatically inserted by the Metrowerks Codewarrior 6 compiler I used to build the program. I don’t remember exactly when Codewarrior 6 was current, but it’s probably 10-15 years newer than those early Macs with the 64K ROM, and so it’s easy to imagine it would assume the target machine had at least a 128K ROM. In fact I know of one example of this already, where Codewarrior automatically includes calls to the StripAddress() trap, which is supposed to make sure addresses are 32-bit clean. But this trap doesn’t exist on old ROMs and old system versions, so programs built with CW6 will mysteriously crash. StripAddress() isn’t even needed on those systems, because they always run in 24-bit mode. The solution I’ve found is to open the compiled program in ResEdit, open the CODE resource, and replace instances of 0xA055 (StripAddress) with 0x4E71 (NOP instruction).

A better solution would be to rebuild the test program with an older compiler that’s more likely to be 64K ROM friendly. Keith Kaisershot kindly did this using Think C 5.0. I haven’t yet had a chance to try his new version, but I hope to give it a shot after I finish up this progress report.

 
BLU Testing

I’ve also been mulling over possible explanations for the BLU test results reported by my remote Lisa pen-pal. It looks like the Lisa is finding the start of the sector’s data section OK, but runs into errors at the data checksum or the data end signature, so something is going wrong midway through the sector data. Possible causes I can think of:

1. It picked up a false data start signature in the middle of some other data, while the floppy controller was out of sync. This might happen occasionally, but it should be rare. I doubt this is the problem.

2. The bit rate sent by the Floppy Emu doesn’t match the bit rate expected by the Lisa. The Emu sends at exactly one bit per 2.0 microseconds. On a real Macintosh and floppy drive, it would be 2.04 microseconds, but this discrepancy never caused a problem. I doubt this is the problem on the Lisa, but it might be.

3. The Lisa is getting confused because the Emu doesn’t provide proper 10-bit bitslips. I don’t think this can be the answer, because it wouldn’t explain how the Lisa could so often read the start of a data section OK, but run into problems somewhere before reaching the end. The bitslip is something that happens before a sector, or between the sector’s address and data sections, but not in the middle of the data.

4. Electrical noise, reflections, ringing, or cross-coupling are screwing up the digital signal from the Floppy Emu to the Lisa, causing read errors. I tend to doubt this, since if it were a problem, it should be a problem on the Mac too. But maybe the Mac is more tolerant of noise, has different voltage thresholds or hysteresis on the inputs, so electrical noise simply doesn’t affect it as much. The scope should reveal this.

5. The structure of a single bit is not what the Lisa expects. When simulating a read, a 0 bit is sent by keeping the signal at whatever level it was previously, and a 1 bit is sent by a high-to-low transition. Some time after the high-to-low transition, but before the next bit window, there must be a low-to-high transition to prepare for a possible high-to-low transition on the next bit. The time delay between these two transitions is undefined, as far as I know, as long as it’s less than a bit window. I believe Floppy Emu does it half-way through the bit window, so a sequence of all 1 bits would be transmitted as a 50% duty cycle square wave. Maybe the Lisa hardware expects a different duty cycle? Comparing the Floppy Emu signal to a real drive on the scope might shed some light on this.

6. Something is interrupting the AVR microcontroller during its transmission of a sector, so it hiccups midway through and introduces an error into the data. I think this is the most likely explanation for the problems observed. But if it were a problem, it should be affecting the Mac too. Possible things that could interrupt or stall the AVR and cause a hiccup:

• It thinks the computer just switched to reading the opposite side of the disk.
• It thinks the computer just stepped to a different track.
• It thinks the computer just began a write operation.
• There is a code path where it takes longer to compute and prepare the next byte than the 16 microseconds it takes to send a byte.

That seems like plenty to think about for tonight.

For a while I’ve been struggling with occasional mystery bugs when making changes to the Floppy Emu AVR microcontroller firmware. I’ll make some seemingly innocuous code changes, and completely unrelated things will break. Frequently I’ll change something in a menu or other user-facing code, and suddenly the Emu will lose the ability to read the SD card, and insist there’s no card present. Needless to say, this makes development a real pain in the butt.

Today I found a perfect example of this behavior, where changing the max loop count in some code that’s not even executed would cause the Emu to lose access to the SD card. Buried in the code that simulates reading a floppy disk image is this:

#define INTER_SECTOR_GAP_SIZE 55
// lots of stuff omitted
for (uint16_t i=0; i<INTER_SECTOR_GAP_SIZE; i++)
{
  SendByteAndCheckRestart(0xFF);
}

What I found is that if I changed 55 to 56 or 65 or pretty much any other number, the Emu would suddenly become unable to read the SD card. What’s strange is that this for loop isn’t even executed during Emu startup, where the SD problem occurs. And just changing a single constant from 55 to 56 shouldn’t change the size or location of the compiled code, or anything else that might reveal previously hidden memory-related bugs. But it was extremely reliable: 55 always worked fine, 56 could never read the SD card.

Determined to find an explanation, I grabbed the binary diff tool VBinDiff and used it to compare the two compiled .hex files. I fully expected the files to be identical, save for a single byte that was 0×47 in one version and 0×48 in another version. But I was stunned to find the two files differ in hundreds of places! There are at least a hundred single-byte differences, as well as whole blocks that are different between the two. Thinking maybe I was getting different compile results from one compile to the next, due to a compiled-in timestamp or something weird, I tried compiling the same source code twice and comparing the results. They were identical. But if I changed the loop count, I got a hugely different result. And somehow that result was causing an SD card problem.

At the moment I don’t have any explanation for this, except maybe for some kind of compiler optimization that kicks in after 55 something-or-others. If you’re curious, you can compare the two .hex files yourself: floppyemu-55.hex, floppyemu-56.hex. The hex files show exactly what will be programmed into the ATMEGA1284′s flash memory.

I’ve been crawling slowly closer to a working floppy emulator for the Apple Lisa, using my existing Floppy Emu hardware. I’ve now got something that’s broadly usable for emulation of Macintosh disks on the Lisa 2/10, when running under the Macworks environment, though it’s still far from perfect. The next step will be emulation of native Lisa floppy disks, so the computer can boot from the Emu and use it from within the Lisa Office System. Things are looking promising!

 
Setup

So far, most of the effort has gone into getting my borrowed Lisa to the point where I can actually run floppy tests. Initially it seemed no setup would be necessary – just plug the Floppy Emu into the Lisa, and see if it works – but reality has proven different:

• Create a hacked version of Basic Lisa Utility that doesn’t need the M key (my M key is broken)
• Buy/build a Lisa-to-PC serial cable to capture the BLU log data
• Build a custom floppy drive A/B switch, so I can connect a real 400K drive and a Floppy Emu at the same time
• Rewrite my floppy tester utility program in Think C 5.0, to avoid a mysterious crash bug on the Lisa

In order to capture the log data from BLU, I needed a serial connection to the Lisa. I ordered this USB-to-DB9 serial adapter, along with a separate DB9-to-DB25 adapter, and waited impatiently for them to arrive. After receiving the adapter, I connected the Lisa up to my Windows 7 PC, and of course it didn’t work. The link appeared totally dead, and nothing I did on one computer was seen by the other.

I’d been corresponding by email with a few Lisa experts, and one of them pointed out what I should have realized about the serial connection: I needed a null modem connection, not a straight serial connection. Serial cables have separate TXD and RXD lines for transmit and receive, and in normal usage the computer will transmit on TXD and receive on RXD, while the peripheral will receive on TXD and transmit on RXD. But with my Lisa-to-Windows hookup, both ends thought they were “the computer”, so both were trying to transmit on TXD. Argh!

I looked into buying a null modem adapter, which would also have required getting a gender changer too. But I got impatient, and finally just built my own solution out of some jumper wires to swap TXD and RXD. It works.

 
Emulation

The best diagnostic tool I’ve found is the floppy tester function of BLU, which generates sector-by-sector debug info. There are some categories of disk problems that BLU doesn’t report, such as drive speed adjustment problems and synchronization problems, but it’s still the most powerful tool for the job.

I’ve been corresponding with two people who own Lisas and Floppy Emus, and the three of us have been testing various Emu firmware versions and comparing the test results. With the latest “Lisa Emu” firmware, the emulation doesn’t work at all on a Lisa 2/5, but does work on a 2/10. These two Lisa models have completely different floppy controller hardware that should be functionally equivalent, but some hidden difference is clearly important here. More on that later.

On the Lisa 2/10, we discovered that the Emu firmware routine that generates the 10-bit bitslip marker wasn’t working. The bitslip marker is used by the floppy controller to find the correct byte-to-byte framing in the floppy data serial bitstream. After fixing that, the emulation started worked on the Lisa, but very slowly. There were clearly still lots of floppy errors happening, slowing down the I/O, even though it eventually succeeded.

 
Disk Rotation Speed

When testing with BLU, doing a sequential read of all the sectors on the disk, it appeared to freeze for about 15 seconds before reading the first sector on each track. BLU didn’t report any errors, but there was clearly something wrong. After some discussion with my remote Lisa testing partners, we began to suspect this was a problem with the simulated rotation speed of the emulated disk, and we were right.

With an Apple 400K floppy disk drive, the drive spins at different speeds depending on which track is being accessed. The disk is divided into five speed zones, with five different rotational speeds ranging from 394 to 590 RPM. The computer directly controls the drive’s rotational speed by modulating a signal called PWM, and the drive indicates its current speed with a signal called TACH. So the computer sets PWM, then reads TACH and verifies that the desired rotational speed has been reached. If the verification fails, a Macintosh will report error -79: “can’t correctly adjust disk speed”. But what will a Lisa do?

The Floppy Emu doesn’t actually use the PWM signal, but instead it sets the TACH value directly, based upon which track is accessed by the computer. I tried modifying the Emu firmware to generate an obviously wrong TACH, and the behavior on the Lisa was unchanged. It still wasn’t reporting any errors, but the 15 second pause at the start of each track was still there. This told me that the TACH value was probably wrong all along, and that the Lisa was waiting about 15 seconds on each track for the TACH speed to become correct, then giving up and attempting the I/O anyway.

I blindly experimented with different formulas for TACH. Make it faster? Slower? Change the speed by a percentage, or by a constant offset? After lots of trial and error, I found that scaling TACH by 2.5% across the board made all the 15 second pauses disappear. So in effect, the Emu is reporting that the drive’s rotational speed is 2.5% faster than the spec. Why is this necessary? I honestly have no idea. The revised formula is almost certainly still wrong, but it seems to work well enough for now.

 
Inter-Sector Gap and Interleave

The sectors on a normal Macintosh disk are interleaved 2:1, with a short gap of dead space between sectors. Conceptually it looks something like this timeline view:

0000000000.6666666666.1111111111.7777777777.2222222222.8888888888 etc.

The 2:1 interleave means sector 6 follows sector 0, then come sectors 1, 7, 2, 8, 3, etc. The gap between each sector is about 10% the duration of the sector itself. The purpose of the interleave is to get the fastest possible I/O speeds when doing sequential reads of many contiguous sectors, allowing for some amount of CPU processing time after reading each sector that wouldn’t be possible with a 1:1 interleave.

For a sequential read of many sectors and a correctly tuned interleave, after locating the first sector on a track, the floppy controller should see zero unwanted sectors go by before the next desired sector appears. But I discovered that for BLU’s sequential read test, the floppy controller was almost always seeing 11 unwanted sectors before the desired sector appeared. There are 12 sectors per track on this region of the floppy, so 11 unwanted sectors meant the Lisa was just missing the desired sector, and had to wait for an entire rotation of the simulated disk (11 more sectors) before the desired sector rolled around again. In short, this meant it needed a higher interleave than 2:1. But that couldn’t be right, because real Mac disks are interleaved 2:1, and the Lisa under Macworks can read them without problems.

I wasted a lot of time experimenting with different interleave values, and different gap sizes between the sectors. Eventually I found a combination that led to zero unwanted sectors after the first sector of the track, but it required a huge and unrealistic inter-sector gap size. And while it made the BLU floppy test results look better, it actually performed worse in real-world tests, copying files under Macworks.

Finally I had the idea to repeat the BLU floppy test with a real floppy disk and drive, and observed the same 11 unwanted sectors before the desired sector. Aha! This told me the issue was actually with the BLU test, and not with the Floppy Emu firmware. BLU must be doing a non-trivial amount of CPU computation or other I/O after each sector, more than is normally performed by the OS during a sequential read, so that by the time it’s ready for the next sector, the desired sector has already rotated past. I reverted all of my changes, and put the inter-sector gap size back where it was originally. The BLU results got worse again, but real-world performance under Macworks improved noticeably.

 
Recalibrations?

One more mystery remains unsolved. In all of my BLU tests, the reported value for recalibrations (Rcl) is always 4C. For one of the other testers, it’s always 02. I’m not sure yet what the third tester is seeing for Rcl. The BLU manual appendix D says Rcl is “recalibrations remaining”, and that an operation normally starts with 1 recalibration remaining and counts down from there – so both 4C and 02 are anomalous. What’s the significance of this? It needs more investigation.

 
Real-World Tests

Using a Lisa 2/10 system, I booted Macworks XL from the Lisa’s hard drive. By holding down the left option key, I told Macworks to initialize the Macintosh environment, but wait for a floppy disk to actually boot the Mac OS. Using a real 400K floppy drive and disk, I booted System 3.2, measuring the time from disk insertion to ready desktop at 37 seconds. Then I repeated the same experiment with Floppy Emu and a disk image of System 3.2, and measured it also at 37 seconds. So it works! No more mysterious slowdowns: Floppy Emu on the Lisa performs at the same speed as a real floppy.

As a second test, I booted Macworks from the Lisa’s hard drive, then used Floppy Emu to insert a 400K disk image containing MacPaint and MacWrite. The disk image appeared on the desktop within a few seconds of inserting it, and copying MacPaint from the Emu to the Lisa’s HD only took a few seconds more. I was also able to copy files from the HD back to the emulated floppy disk without problems. Given what I’m seeing in these tests, the current firmware should provide a fully usable and full-speed floppy emulation for the Lisa under the Macworks environment.

 
Try It

If you’ve got a Lisa and a Floppy Emu, you can try the new firmware yourself. I’ve named this firmware version lisa-emu-1.0S3-F11, and it contains all the fixes and adjustments described above in order to make Macintosh disk emulation work on the Lisa in the Macworks environment. Native Lisa floppy emulation still isn’t implemented, but I hope to tackle that soon.

Lisa floppy drive emulation with Floppy Emu is a success! Begone, evil rotational disk drives, with your failure-prone gummed-up mechanisms. The age of SD card Lisa floppy emulation is here!

After a lot of tinkering, it’s now working on both the Lisa 2/5 and 2/10, and for both Lisa-format and Mac-format disks. I’m able to boot the Lisa from the emulated floppy drive, and use it to install Lisa Office System and other apps to the HD, and copy apps and data files from the Lisa HD to the emulated floppy drive. It also works for Mac-format disks, when running the Lisa under Macworks.

The final hurdle was realizing that the custom adapter I’d built to simultaneously connect a 400K floppy drive and a Floppy Emu was causing problems. After getting rid of the adapter and connecting the Emu directly to the Lisa, in place of the normal floppy drive, it’s now working perfectly.

 
Disk Copy 4.2 Format

From the previous Lisa firmware that I described in an earlier post, the last big piece of the puzzle was adding support for “tags”. On a Lisa floppy disk, a sector consists of 512 bytes of data and 12 bytes of tags. Raw disk image files don’t save the tag info – they’re just a byte-by-byte copy of the 512 data bytes from each sector. So in order to correctly emulate Lisa-native disks, it was necessary to use a disk image format that preserves tags: Disk Copy 4.2 images, the format I love to hate.

Floppy Emu already supported DC42 format image files for use with the Macintosh, but they were treated as read-only disks by the emulator firmware. The problem with tagged DC42 images is that the logical sector data isn’t aligned in the image file, nor in the FAT32 filesystem of the SD Card, and the sector tags are stored separately from the sector data. So to load a single sector of the emulated floppy (512 bytes data plus 12 bytes tags), it’s necessary to load three or sometimes four 512 byte sectors from the SD card, depending how the data and tags for that particular sector are aligned. It’s a pain in the butt.

Writing DC42 images is more complicated still, which is why previous firmware treated DC42 images as read-only. To perform the unaligned writes, the firmware must read a sector from the SD card, modify part of it, then write the modified version back. Again, this can involve three or four SD card sectors in order to write a single emulated floppy sector. SD cards really don’t like this pattern of read-write-read-write for single random-access sectors, so performance suffers a bit. But the new firmware code does its job, and writing to DC42 disk image files is now possible.

 
Checksums

The last unsolved item is DC42 file checksums. A DC42 image file contains a 32-bit checksum of all the data, and a separate 32-bit checksum of all the tags. If you attempt to load an image file with invalid checksums in Disk Copy 4.2, it will refuse to open it. Floppy Emu doesn’t care about the checksums, but there can be a problem if you copy a modified DC42 image file off your SD card, and try to use it with Disk Copy 4.2 or another utility that does care about checksums.

What’s the best way to make sure the checksums are kept up to date, when the DC42 image file is modified? Now that I know the checksum algorithm, I can recompute the checksum easily enough, but when should I do it?

• It’s impractical to recompute and save a whole-disk checksum, every time any sector is modified.
  
  
• I can update the checksum when the disk image is ejected, but that’s dangerous because ejection is very often a prelude to auto power-off a moment later. It takes about 2 seconds to recompute the checksum for a 400K disk, and 4 seconds for an 800K disk. Usually the time between ejection and shutdown is less than that. If the Floppy Emu loses power while it’s writing the new checksum value, the SD card could become corrupted.
  
  
• I might recompute the checksum when the disk image is inserted, but that’s unintuitive. Re-insert the disk image, in order to fix its checksums? And for systems like the Mac that write the last mount time whenever a disk is inserted, the checksum would still always be wrong.
  
  
• I might add some new Floppy Emu menu option or feature to recompute the checksum on demand. But that’s a strange special case I’d like to avoid, and doesn’t feel like the right solution.
  
  
• I could do nothing, and let people fix up the checksums with an offline tool if they ever need to copy them off the SD card and reimport them to Disk Copy 4.2. This is my solution for now.

 
Try It

If you’ve got a Lisa and a Floppy Emu, you can try the new firmware yourself. I’ve named this firmware version lisa-emu-1.0S6-F11, and it contains all the changes needed to emulate Lisa-format and Macintosh-format floppies on the Lisa computer, and to boot a Lisa from the Floppy Emu board. 1.0S6-F11 contains some changes that aren’t compatible with early Macintosh models, so while you won’t hurt anything by trying it on a Mac system, it may not work. For best results, use the normal Mac firmware for Floppy Emu with Macintosh computers, and use 1.0S6-F11 only when working with a Lisa system.

I’ve merged the Lisa floppy emulation functions into the latest Mac version firmware, to create a super universal firmware! it’s a single firmware for Floppy Emu with support for Mac and Lisa, floppy and HD20, raw disk images and Disk Copy 4.2 images. It also brings the benefits of writable DC42 disk images to the Mac. Sorry, it does not make sandwiches or wash your car, but it does nearly everything else. Press the SELECT button while the Emu is displaying version info on the LCD, you’ll enter a config menu where you can choose to operate as a hard disk, Mac floppy drive, or Lisa floppy drive. The new hd20-0.7B-F14.5 universal firmware is available now.

A few other odds and ends:

 
Checksums

After some discussion, I’ve altered the strategy for updating Disk Copy 4.2 checksums. I still don’t have a good solution for keeping the checksums updated when the disk image is modified, but instead of leaving the old (wrong) checksums in place, this new firmware sets the checksums to zero upon the first write to a DC42 image. Hopefully this will make it clearer for some future archivist who may encounter the modified image file, and he’ll understand the checksum was intentionally zeroed, rather than the image file being corrupted.

dc42cksm – I wrote this simple command line program to view the checksums in a Disk Copy 4.2 disk image file, and optionally to update the checksums if they’re not correct. If you ever have some burning need to copy a modified DC42 file off your SD Card, and import it back into Disk Copy 4.2 on the Mac, this tool can fix up the checksums for you. It’s a Windows command-line executable, but the source code is also included if you want to recompile it for OS X or Linux.

 
Blank Disks

Todd Meyer pointed out that blank 400K disks created under Lisa Office System 3.0 and 3.1 aren’t usable under Lisa Office System 2.0. The difference seems to be similar to the distinction between MFS and HFS disks on a vintage Macintosh system, except I don’t think the Mac ever used two different filesystems for the same sized disk. Thanks to Todd for providing a working LOS 2.0 blank disk image, which I’ve included with the lisa-emu-1.0S7-F11 firmware (below), and for the femu-on-Lisa photo that appears above.

 
A Spare Firmware

In case any problems are discovered with the new universal firmware hd20-0.7B, I’m also releasing an updated version of the Lisa-specific firmware, lisa-emu-1.0S7-F11. This is identical to the 1.0S6 Lisa firmware that I released yesterday, except that the checksum in the DC42 image file will be set to zero upon the first write to the disk.

 
???

The Lisa computer is a strange beast. It was the first mainstream home computer to feature a GUI instead of a text-based interface. It’s been interesting working with the Lisa while I developed the new floppy firmware, and for a time I thought maybe I’d like to get a Lisa system of my own when the time comes to return this borrowed machine. But the Lisa never really grew on me, and I can’t exactly say I’ll miss it when I need to give it back.

Running the Macintosh OS under MacWorks isn’t too bad, except that the machine has twice the bulk and weight of a contemporary Mac system. It’s just… unwieldy. That’s not meant as a dig against the Lisa – pretty much all computers of that era were unwieldy by today’s standards – but it’s impressive how much slimmer Apple was able to make the Mac 128K just a year after the Lisa, using most of the same technology except for the internal hard drive.

From the viewpoint of someone in 2015, the native Lisa OS (Lisa Office System) is truly baffling, ugly, and awkward. I’m not surprised Apple had such trouble selling Lisa systems before MacWorks came along. As the first real GUI computer, it’s no wonder Apple didn’t nail it 100% on the first attempt, so I don’t fault the Lisa or its designers for that. It’s fascinating to see this example of an early GUI, in contrast with the continuing improvements that appeared later in the Mac and other GUI systems.

I’ve begun looking into the possibility of Apple II disk emulation with the existing Floppy Emu hardware. The recent research project into Lisa floppy emulation turned out well, so why not do it again with another vintage Apple computer? A cursory check of connector pinouts suggests it’s at least theoretically possible, though it would require major changes to the emulator firmware. But Rome wasn’t built in a day, so let’s start.

There are a confusing number of different Apple II family models and floppy drives. Some are 5.25 inch drives, and some are 3.5 inch. Some use a 19-pin D-SUB connector, and some use a 20-pin ribbon connector. Because of these differences, “Apple II disk emulation” won’t be a single emulator mode, but several different ones depending on the Apple II model and disk image being used.

This summary of Apple floppy drive models gives a nice overview. For the purposes of Apple II emulation, the drives can be organized into three categories: the venerable Disk II and its cousins (Disk IIc, Unidisk 5.25, Apple 5.25, Duodisk 5.25), the SmartPort-based Unidisk 3.5 (A2M2053), and the Apple 3.5 external drive (A9M0106).

 
Disk II Emulation

Emulation of low-density 5.25 inch Apple floppies would be useful for the Apple IIe and earlier models. These computers used a Disk II controller card in an internal slot. The controller card has two 20-pin ribbon connectors, each of which can be connected to a Disk II drive. The pinout of this 20-pin connector is almost identical to the pinout of Floppy Emu’s 20-pin connector. So with the right firmware (five words that gloss over a huge amount of work), you could plug a Floppy Emu directly into the controller card and emulate a Disk II floppy drive. Or plug two Floppy Emus into each of the two controller card connectors, and emulate two drives. With a custom multi-ended cable, it might even be possible to emulate two drives with a single Floppy Emu.

The only obvious mismatch is at pin 20. On the Mac, PWM is an output that controls the rotational speed of the 400K floppy drive. But on the Apple II, WPROT is an input that indicates whether the disk is write-protected. So depending on the emulation mode, pin 20 on Floppy Emu would need to behave like either an input or an output, and that’s a problem. The Emu uses a CPLD to interface with the computer, and it’s easy enough to modify the CPLD to change a pin between acting as input or output. But in practice this would be problematic and dangerous.

Let’s say your Floppy Emu board was configured in Apple II mode, and you plugged it into your Mac, with the intention of switching it to Mac floppy mode. But before you could even access the mode select menu, you’d have two outputs fighting each other on pin 20, possibly damaging the Floppy Emu, the Mac, or both. You could work around this problem by connecting the Emu to and Apple II and then switching to Mac floppy mode from there, but it would be an awkward and error-prone process. Some kind of passive adapter could probably solve this problem, with an inline resistor on pin 20, but I’d prefer to find a solution that doesn’t require extra hardware.

To complicate matters a bit more, there are two different standards for Apple 5.25 floppies. DOS 3.2.1 and earlier stored 113.75 KB per disk, 256 bytes per sector, 13 sectors per track, 35 tracks per side. But DOS 3.3 and later used a more efficient GCR encoding to store 140 KB per disk, 256 bytes per sector, 16 sectors per track, 35 tracks per side. As I understand it, this change also required a new version of the Disk II controller card. Was the newer one backwards compatible with the old format? Then there was ProDOS, which I believe used the same low-level format as DOS 3.3, but with a different filesystem. So Disk II emulation might actually involve two or three separate emulation modes, depending on the specific disk image being used.

The later cousins of the Disk II switched to a 19-pin D-SUB connector instead of the 20-pin ribbon connector, but the drive itself remained basically the same. The 19-pin connector pinout matches Floppy Emu’s 19-pin connector just as well as the 20-pin, with no problems except the collision of PWM and WPROT on the same pin. That means it should be possible to connect a Floppy Emu in Disk II mode to an Apple II with a 19-pin controller card, or with a 19-pin external floppy port such as found on the Apple IIc.

 
SmartPort: Unidisk 3.5

Next we have the Unidisk 3.5, an 800K floppy drive using the SmartPort communication protocol. Unlike the “dumb” Disk II, the Unidisk 3.5 was an intelligent device, communicating with the Apple II using a high-level request/response protocol that abstracted away the details of tracks and sides. From what little I’ve read about SmartPort, it sounds fairly similar to the HD20 protocol that I implemented a few months back for the Mac. It looks like there are already a couple of SmartPort-based disk emulators out there: UNIDISK and an SmartportCFA. That gives me hope that the SmartPort protocol wouldn’t be too difficult to implement.

Here’s where my understanding of things starts to get fuzzy, so if I say anything here that sounds incorrect, please let me know. It looks like the Unidisk 3.5 works on the Apple IIc, but only with certain ROM versions. There’s also a sub-model called the Apple IIc+, but I’m unclear if that’s anything more than a ROM upgrade, or what disk-related features the IIc+ offers over the IIc. The Unidisk 3.5 is also supported on the Apple IIgs, but it’s not recommended, because the performance is worse than can be achieved with non-SmartPort drives.

Did Apple ever sell other SmartPort drives, besides the Unidisk 3.5? I saw one source that mentioned SmartPort could support up to four drives per connection, and up to 32 MB per drive. If that’s true, could a SmartPort implementation on the Floppy Emu provide pseudo hard drive capability to the IIc and IIgs? I’m not sure.

How does the IIc or IIgs detect that a connected drive is a SmartPort drive, as opposed to a dumb 5.25 drive, or a non-SmartPort Apple 3.5 drive? Maybe it just sends a SmartPort request, and checks to see if anything responds. Or maybe there’s a pin that’s used to sense the drive type. The docs refer to a /3.5DISK signal on pin 4 of the 19-pin D-SUB, though I’m unclear how it’s used. More on this later.

Comparing the pinouts of the Floppy Emu 19-pin D-SUB connector with the Apple IIc and Apple IIgs, they mostly match up, but there are some noteworthy differences. There’s some disagreement about the published pinouts too, depending on which source you trust. I believe these are correct, and the Apple IIc+ is the same as the IIgs:

There’s the same collision between PWM and WPROT that we saw previously, and I’m still not sure how best to resolve it. Then there’s this /3.5DISK signal on pin 4 of the IIc+ and IIgs, where others have an extra ground pin. What the heck? How is that used? Is it an input, an output, or both? The usage of pin 16 varies, but that shouldn’t cause a problem for the Emu, assuming the firmware is changed appropriately.

The biggest discrepancy is at pin 9, which isn’t physically connected on the Floppy Emu board. This is some kind of external interrupt on the IIc, which I think can be safely ignored. But on the other systems, pin 9 is used to select the second drive in a two-drive configuration. That means the Emu will be limited to emulating only a single drive, which is probably fine since that’s all it does anyway.

Incidentally, if you have a Unidisk 3.5 drive, you can remove its drive mechanism and substitute a Floppy Emu in its place. Combined with the Unidisk 3.5′s internal daisy-chain board, this combination works today with the current firmware, on the Apple IIgs (and presumably also the IIc+) for 800K disk emulation. See Bryan Villados’ example on the Apple II Enthusiasts group.

 
Apple 3.5 Drive

Last of the bunch is the Apple 3.5 Drive. Unlike the others, this drive functions on the Macintosh as well as on Apple II systems. It is not a SmartPort drive. How does that bit of magic work? I wish I understood it. Internally it’s the same Sony 800K mechanism that’s in the Unidisk 3.5 and in standard Macintosh floppy drives like the M0131, so the difference is only in the interface circuitry. I believe the Apple 3.5 Drive is supported on the Apple IIc+ and the IIgs, but it may also be supported on the standard model IIc – source seem to conflict on this point.

How does the computer know that an attached floppy drive is an Apple 3.5 Drive, and not a Unidisk 3.5 or other SmartPort drive, or a dumb 5.25 drive? I’m not sure, and the lack of documentation is frustrating. You can’t just plug a Macintosh floppy drive directly into a IIgs, so obviously there’s some difference in the way it identifies itself to the Apple II, but what is it? If I can find the answer, then I think the existing Floppy Emu firmware should work as-is for Apple 3.5 Drive emulation on the IIgs and IIc+.

 
/3.5DISK Mystery Signal

The biggest mystery at the moment is how an Apple II system can detect what type of floppy drive is connected, and this /3.5DISK signal on pin 4 seems to be part of the answer. For detecting the difference between a dumb 5.25 drive and a SmartPort Unidisk 3.5, I think /3.5DISK must be irrelevant, because the standard model Apple IIc lacks the /3.5DISK signal but can still use a Unidisk 3.5 drive. Also, SmartportCFA successfully emulates a SmartPort drive, and doesn’t even connect pin 4. My guess is the computer sends some kind of SmartPort “init” command that will fail in a predictable way on a dumb 5.25 drive. Exactly how that works will have to wait for a deeper investigation of the SmartPort protocol.

Most likely, the /3.5DISK signal is used only for detecting the Apple 3.5 Drive. If the Unidisk can be detected by a SmartPort query, then /3.5DISK is probably only for distinguishing between an Apple 3.5 and a dumb 5.25 Disk II drive. That sounds easy enough, but when I start to look at the details, I quickly get lost.

First: is /3.5DISK 0 for 3.5 inch drives and 1 for 5.25 drives, or vice-versa? Most sources refer to it as /3.5DISK or 3.5DISK*, both of which imply it’s an active low signal where 0 means it’s asserted, so 0 should mean to enable the 3.5 drive. This is also consistent with the fact that the Macintosh has pin 4 permanently tied to ground, and in order for the Apple 3.5 drive to function on a Mac, it would need to interpret the 0 volts on pin 4 as the assertion of /3.5DISK. However, this discussion from comp.sys.apple2 says it’s actually the opposite: 0 enables the 5.25 drive and 1 enables the 3.5 drive. Maybe the writer is just mistaken, but I’m not so sure.

Second, and more fundamentally: is /3.5DISK an input, or an output? If the purpose is to detect what type of drive is connected, then it should be an input. None of the documentation I’ve seen actually specifies, but from a few odd comments and schematics, I’ve inferred that it’s actually an output. As best as I can determine, then, /3.5DISK acts more like a secondary enable signal than a drive type detection signal. When /3.5DISK is asserted, then the attached Apple 3.5 drives should respond, and when it’s not asserted the dumb 5.25 drives should respond. Combined with the /ENABLE1 and /ENABLE2 signals, this would provide a way to control two drives of each type, and four drives total (not counting SmartPort). But there’s a problem with this interpretation – the dumb 5.25 drives don’t know anything about /3.5DISK. They think pin 4 is a ground connection, so they’re not going to play along nicely. Obviously I’m missing something, because this just doesn’t add up.

The comp.sys.apple2 discussion that’s linked above further confuses the issue. It refers to /3.5DISK as “an extra enable” line, but also says “The Apple 3.5 drive uses this signal (on its daisy-chain connector) to sense whether a 5.25″ drive (or SmartPort drive?) is connected at the end of the chain.” In this context where it’s used to “sense” a drive’s presence, it sounds like /3.5DISK is an input. Maybe it’s actually some kind of clever circuit that’s both an input and an output, depending on the context.

A final question: what’s the difference between the Apple 3.5 drive and a standard 800K Macintosh floppy drive? The Apple 3.5 drive works on both an Apple IIgs and a Mac – how does it accomplish this? If the answer were only related to the /3.5DISK signal, and that signal was strictly an output from the IIgs, then a Mac 800K drive ought to happily ignore that signal and still respond to the /ENABLE1 signal, and work fine on a IIgs. But that’s not what happens, so there’s a piece of the puzzle I’m missing.

How can you deal with signals that might be inputs or might be outputs, in a way that’s safe and won’t damage sensitive electronics? In my last post I described three different types of Apple II family floppy drives. Since then, I’ve started looking further into SmartPort emulation for the Floppy Emu, which would extend 800K floppy and hard drive emulation support to the Apple IIc and IIgs. The required pinout on the D-SUB 19 pin connector is almost the same as what’s currently used by Floppy Emu, but not quite identical (inputs to the computer marked in bold):

Comparing the Floppy Emu pinout to the IIc and IIgs, a few pins must change from computer outputs to computer inputs. And a few other pins marked with * take on a new bidirectional behavior, being used both to control the floppy drive and to sense the type of the connected drive. All the non-power pins for Floppy Emu are connected to a CPLD, and can be switched from inputs to outputs with a firmware change, so by itself that’s not a problem. The trouble arises if you want to use a single Floppy Emu board on different computers at different times, functioning in different modes. If the Emu is configured for the wrong mode for the computer it’s presently attached to, it could damage both the Emu and the computer. Sooner or later somebody (or me) would make that mistake.

Let’s look at what this means for SmartPort emulation on an Apple IIc or IIgs. On the IIgs, pin 4 is no longer a ground pin, but instead is used to switch between Apple 3.5 drives and other types of drives. We’re not trying to emulate an Apple 3.5 drive yet, so we can safely ignore that difference and continue to use pin 4 as GND. On the IIc, pin 9 is an external interrupt. We don’t need that for SmartPort emulation, which is fortunate because it’s not even connected on the Floppy Emu end.

Pin 10 is the main problem. On the Mac, it’s an output from the computer, but on the whole Apple II line it’s an input. It either indicates the disk’s write-protect status (normal disks), or serves as an ACK signal (SmartPort). If the Floppy Emu is configured to output a WPROT or ACK signal on pin 10, and is connected to a Mac that outputs PWM on pin 10, the two chips will fight each other and cause damage. Zap!

Pin 16 is also a problem. On the Mac and the Apple II/II+/IIe, it’s either an output from the computer, or a +5V connection that will look like a constant logical 1 output. But a SmartPort device turns things around, and uses pin 16 on its daisy-chain port to determine if the next device in the chain is also a SmartPort device. It has an internal pull-up on the daisy-chain pin 16, and it checks the value on that pin. If it sees 0, that means the next device is also a SmartPort device, and if it sees 1 it means it’s not a SmartPort device or there is no device present. The IIgs may behave the same way, although I’m not sure. So in order for Floppy Emu to be detected as a SmartPort device, it may need to output 0V on pin 16. That’s another potential for two chips fighting. Zap again!

 
Playing It Safe

The question is how to make an Apple II SmartPort mode firmware for Floppy Emu, while avoiding potential electrical damage if you accidentally set the wrong mode on the wrong computer.

Caveat Emptor – I could do nothing. As long as you switched into Apple II mode after connecting the Emu board to an Apple II, and switched into Mac mode before disconnecting from the Apple II, you would never have two chips fighting on the same line. But that’s a poor solution. What if you borrowed a Floppy Emu from a friend for use with your Mac, and you didn’t know what mode it was in? Or you just plain forgot?

Physical Adapter – I could build a small passive adapter that sits between the computer and the Floppy Emu board. An inline resistor of about 100 to 330 ohms on pin 10 should prevent possible damage if two chips were fighting. The same solution would probably also work on pin 16, although correct functioning would depend on the value of the SmartDisk pull-up resistor and the logic threshold of the chip it used to sense the value of pin 16. But I’d really like to avoid requiring an adapter if I can. It would be so much nicer if you could just plug your Floppy Emu straight into your IIgs or IIc and have it work.

Detection – Maybe I could somehow detect whether the attached computer is an Apple II or a Mac, and only switch pins 10 and 16 to outputs after confirming it’s an Apple II. That sounds good, but how? Is there a way with the existing hardware that the CPLD could tell if pin 10 is being actively driven with some value, instead of just floating? Or maybe try to detect a SmartPort reset state before switching the pin directions? I’m not confident the SmartPort reset state won’t also be triggered accidentally by Mac drive logic like the HD20 control routines.

Button Push – I could require the user to push a button to “confirm” Apple II SmartPort mode, each time the Emu board was reset, before switching the pin directions. That would be a little inconvenient, and would still have some potential for damage if you pressed the confirmation button when you shouldn’t have. But it’s the best solution I’ve thought of thus far.

About six weeks ago, I made a post titled “The $11185 Connector”, about my search for the increasingly rare 19-pin D-SUB and the price quoted by one Chinese factory to manufacture them. This post attracted a lot of negative comments, and I eventually removed it, but the original post was republished here. The point of the post was that custom manufacturing of DB-19s was going to cost substantially more than I’d hoped, and given the small sales volume of Floppy Emu boards that need the DB-19s, it probably didn’t make economic sense for me to commission new manufacturing. Instead, I’d have to research possible DB-19 substitutes.

Earlier today, I discovered two more sites where that post was linked/republished, and a parallel discussion had sprung up without me knowing about it. That was strange and a little uncomfortable, like finding people talking about you behind your back. The themes of these commenters were similar to the comments on my original post:

1. Why are you using a DB-19? Don’t you know it’s obsolete? Your design is crap.
2. You’re doing it wrong.
3. You’ve a naive idiot.
4. You’re a racist asshole.

Some of these comments were understandable, if inflammatory, if you didn’t know what I was building and why. For the sake of any readers who don’t normally follow the BMOW blog, I use DB-19 connectors for a vintage computing product called Floppy Emu, which plugs into the external DB-19 floppy port of a 1980′s or 1990′s Macintosh computer. Apple chose the DB-19 back in 1984, and I’m stuck with it. The sales volume is fine for a hobby product, but very low by any professional standard. $11185 to manufacture a batch of new DB-19s would be more than an entire year’s net profit.

That’s not to say that $11185 isn’t a fair price for the work involved, or that Chinese manufacturers should work for pennies while I rest my feet on their backs and smoke a cigar. It’s a custom-made part, so there will be engineering setup costs involved before they can make anything, and of course they’ll expect me to pay those costs. That’s perfectly fair. In my naivety I hoped that existing DB-25 or DB-15 machinery might be easy to adapt for building DB-19s, so the setup cost might be only $1000 or so. Apparently that’s not the case.

A few people suggested I was foolish for using Alibaba to find D-SUB manufacturing contacts, saying that I’d never find the best price that way. That’s probably true, but being a single-person low-volume business, I don’t have a Rolodex of contacts at worldwide manufacturers whom I can phone up to ask for quotes. If there’s a better way to find possible manufacturing partners, I’d love to know about it.

Quite a few people linked sources for DB-19s that they found on the web. Unfortunately those leads were all dead-ends. There are at least a dozen electronics suppliers whose sites claim to have DB-19s in stock, but if you call them to place an order, you’ll find they don’t actually have them, or only have a handful. I’ve scoured the web pretty thoroughly, and bought all the large DB-19 supplies I could find. I may have overlooked some, but if so, they’re well-hidden.

A huge number of people suggested I take DB-25 connectors, which are readily available, and cut six pins off the end to make a DB-19. And for a one-off project for personal use, that might be the best solution. I don’t actually manufacture the Floppy Emu boards myself, though – they’re made in batches of ~100 at a time by an electronics assembly company. I spoke to them about the possibility of making DB-19s this way, and they weren’t enthusiastic. They were willing to try it, but believed it would be an awkward, error-prone, and manually time-intensive process that would yield inconsistent results.

 
Today

I eventually found a supply of 500 old stock DB-19 connectors in Eastern Europe. Depending on the Floppy Emu sales rate, which fluctuates wildly, this should last me anywhere from three months to a year or so before another “DB-19 crisis” hits. So what then?

After more research, I also found another D-SUB manufacturer whose bid was significantly cheaper than the first one. Buying DB-19 connectors from them would still be a very large expense, and would require pre-purchasing 5 or 10 years worth of supply, requiring a lot of faith in the long-term sales prospects of Floppy Emu. But if I can’t find another good option, this may be the best solution.

I also worked on a couple of possible DB-19 substitutes, pictured below. They’re just 19 pins sticking out of a custom-made PCB, with a cable connector on the back. They work, but they lack the surrounding shield of a normal D-SUB, and don’t look very professional. I used a pair of rectangular LEDs as alignment guides!

The version on the left uses individual D-SUB crimp pins, with the crimp portion cut off each one. It’s a bit of a hassle to assemble, soldering it is awkward, and it costs $4 for the pins alone. But the result fits well in the D-SUB socket. The version on the right uses standard 0.1″ square pin header. The pin spacing isn’t quite right for a D-SUB and the pins are supposed to be round and not square, but the result is close enough that it seems to work fine, and it’s less hassle to put together.

The most promising lead is from IEC, a vendor of cables and connectors that used to sell DB-19s before they exhausted their stock. On two occasions, their salespeople told me DB-19s were discontinued and they wouldn’t be getting any more. But I later received email from someone at the company saying they were working on getting more DB-19s, using some kind of new manufacturing process. In fact, during the time I’ve been typing this post, I received another email from him saying they expect to have something available by June! Assuming we’re talking about the same part, and the price is similar to what it was before, that could be the answer I’ve been looking for.

On the road to Apple II floppy disk emulation, I’ve picked up a couple of new members for my retrocomputing collection. Above is a classic Apple IIe – let’s call her Edna. The eBay seller didn’t believe much in bubble wrap or other packing materials, so Edna suffered a cracked corner and bent bottom plate during shipping, but she still works just fine. Below is a boxy fellow I’m calling Gary, an Apple IIgs with ROM revision 01. I also picked up an Apple 3.5 Drive and a 5.25 Drive, and some blank double-density disks. None of the computers or drives came with any bootable disks, though – a fact that would soon create trouble.

 
Apple II Video Out

When powered up, both computers beeped and seemed to be working OK, but without a monitor I was working blind. The IIgs has an RGB video port that looks like the video connector on a Macintosh II, but none of my Mac video adapters could get any picture from it. I later learned it’s an analog RGB signal at TV frequencies, not VGA frequencies, and is unlikely to work with anything but a true IIgs monitor or a few other CRTs from the 80′s. That meant I was stuck with composite video for both machines – that yellow RCA plug that harks back to the days of Nintendo NES.

What do you connect a composite video signal to in 2015? I tried my living room TV and it worked fine, but I wanted a desk-sized monitor instead of a 40-something inch HDTV. I tried the composite video input on my Dell 2007WFP LCD monitor, but got nothing but a blank screen. Hmmm. After doing some reading, I learned that the composite video output from the Apple IIs isn’t quite NTSC standard, and the 2007WFP rejects marginal video signals like the Apple’s. The similar Dell 2001FP LCD monitor was reported to work well with Apple IIs and other vintage computer equipment, though, and I was lucky to find someone local selling an old 2001FP. Success! Now, anybody want to buy a used Dell 2007WFP?

 
Bootstrapping with No Disks

With working video, I could boot Edna and Gary, hit control-reset, and have fun typing “STEVE IS GREAT” programs in BASIC. But to really do anything interesting, I needed some disks. For the IIgs, I discovered that you can download a Disk Copy 4.2 image file of IIgs software, use a vintage Mac to write the image to a 3.5″ disk, and the IIgs will happily boot from it. That was great, but it still left me without an easy way of transferring or making 5.25″ disks, or any way of making disks directly with Edna.

Fortunately there’s an excellent piece of software called ADTPro, that can be used to bootstrap an Apple II computer without any other hardware. It works by connecting to the Apple’s cassette in port or serial port, and transfers disk images from a server on a modern PC. Less fortunately, the IIgs doesn’t have a cassette input port, and Edna didn’t come with a serial card. I also didn’t have a Mini-DIN-8 to DB-9 serial cable for making a serial connection to Gary, so that left a cassette port connection to Edna as the only option.

To make a long story short, the ADTPro cassette audio method didn’t work. The first part of the bootstrap process went fine, and I could load the ADTPro client on Edna using the cassette link. But to actually transfer any disk images required two-way communication using two audio cables: one from the PC’s headphone out to the Apple’s cassette in, and another from the Apple’s cassette out to the PC’s microphone in. I’ve only got one PC that even has an analog audio input, and the line level was too low for the ADTPro software to hear the data coming from the Apple. No amount of config changes or level boosting seemed to help. After reading about it, this appeared to be a common problem.

I finally broke down and hand-built a Mini-DIN-8 to DB-9 serial cable for the IIgs, using an Imagewriter II printer cable and a DB-9 cable. It was a lot of fiddly soldering and beeping out wires and swearing at burnt thumbs, but I eventually got it to work. Of course, I learned later that I could have just bought a pre-made cable that’s designed for use with ADTPro. Oh well. With a working serial connection, I can now transfer both 3.5″ and 5.25″ disk images to Gary using ADTPro, and make 5.25″ disks with Gary that will work with Edna. Yes!

 
Floppy IIGS

The point of all this Apple II business is to get Floppy Emu working on Apple II systems. Floppy Emu has a 19-pin D-SUB connector and can emulate 800K disks, and the IIgs has a 19-pin D-SUB connector and can read 800K disks. So maybe you can just plug it in, load a IIgs disk image, and it will work? Sadly, it’s not that easy, and a direct plug connection to a IIgs doesn’t work. I’m not entirely sure why, but it’s something I’ll be investigating closely.

I’d heard from a couple of people that Floppy Emu did work with the IIgs, if you used part of an Apple 3.5 Drive to make the connection. If you open up an Apple 3.5 Drive, inside is a standard Sony 800K floppy drive (identical to those used in early Macs), and another small board called the daisy chain board. The daisy chain board is what’s actually connected to the computer. The board has an internal private connection to the Sony drive, as well as another 19-pin D-SUB where a second daisy-chained drive can be connected. The photo below shows a partially disassembled Apple 3.5 Drive, with the daisy chain board tucked inside, just behind the actual floppy drive mechanism.

With a screwdriver and some gentle tugging, I was able to further disassemble the drive, separating the daisy chain board from everything else. On the underside of the daisy chain board, not pictured, are some electronics and a custom controller chip of some kind. What does it do? Hmmm.

I took the newly-liberated daisy chain board, and connected it to the IIgs using a 19 pin D-SUB to 20 pin ribbon cable – basically the same cable that I sell in the BMOW store. Then I attached the internal drive connector to a Floppy Emu, running the normal Macintosh floppy firmware.

And it worked! I was able to boot GS/OS from an emulated disk on the Floppy Emu with no troubles. I did notice one oddity, however. After accessing the disk, the IIgs always left the disk motor on. Even when the computer wasn’t doing anything, the status LED on the Floppy Emu board continued to flash, and the LCD said “read”. I’m not sure if this is some quirk of my setup, or an issue with the Macintosh floppy firmware being not quite 100% IIgs compatible.

 
The Mysterious Daisy Chain Circuit

So what does this daisy chain board actually do, that allows the Floppy Emu to work on the IIgs? A detailed answer will have to wait for a future post, but as best as I can tell, it’s just some lightweight interface circuitry that helps identify the drive to the computer, and enable it at the correct time. Other than that, it doesn’t seem to get involved with the actual control of the drive or the data transfer in any way. There’s a schematic of the daisy chain board here: page 1 shows the whole board, and page 2 shows what’s inside of the “DSIC” box on page 1.

It looks like pin 4 of the 19-pin D-SUB (pin 7 of the 20-pin ribbon connector) is used as an extra enable signal, for selecting between 3.5″ and 5.25″ disks on the daisy chain. The drive’s RD line is connected both to the computer’s RD line as well as the computer’s WRPROT line. Then there’s some complex-looking enable circuitry involving a 74LS123 one-shot. As far as I can figure, its behavior is this: if the computer enables the drive by asserting /DRIVE1 and /EN3.5IN, then it can afterwards de-assert /DRIVE1 and the circuit will keep the drive enabled for about a second. But if the computer de-asserts /EN3.5IN, or asserts /DRIVE2, then the drive will be disabled immediately. I have no idea why that behavior is important, but there it is.

About half the schematic is related to the daisy-chain circuitry and the eject button, neither of which I need. (Here’s an edited version of the schematic with all the daisy-chain and eject logic removed.) The enable circuit with the one-shot is confusing, but the rest looks like it might not be too difficult to duplicate. Then I could make a little adapter board that allows the Floppy Emu to plug into a IIgs without sacrificing an Apple 3.5 Drive. Maybe even build the necessary circuitry into future versions of the Floppy Emu. Now I need to set out my tools and get to work!

For Lisa computer owners, and Macs with only one floppy connector, disk drive emulation can be awkward sometimes. The Apple Disk Drive A/B Switch aims to eliminate that awkwardness. Available now from the BMOW Store, this board makes it possible to attach a Floppy Emu and a real floppy disk drive at the same time, and select between them with an A/B switch. Both drives will be powered, but the computer will only “see” one drive at a time, depending on the switch position. If you’ve got a single-drive system, and want to work with physical floppy disks and the Floppy Emu without a lot of cable swapping, then this is for you.

The board design is about as simple as it gets. A 20-pin ribbon cable connects the “IN” port to the computer’s logic board. The Floppy Emu is attached to “Disk A” and the real floppy drive to “Disk B”, or the other way around – it doesn’t matter. All of the power and data signals are shared between all three of the connectors on the A/B board, except for the ENABLE signal. By moving the A/B switch, you can alternately connect the computer’s ENABLE signal to either Disk A or Disk B. Both disks also have a 3.3K ohm pull-up resistor on their enable inputs, to ensure they’re disabled while they’re not selected with the switch.

There was some interest in designing customized versions of this A/B board, so I’ve posted the Eagle design files. The design is released under the Creative Commons BY-SA license, and you’re welcome to use it in your own designs.

Good news, Floppy Emu fans: 800K 3.5 inch disk emulation for Apple II is now working! More good news: it doesn’t require any adapter or other hardware, and it looks like the planned 5.25 inch and SmartPort hard disk emulation for Apple II won’t require an adapter either, save for one case as described below. Just plug your Floppy Emu board into the Apple II, load the new firmware, and go.

The new Apple II firmware supports Apple 3.5 Drive emulation of 800K ProDOS disks, and so is primarily of interest to Apple IIgs owners, though it should also work on an older Apple II with the appropriate disk controller card (not common), or the rare Apple IIc+. It works when the Emu board is plugged directly into the Apple II, making it drive #1. My IIgs machine “Gary” is now happily booting GS/OS directly from the Floppy Emu.

 
Apple 3.5 Drive

The Apple 3.5 Drive uses the same 800K Sony floppy mechanism as the early Macintosh models. Because Floppy Emu already supported emulation of 800K floppies for the Mac, I was fairly sure it would be possible to do it on the Apple II as well, but the details eluded me for a while. Inside the Apple 3.5 Drive, there’s an extra board called the daisy chain board that’s not found on the Mac, and it was this board that made things difficult. My previous posts on this topic mentioned semi-mysterious signals called /EN3.5 and WRPROT that don’t exist on the Mac.

As it turns out, the only change that’s strictly necessary is that the drive’s RD output (pin 16 on the 20-pin ribbon connector) should also be connected to pin 20. That’s it. On a Mac, pin 16 is internally connected to both the RD and SENSE inputs on the logic board’s IWM chip. But on an Apple IIgs, pin 16 connects to RD and pin 20 to SENSE, so they must be tied together externally when emulating a 3.5 drive.

For Floppy Emu, I can’t physically tie pins 16 and 20 together, but I can alter the firmware to output the same value on pin 20 and on pin 16, and it works perfectly for the Apple II. But for a Macintosh, pin 20 is the PWM output used to control the drive’s variable rotation speed. This leads us to the first commandment of Apple II firmware for the Floppy Emu:

Warning: Do not connect a Floppy Emu board to a Macintosh while it’s running the Apple II firmware. First connect the Emu board to your Apple II, then install the new firmware. When you want to switch back, reinstall the Macintosh firmware, then move the Emu back to your Mac. Though I believe the risk is low, running Apple II firmware on the Mac has the potential to damage the Emu and/or the Mac.

If you connect a Macintosh to an Emu board that’s running Apple II firmware, both the Mac and the Emu will attempt to drive pin 20. This will cause the output drivers of the two chips to fight each other, possibly damaging them. In the name of science, I tested it for several minutes and didn’t observe any ill effects, but please don’t do it on purpose. A future revision of the PCB will add an inline resistor here to protect against “whoops”, but for now be careful when moving your Emu board between an Apple II and a Mac.

To be clear, this output fighting only happens if you mess up, and use the Apple II firmware on a Mac. There’s no output fighting when using the correct firmware for the correct computer. Even using Mac firmware on the Apple II is fine (though it won’t work). I’m just trying to make things as idiot-proof as possible.

 
Daisy Chaining

In previous posts, I mentioned a signal called /EN3.5. This signal appears on pin 4 of the 20-pin ribbon connector, and is used to enable the 3.5 inch drives in an Apple II daisy chain. But on the Macintosh, as well as on 5.25 inch drives, pin 4 is just an additional GND connection. Both the Emu board and the DB19 to 20-pin extension cables that I sell have pin 4 internally hard-wired to GND. That means there’s no way for Floppy Emu to read the state of the /EN3.5 signal.

“But wait”, you say, “isn’t it bad if the computer’s /EN3.5 signal is connected to an external GND?” Actually it’s fine, and there’s a 470 ohm inline resistor on pin 4 on the logic board or disk controller to cover this exact issue. Remember, 5.25 inch disk drives also have pin 4 hard-wired to GND, and work fine with the Apple II.

“But wait”, you say again, “how can the Floppy Emu emulate a 3.5 inch Apple II drive if it can’t read the state of the /EN3.5 signal?” Ah, good question. The /EN3.5 signal is normally used to deactive the 3.5 drives, so the computer can talk to SmartPort drives or 5.25 drives further down the chain. But since Floppy Emu doesn’t have a daisy-chain out anyway, the /EN3.5 signal is irrelevant. The Emu acts as if /EN3.5 is always asserted. In practice, this means the Emu will also try to respond to any queries for 5.25 drive #1, but its response isn’t valid and is ignored by the Apple II. GS/OS and ProDOS both show that no 5.25 drives are present, which is perfect.

The only case in which an Apple II adapter is needed for Floppy Emu is when daisy chaining it behind a real Apple 3.5 Drive, and configuring it to emulate Apple 3.5 Drive #2. The Apple 3.5 Drive’s daisy chain board uses a little trick to check if pin 4 is GND on the next drive in the chain. If yes, then it assumes that drive isn’t a 3.5 drive, and won’t forward on 3.5 drive control signals from the computer. A small “Apple 3.5 Drive #2 Adapter” board with built-in logic for /EN3.5 and the /DRIVE2 enable signal would fix this, and I plan to offer such an adapter in the future. For now, if you absolutely must have your Floppy Emu configured as 3.5 drive #2, you can remove the daisy chain board from a “donor” Apple 3.5 Drive, and connect Floppy Emu to its internal drive connector, in place of the Sony floppy mechanism.

 
Apple II Firmware

In addition to simply getting emulation working for the Apple II, I added a few other firmware improvements:

• 2MG image file support! Most 800K Apple II disk images are in 2MG format, though some are Disk Copy 4.2. Now both are supported. 2MG worked on the first try too, which pretty much never happens.
• Pressing the NEXT button will eject the current floppy.
• The ProDOS disk name is parsed from the disk image data, and displayed on the Emu’s LCD.

You can download this version of the Floppy Emu Apple II firmware here: Apple II 0.1A-F1. Remember the caution mentioned above, and don’t connect the Emu to a Macintosh while it’s running the Apple II firmware.

 
What’s Next

3.5 inch disk emulation is step 1 of 3 in my Apple II plans. Soon to come, I hope, will be 5.25 inch emulation for 140K disks. The Emu can be connected either to the DB19 port on the IIgs, IIc, and Apple 5.25 drive controller card, or to the 20-pin ribbon connector on the original Disk II controller card. Following that, I hope to add SmartPort emulation, making it possible to emulate one or more hard drives of 32 MB each. There are no guarantees, but I’ve looked into the details of both 5.25 and SmartPort emulation, and they’re fairly well-documented and seem within the capabilities of the Floppy Emu hardware.

When I’m done, I hope to have a single device that emulates Apple II 5.25″ floppies (140K), 3.5″ Apple II floppies (800K), SmartPort block devices (like an Apple II hard disk, up to 32MB), Macintosh 400K, 800K, and 1.44MB floppies, Lisa 400K/800K floppies, and the Apple HD20 hard disk up to 2GB. That would make it a real Swiss Army knife of Apple disk emulation!