Apple Desktop Bus

From Free net encyclopedia

Image:Apple ADB Keyboard.jpg Apple Desktop Bus (or ADB) is an obsolete bit-serial bus for connecting low-speed devices to computers. Used primarily on the Apple Macintosh platform, ADB equipment is still available but not supported by most Apple hardware manufactured since 1998. It has been completely superseded by USB and Bluetooth.

1 History
2 Description
3 See also
4 External link

[edit]

History

ADB 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.

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 internally to interface with the builtin keyboard and touchpad. The internal connection has now been changed to USB.

[edit]

Description

Like most of Wozniak's designs, ADB is a very clever system. 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). It uses only a single pin for data, making it one of the least expensive busses in history. 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 $D, the computer would periodically send out a message on the bus that looked something like...

1101 11 00

This says that device $D (1101) 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. Register zero was generally the primary communications channel. 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.

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 "higher" 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, only the other would then respond. This process continued until no one responded to the request on the original address, meaning there were no more devices of that type to enumerate. In this way the computer built up its list of devices.

Given the simplicity of the system, it is not surprising that the cabling was equally simple. The single data pin was labelled ADB, and was paired with a +5 V power supply and ground. The +5 V pin guaranteed at least 500 mA, and required devices to use only 100 mA 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 needing 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.

[edit]