230 lines
14 KiB
Markdown
230 lines
14 KiB
Markdown
# 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:
|
|
|
|
```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
|
|
.\.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.
|