Front Desk Bus An Alternative Proposal Rev 1.2

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…