re: my phase hypothesis is dead, and the input puzzle is narrower than

this corpus thought

Last iteration I proposed that the boot title is phase 2 and the
attract-returned title is phase 4 state 0, and that only phase 2 wires up
A -- a candidate answer to the oldest open question in
canary-scripted-input-traps.md. I marked it untested and named a test
that needed reading this+132 at runtime.

There was a cheaper one. The decoded graph says B from the main menu is
the edge 4 -> 0, so the B-returned title IS phase 4 state 0. If that
state were the inert one, A would not work there.

A works. Control first -- A on the boot title opened the menu -- then A
on the B-returned title opened it too. So phase 4 state 0 handles A and
the hypothesis is refuted, one iteration after I raised it. Recorded in
REFUTED under my own name, and the conditional stated: the edge is
decoded, but which title it produces is my inference.

The test earned something better than it cost, though. That page frames
the problem as "the boot title accepts A, a later title does not", and
that is too broad -- the B-returned title accepts A perfectly well, a
case nobody had tried. Only the ATTRACT-returned title is inert. Whatever
causes it is tied to the attract cycle specifically rather than to the
title having been shown before, which is a much smaller haystack.

Also reproduced in passing: 4 s after B the plate is absent and fades in
after, the same near-miss this corpus has already been caught by once.
This commit is contained in:
Sylpheed RE agent
2026-08-28 20:21:23 +00:00
parent 736f6b471f
commit ea91c4cbea
4 changed files with 49 additions and 8 deletions

View File

@@ -106,6 +106,10 @@ authored version can be deleted.
blend of **one element on one screen** (a title glow). Take the stable sort and
accept that.
* **Ⓑ returns to the title, and that title still works.** Ⓐ on the Ⓑ-returned
title opens the main menu — measured, with Ⓐ on the boot title as the control in
the same run. (Only the *attract*-returned title is inert, which is an emulator-
harness curiosity, not a port concern.)
* **Menu movement, measured off the running game.** ⬆⬇ move one item per press
and **wrap at both ends** (5-item main menu and 3-item `EXTRAS` both). ⬅➡ do
nothing. Ⓑ goes up one level **and restores focus to the item you came from**;

View File

@@ -35,6 +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.
* "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)
* "`sub_821C6458` is `GamePart_Title`'s state machine" → **mine, imprecise.** It
is the machine for **phase 4** of a five-way outer dispatch at `this+132`;
phase 0 is the splash. The ten states and eighteen edges are phase 4 only.

View File

@@ -521,11 +521,13 @@ 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.
⚠️ **Tested, and dead.** Ⓑ from the main menu is the decoded edge `4 → 0`, so the
Ⓑ-returned title *is* phase 4 state 0 — and **Ⓐ works there**, opening the main
menu, with Ⓐ on the boot title as the control in the same run. Phase 4 state 0
handles Ⓐ, so the two-code-paths explanation is refuted. See
[`canary-scripted-input-traps.md`](canary-scripted-input-traps.md), which the
test did narrow usefully: only the **attract**-returned title is inert, not every
title after the first.
### ⚠️ One query in this section failed its own control

View File

@@ -660,6 +660,35 @@ 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 Ⓐ.
🟡 **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.
### 🔴 Tested the same day — and the candidate is dead
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
4 state 0 were the inert one, Ⓐ would not work there.
**It works.** Measured:
| | |
|---|---|
| *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.)
### ✅ What the test did establish — the puzzle is narrower than this page says
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
case nobody had tried. Only the **attract-returned** title is inert.
So whatever makes the title stop responding is tied to the attract cycle
specifically — the movie playing and coming back — not to "the title has been
shown before". That is a much smaller haystack than the one this page has been
pointing at.
⚠️ Also reproduced in passing: 4 s after Ⓑ the plate is **absent** (169 plate
pixels), and it fades in after. A test that samples too early will read the
returned title as plate-less, which this corpus has already been caught by once.