Today I received a new batch of Wombat boards from my manufacturing partner. Too bad none of them work! Connected devices aren’t recognized, in either ADB or USB input modes. Oops.

After some lengthy investigation, I discovered that the main crystal oscillator speed on these new boards is about 3.69 MHz, but it should be 8.0 MHz. At 3.69 MHz the board will not work. But the oscillator seems to be an 8 MHz one (at least it has “8.0” in the part number stamped on it), and the associated capacitors and resistors measure roughly the same in-circuit values as a known-good board, so it’s unclear why I’m getting 3.69 MHz oscillation.

Problems happen, but this particular problem should have been caught by the testing procedure that I designed, before the boards were ever shipped to me. I re-ran the test procedure here, using a copy of the test harness that I previously gave to the manufacturer, and sure enough all five of the boards I tried failed the test. So either there’s some discrepancy between how I’m testing and how they’re testing, or they did the tests incorrectly, or didn’t run the tests at all.

The hardware and the test process are identical to the previous three Wombat batches made by the same manufacturer, but the person overseeing the project changed this time.

This is my nightmare scenario, and I’m not sure where to go from here. With some more bench time, I could probably determine exactly why the oscillation speed is 3.69 MHz. Perhaps these boards could be fixed with some hot air rework and component replacement, but who’s going to do that? I’m not about to desolder and replace crystal oscillators on hundreds of boards by hand, to fix someone else’s mistake. Returning the whole batch for rework in China would be prohibitively expensive in shipping and tariff costs. Even if the manufacturer agrees to stump for a complete re-do of the manufacturing, I’ll still be out roughly $750 for the cost of ICs I purchased and provided to them.

I’m forecasting an extended out-of-stock period this summer for the Wombat ADB-USB Keybord/Mouse Converter. One of the Wombat’s parts is currently out of stock everywhere, and the manufacturer is advertising 16 weeks lead time for delivery of more parts. There are still enough Wombats on hand to cover a few more weeks of typical sales volume, but then it will probably be October before more are available. If you’ve been considering getting a Wombat, you should order it now or be prepared to wait until autumn.

The Wombat is a bidirectional ADB-to-USB and USB-to-ADB converter for keyboards and mice.

• Connect modern USB keyboards and mice to a classic ADB-based Macintosh, Apple IIgs, or NeXT
• Connect legacy ADB input hardware to a USB-based computer running Windows, OSX, or Linux

No special software or drivers are needed – just plug it in and go. Now you can finally use a modern optical mouse with your vintage Macintosh, or amuse your coworkers with a retro ADB keyboard on your work machine. ADB-USB Wombat is an indispensable tool for Apple collectors and enthusiasts.

The Wombat ADB-USB input converter is now back in stock at the BMOW Store. All pending Wombat back-orders will be shipped during the next few days.

What’s a Wombat? The Wombat is a bidirectional ADB-to-USB and USB-to-ADB converter for keyboards and mice, and was developed by Steve Chamberlin here at Big Mess o’ Wires. For more details, please see the product description page.

Version 0.3.1 firmware for the ADB-USB Wombat is now available. The Wombat is a bidirectional ADB-to-USB and USB-to-ADB converter for keyboards and mice. It enables the use of modern USB peripherals on vintage ADB-based Apple or NeXT computers, or ADB peripherals on modern machines equipped with USB. The Wombat is great for breathing new life into your vintage hardware collection.

Firmware 0.3.1 fixes a small but important bug that affected a small number of USB-equipped Macs that were built between 1998-2003, including some G3/G4 models of iMac, iBook, Powerbook, and Power Macintosh. ADB-to-USB conversion worked normally on these computers when running OS X, but they were unable to detect the keyboard when running MacOS 9. The reverse USB-to-ADB keyboard conversion worked normally under both MacOS 9 and OS X. If you weren’t affected by this bug, there’s no need to update your Wombat and you can safely stay with firmware version 0.3.0.

Here’s an exciting new feature for the ADB-USB Wombat input adapter: custom key mappings.
With firmware version 0.3.0 or later, you can replace the built-in mappings between USB and ADB scan codes, and create your own customized key mapping tables. Change which keys behave as Command and Option, reassign the function keys to new purposes, select a different key to behave as ADB power/wake-up, and design other custom key mappings. Go crazy!

The code framework to support custom mappings has been in place for a while, and it’s little more than a lookup table of USB to ADB scan code equivalents, and a complementary table of ADB to USB equivalents. There are two separate tables, instead of a single bidirectional table, because there’s not always a one-to-one mapping between USB and ADB scan codes (in mathematical terms it’s not a bijection). Use a custom lookup table, and you’ll get custom key assignments.

The harder part was designing a user-friendly interface for viewing and editing the tables. It would be awkward and error-prone to expect people to manually fill in a few hundred numbers in a hex editor. After considering various cross-platform frameworks like Qt, I decided to implement the keymap editor as a web page. All of the logic is implemented in Javascript, so you can see how it works by viewing the page source. I’m not the world’s greatest UI designer, so if you’re a web UI specialist and want to contribute some interface improvements, they would be very welcome.

Because the control, shift, and capslock keys are used to access the Wombat’s help commands, those keys shouldn’t be remapped. A few other mapping details are called out in the editor for ISO keyboards and certain ADB keyboards.

Installing the custom key mappings to your Wombat board is very similar to installing new firmware. Copy a file to a USB flash drive, put the flash drive in the Wombat’s USB port, and hold the board’s power key button while it powers on. Complete instructions are on the keymap editor page. If you accidentally mess up the key mappings so badly that you can’t recover, the keymap editor can also be used to download and reinstall the default keymap.

Here’s a test rig for the ADB-USB Wombat board: my first-ever project whose sole purpose is to facilitate testing of another project. It uses spring-loaded pogo pins to create a bed of nails that fit into test points on the Wombat board. I can drop a new Wombat board onto the tester, clamp it in, and then program and test it with just a few button clicks. This is a huge improvement over my old manual testing method, which involved multiple cable connections and disconnections, and hand-verified keyboard/mouse emulation on two separate computers. That sort of test process is fine for building a few units, but something faster and easier is needed to support higher volume assembly.

Pogo pins contain tiny internal springs. When a Wombat board is pushed down onto the bed of pins, they compress a few millimeters in length. This helps to create a reliable electrical contact for each pin, even if the uncompressed lengths of the pogo pins are slightly different or they’re not perfectly aligned.

The tester has on-board ICs to open and close external loopbacks for the Wombat, so the I/O functions can be verified. It also has a power management IC that can supply the Wombat through two different interfaces, ensuring they both work. But the real value of the tester is that the power cable, PIC programmer, serial cable, ADB peripherals, and USB peripherals can all be permanently connected to the test board instead of plugged/unplugged from the Wombat for each test iteration.

Perfecting the tester took much longer than I’d expected, and it wasn’t until the third generation that it worked reliably enough to be useful. Given the size of that time investment, it’s unclear if I really achieved a net time savings, but I definitely learned a lot. Getting the mechanical aspects working smoothly was a challenge. Thinking about all the ways a Wombat could be broken was also a challenge, since I’m typically thinking about how things work instead of how they don’t work. With those possible failure modes in mind, I then needed to design circuitry to detect each failures.

If the test passes, the Wombat’s LEDs blink with a pulsing glow as shown in the video. If the test fails, the LEDs flash a variable number of times to indicate a two digit failure code. This code can be looked up on a reference sheet to see which sub-test failed, and which components are probably at fault.