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

re: the boot sequence is not data-driven -- closing Q6 with the negative

Browse Source 
rather than leaving it amber

Q6's second half asked what the game READS to decide the boot order. The
answer is nothing, and the value here is the reach rather than a find.

Four places checked, the order in none of them: config.ini's [SYSTEM] is
empty and it is the disc's only config; the movie manifest carries the
boot-side assets but no transitions; the requested GamePart id was
already shown to exist only as a stack argument in flight, with no
persistent field and no literal store; and the string GP_ADVERTISE_DEMO
has zero xrefs of any kind, so nothing in the code reads the attract
entry of the id table. A transition is a call with an id argument.

Traced as far as it goes cheaply: the RegisterToFactory<0,
GamePart_Title> string is referenced from exactly one site,
sub_8280E148, which also takes the address of sub_821C7D98 -- where a
factory template puts its creator. Marked amber, because that is position
and convention rather than proof, and sub_821C7D98 has zero .rdata
references, which fits a new+ctor thunk and not a state machine. The
substantial function in that neighbourhood is sub_821C6458 and I did not
read it.

So Q6 closes as answered with the driver classified as code rather than
data, which means the port AUTHORS the sequence -- and that is fine,
because the sequence itself is measured end to end and the handoff now
carries it in one line.
This commit is contained in:
Sylpheed RE agent
2026-08-28 18:53:14 +00:00
parent c8e8dc0427
commit c760cdc509
3 changed files with 54 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
docs/re/REFUTED.md
View File

@@ -35,6 +35,9 @@ neighbourhood, not just the line.
## Screens, classes and RTTI
* "the boot sequence is driven by a table the game reads" → it is **not
data-driven**; four search spaces closed, transitions are calls with an id
argument. [`boot-config-and-gamepart-registry.md`](boot-config-and-gamepart-registry.md)
* "`config.ini` is a GamePart settings table, so the boot order is in it" → its
`[SYSTEM]` section is **empty**; the only populated section is `[LANGUAGE]`.
[`boot-config-and-gamepart-registry.md`](boot-config-and-gamepart-registry.md)

41
docs/re/boot-config-and-gamepart-registry.md
View File

@@ -91,3 +91,44 @@ manifest gives the boot-side **assets** in play order
the registry gives **which parts exist**. What decides to advance is in
`GamePart_Title`'s own code, and reading it is a static PPC job that has not been
started.
## ❔ The transitions are code, not data — the reach of that negative
Q6's remaining half asked what the game *reads* to decide the boot order. The
answer is: **nothing. It is not data-driven.** Four independent places were
checked, and the sequence is in none of them.
| looked in | result |
|---|---|
| **disc configuration** | `config.ini` is the only config file on the disc, its `[SYSTEM]` section is empty (above) |
| **the movie manifest** | carries the boot-side *assets* in play order, and no transitions — [`movie-binding.md`](movie-binding.md) |
| **a persistent part-id field** | already refuted: the requested GamePart id exists **only as a stack argument in flight**, with no literal store anywhere — [`challenge-mission-gate.md`](challenge-mission-gate.md) §5 |
| **the id table's attract entry** | the string `GP_ADVERTISE_DEMO` at `0x820a1fe8` has **zero xrefs of any kind**; nothing in the code reads it |
So a transition is a **call with an id argument**, chosen by code. There is no
table to read and nothing to poke.
**Where that code is, as far as it was traced.** The `RegisterToFactory<0, class
silph::GamePart_Title>` diagnostic string at `0x820a3d60` is referenced from
exactly one place, `sub_8280E148` — the registration site — which also takes the
address of **`sub_821C7D98`** (`addi`), the position a factory template puts its
creator. 🟡 That identification is by position and convention, not proven;
`sub_821C7D98` itself has **0 `.rdata` references**, consistent with a small
`new`+ctor thunk rather than the state machine. The substantial function in the
same class neighbourhood is `sub_821C6458` (4 460 bytes, has EH, 15 `.rdata`
refs), and **reading it has not been attempted**.
### What this means for the port
The boot sequence is **authored**, not transcribed — and that is fine, because the
sequence itself is measured end to end:
```
developer splash (a RATC screen, not a video)
→ ADV.wmv
→ title + PRESS Ⓐ ──idle ~8–10 s──> fade to black → ADV.wmv in full → title
→ Ⓐ → main menu
```
with the fade-through-black timings in [`screen-transitions.md`](screen-transitions.md)
and Ⓑ from the main menu returning to the title.