command advance sweep
This commit is contained in:
Aiden
@@ -419,10 +419,17 @@ Current interpretation:
|
||||
- `CONNECT:NOT ACT` is a normal no-active-session/cleared-state display, not a terminal latch.
|
||||
- `CONNECT: OK` is table/state driven, probably selector-zero active/connect state.
|
||||
- `0x8080` at selector zero is the strongest known active/connect value.
|
||||
- The panel likely expects the CCU to keep seeding or refreshing state after entering OK.
|
||||
- The panel likely expects the CCU to consume/ACK report-queue frames and keep seeding or refreshing state after entering OK.
|
||||
- The working fake-CCU sequence is probably not "three frames as fast as possible"; it appears to need CCU-like cadence or a live session window, roughly on the heartbeat/report timescale.
|
||||
- A single selector-zero continuation-shaped frame is insufficient in the current tests; two selector-zero writes at the working cadence are enough. They do not need to carry different values, because `80 -> 80` also worked.
|
||||
|
||||
ROM report-source update:
|
||||
|
||||
- The active `02/01 ...` frames seen during CONNECT OK attempts are best modeled as `F870 -> BAF2 -> BA26` report-queue transmissions.
|
||||
- `BAF2` dequeues a report word, encodes the first three TX bytes, reads the payload from `E800 + 2*selector`, and `BA26` appends the `0x5A` XOR checksum.
|
||||
- After sending a queued report, the ROM sets `FAA2.3` and `FAA3.7`; command `4`, `5`, or `6` can then consume/advance the report only while that continuation latch is live.
|
||||
- This makes a reactive fake-CCU test more valuable than another blind fixed-delay matrix: recover to OK, wait for the first active report, then send one candidate continuation/ACK frame.
|
||||
|
||||
## Candidate CCU Seed Values
|
||||
|
||||
These are syntactically valid host frames produced from ROM table mining. Use them as candidate fake-CCU state seeds, not as final protocol truth.
|
||||
@@ -513,6 +520,19 @@ Test whether OK is held:
|
||||
.\.venv\Scripts\python.exe scripts\connect_ok_matrix.py --suite hold --parity E --prompt-observation --result-json captures\connect-ok-hold-result.json
|
||||
```
|
||||
|
||||
Sweep strong continuation/ACK candidates after recovering to `CONNECT: OK`:
|
||||
|
||||
```powershell
|
||||
.\.venv\Scripts\python.exe scripts\connect_ok_advance_sweep.py --suite core --parity E --prompt-observation --result-json captures\connect-ok-advance-core-result.json
|
||||
```
|
||||
|
||||
Candidate suites:
|
||||
|
||||
- `core`: `05 00 40 00 00 1F` pure command-5 report-consume candidate, then `04 00 00 80 00 DE` selector-zero refresh/consume candidate.
|
||||
- `special`: command-5 `0x006C/0x006D/0x006E`, which call the ROM's `BE70` queue helper.
|
||||
- `latch`: command-5 `0x006B/0x0096/0x0097/0x00C6/0x00F8`, which can clear the `F731/F790` latch bits when that path is live.
|
||||
- `all`: all of the above.
|
||||
|
||||
Current matrix result summary:
|
||||
|
||||
```text
|
||||
@@ -554,6 +574,7 @@ This fits the real panel behavior:
|
||||
- Whether the CCU sends a periodic refresh stream after CONNECT OK.
|
||||
- Exact hold time before OK falls back to NOT ACT, if no refresh traffic follows.
|
||||
- Whether command 4 CONNECT success depends on an existing continuation latch, timing, or a side effect created by earlier frames.
|
||||
- Whether the remaining emulator/bench mismatch is an SCI timing bug or a missing ROM/peripheral behavior. The emulator now has an optional 8E1 TX wire-timing mode; with it enabled, repeated `80` no longer immediately reaches `CONNECT: OK`, which is closer to bench behavior but still needs calibration.
|
||||
- How EEPROM option bits change selector behavior.
|
||||
- Whether all old visible `07...` families can be reproduced under `8E1`.
|
||||
|
||||
@@ -561,11 +582,16 @@ This fits the real panel behavior:
|
||||
|
||||
1. Finish the CONNECT matrix runs:
|
||||
- rerun `hold` with 700 ms gaps to measure how long OK remains without refresh traffic.
|
||||
2. Test whether periodic `80` refreshes hold CONNECT OK, and find the longest safe refresh interval.
|
||||
3. Dump selector table state before and after CONNECT OK.
|
||||
4. Seed selectors `0x003`, `0x040`, and `0x0F6` after selector-zero OK and watch lamps/readouts.
|
||||
5. Mine selector dispatch handlers for known UI text terms: `IRIS`, `GAIN`, `SHUTTER`, `BARS`, `BLACK`, `CALL`, `AUTO`, `DIAG`.
|
||||
6. Build a fake-CCU streamer that repeatedly writes a small selector set and logs which RCP reports appear.
|
||||
2. Run the reactive advance sweep from OK and compare:
|
||||
- ACK-only `05 00 40 00 00 1F`
|
||||
- refresh/consume `04 00 00 80 00 DE`
|
||||
- command-5 special selectors `0x006C/0x006D/0x006E`
|
||||
3. Test whether periodic report ACKs plus periodic `80` refreshes hold CONNECT OK.
|
||||
4. Sweep emulator RX phase/gap with `--tx-wire-timing` and compare where `BD0E` is reached or missed.
|
||||
5. Dump selector table state before and after CONNECT OK.
|
||||
6. Seed selectors `0x003`, `0x040`, and `0x0F6` after selector-zero OK and watch lamps/readouts.
|
||||
7. Mine selector dispatch handlers for known UI text terms: `IRIS`, `GAIN`, `SHUTTER`, `BARS`, `BLACK`, `CALL`, `AUTO`, `DIAG`.
|
||||
8. Build a fake-CCU streamer that repeatedly writes a small selector set and logs which RCP reports appear.
|
||||
|
||||
## Source Files And Reports
|
||||
|
||||
@@ -588,5 +614,6 @@ Useful tools:
|
||||
- `h8536_emulator_state_search.py`
|
||||
- `scripts/bench_connect_lcd_sequence.py`
|
||||
- `scripts/connect_ok_matrix.py`
|
||||
- `scripts/connect_ok_advance_sweep.py`
|
||||
- `scripts/serial_table_dump.py`
|
||||
- `scripts/serial_scenario.py`
|
||||
|
||||
Reference in New Issue
Block a user