ADB Busboy: Adapter for USB peripherals over ADB

[Huxley]

I've put a considerable amount of dumpster-diving effort and money into securing a lifetime supply of Apple Extended Keyboard II's - to me, the AEKII is the best keyboard ever made. That being said, having the option to use more modern USB input devices with all my retro ADB-equipped gear would be a fun and unexpected option - I'm definitely down to buy one of your adapters when it's ready!

 

[lameboyadvance]

I only just came across your project and this is something I've been wanting for a while. There are a few projects for the opposite sort of adapter but few that turn a USB keyboard into an ADB one.

Firstly, can your adapter handle 'combo' keyboard & mouse/trackpad style models? That's the type I would likely want to use (something small and combined to easily test my Macs with).

Secondly, I might be a bit late in replying if you've already designed the PCB, but would it be possible to have a USB keyboard with a media 'Power' key trigger the ADB power button instead of having to physically press that button on the PCB? Quite a few keyboards have that key (as well as the USB Mac models).
 
Finally, I would love to have a way to at least use some media key functionality under early MacOS. The Apple Adjustable Keyboard had 'Volume Up', 'Volume Down', 'Mute' and a 'Mic' button which doesn't really have a modern equivalent and could possibly be mapped to Play/Home/Browser/whatever.
TMK has documented these multimedia keycodes now. You do have to broadcast a second device address (0x07). If you could have a mode that advertises the keyboard as an Adjustable then it would at least allow you to have keyboard volume control under OS7. (EDIT: Found a report that says the media keys work on 6.0.7 or later)

 

[Scott Squires]

Yes, ADB Busboy will work with combo devices that have both keyboard and pointing functionality.

I probably won't have the media key functionality done in the v1.0 firmware, but it is one of the first things I would add as a firmware update. The firmware can be upgraded, so one can get new features as I add them.

It won't be possible to turn power on from the keyboard. In order to do that, the keyboard has to be powered on (at least in suspend mode). Since ADB Busboy is powered by the ADB bus, it can't power the keyboard while the computer is turned off. I looked into having a battery that powers the keyboard in suspend mode while the computer is powered off, but the battery would last less than a month. The other option would be for the ADB Busboy to be powered externally instead of (or as well as) over the bus. This required too many additional components and cost. That button you see on the PCB render next to the ADB port is the power button. Instead of pressing the keyboard power button, you'll have to press the button on the ADB Busboy.

Thanks for the feedback, lameboyadvance and Huxley.

 

[ArmorAlley]

Hi Anthon,

 Would it be realistic and viable to fit one of the PRAM battery holders onto the board? These batteries last a very long time and we should all be able to supply our own.

I know (for me), being able to turn the computer on by being able to press the power-key is one of the reasons that I love ADB. Indeed, Macally has a keyboard (iMediaKey) that allows it over USB.

 

[Scott Squires]

The PRAM batteries have a smaller capacity than the ones I was considering. They only last a long time because the clock circuit uses a very very very small amount of energy. The runtime for those batteries powering a usb keyboard in standby would be less than three weeks.

 

[mactjaap]

Great project! Will definitely buy one! Isn't it nice to make

It a Kickstarter project? Then you have a good view on how many people will "back" you!

 

[lameboyadvance]

It was my understanding that the ADB port provides 5V 'standby' on models that allow soft power. Would this voltage be enough to power your device/the attached input devices?

 

[blitter]

I'm definitely in for one of these when they're ready to ship.

Does your firmware use the USB HID spec to detect attached USB devices, and if so, which HID classes is it designed to detect? I would *love* if support existed for game controllers, and then mapped gamepad inputs to Gravis GamePad and/or Mousestick values on the Mac side. I have a Mac II and a beige Power Mac G3 hooked up to my entertainment center for gaming purposes and it would be awesome if I could use something modern like an Xbox 360 controller to play classic Mac games that have Gravis controller sets.

If this isn't on your radar, will the firmware be open-sourced in case I'd like to try my hand at adding support myself?

 

[Scott Squires]

ADB does not provide "standby" power on any computer that I am aware of. If you know of a specific model that supports that, let me know and I'll be happy to investigate. However, I really do not think such a thing exists.

 

[Scott Squires]

I had not planned on using kickstarter for this project. Managing a kickstarter campaign is a headache. Dealing with fulfilling pre-orders (such as kickstarter) is a headache, due to product changes between payment and fulfillment, from people changing addresses, etc. There's also the 5% fee on top. And people being disappointed when a project runs late, and they have already paid for it. So, my current plan is not to take orders until I have product to ship.

I might use kickstarter for another project in the future that is more capital intensive.

 

[ArmorAlley]

It was my understanding that the ADB port provides 5V 'standby' on models that allow soft power. Would this voltage be enough to power your device/the attached input devices?

This is from Wikipedia (https://en.wikipedia.org/wiki/Apple_Desktop_Bus):

ADB's protocol required only a single pin for data, labeled ADB. Two of the other pins were used for +5 V power supply and ground. The +5 V pin guaranteed at least 500 mA, and required devices to use only 100 mA each. ADB also included the PSW pin which was attached directly to the power supply of the host computer. This was included to allow a key on the keyboard to start up the machine without needing the ADB software to interpret the signal. In more modern designs an auxiliary microcontroller is always kept running, so it is economical to use a power-up command over the standard USB channel.

The standby power comes from the power supply of the host computer (I had thought that it came from the PRAM battery) although I am open to being corrrected.

 

[lameboyadvance]

Exactly. I knew the soft power Macs connect the PSW pin to another pin (but couldn't remember if it shorted to 5V or ground) so the Mac knows when to turn on. Keyboard power buttons do 2 things, send the ADB power keycode, but also make a physical connection to PSW for when the Mac is off.

 

[Scott Squires]

Yes, that is how the ADB Busboy power button works. Just to be clear: none of those facts make it possible to turn the Mac on from a USB keyboard attached to the ADB Busboy.

 

[Scott Squires]

Currently the firmware supports keyboard and mouse HID classes. I definitely want to support game controllers. I would implement this sometime after I implement media keys. I don't currently understand how game controllers work on the ADB side. I'm guessing they need a system extension. Do games have to be designed to work with them? Or do they map controller inputs to keyboard/mouse events? Or something else?
 
I'm glad you mentioned some ADB gamepads, I suppose I should acquire some for testing.
 
As for open source, I'm not going to release the source code right away. I haven't really decided how to handle it. And since I can't change my mind after open sourcing it, I'm postponing that decision for now. I might release it under a non-commercial only license like Steve Chamberlin does with the Floppy Emu. If I am unable to dedicate time to developing it for a significant period of time, I'll definitely open source it (in the OSI, free as in freedom sense).

 

[Scott Squires]

OK, I found this video about the Gravis Gamepad. http://www.killgruz.com/?p=928

Looks like the software maps buttons from the gamepad to keyboard and mouse events. What different companies made ADB game controllers? Which one had the best software? Gravis? I think I would just make the ADB Busboy convert the USB controller to a Gravis or whatever. Of course, the ADB Busboy would need to know how to map the buttons on the USB controller to buttons on the pretend ADB controller. Hmmm...

 

[Scott Squires]

Also, is the software different for different types of Gravis controllers? ADB Busboy could theoretically emulate all the ADB game controllers. In that case there need to be a way to select which controller to emulate. But would it be satisfactory to choose the best controller with the best software and go with that? The only reason I can think of not to do that is if one controller has the better software but another controller has a lot more buttons.

 

[blitter]

I don't know how which or how many companies made ADB gamepads, but Gravis was kind of the de facto standard-- many games shipped with Gravis "sets" that were preconfigured mappings of their gamepad buttons to in-game keys. As I recall, the Gravis GamePad shipped with a control panel that you'd use to configure its mappings, but I'm not positive if that control panel was necessary for operation-- it may have just sent scancodes regardless, I'm not sure. It's been a while and I don't have mine handy.

 

[blitter]

The only other standard system used by game controllers that I know of is InputSprocket, but that came later on the Power Mac line and support there is less important given that a USB controller could be configured via InputSprocket.

 

[blitter]

Come to think of it, I don't know how or if InputSprocket detected and worked with ADB controllers, as I've only ever used it with USB. It predates the introduction of the first iMac, so I imagine it has to work with ADB devices, but I've never tried it.

 

[lameboyadvance]

...Another thing, are you planning on handling >1 mouse button? Some ADB mice actually had a second button, but they are a rarity and the most common method of a 'right click' on a Mac was ctrl+click. Simulating that shouldn't be impossible. Also, what about implementing what at least one Mac emulator does and make the mousewheel scrollup/down translate to 2/3 keyboard arrow up/downs to allow you to 'scroll' Finder windows?