I’m continuing work on the USB to ADB input adapter for vintage Macintosh and Apple IIgs computers, and I now have an ADB traffic sniffer that’s more-or-less working. It doesn’t (yet) send any ADB traffic, but it displays ADB traffic from the host computer and other attached devices. This will help me confirm that my ADB decoding is working correctly, and that I actually understand what the heck is happening on the ADB bus, before I start trying to inject anything onto the bus.
The image above shows ADB traffic from a Macintosh SE, at the moment when I began to move the mouse. At first the Mac was repeatedly polling the keyboard (device address 2) by asking it to “talk” register 0, which is the primary data register for an ADB device. The keyboard didn’t have any keypresses to report, so it didn’t reply. At the end of one of these transactions, the mouse pulled the ADB data line low in order to request service for itself – this is the SRQ flag shown in the traffic log. The Mac responded by polling the other ADB devices it knew about, which in this case was only device address 3, the mouse. The mouse responded to the Talk 0 command with some position update bytes. After each Talk 0 command addressed to the mouse, the host sent another Talk 0 to the keyboard, which still didn’t reply. But the mouse again asserted SRQ to request service. Eventually (not shown here), the host stopped polling the keyboard and began repeatedly polling just the mouse. If the keyboard later had new keypress data to report, it would need to assert SRQ.
Here’s a log of the same Mac’s ADB traffic, from a cold boot:
ADB Reset Addr: 0, Talk 3 Addr: 1, Talk 3 Addr: 2, Talk 3 63 08 Addr: 3, Talk 3 68 01 Addr: 4, Talk 3 Addr: 5, Talk 3 Addr: 6, Talk 3 Addr: 7, Talk 3 Addr: 8, Talk 3 Addr: 9, Talk 3 Addr: A, Talk 3 Addr: B, Talk 3 Addr: C, Talk 3 SRQ Addr: D, Talk 3 SRQ Addr: E, Talk 3 SRQ Addr: F, Talk 3 SRQ Addr: 2, Listen 3 0F FE Addr: 2, Talk 3 SRQ Addr: F, Listen 3 02 FE Addr: F, Talk 3 SRQ Addr: 3, Listen 3 SRQ Addr: 3, Talk 3 SRQ Addr: F, Listen 3 SRQ Addr: F, Talk 3 SRQ Addr: 2, Listen 3 0F FE Addr: 2, Talk 3 SRQ Addr: F, Listen 3 02 FE Addr: F, Talk 3 SRQ Addr: 3, Listen 3 SRQ Addr: 3, Talk 3 SRQ Addr: F, Listen 3 SRQ Addr: F, Talk 3 SRQ Addr: 2, Listen 3 0F FE Addr: 2, Talk 3 SRQ
The Mac begins by asking every possible device address to report the contents of register 3, the configuration register. Only addresses 2 and 3 (keyboard and mouse) replied. I’m confused by the reply data bytes shown here – I think the decoding of replies must be buggy, because the lower nibble of the upper byte (3 and 8, respectively) should have matched the device address (2 and 3). Eventually the host sends device 2 a command of Listen 3 0F FE, which tells the keyboard to modify the contents of its configuration register. The effect is to reassign the keyboard from address 2 to address F. Later, it assigns it back to 2, then back to F, then back to 2, over and over. That sure looks odd. The temporary re-assignment of device addresses at startup is part of ADB’s system for discovering address conflicts, but I don’t see why it would need to do so many reassignments. Meanwhile, somebody else (the mouse?) keeps asserting SRQ, which interrupts many of the other commands.
Here’s a log of the startup ADB traffic on an Apple IIgs, ROM 01, with only a keyboard attached:
ADB Reset Addr: 2, Flush Addr: 2, Talk 2 9F 00 Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 2, Talk 0 39 FF Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 3, Listen 3 03 00 Addr: 2, Talk 0 Addr: 3, Listen 3 03 02 Addr: 2, Talk 0 Addr: 2, Flush Addr: 3, Listen 3 03 00 Addr: 2, Talk 0 Addr: 2, Talk 0 Addr: 2, Talk 0 39 FF Addr: 2, Talk 0 Addr: 2, Talk 0
Notice that the IIgs doesn’t appear to do any device address reassignment, so maybe it’s not able to handle ADB address conflicts the way the Mac does. I haven’t tried connecting two keyboards simultaneously to this IIgs, but given what I see in this log, I suspect they would both try to use ADB address 2, and neither one would work. Other interesting things here:
- The host tells the keyboard to Talk 2. This seems to be a special register in the Apple standard and extended keyboards, used to poll the current state of the modifier keys like shift and control. But the Mac doesn’t appear to use this.
- The keyboard twice responded to Talk 0 commands, with the data bytes 39 FF, even though I didn’t press any keys.
- The host repeatedly sends Listen 3 commands to the non-existent mouse, telling it to use device handler ID 0, and then handler ID 2. After reading the ADB docs, I’m unclear what this means.
PIC32 USB Starter Kit II
I’m not exactly loving the PIC32 USB Starter Kit yet. Somehow I missed the fact that this board has no external headers, except for a single super high density connector on the bottom with 132 pins. In practice, the only way to use that connector is to purchase the I/O Expansion Board, which costs more than the kit itself. Otherwise if you want to connect even a single GPIO to the outside world, you’re stuck. There isn’t even any connector for an external power source, other than USB. I ended up having to solder pins to a couple of board test points, and the unpopulated footprint for a 32 kHz crystal. This gave me exactly two GPIOs, 5V, 3.3V, and GND.
Thus far, the Microchip software experience has been not been good. The USB Starter Kit shipped with a CD containing the IDE and example projects, but they didn’t work. I got concerned when the installation instructions only mentioned Windows XP and Vista, and I couldn’t get the IDE to even recognize my board under Windows 7. It turned out that the CD contained MPLAB 8, which was discontinued several years ago, so I deleted everything and downloaded the newest MPLAB X from the Microchip web site, and separately downloaded the XC32 compiler. But all the USB Starter Kit example projects are MPLAB 8 projects, and when I converted them to MPLAB X projects, they didn’t work. After half a day of monkeying around, I finally resolved the issues, but it was a real mess.
For anyone else who may struggle with this, the main problem was that 99.9% of PIC example projects (including Microchip’s own USB Starter Kit examples) use a peripheral library called plib, which is no longer included with the MPLAB X IDE or XC32 compiler. Microchip has declared plib as “end of life”, and is trying to get everyone to use a new framework called Harmony instead, but the developer community seems to have roundly rejected Harmony as being too bloaty and high-level. To use any plib-based examples, you need to download plib separately from the IDE and the compiler, and install it. It makes sense now, but is definitely not a user-friendly process for a PIC newbie. Fortunately I think the environment is finally set up properly, so I can focus on ADB instead of struggling with the tools.