diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index 931aa1bf..4587ca3b 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -304,7 +304,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` (phase 0 = the splash, phase 4 = title/menu) and a 10-way state at `this+136` inside phase 4, with 18 edges selected by an **event code**. Unknown: what the event *numbers* mean, and phases 1–3 | +| 🟡 | **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 | | ❔ | **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 6371582d..0e7d7d08 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -226,3 +226,8 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the rather than a whole wave. They match `BGM_103` exactly — the check had covered only the `BGM_0xx` rows of the census, because that is the block that had been on screen. +* **`instructions.function` is unpopulated for most rows in `sylpheed.db`.** A + query keyed on it returns *nothing* rather than erroring — a `bctr` search + 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. diff --git a/docs/re/boot-config-and-gamepart-registry.md b/docs/re/boot-config-and-gamepart-registry.md index 81303c4f..5586b031 100644 --- a/docs/re/boot-config-and-gamepart-registry.md +++ b/docs/re/boot-config-and-gamepart-registry.md @@ -483,3 +483,53 @@ The same function, a few instructions earlier: **1103 is a BGM cue id** — `BGM_103`. That closes an open residual from Q8/Q10 ("which bank is the menu's music is not on the disc"), and it checks out three ways; see [`structures/bgm-two-stems.md`](structures/bgm-two-stems.md). + + +## The other phases, characterised — and phase 0 confirms the splash twice over + +Same treatment for the phase handlers that were still unread. Strings each one +references, and whether it carries a jump table of its own: + +| phase | handler | size | strings referenced | own switch | +|---|---|---|---|---| +| 0 | `sub_821C5690` | 380 | **`LOGO`** | none | +| 2 | `sub_821C5818` | 1 576 | `BASE_INFO`, **`BUTTON`**, **`TITLE_SCREEN`** | none | +| 3 | `sub_821C5EC0` | 1 220 | *(none)* | one, `bctr` at `0x821c5ef8` | +| 4 | `sub_821C6458` | 4 460 | `BASE_INFO`, `LOADING`, `TITLE_MENU`, `TITLE_SCREEN` | two (known) | + +**Phase 0 references `LOGO`** — a second, independent confirmation that it is the +developer splash. The `iterate3E` notes reached `sub_821C5690` from the guest side +and named the splash's `LOGO` items; this reaches the same function from the +registration site and finds the same string. + +**Phase 2 draws the title *with* the `PRESS Ⓐ BUTTON` plate** — it references +`TITLE_SCREEN` and `BUTTON`, and [`ui-title-build-map.md`](ui-title-build-map.md) +established from the archive that the plate is its own build (2/3), composited +over the title art. + +### 🟡 A hypothesis for a puzzle this corpus has had open for months + +**The title is installed from two different places**: phase 2, and phase 4's +state 0. Same screen, different code. + +[`canary-scripted-input-traps.md`](canary-scripted-input-traps.md) has long +recorded, and never explained, that *the title which ends the boot accepts Ⓐ while +the title the attract loop returns to accepts nothing* — with the giveaway that a +draw capture in each state is identical, 13 quads at the same rects. Two code +paths installing the same screen is exactly the shape that would produce that. + +**Candidate:** the boot title is **phase 2**; the attract-returned title is +**phase 4, state 0**. Only phase 2 wires up the Ⓐ handling. + +⚠️ **This is a hypothesis and nothing more** — it is consistent with the draw +captures and with the phase structure, and it is completely untested. **The test +is cheap**: read `this+132` (the phase field) at runtime on the boot title and +again on the attract title. If they differ, the puzzle is solved; if they match, +this is dead. + +### ⚠️ One query in this section failed its own control + +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. diff --git a/docs/re/canary-scripted-input-traps.md b/docs/re/canary-scripted-input-traps.md index 7b85f5af..7cf037ed 100644 --- a/docs/re/canary-scripted-input-traps.md +++ b/docs/re/canary-scripted-input-traps.md @@ -643,3 +643,23 @@ Two lessons, both cheap: The evidence recovered cleanly once the interference stopped — the interrupted batch's own run 3 had already reached the menu with the same 40 calls / 6 `ResolvePath` signature. + + +## 2026-08-28 — a candidate explanation, from the static side + +This page's oldest open question is **why the attract-returned title accepts no +input while the boot title does**, given that a draw capture in each state is +identical (13 quads, same rects). + +`GamePart_Title` turns out to dispatch on an outer **phase** field at `this+132`, +and **the title screen is installed from two different phases** — phase 2 +(`sub_821C5818`, which references `TITLE_SCREEN` *and* `BUTTON`) and phase 4's +state 0 (`sub_821C6458`). Same screen, different code. See +[`boot-config-and-gamepart-registry.md`](boot-config-and-gamepart-registry.md). + +**Candidate:** the boot title is phase 2; the attract-returned title is phase 4 +state 0; only one of them wires up Ⓐ. + +🟡 **Untested.** The cheap test is to read `this+132` at runtime on the boot title +and again after the attract loop returns. Different values would settle this +page's oldest question; identical values kill the idea outright.