I'm using an stm32f0discovery board to pretend to be a keyboard for a 128k/512k/Plus machine. I chose the board mainly because it's cheap ($8 from digikey) and comes with a perfboard, making it pretty accessible. Solder on some connectors and done (for the most part). It also comes with a builtin programmer, so nothing special needed to program it, hardware wise. This template makes things pretty simple to compile and load onto the device from linux.
It's a 3.3V device and the Plus keyboard is 5V, so I'm using this level converter from adafruit, also fairly cheap and easily attaches to the perfboard.
I've mainly been using this as my reference for the protocol. Essentially the keyboard controls the clock, the data is bidirectional and orchestrated by the computer. When the computer wants to talk, it pulls the normally high data line low, the keyboard starts clocking, and the computer sends its data. The keyboard then responds, and done.
There are only a couple commands the computer sends. The two most common (and the ones I've implemented) are Model Number (0x16) and Inquiry (0x10). The computer polls the keyboard continuously with an Inquiry command, and the keyboard returns any keys that have been pressed. The keyboard must respond within 500ms or the computer resets and starts over. The keyboard will issue another Inquiry command immediately upon receiving a response, so the keyboard is responsible for rate limiting the polling. If no keys have been pressed, the keyboard should wait about 250ms before sending a null response otherwise it'll just be a tight polling loop.
Here's a screenshot from the Saleae logic analyzer:
This shows the start of the Model Number request (0x16), and my response (0x03) indicating a keyboard of model number 1 is connected with no keypad.
This shows the start of the Inquiry request (0x10) and my response (0x7B) indicating no keypress. I'm not waiting here, so the computer is immediately issuing another Inquiry command, which I'm responding immediately, etc.
Woo! The rat's nest in this picture is currently connecting a PS2 keyboard to a Mac Plus, and it's actually working.
This was an invaluable resource for getting the PS2 side of things working. The stm32f0discovery is supporting communication both from the keyboard and to the keyboard (the capslock LED works).
I'll try to clean it up a bit by putting the level converters and connectors onto a perfboard rather than just having wires all over the place, and I'm sure there's still a bug or two around. But it's working well enough for me to type sentences into teachtext.
Here is the whole thing after putting it on the perf board. Ideally those would be connectors instead of soldering the wires to the pcb (well, the rj11 cable is hacked up to connect to headers), but this is all I had available at the moment. Maybe the next one I build will do that.
I took a couple videos of it in action, but sadly the iphone4s' video capabilities aren't that great.
I tried one with the amber display Plus, and one with the normal display to see which came out better.
I've ordered a PCB that should in theory fit as a cape/shield/whatever onto the headers of the stm32f0discovery, and wire up the level converters. I don't actually physically have the rj11/ps2 connectors yet, so I just made this initial PCB rev with headers for connecting the cables.
It's the first time I've sent off one of my PCB designs to be produced, so I'm curious to see how it turns out. It's pretty basic, but I'll find out if I got all the drill sizes correct and spacing and all that fun stuff.
The idea is that you just have the stm32f0discovery, slap this on, and away you go (modulo programming the chip anyway).
The PCBs arrived yesterday. It's been a learning experience.
I intentionally did not make the proper holes for the ps2 and 4p4c rj11 connectors because I didn't have them available at the time I was doing the PCB, so that was an expected issue.
Unexpected issues were 1) I had the hole sizes too small. I was just using the defaults for the program I was using (Osmond PCB), and it turns out those are waaay too small. Essentially pin holes are the same size as vias. And 2) the stm32f0discovery board apparently has different grounds for 3.3v and 5v. I had everything connected to the 3.3v ground, so the 5v to the ps2 keyboard wasn't working correctly.
I could work around all of those issues by soldering wires around, so I could at least verify my corrections.
I think I addressed those 3 issues and sent it off for another revision. So it'll probably be another 3 weeks or so.
These logic analyzer screens have been handy. I finally have a complete dump of the original keyboard and optional keypad's i8021 as seen in the Bitsavers "IM Underground Vol. 1" (that PDF is missing a page in the middle of the commented disassembly, but everything else lines up) and I've been trying to get it working in MESS. It's not always clear who's meant to be pulling the data line which way, among other things, but it's starting to come together.
Cool, I'm glad they're useful. The next round of my PCBs should be arriving in the next 1.5 weeks or so, and I'll be getting into it again then. I'll be setup to do more captures when those arrive, so if you need more let me know.
Looks like the PCBs arrived earlier than I expected.
It attaches to the stm32f0discovery board. The holes for the rj11 supports are off, unfortunately. But other than that it seems to work ok.
If anyone is interested in one of these, let me know. I've got 10 PCBs, since that's the minimum Seeed order. Ideally, any of the initial recipients would be able to use openocd or similar to update the firmware in case something is broken and gets fixed. So far, I'm the only one to use it, and it works for me, but you know how that goes.
Another neat thing I discovered while working on the software for this. The Plus and earlier lacked a lot of meta keys, like escape and control. However, just sending the ADB scan codes for those keys (although the protocol shifts the code left 1 bit and ORs in bit 0) seems to work fine. I was able to use vi and screen via telnet from a Plus using that approach.
So it's another reason to use the adapter! Get keys you can't get on Apple provided keyboards.
Aww.. I wish this worked on my more favorite 8-bit micros, like the AVR or PIC. I am not familiar with that one.
I know there was another project where someone made it work on a Z80 or 8051, something like that. But thats not the Micros I use.
What would be more awesome is the ADB nut cracked, using modern optical mice on the ADB systems. Or optical PS/2 mice on the mac 128/512/plus systems which I worked on at one time, even writing the code to read the positioning information from a PS/2 optical mouse. but I couldnt generate the quadrature encoding correctly.
I hadn't seen the MacCharlie before, that's pretty neat. I'd expect it did something similar, yeah.
As for the chip, I just happened to have a couple of these boards lying around looking for something to do. There's no particular technical reason I picked it. After-the-fact nice features: 1) cheap at $8, 2) I can just slap a board on the back of it and call it good. There's virtually no "production" I have to do.
Since the chip has 5V tolerant GPIOs, I tried it without doing any level conversion and it seems to work fine. That saves about $8-9 off the cost I guess.