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.

Follow-up panel-atlas-standard-master-* webcam runs:

• 0x0012, 0x0013, and 0x0014 high-nibble/selected-bit sweeps did not produce a clean STANDARD or MASTER lamp trigger. The 0x0013=0x8000 SLAVE positive control still worked.
• 0x0010, 0x0011, 0x0015, 0x0016, 0x0017, 0x0018, 0x0019, and 0x001A high-nibble sweeps did not produce a clean STANDARD or MASTER lamp trigger.
• 0x0008 through 0x000F high-nibble sweeps did not produce a clean STANDARD or MASTER lamp trigger.
• 0x0017=0x4000 lit the same far-right bottom BARS lamp/latch as the known 0x0017=0x8000 family. Later 0x0018 rows in that run were latch-contaminated and need fresh-boot isolation before assigning a separate meaning.

Current implication: STANDARD and MASTER are probably not simple direct command-0 high-nibble writes in the 0x0008-0x001A pocket, despite the older broad run that made MASTER flash. Treat that older observation as a real bench-visible event but not yet an isolated selector mapping.

panel-atlas-big-visual-sweep-0001-017f-highbits

The broad webcam sweep and fresh-boot isolation pass produced these confirmed or near-confirmed panel-output mappings:

Selector/value	Current meaning
0x0013 = 0x4000	IRIS/M.BLACK LINK lamp
0x0024 = 0x8000	LCD selector-button lamp
0x0024 = 0x0000	LCD selector-button lamp remained visible at 0.5 s; not a simple clear in this timing window
0x0082 = 0x8000	IRIS readout OP
0x0082 = 0x4000	IRIS readout 1.4
0x0082 = 0x0000	IRIS readout blank
0x0083 = 0x8000	MASTER GAIN -3, SHUTTER OFF, and IRIS AUTO
0x0083 = 0x0000	same visible state remained at 0.5 s; likely latched/copied elsewhere
0x0093 = 0x8000	BLACK/FLARE MANUAL plus white-balance PRESET
0x0093 = 0x4000	BLACK/FLARE MANUAL plus white-balance AUTO
0x0093 = 0x2000	BLACK/FLARE MANUAL plus white-balance MANUAL
0x0093 = 0x0000	BLACK/FLARE MANUAL plus white-balance MANUAL

Run health was good: no resync events, no dropped bytes, and command-4 readbacks appeared for the listed writes.

ROM trace now confirms the 0x0013 bit split:

• E800[0x0013] is H'E826.
• Selector 0x0013 dispatches to H'2E06.
• H'E826.15 sets/clears F791.6 and F713.4, matching SLAVE.
• H'E826.14 sets/clears F791.5 and F716.7, matching IRIS/M.BLACK LINK.
• Local handler H'200E can also toggle H'E826.14 from panel input F006.7/F6DB.7 when its session gate allows it.

Interpretation:

• 0x0082 is the cleanest direct readout lane found so far: set values update the IRIS display and 0x0000 blanks it.
• 0x0083 appears to be a combined status/display lane rather than only the MASTER GAIN display. Its 0x8000 state also brings up SHUTTER OFF and IRIS AUTO, and the clear write did not visually clear it at 0.5 s.
• 0x0093 selects white-balance mode. In this run, 0x2000 and 0x0000 both presented white-balance MANUAL, so bit 13 may be redundant in this context or may need another gate to show a distinct state.

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.