Error-handling inventory: E0 diagnostics, dEAd crash screen, no watchdog

The display has a third use: serial error annunciator. $D5F2 renders
'E0' + three live counters (TX-ring overflow $3187, reply retries
$3184, give-up teardowns $3185); $DAB8/$DAB2 is a terminal crash
screen spelling 'dEAd' when the TX dispatcher meets an unknown command
byte. Also recorded: RX overrun is unhandled (checksum NAKs are the only
symptom), unused vectors hang in BRA-self stubs, FAULT LED = MAX690 PFO,
manual/remote reset works by pulling PFI low, RUN LED = buffered AS*,
and the MAX690 watchdog is unconnected/unserviced — software wedges
persist until reset, matching bench observations.

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

display-board-1408.md

@@ -54,9 +54,10 @@ J1 (14-pin, from the RIO's EXTERNAL DISPLAY port) is all input:
 
 ## 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.
+All display writes go through `$CB49` (buffer render) or five canned
+patterns at `$CB7C–$CC52`, driven from three contexts: initialization,
+the built-in **test mode**, and the **serial error/crash displays**
+(below). During normal, healthy gameplay the display is static.
 
 **Normal operation:** `F0000000` — written at cold boot (`$C068`) and warm
 re-init (`$C64B`), then left alone.
@@ -91,6 +92,28 @@ In the axis tests `hhll` is the **live 16-bit quadrature count in hex**
 and watch the number move. The channel IDs are literally the keypad keys
 that start them, which is why the fourth axis reads `0C`.
 
+## Error displays (the third use)
+
+Two more display writers live in the serial machinery — the display is
+also the RIO's **error annunciator**:
+
+- **`E0` serial-diagnostics readout** (`$D5F2`) — `E0xxyyzz` where
+  `xx` = TX-ring overflow count (`$3187`, outbound byte dropped because
+  the ring was full, `$D66A`), `yy` = reply-retransmit count (`$3184`,
+  the game failed to ACK a reply, `$D96A`), `zz` = reply-teardown/give-up
+  count (`$3185`, `$DA2F`). Each increment site immediately re-renders,
+  so the display live-updates as serial trouble accumulates. If a
+  cockpit's display reads `E0…` instead of `F0000000`, the serial link
+  has been dropping or retrying.
+- **`dEAd` crash screen** (`$DAB8`, loop at `$DAB2`) — the TX-ISR ring
+  drain (`$D8C2`) looks each outgoing command byte up in an 8-entry
+  dispatch table at `$3158`; an unmatched byte means internal state
+  corruption, and the firmware jumps to an infinite loop that renders
+  `#$DE #$AD` → **`dEAd`** followed by RAM bytes `$0000/$0001` (nothing
+  in this build writes them — vestigial debug data). The board is dead
+  until reset; there is no watchdog to rescue it (the MAX690's WDI is
+  not connected to the CPU and no strobe code exists in the firmware).
+
 ## Cross-references
 
 - [README.md](README.md) — board family, photos, schematic page map