In the comments section of yesterday’s post, I mentioned a concern about ADB’s service request (SRQ) mechanism. A device requesting service can pull the ADB bus low at a certain point midway through another ADB transaction, which is called an SRQ signal. It appeared that the SRQ would interrupt the transaction in progress, and cause the host to poll other ADB devices to find the one asserting SRQ. The traffic logs collected by my ADB packet sniffer matched this theory. That would create the potential for bus deadlock if two devices both requested service, each one forever interrupting the other.

To answer this question, I got out my Saleae logic analyzer, so I could directly inspect traffic on the ADB bus. Here’s what I saw for a typical ADB transaction without an SRQ signal:

Everything up to the first stop bit is generated by the host. Everything after that is the reply from the device. Tlt is the “stop bit to start bit time” described in the ADB spec, a period of about 200 microseconds between the command and data sections during which the bus remains high.

A device asserts the SRQ signal by pulling the bus low during the first stop bit, after the command section of the transaction. I had thought this cancelled the rest of the transaction. Or maybe the SRQ signal (nominally 300 microseconds) ate into the Tlt time following it, but the rest of the transaction still finished, as shown by the dotted red line here:

My ADB traffic sniffer showed no traffic after the SRQ, so I assumed it cancelled the rest of the transaction. But when the logic analyzer captured a transaction including an SRQ, it showed this:

SRQ doesn’t cancel the transaction, nor does it eat into the Tlt time. It’s basically a stop bit with an extra-long low time, and it simply delays everything that follows. So there’s no fear of ADB bus deadlock.

Why wasn’t my ADB traffic sniffer showing the data that follows the SRQ? It turned out this was wholly unrelated to my misunderstanding of the SRQ mechanism, but was just a bug in my code. I got too fancy trying to maintain a byte count and a separate SRQ flag in a single status byte, using bit masking operations, and my code didn’t work. With the bug fixed, I now see the true ADB traffic. Address 2 is the keyboard, 3 is the mouse. The keyboard keeps asserting SRQ, but that doesn’t prevent communication with the mouse.

ADB Reset
Addr: 0, Talk 3
Addr: 1, Talk 3
Addr: 2, Talk 3 62 02
Addr: 3, Talk 3 SRQ 69 01
Addr: 4, Talk 3 SRQ
Addr: 5, Talk 3 SRQ
Addr: 6, Talk 3 SRQ
Addr: 7, Talk 3 SRQ
Addr: 8, Talk 3 SRQ
Addr: 9, Talk 3 SRQ
Addr: A, Talk 3 SRQ
Addr: B, Talk 3 SRQ
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 0F FE
Addr: 3, Talk 3 SRQ
Addr: F, Listen 3 SRQ 03 FE
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 0F FE
Addr: 3, Talk 3 SRQ

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.

I’ve added a new feature to the Macintosh/Lisa firmware for the Floppy Emu disk emulator: a menu for selecting disk images while running in Mac hard disk emulation mode. This is the mode that enables Floppy Emu to function as an HD20-type hard disk with compatible Macintosh models, with disk sizes up to 2 GB. Previously the hard disk image was always taken from a file named “HD20.dsk” on your SD card. If you had a few different hard disk image files, and wanted to select the right one for a given situation, you had to put the SD card into your Windows/OSX computer and rename the desired file to HD20.dsk. While this wasn’t a common need, it was not especially user-friendly.

Get the new firmware here: hd20-0.7F-F14.5

With the new firmware, the first time you run it you’ll see a hard disk image selection menu. The name of the chosen disk image file is saved in EEPROM memory, and will be used for all future sessions. If you later want to choose a different disk image file, the NEXT button will return you to the selection menu.

After choosing a new disk image for hard disk emulation mode, the Mac needs to be turned off and on (Floppy Emu will prompt you to do this), or you need to press the Mac’s hardware reset switch. That’s because the Mac doesn’t expect HD20-type drives to be removable media, and doesn’t recognize when the disk has changed. Without a reboot, it will blindly continue as if the original disk were still present, leading to unpleasant results.

I welcome your feedback on this change. Let me know if you run into any trouble.

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!

Holy cow, this is actually happening! After over a year of searching what seems like every warehouse and basement on the planet to scrounge for DB-19 connectors, I’m finally moving forward with the manufacture of new ones. As far as I’m aware, these will be the first new DB-19s made anywhere in two decades, since the days of the Macintosh II, Atari ST, and NeXT.

To make this work, we need to place a BIG order. Right now that looks like 10,000 pieces. If anyone else in the vintage Apple, Atari, or NeXT communities might be interested in joining this group buy for a minimum of 500 pieces or more, please contact me by Monday, March 21. For a male DB-19 with solder cups as pictured above, the price will be about USD $1.41 each, plus or minus a few percent depending on the final tally for shipping and other fees. If you’re interested in a smaller number of connectors, or just one, stay tuned. Other participants in the group buy will be selling individual connectors at retail once the manufacturing is done. More details soon…

I’ve begun looking into options for a USB-to-ADB adapter, to enable use of modern USB keyboards and mice on vintage Macintosh and Apple IIgs hardware. There’s no real “meat” to this yet, as I’m just looking at parts availability and searching for relevant example code, but every project has to begin somewhere.

I did a search to find the cheapest microcontroller with USB Host support (actually USB OTG), and the winner was the Microchip PIC32MX. I know zero about developing with PICs, but how hard can it be? Actually I’ve heard that older PICs were quite awkward to work with, but the PIC32 is a modern RISC-type design.

Microchip sells a PIC32 USB Starter Kit III for $59. I’m not quite sure what this is yet, but it’s probably a better starting point than a bare PIC32 chip.

The kit has an 8 MHz crystal. Will that be enough? Is it replaceable? The PIC32MX is rated to 40-50 MHz depending on the version, but I’m not sure I’ll actually need that speed.

Do I need a USB OTG cable for the finished product? Can the hardware support two attached USB devices (mouse and keyboard), or a USB hub?

What’s this about the MPLAB C compiler reverting to optimization level 1 (no optimization) after 60 days?

So many questions.