""""'' wr·,.,,, ,• 062-0267 Specltlcation, Front Desk Bus Revision B Proposal M.R. Ctark UNRELEASED I CONFIDENTIAL INTRODUCTION The Front Desk Bus is a method and protocol for interconnecting computers with human input and other devices. This specification covers the l'hyslca1,Datallnk, and Network 1ayers of the Front Desk Bus. In this specification the computer is referred to as the host. Peripherals connected to the bus are referred to as devices. The host is the undisputed bus master. It controls the flow of data by issuing Commands and it is the only device permitted to issue them. Talk is the command used for a data transaction from a device to the host. Listen is the command used for a data Lransa<.;Lluu frow lhc hu~l lu ts elev i\;~. PHYSICAL LAYER Interconnection: All devices will communicate with the host via a 3.5 mm mini phone jack, as specified in Apple Specification,T.B.D., with the following connector assignments; Tip-Power, Riu~·Data, SlceV'c-Powcr Return They will be interconnected with three conductor cables terminated with 3.5 mm mini phono plugs, as specified in Apple Specification, T.B.D. Signal Levels: Input Signals: Data: The data line will be pulled up by the host with a 10 K Ohm resistor to power. A "High" is 2.4 V minimum . A "Zero" is 0.8 V maximum . Power: The Host will supply 5.0 Vdc + 10% to the devices. The power line will be current limited by the host to prevent systems damage in the event of a Power to Power Return short. Output Signals: A "High" is the voltage on the Tip connection. Each device in the inactive or "High" state must source less than SO uA. A "Zero" is 0.4 V maximum at 1.6 mA minimum. Devices will provide current limiting on the data line to prevent damage to the device in the event of a Power to Data line short. Page 1 of 12 © Apple Computer Inc., 1985 June 13,1985 062·0267 Specification, Front Desk Bus Revision B Proposal M.R. Ctark UNRELEASED I CONFIDENTIAL Modulation: There are three f onns of modulation on the bus, Normal modulation which transmits commands and data, Hi&h Speed modulation which transmits data, and Signals which broadcast global messages such as s~rvk~ Rcquc~l auu Rt:set. Normal Modulation: An RZ code for modulation has been adopted for the Front Desk Bus. Each bit ce 11 boundary is signified by a falling edge on the bus. The period of each bit cell is the time between two falling edges on the bus. The time for a normal modulation bit cell, Teye' is 100 usec + 30%. All devices must support nonnal modulation for data transactions. The data is encoded as the ratio of low to high time of each bit cell. Thus a "O" is ~ncuc.le<l ct~ a hit cell in which thP. lnw timP. i~ 2reatcr thPtn th~ hieh t1me.. C.onver.~ely. a "l" is encoded as a bit cell in which the low time is kss than the high time. A Start is defined as a" l ".A Stop is similar to a "O", in that it has a low time of TO , but it does not have another negative edge to define the bit cell time. It is used to s…

To: Bob Bailey Gary Butts - APG Date: Sept. 6, 1984 Dave Christensen - APG Mike Clark - APG Burrell Smith From: Peter Ashkin Subj: Front Desk Bus - An Alternative Proposal - REV 1.2 To make the "Front Desk Bus" a more fleiible and powerful interface, I believe that it should have the following properties: 1. The bus shall be bidirectional. [An input only bus is too restrictive.] 2. Each device on the.bus has a .un~que address... For. t>ractical purposed the address.range should be 0 - 15. Some of these addresses may be reserved for broadcasting universal messages. [This seems like a sane number of devices, particularly since there e1ists today only three devices; keyboard, keypad and mouse.) 3. All command tr11ns11ctio11s shall be fired Jen11h (recommended to be 8 bits). All d11t11 tr1111sactio11s shall be fired length (recommended 10 be 16 bits). [This facilitates the decoding of commands by devices of limited intelligence.) 4. The host shall be the undisputed bus master. /This removes any questions of who's controlling the bus./ 5. There shall be a limited number of commands. Commands should be broken into two grO\IPS, basic commands (TALI: and LISTBN) which all devices on the bus shall understand; and advanced commands which only intelligent devices (as appropriate) should understand. (This makes the command interpreter, be it hardware or software, simple,. It also allows more compleI devices to used some of the "fancier" features of the bus.) 6. There shall be only one active talker on the bus at any time, this may be the host or a remote device. [When a new device is commanded to TALI:, an old device that was addressed to T AL[ is "untalked".] Front Desk Bus September 6, 1984 7. Bus must accept devices that talk at different speeds. The host, at a minimum, must be able to listen at various speeds. (This implies that the data on the bus must be "self-clocked". By not rigidly fixing the speed of transmission, the bus does not need to be crystal (etc.) controlled.] 8. There can be multiple active listeners on the bus. (LISTEN commands are additive, as needed, multiple devices can be addressed to listen. To remove a selected listener, a special "unlisten" command is sent to globally deselect all listeners.) 9. An interrupt mechanism must be available which circumvents the needs to poll devices that need service. [Since the bus is relatively slow, the interrupt latency time in a polled environment is long. The ability to interrupt the master for service is important.] 10. There shall exist a mechanism that sends a unique message that puts all devices on the bus into the command (reset) mode.. .{This is important if for some r~ason.the bus gets "hung".) ... 11. There should be a minimum number of "time-outs" needed on the bus. The only needed time out should be to time out a non-responsive talker. (Timers are ugly, but waiting for a dead device is uglier.] 12. Hand-off of the bus from the master to a talker and /Jack again must be…

I ~' - --~-" To: Bob-Bailey Gary Butts - APG Dave Christensen - APG Mike Clark - - APG Burrell Smith From: Peter Ashkin Subj: Front Desk Bus - An Alternative Proposal Date: August 20, 1984 To make the "Front Desk Bus" a more fleiible and powerful interface, I believe that it should have the following properties: The bus shall be bidirectional. [An input only bus is too 1. restrictive.) 2. Each device on the bus has a unique address. For practical purposed the address range should be 0 - 15. Some of these addresses may be reserved for broadcasting universal messages. (This seems like a sane number of devices, particularly since there eiists today only three devices; keyboard, keypad and mouse.) 3. . All messages on the bus shall be filed length. (This facilitates the decoding of commands by devices of limited intelligence.) 4. Only one rdevice at a time can be "bus master". This ability can be relinquished, and another device can assume bus mastership. (Usually the host will be the bus master, but the interface should not preclude a future device which may master the bus. Also, by having an undisputed bus master, there are no bus contention problems.) 5. There shall be a limited number of commands. Commands should be broken into two groups, basic commands (T AL~ and LISTBN) which all devices on the bus shall understand; and advanced commands which only intelligent devices (as appropriate) should understand. (This makes the command interpreter, be it hardware or software, simple. It also allows more comple1 devices to used some of the "fancier" teatures of the bus.) There shall be only one active talker on the bus at any time, this may be the host or a remote device. (When a new device is commanded to T ALl, an old device that was addressed to T ALl is "untalked".) 6. FrontJ&s_k_B_u_s__ ~,-- __ _ Auaus.t 24. J 984 7. Bus must accept devices that talk at different speeds. The host, -at-a· minimum, must be able to listen at various speeds. (This implies that the data on the bus must be se1f-clocked... By not rigidly filing the speed of transmission, the bus does not need to be crystal (etc.) controlled.] 11 8. There can be multiple active listeners on the bus. (Listen commands are additive, as needed, multiple devices can be addressed to listen. To remove a selected listener, a special Unlisten" command is sent to globally deselect all listeners.) 11 9. An interrupt mechanism must be available which circumvents the needs to poll devices that need service. (Since the bus is relatively slow, the interrupt latency time in a polled environment is long. The ability to interrupt the master for service is important.) 10. There shall eiist a mechanism that sends a unique message that puts all devices on the bus into the command (reset) mode. (This is important if for some reason the bus gets hung".) 11 11. There should be a minimum number of "time-outs" needed on the bus. The only needed time out should be to time out a non-responsi…

•• , I To: Bob Belleville Date: October 29, 1984 Bt11 Bu11 -c;ary· Butts Mike Clark Jerome Coonen Dan Hil1man Larry Kenyon Burre11 Smith ?et, From: Peter Ashkln Subj: Front Desk Bus - rev 3.1 Enclosed is the latest version of the Front Desk Bus (rev 3.1) specification. It is divided into three sections: Preface - which contains the 12 fundamental properties of the bus; Main - which contains the commands which devices on the bus must execute and deta11s on the timing and the moduJat ion of the bus; and the Appendix - which describes the interface between the FOB "modem· and the Macintosh digital subsystem. There are some things this specification does not contain, there is no description of the connectors nor is there any mention of how the bus should be "used". Please read this over and feel free to make any changes or improvements. I'm interested in a robust (and useful) spe~ification. 1911 contact each of you the first week in_·November to discuss your comments. Thanksm •• rtrrae - rroat Int .. I•• To mate the "Front Delk Bua" 1 more ne1ible and powerful interface, it should have the f ollowina properties: l. The bus shall be bidirectional. (An input only bus is too restrictive.) 2. Bach device on the bus has a unique address. For practical purposed the address range should be 0 - 1.f. Some of these addresses may be reserved for broadcasting universal messages. (This seems lite a sane number of devices, particularly since there eiists today only three devices; keyboard, keypad and mouse.) 3. All command transactions shall be eight bits Iona. All data transactions shall be 16 bits long. (This facilitates the decoding of commands by devices of limited intelligence.) The host shall be the undisputed bus master. (This removes any question of who's controlling the bus.) 4. 5. There shall be a limited number of commands. Commands should be broken into two groups, basic commands (TALI: and LISTBN) which all devices on the bus shall understand; and advanced commands which only intelligent devices (as appropriate) should understand. (This makes the command interpreter, be it hardware or software, simple. It also allows more comple1 devices to used some of the fancier" features of the bus.) · 0 6. There shall be only one active talker on the bus at any time, this may be the host or an addressed device. (A device addressed to TALI: with data to send untalts itself after it sends its 16 bits of data or if it has no data to send "untalts" itself immediately and allows the bus to time-out.I 0 0 The bus protocol must accept devices that talk at different speeds. The host, at a minimum, must be able to listen at various speeds. (This implies that the data on the bus must be self-clocked". By not rigidly filing the speed of transmission, the bus does not need to be crystal (etc.) controlled.) 7. 0 There shall be only one active listener on the bus at any time, this may be the host or an addressed device. (A device addressed to LISTBN…

To: Bob Bailey Date: Sept. 26, 198-4 Gary Butts - APG Dave Christensen - APG Mike Clark - APG Burrell Smith From: Peter Ashkin Subj: Front Desk Bus - Rev 2.1 To make the "Front Desk Bus" a more flexible and powerful interface, I believe that it should have the follo"'1ing properties: 1. restrictive .J The bus shall be bidirectional. [An input only bus is too 2. Each device on the bus has a unique address. For practical purposed the address range should be o - 14. Some or these addresses may be reserved for broadcasting universal messages. [This seems like a sane number or devices, particularly since there exists today only three devices; keyboard, keypad and mouse .J 3. All command transactions shall be eight bits long. All data transactions shall be 16 bits long. [This facilitates the decoding of commands by devices. of limited iiltelligence.J 4. The host shall be the undisputed bus master. [This removes any question of who's controlling the bus.J 5. There shall be a limited number of commands. Commands should be broken int.o two groups, basic commands (TALK and LI STIR) Which all devices on the bus shall understand; and advanced commands vvhich only intelligent devices (as appropriate) should understand. [This makes the command interpreter, be it hardv.1are or soft"'1'8.re, Simple. It also allo'NS more complex devices to used some of tl:te "fancier" features of the bus.] There shall be only one active talker on the bus at any time, this may be the host or an addressed device. [A device addressed to TALI ¥\Tith data to send "untalks" itself after it sends its 16 bits of data or if it has no data to send "untalks" itself immediately and allo'\AIS the bus to time-out.] 6. Front Desk Bus September 26, 1984 7. The bus prot:ocol must accept devices that talk at different speeds. The host, at a minimum, must be able to listen at various speeds. (This implies that the data on the bus must be "self-clocked". By not rigidly fixing the speed of transmission. the bus does not need to be crystal (etc.) controlled.] There shall be only one active listener on the bus at any time, this may be tlle host or an addressed device. [A device addressed to LI STIR "unlistens" itself-after it receives 16 bits of data or if it receives a new command before receiving 16 bits of data.] 8. 9. An interrupt mechanism must be available which circumvents the needs to poll devices that need service. [Since the bus is relatively slow. tlle interrupt latency time in a polled environment is long. The ability to interrupt the master for service is important.] 10. There shall exist a mechanism that sends a unique signal that puts all devices on the bus into the command (reset) mode. [This is important if for some reason the bus gets "hung".) 11. There should be a minimum number of "time-outs" needed on the bus. The only needed time out should be to time out a non-responsive talker. [Timers are ugly, but "'1aiting for a dead device is uglier. The length of this time-…