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:

.\.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.