From 52275ddd530e4377d01429d736ed82d6b951c0c9 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Fri, 28 Aug 2026 20:00:49 +0000 Subject: [PATCH] re: state 4's edges are selected by an event code -- 6 of 26 handled Continuing Q6's last item: the condition on each edge. sub_821C6458's third argument is an EVENT CODE, and state 4 -- reached straight after the main menu is installed, so the input-waiting state -- dispatches on it through a second jump table at 0x821c6b7c, 26 cases. Six are handled and twenty fall through changing nothing: event 0 -> state 0 (TITLE_SCREEN, back to the title) events 3, 5, 8, 25 -> state 8 (LOADING) event 10 -> state 5 So the edges I listed last iteration as "4 -> 0, 5, 8x4" are each now attributed to a specific event, and the input state's graph is complete. One thing I deliberately did NOT promote. The main menu has five items, B returns to the title, and this table has one event to the title, four to LOADING and one elsewhere. That is a tempting fit -- B plus four items that load an external archive plus EXTRAS staying inside GP_TITLE -- and it matches everything measured. It is also a count-match and nothing more: the events are unnamed, nothing shows event 3 is a particular menu row, and state 5 installs no named screen so the EXTRAS half has no support at all. Written down as an observation with that said plainly, because the same shape of reasoning already cost me DIFFICULTY and EXTRA_MENU two iterations ago. Still open: what the event numbers mean, the conditions on edges out of the other states, and what states 1/3/5/6/7/9 do. --- docs/port/HANDOFF.md | 12 +++-- docs/re/boot-config-and-gamepart-registry.md | 49 ++++++++++++++++++++ docs/re/data/title-state-machine.txt | 21 ++++++++- 3 files changed, 78 insertions(+), 4 deletions(-) diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index 24419672..4ee9ff4f 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -212,8 +212,14 @@ authored version can be deleted. `LOADING`. `4 β†’ 0` is the only edge back to the title, reached from `2 β†’ 4` β€” which matches β’·-returns-to-title as measured. Full graph in [`data/title-state-machine.txt`](../re/data/title-state-machine.txt). - 🟑 The **conditions** on the edges are not decoded, so the port still takes the - order from measurement; the graph corroborates it rather than replacing it. The sequence itself is fully measured: + βœ… **State 4's edge conditions are an event code** β€” `sub_821C6458`'s third + argument. State 4 is the input-waiting state (reached straight after the menu + is installed) and handles 6 of 26 events: **`0` β†’ title**, **`3`, `5`, `8`, + `25` β†’ `LOADING`**, `10` β†’ state 5. + 🟑 What the event *numbers* mean is not decoded β€” button id, menu row, or + message id β€” so the port still takes the buttonβ†’destination map from + measurement. The one-to-title / four-to-loading shape matches the five-item + menu with β’·, but that is a **count-match, not a mapping**. The sequence itself is fully measured: splash β†’ `ADV.wmv` β†’ title + `PRESS β’Ά` β†’ (idle ~8–10 s β†’ `ADV.wmv` in full β†’ title) β†’ β’Ά β†’ main menu, with β’· from the main menu returning to the title. @@ -290,7 +296,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) | **the state machine is decoded** β€” `state = this+136`, ten states, jump table at `0x821C6498`, 18 literal transitions; states 0/2/8 install `TITLE_SCREEN`/`TITLE_MENU`/`LOADING`. Still unread: the **condition** on each edge | +| 🟑 | **the boot transitions in code** (Q6) | state machine **decoded** (10 states, 18 edges) and state 4's edges are selected by an **event code** β€” 6 of 26 handled: `0`β†’title, `3/5/8/25`β†’`LOADING`, `10`β†’state 5. Still unknown: what the event *numbers* mean | | ❔ | **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/boot-config-and-gamepart-registry.md b/docs/re/boot-config-and-gamepart-registry.md index 3c96f76d..d7848165 100644 --- a/docs/re/boot-config-and-gamepart-registry.md +++ b/docs/re/boot-config-and-gamepart-registry.md @@ -350,3 +350,52 @@ which branch. * **states 1, 3, 5, 6, 7, 9** install no named screen, so what they do is unknown; * **state 3 is never a destination** in this function, so something outside sets it. + + +## βœ… The edge conditions, for the state that has them β€” an EVENT CODE + +The previous section left "the condition on each edge" open. For the state that +matters it is now read. + +**`sub_821C6458`'s third argument is an event code.** State 4 β€” reached from +`2 β†’ 4`, i.e. immediately after the main menu is installed β€” is the +**input-waiting state**, and it dispatches on that argument: + +``` +821c6b5c cmplwi cr6, r27, 0x19 ; 26 events, 0..25 +821c6b60 bgt cr6, +821c6b68 addi r12, r12, 27516 ; second jump table, at 0x821c6b7c +821c6b78 bctr +``` + +**Six of the 26 are handled**; the other twenty fall through and change nothing. + +| event | β†’ state | | +|---|---|---| +| **0** | **0** | `TITLE_SCREEN` β€” back to the title | +| 3 | 8 | `LOADING` | +| 5 | 8 | `LOADING` | +| 8 | 8 | `LOADING` | +| 10 | 5 | β€” | +| 25 | 8 | `LOADING` | + +So last section's edges `4 β†’ 0, 5, 8Γ—4` are each now attributed to a specific +event, and the shape of the state graph is complete for the input state. + +### 🟑 A correspondence worth noticing, and not more than that + +The main menu has five items, β’· returns to the title, and this table has **one +event to state 0, four to `LOADING`, one elsewhere**. It is tempting to read that +as *β’· = event 0, four items load an external archive, `EXTRAS` stays inside +`GP_TITLE`* β€” which would match everything measured. + +**That is a count-match, not a decode.** The event numbers are not named, nothing +here shows event 3 is a particular menu row, and state 5 installs no named screen, +so the `EXTRAS` half of the story has no support at all. Recorded as an +observation so the next person sees the shape; it is **not** a buttonβ†’event map. + +### What is still not decoded + +* **what the event numbers mean** β€” button id, menu-item index, or message id; +* **conditions on edges out of the other states** (`0 β†’ 1` vs `0 β†’ 2`, `6 β†’ 7/9/2`); +* states 1, 3, 5, 6, 7, 9, which install no named screen. diff --git a/docs/re/data/title-state-machine.txt b/docs/re/data/title-state-machine.txt index 519d7d78..dc9311ae 100644 --- a/docs/re/data/title-state-machine.txt +++ b/docs/re/data/title-state-machine.txt @@ -48,8 +48,27 @@ TRANSITIONS -- every `li rX,N ; stw rX,136(r30)` in the function 8 2 0x821c7548 (state 9 stores nothing -- terminal within this function) +THE CONDITION ON STATE 4's EDGES -- decoded + sub_821C6458(this, ?, r5) takes an EVENT CODE in its third argument. + State 4 -- the input-waiting state -- dispatches on it: + + 821c6b5c cmplwi cr6, r27, 0x19 ; 26 events, 0..25 + 821c6b60 bgt cr6, + 821c6b68 addi r12, r12, 27516 ; table at 0x821c6b7c + 821c6b78 bctr + + Only 6 of the 26 are handled; the other 20 fall through with no state change. + + event 0 -> block 0x821c6be4 -> state 0 (TITLE_SCREEN -- back to the title) + event 3 -> block 0x821c6e78 -> state 8 (LOADING) + event 5 -> block 0x821c6f84 -> state 8 (LOADING) + event 8 -> block 0x821c6f34 -> state 8 (LOADING) + event 10 -> block 0x821c6e28 -> state 5 + event 25 -> block 0x821c6ed8 -> state 8 (LOADING) + WHAT IS NOT DECODED - * the CONDITION on each edge -- which input or event selects it; + * what the event NUMBERS mean -- button id, menu-item id or message id; + * the conditions on edges out of states other than 4; * what states 1, 3, 5, 6, 7 and 9 do (they install no named screen); * state 3 is never a destination here, so something outside this function sets it.