Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Apple Desktop Bus
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Design == === Physical === 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|date=February 2021}} 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 signal|self-clocking]] by sending a 0 as low for 65 microseconds and high for 35 ΞΌs, while sending a 1 uses the opposite timing.<ref name="macintosh-hardware">{{cite book|url=https://archive.org/details/apple-guide-macintosh-family-hardware/page/n357/mode/2up?view=theater|title="Guide to Macintosh Family Hardware, second edition"|page=317-320|isbn=0-201-52405-8|date=1990|author=Apple Computer, Inc}}</ref> It is a multi-drop [[open collector]] design with pull-ups to 5 V and uses [[Carrier-sense multiple access with collision detection|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.<ref name="macintosh-hardware"/> 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]] [[Application-specific integrated circuit|ASIC]] as well as associated [[#Patents|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 [[PIC microcontrollers|Microchip]] PIC16CR54 microcontroller. [[File:Apple Desktop Bus Microchip.jpg|thumb|ADB is implemented in an early Microchip PIC microcontroller in the Macintosh SE.]] === Communication === 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: * <code>talk</code> - tells the selected device to send the contents of a register to the computer * <code>listen</code> - tells the device to set the register to the following value * <code>flush</code> - clear the contents of a selected register * <code>reset</code> - 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: <code>1101 11 00</code> 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 <code>talk</code> 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.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)