Fresh from the Factory
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.
Read 6 comments and join the conversation6 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
Just wondering about the compatibility of these, would they work with 400K floppies, i.e would be nice to use this with a Lisa. 🙂
400K floppies, yes; Lisa, no. See the main page Floppy Emu page for more compatibility information.
From what I see you’d just need to enable tags. You could write these to a different file perhaps, or build a writeable DiskCopy format, which is very easy to do if you just ignore the checksums.
Yes, I think you’re right. I’m not 100% certain the Lisa floppy port is identical to the classic Mac’s though. Assuming it is, then a read-only Lisa support should theoretically be do-able. Write support would be harder, since it would need to do two SD card block writes for every floppy image sector write, instead of one. If I had a Lisa to experiment with, I might be able to get that to work, but it’s not clear the hardware would be fast enough to keep up.
Well, I’ve got two Lisas, and you’ve got the floppy emu, if you have some way to remotely debug the code, and point me at how to upload new firmware to it, I can certainly test it for you.
I also have a DiskCopy 4.2 C library that you could use to enable writes to DiskCopy 4.2 media if you’d like. The problem is that the header makes the blocks get offset on non 512 byte boundaries, so you’d be reading/writing to/from two blocks either way, plus one more for the tags.
The library does fix the checksums when you close the image. It has an interface similar to fopen/fclose, fread/fwrite.
I wonder if your timings are so tight that even a slight variation of propagation delay from chip-to-chip causes problems with some?