command advance sweep

docs/pt2-protocol.md

@@ -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`