USB to ADB Napkin Design
I’ve finished my rough-and-ready “napkin” design for a USB to ADB converter, building off the ideas discussed in my previous post. This device will enable modern USB-based keyboards and mice to be used with vintage ADB-based Apple IIgs and Macintosh computers. I’ll be designing this for low cost, and offering it for sale in the BMOW store when it’s done.
The design doesn’t need much more than a microcontroller and some clever software, along with the necessary USB and ADB connectors. After looking at several options, I think the best microcontroller for this project is the PIC32MX2xx series. These have hardware support for USB Host functions, are well-documented with lots of examples, and are cheap. I’ve never worked with a PIC before, but that’s OK.
ADB Protocol
The ADB protocol is described in detail in the Apple Guide to the Macintosh Family Hardware. It’s a 1-wire open collector bus protocol without an explicit clock. Each bit is 100 microseconds wide, with a 0 bit being 65 us low and 35 us high, and a 1 bit being 35 us low and 65 us high. Unfortunately it’s not a good match for any of the microcontroller’s standard SPI, I2C, or UART modules, so it will need to be bit-banged through software. Documentation is not great, but there are enough examples of other ADB projects that I’m confident I can get this working.
USB Hubs
The PIC32MX2xx, like almost all other microcontrollers with USB Host functions, has only a single USB interface. To connect a USB keyboard and mouse at the same time, then, I’ll need a USB hub. Early versions of Microchip’s USB framework for PICs didn’t support hubs, but fortunately hub support was added sometime around 2014.
My first thought was to build a hub directly into this device. I might use a separate 2-port hub chip like Microchip’s USB2412, along with the required crystal oscillator for the chip and other support components, and a 2-port USB type A connector. But then I looked at how cheaply you can get a stand-alone 2-port or 4-port USB hub, when buying in wholesale directly from Asia. It’s far cheaper than the cost for me to integrate equivalent functionality into my device! So I’ll probably design the device with a single USB type A connector, and package it bundled with a basic USB hub.
Power Supply
The device will be powered directly from the ADB bus. Apple’s spec allows for 500 mA current draw at 5V from ADB, which should be plenty for the device itself plus an attached keyboard and mouse. Powerbooks reduce this limit to 200 mA, which might be a problem. Two possible solutions:
- State that Powerbooks are not supported by this device (or are not guaranteed to work).
- Add a power jack for an optional external 5V supply.
I’d prefer to avoid an external power supply, even as an optional item. It just feels clunky, and even an optional jack will add to the cost and complexity. Some method of switch-over would be needed, to avoid back-feeding current from an external supply into the Mac’s +5V ADB line.
ADB Pass-Through
Some ADB-based computers have two ADB ports, and some only have one. Is there a need for an ADB pass-through on this device? Without one, it will be impossible for a computer with a single ADB port to use this USB-to-ADB device and another ADB device at the same time, without resorting to a 3rd-party ADB-splitter. But my guess is that would be a rare need, and an ADB pass-through connector would go unused 99% of the time. It’s probably better to keep things simple and omit it.
Power Button
Standard ADB keyboards have a power/reset button, which is the normal way to turn on most Macintosh models. This is the only ADB feature I can’t see a good way to replicate using USB input devices. In an ADB keyboard, the power button is a physical switch that grounds a pin in the Mac’s startup circuit, activating its power supply. Before the switch is closed, the keyboard and computer are truly off, and there is no source of power available to ADB devices.
Without power, my USB-to-ADB device and any attached keyboards and mice will be fully turned off. That means there’s no way a magic key combination on the USB keyboard can be used to power on the Mac.
I can add a physical power button to the USB-to-ADB device itself, and that will work, but it’s not ideal. Were it not for this, the device could be shoved behind your monitor, out of sight. Using it for the “on” button requires it to be in your workspace and accessible. An external power supply (or batteries) could provide another solution, keeping the device and USB peripherals always on even when the computer is off, but I’d prefer not to go down that route.
Time to buy a PIC experimenter board and some ADB (aka S-Video) connectors, and start hacking!
Read 23 comments and join the conversation23 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
USB devices can support remote wake-up, where the device can wake up the host (e.g. on keypress). Perhaps in suspended state the entire converter + keyboard circuit could be powered by a supercap, if not a battery.
Most of the legacy ADB-to-PS/2 adapters out there (mostly for KVM switch integration) had the power button on a separate little box. See http://cache-www.belkin.com/support/dl/f1d080.pdf
Also take a look here for some protocol info: https://github.com/tmk/tmk_core/blob/master/protocol/adb.c#L301-L478
@Chris M, that Belkin doc shows the power button as being on the device itself, if I’m not mistaken. So it’s basically the same thing I was proposing:
“Position the Adapter so that it is conveniently accessible. This is necessary because the POWER button on the Adapter performs the function of the Power button on the Macintosh keyboard. You may want to situate the Adapter so that the POWER button is facing you.”
Correct, although I’m curious whether or not the power button on the Belkin also sends the Power Button’s scan code or if it just grounded pin 2. It would make for an interesting 3-finger salute to soft reset a machine.
Having a connector (2 pin JST, or a 3.5mm jack even?) for an external power button would solve the problem at minimal cost :v
Consider using SPI if you can make everything fit in triple-wide back-to-back transfers with DMA. The timing would be tweaked a tiny bit (33.3 / 66.6) but you could in theory use 3 bits of an SPI transmission to represent 1 bit of the ADB bus. Some of the faster WS2812 LED libs use the technique (expanding every 4-bit nybble to 12-bit spi transfers, allowing a 16-entry lookup table to generate the SPI data quickly)
@Andrew – I’d been trying to avoid that, but maybe it’s OK. I may also want to include a USB mini-B jack, so the device could be connected to a Windows/OSX computer for firmware updates. That could do double duty as an external power connector.
@David – Good thought. I had considered using SPI to do the ADB communication, and for sending ADB data I think what you proposed would work, if combined with an external open collector buffer. But I’m not sure how it would work for receiving ADB data, since there is no clock signal in the ADB communication, but SPI requires one.
Hi. Speaking as a potential user… AFAIK, ADB keyboards have two ADB ports for daisy-chaining. I’d see myself continuing to use the ADB keyboard, and attaching the convertor after the keyboard to use an optical mouse. So the keyboard power switch is still functional, and no need for USB hub capability. (Or am I wrong in thinking that?)
ADB keyboard with pass-through and a USB mouse should work fine, and the power button on the keyboard would also work. I expect most people will want both a USB keyboard and USB mouse, though – at least that’s how I’d use it. So that will require a hub for connecting two USB devices.
Steve, I’m not a Apple user myself, but I’m a hardware tinkerer. That’s why I’ve been following your site.
Regarding the ADB emulation of keyboards and mice: I looked at your proposed board, and I’m sure you can make it work (I’ve looked at some of the other stuff you’ve done), but have you considered starting with a raspberry pi? The board cost isn’t *that* much more for all the flexibility you gain. I read that your proposed board has ADB emulation documented, but then you get all the headaches of handling the USB hub programming, etc. the Pi comes with multiple USB ports, and the interfaces already written for them. The hard part with the Pi is that you’ll have to handle the ADB side. The Pis have I/O pins, so the most you’ll have to handle on the hardware side is interfacing it to the Apple bus.
I don’t have any real experience with the Pi yet or I’d offer to help with the interface.
I’ve just been looking at the various options out there right now, and the Pi seems to have one of the most robust support organizations out there.
But of course, if you have experience with another platform, that trumps just about everything else. Use what you know.
Just a thought.
Well, I just looked at the Pis, and it looks like the minimum unit with more that one USB port is almost $40. That will probably put out of the price point you’re looking for. Crap. Sorry for the noise….
You raise a good point, and I’m sure this could be done with a Raspberry Pi. I have a couple of them already, and while they’re neat, I’m a little bit biased against them. They’re basically general purpose computers, not embedded platforms, and for me they’re not as interesting as more bare-metal type microcontroller work and custom circuits. For all its headaches, I still enjoy the nuts and bolts of low-level electronics work much more than something like Python scripting on an RPi. But there’s no doubt they’re very convenient for many uses.
The Microchip PIC32 eval board I purchased isn’t meant to be the final hardware for this project – it’s just a convenient platform for experimenting and prototyping work involving a PIC. Once I have the details ironed out, I plan to design a custom board that contains only the micro and the other components needed for this specific purpose.
> I’ll probably design the device with a single USB type A connector, and package it bundled with a basic USB hub.
> It just feels clunky, and even an optional jack will add to the cost and complexity.
Doesn’t this seem a little inconsistent to you? A USB hub IC (e.g. TUSB2036) is ~$2 at 100s. You should be able to get a dual USB-A connector for about $0.50 at 100s. The remainder that’s actually required say maybe $0.25. Add another $1 for a power switch to do things properly. Under $5 on the BOM to make the product a lot nicer to use and less clunky. Packaging a cheap-ass import hub (have you considered QC costs…) is much uglier to me than having an optional external power supply.
To accomplish an optional external power supply, you can use something like the TPS2115. It’s about $1. You could make it optional, with the benefit of having it allowing you to power up the Apple from the keyboard/mouse. Keep the power button on the box, but if there’s external power, put the USB peripherals into standby and wait for their wakeup notification to trigger the Apple to turn on.
Let me put in a vote for having the “power button” button recreated somewhere and somehow. Assuming this will work with an Apple IIgs, the “power” button acts as a reboot – Ctrl+Apple+Reset. Pretty sure it works the same way if you’re running an LC machine with the IIe emulation card.
That said, I gather there may be a little variation in the early ADB implementations. When using a Mac LC with the Belkin adapter, I ran into a problem where connecting both the keyboard and mouse would cause the mouse movement to just be really erratic and totally unusable. Just keyboard or just mouse work fine. I ended up daisy chaining two Belkin units, one for the keyboard and one for the mouse, and it works great. Haven’t looked real hard, but some quick searching didn’t reveal much of anything about the differences, etc. If you don’t have an LC or IIgs or such, I would be happy to help test when the time comes.
And lastly – would there be any easy way to make this setup work with PS/2 keyboards and mice? Only reason I ask is I’m using an older non-USB keyboard along with a PS/2 KVM. But…I may be the only person who would want such a feature…
Lots of interesting ideas! I agree a built-in hub functionality would be nicer than an external hub, all other things being equal, though the idea of using an external hub doesn’t offend me if it brings cost and complexity savings. Thanks for the pointer to the TPS2115, that’s a very interesting chip! As for PS/2 support, it’s certainly possible, and would be easier in some ways. But since PS/2 itself is nearly as dead as ADB, I’m focusing on USB to ADB.
toru173 made a couple of interesting suggestions in the comments of the older post, which I’ll respond to here.
1. Use two separate MCUs, one for the keyboard and one for the mouse, to avoid the need for a hub. This is so crazy it just might work. Cost-wise it would be about the same as using a separate hub chip, I think. It would add complexity in some areas (firmware updates need to update two MCUs) but remove it in others (no need for firmware hub support).
2. Handle firmware updates in USB Host mode by loading a file from a thumbdrive, instead of needing to include USB Device functionality and pushing the firmware update from a Windows/OSX/Linux computer. This is a great idea! It would enable the device to be USB Host only, instead of a dual-mode device.
“1. Use two separate MCUs, one for the keyboard and one for the mouse, to avoid the need for a hub”
Steve, I don’t have a lot of experience with PICs myself yet, but I think this is a brilliant thought. My original idea of a Pi was due to the additional code you’ll need to handle the hub, and all of the configurations it’ll cause. This eliminates all of that. If I was doing what you’re planning on doing, I would definitely go this route (and in future projects of mine, I’m going to steal this idea. Thanks toru173).
Hi all,
Spitballing ideas continues. I would imagine each MCU would have the same firmware, and have two possible methods of updating the firmware. Option one is as I suggested earlier – from a USB drive. Option two would be when the MCU detects a reset of the ADB bus. I’m remembering vaguely, but I seem to recall the ADB bus would respond to a reset with all devices waiting until their was no bus contention, requesting a (random) device ID, then being allocated a (higher, but still random) device ID. During ADB reset, the MCU with the thumbdrive could hold the other MCU in reset or device firmware update mode, update it’s own firmware then update the firmware of the other device via SPI or similar.
It would mean more complicated firmware and more than 4 GPIO pins used per MCU, but back of the envelope thinking would indicate an extra 5 pins is doable on the chips you’ve selected and a single code base would be easier to maintain rather than a ‘master’ and ‘slave’ MCU firmware. This would also mean the user doesn’t have to plug mouse, keyboard, upgrade USB stick etc into a specific USB port
Thinking ahead of myself. I assumed the MCU would trigger an ADB reset after upgrading firmware, so chose that as a way to trigger an update in other attached MCUs.
Would running two MCUs vs. one be a problem with the available power on the ADB port?
Not sure how doable it would be, but you might have enough room in the PIC32 to have the bootloader check for usb mass storage devices, and if present compare the firmware in flash to what is on the usb, and update the flash if it doesn’t match. If one firmware contains all the logic for both micro controllers, it is as simple as loading the file on a thumb drive, inserting it in one slot, power up the adapter with external brick / usb-to-barrel cable wait for flashing leds to stop flashing, repeat with the other usb port. http://ww1.microchip.com/downloads/en/AppNotes/01388B.pdf has info on designing bootloaders for the PIC32 series. At powerup you could enumerate the USB and see if it is Keyboard / Mouse / MSD / Gameport and boot the appropriate firmware or routines.
One (hopefully minor) request: broad support for HID devices, specifically USB game controllers, with the idea that this breakout box can emulate the Gravis line of ADB gamepads and gamepad adapters that had fairly common support in the 90s. This is essentially the one thing in my way of playing classic Mac games, on original hardware, from my couch.
What about wireless USB keyboard combos (the once with a single RF transceiver for kbd/mouse)… those tend to show up as a composite device I think.
Have you succeeded in making this USB to ADB converter? Does it work with keyboard only? my email is vmelkon m yahoo come on down.