h8-536-decoder/docs/pt2-lamp-selector-map.md

# PT2 Lamp And Panel Output Selector Map

This note tracks bench-visible lamp/readout effects from CCU-to-RCP selector writes.

## Current Model

The panel lamps and seven-segment displays are driven by selector-table state, not by one monolithic "connected" flag. Command 0 writes into the primary/current tables, and several selectors immediately affect visible panel outputs while `CONNECT: OK` is alive.

Known active-state foundation:

- `E000[0x0000] = 0x8080` wakes/holds `CONNECT: OK`.
- `E000[0x008F]` drives shutter `EVS`/`OFF` style display state and iris AUTO side effects.
- `E000[0x0093]` drives at least white-balance and black/flare lamp state.

## Bench Observations 2026-05-26

### `lamp-0093-lowbyte-sweep`

Result: no new visible behavior beyond the already-known `0x0093` family.

Interpretation:

- The earlier `0x0093` mapping still stands.
- Individual low-byte probes inside a streamed `0x90xx` context did not reveal a new lamp in this run.
- Keep `0x9020` as a useful manual/baseline context and `0x90FF` / `0xFFFF` as black/flare AUTO positive controls.

### `lamp-known-button-selector-probe`

Visible result:

- CAM button/lamp flashed on/off.
- CALL lamp flashed on/off.
- BARS and MASTER lamps flashed on/off.
- Camera tally changed red, then later green.
- Each visible output illuminated by itself, not as a broad all-lamps blast.

Serial result:

- The run stayed in normal `CONNECT: OK` response cadence.
- Each command-0 write produced an immediate `04 ...` readback-style frame and repeated `02 00 02 00 00 5A` active responses.

Candidate mapping:

| Selector/value pair | Current meaning |
| --- | --- |
| `0x0007 = 0x8000/0x0000` | CAM POWER lamp blink confirmed by isolated run |
| `0x0015 = 0x8000/0x0000` | CALL lamp blink confirmed; red tally also blinked in the same phase |
| `0x0012`, `0x0013`, `0x0016`, `0x0017`, `0x0018`, `0x001A` | ordered candidates for SLAVE, green tally, BARS, MASTER, and neighboring lamp states |

Follow-up `lamp-isolate-cam-call` result:

- First phase blinked CAM POWER.
- Second phase blinked CALL and red tally.

Follow-up `lamp-isolate-known-neighbors` result:

- Visible order was SLAVE, then green tally, then BARS.
- The pattern repeated, and at one point SLAVE and BARS were visible together.
- Treat the ordered mapping as likely but not final until a fresh-boot single-selector run separates latch/persistence effects from the selector under test.

Follow-up `lamp-isolate-neighbor-single-boot` result:

| Fresh-boot candidate | Visible result |
| --- | --- |
| `0x0012 = 0x8000/0x0000` | no visible change reported |
| `0x0013 = 0x8000/0x0000` | SLAVE lamp |
| `0x0016 = 0x8000/0x0000` | camera tally green |
| `0x0017 = 0x8000/0x0000` | BARS lamp |
| `0x0018 = 0x8000/0x0000` | no visible result reported yet |
| `0x001A = 0x8000/0x0000` | no visible result reported yet |

This confirms that the host/CCU can directly drive panel lamps through selector-table writes. It also validates using the ROM dispatch-neighbor list around `0x0007` and `0x0015` as a high-value lamp map.

### `lamp-broad-status-selector-sweep`

Visible result:

- KNEE AUTO lamp flashed a few times.
- No other new visible result was reported.
- Follow-up isolation saw KNEE AUTO toward the end of the run, then blinking.

Candidate selectors in that run:

`0x0003`, `0x0040`, `0x0081`, `0x0092`, `0x00A7`, `0x00B7`, `0x00B9`, `0x0110`

Interpretation:

- KNEE AUTO is likely in this broader status cluster.
- Because the visible change happened toward the end, strongest next candidates are `0x00A7`, `0x00B7`, `0x00B9`, and `0x0110`, with `0x0092` kept as a guard candidate.
- Exact selector/value still needs isolation because the broad sweep changed several selectors in sequence.

Follow-up `lamp-isolate-knee-tail-single-boot` result:

| Fresh-boot candidate | Visible result |
| --- | --- |
| `0x0092` | iris AUTO/OFF behavior |
| `0x00A7` | no visible result reported |
| `0x00B7` | no visible result reported |
| `0x00B9` | KNEE AUTO |
| `0x0110` | KNEE AUTO |

Interpretation:

- `0x00B9` and `0x0110` are now the strongest KNEE AUTO candidates.
- Because two selectors can light the same lamp, the KNEE status may be split between camera status and panel/display state, or one selector may select the subsystem while the other sets the visible mode.
- `lamp-isolate-knee-bit-scan` lit KNEE AUTO in both candidate passes. The current working map is `0x00B9.15` and `0x0110.15`.
- No lower-bit KNEE behavior has been reported from that scan yet.
- The next useful step is an OR/precedence test: set both candidate bits, then clear one while the other remains set. If KNEE AUTO stays on, the lamp is probably an OR of two status sources. If it turns off, the latest selector write or a hidden mode gate is more important than the raw bit state.

Follow-up `lamp-knee-or-precedence` result:

- Case 1 (`0x00B9.15` set, then `0x0110.15` set, then `0x00B9` cleared) kept KNEE AUTO on until near the end, when `0x0110` was cleared.
- Case 2 (`0x0110.15` set, then `0x00B9.15` set, then `0x0110` cleared) turned KNEE AUTO off well before the end, even though `0x00B9` had been set.
- This argues against a simple OR model. Current best interpretation: `0x0110.15` is the stronger live display/control source for KNEE AUTO; `0x00B9.15` is related, but may be a transient, secondary status source, or only meaningful with another gate active.

## Follow-Up Isolation Scenarios

Run these with the console visible and record the exact label shown when each lamp changes:

```powershell
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\lamp-isolate-cam-call.json --parity E --log captures\lamp-isolate-cam-call.txt --result-json captures\lamp-isolate-cam-call-result.json
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\lamp-isolate-known-neighbors.json --parity E --log captures\lamp-isolate-known-neighbors.txt --result-json captures\lamp-isolate-known-neighbors-result.json
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\lamp-isolate-knee-status-selectors.json --parity E --log captures\lamp-isolate-knee-status-selectors.txt --result-json captures\lamp-isolate-knee-status-selectors-result.json
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\lamp-isolate-neighbor-single-boot.json --parity E --log captures\lamp-isolate-neighbor-single-boot.txt --result-json captures\lamp-isolate-neighbor-single-boot-result.json
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\lamp-isolate-knee-tail-single-boot.json --parity E --log captures\lamp-isolate-knee-tail-single-boot.txt --result-json captures\lamp-isolate-knee-tail-single-boot-result.json
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\lamp-isolate-knee-bit-scan.json --parity E --log captures\lamp-isolate-knee-bit-scan.txt --result-json captures\lamp-isolate-knee-bit-scan-result.json
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\lamp-knee-or-precedence.json --parity E --log captures\lamp-knee-or-precedence.txt --result-json captures\lamp-knee-or-precedence-result.json
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\lamp-knee-sustain-compare.json --parity E --log captures\lamp-knee-sustain-compare.txt --result-json captures\lamp-knee-sustain-compare-result.json
```

Method notes:

- Record visible changes immediately during each labeled hold. Later `CONNECT: NOT ACT` cleanup is not selector evidence.
- If a selector causes a latch or unexpected mode, stop and keep the log instead of continuing the whole sweep.
- Prefer exact notes like `selector_0018_high -> tally red`, because the logs already preserve send timestamps and readback frames.
- For the single-boot follow-ups, each candidate gets a fresh power cycle. That is deliberate: it tests whether a lamp is truly driven by that selector rather than retained from a previous write.