Skip to content
RetrogamingDeep Dive Published Updated 7 min readViews unavailable

Atari 8-Bit SIO: Command Frames, Checksums, and Peripheral Timeouts

Follow Atari 8-bit SIO commands from a five-byte request through checksummed data and completion, with device-specific timing and retry boundaries.

An Atari 8-bit serial peripheral operation is a small protocol exchange, not simply a byte stream sent to a disk drive. The computer identifies a device, sends a command and two auxiliary bytes, checks the request, and then follows one of several data-transfer paths. Timing matters as much as the bytes: a late retry can turn an uncertain write into a repeated operation.

This guide focuses on the command/data lifecycle described in Atari’s system references. Device command meanings remain device-specific, and Atari-compatible peripherals are not interchangeable merely because they share the SIO connector. The examples below use diskette commands as illustrations, not as a complete command set for every printer, modem, cassette interface, or modern SIO adapter.

Start with the five-byte command frame

The computer originates SIO bus operations. A command frame consists of five bytes sent while the command line is asserted:

Byte Meaning
1 Device ID
2 Device-specific command
3 Auxiliary byte 1
4 Auxiliary byte 2
5 Checksum of the preceding four bytes

Atari’s technical reference describes the checksum as the arithmetic sum of the first four bytes with each carry folded back into the low byte. This is an end-around-carry checksum, not a CRC and not a two’s-complement checksum chosen to make the complete frame sum to zero. For example, calculate it by adding each byte to an 8-bit accumulator and adding any carry-out back into that accumulator. A device should validate the addressed ID and frame checksum before acting on the command; an emulator or bus logger should preserve the raw five bytes as well as the decoded fields.

For a conventional diskette drive, IDs $31 through $34 identify D1: through D4:. In the diskette command table, $52 is READ SECTOR, $50 is PUT SECTOR without verify, $57 is PUT SECTOR with verify, and $53 requests status. For sector operations, the auxiliary pair carries the sector number low byte first, then high byte. These values are examples from the documented diskette handler; another device can assign different meanings to the same command or auxiliary bytes.

The device-control block is the software-side source of the command fields. For diagnosis, retain both the requested operation and actual wire frame: a correct DCB can still fail during framing, device selection, command validation, or response timing.

Acknowledge, data, and completion are separate states

Do not collapse SIO’s one-byte responses into a single success/failure flag. Atari’s system-level SIO response vocabulary includes acknowledge ($41, ASCII A) and negative acknowledge ($4E, N), but the exact rejection and timeout behavior must be taken from the relevant OS and device documentation. Do not generalize one drive’s malformed-frame behavior to every peripheral, and do not interpret silence as evidence that a command succeeded.

After command acknowledgement, the transfer direction determines what happens next:

  • For input, the peripheral sends a data frame, followed by its checksum. The computer checks it before accepting the bytes.
  • For output, the computer sends a data frame and checksum after the command ACK. The peripheral responds to that data frame, then reports whether the requested operation completed.
  • For an immediate command, neither side transfers a data frame. The peripheral still reports an operation result where that command’s contract requires one.

$43 (C) is COMPLETE and $45 (E) is ERROR in the general SIO response vocabulary. A data-frame ACK and the final completion response describe different milestones: “the frame arrived” does not necessarily mean “the drive finished writing or verifying the sector.” A tool that records only the final status loses the distinction between a command rejected before data, a bad data checksum, and a device error after a syntactically valid transfer.

The checksum on the data frame is also distinct from the command-frame checksum. Validate the exact number of bytes expected by the device command and the trailing checksum before handing the payload to a sector buffer or application. Do not assume every peripheral uses a 128-byte payload: the standard interface is shared by devices with different transfer sizes and command rules. The diskette handler’s 128-byte sector description is not a universal SIO maximum.

Timeouts and retries belong to the operation contract

SIO’s frame sequence gives an implementer useful response boundaries, but it does not make every device command finish in one fixed interval. A status request, a sector write, a verify-after-write, and a format operation have different work to do. The host’s operating-system SIO routine uses retry and wait policy; a device’s firmware may also have command-specific delays. A modern interface that adds USB, network, or storage emulation layers introduces additional latency that the original bus model did not describe.

Treat a timeout as “the expected next protocol event was not observed before this caller’s deadline,” not as a protocol byte. Preserve which state expired: no command ACK, no data frame, no data ACK, or no COMPLETE/ERROR. That phase-specific diagnostic tells you whether to inspect device selection, transfer direction, checksum, or backend operation. A diagnostic log should include device ID, command, auxiliary bytes, expected direction and length, elapsed time, retry count, and the last response byte, without dumping private payload data unnecessarily.

Retries need command-aware semantics. Reissuing a READ SECTOR after a lost response is generally different from repeating a format command or a write to a device that performs additional side effects. Sector writes can often be made repeatable when the retried command and payload are identical, but that should be a property of the device implementation, not an assumption made by the bus layer. If a timeout happens after the peripheral committed the operation but before the computer received COMPLETE, the caller cannot infer whether the side effect occurred. Keep that uncertainty visible rather than reporting “failed” as if the device certainly did nothing.

Avoid one global short timeout for every SIO command. Set deadlines from the supported device behavior, allow longer operations to have longer bounds, and make retry counts explicit in the emulated OS or adapter configuration. When a device is absent, return or preserve the documented no-response behavior for that model; do not invent a success ACK to make software progress. For a present device, represent rejection only as documented by that device and OS combination, keeping a reported NAK distinct from transport silence.

A practical emulator and hardware test matrix

For a disk image or physical drive, test the protocol with a known-good, disposable medium or image and keep a separate unmodified copy. Capture command/data/status bytes around these cases:

  1. A valid status request, including its five-byte frame checksum and final response.
  2. A valid sector read with a correct data checksum, then a deliberately corrupted data checksum.
  3. A write whose data frame is acknowledged, followed by successful completion and by a device-reported error.
  4. An unsupported command, a wrong device ID, and a command with a corrupted command checksum.
  5. A peripheral that is disconnected, one that responds after the configured deadline, and one that acknowledges but never completes.
  6. A retry after a lost response, verifying whether the underlying operation is safely repeatable.

The result should be a state trace, not just a screenshot or “disk mounted” message. A useful trace labels each byte by phase, gives elapsed time from the preceding transition, and records the exact device/OS implementation. In a hardware capture, identify the SIO command and data phases from the relevant signal lines; in an emulator, log protocol states where the emulated OS and virtual device exchange data. Keep those evidence types separate: an emulator’s behavior confirms that emulator revision, not every physical drive’s timing.

Atari’s references establish the common frame layout and response vocabulary, while the device table defines the operation-specific payload. The Atari800 project is a useful implementation comparison, but it is not a replacement for the original bus documentation. No physical Atari or SIO peripheral was exercised for this draft, so the timeout test matrix is a recommended validation procedure, not a report of measured timings.

Related:

Sources:

Comments