fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: phase 0 is the splash, phase 2 is the title -- and a candidate answer

Browse Source 
to this corpus's oldest input puzzle

Continuing Q6 on the phases left unread. Strings each phase handler
references, plus whether it carries its own jump table:

  phase 0  sub_821C5690   LOGO                                    no switch
  phase 2  sub_821C5818   BASE_INFO, BUTTON, TITLE_SCREEN         no switch
  phase 3  sub_821C5EC0   (none)                                  one switch
  phase 4  sub_821C6458   BASE_INFO, LOADING, TITLE_MENU, TITLE_SCREEN

Phase 0 referencing LOGO is a second independent confirmation that it is
the developer splash -- the iterate3E notes reached the same function
from the guest side and named the splash's LOGO items. Phase 2 draws the
title WITH the PRESS A plate, which the archive side had already
established is a build of its own.

Which produces something worth more than either: the title is installed
from TWO places, phase 2 and phase 4 state 0. Same screen, different
code. canary-scripted-input-traps.md has recorded for months, and never
explained, that the boot title accepts A while the attract-returned title
accepts nothing, with the giveaway that a draw capture in each is
identical. Two code paths installing one screen is exactly that shape. I
have written it into that page as a candidate with the cheap test named
-- read this+132 on each title -- and marked it untested, because it is.

One query in this iteration failed its own control and I threw its half
away: counting stw rX,136(r30) per phase returned 0 for phase 4, which
has 18, because the operand text has a space the pattern did not allow.
The bctr half passes its control and is reported. METHOD gets the
underlying trap: instructions.function is unpopulated for most rows, so a
query scoped on it silently returns nothing.
This commit is contained in:
Sylpheed RE agent
2026-08-28 20:15:02 +00:00
parent 86e52b01d0
commit 4380305921
4 changed files with 76 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
docs/re/canary-scripted-input-traps.md
View File

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