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 real KNEE-related selectors, but a ROM trace now shows they are not a simple OR-held lamp pair.
• loc_1795 is the local KNEE/panel-input handler. It is reached from F104 -> F692 -> F6F0.1, then reads E000[0x00B9] and E000[0x0110].
• The ROM gate for the live KNEE value/report branch is 0x00B9.13, not 0x00B9.15.
• 0x0110.15 forces a timed KNEE page/display override. That fits the observed "lights, then clears" behavior.
• 0x00B9.15 still matters on the timed KNEE LCD page: it selects the PRESET label when 0x0110.15 is clear. With both clear, the same page labels KNEE as AUTO.
• When 0x00B9.13 is set and 0x0110.15 is clear, the ROM computes F692 - F6B2 and reports/updates selector 0x00BC. That is now the strongest candidate for the KNEE control value lane.

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 lamp-knee-sustain-compare result:

• Repeated 0x00B9.15 refresh never lit KNEE AUTO.
• Repeated 0x0110.15 refresh lit KNEE AUTO, but it turned off again around the middle of the repeated-refresh window.
• This makes 0x00B9.15 look like a context-sensitive or stale interpretation rather than a maintained lamp source.
• 0x0110.15 remains the best KNEE AUTO source, but it is not sufficient by itself to hold the lamp. It likely needs a surrounding CCU status refresh, or another selector periodically clears/rebuilds the visible lamp bank.

Follow-up lamp-knee-context-hold result:

• Pairing 0x00B9.15 with the known 0x0093=0x9020 active refresh did not light KNEE AUTO.
• Pairing 0x0110.15 with 0x0093=0x9020 did light KNEE AUTO, but it still turned off around the middle of the run.
• The serial log stayed clean: repeated table readbacks and 02 00 02 00 00 5A active responses continued, with no resync or NOT ACT-style serial collapse.
• Current best hypothesis: 0x0110.15 behaves more like an edge/pulse or consumed display request than a pure level-held lamp bit. Repeating the same high value may not retrigger it after the display task has consumed the state.

ROM follow-up:

• Detailed notes: docs/pt2-knee-rom-trace.md.
• The timed path sets F732=0x1C03, FB02=0x14, calls loc_48FA, and later restores the previous page through loc_48EF.
• F732=0x1C03 dispatches to a KNEE LCD page. Its second line is DL when 0x0110.15 is set, PRESET when 0x0110.15 is clear and 0x00B9.15 is set, otherwise AUTO.
• knee-rom-gate-and-value-probe produced a new bench LCD state with DTL on the left and KNEE on the right. This matches the ROM page-0x1C neighborhood: KNEE entry at 0x95CE, DETAIL entry at 0x97C8.
• The panel physically has DETAIL and KNEE buttons near the LCD, so this is likely a local menu/button context. Pressing those buttons during the prepared gate window may supply the F104 transition that the ROM needs before it calls loc_1795.
• Follow-up isolation lit KNEE AUTO in the later KNEE cases/windows but did not change the LCD. Treat the KNEE AUTO lamp and the DETAIL/KNEE LCD page as related but separate paths: 0x0110.15 remains the strongest lamp/status source, while LCD movement likely needs an additional local menu/display gate.
• Next bench retest should include 0x00B9.13 (00 01 39 20 00 42) and the 0x00BC report/read lane, not only the older 0x00B9.15 / 0x0110.15 pair.

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
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\lamp-knee-context-hold.json --parity E --log captures\lamp-knee-context-hold.txt --result-json captures\lamp-knee-context-hold-result.json
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\lamp-knee-edge-refresh.json --parity E --log captures\lamp-knee-edge-refresh.txt --result-json captures\lamp-knee-edge-refresh-result.json
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\knee-rom-gate-and-value-probe.json --parity E --log captures\knee-rom-gate-and-value-probe.txt --result-json captures\knee-rom-gate-and-value-probe-result.json
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\knee-rom-dtl-knee-isolation.json --parity E --log captures\knee-rom-dtl-knee-isolation.txt --result-json captures\knee-rom-dtl-knee-isolation-result.json
.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\knee-detail-physical-button-watch.json --parity E --log captures\knee-detail-physical-button-watch.txt --result-json captures\knee-detail-physical-button-watch-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.