TeslaRel410/restoration/rio-firmware/IO-ARCHITECTURE.md

RIO I/O architecture — the pod bus, decoded

How the RIO board actually moves buttons, keypads and lamps over its eight-port "pod bus": the control-latch bit map, the 50-byte script format the firmware replays, the complete port/address population of a pod, and what it all costs in CPU cycles.

Derived 2026-07-26 from RIOv4_2.disasm.asm plus the recovered memory map in ../rio-hardware/gal/README.md and schematic sheet 3 (RIO_1407). Cross-checked against the physical inventory (9 buttons boards + 2 keypads per pod, operator-confirmed).

Everything here is read out of the firmware image unless flagged INFERRED or UNVERIFIED.

The control latch at $A010

The pod bus is bit-banged by rewriting one 74HC574 latch (BND_SEL, write-only, decoded by U7). Every bus edge is one STAA $A010. Bit assignment recovered by diffing all 11 scripts in ROM:

Bit	Signal	Behaviour
0	CCK	shift clock — toggles on every write
1	D_OUT / DD_IN	serial data into the pod's 74HCT164
2	WR_SB	write strobe — used only in write scripts
3	RD_SB	read strobe — parallel-loads the pod's 74HCT165
4	(unidentified)	static 1 in every script
5-7	SEL0-2	port select → 74LS138; all 8 values used

SEL0 = bit 5, SEL1 = bit 6, SEL2 = bit 7, so a script's first byte $N0 gives its port directly as N >> 1.

The 50-byte script format

The firmware does not bit-bang inline. It replays precomputed 50-byte scripts, one latch state per byte:

• 18 bytes — preamble. Nine CCK pulses shifting a walking 1 down the cable into the board's address 74HCT164; its position picks the ADR. SEL. jumper (A-0 = shift position 7, A-1 = 6, A-2 = 5). The last pair asserts the strobe.
• 32 bytes — payload. 16 CCK pulses, 2 bytes each. On reads, PORTE is sampled between pulses; on writes, WR_SB (bit 2) latches.

18 + 32 = 50, matching the table stride exactly.

The acquisition routine $CFC0

CFC0  PSHA/PSHB/PSHX/PSHY            ; prologue
CFC5  LDY  #$2152                    ; sample destination
CFC9  LDX  $2150                     ; script pointer
CFCC  LDAB #$12                      ; 18 preamble bytes
CFCE  LDAA $00,X / STAA $A010 / INX / DECB / BNE   ; preamble loop
CFD8  LDAB #$10 / STAB $2036         ; 16 bits
CFDD  LDAA $100A                     ; sample PORTE   <-- bit loop top
CFE0  PSHX / STY $2031 / LDX $2031 / STAA $00,X / PULX / INY
CFED  LDAB #$02
CFEF  LDAA $00,X / STAA $A010 / INX / DECB / BNE    ; one CCK pulse
CFF8  DEC $2036 / BNE $CFDD
CFFD  NOP / PULY / PULX / PULB / PULA / RTS

Disassembler sync gap. RIOv4_2.disasm.asm renders $CFE0-$D003 as .byte — it lost sync on the 18 FF (STY extended) prebyte. The listing above is the hand decode; both branch displacements ($CFF6 → $CFEF, $CFFB → $CFDD) land exactly on its instruction boundaries, which confirms it. The same gap recurs at $C380-$C38F.

PORTE ($100A) is read at exactly one site in the whole firmware — this one. Every bit of pod input arrives here.

Script tables in ROM

Region	Size	Contents
$DBB0-$DC13	2 × 50	keypad scripts — SEL 4, SEL 5
$DC14-$DC23	16 B	keypad key-code table (see below)
$DC24-$DDE5	9 × 50	read scripts — the 9 buttons boards
$DDE6-$DFA7	9 × 50	write scripts — lamps (WR_SB active)
$DFA8-$DFEF	72 B	lamp-fault mask — one byte per lamp (see below)
$DFF0-$FFxx	8,144 B	erased — the largest free run in the EPROM

The blocks butt against each other with zero slack: there is no reserved tenth script anywhere in the image.

Port and address population of a pod

Scan order is $CF40, nine JSR $CFB6 calls. SEL values across the scripts are 0,1,2,2,3,3,3,6,7, matching the $204E increment sequence exactly ($204E = SEL + 1; it starts at 1 per $CF3E).

Port	Board	Addr	Logical range
0	buttons	A-0	0x00-0x07
1	buttons	A-0	0x08-0x0F
2	buttons ×2	A-0, A-1	0x10-0x1F
3	buttons ×3	A-0, A-1, A-2	0x20-0x37
4	keypad 1	A-0	0x50-0x5F
5	keypad 2	A-0	0x60-0x6F
6	buttons	A-0	0x38-0x3F
7	buttons	A-0	0x40-0x47

All eight ports are populated. The button scan's INC $204E ×3 at $CF8B skips ports 4-5 because those are keypads, driven from the separate script pair at $DBB0/$DBE2 (referenced LDX #$DBB0 at $C350).

Port→logical assignment within port 3 and the port-6/7 ordering is INFERRED from scan order ($2037 increments monotonically, 8 per script); the ROM does not label them.

The keypads — a second, separate engine

The keypads do not ride the button scan. They have their own scripts, their own bit-bang engine, their own RAM, and their own message type. This is why they never appear in the 72-entry button arrays.

Templates are copied ROM → RAM so rows can be patched

$C34C copies 100 bytes (LDAB #$64) from $DBB0 to $2050 — both keypad scripts. $C369 does the same for the 9 write scripts ($DDE6 → $220A, #$09 × #$32). Scripts live in RAM because the firmware rewrites bits inside them between replays.

	Keypad 1	Keypad 2
Entry	$CC53	$CC7E
Port (SEL)	4	5
$204E	5	6
RAM script	$2050	$2082 (= $2050 + $32)
Raw samples	$20B6 (32 B)	$20D6 (32 B)
Key states	$20FC (16 B)	$210C (16 B)
Key code out	$204A	$204B

$2082 never appears as a literal — $CC7E reaches it with LDAB #$32 / ABX, and likewise offsets the two buffers by $20/$10.

$204E = 5 and 6 are exactly the two indices the button scan skips with its INC $204E ×3 at $CF8B. The two engines share one index space and partition it cleanly.

The script shape differs from a buttons board

buttons: 7 pulses data=0, 1 pulse data=1, strobe, 16 read pulses
keypad : 15 pulses data=0, 1 pulse data=1, strobe,  8 read pulses

The keypad shifts 16 bits, not 8 — the 1402 carries two chained 74HCT164s (8 bits board address + 8 bits matrix row drive, through the 74LS05 open-collector inverters), so the walking 1 has to travel twice as far. It then reads back only 8 bits, because the single CD74HCT165 sees 4 columns plus BRD_DT* and spares.

The scan engine $CCB2 — four rows

LDY $20F6 ; result ptr      LDAB #$04 / STAB $2034   ; 4 ROWS
CCBC: LDX $20B4             ; reload script base each row
      dispatch on row: $CD1E (4) / $CD4F (3) / $CD80 (2) / $CDB1 (1)
                                  ; ^ patch the row bit in the RAM script
CCE3: LDAB #$22             ; 34 bytes = 17 CCK pulses + strobe
      LDAA $00,X / STAA $A010 / INX / DECB / BNE
CCF2: LDAB #$08 / STAB $2035 ; 8 columns
CCF7: LDAA $100A            ; sample PORTE (the 2nd of only 2 such sites)
      ... store, INY, 2 latch writes = one CCK pulse ...
CD12: DEC $2035 / BNE $CCF7  ; 8 bits
CD17: DEC $2034 / BNE $CCBC  ; 4 rows

The four row patchers are near-identical; $CD1E is LDAA $08,X / ORAA #$02 / STAA $08,X (etc.) — setting and clearing bit 1 (D_OUT) at specific script offsets, which walks the row 1 to a different shift position for each row.

Demux $CDE2 and the key-code table

Per row it does INX ×4 — discarding the first 4 sampled bits — then takes 4. That is 4 columns × 4 rows = 16 keys, indexed by $20FB running 0-15. The discarded bits are the 165's status half; $CEFA picks two of them ($20B6+$03 bit 4, $20D6+$03 bit 5) into the fault array at $24ED+9/+$0A — keypad board-detect.

$CE1F/$CE72 load LDY #$DC14, a 16-byte scan-code → legend table occupying the gap between the keypad scripts and the button read block. Contents are the stock hex-pad layout:

	c0	c1	c2	c3
r0	1	2	3	C
r1	4	5	6	D
r2	7	8	9	E
r3	A	0	B	F

$CE72 is the press path (state → $01), $CE1F the release path (state → $00); a pressed key reads 0, being pulled low against the 2.7K column pull-ups. Both enqueue message type $8B — not the $88/$89 button press/release pair.

So 0x50/0x60 are host-side logical IDs, formed as a per-pad base plus the 0-F key code; the wire carries a distinct message type and a nibble. That is why the pads consume none of the 112-entry button map internally. (INFERRED — the base-plus-code composition is the reading that fits both the firmware and the observed map; PROTOCOL.md in the RIOJoy repo is the authority.)

Cadence asymmetry

The main loop at $C0B0 is:

C0B0  JSR $C579   ; protocol service
C0B3  JSR $CF31   ; button scan (9 boards)
C0B6  JSR $C579
C0B9  JSR $CC7E   ; keypad 2 ONLY
C0BC  JSR $C579
C0BF  JSR $C1CB
C0C2  JSR $C579
C0C5  JSR $C0EB
C0C8  JMP $C0B0

Both pads are polled every pass, but by different routes. Keypad 2 is scanned directly at $C0B9. Keypad 1 goes through $C33B (JSR $CC53 / LDAA $204A / RTS — scan and return the key), which is called by the A-9-E chord detector $C1CB at $C0BF; $CC53 is also reached from the CheckRequest self-test at $C5C9. So keypad 1 feeds the test-mode entry sequence while keypad 2 feeds the normal event stream — a functional split, not a polling gap.

I/O inventory — one pod

Inputs	Count	Address
Buttons (9 × 1401 × 8)	72	0x00-0x47
Keypad 1 (1402 hex pad)	16	0x50-0x5F
Keypad 2 (1402 hex pad)	16	0x60-0x6F
Total digital controls	104	of a 112 map
Analog axes (HCTL-2016, 512 cpr)	5	$A020-$A03F
Panel switches (RESET, ABORT→IRQ*)	2	—

Outputs	Count
Button lamps (9 × 8, UCN5821A)	72
Global brightness PWM (BRT_CTR)	1
Display digits (ICM7228B)	8
Status LEDs	6

Logical address map

Range	Count	Contents
0x00-0x47	72	buttons — fully populated
0x48-0x4F	8	gap — one unused board slot
0x50-0x5F	16	keypad 1
0x60-0x6F	16	keypad 2

0x48 = 72 is the #$48 constant that sizes five separate arrays — the button space and the gap boundary are the same number.

RAM layout (packed solid)

Base	Size	Contents
$2050	2 × 50	keypad scripts, copied from $DBB0, row-patched in place
$20B6 / $20D6	32 B ea	keypad raw samples (4 rows × 8 bits)
$20FC / $210C	16 B ea	keypad key states
$2152	16 B	raw PORTE samples, bit-major
$2162	$60 = 96	input state, logical 0x00-0x5F
$21C2	$48 = 72	second demux path ($D144, index $2442)
$220A	9 × 50 = 450	lamp write-script buffer (board × 50)
$23CC	2 B	script pointer used by $D331
$23CE	$48 = 72	lamp state
$2454	$48 = 72	lamp command
$249C	$48 = 72	(button-indexed)
$24ED	$14 = 20	fault/status flags ($CEFA)

Arrays abut with no padding — $21C2 + 72 ends at $2209, exactly where the lamp buffer begins.

Cycle budget (2 MHz E-clock, 0.5 µs/cycle)

Hand-counted from M68HC11 instruction timings; all register access is extended mode (no LDX #$1000 base pointer exists in the image), so operand enumeration is exhaustive.

Stage	Cycles	Time
Preamble loop (18 × 16)	288	144 µs
Bit loop (16 × 75)	1,200	600 µs
Prologue/epilogue/JSR	66	33 µs
$CFC0 acquisition	1,554	777 µs
$D004 demux (8 inputs)	~1,132	566 µs
$D144 demux (8 inputs)	~1,132	566 µs
$CFB6 — one pass	~3,829	1.91 ms
Full scan (9 passes)	~34,500	17.3 ms

Maximum scan rate ≈ 58 Hz; worst-case button latency ≈ 17 ms. Acquisition is only 40% of it (7.0 ms) — demux is 60% (10.2 ms).

Marginal costs: one more pass (+16 bits) = 1.91 ms; one more input inside an existing pass = 135 cycles = 68 µs.

Keypads, same method (estimates — the row patchers and handlers are state-dependent):

Stage	Cycles	Time
$CCB2 per row (patch + 34 shift + 8 read + loop)	~1,275	637 µs
$CCB2 × 4 rows	~5,150	2.6 ms
$CDE2 demux (16 keys)	~2,800	1.4 ms
One keypad	~7,950	~4.0 ms

A main-loop pass therefore costs roughly 17.3 ms (buttons) + 4.0 ms (keypad 2) ≈ 21 ms, plus the encoder sweep and four $C579 protocol services — call it ~45 Hz of button/keypad latency. Keypad 1 adds its 4.0 ms only when the host asks for it.

The scan is fully interruptible — every SEI/CLI in the image is at $C0AF and $C6E9-$C804 (message-queue critical sections), none in $CF40-$D180. Lengthening the scan costs latency, not SCI ISR margin.

Why demux dominates

Two naive constructs, both fixable in the $DFF0 cave:

1. Bit extraction shifts a byte right k times via DECB/BEQ/LSRA/JMP — 10 cycles per position, up to 75 to reach bit 7. A mask table replaces it with ~4.
2. The press/release handler is a JSR with full register save (58 cycles) even when nothing changed.

Estimated together: demux ~1,132 → ~400 cycles/pass, full scan 17.3 → ~9.4 ms. UNVERIFIED — not implemented or benched.

Lamp readback and the fault mask

The second 8 bits of each board's 16-bit read — the $D144 path into $21C2 — are lamp readback, not spare status. This closes the loop the 1401's second 74HCT165 exists for.

• $D144 compares each bit against the expected polarity in $24EA; $D180 sets the entry's bit 0 accordingly, $D19E clears it. $21C2[n] therefore holds lamp n's health: 1 = OK, 0 = fault.
• $D262 sweeps all $48 = 72 entries and calls $D28C for every zero.
• $D28C indexes $DFA8 by the same lamp number. Mask byte 0 suppresses the report; nonzero emits report type $03 with the lamp index in $2519 via $C75E.

So $DFA8 is a per-lamp populated map — which of the 72 lamp positions are physically fitted and therefore worth fault-checking. It is 72 bytes ($DFA8-$DFEF), exactly matching the array, with the erased cave starting at $DFF0. Suppressed entries:

Board	Lamps	Mask
0-2	$00-$17	all monitored
3	$18-$1F	$1F suppressed
4-6	$20-$37	all monitored
7	$38-$3F	$3C, $3F suppressed
8	$40-$47	all 8 suppressed

61 of 72 positions are monitored. The ninth board carries no fault-checked lamps at all.

This explains the persistent "board/lamp fault item" seen in both CheckRequest snapshots (RIOv4_2-ANALYSIS.md) — it is a type-$03 report, and $2519 carries the exact lamp index, so a captured snapshot identifies precisely which lamp is dead.

$D0BC — the routine $C0EB defers by four main-loop passes, and skips while the test-display flag $2421 is set — walks the two other 72-entry lamp arrays ($249C, $2454) under a rotating bit mask $24E8 that advances one position per call and reloads at $80 after 8 ($24E9). One bit-plane per tick across all lamps: most consistent with per-lamp blink/intensity sequencing (INFERRED — the bit-plane walk is plain, the visual effect is not proven).

The encoder bank — decode has room, the board does not

Settled 2026-07-26 from the board photo and schematic sheet 1.

Addressing. Each HCTL-2016 consumes two 74LS138 outputs, not one:

Line	Role
A[0]	0 = data read, 1 = strobe (the OE/RST pair)
A[2:1]	channel within a '138
A[3]	which '138 — U8 or U9, via the GAL's NOT_A3
A[4]	SEL pin = high/low byte of the 16-bit count

Both '138s take A[0:2] + PH_SEL* + E; U8's G2B is A[3]. Firmware confirms the split — $C8CC-$C9A7 reads the even (data) addresses $A020/$A030 … $A028/$A038, while $C458-$C4C0 hits the odd (strobe) addresses $A021-$A029.

So the ceiling is 8 channels: U8 serves OPT1-4 (Y0/Y1 … Y6/Y7), U9 serves OPT5 on Y0/Y1 and has Y2-Y7 free = 3 spare channel decodes. (An earlier estimate reached the same "3 spare" by assuming one decode line per chip; the count is right, the reasoning was not.)

But there are no footprints. The 1407 carries exactly five HCTL-2016 positions — U12-U16 = OPT1-5, headers J5/J6/J7/J3/J4 — and the schematic draws exactly five symbols, U16 being the last. Below OPT5 the PCB is bare: no silkscreen outline, no plated holes. For contrast, this board's genuinely unpopulated sites (U31, the 22V10, and R43/R44) show an obvious white outline over two rows of empty pads. The encoder bank has nothing of the kind.

The '138 outputs are pulled up by R16/R15 (PULLUP10, 2.7K); R16's spare pin is net nc2, carrying an explicit fab instruction on the sheet: *"*Note: Do not wire net nc2 on pcb."

Verdict: +3 axes is NOT firmware-only. The decode would accept them; the board offers nowhere to put them. It needs a daughterboard hung off U9's spare selects, or a respin.

Expansion capacity

Resource	Now	Add	Gated by
Buttons	72	+8	the 0x48-0x4F gap = one 1401 board
Lamps	72	+8	same board
Analog axes	5	+3 (hardware)	decode has 3 spare selects but no PCB footprints
Keypad keys	32	0	map ends at 0x6F
Display digits	8	0	ICM7228B is 8-digit
Pod-bus slots (hardware)	64	+53	no logical IDs to reach them

The pod is built out. 104 of 112 logical inputs are in use. Past +8 buttons, expansion is protocol-bound, not hardware-bound: the bus can address 64 slots and the CPU could service ~17 at 30 Hz, but the map has no IDs left.

The single tenth buttons board is the only expansion this hardware takes without modification. The analog axes looked like the free win but are not: the decode has three spare channel selects on U9, and the board has nowhere to solder them (see the encoder-bank section above). Everything else — more buttons, more keys, more axes — needs either a protocol revision or new hardware.

Adding the tenth board

No free port — all 8 are populated, so it chains onto an existing port's cable at a spare ADR. SEL. position (A-3+ are unused everywhere; DD_OUT is open-collector precisely to allow sharing). INFERRED: port 7 at A-1 is the natural spot, since 0x48-0x4F follows port 7's 0x40-0x47 in scan order. The harness decides.

Cost: one scan pass (17.3 → 19.1 ms, 58 → 52 Hz), ~100 bytes of script in the cave, a tenth JSR $CFB6, and five #$48 → #$50 constants ($C399, $C3A2, $C3B4, $C3BD, $D26D). The catch is RAM: the arrays abut, so growing them in place overruns the lamp buffer at $220A — it needs a re-layout, though SRAM is 32K with only ~$2000-$2500 in use.

Corrections to earlier claims

Recorded so they don't get re-derived wrongly:

• PORTE is the pod-bus return path, not spare ADC. All 8 pins carry DI[0..7]; the A/D is never powered up (OPTION/ADCTL/ ADR1-4 untouched) because the pins are already busy. This is also why there are exactly 8 pod ports — PORTE is 8 bits wide.

• There is no 8× demux win. An acquisition stores whole PORTE bytes, which looks like all 8 ports captured in parallel — but SEL varies per script and tracks $204E, so the 74LS138 gates the strobes per port and only the selected port returns valid data.

• Ports 4 and 5 are not empty — they are the two keypads.

• The keypads are not daisy-chained into button shift chains; they have their own ports and their own scripts at $DBB0/$DBE2.

• $CC53 is the keypad-1 scanner, not an encoder sweep. RIOv4_2-ANALYSIS.md's CheckRequest write-up cited $CC53 for "sweeps all five encoder channels". The behavioural claim is right (the sweep does end on channel 4) but the address is wrong: the five channels are read at $C8CC-$C9A7 (pairs $A028/$A038, $A020/$A030, $A022/$A032, $A024/$A034, $A026/$A036), driven from $C0CB. $C5C9/$C5CC in the self-test are the two keypad scans.

• The disassembly under-reports hardware access. Sync gaps hid a second PORTE read ($CCF7) and two $A010 writes ($CCEA, $CD0B). Search the raw binary for B6 10 0A / B7 A0 10 rather than grepping the listing.

The main loop, fully accounted for

C0B0  JSR $C579   ; protocol service (runs between every stage)
C0B3  JSR $CF31   ; button scan — 9 boards, 17.3 ms
C0B9  JSR $CC7E   ; keypad 2 scan, 4.0 ms
C0BF  JSR $C1CB   ; keypad 1 via $C33B + A-9-E chord detector
C0C5  JSR $C0EB   ; deferred lamp bit-plane tick (every 4th pass)
C0C8  JMP $C0B0

$C1CB is the test-mode chord detector. It calls $C33B (scan keypad 1, return its key) every pass and matches the sequence A → 9 → E in a 3-byte buffer at $20F8; on the third key it sets the test-display flag $2421, sends TestModeChange ($C70E), and runs $CBA7/$C241. So keypad 1 is polled continuously — the earlier "on demand only" reading was wrong; the demand is this detector. That is the keypad-A-9-E test mode described in ../rio-hardware/display-board-1408.md.

The encoder sweep is not in this loop — it runs from $C0CB ($C8CC-$C9A7).

Open questions

Nothing outstanding on the I/O path. Remaining loose ends are cosmetic: the precise visual effect of $D0BC's bit-plane walk, and the three individually-suppressed lamp positions ($1F, $3C, $3F) — which may record real cockpit wiring rather than anything in firmware.

Reading the schematics without a PDF renderer

Scans_018-014.pdf holds seven CCITT G4 scans (6800×4400, one per sheet) and no text layer. With no pdftoppm/Ghostscript available, the working route is to pull each image stream out of the PDF and rewrap it in a minimal TIFF header (Compression=4, PhotometricInterpretation=0), which Pillow decodes directly. Sheet order matches the table in ../rio-hardware/README.md.

Cross-references

• RIOv4_2-ANALYSIS.md — wedge fix, baud ladder, certification history
• ../rio-hardware/README.md — boards, schematics, pod-bus signal set
• ../rio-hardware/gal/README.md — U7 decode and the memory map