Apple Desktop Bus

From Wikipedia, the free encyclopedia.

Jump to: navigation, search
First ADB device
Enlarge
First ADB device

Apple Desktop Bus (or ADB) is an obsolete bit-serial bus for connecting low-speed devices to computers.

History

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, starting on the iMac in 1998. 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 touchpad. 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 the latest position changes". Registers could contain between two and eight bytes. Registers one and two were undefined, and were generally intended to allow 3rd party developers to store configuration information. Register three always contained device identification information. A mouse could be implemented with a few 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 randomly selected address. The computer then responded by sending another command to that new address, asking the device to move to yet another new address. Once this completed that device was marked "live", and the system continued polling it in the future.

Although it was not common, it was possible for the ADB bus to have more than one device of the same sort plugged in -- two graphics tablets or software protection dongles for instance. In this case when it asked for devices on that default address, both would respond and a collision would occur.

However the devices included 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 "snooping" the bus to make sure it was not busy. If you did plug in two dongles, when the bus was first setting up one of them would be the first to respond, 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 connectors 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.

External links

Personal tools
In other languages