diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index 9935fe58..aea1a7df 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -308,7 +308,7 @@ here until 2026-08-28 and is now settled.) | ❔ | **the other ~319 SE cues** (Q8) | located one at a time by triggering them; only the three the menu needs have been done | | 🟑 | **the paint-order tie-break** (Q3) | eight candidates refuted; costs one element's blend on one screen | | 🟑 | **GamePart ids behind the buttons** (Q4) | the *screens* are measured; the ids are a name match onto the executable's class names | -| 🟑 | **the boot transitions in code** (Q6) | `GamePart_Title` has **two nested state fields** β€” a 5-way phase at `this+132` and a 10-way state at `this+136` inside phase 4. Phase 0 = splash (`LOGO`), phase 2 = title + `PRESS β’Ά` plate, phase 4 = the menu machine. Unknown: what the event *numbers* mean, and phase 1/3 | +| 🟑 | **the boot transitions in code** (Q6) | both levels decoded β€” phase at `this+132` (`entryβ†’2`, `2β†’0`, `2β†’3`, `3β†’4`, `4β†’2`) and state at `this+136` inside phase 4. Phase 0 = splash (`LOGO`), phase 2 = title + `PRESS β’Ά`, phase 4 = menu. Unknown: what the event *numbers* mean | | ❔ | **builds 0/1 and 10/11**, the `DELTASABER` plates (Q2) | never seen anywhere in the boot path, the title-side screens or the attract loop. A mission load is the remaining candidate and this container kills runs before one completes | (An earlier version of this table called the audio items blocked on "an emulator diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index 0e7d7d08..3ef44ed1 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -231,3 +231,10 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the scoped that way reported "no jump tables" for a function with two known ones. Scope by `address between and ` instead, and gate any such query on a function whose answer you already know. +* **Before testing "state X behaves like this", check that your route actually + reaches state X.** A test of "does β’Ά work in phase 4 state 0" was run by + pressing β’·, on the strength of a decoded `4 β†’ state 0` edge β€” but the same basic + block also writes the *phase* field, sending it to phase 2. The test probed the + wrong state and produced a confident refutation of a live hypothesis. When a + transition sets more than one field, read the whole block, not the one store you + were looking for. diff --git a/docs/re/REFUTED.md b/docs/re/REFUTED.md index 57485477..416841a7 100644 --- a/docs/re/REFUTED.md +++ b/docs/re/REFUTED.md @@ -35,9 +35,12 @@ neighbourhood, not just the line. ## Screens, classes and RTTI -* "the boot title is phase 2 and the attract title is phase 4 state 0, and only - phase 2 handles β’Ά" β†’ **mine, and refuted the next iteration.** β’· from the menu - is the decoded edge `4 β†’ 0`, and β’Ά on that returned title opens the menu. +* ~~"the boot title is phase 2 and the attract title is phase 4 state 0, and only + phase 2 handles β’Ά" β†’ refuted~~ β€” **the REFUTATION is withdrawn.** The test + assumed β’· lands in phase 4 state 0; the event-0 block actually sets + **phase = 2** and state = 0 together, so it probed phase 2. The hypothesis is + untested, not dead. + [`boot-config-and-gamepart-registry.md`](boot-config-and-gamepart-registry.md) * "any title after the first one refuses input" β†’ too broad. The **β’·-returned title accepts β’Ά**; only the **attract**-returned title is inert. [`canary-scripted-input-traps.md`](canary-scripted-input-traps.md) diff --git a/docs/re/boot-config-and-gamepart-registry.md b/docs/re/boot-config-and-gamepart-registry.md index 9ba374a1..9603d6c0 100644 --- a/docs/re/boot-config-and-gamepart-registry.md +++ b/docs/re/boot-config-and-gamepart-registry.md @@ -535,3 +535,49 @@ Counting `stw rX, 136(r30)` per phase returned **0 for phase 4**, which is known to have 18 β€” the operand text is `r11, 136(r30)` and the pattern did not allow the space. The per-phase store counts were discarded. The `bctr` half *does* pass its control (phase 4 shows both known tables) and is reported above. + + +## βœ… The phase transitions β€” and they invalidate yesterday's test + +Nine stores to the phase field `this+132` across the `GamePart_Title` +neighbourhood, attributed to the handler each lives in (control: the same query +shape finds 30 stores to `this+136`, β‰₯ the 18 known in phase 4): + +| store | sets phase | lives in | +|---|---|---| +| `0x821c4fbc` | 2 | outside the handlers (entry/setup) | +| `0x821c4fe0`, `0x821c4fec` | 4 | outside the handlers | +| `0x821c5010` | *(not an immediate)* | outside the handlers | +| `0x821c592c` | **0** | phase 2 | +| `0x821c5b00` | **3** | phase 2 | +| `0x821c6370` | **4** | phase 3 | +| **`0x821c6e04`** | **2** | **phase 4, in the event-0 block** | +| `0x821c7950` | 2 | the dispatcher | + +``` +entry β†’ 2 2 β†’ 0 (splash) 2 β†’ 3 3 β†’ 4 4 β†’ 2 (event 0) +``` + +### πŸ”΄ Withdrawing the refutation from the previous iteration + +The event-0 block sets **both** fields, one instruction apart: + +``` +821c6df8 li r11, 2 +821c6e00 stw r28, 136(r30) ; state = 0 +821c6e04 stw r11, 132(r30) ; phase = 2 +``` + +So **β’· from the menu lands in phase 2**, not phase 4 state 0. The previous section +tested "β’Ά on the β’·-returned title" believing it was probing phase 4 state 0 β€” +**it was probing phase 2**, the same phase as the boot title. + +The test therefore says nothing about phase 4 state 0, and the refutation it +produced is **withdrawn**. Worse for me and better for the idea: β’Ά working there +is exactly what the hypothesis predicts, since phase 2 is the phase that +references `BUTTON`. + +**Status of the hypothesis: untested, and now consistent with two observations** +(β’Ά works on the boot title and on the β’·-returned title, both phase 2). What it +still needs is the **attract**-returned title's phase β€” the one thing no test so +far has read. diff --git a/docs/re/canary-scripted-input-traps.md b/docs/re/canary-scripted-input-traps.md index 073674bb..84e073ba 100644 --- a/docs/re/canary-scripted-input-traps.md +++ b/docs/re/canary-scripted-input-traps.md @@ -660,7 +660,7 @@ state 0 (`sub_821C6458`). Same screen, different code. See **Candidate:** the boot title is phase 2; the attract-returned title is phase 4 state 0; only one of them wires up β’Ά. -### πŸ”΄ Tested the same day β€” and the candidate is dead +### ⚠️ Tested the same day, and the TEST was invalid β€” see the withdrawal below There was a cheaper test than reading `this+132`: the state graph says β’· from the main menu goes `4 β†’ 0`, so **the β’·-returned title *is* phase 4 state 0**. If phase @@ -673,12 +673,18 @@ main menu goes `4 β†’ 0`, so **the β’·-returned title *is* phase 4 state 0**. If | *control* β€” β’Ά on the boot title | β†’ main menu βœ… | | β’Ά on the **β’·-returned** title | β†’ **main menu** βœ… | -So phase 4 state 0 does wire up β’Ά, and "the boot title is phase 2, the returned -title is phase 4 state 0, only phase 2 handles β’Ά" is **refuted**. (Conditional on -the graph reading that β’· lands in state 0 β€” that edge is decoded, but which -*title* it produces is my inference.) +**πŸ”΄ Withdrawn.** Reading the event-0 block in full shows it sets **two** fields, +one instruction apart: `stw r28, 136(r30)` (state = 0) *and* `stw r11, 132(r30)` +with `r11 = 2` β€” **phase = 2**. So β’· lands in **phase 2**, the same phase as the +boot title, and this test never probed phase 4 state 0 at all. -### βœ… What the test did establish β€” the puzzle is narrower than this page says +The refutation is withdrawn. β’Ά working on the β’·-returned title is exactly what +the hypothesis predicts β€” phase 2 is the phase that references `BUTTON`. + +### βœ… What the test DID establish β€” the puzzle is narrower than this page says + +(This part stands: it is a measurement, independent of which phase the returned +title turns out to be.) This page frames the problem as *the boot title accepts β’Ά, a later title does not*. That is too broad. **The β’·-returned title accepts β’Ά perfectly well** β€” a