The Serial Input/Output system, universally known as SIO, was a proprietary peripheral bus and related software protocol stacks used on the Atari 8-bit family to provide most input/output duties for those computers. Unlike most I/O systems of the era, such as RS-232, SIO included a lightweight protocol that allowed multiple devices to be attached to a single daisy-chained port that supported dozens of devices. It also supported plug-and-play operations. SIO's designer, Joe Decuir, credits his work on the system as the basis of USB.
SIO was developed in order to allow expansion without using internal card slots as in the Apple II, due to problems with the FCC over radio interference. This required it to be fairly flexible in terms of device support. Devices that used the SIO interface included printers, floppy disk drives, cassette decks, modems and expansion boxes. Some devices had ROM based drivers that were copied to the host computer when booted allowing new devices to be supported without native support built into the computer itself.
SIO required logic in the peripherals to support the protocols, and in some cases a significant amount of processing power was required - the Atari 810 floppy disk drive included a MOS Technology 6507 for instance. Additionally, the large custom connector was expensive. These drove up costs of the SIO system, and Decuir blames this for "sinking the system".[1][2] There were unsuccessful efforts to lower the cost of the system during the 8-bits' history.
The name "SIO" properly refers only to the sections of the operating system that handled the data exchange, in Atari documentation the bus itself is simply the "serial bus" or "interface bus", although this is also sometimes referred to as SIO.[3] In common usage, SIO refers to the entire system from the operating system to the bus and even the physical connectors.
History
FCC problem
The SIO system ultimately owes its existence to the FCC's rules on the allowable amount of RF interference that could leak from any device that directly generated analog television signals. These rules demanded very low amounts of leakage and had to pass an extensive testing suite. These rules were undergoing revisions during the period when Atari's Grass Valley group was designing the Colleen machine that would become the Atari 800.[4]
The Apple II, one of the few pre-built machines that connected to a television in that era, had avoided this problem by not including the RF modulator in the computer. Instead, Apple arranged a deal with a local electronics company, M&R Enterprises, to sell plug-in modulators under the name Sup'R'Mod. This meant the Apple did not, technically, generate television signals and did not have to undergo FCC testing. One of Atari's major vendors, Sears, felt this was not a suitable solution for their off-the-shelf sales, so to meet the interference requirements they encased the entire system in a cast-aluminum block 2 mm thick.[4]
Colleen was originally intended to be a game console, the successor to the Atari 2600. The success of the Apple II led to the system being repositioned as a home computer, and this market required peripheral devices. On machines like the Apple II, peripherals were supported by placing an adapter card in one of the machine's internal card slots, running a cable through a hole in the case, and connecting the device to that cable. A hole large enough for such a cable would mean Colleen would fail the RF tests, which presented a serious problem. Additionally, convection cooling the cards would be very difficult.[4]
TI diversion
During a visit in early 1978, a Texas Instruments (TI) salesman demonstrated a system consisting of a fibre optic cable with transceivers molded into both ends. Joe Decuir suggested they could use this to send the video signal to an external RF modulator, which would be as simple to use as the coaxial cable one needed to run the signal to the television anyway. Now the computer could have normal slots; like the Apple II, the RF portion would be entirely external and could be tested on its own separately from the computer.[4]
When Decuir explained his concept, the salesman's "eyes almost popped out."[4] Unknown to the Grass Valley team, TI was at that time in the midst of developing the TI-99/4 and was facing the same problem with RF output. When Decuir later explained the idea to his boss, Wade Tuma, Tuma replied that "No, the FCC would never let us get away with that stunt."[4] This proved to be true; TI used Decuir's idea, and when they took it to the FCC in 1979, they rejected it out of hand. TI had to redesign their system, and the resulting delay meant the Atari's reached the market first.[4]
SIO
With this path to allowing card slots stymied, Decuir returned to the problem of providing expansion through an external system of some sort.[4]
By this time, considerable work had been carried out on using the Atari's POKEY chip to run a cassette deck by directly outputting sounds that would be recorded to the tape. It was realized that, with suitable modifications, the POKEY could bypass digital-to-analog conversion hardware and drive TTL output directly. To produce a TTL digital bus, the SIO system used two of the POKEY's four sound channels to produce steady tones that represented clock signals of a given frequency. A single-byte buffer was used to send and receive data; every time the clock signal toggled, one bit from the buffer would be read or written. When all eight bits were read or written, the system generated an interrupt that triggered the operating system to read or write more data.[5]
Unlike a cassette interface, where only a single device would normally be used, an external expansion port would need to be able to support more than one device. To support this, a simple protocol was developed and several new pins added to the original simple cassette port. Most important among these was the COMMAND pin, which triggered the devices to listen for a 5-byte message that activated one of the devices on the bus and asked it for data (or sent it commands).[6] They also added the PROCEED and INTERRUPT pins which could be used by the devices to set bits in control registers in the host, but these were not used in the deployed system. Likewise, the timing signals generated by the POKEY were sent on the CLOCKOUT and CLOCKIN pins, although the asynchronous protocol did not use these.[7]
Description
Hardware
The SIO connector used sprung metal leaves to make a firm connection to the pins in the devices. The slots cut into the connector give the leaves room to move.The Atari 850 provided Centronics printer and RS-232 serial ports to connect to 3rd party devices. Typical of SIO devices, it has both in and out ports to allow daisy chaining.
The SIO bus was implemented using a custom 13-pin D-connector arrangement (although not D-subminiature) with the male connectors on the devices and the female connectors on either end of the cables.[8] The connectors were physically robust to allow repeated use, with very strong pins in the device socket and sprung connectors in the cables, as opposed to friction fit as in a typical D-connector. Most devices had in and out ports to allow daisy chaining peripherals, although the Atari 410 Program Recorder had to be placed at the end of the chain and thus did not include an out port.
Communications
SIO was controlled by the Atari's POKEY chip, which included a number of general purpose timers. Four of these allowed fine control over the timing rates, and were intended to be used for sound output by connecting them to a digital-to-analog converter (D-to-A) and then mixing them into the television signal before entering the RF modulator. These were re-purposed as the basis of the SIO system, used as clocks in some modes, or to produce the output signals directly in others.
The system included a single "shift register" that was used to semi-automate most data transfers. This consisted of a single 8-bit value, LSB first,[9] that was used to buffer reads and writes. The user accesses these through two memory locations known as SEROUT for writing and SERIN for reading. These were "shadow registers", locations in the RAM that mirrored registers in the various support chips like POKEY. The data bits were framed with a single zero start bit and a single one stop bit, and no parity was used.[9]
To write data in synchronous mode, the POKEY's main timer channels were set to an appropriate clock rate, say 9600 bit/s. Any data written to the SEROUT register was then sent one bit at a time every time the signal went high. It was timed so the signal returned low in the middle of the bit. When all 10 bits (including the start and stop) had been sent, POKEY sent a maskable interrupt to the CPU to indicate it was ready for another byte. On reading, if another byte of data was received before the SERIN was read, the 3rd bit of the SKSTAT was set to true to indicate the overflow. Individual bits being read were also sent to the 4th bit of SKSTAT as they arrived, allowing direct reading of the data without waiting for the framing to complete.
The system officially supported speeds up to 19,200 bit/s, but this rate was chosen only because the Atari engineer's protocol analyzer topped out at that speed. The system was actually capable of much higher performance. A number of 3rd party devices, especially floppy drives, used custom hardware and drivers to greatly increase the transmission speeds to as much as 72,000 bit/s.
Although the system had CLOCKOUT and CLOCKIN pins that could, in theory, be used for synchronous communications, in practice only the asynchronous system was used. In this case, a base speed was set in as above in the POKEY, which would follow changes of up to 5% from this base rate. This made it much easier to work with real devices where mechanical or electrical issues caused the slight variation in the rates over time. One example was the cassette deck, where tape stretch could alter the speed, another is a modem, there the remote system may not be exactly clocked to a given speed.
Device control
The SIO system allowed devices to be daisy chained, and thus required some way of identifying that information on the various data pins was intended for a specific device on the chain. This was accomplished with the COMMAND pin.[9]
The COMMAND pin was normally held high,[8] and when it was pulled low, devices on the bus were required to listen for a "command frame". This consisted of a 5-byte packet; the first byte was the device ID, the second was a device-specific command number, and then two auxiliary bytes of data that could be used by the driver for any purpose. These four were followed by a checksum byte.[6] The COMMAND pin went high again when the frame was complete.[10]
On reception of the packet, the device specified in the first byte was expected to reply. This consisted of a single byte containing an ASCII character, "A" for Acknowledge if the packet was properly decoded and the checksum matched, "N" otherwise. For commands that exchanged data, the command frame would be followed by a "data frame" from or to the selected device. This frame would then be acknowledged by the receiver with a "C" for Complete or "E" for error.[11] Since every packet of 128 data bytes required another command frame before the next could be sent, throughput was affected by latency issues; the Atari 810 disk drive normally used a 19,200 bit/s speed, but was limited to about 6,000 bit/s as a result of the overhead.[12]
Devices were enumerated mechanically, typically using small DIP switches.[13] Each class of device was given a different set of 16 potential numbers based on hexadecimal numbers, the $30 range for disk drives and $40 for printers, for instance. However, each driver could support as many or as few devices as it wanted; the Atari 820 printer driver supported only a single printer numbered $40,[14] while the disk drivers could support four drives numbered $31 to $34.[15]
Cassette use
The original 410 was replaced by the much smaller 1010 during the XL era.
Design of what became the SIO had started as a system for interfacing to cassette recorders using the sound hardware to generate the appropriate tones. This capability was retained in the production versions, allowing the Atari 410 and its successors to be relatively simple devices.
When set to operate the cassette, the outputs from channel 1 and 2 of the POKEY were sent to the DATAOUT rather than the clock pins. The two channels were set to produce tones that were safe to record on the tape, 3995 Hz for a zero was in POKEY channel 2 and 5326 Hz for a one was in channel 1. In this mode, when the POKEY read bits from the SERIN, any 1's resulted in channel 1 playing into the data pin, and 0's played channel 2. In this fashion, a byte of data was converted into tones on the tape. Reading, however, used a different system, as there was no A-to-D converter in the computer. Instead, the cassette decks included two narrow-band filters tuned to the two frequencies. During a read, the output of one or the other of these filters would be asserted as the bits were read off the tape. These were sent as digital data back to the host computer.[16]
Because the tape was subject to stretching and other mechanical problems that could speed or slow transport across the heads, the system used asynchronous reads and writes. Data was written in blocks of 132 bytes per record, with the first two bytes being the bit pattern "01010101 01010101". An inter-record gap between the blocks with no tones allowed the operating system to know when a new record was starting by looking for the leading zero. It then rapidly read the port and timed the transitions of the timing bits from 0 to 1 and back to determine the precise data rate. The next byte was a control byte specifying if this was a normal record of 128 data bytes, a short block, or an end-of-file. Up to 128 bytes of data followed, itself followed by a checksum byte, including everything before the checksum.[16]
The operation was further controlled by the MOTOR pin in the SIO port, dedicated to this purpose. When this pin was low, the motor in the deck was turned off. This allowed the user to press play or play and record without the tape beginning to move. When the appropriate command was entered on the computer, MOTOR would be asserted and the cassette would begin to turn.[16]
Another dedicated pin was the AUDIOIN, which was connected directly to the sound output circuits between the POKEY's D-to-A converters and the final output so that any signal on the pin mixed with the sound from the POKEY (if any) and was then sent to the television speaker. This was connected to the left sound channel in the cassette, while the right channel was connected to the data pins. This allowed users to record normal sounds on the left channel and then have them play through the television. This was often combined with direct motor control to produce interactive language learning tapes and similar programs. Some software companies would record sounds or music on this channel to make the loading process more enjoyable.[17]
.jpg)
