With the missing parts finally on hand, I was able put in some quality soldering time this weekend and build a whole pile of Floppy Emus. If you’ve been waiting, then wait no longer: they’re available now on the Floppy Emu page. It was a soldering ultra-marathon, and wow, was it tedious! I’ll definitely be looking into options for having an electronics shop assemble boards in larger batches in the future. I wish there were an easy way to hand-off the programming, testing, and order fulfillment too, as those tasks are surprisingly time-consuming. Many assembly shops can do programming and testing too, but when your test routine begins with “turn on the Macintosh Plus”, the conversation doesn’t go very well.

Most of the new batch of Floppy Emus were sold within 12 hours of putting them out for sale, before I’d even had a chance to mention it here on the blog, so hopefully there will still be some left by the time you read this. In fact, the level of interest remains surprisingly high for such a niche product, and to be  honest I’m a little bewildered by it. Sure it’s a neat little gizmo, but I never would have guessed there were so many people out there with Mac SE/30’s rattling around in their closets, looking for a floppy emulation solution. Who are you people? Don’t you have anything better to do? You’re crazy! But I love you anyway.

With this batch of hardware, I’m also introducing a new variant of the Floppy Emu. For an extra $13, you can get the DB-19 floppy connector on a 36 inch extension cable, instead of having it built-in directly to the Floppy Emu board. This provides some extra flexibility for positioning the Floppy Emu where it’s convenient for you to see it and press the menu buttons. It’s similar to what you’d get with IEC’s cable, only now you can get it at the same time that you purchase the emulator.

The extension cable uses a tiny circuit board to adapt the DB-19 floppy connector to a standard IDC-20 header, then adds an IDC-20 to IDC-20 cable. Using a custom circuit board here seems a little like overkill, but I was unable to find a DB-19 shrouded header anywhere. The whole cable assembly is hand-built by me. This new extension cable Floppy Emu variant is an experiment, and I’ll be looking to see how popular it becomes, and how tedious it is to make the cables. If the experiment doesn’t go well, I’ll probably return to selling only the original variant with the built-in DB-19 floppy connector, and let IEC have the extension cable business for those who want one.

Where and how do you find the parts needed to build your hardware? Selling Floppy Emu on a small scale has introduced me to the difficulties of managing a supply chain, and I’ve discovered it’s more difficult than it looks. Doing it wrong means higher costs, more risk, and a danger of running out of key parts at the wrong time. Due to my own poor planning, Floppy Emu has been stuck at “out of stock” for far too long, and I can’t even say for certain when it will be back.

Choosing a vendor from whom to buy parts seems like it should be easy: just use a search engine like Octopart to find the vendor with the lowest price. Sadly it’s not that simple. Some guy on eBay may have the lowest price, but how can I know if his parts are good quality, or if they’re recycled, relabeled, or even counterfeit? Is the savings enough to be worth the risk? And then there are “overstock” vendors like Arrow, Avnet, and Verical, who often have very good prices but require minimum orders of 100+ parts. Are they worth it?

Even if it’s clear which vendor is best for a specific part, it becomes less clear when all the parts are considered together. Floppy Emu is built from about 15 different types of parts, and if I ordered each one from a different vendor, the combined shipping costs from all those vendors would kill me. It’s a balancing act, and it’s often necessary to buy a part from a vendor whose price isn’t the best, so I can combine it with other parts in the same order from that vendor.

Mapping all this out is a pain, but at least it only needs to be done once, right? Wrong. The vendor prices are constantly changing, and less commonly the minimum order sizes change as well. So every time I go to order more parts, I have to start the analysis over again.

I struggle the most with determining how many parts to order. Virtually every vendor has a sliding price scale, where the per-part cost decreases as the number of parts ordered goes up. So there’s an incentive to make orders for large numbers of parts to drive down the average cost, but there’s also a risk. If I order 100 ATMEGA1284 microcontrollers, and then interest in Floppy Emu dries up, I could be left with $1000 worth of useless chips sitting on a shelf. But if I order them 10 at a time, I’ll not only be paying more per chip, I’ll also be reordering nearly every week and risking running out of parts if demand temporarily spikes up.

Out of Stock

My current problems are due to Floppy Emu’s LCD display. In mid-January I thought I had two boxes of LCDs remaining, when in reality I only had one. When I discovered the truth, I only had about six LCDs left. I placed an order for more LCDs on January 29, from the same Chinese vendor I’d used in the past. But then Chinese New Year hit, and nothing happened for a week. The package finally shipped on February 6. Meanwhile, I ran out of LCDs on February 8 and put Floppy Emu into “out of stock” status.

My last order from this vendor took 10 days to arrive from China, so I expected the new LCDs to appear around February 16. But that day passed with nothing in my mailbox, nor the next, nor the next. Time ticked by. As I waited, I accumulated enough Floppy Emu back orders so that the new supply of LCDs would already be nearly exhausted by the time it arrived, so I placed a second order for even more LCDs.

When I checked back on the first order, I saw the vendor was now quoting 25 to 30 working days for delivery. What?! That’s like a month and a half! I’m not sure if this was a change in policy, or the 10-day delivery time I had earlier was just an outlier, but they were now giving me an estimated delivery date of March 7-15. Somehow the second LCD order was estimated to arrive earlier, on February 28 to March 6, despite being ordered three weeks after the first LCDs and being shipped by the same method. And there’s no tracking info on either shipment, so there’s nothing to do but wait.

The Apple Hard Disk 20 (HD20) was an external 20 MB hard drive for the Macintosh, introduced in 1985. This was during the earliest days of the Mac’s history, before the introduction of SCSI support, so the HD20 connected to the Mac’s floppy port. Despite sharing the same DB-19 connector as a floppy drive, the HD20 used an entirely different communication method, making it something of a hardware freak. When SCSI support was introduced in 1986, external hard drive solutions quickly adopted the new standard, and the HD20 faded into obscurity.

During the long course of Floppy Emu’s development, several people have suggested that it might be possible to emulate the HD20 using the same hardware. In theory it should only require changes to the CPLD and AVR firmware, since the HD20 uses the same physical interface with the same pins as a floppy drive. But in practice, no documentation of the HD20 communication protocol existed, and reverse engineering it looked to be such a daunting task that it wasn’t worth it.

Circumstances changed last fall, when a couple of HD20 specification documents surfaced on the internet. Who knows where they came from – probably rescued from the bottom drawer of an ex-Apple engineer’s desk in a questionable release of company confidential information. But it’s hard to imagine anyone getting upset over documents nearly 30 years old, detailing a long obsolete peripheral for a long obsolete computer. The two most interesting documents are the specifications for “directly connected disks”, one dated March 1985 and a later revision dated May 1985. The DCD standard was planned to support a variety of device types, but ultimately the HD20 was the only product to ever use it. With these two documents and a careful examination of the HD20 driver routines contained in the Mac’s ROM, it looked like it might finally be possible to emulate the HD20.

Into the Abyss

So how does it work? First off, we can assume that raw data bytes are sent and received in serial fashion using NRZI encoding on the ReadData and WriteData lines of the floppy connector. While the DCD documents don’t specifically mention this anywhere, it’s a safe assumption because the floppy interface is powered by the Mac’s IWM chip (Integrated Wozniak Machine), which is hard-wired to send and receive data this way. So the main questions surround exactly what data bytes are sent and received, and when, and how the other lines on the floppy connector are used.

The DCD docs describe a state-based protocol that’s mercifully straightforward, compared to the oddities of the floppy drive interface. The Phase0, Phase1, and Phase2 lines on the floppy connector (sometimes called CA0, CA1, CA2) are used as a 3-bit state ID, to control the workings of a state machine governing Mac to DCD communications. At boot up, the Mac cycles through states 6, 7, and 5 in that order, checking the value on the ReadData line after each state transition. If it sees the values 1, 1, and 0, then it concludes that a DCD is connected to the floppy port, rather than a standard floppy drive.

HD20 communication is always a two-way exchange, with a command from the Mac followed by a response from the drive. From state 2 (idle), the Mac transitions to state 3 to indicate it wants to send a command. Seeing this, the DCD pulls /HSHK (the ReadData line) low to indicate that it’s ready to receive the command. The Mac then transitions to state 1 and sends the command, after which it transitions to state 3 to signal that it’s done. The DCD then brings /HSHK high again to acknowledge the end of the transfer, after which the Mac transitions back to the idle state.

When the DCD is ready to send a reply, while in the idle state, it pulls /HSHK low to indicate that it wants to send. The Mac then switches to state 1, and the DCD sends the reply bytes. After the last byte, the DCD brings /HSHK high again, and the Mac transitions back to the idle state.

Commands follow a fairly simple structure. A read command and response are shown above. The command begins with $AA, which functions as a sync byte and start of command marker. The next byte is the command id. In this case, $00 means it’s a read command. Following that are the number of 512-byte blocks to read, a three byte block address, a padding byte, and a checksum.

The reply looks similar to the command. Again there’s an $AA sync byte, followed by the command id. The command id in the reply is always the command id from the request plus $80, though I’m not sure the reason for this. After that is the sequence number of the block being sent, a status byte (zero means OK), more padding, the actual block data, and a checksum.

The HD20 carries over the concept of tag bytes that originated with the Apple Lisa, and that are also present (but unused) on Macintosh floppies. Each block has 20 tag bytes, so from a low-level point of view, blocks are essentially 532 bytes instead of 512, and 532 bytes of data will be returned in reply to a read request. The Mac throws away the 20 tag bytes, however, and only the last 512 bytes are treated as disk data. From the point of view of an emulator, only those 512 bytes need to be filled from a disk image file, and 20 bytes of zeroes can be prepended for the tags.

Because of the way the IWM works, the MSB of every transmitted byte must always be 1, so in effect there are only seven usable bits per transmitted byte. The DCD standard uses a 7-to-8 technique in which data is collected into groups of seven bytes, and then repackaged and transmitted as eight bytes with an MSB of 1 for every byte. This technique right shifts each of the seven bytes by one bit, chopping off the LSB, and setting the MSB to one. Then all of the chopped off LSBs are collected into an 8th byte. At the other end of the line, the receiver applies the reverse process to recover the original seven data bytes.

From Theory to Practice

That’s how it’s supposed to work, anyway, but there are many gaps and inconsistencies in the documents. One of the biggest concerns is that the March version of the doc differs in major ways from the May version. For example, the handshaking method described in the March doc is completely different than what I described in the previous section, based on the May doc. If there was that much change in the space of two months, it’s likely that the spec continued to evolve after that, and the May doc may not reflect the final version as it was eventually implemented.

Some important details just aren’t mentioned at all. What’s the checksum algorithm used? Nobody knows. An appendix also mentions a couple of dozen diagnostic commands, without describing what the parameters mean, or how the DCD should reply. Answering these kinds of questions requires a combination of educated guesswork, experimentation, and good old reverse engineering.

The code used by the Mac to communicate with the HD20 is contained in the ROM of the Mac Plus and other early Macs. Unfortunately this is raw 68000 machine language, so it’s difficult to read and understand what it’s doing. With the help of disassembler tools, the ROM data can be converted into 68000 assembly mnemonics, and symbolic names can be substituted for some known memory addresses, resulting in a code listing like this one:

L4772: MoveQ.L $4, D0
L4773: DBF D0, L4773
       Move.L D6, D0
       Add.L $810081, D0
       Move.B $-56, $400(A0)
L4774: Tst.B (A3)
       BPL L4774
       Move.B D0, (A0)
       Swap D0
L4775: Tst.B (A3)
       BPL L4775
       Move.B D0, (A0)

That’s not very instructive. But after long hours of studying and examining other nearby sections of code, some sense of structure does slowly emerge. For example, from looking at where A3 is set previously, I can tell that those Tst.B (A3) instructions are checking to see if the IWM is busy. And the Move.B D0, (A0) instructions are each writing a new byte to the IWM. Other clues are provided by the literal value $-56 appearing in the code, which when expressed as an unsigned byte is $AA – the sync byte. So what we have here is something that does a short busy loop, then adds $810081 to an unknown value from D6, and stores the 32 bit result in D0. Then it writes the $AA sync byte, waits for the IWM, writes the low byte of D0, waits for the IWM, and writes the high byte of D0. So it looks like it’s the preamble to sending a command to the DCD.

This is the kind of “deep in the weeds” analysis that’s needed to fill in the blanks for an emulation project. It’s something I’ve spent a lot of time doing for Floppy Emu and for Plus Too before that, so I’ve gotten pretty good at it, but I can’t really say it’s fun.

And a Progress Report

Armed with all this information, I began by hacking up the firmware on a Floppy Emu to identify itself as a DCD, and observe the proper handshaking rules for the various states. No data was actually sent or received. That was enough to get a noticeable reaction from the Mac: at bootup it froze for a long time, then when it finally did boot (from a SCSI drive), it complained that an attached disk was uninitialized and needed to be formatted. Then I wrote a simple test program to read arbitrary blocks from the DCD. The program always reported error -17 (driver can’t respond to this call). That was logical, but a little disappointing, as I could see from the ROM disassembly that there were many other more specific error codes that might be returned to give better feedback on what was and wasn’t working. I was hoping I might get an error like 64, no response received, or 33, timeout waiting for sync byte.

I spent a while tinkering with things, trying to get a more specific error than -17, but without success. I also tried using MacsBug to debug the HD20 driver routines while they were executing, but that appeared to create some new timing-related problems that messed things up even worse. Finally I decided to change course, and attack the other end of the problem by looking at what was happening on the Floppy Emu when the error -17 occurred.

I started with just displaying the current state number on the Floppy Emu LCD. I could see it go through states 6, 7, and 5 at bootup, just as the docs say it should. Then it went through states 2, 3, 1, 3, and 2, which looked like an attempted Mac to DCD command transmission. That seemed promising, so I leveraged the existing write code for Floppy Emu to try to collect the data bytes sent by the Mac, and display them on the LCD. That’s when I got the first payoff, as the received bytes were:

AA 81 B1 C1 81 80 80 80 80 80 FE

There was the $AA sync byte. And if you looked at the last eight bytes (beginning with $C1), it looked like a valid 7-to-8 encoding. Decoding those bytes yielded:

03 00 00 00 00 00 FD

That was command id 3 (drive status, according to the doc), with a bunch of padding and a checksum of FD. The sum of all the bytes mod 256 was 00, so that’s likely the checksum algorithm.

But wait, what were the second and third bytes for, 81 B1? Those shouldn’t have been there, according to the doc. Help! Truthfully I’m still not sure what those are, but after long examination of the ROM routines, I’m about 90% sure the first byte is the size of the data being sent, and the second byte is the size of the expected reply. Both sizes are expressed as a number of 7 byte groupings, then added to $81. In fact, the code that outputs those two bytes is the snippet I analyzed in the previous section.

So for the example above, the size of the data being sent was zero (no data payload for a drive status command), and the size of the expected reply was $30 groups of 7, or 336 bytes. Probably these size bytes were added to the DCD protocol late in the development process in an attempt to provide some amount of forward compatibility, so a device could gracefully handle an unknown command and send back a dummy reply of the correct size.

That’s where things stand today. With a little more experimentation, I’m hoping I can send back a valid drive status reply, or at least one that’s close enough to generate a more specific error code than -17. Then things will start to get very interesting.

Introducing Floppy Emu version 1.2: it’s blue, because blue makes it go faster! Buy yours now from the Floppy Emu product page.

Version 1.2 is a minor update that cleans up a few details. You may have noticed that the silkscreen labels on the version 1.1 boards looked a bit strange, with some overlapping labels and most parts labeled twice. That will teach me to submit my designs to the PCB fab without inspecting the Gerbers first! Version 1.2 corrects this, and makes everything much more readable.

More significantly, the pin assignments on the LCD connector have changed. The leftmost pin was 3.3V in version 1.1, but now it’s RESET, and the other pins have changed as well. This was done to accommodate a change that’s occurred in Asia where these LCD panels are made. About six months ago, I noticed that two versions of this Nokia-clone LCD were available for sale online, seemingly identical except for the order of the pins. Over time, LCD panels with the old pin layout became harder and harder to find, so I’ve switched to the new pin layout beginning with version 1.2. I had to replace my stock of LCDs, and was left with a few old-style LCDs I can’t use, but that’s the price of progress!

Did I mention that it’s blue?

You’ll also notice a through-hole resistor footprint labeled LIGHT, adjacent to the PREV button. This was added to make it easier for people to mod their boards to enable the LCD backlight. I think the backlight looks like poop, so I don’t enable it for the Floppy Emus I build. Some people really, really want the backlight, though, and this was meant to give them a way to do it. Unfortunately, it doesn’t work. The new-style LCD modules surprised me by reversing the polarity of the backlight LEDs, so the circuit I designed doesn’t work. Doh! Eventually there will probably be a version 1.3 to correct it. The vertical spacing between the two LCD headers is also a bit off, so that’s another point to address in a future version. But other than those minor headaches, I’m quite happy with this new version 1.2.

Mounting holes were added to the corners of the board in version 1.1, with the idea of supporting a case for the Floppy Emu. But to my knowledge, no one has made one yet. It should be simple to cut and drill two pieces of acrylic to act as top and bottom plates, and put them together with standoffs like a sandwich. It wouldn’t be a true case due to the open sides, but it would still look pretty spiffy. More advanced makers might use the mounting holes to anchor a custom 3D-printed case. At least one person was working on a custom case that looks like a miniature external Apple drive, but never quite got it to work. If you’ve got a cool case design, post it in the comments!

Floppy Emu uses a generic LCD that’s a clone of the display in the Nokia 5110 phone. It’s a nice little bitmapped display with a good range of configuration options, including the ability to set the display’s contrast level through software instead of with an external resistor. Unfortunately there’s a huge variability in contrast response from one LCD to the next, and even the same LCD can exhibit contrast changes from day to day. I’m not sure if it’s due to temperature, fluctuating voltages, bad solder joints, or something else, but it makes it virtually impossible to choose one contrast level in the Floppy Emu firmware that will work well for all LCDs. Until now, I’ve been making a custom firmware build for each Floppy Emu that I assemble, with a hand-tweaked contrast level, but that’s a huge pain in the butt. No more!

Firmware 1.0L F11 introduces the ability to adjust the contrast level and save it to EEPROM. Now you can tune the contrast exactly how you like it. To adjust the contrast, hold down the SELECT and NEXT buttons while Floppy Emu is initializing (after pressing the reset button, or when first powering it on). After a few seconds, the contrast adjustment screen will appear. Press PREV and NEXT to tune the contrast level, and SELECT to save the contrast setting to EEPROM. Easy peasy lemon squeezy.

To apply this firmware update to your Floppy Emu hardware, download the firmware files, and copy the file femu.bin to your SD card. Then hold down PREV and SELECT while the Floppy Emu is initializing. This update only changes the AVR software (from 1.0K to 1.0L), the CPLD is unchanged (it’s still F11).

Happy contrasting!

It’s been about a month since I began selling my Floppy Emu disk emulator for vintage Macs, and it’s time for a progress report. It’s been a real learning experience with the hardware, as well as on the “business” side of things. If you’ve ever considered turning a hobby project into a source of extra income, you may be especially interested in this side of the story.

The Biz

First, the business report: To date I’ve hand-built 44 of these little guys. 39 passed all my tests and received the seal of approval, for a yield of about 89%. Of the working boards, I sold 33, gave two as gifts, kept two for myself, and have two currently available for sale.

About half the Floppy Emus I’ve sold have gone to people outside the USA. Initially this surprised me – I’m in the USA, and I assumed most of the readers of my blog were too. Then there are large chunks of the world where the Mac was never popular, which are effectively ruled out as potential customers. And because the blog is in English, potential customers are further limited to those who are comfortable enough with the language to follow along. Yet despite all this, there are a surprising number of die-hards in Slovenia, Brazil, and other unexpected places who are buying Floppy Emus. Hello! So if you’re in the United States and considering selling some kind of DIY product, don’t make the mistake of ignoring the international market.

For a while I was operating a waiting list, but it was a bigger hassle than it was worth. Only about half the people on the waiting list actually followed through to make a purchase once I told them their board was ready. It was also awkward to reserve units for people on the waiting list, who may or may not eventually buy them, when it meant there weren’t enough units for the people who came later and were ready to buy.

Assembly and Test

All the Floppy Emus are built by hand, by me, with a regular soldering iron. It’s a fairly labor-intensive process, and with orders averaging about one per day, it’s monopolized most of my free time for the past month. I’ve been building boards in small batches of three to five at a time, updating the stock on the web page as new boards become available. This has created a pattern where Floppy Emu is constantly going in and out of stock, and I haven’t yet been able to get far enough ahead to keep a steady stock available. I guess that’s a good thing as it means there’s demand, but it would be nice if I weren’t always on the edge of running out.

The 89% success rate is pretty bad. Or maybe it’s reasonable for a hand-assembled electronics item, but throwing 11% of the hardware in the trash is a frustrating and expensive way to do manufacturing. Not only do I lose all the money that went into those failed boards, I also lose the hours it took to assemble and test them. This is an area where I really need to improve. The defective boards failed in various ways that I couldn’t diagnose or repair. Some of them almost work, but exhibit occasional failures when reading or writing. Others are nothing but scrap.

I’ve looked into having an assembly shop build a batch of Floppy Emus, but I probably need to purchase 50 or 100 units at a time for it to be cost-effective. With a new manufacturer, there’s also a risk of some misunderstanding or error that would lead to delivery of 100 non-functional Floppy Emus, and I can’t afford that risk. There are also some elements that an assembly shop likely couldn’t accommodate with their standard process, like the edge-mounted DB-19 connector, and the LCD mounted on a separate module. So for the time being, Floppy Emus will continue to be hand-assembled.

Assembly is slow, and it’s not just the time spent soldering. Setting the AVR fuses, programming the chip, and adjusting the LCD contrast for each board takes a surprising amount of time. Just digging the next part out of the box eats a substantial amount of time too. With a dedicated work area I could leave all the parts laid out for easy access, but I have to get by with a small desk that’s also used for other purposes.

Each Floppy Emu is tested three times on three different computers: a 400K disk test on a Mac 512K, an 800K test on a Mac Plus, and a 1.4MB test on a IIsi. These aren’t just quick boot-up tests either: they’re read and write tests that fill an entire disk image, multiple times, using each of the two floppy connectors on the board. Each Floppy Emu goes through about 20 minutes of testing, but when testing multiple boards at once I can do one every 10 minutes with pipelining. That’s a lot of manual testing work, and it bloats the time per board beyond the actual assembly time. And of course if there’s a problem found during testing, more time is needed to troubleshoot and fix it.

Shipping and Handling

I used to think “handling” was just a bogus term used to rip-off buyers, but now I understand why the cost to ship something is not necessarily the same as the cost of postage.

For USA shipments, it takes me about 10 minutes to prepare one Floppy Emu to be mailed. How can it take 10 minutes just to put something in a box? I didn’t believe it myself at first, but I’ve timed myself doing it often enough to accept it. The buyer’s contact info needs to saved, so I can contact him/her later if necessary. Then the Floppy Emu has to go in an anti-static bag, and the bag gets sealed. I have to assemble a box, fill it with foam peanuts, wrap the anti-static bag in bubble wrap, and cradle it in the peanuts. Then I need to print a packing slip and an instruction sheet, stuff those in the box, close it up, and seal it all with packing tape. Then I need to feed a sheet of label paper into the printer, log into the PayPal web site, purchase and print the postage, and stick it on the box. I have newfound sympathy for mail room employees.

For shipments going outside the USA, it takes about 15 minutes to prepare one Floppy Emu for mailing. For unknown reasons, PayPal will not sell postage for International First Class mail. I need to log into a separate account at the US Post Office Click-n-Ship site, and copy the pieces of the address one at a time from the PayPal data to the Click-n-Ship page. Instead of a single blank field for the address, Click-n-Ship forces me to break it up into separate form fields for first name, last name, street address, city, postal code, etc. Often these don’t match well with the way addresses in other countries are formatted.

If any letters have accents, the form validation fails, and I have to reformat it manually. Méndez Núñez must become Mendez Nunez. Sorry. This reminds me of some traffic signs in the area of California where I live. Many local place names are Spanish, and some signs for Cañada College have it as Canada College. When I first moved to the area, I couldn’t understand why the nation of Canada was sponsoring a local school.

I discovered that shipping materials cost real money! For USA shipments I can use the free Priority Mail boxes, but for international mailing I need to buy appropriate boxes, which must be purchased 50 or 100 at a time. Anti-static baggies, bubble wrap, packing tape, and shipping labels all cost money too. I hadn’t really considered this when I did my original cost estimates.

Once everything’s packed and ready to go, I have to bring it to the post office for mailing, which is about a 20 minute errand round-trip. Sometimes I can combine it with another errand, but I often find myself spending 20 minutes in the car just so I can mail a single Floppy Emu package. Post-9/11 paranoia means we’re no longer allowed to put packages in neighborhood mailboxes, but must take them to the post office and put them in the mail drop there. For international packages, you’re not even allowed to use the mail drop, but must wait in line to hand the package to a retail employee in person, even if the postage was already purchased online. Fortunately my local post office workers don’t insist on this rule, and told me that putting international packages in the mail drop is fine.

Between testing, packing, and visiting the post office, I’m averaging at least 30 minutes of labor per Floppy Emu above and beyond the time it takes to actually build it. Combined with the costs of shipping materials, that’s a significant amount of overhead I hadn’t planned for.

Parts Sourcing

Getting the parts needed to build each Floppy Emu has proven to be more challenging than I’d expected. I’m buying most of the parts from DigiKey, but the prices are constantly fluctuating, and sometimes it’s cheaper to buy certain parts from another vendor. It’s a bit of a puzzle, every time I refill my supplies. For most parts, the unit price is substantially cheaper when buying many of them vs buying a single one. I’ve been buying the majority of parts 10 at a time, but vendors other than DigiKey typically have higher minimum orders or steeper discount curves that force you into buying large quantities. I had to buy 73 of those DB-19 connectors!

Two other parts costs I neglected to account for are shipping and sales tax. These two combined add about 20% to my total cost of parts. In theory I could avoid paying sales tax by showing the suppliers a sales tax exemption certificate, but that would involve a layer of government red tape I haven’t wanted to mess with yet. It would also mean collecting sales tax when a California resident buys a Floppy Emu, which is something I really should be doing anyway, but would be a pain in the butt.

I discovered another hidden cost of parts sourcing too, and it’s one that wasn’t obvious at first. Say I’m building widgets, and each one needs a sprocket and a lever. If I buy 50 sprockets for $4 each and 50 levers for $3 each, then my total cost of parts is $7 per widget, right? Well, not exactly. It costs $350 to buy 50 sprockets and 50 levers, and I won’t recoup that cost until I’ve sold 50 widgets. If I do this repeatedly, on average at any given time I’ll have the parts for 25 unsold widgets sitting on my shelf. That’s a cost of $175 that I’ll never get back unless I quit the business after selling some exact multiple of 50 widgets. It’s like a security deposit, or worse.

The Sincerest Form of Flattery

The last of the business surprises was the theft of the Floppy Emu name. Another person (or company?) in Europe has started selling disk emulators using the Floppy Emu name for their product. I won’t link to it and lend it extra page rank points, but you can find it if you try. As far as I can tell, it’s a PC floppy emulator and not compatible with vintage Macintosh computers, so it’s not going to accomplish much except for confusing people.

Biz Summary

If you’re getting the picture that there are a lot of unforeseen costs and unexpected time sinks involved, you’re right. Don’t feel too sorry for me, though: even after all of this, I still make money from selling Floppy Emus. But with all the labor involved, it’s basically like I’ve invented a new part-time job for myself. It pays more than minimum wage, but not by much. 🙂

Hardware

Enough of all this business stuff – let’s talk about what’s happening with the hardware! The good news is that Floppy Emu is working well in the wild, and I haven’t had any reports of major problems or incompatibility. The worst problem seems to be one I encountered myself: on my Mac 512K, maybe one in ten times the computer will fail to boot, and will show a Sad Mac error. I suspect this is because the drive speed emulation for the Mac 512K (and Mac 128K) is imperfect, and so the Mac sometimes freaks out when it thinks the floppy drive is rotating at the wrong speed. Newer Macs don’t use the drive speed signal and so don’t run into this problem. On the other hand, maybe it’s just something flakey about my 512K.

LCD

The LCD has been a source of headaches. About 10% of the LCD modules I’ve purchased have been defective in some way: damaged screens or dead pixels. That’s annoying, but the bigger headache has been varying contrast between LCD modules. Using the same software contrast setting, some modules show nice crisp text, some are washed out, and some are nearly solid black. I think it has something to do with how the LCD glass is mounted on the module, as I can usually change the contrast by pushing on the glass with my finger.

For the LCDs that don’t look good with the default contrast setting, I’ve been making custom firmware versions with a different contrast value, so every Floppy Emu that ships should have a nice display image. This isn’t a good long-term solution, though. It’s time consuming, and the customized firmware will be lost if the user ever applies a firmware update. People can make their own custom firmware, but it’s a hassle. What I probably need to do is add a manual contrast adjustment feature to the firmware, with the selected contrast value stored in EEPROM. Then everybody can tune the contrast exactly how they want it.

The revision 1.1 board that’s shipping now was designed to backlight the LCD, and the LCD modules have backlight LEDs built-in. After doing a few samples, though, I decided it looked better without backlighting. The backlight highlighted imperfections in the display glass, and gave it a washed-out look. All the Floppy Emus that are now shipping have the backlight disabled, but for people who really really want backlighting, they can add a 220 Ohm resistor at location R5 to enable it. A future board revision will have a through-hole footprint for R5 instead of a surface-mount footprint, to make it a little easier for modders.

Future Development

Time permitting, I hope to continue development of the Floppy Emu firmware. Some early adopters discovered that Floppy Emu works with the Apple IIgs, but it’s not as simple of a setup as I’d like. It works when the Floppy Emu is connected to the pass-through board of a real 3.5 inch Apple external drive, but not when Floppy Emu is connected directly to the IIgs. I’m pretty clueless when it comes to all things IIgs-related, so I’m not sure what’s going on, but I hope to find out.

According to what I’ve read, it should also be possible to make Floppy Emu work on a Lisa – the precursor to the Macintosh. This would require a firmware change, since Lisa disks have essential data in the “tags” section of each sector, but the Macintosh doesn’t use tags and Floppy Emu ignores them. This may never happen, though, since the Lisa community is such a small audience of potentially interested people. I’m not ready to plunk down thousands of dollars for a Lisa just to test it out.

The most exciting thing on the horizon is HD20 support. The HD20 was a very early Apple hard drive from before the introduction of SCSI, and it connected to the external floppy port. In the past, several people have suggested HD20 emulation as a possible new feature, and I’ve always said it was impossible. But some new documentation that’s recently come to light suggests it may be possible after all – so Floppy Emu could emulate a 20 MB hard disk instead of an 800K floppy. In fact, it might even be possible to emulate hard disks larger than 20 MB. Unfortunately only a few early Macs have HD20 support in ROM, so it wouldn’t be a universal solution, but it would be great for those Macs that support it. It looks like HD20 emulation would involve a near total re-write of the Floppy Emu firmware, though, so don’t expect to see it next week!