A few days ago I received an urgent note from the facility in China where the ADB-USB Wombat Input Converter is manufactured. They’d just finished assembling 250 new Wombats, and all of them were failing the automated functional tests. Was there a systematic assembly flaw in this entire batch of boards? Or was it a problem with the test apparatus?

I developed the Wombat tester (pictured above with a Wombat riding on top) back in 2017. It’s a board with some simple electronics and an array of spring-loaded pogo pins that make contact with a Wombat board placed on top of it. Grab a newly-assembled Wombat, press it down onto the bed of pins, press a button, and in a few seconds you’ll have a functional test result. Hooray for high-speed testing. The Wombat tester that’s used by the Chinese factory is the original one that I hand-built six years ago.

The tester’s schematic is terrible, and I have no one to blame but myself. It looks like a pile of disconnected components where you can’t really make sense of anything. There are only three chips – everything else is connectors or pogo pins. IC1 is a triple 2-channel analog switch, IC2 is a power distribution switch, and IC3 is a simple quad-OR:

I had only two pieces of information:

1. The functional test was failing ADB communication. USB communication was apparently OK.
2. An engineer found that bridging pins 6 and 7 on IC2 allowed the test to finish successfully.

The engineer suspected IC2 had failed and was searching for a replacement. Given the clues and the schematic diagram, what do you think is the most likely cause of the failure?

IC2 pins 6 and 7 are two separate power supplies: one that’s normally supplied by the ADB host, and another that’s supplied by the USB host. Only one should be active at a time, so bridging them together is not a valid test. Because bridging helped the failing ADB test to succeed, it suggested maybe the ADB5V supply was not turning on when it should. Yes, that could be due to IC2 failure, but could also have other causes.

The ADB5V supply is enabled by the control signal /ADB5VON at IC2 pin 3. That signal comes from the quad-OR gate at IC3, so maybe that was the source of failure? The quad-OR is also responsible for generating the USB power supply control signal. Both signals are dependent on three signals named UNK3, /UNK3, and GNDOUT. Because bridging the IC2 supply pins helped somehow, we can probably conclude the USB supply was active, meaning that /VBUSBON had to be asserted. If the quad-OR was working correctly, that means UNK3 and GNDOUT both must have been low.

What’s with these UNK3 and /UNK3 signals? Tracing back further, we see that /UNK3 is generated form IC1, where one channel of the analog switch is rigged up to behave like an inverter. The non-inverted signal UNK3 has a pull-down resistor at R2. Ultimately the UNK3 signal comes from J7 pin 3, which is one of the pogo pins. The signal comes from the Wombat board being tested, via the pogo pin.

Hmm… what would happen if that pogo pin were misaligned or broken? UNK3 would be disconnected and floating, but the R2 pull-down resistor would bring it low. With GNDOUT also low, /VBUSBON would always be asserted and /ADB5VON would never be asserted. The ADB power supply would never turn on, the USB supply would always be on, and the behavior would be consistent with the observed clues.

Mulling this analysis over a cup of coffee, I replied to the factory: “Check if pogo pin 3 at J7 is bent”. Their response came the next day: “Steve, you are really a professional engineer! The guess you made is correct. After trying again, the tester board started working normally.”

Success! That was a very satisfying fix, based on minimal information and without physical access to the faulty circuit.

The BMOW Wombat enables the use of USB mice with ADB computers, such as classic Macintosh and Apple IIgs systems. It’s a great feature, but sometimes the mouse tracking speed appears too fast or too slow for convenient use, even after making adjustments in the host OS’s mouse control panel. Firmware version 0.3.9 introduces a new Wombat feature to help: hardware mouse scaling.

With each long-press of the USB mouse wheel button (longer than half a second), the Wombat increases the mouse tracking hardware scale by a factor of 2. This scale is in addition to any mouse scaling that’s applied in the host OS’s control panel. The available scaling factors are 1/2/4/8/16x. For the Razer Basilisk v2 mouse shown in the video, I found that 8x scaling felt about right, but your tastes may be different.

Firmware 0.3.9 also disables an error-checking feature in the Wombat’s parser for USB HID report descriptors, because some USB devices have a minor error in their report descriptor, including this Basilisk mouse. The descriptor uses a sort of universal grammar for HID devices to describe what they do and what kind of data they can send and receive. The Basilisk has an error in its report descriptor where it specifies a maximum possible value of 572 for a report item that’s only 8 bits in size. The Wombat report parser was seeing this error and rejecting the whole device. Disabling the error check enables the Basilisk to work with no ill effects. This change may also “fix” some other USB mice and keyboards that previously weren’t recognized by the Wombat.

Download the latest Wombat firmware now, and let me know how it works for you.

Firmware version 0.3.8 is now available for the Wombat ADB-to-USB input converter. This version fixes a minor problem with the latching Caps Lock key on ADB keyboards in ADB-to-USB translation mode. If you accidentally bumped the Caps Lock key without depressing it fully, you could sometimes end up with Caps Lock enabled even though the key wasn’t latched down. Firmware 0.3.8 resolves this little annoyance. You can download the latest Wombat firmware from the project home page.

Are you new to the Wombat? It’s a bidirectional ADB-to-USB and USB-to-ADB converter for keyboards and mice. With the Wombat you can connect modern USB keyboards and mice to a vintage computer like an ADB-based Macintosh, Apple IIgs, or NeXT. Or you can do the reverse, and hook up vintage ADB keyboards and mice to a modern USB-based computer running Windows, OSX, or Linux. Want to rock an AEK II on your new M2 MacBook Air? The Wombat is your solution. Get yours now from the BMOW Store.

BMOW’s Internal/External Drive Switcher for Apple IIc is back in stock! Select which 5.25 inch floppy drive should act as bootable Drive 1: the external Floppy Emu disk emulator or the IIc’s internal floppy drive. The Switcher also adds IIc support for Floppy Emu’s new dual external 5.25 inch floppy drive emulation feature.

The Wombat keyboard/mouse converter is also back in stock. Connect modern USB keyboards and mice to a classic ADB-based Macintosh, Apple IIgs, or NeXT. Or connect legacy ADB input hardware to a USB-based computer running Windows, OSX, or Linux.

Both products were delayed by parts availability problems, shipping problems, and COVID lockdowns in China. It’s a difficult time for small-scale manufacturing! Grab your hardware today before these are gone again.

The Wombat ADB-USB input converter is now back in stock at the BMOW Store. Thanks for everybody’s patience during the manufacturing delay.

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

No special software or drivers are needed – just plug it in and go.

The Wombat was developed by Steve Chamberlin here at Big Mess o’ Wires, and it’s great for breathing new life into your vintage Apple hardware collection.

For more details, please see the product description page.

Firmware version 0.3.7 is now available for the Wombat ADB-to-USB input converter. This version fixes a compatibility problem with some ADB mice that use non-standard communication timing. You can download the new firmware here.

This was an interesting discovery. Apple only ever produced a few different ADB mice, with model numbers A9M0331, M2706, and G5431. You might think that mice with the same model number would be the same, but in fact there are several different versions of each model and they have very different internal parts. It may be possible to tell them apart by checking the country of manufacture printed on the mouse, which could be USA, China, Malaysia, Taiwan, or others.

Some of the “Made in Taiwan” ADB mice have a controller chip inside that’s made by Logitech rather than Apple. These mice communicate over ADB at 75 microseconds per bit, instead of at the normal rate of 100 microseconds per bit. A small change to the Wombat firmware was required to make it more flexible about the bit timing.

 
PICkit 3 R.I.P.

The Wombat is designed around a Microchip PIC32 microcontroller, and I use a Microchip PICkit 3 to program and debug. Somewhere within the last year or so, the PICkit 3 has basically stopped working. It gives every indication of being some kind of Windows 10 problem or USB driver issue, rather than a hardware problem with the PICkit 3. Searching the web turns up many similar complaints, but no solution.

Using Microchip’s MPLAB X IDE for development and debugging, the PICkit 3 doesn’t work at all. The IDE will detect that it’s there, but any attempt to actually use it just gets a “connection failed” error. This means that I can’t use the debugger, and I’m reduced to debugging using print statements over the serial port.

The PICkit 3 sort-of works with the MPLAB IPE, a stand-alone programming tool with no debugging capabilities. But it only works for a short window of time after rebooting my computer. After a few programming cycles, it falls back to the same “connection failed” behavior as the IDE. The only way I’ve found to fix it is to reboot… again. Unplugging and replugging the PICkit3 doesn’t help, nor does updating the PICkit 3’s firmware, restarting MPLAB, or anything else I can think of. The word from Microchip’s own support is basically “Oh, you bought one of THOSE? Ha ha ha. Yeah, those PICkit 3s don’t work very well and we’ve dropped support for them.”

After spending quite a long time trying to resolve this, I eventually gave up, and decided I won’t be using any PIC parts for any future projects. The tools are just too clunky and buggy, and there doesn’t seem to be nearly as large of a community using PIC32 parts as other options like STM32. That means that when something’s not working, there aren’t many people who can offer help, and you’re basically out of luck. Too bad.