Apple Desktop Bus

AppleBus

Early during the creation of the Macintosh computer, the engineering team had selected the fairly sophisticated Zilog 8530 to supply serial communications. This was initially done to allow multiple devices to be plugged into a single port, using simple networking protocols implemented inside the 8530 to allow them to send and receive data with the host computer.^[2]

During development of the AppleBus system, computer networking became a vitally important feature of any computer system. With no card slots, the Macintosh was unable to easily add support for Ethernet or similar local area networking standards. Work on AppleBus was re-directed to networking purposes, and was released in 1985 as the AppleTalk system. This left the Mac with the original single-purpose mouse and keyboard ports, and no general-purpose system for low-speed devices to use.^[2]

ADB

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.

The first system to use ADB is the Apple IIGS of 1986. It is used on all Apple Macintosh machines starting with the Macintosh II and Macintosh SE. ADB is also used on later models of NeXT computers.^[3] The vast majority of ADB devices are for input, including track balls, joysticks, graphics tablets and similar devices. Special-purpose uses include software protection dongles and even the TelePort modem.

Move to USB

The first Macintosh to move on from ADB is the iMac in 1998, which uses USB in its place. The last Apple computer to have an ADB port is the Power Macintosh G3 (Blue and White) in 1999. PowerPC-based PowerBooks and iBooks still use the ADB protocol in the internal interface with the built-in keyboard and touchpad. Subsequent models use a USB-based trackpad.

Physical

In keeping with Apple's general philosophy of industrial design, ADB was intended to be as simple to use as possible, while still being inexpensive to implement. A suitable connector was found in the form of the 4-pin mini-DIN connector, which is also used for S-Video. The connectors are small, widely available, and can only be inserted the "correct way". They do not lock into position, but even with a friction fit they are firm enough for light duties like those intended for ADB.

ADB's protocol requires only a single pin for data, labeled ADB. Two of the other pins are used for +5 V power supply and ground. The +5 V pin guarantees at least 500 mA, and requires devices to use only 100 mA each. ADB also includes the PSW pin which is attached directly to the power supply of the host computer. This is included to allow a key on the keyboard to start up the machine without needing the ADB software to interpret the signal. In more modern designs, an auxiliary microcontroller is always kept running, so it is economical to use a power-up command over the standard USB channel.

Most serial digital interfaces use a separate clock pin to signal the arrival of individual bits of data. However, Wozniak decided that a separate wire for a clock signal was not necessary; and as ADB was designed to be low-cost, it made economical sense to leave it out. Like modems, the system locks onto the signal rise and fall times to recreate a clock signal.

The decoding transceiver ASIC as well as associated patents were controlled by Apple; this required vendors to work more closely with Apple. In the Macintosh SE, the ADB is implemented in an Apple-branded Microchip PIC16CR54 Microcontroller.

The ADB is implemented in an early Microchip PIC Microcontroller in the Macintosh SE.

Communication

The ADB 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). 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 take the form of single-byte strings. The upper four bits contain the address, the ID of one of the devices on the chain. The four bits allow for up to 16 devices on a single bus. The next two bits specify one of four commands, and the final two bits indicate one of four registers. The commands are:

• 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 is known to be at address $D, the computer will periodically send out a message on the bus that looks 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 can contain between two and eight bytes. Register zero is generally the primary communications channel. Registers one and two are undefined, and are generally intended to allow 3rd party developers to store configuration information. Register three always contains device identification information.

Enumeration and identification

The addresses and enumeration of the devices are set to default values when reset. For instance, all keyboards are set to $2, and all mice to $3. When the machine is first powered on, the ADB device driver will send out talk commands asking each of these known default addresses, in turn, for the contents of register three. If no response comes from a particular address, the computer marks it dead and doesn't bother polling it later.

If a device does respond, it does so by saying it is moving to a new randomly selected higher address. The computer then responds by sending another command to that new address, asking the device to move to yet another new address. Once this completes, that device is marked live, and the system continues polling it in the future. Once all of the devices are enumerated in this fashion, the bus is ready to be used.

Although it was not common, it is possible for the ADB bus to have more than one device of the same sort plugged in — two graphics tablets or software copy protection dongles, for instance. In this case when it asks for devices on that default address, both will respond and a collision could occur. The devices include a small bit of timing that allows them to avoid this problem. After receiving a message from the host, the devices wait a short random time before responding, and then only do so after "snooping" the bus to make sure it was not busy.

With two dongles plugged in, for instance, when the bus is first setting up and queries that address, one of them will be the first to respond due to the random wait timer. The other will notice the bus was busy and not respond. The host will then send out another message to that original address, but since one device has moved to a new address, only the other will then respond. This process continues until no one responds to the request on the original address, meaning there are no more devices of that type to enumerate.

Data rates on the bus are theoretically as high as 125 kbit/s. However, the actual speed is at best half that, due to there being only one pin being shared between the computer and devices, and in practice, throughput is even less, as the entire system was driven by how fast the computer polls the bus. The classic Mac OS is not particularly well suited to this task, and the bus often gets bogged down at about 10 kbit/s. Early Teleport modems running at 2400 bit/s have no problems using ADB, but later models were forced to move to the more expensive RS422 ports as speeds moved to 14.4 kbit/s and higher.