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

2
docs/port/HANDOFF.md
View File

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