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.

Help request! If any reader has experience taking a hobby-scale electronics project to an outside vendor for assembly, I’d love to hear from you. I’ve been talking with the fab in China that makes the Floppy Emu PCBs, and they can do the full assembly process for a reasonable price. That means making the PCBs, ordering all the components, and doing 95% of the assembly. I’ll add the DB-19 connector and LCD myself. But I’m stuck on determining what kind of testing to request from them, if any. It seems like a simple question, but I don’t have the experience to know what kind of failures to test for or what failure rate is typical.

The vendor will send me hardware that passes whatever tests I specify. If a board fails a test, it’s up to them to find out the problem and fix it. Ideally they’d do a full functional test – the same test I do before shipping a Floppy Emu – but that’s not practical for several reasons. I’d have to ship several vintage Macs to Shenzhen, and give them instructions on how to use old System 2.0 software and perform a non-automated series of file copy tests. Assuming they were even willing to do this, it would be expensive and time-consuming, and I’m not sure I’d even trust them to do it correctly.

At the other end of the spectrum, they could do a basic power-on test. Apply power, and confirm that the power LED turns on. But that wouldn’t really prove much except that there are no power-to-ground shorts. There could be all kinds of horrible problems with the board, but the LED would still turn on and the test would still pass. Furthermore, it’s not so easy to “power on” a Floppy Emu without having a Mac, since it’s meant to be powered through the floppy port. I’d have to build them some kind of power adapter, or they’d need to connect test leads to specific pins on the board to power it.

A mid-level test would be for them to flash the AVR firmware, then confirm that the status LED blinks three times at power-on (the normal behavior). That would at least show that the AVR was working correctly. But it wouldn’t do anything to test the SD card interface, or the CPLD, or the LCD interface. And there would still be the same challenge of powering the hardware without having a Mac to connect with it.

What makes this difficult is not knowing what kind of failure rate is typical, nor what kind of failures. If I specified no tests at all, and they installed an IC backwards in all the boards, I could get a 100% failure rate. Would something like that be my responsibility, or theirs? If I didn’t provide any tests at all, they could theoretically send me anything and have still met their obligation.

Lastly, the cost of testing time is somewhat expensive relative to the cost of the hardware. For a run of 50 units, for each 1 minute per unit spent on testing, it’s the same cost as if they did no testing and 1 unit was defective and discarded. For example if they spent 5 minutes per unit on testing, I could afford to have 5 of the 50 units be defective and unusable – a 10% failure rate – for the same cost. Since 5 minutes of testing still wouldn’t guarantee a 0% failure rate anyway, the cost of testing begins to look questionable unless the typical failure rate is high.

Working out testing details with someone who’s on the other side of the planet and who’s not a native English speaker can be difficult. I tried to find an electronics assembler in the United States, but had terrible results. One place actually contacted me, after reading the blog, but they later said they couldn’t handle my order and referred me to a second US vendor. I contacted the second vendor, but they never responded. A third US vendor was referred to me by a friend of a friend. I sent them a detailed description of the project and some questions about their process, but heard nothing for more than a week. Finally they wrote back with a generic reply, without quoting any price or answering any of the questions I’d asked. A fourth US vendor was referred to me by another retro-computer enthusiast I know, but so far I’ve had no response from that vendor either. In contrast, the Chinese shop sent me a detailed quote within 24 hours of my first inquiry, and was happy to have my business.

In a perfect world I’d have a test that was easy to run, quick, required no extra equipment, and could catch near 100% of the possible problems. But I don’t have that, or even anything close. So I’m leaning towards no testing, but my nightmare scenario is to spend lots of money and receive 50 units that are all broken, due to some kind of systematic assembly problem.

Has anyone else been through this process before? What was your experience?

So you’ve designed an electronic gizmo, it works nicely, and the public wants to buy it. You’ve built one, or ten, or a hundred by hand until your soldering iron wore out, and now you’re ready to have the gizmo manufactured in a low-volume production run. Where do you go, and how do you get started? This is where I stand today with my Floppy Emu project, and I’ve spent the past few weeks researching the answers.

Step one is identifying and contacting potential manufacturers. This is harder than it looks! Electronics manufacturers generally don’t deal with “the public”, and you can’t just browse listings on amazon.com. Many of them seem to be semi-anonymous, with generic-sounding names like Electronic Systems, Inc. From my experience, the best way to find manufacturing candidates is to ask everyone you know for referrals. Dropping the name of a current client may also help make a manufacturer more willing to work with you.

If you’re an inexperienced one-person team looking for a production run of 50 or 100 units, be aware that most manufacturers won’t talk to you. They won’t even bother to reply when you contact them – you’re just not worth their time. Don’t be offended, just move on.

Somebody Set Up Us the BOM

You can increase your chances of a favorable reply by being informed and organized when talking with the manufacturer. Have your Eagle/KiCad files and Gerbers ready to provide if requested. Make sure every part in your design is clearly identified with a designator like UC2 or R2, both in the design files and printed on the board itself. And most importantly, provide a detailed bill of materials (BOM) that defines exactly what part goes at UC3, R2, and everywhere else. If there are some footprints on the board that should be left empty, list those too. The more detail, the better.

Poor BOM:

• UC3 – ATMEGA1284P
• R2 – 220 Ohm resistor
• SW1 – push-button switch

Better BOM:

• UC3 - Atmel ATMEGA1284-AU, 44 pin TQFP package, http://www.digikey.com/product-detail/en/ATMEGA1284-AU/ATMEGA1284-AU-ND/2271240
• R2 – Yageo RC0805JR-07220RL 220 Ohm SMT resistor, 0805 package, 1/8 Watt, 20% tolerance, http://www.digikey.com/product-detail/en/RC0805JR-07220RL/311-220ARCT-ND/731230
• SW1 - TE FSM4JSMA 6x6mm 160gf SMD N.O. tactile switch, http://www.digikey.com/product-detail/en/FSM4JSMA/450-1129-ND/525821
• J2 – do not populate, leave empty

This saves the manufacturer a lot of time, eliminates potential confusion, and makes you look like you know what you’re doing.

Choosing a Manufacturer

After you get some manufacturers to reply with a quote, you just choose the cheapest one, right? Unfortunately it’s not that simple, even if cheapest were the only criteria. It’s often difficult to make an apples-to-apples comparison, because not all manufacturers provide the same services, and they don’t always structure quotes in the same way.

Some assemblers are assembly only, and it’s up to you to provide them with the blank PCBs and the parts. Others can handle that for you, either internally or externally. Most assemblers can also program any programmable chips on the board, and perform post-assembly custom testing if you desire. If you specify no custom testing, the default testing varies between assemblers, so be sure to ask. Does it include an electrical test for shorts or open circuits? Is there a visual inspection, and if so what do they check for? For my project I focused on manufacturers providing the full service of PCB manufacture, parts procurement, and assembly. Then I looked at options with and without programming and custom testing.

Order quantities matter a lot, and some manufacturers are optimized for different quantities than others. Your cheapest option for 50 units may not be your cheapest option for 200 units, or 1000.

Many manufacturers are in China, but be sure to investigate local options too. The labor cost will generally be cheaper in China, but the parts will cost about the same, while the lead times will be longer and the shipping costs higher. Especially if this is your first time manufacturing an electronics assembly, it may be worth paying a little extra to use a local manufacturer who can help walk you through the process.

From my experience, price quotes came in one of two general types: a generic NRE fee (non-recoverable engineering) plus rolled-up price per unit, or a more detailed cost breakdown with separate prices for PCB, parts, stencil, labor, etc. Make sure you know roughly how much your BOM parts should cost, so you can estimate the fraction of a rolled-up price per unit that’s assembly vs parts. A couple of examples may help (numbers are fictional):

Example Rolled-Up Price Quote:

NRE for manufacturing setup: $500, in addition to the quotes below
Qty 50, 4 week turn: $48.00 each
Qty 100, 4 week turn: $43.00 each

Quote includes:

- Fabrication of bare PCB with specs: 0.062" thickness

HASL finish (not lead-free) green soldermask
 1 oz copper
 electrical test

- All parts and components per BOM
- Soldering and assembly
- Visual inspection for defects
- Packaged in individual anti-static bags

Quote does not include:

- Power up or test of final assembly
- Shipping cost to customer

Example Broken-Down Price Quote:

50 X PCB Manufacturing: 118.20 USD
 - Quantity: 50
 - Max X-Dimension (cm): 10
 - Max Y-Dimension (cm): 4.5
 - Layers: 2
 - PCB Thickness (mm): 1.6
 - Copper Thickness: 1 oz
 - Surface Finish: HASL (Hot Air Solder Leveling)
 - E-Test Pass: 100%
 - Separated Sub-Boards: no

1 X Stencil Manufacturing: 49.00 USD

50 X BOM Part Sourcing: 1435.23 USD

50 X PCB Assembling, Manual + Stencil, 30 THT pins, 181 SMT pads: 755.49 USD

Depending on the complexity of your board, type of parts used, order quantity, and the manufacturer, I found that assembly costs for small volumes were typically in the range of $5 to $20 per board. If you’re finding prices substantially higher than that, keep looking. And if you’re finding prices substantially lower, let me know where!

Manufacturer Options

I talked with five different manufacturers. This was my experience:

SDM Assembly (Florida) – They were referred to me by someone on a vintage computing forum who had used them in the past. There’s no company website. I emailed the owner some details and questions, but didn’t hear anything back until six days later. He was friendly and polite, but said they were “assembly only” although they would be happy to do the assembly work if I sent them the PCBs and parts. I got the feeling they were a little overwhelmed with too much work. I never got a price quote.

Kalow Technologies (Vermont) – They contacted me, and I think somebody from Kalow reads the BMOW blog. They were friendly and helpful, but after looking at my design in detail they concluded they couldn’t do it economically, and declined to give me a price quote. I think they’re geared towards more full-service work including testing and packaging. They referred me to:

Imperial Electronic Assembly (Connecticut) – They were referred by Kalow. I contacted them, but never received a response.

Smart-Prototyping (China) – They made some of my PCBs, though I have no prior experience with their assembly work. The best part about Smart-Prototyping is that their formulas used to calculate assembly costs are right there on the web site, so you can do the math yourself. The price quotes for assembly without testing were fairly inexpensive. Testing is charged at a $28/hour labor rate. That seemed high to me – I thought a major reason for manufacturing in China was cheaper labor costs, but maybe that is cheaper. I don’t have anything to compare it to. Their price quote included a detailed break-down of all the costs, which I liked. Communication and questions (in English) went fairly smoothly, but the time difference meant every question and answer involved a 24 hour delay.

Microsystems Development Technologies (California) – They were referred by someone I once sold a computer too, who used them for his own retro-computing project. The owner responded quickly, and got me a price quote on a Saturday. Their quote was the rolled-up type, and for quantity 50 the assembly cost was about 75% more expensive than Smart Prototyping. For quantity 100, however, the price was about equal to Smart Prototyping. We exchanged many emails to answer questions and revise small details, and they always responded quickly and clearly.

In the end, I decided to go with Microsystems, even though they weren’t the cheapest option. The cost of assembly is only one part of the total manufacturing cost, which is dominated by the cost of parts. Even with the higher assembly cost, the total cost at Microsystems wasn’t too much higher than Smart-Prototyping. Spending the extra money to have a local manufacturing partner who’s good at answering questions and is close enough to visit in person feels like a smart investment. And I can always switch to a different manufacturer for future orders if I need to, but so far I’m happy with my choice.

Programming and Testing

Is it worthwhile having the manufacturer test your boards after assembling them? The assembler is responsible for delivering finished hardware that passes all the tests you specify, but if you don’t specify any tests, it’s uncertain what you might get. From talking to manufacturers, even with no testing they will still guarantee against egregious assembly errors like missing parts or parts installed backwards. They may also do basic electrical testing, like checking for power-to-ground shorts with a continuity meter.

Without further testing, there’s a risk that some boards will be defective and you’ll end up paying for non-working hardware. Typically this is caused by solder bridges between adjacent pins on a chip, or dry joints where the solder never bonded properly. Less often, problems will pop up due to damaged or defective parts. Without any post-assembly testing, Microsystems Development Technologies estimated 3-5% of boards might have such problems, but Smart-Protoyping estimated 10-20%. I suspect the difference is due to how pessimistic they are, rather than any inherent difference in their assembly processes.

If you’re making a small run of a few hundred units or less, the testing decision depends on cost and the predicted defect rate. If the expected defect rate is low, and you’re OK shipping potentially defective units to customers, then it might be OK to forgo testing entirely. If 3% of units are eventually returned as defective, but testing would have added 10% to the assembly cost, then you still come out ahead (although your reputation may suffer a bit).

If shipping potentially defective units is not OK, then somebody obviously must test them. Doing it yourself seems like a good way to save money, but don’t forget that your time has value too. If you can do the testing yourself in five minutes, or the manufacturer can do it for $1, it becomes a basic calculation of how much your time is worth to you. Don’t forget that money paid to the manufacturer for testing is tax-deductible, but the value of your own time spent testing is not, unless you incorporate your business and pay yourself a salary.

I think many people in this situation shy away from having the manufacturer do testing because they don’t know how to define the testing requirements, rather than because of the testing cost. That’s certainly true in my case. Is the manufacturer going to hook up a Mac Plus and run some test programs on the Floppy Emu hardware? It seems hard to imagine. Even quantifying exactly what to test, and how to test it, and what results to expect can feel so onerous that it may seem easier just to skip it completely.

Most manufacturers can also do firmware flashing for any programmable parts on your board. This can be done via your programming header after assembly is complete, or in some cases the bare chip can be programmed before assembly (I wish I knew how that worked). This might seem like a waste of money when you can very well program the firmware yourself, but again it’s a question of the value of your time. Do you want to spend two hours plugging and unplugging cables to program the firmware for 100 boards? Or do you want to pay someone else $50 to do it? Flashing the firmware can also serve as a cheap and easy method of testing, since some defective boards will fail the firmware update and be sent for a re-check without needing further tests.

Floppy Emu Self-Test

After way too many hours of deliberation, I decided that Floppy Emu’s manufacturer will do firmware programming and testing. This will add about 5% to the cost, and still won’t catch 100% of assembly problems, but I think it’s money well-spent. When considering the firmware programming by itself, I was ambivalent about having them do it or doing it myself. But the big advantage of having the manufacturer do the firmware programming is that I can include a self-test program in the firmware, which checks the majority of the board’s functions in just a few seconds. So I’m paying them a fair price to do firmware programming I’d otherwise have to do myself, and then I get the benefit of some extra testing almost for free.

What is this self-test, you ask? I’ve been busy putting it together over the past few days, and I’m pretty excited about it. Previously there weren’t any self-test or diagnostic routines of any kind – Floppy Emu just powered on and started working (or not), and that was it. But now it takes a few milliseconds to:

• verify the AVR fuse settings
• verify the version number reported by the CPLD matches what’s expected
• exercise all the lines that connect between the AVR and CPLD to check for bridges, shorts, or open circuits
• verify that the SD card initialized correctly

The “exercise all the lines” test required some substantial re-plumbing of the CPLD, and significant changes on the AVR side too, so thorough testing is needed to be sure I didn’t break anything. But once it’s working, it should be a major time-saver.

The self-test routine concludes with a happy face if everything is OK, a sad face plus error message if a test fails, and a question mark if something is missing (no SD card, or CPLD is blank). I can’t assume that whoever’s running the test is fluent in English, so icons seemed like the way to go.

The manufacturer’s full firmware programming and testing procedure will be:

• flash the AVR microcontroller
• insert SD card
• update the CPLD firmware from the SD card
• press RESET button and check for the happy face on the LCD display

I’ve timed this repeatedly, and it takes about 1 minute 20 seconds, including the time needed to plug and unplug all the cables, cards, and the LCD. Directly or indirectly, this procedure will test everything except the CPLD-to-Macintosh interface (10 pins), the SELECT button, and the SD card write-protect signal. It’s not a perfect test because the CPLD-to-Mac pins aren’t covered, and occasionally my Mac-based testing uncovers intermittent I/O errors that wouldn’t be detected by this kind of testing anyway. But it should catch the majority of typical assembly errors, while also saving me the time needed for firmware programming, all at a reasonable cost. Check back in about four weeks to see how it turned out!

There’s a big difference between building one of something, and building a hundred. When building one, the challenge is simply to get the thing working at all. When building a hundred, the focus changes to issues like how fast you can do the build, and how reliably. Little problems that only crop up rarely start to become headaches. And if you’re like me, you start to get obsessed with achieving 100% reliability without sacrificing build speed or cost.

With Floppy Emu now past the 100 units mark, I can start to get some meaningful data from the assembly process. Thus far slightly more than 90% of the units I’ve built passed all my tests, and were able to be sold. Even for a hand-built piece of hardware, that’s not great. Getting closer to 100% yield will require troubleshooting what went wrong, and making sure it doesn’t happen again, but that’s easier said than done.

Releasing the Magic Smoke

The most common failure I’ve seen is something I call “burnout”, and has affected about 4% of the units. After anywhere from one minute to a few hours of working normally, the Floppy Emu stops functioning, and both the 3.3V regulator and the CPLD become hot to the touch. The AVR, SD card, and LCD still seem to operate normally, but floppy emulation or anything else involving the CPLD no longer work. After some experimentation, I discovered that if the CPLD is removed and replaced using a hot air gun, the Floppy Emu can be returned to normal functioning and the problem does not reappear.

Hot chips imply a short circuit somewhere. Measuring the current draw is tricky, because Floppy Emu is normally connected directly to the Macintosh which powers it, and there’s no place to insert an ammeter inline and measure the current. I finally broke down and built a simple bench test rig, where the Floppy Emu is powered from an external power supply and no Macintosh is involved. This only provides a way to measure the current draw of the whole board, and not individual chips, but it’s better than nothing.

What I found is that a normal board idling on the main menu screen draws about 124 mA. Removing the CPLD with the hot air gun lowers this to 41 mA, implying that the CPLD and the incremental 3.3V regulator current are about 83 mA combined. That’s a bit more than the CPLD datasheet says is typical, but the actual supply current depends on how the CPLD is configured, so it’s within the realm of possibility. The CPLD current likely increases when the device is active and floppy emulation is happening, but I don’t have any way to measure that with the existing bench test rig.

Next, I measured a Floppy Emu in “half burnout” condition. This one actually functioned OK, but after several minutes it would grow pretty hot and stop working. Unlike the other burnout Emus I’ve had, this one would start working again if it were left to cool off for a minute. With my test rig, I measured this board’s idle current draw at 400 mA, more than three times higher than the normal board. Removing the CPLD dropped the current down to 41 mA again, so it seemed clear the trouble was related to the CPLD and not somewhere else.

So what’s going on with this burnout? It looks like something’s causing the CPLD to draw high amounts of current from the 3.3V regulator, resulting in high power dissipation and overheating in both chips. The regulator has an internal safety switch that will protect it from damage, but the CPLD apparently gets toasted. That makes sense, but what causes the high current draw in the first place? Like a good mystery detective, I came up with a few theories, which I think cover all the possibilities:

1. The chip was defective. That’s possible, but blaming faulty chips should always be a last resort. In all the electronics projects I’ve ever built, only once have I ever encountered a problem that was conclusively linked to a faulty part.
2. The PCB was faulty, and two closely-spaced CPLD traces were shorted together somewhere. The fact that replacing the CPLD fixed the problem seems to rule out this theory.
3. A software error in the AVR program or the CPLD config caused two chips to simultaneously drive the same signal to different values. This seems unlikely, as almost all of the signals are unidirectional, and the only bidirectional signals are controlled by a simple mechanism that would be hard to go wrong. A software error should also affect all the hardware, not just a few units, unless it’s some rare timing-based error that only appears in very specific circumstances.
4. The chip was damaged during assembly, due to static electricity or high heat. Possible, but I’ve never encountered a damaged AVR, and it’s the exact same package and pin count as the CPLD, and I handle it exactly the same way during assembly. Maybe the CPLD is more sensitive to mishandling somehow? Seems doubtful.
5. I accidentally shorted two CPLD pins together with a poor soldering job. I carefully checked all the pins with a 10x magnifier, and couldn’t find any shorts. Still, this seems like the most plausible explanation.
6. The “5V tolerant” chip isn’t very tolerant, and continuous 5V inputs eventually lead to damage. The datasheet seems clear this shouldn’t be true. Recommended operating conditions for a high input voltage are between 2.0 and 5.5 volts.
7. “Bad” voltages from the Macintosh damage the CPLD, because it’s the only chip that’s directly connected to the Mac. I can’t rule this out, but it seems unlikely. It’s definitely possible for a vintage Mac’s 5V supply to be out of adjustment, but the CPLD is a 3.3V chip and doesn’t use the 5V directly. The Macintosh signal voltages could be out of whack, but I think that would also cause problems for the Mac itself.
8. The Floppy Emu circuit design pushes the CPLD beyond its maximum ratings, causing damage. Maybe there’s some significant voltage overshoot or undershoot somewhere that can cause damage, or a big transient that happens at power-on. Possible, but without a specific culprit to investigate it’s hard to say.

Of these, the most likely explanations are the poor soldering job and the chip damage caused by a design that exceeds maximum ratings. Replacing the CPLD with a new one would fix both problems, since it replaces both the soldering job and the chip itself at the same time. To separate these theories, I took the “half burnout” board, removed the CPLD with the hot air gun, then resoldered the same CPLD. It still failed the same way, and drew exactly the same amount of current, demonstrating that the problem lay with the chip itself and not the soldering.

So I’ve got a few damaged CPLDs. Maybe they came defective from the factory (theory 1), maybe I damaged them during assembly (theory 4), or maybe a rare software bug causes damage (theory 3). Maybe an evil Mac is frying them with 12V logic signals (theory 7). But I’m betting on theory 8, and it’s somehow my own fault for a design that zaps the CPLD with occasional voltage overshoots, power-up transients, or other circuit gremlins that lead to failures in a small fraction of the CPLD chips.

Unfortunately there’s not a lot I can do to test this theory with the current hardware. I can only measure the current drawn by the whole board, not a single chip, and I can’t do any measurements while the board is connected to a Mac. Even if I could, an instantaneous surge in current would be met by the CPLD’s decoupling caps more than the power supply, so it might not even show up in any measurements I did. As for checking individual signals for overshoots or weird transients, it’s just not practical. The CPLD is a surface mount chip with tiny 0.5 mm pin spacing, so there’s no way to connect an oscilloscope or other probe. For now, then, there’s probably nothing to do but keep testing, and try to look for patterns in the timing and nature of future failures that might point to a more specific cause.

I’m something of an anti-backlight guy, and I intentionally designed Floppy Emu with the LCD screen’s backlight disabled. Without the backlight, the text is crisp and the contrast is excellent. With the backlight, the text looks more washed out, and imperfections in the LCD glass become visible. Nevertheless, some people really want a backlight, so this post will show you how to hack your Floppy Emu to turn the backlight on.

The LCD already has four backlight LEDs built-in to the edges of the display, and all you need to do to enable them is solder a resistor or a piece of wire to the right pins. The procedure is slightly different, depending on which version of the LCD you have.

For Floppy Emus with serial numbers 51 and higher, connect the holes labeled LIGHT and GND at the top-right of the LCD with a low-value resistor, or a plain piece of wire. If you use a resistor, I recommend something in the range of 10 to 50 Ohms (lower values will give a brighter light). Because the LIGHT and GND pins are so close together, you’ll probably need to orient the resistor vertically, as shown in the photo. For the brightest backlight, use a plain piece of wire instead of a resistor. This won’t damage the LCD, because it already has a small backlight resistor built-in.

For Floppy Emus with serial numbers 1-50, the LCD design is slightly different. Connect a resistor between the pins labeled LED and VCC at the top of the board. You’ll probably find that there’s already a cut-off pin at those two spots, so you can solder your resistor to those pins. I recommend a resistor in the range of 47 to 100 Ohms. Don’t use plain wire here – these LCDs do not have any built-in resistors, and using them without any resistance may damage the LCD.

Some of the LCDs have a white backlight, and some have blue. It’s a surprise!

It’s been quiet here in electronics hobby land, but I do have some good news to report: as of now, all Floppy Emu boards are professionally assembled by Microsystems Development Technologies in California, USA. No more hand assembly! It’s a glorious thing to receive a big box stuffed with assembled boards, and as good as a kid opening a package on Christmas Day. Microsystems wasn’t the cheapest option I found, but they weren’t too far off. I was convinced to go with them thanks to their quick and helpful answers to my many questions, and by their nearby location in San Jose. That’s a short drive from where I live, so when the boards were finished I was able to drive down there and meet the owner in person, and discuss potential changes for future board revisions. That alone was worth the cost difference versus slightly cheaper Asian alternatives.

Microsystems took my design files and bill of materials, and handled everything from there. They made the PCBs, purchased the parts, assembled everything, programmed the chips, and ran the board self-test. That’s a huge time savings for me, and it also removed a major source of potential faults because they handled all the tricky surface-mount work.

Unfortunately, the “finished” boards from Microsystems still aren’t quite ready to sell. It takes another 15-20 minutes of labor per board for me to attach a DB-19 connector (or build a DB-19 extension cable, depending on the type of board), assemble an LCD module, adjust the LCD contrast, and run the board through real-world file copy tests on a couple of vintage Macs. I thought Microsystems wouldn’t be able to handle those steps very easily, so I asked them to skip it. After more discussion, though, it looks like they can do everything except the file copy tests without much trouble. It’ll cost me a few extra dollars, but if it saves me time and headache, it’s probably worth it.

One bummer is that I’m still seeing a few boards that consistently fail my file copy tests, and can’t be sold. This happened sometimes with the old hand-assembled boards, and I never did find the cause, but I suspected it was related to my lousy hand-soldering job. But since it’s still happening with the professionally assembled boards, it’s probably some kind of design flaw. Ugh. For the time being I’m just setting these boards aside in the reject bin, but eventually when I’m sufficiently motivated I’ll see if I can figure out what’s wrong.

TL;DNR – While it doesn’t solve every problem, having professionals source the parts and assemble the boards is very nearly the best thing since sliced bread. I’m happy to give my soldering iron a well-deserved rest.

Sometimes a Floppy Emu board fails one of my functional tests, and I can’t find the cause of the problem. I have several boards that appear to work fine for 400K and 800K disk emulation (tested on a Mac Plus and Mac 512K), but that don’t work reliably for 1.4MB disk emulation on newer Macs. Instead of throwing these in the trash, I’ve decided to sell the “scratch and dent” boards for $15.

If you’ve got a Mac 512K, Plus, or older Mac SE that only supports 400K and 800K disks, one of these boards might work well for you. Because the boards failed some of the functional tests, there’s definitely a problem with them, so keep that in mind when deciding between these and the regular Floppy Emu boards. Scratch and dent boards are warranted for 400K and 800K operation for 30 days. The 1.4MB emulation on these boards isn’t guaranteed to work, but maybe you’ll get lucky.

These Floppy Emu boards have a built-in connector, and are physically identical to those that normally sell for $89.
 
Update: The scratch and dent boards have all been sold. Thanks for the interest!

Chris Siegle has designed an amazing Floppy Emu case made entirely out of LEGO bricks! The case features LED “light tubes” and working buttons. Step-by-step build instructions are here. Thanks Chris!

An official laser-cut case for Floppy Emu has finally arrived! It took a lot of prototyping and fiddling with tiny parts, but I hope you’ll agree the result was worth it. The case is only 6mm larger than the board itself, accommodates boards with the extension floppy connector or the built-in connector, and features light pipes to channel the LED’s to the outside of the case. The whole thing is cut from a single sheet of 3mm acrylic, and assembles like a 3D jigsaw puzzle.

I hope to offer these cases for sale soon, but I need help determining how many to make and in what colors. If you might be interested in a case, drop me an email or leave a comment below, and mention your color preference. Cases will probably be $19, and the color will be either clear or black.

 
Case Design

I was surprised how challenging it was to make a “simple box” case. My first plan was to design a 3D printed case, but I quickly abandoned that idea once I realized how expensive it would be. 3D printing is an impressive technology, but home 3D printers don’t really have the necessary reliability or speed for consistent manufacturing, and the material cost is significant. Online 3D printing services like Shapeways are another option, but they’re even more expensive. I also doubted I had the necessary 3D modeling skills to design a workable 3D case, so the idea never got very far.

The best alternative seemed to be a laser cut case, constructed of multiple flat pieces assembled into a box shape. Adafruit’s laser-cut enclosure design tutorial was a big help, as was the web-based design tool MakerCase. Before I knew it, I’d designed a basic six-sided box of the proper dimensions, with finger joints at the edges to hold it together. But would it work? Designing a case using finger joints this way requires compensating for the kerf – the thickness of the laser cut. Assume a zero sized kerf, and the box won’t hold together. A 5mm wide tab will end up closer to 4.8mm wide after cutting, while a 5mm wide slot will end up closer to 5.2mm, and the tabs will sit loose in the slots. To compensate, the tabs in the design file should be slightly wider than the desired finished size, and the slots slightly narrower, but not too much. Overestimate the kerf, and the finished tabs will end up wider than the slots, preventing the parts from fitting together at all.

Next I added holes for case screws, the SD card slot, and the extension cable. Easy enough. But what about the buttons? Floppy Emu has four pushbuttons that are needed to operate it, so I couldn’t just seal them up inside the case. I could have cut a big finger-sized hole in the case lid above each button, so you could reach in and press it, but that seemed ugly and awkward. I could also have left the area above the buttons entirely uncovered, but that seemed even less appealing. If I were designing a product that was *always* in a case, I could have switched to a different type of push button with a long plunger that extended outside the case. But I’m not, and that would be goofy for everyone using a Floppy Emu without a case.

 
The Stick

I finally concluded the only decent solution was to use some kind of stick to poke through a small hole in the top cover, and press the push button inside the case. This proved to be tricky to get right. If the stick were just a straight shaft, it would fall out if the case were turned upside down. And there was no positive force holding the bottom end of the stick onto the push button. It might wobble around or even slide off the button entirely, causing the whole stick to fall down inside the case. My solution was to add a crossbar to the stick to prevent it from falling out, turning the stick into a sword, and hoping that a tight fit between the sword and the hole would prevent it from sliding around. The light tubes used the same sword design, but modified in size to fit on top of an LED instead of a button. Voila! A finished design.

I sent the design file off to Ponoko for manufacturing, and about a week later I received the laser cut parts in the mail. With eager anticipation I separated the parts, fit them together, and bzzzzt! I had overestimated the kerf, and the parts didn’t fit together at all. Total failure. I went back to the design file, reduced the kerf estimate by half and made a few other mods, and sent revision 2 off to Ponoko. Another week passed. Finally I got the new parts, and it worked! Sort of.

The rev 2 case fit together, and the Floppy Emu board fit inside of it, so that much was looking good. But the swords had big-time slippage problems. They were too loose, and were constantly wobbling around or slipping down inside the case. For revision 3, I made the swords a bit thicker relative to the holes, so they’d fit more tightly and have less room to wobble. I also added “feet” to the swords, to help keep them centered on the buttons and LEDs.

Another week went by, and when the rev 3 case parts arrived, everything looked pretty good. The button swords still wobbled a bit, but not far enough to cause problems or fall off the button. The LED swords were more problematic, and sometimes wobbled off the LED’s centers, but generally stayed close enough to continue working as light pipes. Before offering these cases for sale I’ll probably do a rev 4 design to tighten everything up a little more, but rev 3 is definitely useable. Hooray!

Rev 3 also includes two alternate versions of the base and left side pieces: one for boards with a built-in floppy connector, and one for boards using the extension connector. That makes eight total side pieces, of which you’ll use six.

 
Sword Assembly

The only aspect of the design I’m not thrilled with is handling of the swords during assembly. How do you get those little buggers in there and aligned correctly, before you put the top on the case? You can’t just balance the swords on the buttons and then lower the top plate onto them – the swords won’t balance by themselves. One option is to assemble everything upside down: put the top plate upside-down on the table, then place the swords into the holes in the top plate, and finally lower the inverted Floppy Emu board onto the whole assembly. That works, but it’s pretty awkward.

The best solution I’ve found is to do assembly right-side up, and use tape to temporarily hold the swords in the top plate. You assemble the bottom and side pieces normally, and place the Floppy Emu board inside. Then you loosely cover all the top plate holes with tape, and push the swords up from underneath until their top surfaces touch the tape. Now you’ll be holding a top plate with all the swords dangling down under it. Finally, you lower this whole package onto the rest of the assembly, add the case screws, and then remove the tape. It’s not the most elegant system, but it works.

 
Colors

I originally planned to design the case in black, to give the final product a sleek iPhone-style appearance. But when I did a prototype in clear acrylic, my wife loved it and predicted it would be much more popular than black. One big advantage of a clear case is that it won’t need light pipes at all, since you can see the LEDs inside. The material is also a bit cheaper. But the etching on a clear case is difficult to see from some angles, and the final result with its exposed internals looks more like a science fair project than a professional product. What do you think? Which would you prefer?

The revision 4 Floppy Emu cases are here, and they look great! Clear and black acrylic in different layouts, birch plywood, and chocolate-colored hardboard. I’m having too much fun putting these together. The purpose of revision 4 was to test a few layout tweaks and a sampling of different materials, so I could decide which one to get manufactured in larger quantities. The layout changes are probably the most important, but first let’s talk about materials.

First is a birch plywood. It’s actually just a thin birch veneer over some kind of filler layer, but it still looks very nice. You can see the veneer layers when you look at the board edge-on, and the edges are quite dark in color compared to the face of the board. This gives the case a high-contrast look. The engraved logo and text came out well, although they probably could have been a bit darker. The areas of the the board near the holes and corners are baked a darker shade of brown from the heat of the laser. The white case screws look decent with the light birch, though it’s not the best match. Overall the plywood case came out well, but I can’t say it’s my favorite.

Second up is hardboard, which is just a higher-density version of the ubiquitous MDF fiberboard. You might think fiberboard is icky, but this case came out great and is easily my favorite. The faces are a dark chocolate brown color, while the edges are near black, and the combination looks nice together. The black case screws accent it nicely too. The engraved logo and text are clearly visible, yet still understated. The quality of the engraving is also extremely sharp and crisp. There’s no darkening of the board near holes and corners, like occurred with the plywood. The one big drawback of hardboard is that it requires more than twice as much laser time to cut than the other materials do, which increases its cost. If I sold a hardboard case, it would have to be for $4 or so more than a case made from acrylic or plywood.

Black acrylic came out well too, and as expected it’s very similar to the previous cases I did in clear acrylic. I’m not in love with it, though. It’s very glossy, and it shows every fingerprint and smudge. The engraving is pretty good, but it’s like matte gray set against shiny black, and is difficult to see from some angles. Maybe it’s good… I can’t decide.

The new clear acrylic case is almost identical to the old one, except I’ve increased the sizes of the finger joints from 4 mm (as shown on the black case above) to 18 mm. This gives the edges a much less busy look, and helps the pieces fit together more easily. Clear acrylic shows fingerprints too, though not as much as black. And everybody likes clear, right?

I don’t have photos of the layout changes, but they’ll help save manufacturing dollars and assembly headaches. Believe it or not, going from 4 mm to 18 mm finger joints cuts almost $1 off the cost of the case. Fewer direction changes for the laser as it’s cutting means it can finish the job quicker. I also eliminated the two extra pieces I’d been using to accommodate boards with a built-in floppy connector, and instead there’s now a punch-out section on two of the boards that can be removed if necessary, opening a space for the connector. I tested the punch-outs in acrylic and they worked well – didn’t break loose accidentally, but could be broken off using only finger pressure when needed. I didn’t think to include punch-outs in the two wooden cases, but hopefully they’ll work equally well there.

I also made several tiny size adjustments to help make the “swords” for the LEDs and buttons fit just right. And I didn’t quite get it perfect, but now I think I have the dimensions I need to nail it next time. The buttons have tiny nubs on them to help prevent them from slipping back through the top plate while you’re assembling the case. This worked pretty well, but wasn’t 100% reliable. I suspect it will still be necessary to use the tape trick during assembly that I described last time. Hopefully people won’t mind that too much.

Armed with all this information, I think I’m about ready to do a larger manufacturing run of at least a few dozen cases. Given what I saw from these, I’ll probably make the majority of them clear acrylic, and maybe make a few hardboard ones I’ll sell for a couple dollars more as “premium cases” or similar. Thanks to everyone who wrote in with their preferences and requests. Check back in about 10 days and I hope to have a stock of new cases ready to go!

Custom-made cases for Floppy Emu are finally here, and available for sale now on the Floppy Emu home page! These laser-cut enclosures will keep your board protected in style. The clear acrylic universal case is $17, and fits all models of Floppy Emu boards. The deluxe brown hardboard case fits the Floppy Emu with Floppy Extension Connector, and is $19. Both styles of case require assembly, which takes about 10 minutes and a screwdriver.

The prototype cases are also available for sale at a small discount, including black acrylic and birch plywood. The dimensions on the prototypes are slightly different, so they’re a bit more fiddly to assemble, but once assembled they look and feel the same as the regular cases.

I’m also testing out a new shopping cart interface for the first time, so let me know if you have any trouble while making a purchase.

It’s been roughly a year since I turned a personal electronics project into a retrocomputing mini-business, which makes now a good time for a short review. When I started dabbling in floppy disk emulators for vintage Macintosh computers, I never would have guessed there would be other people out there who wanted one of their own. It’s been an interesting adventure!

After selling a few prototypes on eBay, and giving away a few boards as gifts, the first real sale was board S/N #0008 on December 9, 2013. Since then I’ve made 223 Floppy Emu boards, sold 182, junked 4 that had defects revealed in testing, replaced 2 that had problems during the warranty period, and have 35 in inventory (aka my floor).

The first 123 boards were built by hand, one at a time, one component at a time. There’s not a lot to say about that experience except that it sucked, and I inhaled a lot of leaded solder fumes. Of those 123, there were 3 with major defects that had to be junked, and 4 more that only worked at 400K/800K disk speeds and were sold at a discount. Since serial number #0121, all boards are now professionally assembled by Microsystems Development Technologies in San Jose, CA. That’s helped improve the quality, and restore my sanity. Of the 55 boards from Microsystems that I’ve tested thus far, only one has had a defect.

Initially, all Floppy Emus were sold with a built-in DB-19 floppy connector, so the board could be plugged directly into a Mac’s rear floppy port. I later introduced a version with the DB-19 on a 3 foot extension cable instead of soldered directly to the board, and that’s proven to be very popular. Since mid-August when I lowered the price of the extension connector model by a few bucks, it has outsold the built-in connector model by 4:1. At some point I’ll probably drop the model with the built-in connector, and standardize on the extension connector model for all sales.

Cases for Floppy Emu have only been available for a short while, but they’ve been well-received. The attachment rate for cases (percent of people buying a board who also buy a case) has been 83%, much higher than I’d expected. And despite my predictions, the brown hardboard case has been much more popular than the clear acrylic case. I’ve already sold out of the hardboard cases, and just placed an order today to manufacture more.

About 50 percent of sales have been to the United States, which isn’t too surprising since that’s where I am. Australia, Canada, and the UK have also all seen significant sales. No sales to Africa or Antarctica yet, but all the other continents are represented.

Shipping has gone smoothly, even internationally. I’ve only had one shipment (to New Zealand) that never reached the buyer.

My order handling and fulfillment process is still horribly inefficient, but there aren’t enough sales to justify a big investment in streamlining things. Between manually testing each board on a Mac 512K and a Mac IIsi, downloading Paypal order details, fighting the post office web site to print electronic postage, generating sales receipts, wrapping boards, packing boxes, and driving to the post office, there’s about 30 minutes of labor time required for every single sale. Then there are often post-sale questions, which require additional support time. It’s not exactly a low-overhead business.

I’m excited to see what year 2 will hold for Floppy Emu. Thanks for coming along for the ride!

Finally after nine months, a progress update on HD20 emulation! Back in February I wrote about my efforts to reverse engineer the Apple HD20, an external 20 MB hard drive for the Macintosh that was introduced way back in 1985. This was before the introduction of SCSI support, so the HD20 connected via the Mac’s floppy port. With luck, that might make it possible to emulate an HD20 using the hardware I previously developed for Floppy Emu, the Macintosh floppy drive emulator. 20 MB (or more?) of external storage for a Mac Plus or other vintage machine, stored on an SD memory card, with no dependencies on SCSI or aging rotational disks! But doing it would require understanding how the HD20 worked well enough to emulate it.

 
A Little History

The HD20 has a famously strange reputation. Despite sharing the same DB-19 connector as a floppy drive, it used an entirely different communication protocol. When SCSI support was introduced in 1986, external hard drive solutions quickly adopted the new standard, so the HD20 was the only hard drive to ever use this protocol. The protocol was never documented anywhere publicly, and eventually became an old, obscure mystery. Emulating the HD20 was virtually impossible.

Then about a year ago, a couple of ancient Apple internal documents about “directly connected disks” surfaced on the internet. The term “HD20″ didn’t appear anywhere in them, but it was clear that’s what they were about. Two docs dated March 1985 and May 1985 outlined the DCD communication protocol. They described a state-based command-and-response system, in which data was transferred in groups of 7 logical bytes encoded into 8 physical bytes. But the docs conflicted with each other in many details, and were silent on other critical points. And as I later discovered, both docs conflicted with tests performed on a real Macintosh system. Still, it was enough to get started. In my February experiments, I got as far as fooling the Mac into believing an HD20 was connected, and receiving/decoding a drive status query. But I was never able to send back a reply, and I eventually lost interest.

 
New Preparations

Thanks to a slow trickle of people who kept encouraging me to look at it, I recently dusted off the HD20 project again. I could receiving a drive status query, but how could I send a reply? What kind of handshaking was needed to tell the Mac a reply was ready? How big was the reply, and what data did it contain? What checksum method did it use? Armed with the DCD docs and some educated guesses, I programmed the Emu hardware to send a drive status response. Then to test it, I wrote a Macintosh program to read arbitrary sectors from disk ID #2, the first connected DCD.

Side note: it’s not a simple thing to write new software for a 30-year-old computer system! In order to create my test program, I used an old copy of Metrowerks Codewarrior, running under emulation in Basilisk II. The finished program was saved to Basilisk’s virtual hard disk image. Then I mounted a virtual floppy disk image in Basilisk, and copied the program to it. After quitting Basilisk, I copied the floppy disk image file to an SD card, put the SD card in a second Floppy Emu (the first one having been turned into an HD20 Emu), booted my Mac Plus with the Floppy Emu attached, mounted the floppy image, and copied the program file to the Plus’s external SCSI disk. Oof!

The Mac really doesn’t like to boot if it thinks there’s a sort-of-working HD20 attached. It either hangs for long periods, or complains endlessly about disk errors. If I used the SCSI drive and managed to boot into the Finder, the Finder would freeze forever while trying to communicate with the emulated HD20, so I could never actually launch my test program. Doh! My solution was to configure the Mac to run the test program immediately at boot-up, instead of running the Finder. With the not-really-an-HD20 disconnected, this can be done by highlighting the test program, then selecting the Finder’s Special -> Set Startup menu.

 
Crawling towards Two-Way Communication

At last I had something to test, and of course it didn’t work. The test program reported error -17, which according to Inside Macintosh means “driver can’t respond to this control call.” I could tell my hardware was receiving the drive status command, and trying to send a reply, but beyond that I was blind. Did the Mac receive the reply, but reject it as misformatted? Was it the wrong size, or encoded incorrectly? Maybe the handshaking wasn’t working, and the Mac wasn’t even seeing any response at all? No matter what I did or what I tried, all I got was error -17, with no further clues to help me troubleshoot.

From another Apple document, I knew there were supposed to be HD20-specific error codes, and I could see places in the Mac ROM disassembly where those errors were generated. They are:

; New HD20 error codes

wrtHsLw         equ     $10             ; HSHK low before starting
wrtHSLwTO       equ     $11             ; Time out waiting for HSHK to go low
wrtHSHighTO     equ     $13             ; Time out waiting for HSHK to go high
rdHsHi          equ     $20             ; HSHK high before starting
rdSyncTO        equ     $21             ; Time out waiting for sync ($AA) bye
rdGroupTO       equ     $22             ; Time out waiting for group
rdHoffSyncTO    equ     $24             ; Time out waiting for sync after holdoff
rdHsHiTO        equ     $25             ; Time out waiting for HSHK high
rdChksumErr     equ     $26             ; Checksum error on response packet
invalidResp     equ     $30             ; First byte in response packet was wrong
sqncNumErr      equ     $31             ; Sequence number in response packet was wrong
dNumberErr      equ     $32             ; Drive number in response packet was wrong
noResp          equ     $40             ; No response packet ever received

Those are some great low-level error codes covering handshaking, checksums, and other details. Why was I only getting error -17, instead of the more detailed codes? With no useful feedback, I continued pounding away at the problem blindly for far longer than I should have, but got nowhere.

Something was generating that -17, and I was determined to find out what. On the early Macs, most of the operating system code is stored in ROM, and this includes the HD20 I/O routines. It’s possible to pull those ROMs, dump the data from them, and run it through a 68000 disassembler. Other people have done this long ago. But the result is only useful to a point – it’s just raw assembly language code, without any symbolic names or comments or any other context to help understand what it’s doing. Just thousands of lines like these:

SubA.L    A4, A4
SubA.L    A5, A5
MoveQ.L   $1, D3
MoveQ.L   $0, D6
MoveQ.L   $0, D7
Move      $64, $1C0(A1)
Move      $4650, $1C2(A1)
Cmp.B     $3, $19C(A1)
BNE       L4809
Move.L    $14C, D7
Move      $A, $1C0(A1)
Move      $2710, $1C2(A1)
Lea.L     $1C4(A1), A4

Ugh. But with slow and painful effort, it’s eventually possible to make at least partial sense of it all. For example, looking backwards from this code, I can see that A1 was previously loaded from memory location $000134, which I know from other Mac programming resources is a pointer to a structure containing drive state, called SonyVars. So all those references like $19C(A1) in the code above are offsets into this SonyVars structure. And from yet another Apple internal document, I learned that offset $19C in SonyVars is the DCD command number. So here’s some code that (in part) checks if the command number is 3 – the drive status command, and branches away somewhere else if it’s not. If it is command 3, it stores the curious number $14C (332 decimal) in another register. Which after more tedious analysis, turns out to be the size of the expected drive status reply. Except for some extra padding and modulo-7 business, which I discovered after still more analysis.

If you feel dizzy, I’ll pause for a moment if you want to lean over and vomit.

Here are the DCD-specifc SonyVars offsets and constants that I learned:

sonyVarEnd      equ     $128
; (4) Direct-connect driver locals.

TagSize         equ     20                      ; 20 bytes tags/block
dcdLclLth       equ     28                      ; (use fields through DriveMisc)
drive3          equ     sonyVarEnd              ; first DCD                     
drive4          equ     drive3+dcdLclLth        ; second DCD
drive5          equ     drive4+dcdLclLth        ; third DCD
drive6          equ     drive5+dcdLclLth        ; fourth DCD
stsRtnAddr      equ     drive6+dcdLclLth        ; DCD status call return address
dcdCmd          equ     stsRtnAddr+4            ; command byte to DCD
response        equ     dcdCmd                  ; response byte (command+$80)
seqNum          equ     response+1              ; mb sequence number (sys commands only)
status          equ     seqNum+1                ; returned status bytes
startBlock      equ     status                  ; starting block # (in commands)
driveOut        equ     startBlock+3            ; we send drive number in this field
driveIn         equ     status+2                ; low 6 bits
tagBytes        equ     status+4                ; tag bytes get stuffed here temporarily
devType         equ     tagBytes                ; first 20 bytes of status are written
devManufctr     equ     devType+2               ;       in the 20-byte tag buffer
devChar         equ     devManufctr+2
devBlks         equ     devChar                 ; low 3 bytes of this longword
devSpares       equ     devChar+4
devBadBlks      equ     devSpares+2
devMisc         equ     devBadBlks+2            ; 8 bytes misc
bufSize         equ     tagBytes+tagSize        ; number of bytes/block
lastStatus      equ     bufSize+4               ; last status returned
lastResult      equ     lastStatus+4            ; error type
dcdFlags        equ     lastResult+1            ; flag of whether we've done a reset
chkTime         equ     dcdFlags+1              ; 100usec check ready count
maxTime         equ     chkTime+2               ; maximum number of checks
stsBuffer       equ     maxTime+2               ; 512 bytes of status
devReserve      equ     stsBuffer
devIcon         equ     devReserve+44
devFiller       equ     devIcon+256             ; 32 bytes for optional name
diskVarLth      equ     devFiller+32
stsBufSize      equ     diskVarLth-stsBuffer

; device characteristics byte:
devChEject      equ     4               ; ejectable if 1
devChWP         equ     3               ; write protected if 1
devChIcon       equ     2               ; icon available if 1

; (4) Direct-connect drive constants.
blkSize         equ     512             ; 512 bytes data/block
syncByte        equ     $AA             ; Sync byte for start of transmission

noError         equ     0               ; resultTypes
nonZerStat      equ     1
comErr          equ     2

Applying these offsets and constants to the ROM disassembly, and doing many hours of analysis, I was finally able to construct a halfway decently commented version of the HD20 I/O routines. It’s not pretty, but it’s enough to resolve the conflicts and unanswered questions left by the DCD documents. Take a look, if you dare: macintosh-HD20-io-routines.asm

 
Checksum Error

This ROM analysis finally revealed one crucial fact: the “missing” HD20 error codes were packed into the most significant byte of the 4-byte value lastStatus, which is set by the disk I/O call. My test program had been displaying this value all along, in decimal format. I had seen lastStatus values like 637534208, but just assumed it was some uninitialized garbage value. But wait, 637534208 in hex is $26000000, and from the table above, $26 is the error code for “checksum error on response packet”. HOLY SHIT! This was my eureka moment, my Rosetta Stone, when I was finally able to get meaningful feedback instead of those blasted error -17′s. I could make changes in the emulator routines, and see changes in the error codes reported by the Mac, and start to do real troubleshooting. Yes!

A checksum error could be caused by many things. I might have the wrong checksum algorithm, or be putting the checksum value in the wrong spot, or encoding the whole message improperly, or any number of other mistakes. Without being able to see the data as it was received by the Macintosh, it was hard to say what was wrong. I was about to get out my oscilloscope and logic analyzer, but then I took another look at the ROM disassembly. After a drive status response, even if there was a checksum error, the response data should be available at SonyVars+$19C. I already had MacsBug installed on my Plus, so I hit the interrupt switch, and used the dm command to display the region of memory. Ta-dah! There was my response data, seemingly received perfectly:

The first byte was $83, which was the command number plus $80. Afterwards followed a pile of other fields and flags, some of which I filled with sequences of consecutive numbers so I could recognize them in the debugger. But there were a few oddities, like the 14-byte break between 07 and 08 in the sequence on the second and third lines. At first I thought this was a bug in my sending code, but it turns out that the Mac actually stores it this way intentionally. I don’t know why, but from examining the ROM disassembly, it’s clear that after the first 26 bytes are received, it jumps the buffer pointer to a new address and stores the remainder of the data there.

The other odd thing about this memory dump completely escaped my notice at first. In the sequence ending on the 22nd line, notice how the last two bytes are FCFC? The expected continuation of consecutive values should be FCFD. This was a clue whose meaning I didn’t discover until later.

Unfortunately, the ROM routines don’t actually store the checksum byte itself, so I couldn’t use MacsBug to examine it and see why it was wrong. It was that FCFC value that finally led me to the answer. For reasons I still don’t understand, it appears that the last byte in a transmission I send from the Emu hardware to the Mac isn’t received correctly. The last byte contains the least significant bits of the preceding seven, which include the checksum byte. By appending an extra dummy byte onto the end of the transmission, the LSB byte was now received correctly, and the last seven bytes before it could be correctly reconstructed.

Once I made this fix, the test program started reporting something new: error -19, read error. And the Emu received a new command after #3 drive status: command #0, read block. The Mac had accepted my drive status reply, and was continuing on to perform a read request! Two way communication at last! Of course I hadn’t implemented a handler for block read requests yet, that was next. But it was time to take a break, and celebrate my progress to this point.

Here is the correctly-formatted drive status structure:

#define DEVICE_CHAR_DISK_IN_PLACE 0x02
#define DEVICE_CHAR_ICON_INCLUDED 0x04
#define DEVICE_CHAR_WRITE_PROTECTED 0x08
#define DEVICE_CHAR_EJECTABLE 0x10
#define DEVICE_CHAR_WRITABLE 0x20
#define DEVICE_CHAR_READABLE 0x40
#define DEVICE_CHAR_MOUNTABLE 0x80

struct DriveStatus
{
	uint16_t deviceType;
	uint16_t deviceManufacturer; // Apple = 1
	uint8_t  deviceChars; // characteristics
	uint8_t  numBlocks[3]; // 3 bytes number of blocks on device
	uint16_t numSpares;
	uint16_t badBlocks;
	uint8_t  reserved[52]; 
	uint8_t  icon[256];
	uint8_t  padding[16]; 
};

The structure is 336 bytes. A valid drive status response is:

$83 - command number plus $80
$00 - pad
$00 - status high byte, zero means no error
$00 - status low byte, zero means no error
$00 - pad
$00 - pad
DriveStatus struct
checksum - choose this so the sum of all bytes (including this one) is 0 modulo 256

This is 343 bytes. Then the response must be encoded using the 7-to-8 encoding method described in the DCD doc, and in my posting from last February. This results in 49 groups of 8 encoded bytes each that are actually sent to the Mac.

 
Checksum Non-Sequitur
Story time about checksum errors: my first computer was an Atari 800, which my family bought when I was 12. Day 1 when it arrived from the store, I attempted to load my very first program from cassette tape. The Atari reported “ERROR 143″. Confused, I consulted the printed manual to learn that error 143 meant “SERIAL BUS DATA FRAME CHECKSUM ERROR”. This was the full explanation, and the only help provided for the error. At the time, those words made as little sense to me as “BYTE VECTOR DIRECTION BUFFER INTERRUPT” might have, and I nearly threw the machine out the window. Fortunately it worked the second time I tried it, and my future in computer technology was assured.

 
Whee!

To prove that the drive status response was really working, I whipped up an ugly BMOW icon, and stuffed its bytes into the icon field of the DriveStatus struct sent from the Emu. Now when I try to mount the emulated HD20 in the Finder, I see the message shown in the photo at the top of this post. Woohoo, that is one ugly icon! But it comes from a successfully received drive status reply, so that makes it awesome.

There are still plenty of other issues to resolve before I can get full HD20 emulation working, not the least of which is actually implementing the read and write commands. Beyond that, here’s a strange one – if you move the mouse during a data transmission, it fails! The Mac ROM routines poll the SCC and VIA chips during HD20 transfers, and if there’s a pending interrupt, it puts the HD20 into a holdoff state so it can service the interrupt. I’m a little hazy on the details of how that works, and I haven’t yet tried to implement the holdoff logic. So for now if you move the mouse or do anything else to generate an interrupt, the transfer fails.

The bigger issues may be unrelated to the HD20 code itself. My current prototype uses the Floppy Emu hardware, but it replaces the Floppy Emu software rather than adding to it. In particular, I don’t think there are enough logic resources in the Emu’s CPLD chip to handle both floppy and HD20 emulation. This would mean you’d have to flash new firmware every time you wanted to switch between emulation types – not exactly a great user experience.

It’s also unclear which Macintosh models could make use of HD20 emulation. The Mac 512Ke and Mac Plus definitely have HD20 support in their ROMs. The Mac 512K can use an HD20 if you first boot it with a System file containing the HD20 Init – but that would require having a working floppy drive and floppy disk, or a second Floppy Emu to serve as the boot disk. According to mac512k.com, the Mac SE, Classic, IIci, and Portable also have HD20 support in ROM, but the SE/30, II, IIx, IIcx, IIsi, IIfx, and LC don’t. I assume that means anything newer than those machines doesn’t have HD20 support in ROM either. It’s not clear if newer machines could make use of the HD20 System Init, but if they could, they’d be subject to the same requirement of having a working floppy drive & disk or a second Floppy Emu for booting.

Even if HD20 emulation only proves useful to owners of the 512Ke, Plus, SE, Classic, Portable, and IIci, that’s still a lot of people! If any Floppy Emu owners with an SE/30, LC, or II-series machine other than the IIci would be willing to help test this, please let me know.

Good news, HD20-ers! I have rudimentary HD20 emulation working now, and I was able to use it to boot my Mac Plus. This runs on the standard Floppy Emu hardware, which means the same hardware can function as a floppy drive emulator or as a single large hard drive. If you’ve already forgotten, the HD20 was a mid-1980′s Macintosh hard drive that connected via the floppy port. Anyone with one of my Floppy Emu boards who’d like to help test this new firmware, grab the files and give it a try! But if you’re looking for something more complete and polished, you’ll need to wait a while more – this first firmware is very rough.

 
Version 0.1

• You can’t move the mouse during disk I/O, not even a tiny bit, otherwise bad things happen. It’s hard to avoid! The same thing goes for using the serial port, or anything else that will cause CPU interrupts. I had to single-click on icons and then press Cmd-O to open them, instead of double-clicking and accidentally nudging the mouse. Obviously this needs to be next on my list of things to fix.
• This is read-only emulation for the time being. The disk appears with a lock icon in the Finder.
• The disk icon on the desktop looks like random garbage. But in the disk’s Get Info window, it looks fine. Something about needing an icon mask, maybe? But there’s no place in the HD20 drive status structure to supply an icon mask, as far as I can see.
• In the disk’s Get Info window on System 6.8, the “where” field shows random garbage. For a SCSI disk, this field shows “SCSI1″. If someone has a real HD20, please do Get Info on the disk and let me know what it says for “where”.
• SD card transfers are totally unoptimized, one block at a time reads. This should be possible to improve significantly. But it still feels decently fast already: at least as fast as a floppy if not more so. It boots up to the desktop in 5-10 seconds.

I need help testing which Macintosh models have built-in HD20 support, and which don’t but can use an HD20 after booting from another disk with the appropriate software. From what I’ve learned so far, I believe these Macintosh models have HD20 support built into ROM:

• 512Ke
• Plus
• SE
• Classic
• Classic II
• Portable
• IIci
• IIsi
• LC (but not LC-II or LC-III)

The Mac 512K and 128K can use an HD20 if they boot from another disk that contains Apple’s HD20 Init. That Init may also work for other II-series machines that lack HD20 support in ROM. HD20 Init shipped with very old version of the Macintosh system software, and I’m still looking for a download link for it. Let me know if you’ve got one.

You’ll need to connect the Floppy Emu board to the external floppy port, not the internal one. For the LC, one of the two internal floppy ports is considered “external” – try them both to find which works.

I would also appreciate help testing different sizes of disk images. The HD20 was a 20 MB drive, but its communication protocol can support larger drives. The limit is either 32 MB or 8 GB, but I’m not sure which. Just because the computer boots and says there’s a 1 GB disk doesn’t mean it’s actually working though. It’s necessary to test reading files from all parts of the disk to make sure the full capacity is actually working correctly. The OS itself also imposes a limit of 2 GB for disks.

 
Let’s Do This!

When you program this firmware to your Floppy Emu hardware, it will no longer function as a floppy drive emulator until you program it again with the old firmware. Before you begin, take note of what firmware version you’re currently using. This is displayed on the LCD for a few seconds after a reset – look for a string like “App Version 1.0 Q, CPLD Firmware 13″.

Program the hardware with firmware HD20 0.1A-F64. Edit: see this later post for newer firmware that fixes most of these issues. Instructions for applying the firmware update are included with the download. Note that the update comes in two parts: a new application for the microcontroller, and a new configuration file for the CPLD. You must apply both parts.

To use the emulator, put a file named “HD20.dsk” on your SD card, put the card in the Floppy Emu, and reboot. The disk image file format is the same as the disk images from popular emulators like Mini vMac and Basilisk II, so have fun. If your image file ends with a .dsk or .hfv extension, you can probably just rename it to HD20.dsk with no other changes necessary. If you don’t have an appropriate disk image handy, try this one.

When you’re done playing, reprogram the old firmware. If you were previously using 1.0L-F11 or earlier, restore the hardware to 1.0L-F11. If you were previously using something later than 1.0L-F11, restore the hardware to 1.0Q-F13. If you get messages about “bad fuses” or “wrong CPLD” after restoring the old firmware, don’t panic – it means you’ve programmed the wrong firmware, or only programmed one of its two parts. If you get really stuck, email me.

Both models of Floppy Emu boards are on sale this week, $10 off until December 5. If you’ve been holding off on getting one, now’s your chance! With the new HD20 firmware hopefully finished soon, the Floppy Emu board will be like two devices in one: a floppy disk drive emulator and a hard disk emulator. HD20 mode will require a Macintosh model with support in ROM (512Ke, Plus, SE, Classic, Classic II, Portable, IIci, IIsi, LC-I) or booted from another disk that has Apple’s HD20 Init.

Floppy Emu is a prototype floppy disk drive emulator for vintage Macs. It uses an SD memory card and custom hardware to mimic a 400K, 800K, or 1.4MB 3.5 inch disk drive and floppy disk. It plugs into the Mac’s external or internal floppy connector, and behaves exactly like a real disk drive, requiring no special software on the Mac. Floppy Emu is perfect for setup or troubleshooting of a Mac without a hard drive or a working OS. Just plug in the Floppy Emu, and you’re booting up in seconds. Keep it as a permanent solution, or use System 7 installer disk images to do a new hard drive installation. The hardware is also great for moving files between vintage Macs.

• Compatible with everything from the original Mac 128K through the Mac II and Power Mac series
• Reads and writes emulated 400K, 800K, or 1.4MB disk images
• Supports all major Macintosh disk image types
• External or internal connection to your Mac
• Can be used simultaneously with another floppy drive

I’ve fixed an HD20 emulation bug that caused occasional errors on faster 68020- and 68030-based Macs. The symptom was a “NEG COMMAND SIZE” error message on the LCD screen, and I/O failure. This version also fixes the “BAD FUSES” error that a few people with older boards encountered when running this firmware.

Another note: the firmware requires that the HD20.dsk file on your SD card occupy a contiguous range of sectors. If it doesn’t, you’ll see an “image not contiguous” error on the LCD. The easiest way to ensure all your SD card files are contiguous is to copy them all to your PC, delete everything on the SD card, then copy the files from your PC back to the SD card. You can also use a defragmentation tool on the SD card if you want to get fancy.

• Fixed NEG COMMAND SIZE error that sometimes appeared on faster Macs
• Fixed BAD FUSES error that appeared on older Floppy Emu boards

HD20 Firmware 0.3A-F65

Firmware 0.4 adds support for writing to the emulated HD20 disk drive. No more read-only disks! I’ve tested it with a Mac Plus and a Mac IIsi, copying lots of files about and moving the mouse in crazy circles to exercise the holdoff logic, and it all seems solid.

• Implemented writing to the emulated HD20 disk

HD20 Firmware 0.4A-F66

This marks the completion of the HD20 emulation work, and the latest firmware version is fully usable as a general purpose boot disk or secondary disk. I still need to do some code cleanup and performance optimization, and see how much of the floppy and HD20 emulation code can be merged, but that’s all bonus stuff. Assuming no major problems surface with this HD20 firmware 0.4 in the next couple of days, I’ll promote it to 1.0 status and call it done. Woohoo!

Thank you, Apple, for creating such an oddball hard drive that hijacked the floppy port. HD20 lives!

Ta dah! I thought it couldn’t be done, but I used my hammer and tongs to smash HD20 emulation and floppy emulation into a single firmware version. No more re-flashing the board when you want to switch between emulation types; now you can make your choice from a config menu during start-up. Your default choice is saved in EEPROM, so you only need to access the config menu if you want to choose a different emulation mode than you did last time. Unfortunately this combo firmware was born on the grave of the self-testing logic, which is now gone. That means I can’t use this to replace the regular production firmware. Maybe I’ll look into using JTAG boundary scan for a future firmware update, and re-implement the self-test using that method instead of with CPLD logic.

This firmware is a major change from version 0.4. The code for both floppy and HD20 emulation underwent significant changes, and the CPLD logic was altered substantially too. That means there’s an excellent chance I broke stuff. If you see any strange behavior during floppy or HD20 emulation that wasn’t present with the previous firmware, please let me know.

The scariest and most perplexing issue with this new firmware is that it doesn’t work on my original purple Floppy Emu board, the very first one I ever built back in April 2012. With this firmware, the purple board experiences constant SD card errors, or even spontaneously reboots during disk I/O! The behavior is similar to what I found on the first production boards, before I discovered that they needed more capacitance on the output of their voltage regulators. The purple board lacks that capacitor, and also has a few other small differences from the production boards. So I’d be prepared to believe the problems are all due to the purple board’s hardware, except that it worked fine with every previous firmware version, including Sunday’s version 0.4A-F66. So… yeah. There’s that.

I’ve tested this new firmware in both floppy and HD20 modes, on a Mac 512K, Plus, and IIsi, with one of the current batch of production boards as well as the first (hand-soldered) production board with serial #0001. No problems anywhere.

• Merged the firmware, with a menu-selectable HD20 or floppy mode. Default choice is stored in EEPROM.
• Changed the default HD20 disk icon to a standard Apple hard drive icon.
• LED now blinks during HD20 disk activity.
• Fixed a bunch of little bugs.
• Disabled self-tests.

Combo Firmware 0.5A-F14

Notes on which Macintosh models you’ve confirmed to work with the latest firmware are always welcome.

Firmware 0.6A-F14 now supports formatting the emulated HD20 disk from the Finder. This is handy for creating new hard disk images without the aid of programs like Mini vMac or Basilisk II. Just grab any random file of 100 MB or so (or create a new one using DD under Linux), name it HD20.dsk, and put it on the SD card. If you boot the Mac from another disk, it will see the HD20 disk image, but won’t recognize it as a valid Macintosh disk. The Finder will ask if you want to initialize the disk – answer yes. Be aware that formatting large disk images can take several minutes, during which there’s no on-screen feedback that anything is happening.

While working on this firmware, I encountered more mysterious errors and spontaneous reboots of the sort I described with firmware 0.5A-F14 on my original purple prototype board. But this time it was happening on another board. I rearranged some code, and the problems mysteriously went away, and even the balky purple prototype board started working fine again. I can’t explain what was causing those errors originally though, so maybe I fixed them, or maybe I just papered over them and there’s still a problem lurking somewhere. Please let me know if you experience any of these issues with this firmware 0.6A-F14:

• Emu consistently says there’s no SD card, when there is. Even after reboot, reset, reinsert card.
• Emu in floppy emulation mode says “no image files found”, even though there are disk images on the SD card
• Emu resets to the smiley face screen in the middle of disk I/O, as if you had pressed the reset button

Combo Firmware 0.6A-F14

Once again, if you try this firmware, I would appreciate feedback on what systems you tried it with and what the results were. Thanks!

Firmware 0.7A-F14 improves write performance for HD20 emulation. With the old firmware, if you wrote a 1 MB file to the disk, it would do 2000 separate 512 byte writes to the SD card. SD cards really don’t like this! With the new firmware, the Emu hardware uses an internal 10K RAM buffer, and does 100 separate 10K writes to the SD card. Read behavior is unchanged, so read performance will be the same as before.

Combo Firmware 0.7A-F14

The performance gain vs the old firmware for HD20 writes depends on the model of Macintosh, and the size and type of SD card used. Faster Macs like the IIci will see more benefit than a Mac Plus, since I/O in the faster Macs is less constrained by CPU speed and more directly tied to the actual disk throughput. SD cards with a larger erase page size will also see more benefit from this new firmware. The erase page size is the native block size of the SD card, and typically is something like 4K. When performing a small 512 byte write, the SD card must read an entire 4K block from flash memory into an internal RAM buffer, erase the whole block of flash, update the 512 bytes of the buffer that are being modified, then write the whole 4K buffer back to flash memory. The larger the erase page size, the more inefficient this process is for small writes, and the more this new firmware will help. Unfortunately erase page sizes aren’t normally advertised, but larger SD cards usually have a larger erase page size than smaller cards. For this reason, the best Emu performance in both HD20 and floppy modes will typically be achieved with a small capacity SD card. Use a card of 2 GB or smaller if you can find one.

On a Mac IIsi with an 8 GB SD card, this new firmware provided a 40% improvement in HD20 write speeds in my testing. With a 2 GB card, the improvement was 8%, but it was still faster in absolute terms than the 8 GB card. Interestingly, the 2 GB card with old firmware had the same performance as the 8 GB card with new firmware, so erase page size really matters! On a Mac Plus with the 8 GB card, the new firmware resulted in about a 36% improvement in HD20 write speeds. With the 2 GB card there was no measurable write speed improvement on the Mac Plus. Bottom line: use a small capacity card in combination with this new firmware for the best HD20 write speeds.