I've been living on the adapter using an imate to connect it to my work system with USB, for the past couple days. I've also used it with a 9600.
I've ironed out a few bugs, and have the power button working using shift-esc as the power button for usb keyboards. It seems pretty usable to me, using it for my daily work on a modern system, and using it with macssh/screen/vi/irssi on the 9600.
If anyone wants one, let me know. I've got 8 or 9 PCBs left.
Ok. I'll see if anyone else wants one, and then place an order for several processor boards so I can send complete units already programmed, and save on shipping by ordering multiple at once.
It'll need a usb cable for power and whatever cable you will use to connect to the mac. The DB9 can just use a straight through serial cable for pre-ADB mouse. The rj11 is wired for straight through, which is what the original keyboard is wired for. Telephone handset cables are rolled, and that'd be bad (crosses 5V and ground). Or just regular old ADB.
Wiring up 5V power would be easy enough, but the documented power budgets of both pre-adb and adb are significantly less than the required power draw of ps2 peripherals, I've found. The pre-ADB macs document a total 5V power draw by all peripherals as 200mA. ADB power supply varies by machine. Most desktop machines can supply a total of 500mA to all ADB devices combined, with individual devices limited to 100mA each, and powerbooks are documented at total supply of 200mA or less. I have noticed that the 200mA ADB supply is a bit conservative on powerbooks, but still something to be concerned about.
PS2 is rated at 275mA for each port, so would theoretically need 550mA. In practice, it's less than that, but...
My generic DEC PS2 keyboard is rated to draw 200mA on its own, and my MS Intellimouse is rated to draw 100mA. That's probably ok on a desktop machine, but I'd be a bit concerned on a powerbook, and wouldn't want to even try it on a pre-ADB compact.
I've ordered some of the stm32f0discovery boards. I'll assemble some adapter boards, program the stm32f0's when they arrive, and then will be ready to go.
FWIW, the firmware now works with NetBSD's ADB implementation, and seems to work with the IIgs ROM1.
I've addressed a key repeat issue with the ADB side, which ended up not being a key repeat issue at all. The ADB keyboard register 0 is used to convey keystroke information. Register 0 is 16bits wide, which conveys 2 key events at a time. If there's only 1 key event, I was padding the other byte with 0x7F. MacOS interpreted this as a keydown event, but for an unknown/unmapped key, which broke the OS support for autorepeat of the 1st key. Just changing to using 0xFF for padding fixed this. Throwing the logic analyzer on the Apple Standard Keyboard showed that's what the Apple keyboard uses.
The only other known remaining issues are:
1) collision detection. I don't think I'm going to fix this unless someone has a real world problem with it. I also suspect this will require a PCB spin to fix. To detect collisions, I think I need 2 pins connected to the data line. One that is always an input, and the other used to drive the bus. Then use the always-input pin to read while the other is driving, and make sure the data line is what we're expecting. Trying to swap the single driver pin from output to input, read, then go back to driving the bus seems too sketchy to bother with.
2) LEDs. The current behavior is the adapter drives the PS2 keyboard's LED. So when the adapter sees the capslock keydown/keyup, it keeps track of the capslock key state internally and then sends PS2 commands to the keyboard to turn the LED on & off. I originally implemented this behavior when the adapter was pre-ADB only, since pre-ADB keyboards have no LEDs and the protocol has no notion of the computer being able to tell the keyboard to turn them on/off. So the adapter drove the LED state to make it work without OS support.
ADB is a bit of a different story, since the Apple Extended Keyboard introduced the 3 LEDs, and the protocol allows for the computer to turn them on/off. Right now, the adapter does not honor the computer's commands to toggle the LEDs, the command is silently ignored. For the most part this doesn't matter, since what the computer is telling the adapter is what the adapter does anyway (turn capslock led on when capslock is pressed, turn it off when pressed again, etc). However, there's a couple little utilities out there to mess with the LEDs of the keyboard for other purposes. I know of at least 2: one that toggles the LEDs to reflect system activity (disk/floppy/etc), and one that just cycles the LEDs.
My current inclination is to leave the existing behavior, since it usually doesn't matter, and it makes the LEDs work with pre-ADB systems.
I just discovered the adapter does not work with an ADB NeXT in the current form. It looks like the NeXT ADB implementation is even more restrictive than the IIgs.
The IIgs Hardware Reference guide documents the 0/1 encoding of ADB as: "A low period of less than 35 percent of the bit-cell time is interpreted as a 1. A low period of greater than 65 percent of the bit cell time is interpreted as a 0", and the overall cycle time should be 100uS. Guide to the Macintosh Family Hardware documents this as a 35/65uS split with a margin of error for ADB devices of +/-5uS. The current adapter uses a 10uS timer, and does a 30/70uS split on the cycle. This meets the IIgs and the Mac specifications of ADB. However, it looks like the NeXT implementation doesn't like 70uS low times (well 69.something uS). That's a bit too long for the NeXT it seems.
As an update, the USB boards arrived and I've got USB to ADB working pretty well for both mouse and keyboard.
Frustratingly, the USB host HID code I'm using seems to not detect the USB devices reliably. I have to reset the board a couple times before it will finally get the keyboard working. I'll have to dive into the USB code at some point to see if I can fix that.
The smaller versions of the ps2 adapter boards arrived today, and I made one up:
It's pretty cramped, and I got the DB9 slightly too close to the ADB & RJ11 connectors, so it's a bit at an angle to fit in. On the PCB, but obscured by the connectors are labels for PS2 keyboard vs. mouse. I guess I should get some purple PS2 connectors to indicate by color coding since labels aren't visible.
I ran into a problem with mounting these on the top of the discovery board:
The adapter board touches (and shorts) some of the connectors on the top of the board, including the programming jumpers. Also when the ADB cable is connected, it obscures the reset button under it (but didn't actually rest on the button depressing it, which is good).
After I doubled up some of those female headers to get the adapter board further off the top of the discovery board, things worked out much better. No touching traces, and the extra space makes the reset button accessible under the ADB cable.
Since I completely changed all the pins and the GPIO registers everything is in, I need to update the code for the new layout, and hopefully I didn't screw anything else up with it. I've got ps2 to ADB keyboard working fine so far.
Awesome, looking good! I agree the DB9 to ADB and RJ11 spacing does seem very tight. Is there room to make the board slightly longer, to space them out just a bit more? Does a DB9 cable fit onto the connector without bumping the other pieces? Though I can't imagine you'll want to do yet another board rev at this point - this is like your third or fourth one, right?
That's too bad about the board shorting the programming jumpers, and the ADB cable obstructing the reset button. I feel guilty, since I believe I was the one who first suggested this layout. I think you can find extra-tall headers on Digikey if you poke around a little - that might solve the problem without needing to insert double headers.
You need to find a spot for the bbraun logo on there somewhere too!
Heh, this is the 5th rev I think? What's one more? I really need a subscription based model for a PCB house!
Anyway, I can make a little more space, so I added essentially 2 more pins worth of space "downward" and moved the ADB and RJ11 connectors down a bit. I haven't moved the DB9 connector, which means it'll be flush with the PS2 connectors, and there should be a little wiggle room between the DB9 and ADB/RJ11 connectors. But I think that's about it. If I go much bigger than that, I may as well go the full length of the board. Plus, the longer the board is, the more the connectors overlap with the buttons on the discovery board.
I've thought about rotating the connectors so they go out the sides, but it seems like the cables will snag and chafe against the solder joints of the header pins, so I'm not really too keen on that.
I've also been thinking about your suggestion of doing a right angle DB9. I think the only way to do that is to go back to doing a full length (or close to it) board. A right angle DB9 should clear the adapter board's header pins just fine.
For the tall female header, I haven't been able to find any on digikey, but they seem to be cheap and plentiful in 6, 8, and 10 pin versions for the Arduino folks. The new board should use two 1x16 female headers, so I guess I can double up the 8pin versions.
Oh, the other thing I realized is I made the header pin holes on the adapter board too small. They work fine for the headers I'm currently using with short flimsy connector pins, but the taller headers use the full sized pins that are too big for the holes I originally had. So this version also increases the hole size for those and the DB9 connector just for good measure.