Display board 1408: full output definition + firmware display content

New display-board-1408.md: pin-level definition of the board's outputs
(8 multiplexed hex digits via ICM7228B, isolated LPT LED monitor block,
no readback path) and, from the firmware disassembly, everything the RIO
puts on it: F0 boot banner, F1 test-mode banner (keypad sequence A-9-E
enters, D exits), and the sub-test displays — five live encoder-count
readouts, button test with input index, two lamp patterns, keypad test.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

README.md

@@ -92,12 +92,13 @@ hardware addressing is what the 0x00–0x6F logical input map in
   on an 8-line header (4×4 matrix). A second 74HCT164 drives the matrix
   rows through open-collector 74LS05 inverters; the 74HCT165 reads the four
   columns (`IN0-3`, 2.7K pull-ups) plus a board-detect line `BRD_DT*`.
-- **1408 Display board** (`DSP_1408`) — ICM7228B decoding `HD[00:04]` +
-  `AS0-2` + `WR` from the RIO's dedicated 14-pin *external display* port into
-  eight LTS313A digits (hex/code-B). The board also has a 26-pin **"IBM
-  printer port"** header with series resistors and per-line LEDs — a
-  diagnostic tap so a PC parallel port can exercise/observe the display bus.
-  Silkscreen reads "P/N 140B" but the schematic title block confirms **1408**.
+- **1408 Display board** (`DSP_1408`) — ICM7228B driving eight LTS313A
+  digits (hex decode) from the RIO's dedicated 14-pin *external display*
+  port; write-only, plus an isolated 26-pin **"IBM printer port"** LED
+  monitor block. Silkscreen reads "P/N 140B" but the schematic title block
+  confirms **1408**. Full pin-level output definition — and what the
+  firmware actually displays (boot banner + the keypad-A-9-E test mode) —
+  in [display-board-1408.md](display-board-1408.md).
 - **1413 Quad Amplifier Board** (`AMP_PLT`, silkscreen "Quad Amplifier
   Board … P/N 1413 REV. 1") — the actual amplification is a stock
   **Pyramid PB-150P "Pro Plus"** 4-channel 12 V car-audio amplifier bolted

display-board-1408.md

@@ -0,0 +1,102 @@
+# Display Board 1408 — outputs, and what the RIO shows on it
+
+Complete definition of the RIO External Display board (P/N 1408 Rev. 1,
+`DSP_1408` sheet 7), from the schematic, the board photos, the GAL decode,
+and the firmware disassembly (`RIOv4_2.disasm.asm`).
+
+## Outputs: light only — the board is electrically write-only
+
+No signal leaves the board toward the RIO or anything else. J1 has no
+readback line, matching the GAL's write-only `DSP_SEL*` decode, and the
+PC↔RIO protocol has no display command — only the firmware writes it.
+
+### 1. Eight multiplexed 7-segment digits (U2–U9, LTS313A, red, common-cathode)
+
+The ICM7228B (U1) does all driving. `HEX/B/SHD` is strapped high via 2.7 K
+(R1): **hexadecimal decode mode, always enabled** — each digit renders 0–F
+plus a decimal point; no raw-segment access exists as built.
+
+- **Segment bus** — U1 pins 16, 17, 20, 18, 21, 22, 23, 15 drive
+  `SEGA`–`SEGG`, `SEGDP`, shared by all digits (digit pins A–G, DP =
+  10, 9, 8, 5, 4, 2, 3, 7). Segments source the multiplexed current
+  (~20 mA peak).
+- **Digit commons** — U1 outputs `DSP1`–`DSP8` (pins 4, 25, 3, 1, 26, 2,
+  27, 24) each sink one digit's tied-together commons (CC1+CC2, pins 6+1).
+  `DSP1`→U2 (leftmost) … `DSP8`→U9 (rightmost).
+- Multiplex scanning is internal to the ICM7228; the host only writes
+  digit registers.
+
+From the 68HC11 the digits are bytes at **`$A000`–`$A007`** (`AS0-2` =
+A0–A2, strobed by `DSP_SEL*` = `E & /R/W`-qualified, arriving as the
+7228's `/WR` on J1 pin 7). Data format per write: bits 0–3 = hex value
+(`MD[00:03]`→`ID0-3`), bit 4 = decimal point (`MD[04]`→`ID7`; DP lights
+when the bit is **low** — the firmware always sets it, so the DP is never
+used). **`$A000` = leftmost digit (U2), `$A007` = rightmost (U9)**; the
+firmware's render buffer (`$2038`, routine `$CB49`) fills right-to-left so
+multi-digit hex numbers read naturally.
+
+### 2. Twelve passive monitor LEDs on the "IBM printer port" header (J2) — an input, not an output
+
+J2 (26-pin IDC, standard LPT-ribbon mapping to a DB25) is electrically
+isolated from the display circuit; its `DD` nets touch nothing but LEDs
+and 1 K resistors referenced to the PC's own ground (`IBM_GND`). With a PC
+parallel port plugged in, the LEDs show: **D0–D7** = data bits (J2 pins
+3, 5, 7, 9, 11, 13, 15, 17), **D8** = `/STROBE` (pin 1), **D9–D11** =
+`/AUTOFD`, `/INIT`, `/SELECTIN` (pins 2, 6, 8). The LPT status returns are
+strapped to ground so a PC streams without waiting. It is a built-in
+parallel-port activity monitor / bench tool, powered entirely by the PC.
+
+### 3. Nothing else
+
+J1 (14-pin, from the RIO's EXTERNAL DISPLAY port) is all input:
+`MD[00:04]` on pins 2, 4, 6, 8, 10; `AS0-2` on 1, 3, 5; `BF_DSP_SEL*` on
+7; GND on 9, 11, 13; VCC on 12, 14.
+
+## What the RIO firmware displays (v4.2)
+
+All display writes live in `$CB49–$CC52` (one buffer-render routine + five
+canned patterns) and are driven from two contexts: initialization and the
+built-in **test mode**. During normal gameplay the display is static.
+
+**Normal operation:** `F0000000` — written at cold boot (`$C068`) and warm
+re-init (`$C64B`), then left alone.
+
+**Test mode** — entered by typing the keypad sequence **A, 9, E** on a
+cockpit keypad (`$C1CB` tracks the sequence at `$20F8`); entry sets flag
+`$2421`, shows `F1000000`, and notifies the PC (`TestModeChange`, cmd
+`0x8C` — see [PROTOCOL.md](../PROTOCOL.md)). Within test mode the next
+keypad digit selects a sub-test; **F** ends a sub-test (back to
+`F1000000`), **D** exits test mode (back to `F0000000`).
+
+Display format convention: **left pair = test number, right = value**,
+zeros as filler; the decimal points are never used.
+
+| Key | Display | Test |
+|-----|---------|------|
+| *(entry)* | `F1000000` | test-mode banner |
+| `0` | `00000000` | encoder-counter reset: presets the five 16-bit accumulators to `$FAFA` and re-reads all HCTL-2016s (`$C446`) |
+| `1` | `0100hhll` | axis test, channel 01 — counter at `$A028/$A038` |
+| `2` | `0200hhll` | axis test, channel 02 — `$A020/$A030` |
+| `3` | `0300hhll` | axis test, channel 03 — `$A022/$A032` |
+| `C` | `0C00hhll` | axis test, channel 0C — `$A024/$A034` |
+| `4` | `0400hhll` | axis test, channel 04 — `$A026/$A036` |
+| `5` | `050000nn` | button test — `nn` = index of the pressed input (scan at `$D004` over the pod input state at `$2152`), with lamp feedback |
+| `6` | `06000003` | lamp test, pattern 3 (`$D34A`) — right digit is the pattern code |
+| `7` | `07000001` | lamp test, pattern 1 (`$D370`) |
+| `8` | `080000kk` | keypad test — `kk` = keypad status byte `$204B`, refreshed while scanning (`$CC7E`) |
+
+In the axis tests `hhll` is the **live 16-bit quadrature count in hex**
+(high:low = `$201D:$201E`, alternating with the raw latched bytes
+`$2026:$2025` as the loop runs) — spin the stick/throttle/pedal encoder
+and watch the number move. The channel IDs are literally the keypad keys
+that start them, which is why the fourth axis reads `0C`.
+
+## Cross-references
+
+- [README.md](README.md) — board family, photos, schematic page map
+- [gal/README.md](gal/README.md) — `DSP_SEL*` decode (`$A000-$A00F`,
+  write-only) recovered from the GAL fuse map
+- [`rio-firmware/RIOv4_2.disasm.asm`](../../rio-firmware/RIOv4_2.disasm.asm)
+  — display routines `$CB20/$CB36/$CB49` (buffer render), `$CB7C` (`F0`),
+  `$CBA7` (`F1`), `$CBD2`/`$CBFD` (lamp-test banners), `$CC28` (zeros),
+  test dispatcher `$C241`, entry-sequence tracker `$C1CB`