Hubbry Logo
logo
Apple Desktop Bus avatar
Apple Desktop Bus
Community hub

Apple Desktop Bus

logo
0 subscribers
Read side by side
Apple Desktop Bus
View on Wikipedia
from Wikipedia

Apple Desktop Bus
The Apple Desktop Bus icon and an early Apple Desktop Bus keyboard
Type Human input device interface
Production history
Designer Apple Computer
Designed 1986; 39 years ago (1986)
Manufacturer Apple Computer Inc.
Produced 1986 to 1999
Superseded RS-422/6522 keyboard and mouse
Superseded by USB and FireWire (1998–1999)
General specifications
Hot pluggable occasional support
External yes
Pins 4
Connector Mini-DIN
Data
Data signal Bi-directional serial command stream
Bitrate 125 kbit/s maximum
(~10 kbit/s actual)
Max. devices 16 maximum
(~5 actual, 3 supported)
Protocol Serial
Pinout
Female socket from the front
Pin 1 Apple Device Bus Data
Pin 2 PSW Power on
Pin 3 +5 V +5 volts power
Pin 4 GND Ground
Same connector as S-Video

Apple Desktop Bus (ADB) is a proprietary[1] bit-serial peripheral bus connecting low-speed devices to computers. It was introduced on the Apple IIGS in 1986 as a way to support low-cost devices like keyboards and mice, enabling them to be connected together in a daisy chain without the need for hubs or other devices. Apple Desktop Bus was quickly introduced on later Macintosh models, on later models of NeXT computers, and saw some other third-party use as well. Like the similar PS/2 connector used in many PC-compatibles at the time, Apple Desktop Bus was rapidly replaced by USB as that system became popular in the late 1990s; the last external Apple Desktop Bus port on an Apple product was in 1999, though it remained as an internal-only bus on some Mac models into the 2000s.

History

[edit]

AppleBus

[edit]

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 communication protocols implemented inside the 8530 to allow them to send and receive data with the host computer. The idea was to allow multiple devices to be connected to a port, eliminating the need for many different types of ports or the use of expansion slots.[2]

During development of this 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]

Apple Desktop Bus

[edit]

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

Move to USB

[edit]

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

Design

[edit]

Physical

[edit]

In keeping with Apple's general philosophy of industrial design, Apple Desktop Bus was intended to be as simple to use as possible, [citation needed] while still being inexpensive to implement. A suitable connector was found in the 4-pin mini-DIN, which is also used for S-Video. In fact, many S-Video cables can be successfully used in place of their ADB counterparts. However, pins one and two on some (mainly lower-end) cables are bridged together, which can result in catastrophic damage to the system or ADB device. 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 ADB.

ADB protocol requires only a single pin for data, labeled Apple Desktop Bus. The data signal is self-clocking by sending a 0 as low for 65 microseconds and high for 35 μs, while sending a 1 uses the opposite timing.[4] It is a multi-drop open collector design with pull-ups to 5 V and uses collision detection to avoid device ID conflicts as well as clock stretching on the stop bit to indicate that a device requires a service request.[4] Two of the other pins are used for +5 V power 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 (Power Switch) pin which is attached directly to the power supply of the host computer. This is included to allow a keypress on the keyboard to start 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.

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

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

Communication

[edit]

The Apple Desktop Bus system is based around the devices having the ability to decode a single number (the address) and being able to hold several small items 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 - tells the selected device to send the contents of a register to the computer
  • listen - tells the device to set the register to the following value
  • flush - clear the contents of a selected register
  • reset - tell all devices on the bus to reset

For instance, if the mouse is known to be at address $D, the computer will periodically send out a 1-byte 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

[edit]

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 Apple Desktop 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 timing variation 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 nothing 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 throughput 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 slows to about 10 kbit/s. Early Teleport modems running at 2400 bit/s have no problems using Apple Desktop Bus, but later models were forced to move to the more expensive RS-422 ports as speeds moved to 14.4 kbit/s and higher.

Problems

[edit]

While Mini-DIN connectors cannot be plugged in the "wrong way", it is possible to have trouble finding the right way without looking inside the circular connector's shroud. Apple attempted to help by using U-shaped soft plastic grips around the connectors to key both plugs and sockets so the flat side has a specific relation to the shell keyway, but this feature was ignored by some third-party manufacturers. Additionally, there are four ways to orient the receiving socket on a device such as a keyboard; various Apple keyboards use at least three of these possible orientations.

The mini-DIN connector is only rated for 400 insertions and it is easy to bend a pin if not inserted with caution; in addition, the socket can become loose, resulting in intermittent function.

Some Apple Desktop Bus devices lack a pass-through connector, making it impossible to daisy-chain more than one such device at a time without obscure splitter units. Few mice or trackballs have them.

In spite of being electrically unsafe for hot-swapping on all but a few machines, ADB has all the basic capabilities needed for hot-swapping (like modern buses) implemented in its software and hardware. On practically all original Apple Desktop Bus systems, it is not safe to plug a device once the system is powered on. This can cause the opening of a soldered-in fuse on the motherboard. If brought to an authorised dealer, this can result in a motherboard swap at a significant expense. The simpler alternative is to obtain a fuse at a nominal cost and wire it in parallel across the open motherboard fuse (not necessarily requiring soldering).

Patents

[edit]
  • 4,875,158 Ashkin; Peter B. (Los Gatos, CA), Clark; Michael (Glendale, CA)
  • 4,910,655 Ashkin; Peter B. (Los Gatos, CA), Clark; Michael (Glendale, CA)
  • 4,912,627 Ashkin; Peter B. (Los Gatos, CA), Clark; Michael (Glendale, CA)
  • 4,918,598 Ashkin; Peter B. (Los Gatos, CA), Clark; Michael (Glendale, CA)
  • 5,128,677 Donovan; Paul M. (Santa Clara, CA), Caruso; Michael P. (Sudbury, MA)
  • 5,175,750 Donovan; Paul M. (Santa Clara, CA), Caruso; Michael P. (Sudbury, MA)
  • 5,828,857 Scalise; Albert M. (San Jose, CA)

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Apple Desktop Bus

View on Grokipedia
from Grokipedia
The Apple Desktop Bus (ADB) is a proprietary, low-speed bit-serial peripheral interface developed by Apple Inc. for connecting input devices, such as keyboards, mice, and graphics tablets, to Macintosh and Apple II computers.[1] First introduced on the Apple IIGS in September 1986, ADB was adopted in Macintosh systems starting with the Macintosh SE and Macintosh II models in March 1987, replacing earlier proprietary serial connections and allowing daisy-chaining of up to 16 devices on a single bus using a 4-pin Mini-DIN connector, with a maximum data rate of approximately 10 kbit/s.[2] The bus operates on a polled protocol managed by the ADB Manager software in the Macintosh Operating System, which assigns unique 4-bit addresses to devices (ranging from 1 to 15) to resolve collisions and facilitate communication through commands like Talk, Listen, and Flush.[1] Electrically, ADB uses open-collector signaling with a 5V supply, enabling service requests from devices during idle periods on the bus.[3] It became the standard for low-bandwidth peripherals on Macintosh systems through the 1990s, supporting devices like the Apple Extended Keyboard and ADB Mouse II, until its discontinuation with the release of the iMac on August 15, 1998, which adopted USB as the replacement interface for greater speed and universality.[1]

History

AppleBus Proposal

In the early 1980s, Apple's Macintosh project required an affordable interface for connecting low-bandwidth peripherals such as keyboards, mice, and joysticks, prompting engineers to explore alternatives to expensive dedicated hardware. The team initially planned to use the Zilog 8530 serial communications controller for these devices, but its complexity and cost—around $10 per unit—proved incompatible with the Macintosh's goal of a sub-$1,000 price point.[4] Ultimately, separate RJ-11 keyboard and DE-9 mouse ports were used in the original Macintosh and Lisa systems due to development timelines and the evolving focus on distinct topologies for initial production models. These early designs laid foundational ideas for economical peripheral connectivity that later matured into the Apple Desktop Bus protocol.[4][5]

Development and Standardization

The development of the Apple Desktop Bus (ADB) commenced in 1986 as an internal Apple project to create a low-cost peripheral interface for input devices, motivated by the need to replace more expensive connectors like the DE-9 used in earlier Macintosh models. This effort resulted in a bit-serial bus optimized for keyboards, mice, and similar low-bandwidth devices, with initial implementation completed for the IIGS release in September 1986.[4] Key design choices emphasized cost reduction and ease of integration, adopting a 4-wire interface consisting of +5V power, two ground lines (logic and power return), and a single bidirectional open-collector data line via a 4-pin Mini-DIN connector. The bus supports up to 16 devices in theory through daisy-chaining and address-based communication, though practical limits were often lower due to power and protocol constraints. Signaling operates at a nominal bit rate of 10 kbit/s, with capabilities up to 125 kbit/s in optimized configurations, prioritizing reliability over high speed for input peripherals.[6][4] Apple opted to maintain ADB as a proprietary standard, requiring manufacturers to obtain a license and unique device handler ID from Apple for compatibility, rather than adopting open industry protocols like RS-232, which lacked built-in power delivery and multi-device support. This decision ensured tight control over the ecosystem but limited broader adoption beyond Apple's platforms. The full specification was provided to licensees, formalizing ADB as Apple's standard for low-speed peripherals.[6] Early prototypes were tested internally on the Macintosh SE in 1987, validating the bus's reliability for multi-device operation before wider integration. Third-party involvement included developers like Alps Electric, who contributed to initial peripheral implementations such as keyboards, enabling early ecosystem growth under Apple's licensing framework.[4]

Introduction in Macintosh Systems

The Apple Desktop Bus (ADB) debuted commercially in Macintosh systems with the release of the Macintosh SE and Macintosh II in March 1987.[2] These models marked Apple's shift toward a standardized peripheral interface, replacing the proprietary DE-9 connector for the mouse and RJ-11 connector for the keyboard that had been used on the preceding Macintosh Plus.[7] The introduction of ADB provided a more flexible and expandable solution for connecting input devices.[6] The initial ADB port on these Macintosh systems utilized a 4-pin mini-DIN connector, enabling a daisy-chain topology that theoretically supported up to 16 devices connected in series.[4] This design allowed for simplified cabling by permitting peripherals to pass the bus signal to the next device, reducing the need for multiple dedicated ports on the computer. Additionally, the port delivered power to connected devices at 5 V with a total capacity of up to 500 mA, sufficient for low-power input peripherals without requiring separate power supplies.[8] Early peripherals designed for ADB included the Apple Keyboard (model M0110), the Apple Mouse (model M0100 successor), and Apple's trackball options, which integrated seamlessly with the new bus for pointing and input tasks.[9] These devices emphasized ergonomic design and reliability, with the keyboard offering an extended layout and the mouse featuring an optical-mechanical tracking mechanism. Initial market reception was positive among users seeking expandability, as ADB facilitated easier setup compared to the Macintosh Plus's rigid connections. Third-party support emerged quickly following the launch, with companies like Logitech developing compatible mice that adhered to Apple's specifications, broadening peripheral options for Macintosh users.[10] To encourage this adoption, Apple released developer guidelines in 1987 through the Inside Macintosh documentation, detailing the bus protocol, addressing, and integration requirements for custom ADB devices.[6] This documentation provided essential resources for hardware and software compatibility, fostering an ecosystem around the new interface.

Expansion and Peak Usage

Following its initial adoption in 1987 with the Macintosh SE and Macintosh II, the Apple Desktop Bus (ADB) saw significant expansion across Apple's product lines in the late 1980s and 1990s. The interface was integrated into the first PowerBook laptops, starting with the PowerBook 100 series introduced in October 1991, which featured a single ADB port for connecting keyboards and pointing devices.[11] By 1994, ADB had become a core component of the Power Macintosh lineup, as evidenced by the Power Macintosh 6100, Apple's inaugural PowerPC-based desktop, which included one ADB port alongside other connectivity options.[12] Peripherals like the Apple Extended Keyboard, launched in 1987 as an optional full-size accessory for the Macintosh II and SE with its ADB connectivity enabling daisy-chaining, further exemplified early growth in compatible hardware.[13] By the mid-1990s, ADB achieved peak usage as the standard input interface for nearly all Macintosh systems, supporting a wide array of low-bandwidth peripherals essential to creative and professional workflows. It powered diverse devices such as MIDI interfaces for music production, graphics tablets for design applications, and barcode scanners for inventory management in retail environments.[4] This ubiquity stemmed from ADB's simplicity and daisy-chain design, which allowed up to five devices—though Mac OS typically limited practical use to three—without requiring dedicated ports for each.[14] The ecosystem flourished with robust third-party support, enhancing ADB's versatility beyond Apple's offerings. Companies like Kensington contributed trackballs, such as the Turbo Mouse series introduced in 1989, which provided precise control for graphic designers and became a staple in the Macintosh community.[15] Similarly, Gravis developed ADB-compatible joysticks like the Advanced Gravis MouseStick, a programmable opto-mechanical controller released around 1990 that doubled as a pointing device for gaming and productivity on Macintosh systems.[16] Apple facilitated this integration through the ADB Manager, a software component in the Macintosh Operating System that enabled developers to query device information, send commands, and manage bus communications for seamless configuration.[17] ADB's expansion extended internationally, with adaptations for regional markets including Japanese Macintosh models equipped with localized JIS-layout keyboards connected via the bus. These variants, such as the Apple Keyboard II JIS (model M0487), supported kanji input and full-width characters while maintaining compatibility with standard ADB protocols.[18]

Transition to USB

In October 1997, during a keynote address, Steve Jobs announced Apple's forthcoming support for USB as a standard interface for peripherals, driven by the need for industry-wide standardization and USB's superior performance capabilities, including full-speed data rates up to 12 Mbit/s compared to ADB's theoretical maximum of 125 kbit/s.[19][20] This shift marked the beginning of ADB's gradual phase-out, with USB making its debut on the iMac G3 released in August 1998, a consumer desktop that featured two USB ports exclusively for peripherals and eliminated ADB connectivity to simplify design and promote cross-platform compatibility.[21] ADB persisted on professional models for legacy compatibility, including the Blue & White Power Macintosh G3 introduced in January 1999, which included both USB and ADB ports until its discontinuation later that year.[4] The transition presented challenges for users reliant on ADB devices, prompting Apple to endorse third-party USB-to-ADB adapters—such as the iMate converter—that enabled older keyboards, mice, and other peripherals to interface with USB-equipped systems, supplemented by Mac OS X's built-in ADB Manager software for emulation and driver support.[22] By 2000, with the introduction of the Power Mac G4 series, Apple fully omitted native ADB ports from new hardware, accelerating the ecosystem's reliance on USB.[23] ADB hardware support ended entirely with the Power Mac G5 in 2003, and software compatibility for legacy ADB devices via adapters was phased out by Mac OS X 10.5 Leopard in 2007, concluding over two decades of ADB's role in Apple's computing platforms.

Design

Physical Interface

The Apple Desktop Bus (ADB) employs a proprietary 4-pin mini-DIN connector for its physical interface, which differs from standard mini-DIN implementations in pin assignments to support bus functionality.[24] The pinout is as follows: pin 1 carries the bidirectional ADB data signal, pin 2 handles the power switch (PSW) line for system control, pin 3 provides +5 V power, and pin 4 serves as ground.[25] This connector design allows for both upstream connection to the host and downstream pass-through for daisy-chaining peripherals.[24] ADB systems utilize a daisy-chain topology, where devices connect in series via short extension cables, enabling a single port on the host computer to support multiple peripherals without a hub.[24] The cabling consists of four wires—corresponding to power, ground, data, and PSW—shielded within a twisted-pair or coaxial configuration to minimize interference, with a maximum total bus length of 5 meters to maintain signal integrity.[5] Up to 16 devices can theoretically be addressed on the bus, though Apple recommended limiting configurations to three devices to prevent excessive signal degradation.[24] Power delivery over ADB is provided at +5 V DC, with a shared maximum current of 500 mA across all connected devices from the host's supply.[26] This allocation supports low-power peripherals like keyboards (typically 25–100 mA) and mice (up to 10 mA), but high-current devices such as certain trackballs or scanners require external power supplies to avoid exceeding the bus limit.[24] The data line operates as an open-drain interface for bidirectional communication.[5] While the standard connector is the 4-pin mini-DIN across most Macintosh systems, some laptop models like the PowerBook series and ADB adapters for Apple II compatibility occasionally used a larger round 4-pin variant or integrated ports, though functionality remained consistent with the core pinout.[27]

Electrical and Signaling Characteristics

The Apple Desktop Bus (ADB) employs an open-drain configuration for its bidirectional data line, allowing multiple devices to share the bus without contention by enabling any device or the host to pull the line low while the idle state is maintained high.[28] Devices interface with the data line using NMOS pull-down transistors to actively drive the signal low, ensuring compatibility with the wired-OR logic arrangement.[5] In the idle state, the data line is pulled high to +5 V through a 470 Ω resistor connected to the host's power supply, preventing floating inputs and establishing a defined logic level.[28] Logic high levels range from 2.4 V to 5 V, while logic low is defined as a maximum of 0.8 V, with output low specified at 0.45 V when sinking up to 12 mA to mitigate bus contention during simultaneous pulls.[28][5] Power for ADB devices is provided by a regulated +5 V supply from the host, with a total current limit of 500 mA across all connected devices to ensure stable operation and prevent overload.[28] To preserve signal integrity, each device contributes no more than 150 pF of input capacitance, with cable capacitance limited to 100 pF per meter, resulting in a total bus capacitance under 200 pF for typical configurations.[28] ADB does not utilize differential signaling for the data line, relying instead on single-ended transmission susceptible to noise over longer distances; Apple recommends shielded twisted-pair cabling within the 4-wire Mini-DIN connectors to minimize electromagnetic interference and maintain reliable signaling up to 5 meters.[28]

Communication Protocol

The Apple Desktop Bus (ADB) employs an asynchronous serial communication protocol designed for low-speed input devices, operating in a bit-bang style where the host or devices generate timing signals on demand.[28] The protocol uses non-return-to-zero (NRZ) encoding, with each bit cell lasting approximately 100 µs (nominal bit rate of 10 kbit/s), where a logical '0' consists of 65 µs low followed by 35 µs high, and a logical '1' consists of 35 µs low followed by 65 µs high (tolerances of ±5% for timing accuracy).[29] Data transmission includes start and stop bits for framing: commands begin with an attention signal (line low for ~800 µs), a sync pulse (65 µs high ±3%), an 8-bit command byte, and a stop bit (70 µs low); data packets follow with a start bit (logical '1'), 2 bytes of data transmitted most significant bit first, and a stop bit (logical '0').[28][1] The command structure is based on a single 8-bit command byte, where bits 7–4 specify the device address (0–15, hexadecimal 0–0–F), bits 3–2 indicate the command code (10 for Listen, which directs the device to receive 2 bytes from the host into the specified register; 11 for Talk, which prompts the device to transmit 2 bytes from the specified register to the host; 00 for Flush, to clear the specified register, typically with register select 01; SendReset is a special global command with address and register 00), and bits 1–0 select the target register (0–3 on the device for data storage). Each register is 16 bits (2 bytes) in size, allowing for structured data like key codes or coordinates.[1][29] Following the command byte, Listen commands include 2 bytes of host-to-device data, while Talk commands elicit 2 bytes of device-to-host data from the specified register, typically register 0 for primary input like mouse coordinates or key codes.[28] SendReset is a special global command (all addresses, code 00) that pulls the bus low for at least 3 ms to reset all devices.[8] Error detection relies primarily on collision monitoring during transmission rather than explicit parity bits or checksums, though some device extensions may incorporate basic checksum validation for data integrity.[5] Bus arbitration in ADB supports multi-master access through an open-collector (open-drain) configuration on the bidirectional data line, allowing multiple devices to share the bus without damaging conflicts via wired-OR logic.[28] The host acts as the primary master, initiating synchronous Talk or Listen requests via polling (typically every 11 ms for active devices or 250 ms otherwise), but devices can request service by asserting a Service Request (SRQ) signal, pulling the data line low for approximately 300 µs (±30%) following the stop bit of the previous transaction to signal pending data.[1] Collision detection occurs during address enumeration or SRQ phases, where devices monitor the bus state in real-time; if a collision is detected (e.g., another device pulling low simultaneously), the losing device aborts and retries after a random delay, ensuring fair access through this decentralized mechanism.[29] This arbitration enables up to 16 devices on the bus while maintaining orderly communication, with effective throughput limited to around 1–2 kB/s due to polling overhead despite the nominal 10 kbit/s bit rate.[28]

Device Addressing and Enumeration

The Apple Desktop Bus (ADB) employs a 4-bit addressing scheme, allowing for up to 16 unique addresses numbered from 0 to 15 (in hexadecimal, $0 to $F), with address 0 ($0) reserved for the host in global commands, and addresses 1 to 14 ($1 to $E) available for peripheral devices (8 to 14 for dynamic reassignment to resolve conflicts).[28][30] Each device is initially assigned a default address by the manufacturer, corresponding to its general type—such as $2 for keyboards and $3 for mice—to facilitate basic identification and communication without prior configuration.[1] These default addresses are predefined under Apple's licensing guidelines to minimize conflicts among standard peripherals, though custom or third-party devices may require dynamic reassignment during operation.[1] Enumeration of devices on the ADB occurs primarily at system startup or after a bus reset, initiated by the host sending a global Reset command that places all connected devices into a known initial state where they respond to commands directed at their default addresses.[28] The host then systematically polls potential default addresses (typically $1 through $E) using Talk Register 3 commands, prompting each device to transmit the contents of its Register 3, which includes its current address and a device handler ID byte for type identification—such as 0x01 for an Apple Standard Keyboard or 0x0F for a mouse.[1] If multiple devices share the same default address, a collision is detected through the bus's synchronous serial protocol, where simultaneous transmissions result in timing anomalies that the host recognizes; in such cases, the ADB Manager reassigns unique addresses to the conflicting devices by issuing targeted Listen Register 3 commands with new address values, often starting from higher addresses like $8 to avoid overlap with defaults.[28] This process builds a device table in the host's memory, mapping each device's address, handler ID, and location for subsequent communication, ensuring orderly access without true plug-and-play capabilities.[1] ADB devices support up to four registers (numbered 0 through 3), each 16 bits wide, for configuration and status data.[1] Register 0 typically holds core device identification and input data, such as key codes from a keyboard; Registers 1 and 2 store auxiliary configuration or status information, like modifier keys; and Register 3 contains critical enumeration details, including the 4-bit device address in its upper nibble (bits 11-8) and the 8-bit handler ID in the lower byte (bits 7-0), along with version information in some cases.[1] During enumeration, the host queries these registers sequentially via Talk commands to gather full device profiles, enabling software to load appropriate drivers based on the handler ID—for instance, distinguishing a standard mouse (handler ID 0x0F) from other pointing devices.[28] Despite its structured enumeration, ADB lacks native hot-plug support, meaning devices added or removed after initial startup do not trigger automatic redetection, often requiring manual intervention such as executing the ADBReInit routine to rebuild the device table or performing a full system reset to reinitialize the bus.[1] This limitation stems from the protocol's reliance on a fixed startup polling sequence, where changes in bus topology can lead to unrecognized devices or stalled communications until reconfiguration, making ADB unsuitable for dynamic peripheral swapping without user or software assistance.[28]

Implementation

Hardware Integration

The Apple Desktop Bus (ADB) was integrated into Macintosh motherboards through dedicated hardware components responsible for bus arbitration, data serialization, and peripheral polling. On the host side, some early Macintosh systems, such as the Macintosh II, employed a Motorola 68HC05 microcontroller, programmed with custom firmware to manage ADB operations, including interrupt-driven communication with the CPU via the MOS Technology 6522 Versatile Interface Adapter (VIA). This configuration allowed the main processor to offload low-level bus tasks, ensuring responsive handling of input devices while minimizing CPU overhead.[31][32] Peripheral controllers utilized custom application-specific integrated circuits (ASICs) and microcontrollers to interface with the bus, enabling features such as automatic power switching and status feedback via LEDs. For instance, Apple's keyboards and mice incorporated chips like the M50740 (a 6502-based MPU in the Apple IIGS keyboard) to decode commands, manage device registers, and transmit data synchronously. These components supported bidirectional communication and collision detection without requiring complex external logic.[33][32][34] Expansion capabilities extended ADB to non-native systems via add-in cards, such as those fitting the Processor Direct Slot (PDS) in Macintosh LC-series computers, which could incorporate ADB transceivers for additional ports or enhanced compatibility. Adapters also facilitated Apple II integration, allowing ADB peripherals to connect to older models lacking native support through bridging circuitry that emulated legacy interfaces.[4][35] The bus's simple four-wire design and reliance on low-pin-count ICs, including transceiver ASICs licensed from Apple, enabled economical hardware integration, with basic port implementations achievable at minimal additional cost due to shared connectors and off-the-shelf components.[36][5]

Software Drivers and APIs

The software support for Apple Desktop Bus (ADB) in Macintosh systems centered on the ADB Manager, a component of the Macintosh Toolbox that facilitated communication with attached devices, device enumeration, and address conflict resolution.[1] The core programming interface was the ADBOp procedure, which enabled asynchronous transmission of commands to ADB devices for specialized operations beyond standard event handling, such as configuring device-specific features. This procedure accepted parameters including a pointer to an optional data buffer (with the first byte indicating length and up to eight bytes of data), a completion routine executed upon command finish, and a 16-bit command number encoding the device address (bits 15-12), register select (bits 11-10), and operation type (e.g., Talk Register or Listen Register). Supporting APIs included CountADBs to determine the number of connected devices, GetIndADB and GetADBInfo to retrieve details like default addresses and handler IDs from the device table, and SetADBInfo to install custom device handlers or update data areas.[1][17] In classic Macintosh operating systems from System 6 to 9, ADB driver architecture relied on the Interrupt Manager for low-level processing, where the ADB Manager continuously polled devices at intervals of approximately 10 ms and invoked type-specific device handlers at interrupt time to interpret responses and post events to the Event Manager. Device handlers received parameters such as data pointers and command details, adhering to interrupt-level constraints to avoid blocking the system, while the ADB Manager maintained an internal device table initialized at startup or reset to track up to 16 addresses.[1][17][30] Early Mac OS X versions prior to 10.5 incorporated ADB support through IOKit on PowerPC hardware, where drivers like the Power Management Unit (PMU) managed enumeration and interrupt handling for legacy ADB devices, queuing commands and processing reads to integrate with the modern kernel framework.[37] Configuration and testing were handled via the ADB Manager's APIs, which supported address assignment by resolving conflicts through temporary allocations in the range $8 to $E during enumeration and provided routines for verifying device responses. Error handling addressed issues like bus timeouts or queue overflows with codes such as errADBOp (-1), prompting developers to implement retries in completion routines or buffer checks. These tools were integral to development from 1987 onward, enabling reliable setup without dedicated standalone utilities.[1][17] ADB remained primarily proprietary to Apple platforms, with limited cross-platform compatibility; emulators like SoftPC provided Macintosh users access to Windows environments but offered no native ADB extension to non-Apple systems.[38]

Supported Peripheral Devices

The Apple Desktop Bus (ADB) was designed to connect low-speed input peripherals to Macintosh and Apple IIGS computers, supporting up to 16 devices per bus through a daisy-chain topology.[1] Primary categories included encoded devices for text input, relative-position devices for pointing, and absolute-position devices for precise coordinate input, each assigned default addresses during enumeration.[1] These classifications ensured compatibility with human-interface hardware, drawing power from the +5 V bus line with a total limit of 500 mA across all devices.[8] Keyboards formed the core of ADB input devices, categorized as encoded devices with a default address of 2.[1] Apple's Standard Keyboard used handler ID 1, while the Extended Keyboard employed IDs 2 and 3 for enhanced functionality, consuming up to 100 mA and 85 mA respectively at maximum load.[1][8] Mice and trackballs operated as relative-position devices with default address 3, exemplified by the Apple Desktop Bus Mouse, which reported movement in counts per inch and typically drew lower power around 10 mA during operation.[1][8] Graphics tablets functioned as absolute-position devices with default address 4, enabling precise cursor control for design and illustration tasks.[1] Wacom produced several ADB-compatible models, such as the ArtZ series, integrating pressure-sensitive pens for professional graphics work.[6] Joysticks and gamepads also utilized ADB, often treated as relative-position or miscellaneous appliances (default address 7), with the Gravis GamePad providing multi-button controls for gaming on Macintosh systems.[8][39] Beyond basic input, ADB supported specialized peripherals like MIDI interfaces from Opcode Systems, which connected via the bus for music production and allowed daisy-chaining with other devices.[40] Trackpad modules in PowerBooks, such as the Alps Glidepoint, extended pointing capabilities externally or internally, emulating mouse input over ADB.[6] Barcode scanners, including models like the Unitech MS801-1, integrated as data transfer or miscellaneous devices for inventory applications.[41] Third-party developers expanded ADB's ecosystem, licensing handler IDs from Apple to ensure interoperability across over a hundred compatible products by the mid-1990s, including international variants like numeric keypads.[1]

Limitations and Criticisms

Performance Constraints

The Apple Desktop Bus (ADB) exhibited several inherent performance constraints that restricted its utility for data-intensive or real-time applications. Its bandwidth was fundamentally limited by the serial signaling protocol, which used a 100 μs bit cell duration to encode data bits via pulse-width modulation, yielding a theoretical maximum bit rate of 10 kbit/s.[3] However, protocol overhead from attention signals, synchronization pulses, and stop-to-start intervals reduced effective throughput to approximately 154 bytes per second (roughly 1.2 kbit/s), rendering it inadequate for tasks such as high-resolution video capture or substantial file transfers.[42] While standard operation is ~10 kbit/s, some third-party hardware supported higher rates up to 230 kbit/s.[4] Device addressing supported a maximum of 16 unique nodes on the shared bus, though Apple recommended limiting configurations to three devices to prevent signal degradation from cable capacitance and resistance.[42] This shared architecture, combined with the host's polling mechanism—typically cycling at around 10 ms per transaction—introduced latency that scaled with the number of devices; for a full complement of 16, worst-case response delays could approach 160 ms during enumeration or high-activity scenarios.[30] Power delivery over the bus was capped at a total of 500 mA across all connected devices, sourced from the host computer's +5 V supply, which often resulted in voltage brownouts when multiple peripherals drew current simultaneously (e.g., a keyboard at 100 mA alongside a trackball and tablet).[43] Unlike later standards such as USB, ADB lacked suspend or power management modes to mitigate these issues, exacerbating constraints in multi-device setups.[1] Scalability was further hampered by the absence of isochronous transfer support, as all communication relied on asynchronous host-initiated polling rather than guaranteed bandwidth allocation, making ADB unsuitable for real-time peripherals like audio interfaces or video digitizers that required consistent timing.[1] Protocol overhead, including service request assertions and inter-packet gaps, contributed to these delays without provisions for prioritization.[3]

Reliability and Maintenance Issues

The Mini-DIN connectors used for Apple Desktop Bus (ADB) connections are susceptible to mechanical wear over time, with typical durability ratings for such connectors ranging from 500 to 5,000 mating cycles depending on the specific design and manufacturing quality.[44][45] In portable systems like the 1990s PowerBooks, these ports were particularly vulnerable to pin bending during frequent insertions and removals, as well as oxidation from environmental exposure, leading to intermittent connectivity issues. The daisy-chain topology of ADB cables, which relies on sequential device connections, exacerbates these problems by concentrating stress on shared connectors. Cable degradation in ADB setups often stems from the daisy-chain configuration, making the bus vulnerable to electromagnetic interference (EMI) and short circuits if a single link fails. Apple recommended using shielded 4-conductor cables to mitigate EMI, but many third-party products omitted proper shielding, resulting in signal corruption and unreliable operation in noisy environments. Power-related failures were another common concern, as faulty devices could draw excessive current beyond the bus's 500 mA limit, potentially damaging the host port; early ADB designs lacked dedicated fuses, leaving the system reliant on inherent current limiting for protection. Diagnosing ADB issues presented significant challenges due to the absence of built-in bus-level self-testing hardware, requiring technicians to depend on software-based methods such as polling loops via the ADB Manager's functions like CountADBs and GetADBInfo to isolate faulty devices or address collisions.[1] Address collisions during initialization and buffer overflows from timing mismatches further complicated troubleshooting, often prolonging repair times as manual reinitialization and device enumeration were necessary.[1] While individual devices could perform self-tests using commands like Listen Register 3 (0xFF), this did not extend to comprehensive bus diagnostics, emphasizing the need for careful hardware maintenance to prevent cascading failures.[5]

Compatibility Challenges

The proprietary nature of Apple Desktop Bus (ADB) limited its interoperability with non-Apple systems, such as IBM PC-compatible PS/2 ports or Amiga serial interfaces, necessitating specialized adapters for cross-platform use. Unlike the more standardized PS/2 protocol, ADB employed a unique bit-serial multidrop topology that was incompatible without conversion hardware, such as PS/2-to-ADB adapters developed by third parties to enable inexpensive PC peripherals on Macintosh systems. Similarly, Amiga computers, which relied on DB-9 serial ports for input devices, required protocol translation adapters to interface with ADB keyboards or mice, further isolating ADB within the Apple ecosystem. Legacy support in operating systems like Linux and macOS became increasingly limited after 2007, with Linux kernel modules providing basic ADB functionality primarily for PowerPC Macintosh hardware but lacking comprehensive driver updates for modern distributions. Minor differences in signaling timing existed between early implementations on the Apple IIGS and later Macintosh systems, but these rarely caused significant compatibility issues, as the protocol remained consistent with a theoretical maximum of 125 kbit/s across variants, though practical speeds were ~10 kbit/s. These inconsistencies arose from subtle protocol evolutions in hardware controllers, requiring software workarounds or device-specific firmware updates to mitigate enumeration failures in rare cases. Hot-swapping ADB devices—inserting or removing them while the system was powered on—posed significant risks, including potential corruption of the bus enumeration process and hardware damage from voltage spikes or improper pin sequencing in the Mini-DIN-4 connector. Apple explicitly advised against hot-swapping, as the protocol's design assumed all devices were connected at boot time for initial addressing and synchronization, and mid-operation changes could disrupt the shared bus topology, often necessitating a full system reboot to restore functionality. In practice, users reported logic board failures or device inoperability following such attempts, underscoring the protocol's lack of built-in hot-plug safeguards. Following Apple's transition to USB in 1998, ADB devices faced end-of-life challenges, relying on bridge adapters like the Keyspan iMate or third-party USB-to-ADB converters to interface with modern systems, though native driver support was phased out starting with OS X 10.5 Leopard due to the end of PowerPC hardware support and USB standardization. These adapters emulated HID protocols to maintain compatibility, but their effectiveness diminished as Apple ceased updates for legacy IOKit families, leaving users dependent on community-maintained firmware for continued operation. The USB transition exacerbated these hurdles by rendering ADB peripherals obsolete without such intermediaries, limiting their viability in post-2000 environments.

Legacy

Patents and Intellectual Property

Apple maintained intellectual property rights over the Apple Desktop Bus (ADB) through a series of U.S. patents that covered core aspects of its design, including bus control mechanisms and interface implementations. One notable example is U.S. Patent 5,828,857 (issued October 27, 1998), which details an application-specific integrated circuit (ASIC) cell for an ADB bus controller featuring multiple registers to enable dynamic timing adjustments for data transmission and synchronization. This patent highlights Apple's focus on optimizing the serial protocol for reliable peripheral communication in low-speed environments.[36] To enforce its proprietary control, Apple required third-party developers and manufacturers to obtain licensing agreements for producing ADB-compatible hardware, such as chipsets and peripherals. These licenses granted access to the official Apple Desktop Bus Specification and ensured adherence to the protocol's electrical and logical standards. For instance, Synaptics Incorporated developed touchpad interfaces supporting the ADB protocol, as outlined in their technical documentation, which referenced Apple's specifications for integration with Macintosh systems. Such agreements facilitated limited third-party adoption while safeguarding Apple's IP.[6][46] The foundational ADB patents, originating from filings in the mid-1980s, expired between approximately 2005 and 2008 under the prevailing U.S. patent term rules—typically 17 years from the issue date for pre-1995 patents or 20 years from filing. This lapse removed legal barriers to independent implementations, paving the way for open-source emulations and hobbyist projects. Examples include the Adbuino, an Arduino-based converter that emulates ADB peripherals from USB inputs, and the Hootswitch, a Raspberry Pi Pico-driven switch for multiplexing ADB devices across multiple vintage Macintosh systems.[47][48] Throughout ADB's lifecycle, Apple encountered few significant intellectual property disputes or lawsuits related to the technology. In contrast to standards like USB, which spawned extensive litigation over bus architecture and protocols, ADB's niche application in Apple's ecosystem resulted in minimal conflicts, with no major court cases documented. Occasional reverse-engineering efforts occurred, particularly among peripheral vendors, but these did not escalate to formal legal challenges.[6]

Influence on Subsequent Technologies

The concepts central to Apple Desktop Bus (ADB), including simplified daisy-chaining, shared 5V power distribution, and device addressing through polling and enumeration, directly informed Apple's transition to USB in Macintosh systems. When the iMac G3 debuted in 1998, USB 1.1 supplanted ADB as the standard for low-speed peripherals like keyboards and mice, offering 12 Mbps bandwidth compared to ADB's 125 kbps maximum while preserving user-centric features such as bus-powered operation and hot-pluggable connectivity without system restarts. This evolution allowed Apple to maintain a seamless peripheral experience, with early USB implementations on Macs echoing ADB's emphasis on reducing cable clutter and dedicated ports.[49][4] Modern legacy support for ADB is facilitated by bidirectional USB adapters that emulate ADB peripherals as standard Human Interface Device (HID) inputs, enabling compatibility with contemporary macOS without requiring custom drivers or software modifications. For instance, the Wombat converter translates ADB signals from keyboards and mice into USB HID reports, supporting features like Macintosh-mode control-click emulation and functioning on systems running macOS Ventura or later via a simple USB connection. These adapters extend ADB's influence to iOS ecosystems, where HID protocols for Bluetooth and wired keyboards/mice standardize input handling in a manner that builds on ADB's model of lightweight, polled device communication for user input.[50][51] ADB's daisy-chain architecture, which permitted up to 16 low-power devices on a single bus, resonated in Apple's subsequent high-speed standards, notably FireWire (IEEE 1394), developed internally starting in the late 1980s to support peer-to-peer chaining of up to 63 devices for multimedia peripherals. This topology prioritized flexible expansion without host intervention, a principle refined from ADB's serial bus design to handle isochronous data streams in professional audio and video workflows.[14] ADB contributed to the Macintosh's reputation for an intuitive peripheral ecosystem, emphasizing ease of connection that simplified user interaction during the 1980s and 1990s, as reflected in developer recollections of the era's hardware innovations. By 2025, cultural interest persists among vintage computing enthusiasts, with online communities maintaining active inventories of rare ADB hardware—such as trackballs, joysticks, and third-party modems—and developing tools like ADB parsers for testing and restoration on emulated systems.[52][53]

References

  1. [PDF] ADB Manager - Apple Developer
  2. The First Expandable Macs: The Mac II and SE
  3. The iMac Cometh: Apple's new all-in-one revealed | Macworld
  4. Get on the Bus: Data Busses Used in Macs, 1984 to 2000
  5. [PDF] Apple - Desktop Bus (ADB ) - Bitsavers.org
  6. A brief history of Mac ports – low speed - The Eclectic Light Company
  7. Apple Desktop Bus - RetroTechCollection
  8. About the Apple Desktop Bus(IM: D) - Inside Macintosh
  9. apple macintosh - Will any serial mouse connect to Classic Macs?
  10. [PDF] Apple Desktop Bus (ADB): Specifications (12/94)
  11. When mice had balls: Remembering the Apple Desktop Bus Mouse
  12. Mouse History, 1978 to 1999 - Low End Mac
  13. Macintosh PowerBook 100: Technical Specifications - Apple Support
  14. Power Macintosh 6100/60: Technical Specifications - Apple Support
  15. The Legendary Apple Extended Keyboard - Low End Mac
  16. One cable to rule them all: a look at Apple's retired connectors ...
  17. 2-Button Kensington Mouse ADB - Low End Mac
  18. Advanced Gravis MouseStick - Macintosh Repository
  19. About the ADB Manager(IM: D) - Inside Macintosh
  20. Apple Desktop Bus keyboard A9M0330 658-4081
  21. Did Apple "jumpstart" the USB market? - Skeptics Stack Exchange
  22. Milestones:Universal Serial Bus (USB), 1996
  23. ATPM 5.10 - Review: iMate ADB-USB converter
  24. Power Mac G4 (AGP Graphics) - Technical Specifications
  25. None
  26. ADB Apple Desktop Bus - AllPinouts
  27. Power Macintosh G3 (Blue and White) - Technical Specifications
  28. Ports and Pinouts - Apple2.org
  29. [PDF] Guide to the Macintosh® Family Hardware Second Edition
  30. Apple Desktop Bus Protocol
  31. Apple I/O Notes - McOS Re
  32. Mac SE ADB Controller - 68kMLA
  33. Apple's ASIC's - AppleLogic
  34. [PDF] Apple Desktop Bus (ADB) Keyboard Microcontroller ERS
  35. Apple Desktop Bus (ADB) - Higher Intellect Vintage Wiki
  36. US5828857A - ASIC cell implementation of a bus controller with ...
  37. Handling Events - IOKit Fundamentals - Apple Developer
  38. SoftPC 3.1 with Windows - Macintosh Repository
  39. Gravis Mac GamePad - Gamepad | Overview, Specs, Details | SHI
  40. http://www.muzines.co.uk/articles/hands-on-apple-macintosh-computers/10521
  41. Workgroup Server 95: Technical Specifications - Apple Support
  42. [PDF] Apple ® Desktop Bus (ADB™)
  43. http://absurdengineering.org/library/MASTER%20Tech%20Info%20Library/Macintosh%20Hardware/Mac%20II%2C%20IIx%2C%20IIcx%2C%20IIci%2C%20IIsi%20&%20IIfx/Kybd&Apl%20Desktop%20Bus%20Info/TIL00902%20-%20Apple%20Desktop%20Bus%20(ADB
  44. Apple Desktop Bus · tmk/tmk_keyboard Wiki - GitHub
  45. Power Macintosh G3 (Blue and White) - Technical Specifications
  46. LN-0507 DIN Socket - Durable Mini-DIN Jack for High-Performance ...
  47. [PDF] Mini Din Connector
  48. [PDF] Synaptics TouchPad Interfacing Guide - Instructables
  49. akuker/adbuino: Arduino-based USB keyboard and Mouse to ADB ...
  50. Hootswitch, a (work-in-progress) Apple Desktop Bus switch | 68kMLA
  51. Apple Desktop Bus (ADB): The Legacy of Apple's Proprietary Interface
  52. Wombat ADB-USB Input Converter - Big Mess o' Wires
  53. USB Device Overview - Apple Developer
  54. Early Macintosh Folklore - Macworld
  55. Calling all owners of rare ADB devices! - 68kMLA
User Avatar
No comments yet.