Apple Desktop Bus

Apple Desktop Bus (or ADB) is a bit-serial computer bus for connecting low-speed devices to computers. It was used on all Apple Macintosh machines starting with the Macintosh II, before it was replaced by USB in the late 1990s, starting on the iMac. ADB was also used on the last series of NeXT machines, models which became known as the "Turbo ADBs". No machines being built today currently use ADB.

The system was created by Steve Wozniak, who had been looking for a project to work on in the mid-1980s. Someone suggested that he should create a new connection system for devices like mice and keyboards, one that would require only a single daisy-chained cable, and be inexpensive to implement. As the story goes, he went away for a month and came back with ADB.

Like most of Wozniak's designs, ADB is a very clever system. It uses only a single pin for data, making it one of the least expensive busses in history. The entire system is based around the devices having the ability to decode a single number (the address) and being able to hold several small bits of data (their registers). ADB can be implemented for less than a penny, the connector always costs more than the hardware.

All traffic on the bus is driven by the host computer, which sends out commands to read or write data: devices are not allowed to use the bus unless the computer first requests it. These requests took the form of single-byte strings. The upper four bits contained the address, the id of one device on the chain, allowing for up to 16 devices on a single bus. The next two bits specified one of four commands, and the final two bits indicated one of four registers. The commands were:

• talk - send the contents of a register to the computer
• listen - set the register to the following number
• flush - clear the contents of the register
• reset - tell everyone on the bus to reset

For instance, if the mouse was known to be at address $3, the computer would periodically send out a message on the bus that looked something like...

0011 11 00

This says that device three (0011) should talk (11) and return the contents of register zero (00). To a mouse this means "tell me if the button has been clicked". This would typically be followed by an additional two commands asking for the contents of registers one and two, the x and y movements. Register three always contained device information. A mouse could thus be implemented with four bytes of memory and a trivial controller.

Device addressing and enumeration was just as clever, if not more so. The addresses of the devices were set to default values when reset. For instance, all keyboards were set to $2, and all mice to $3. When the machine was first powered on the ADB device driver would send out talk commands asking each of these known default address, in turn, for the contents of register three. If no response came from a particular address, the computer marked it dead and didn't bother polling it later.

If a device did respond, it did so by saying it was at a new, random, address. The computer then responded by telling it to move to yet another new address. This made sure that the device was responding correctly, as well as making each device have a unique address. This was included to allow more than one device of the same type to be plugged in, two graphics tablets for instance. In the common case you'd only have one plugged in, and the enumeration would have no problem. However, if you do have more than one they then would all attempt to respond to that initial talk command at the same time, and a collision would occur.

Like any collision this means that the data would be corrupted. ADB relied on this. The devices needed only one more ability, and that was to detect a collision by watching the single data pin. When queried for their register three during startup so that they would return their new random address, they would all watch the bus and only one would be able to respond. That device would then automatically move to the new address handed out by the computer. Now when the next talk command goes out, there's one less device on that default address that answers. After a few tries, all devices have moved and the collisions are gone.

Given the simplicity of the system, it's not surprising that the cabling was equally simple. The single data pin was labelled ADB, and was paired with a +5V and ground. The cable guaranteed at least 500mA, and required devices to use only 100mA. Oddly, however, the ADB cable also included the PSW pin which was attached directly to the power supply. This was included to allow a key on the keyboard to start up the machine without the ADB software needing to interpret the signal.

Data rates on the bus were theoretically as high as 125kbps. However the actual speed was at best half that due to there being only one pin being shared between the computer and devices. In actual use the speed was much less than that, as the entire system was driven by how fast the computer polled the bus. The MacOS was not particularly well suited to this task, and the bus often got bogged down at about 10kbps.

Another problem was while the bus did include a reset command, there was no way for the devices to trigger the bus to indicate some sort of change. This meant that if the bus changed, for instance by plugging in a new device, there was no way for the computer to know. This meant that the system was not hot swappable although this could have been implemented very easily using the PSW had they thought about this case.

External links

• About the ADB Manager (http://developer.apple.com/techpubs/mac/Devices/Devices-205)