Apple Desktop Bus
Apple Desktop Bus (or ADB) is a bit-serial computer bus for connecting low-speed devices to computers. The first system to use ADB was the Apple IIgs in 1986. It was subsequently used on all Apple Macintosh machines starting with the Macintosh II and Macintosh SE, 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 use ADB for device interconnection, but up to February 2005, Powerbooks and iBooks still used ADB to interface with the builtin keyboard and trackpad. The internal connection has now been changed to USB.
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 moving to a new, random, address. The computer then responded to that new address by telling it to move to yet another new address. This bootstrapping protocol served three purposes, one was that it ensured the device in question was working properly, as well as allowing the host computer to build a full list of devices, and finally, it allowed for more than one device of each type.
Given that all keyboards were on $2, it would normally be expected that one could have only a single keyboard, which would respond to messages sent to that address. However the devices were set up with a small bit of timing that allowed them to avoid this problem. After receiving a message from the host, the devices waited a short random time before responding, and then only did so after looking at the bus to make sure it was not busy. If you did plug in two keyboards, or a more common example, two graphics tablets, when the bus was first setting up one of them would be the first to respond on the bus, and the other would notice the bus was busy and not respond. The host would then send out another message to that original address, but since one device had moved to a new address, the other would then respond. This process continued until no one responded to the request, and in this way the computer built up its list of devices.
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 power supply and ground. The +5v pin guaranteed at least 500mA, and required devices to use only 100mA each. Oddly, however, the ADB cable also included the PSW pin which was attached directly to the power supply of the host computer. This was included to allow a key on the keyboard to start up the machine without the ADB software needing to interpret the signal.
Physically, ADB cables are identical to S-Video cables.
Data rates on the bus were theoretically as high as 125 kbit/s. 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 Mac OS was not particularly well suited to this task, and the bus often got bogged down at about 10 kbit/s.
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. As a result, the system was not hot swappable, although this could have been implemented very easily using the PSW had they thought about this case.