Skip to content
RetrogamingDeep Dive Published Updated 5 min readViews unavailable

Commodore 64 Serial Bus: ATN, TALK/LISTEN, and Byte Handshakes

Trace the C64's serial-bus roles, ATN address phase, CIA signal paths, byte handshake, and practical timeout diagnostics from Commodore manuals.

The Commodore 64’s peripheral connector carries more than a stream of bytes. Its serial bus is a controller-managed protocol for selecting devices, assigning who talks and who listens, and pacing transfers with clock and data signals. That distinction matters when diagnosing a disk drive that appears connected but never answers, building an adapter, or reading a logic-analyzer trace.

The Commodore 64 Programmer’s Reference Guide describes a daisy-chain bus that can connect several devices. It separates three roles: the C64 is the controller, while a device can be a talker, a listener, or both. The computer may talk to a printer or listen to a disk drive, but only the C64 controls the bus. Multiple devices may listen to one talker, while two simultaneous talkers would collide. [1]

Control is not the same as data direction

Treat CONTROL, TALK, and LISTEN as distinct protocol roles rather than names for three electrical wires. CONTROL decides which participant is addressed and when a transfer proceeds. TALK identifies the participant that supplies data. LISTEN identifies one or more recipients. For example, when the C64 reads from a disk drive, the C64 remains the controller while the drive becomes the talker and the computer listens. When printing, the data direction is reversed without transferring bus control to the printer. [1]

This separation is a useful first diagnostic. If the controller has selected the wrong direction, valid clock transitions do not make the payload meaningful. If two devices believe they are the talker, the symptom may look like corrupted data even though the fault is in device selection rather than byte timing.

ATN begins a device-selection phase

The guide says that pulling SERIAL ATN low starts a command sequence. All attached devices then listen for the address transmitted by the C64. The computer uses the address to route subsequent bus operations; its manual gives the address range as 4 through 31. The addressed device is expected to respond within a preset interval. If it does not, the C64 treats it as absent and reports an error through its status word. [1]

Phase What the controller does What a trace should tell you
Attention Asserts ATN to begin a command sequence Did the bus enter the command phase?
Address and command Sends the device address and directs a device to TALK or LISTEN Did the intended device acknowledge selection?
Data Coordinates the selected talker and listener or listeners Which side is driving data, and is the listener accepting it?
Completion or timeout Ends the operation or reports a missing response Did the device answer within the documented response window?

The table is a protocol-level reading aid, not a claim that every peripheral implements identical command semantics. The device’s own firmware determines what a selected command means. The Programmer’s Reference Guide’s serial timing table lists a required ATN response with a maximum of 1,000 microseconds; its note associates exceeding the limit with a device-not-present error. That is a documented limit for this timing entry, not a universal timeout for every transfer or every third-party device. [1]

The CIA turns bus roles into signal paths

The C64 Service Manual ties the bus to the 6526 CIA’s Port A. Its serial-interface description identifies PA3 as ATN output, PA4 as clock output, PA5 as data output, PA6 as clock input, and PA7 as data input. The service manual also describes the clock’s role in synchronizing data sent between the computer and a peripheral. [2]

The manual notes that U8 inverts the PA3, PA4, and PA5 outputs before they reach the external serial connector, so the table describes CIA-side signal roles rather than connector polarity.

CIA Port A bit Service-manual signal name Practical interpretation
PA3 ATN out Controller’s attention/control signal
PA4 Clock out Clock used when the C64 sends data
PA5 Data out Data driven from the C64 toward a device
PA6 Clock in Clock received for data arriving from a device
PA7 Data in Data received by the C64

The Programmer’s Reference Guide’s timing diagram labels the states “TALKER READY-TO-SEND,” “TALKER SENDING,” “LISTENER READY-FOR-DATA,” and “LISTENER DATA-ACCEPTED.” Read together with the CIA signal assignments, it is more accurate to think of the interface as a clocked handshake than as a generic asynchronous UART byte stream. A byte is not just eight bits that happen to arrive; the participants coordinate when data is valid and when a listener has accepted it. [1][2]

A disciplined way to debug a missing peripheral

Capture ATN, clock, data, and ground at the computer and, if practical, at the peripheral. First verify that ATN changes state when the command begins. Then check that the address/command phase reaches the chain and that the selected device answers before the response limit. Only after that should you investigate data direction and the per-byte handshake. Comparing the computer-side and drive-side traces can reveal a broken cable or connector that a software status read alone cannot localize.

Keep the evidence layers separate. The reference guide documents the bus contract and timing expectations; the service manual documents how the C64’s CIA signals implement the interface. A modern drive emulator or fast-loader may add behavior beyond those base manuals. Do not attribute an adapter’s accelerated transfer timing to the original protocol without identifying that implementation.

The C64 serial bus is therefore best understood as a small addressed network with one controller and negotiated data direction. Once control, selection, and transfer are treated as separate phases, a missing-device error or garbled byte stream becomes a much narrower hardware or protocol question.

Related:

Sources:

Comments