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

re: the base-solver's confidence axis was inverted

Browse Source 
The remaining named false-positive mode - "107 rows solve to a 64K-boundary
base, a bare addis with no addi of its own, so any scatter of displacements
votes for it" - is refuted by its own measurement.

New positive test in the tool: simulate lis/addis rD,r0,HI + addi rD,rA,N +
or rD,rA,rA forward through each row's function and ask whether the solved
base lands in the solved register.

  64K-boundary bases ("low confidence") : 107 / 107 confirmed
  non-zero low half ("trustworthy")     :   8 / 154 confirmed

A round base is the case where the compiler needed no second instruction, so
`addis r11, r0, 0x820B` stands in the code in full. A miss on the other class
is silence (base built in the caller or loaded from memory), not refutation.

Control: every row the corpus independently validated against the disc has a
64K-boundary base - debriefing, career, save, leaderboard, the 205-name PG*
HUD roster, material slots, the S16 boss collision/frames/motions and its
loader. 13 rows over 10 functions. The dense-short-string false positives the
corpus did name (r31 = 0x8202xxxx) all sit in the "trustworthy" class.

The 0x820B0000 cluster is DUPLICATION, not error: 60 of its 82 rows are one
function emitted 60 times, exactly 491 instructions each, two instructions
differing (both global data pointers), identical 41-address string sequences.
40 resource names written into a per-copy global via sub_8217FA08 at 24-byte
strides. 38 of the 40 are disc GameResourceID values (480 distinct); rot_n001
and rou_e202 are not, and no disc GameResourceID uses the rot_ prefix.

Artefact diff 13/4, confined to the replaced section; the 261-row table and
the 64K histogram untouched; byte-identical on a second run. Fourteen other
artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-28 00:42:46 +00:00
parent bb6fb9024b
commit 105ccab038
4 changed files with 222 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

64
docs/re/BACKLOG.md
View File

@@ -5553,3 +5553,67 @@ was a second one. **The shortlist is now empty.** Still open: whether a `stvx`-
style helper elsewhere fooled a *non*-`r0` row (the 64K-boundary cluster is the
remaining known false-positive mode, unaddressed); `Detail_Window_Known/_Unknown`;
whether `Extra01…04` map onto the challenge missions.
---
## 🔴✅ 2026-08-28 — the base-solver's confidence axis was inverted
Item (a): the remaining named false-positive mode, "**107 rows solve to a base on
a 64K boundary — a bare `addis rX, r0, 0xHHHH` with no `addi` of its own, so any
scatter of displacements votes for it**". **Refuted, and by its own measurement.**
**The test, now in the tool.** Simulate `lis`/`addis rD, r0, HI`,
`addi rD, rA, N` and `or rD, rA, rA` forward through each row's own function and
ask whether the solved base ever lands in the solved register — positive
confirmation from the instruction stream, independent of the displacement vote.
* bases on a **64K boundary** ("low confidence"): **107 / 107 confirmed**
* bases with a **non-zero low half** ("trustworthy"): **8 / 154 confirmed**
A 64K-boundary base is the case where the compiler needed **no second
instruction**, so `addis r11, r0, 0x820B` stands in the code in full. A non-zero
low half usually means the base was built in the caller or loaded from memory,
which the simulation cannot see — a miss there is silence, not a refutation
(the control `sub_82341A20 r30` is one such silence; it stands on 217/226 and on
the disc).
🔑 **The control that settles it: every row the corpus independently validated
against the disc has a 64K-boundary base** — debriefing `sub_822814D8`, career
`sub_8227A3A0`, save `sub_82286BC8`, leaderboard `sub_8219E560`, the 205-name
`PG*` HUD roster `sub_822215D0` (r11 and r10), material slots + shader constants
`sub_822E3EC8` (r11 and r10), the S16 boss collision/frames/motions
`sub_823AE908` / `sub_823BDAA8` (r11 and r10) / `sub_823C0260`, and the boss
loader `sub_82315AE8`. Thirteen rows over ten functions. Meanwhile the
dense-short-string false positives the corpus *did* name — the
`r31 = 0x8202xxxx` rows — all sit in the class that was called trustworthy.
**The axis pointed the wrong way in both directions.**
✅ **What the `0x820B0000` cluster actually is: duplication, not error.** 82 rows
carry that base and **60 are one function emitted 60 times** — exactly **491
instructions** each, and diffing any two, **two instructions differ**, both a
global data pointer (`addi r30, r11, 14272` vs `15552`; `addi r3, r11, -13024` vs
`-12984`). All 60 reference an **identical sequence of 41 string addresses**,
writing 40 resource names into a per-copy global through
`sub_8217FA08(dest, name, -1)` at 24-byte strides. A static array duplicated once
per translation unit. The resolution ratio cannot show that, and the confirmation
test does not care.
The roster is 30 `rou_*`, 6 `mob_*`, 3 `rob_*`, 1 `rot_*`, and **38 of the 40 are
`GameResourceID` values on the disc** (480 distinct, each used once).
[[collisionset]] owns the prefix vocabulary and the `GameResourceID` link; what it
does not say is that the image compiles a fixed 40-name subset. 🟡 The two that
are not disc `GameResourceID`s: **`rot_n001`** — and no disc `GameResourceID` uses
the `rot_` prefix at all (`eff` 197, `rou` 172, `mob` 71, `wep` 23, `rob` 4,
`stg*` 9) — and **`rou_e202`**, whose siblings `rou_e201` and `rou_e901` are both
present.
Artefact diff is 13 added / 4 removed, confined to the replaced section; the
261-row table and the 64K-base histogram are untouched, and the file is
byte-identical on a second run. Written up in
`docs/re/structures/player-tuning-tables.md`.
🟡 Not settled: what reads the 60 duplicated globals; what selects 40 of the disc's
172 `rou_*` ids; whether `rot_n001` / `rou_e202` appear anywhere else on the disc.
**Both of the solver's named false-positive modes are now closed — one real
(`r0`), one refuted (the 64K flag).** What remains unmeasured is the 146 rows the
positive test is silent on.

17
docs/re/data/name-block-bases.txt
View File

@@ -268,16 +268,25 @@
sub_82766DB0 r11 0x82050000 12 / 29
sub_827D7C00 r11 0x82060000 12 / 14
## Confidence split
bases with a non-zero low half (a real `addis`+`addi` pair): 154
bases on a 64K boundary (LOW CONFIDENCE, see below) : 107
## Is the base built by the function itself? (positive test only)
rows whose function materialises the solved base into the solved register: 115 / 261
bases on a 64K boundary : 107 / 107
bases with a non-zero low half : 8 / 154
A 64K-boundary base is `addis rX, r0, 0xHHHH` written out in full, so it confirms
directly; it is NOT the low-confidence class it was first called. A non-zero low
half usually means the base was built in the caller or loaded from memory, which
the simulation cannot see -- a miss there is silence, not a refutation.
64K-boundary bases by value:
0x820B0000 x82 rows
0x82030000 x10 rows
0x82050000 x7 rows
0x820A0000 x5 rows
0x82040000 x2 rows
0x82060000 x1 rows
⚠ the 0x820B0000 cluster is ~60 near-identical functions in 0x8281xxxx-0x8284xxxx that all name the same `rou_e0NN` list.
⚠ 60 of the 0x820B0000 rows are one function emitted 60 times: exactly 491
instructions each, an identical sequence of 41 string addresses, differing only
in two global data pointers. That is DUPLICATION, not error.
## Is the row a DATA-TABLE schema? (names that are IDXD record/field names on the disc)
distinct IDXD record+field names disc-wide: 13450

75
docs/re/structures/player-tuning-tables.md
View File

@@ -360,3 +360,78 @@ region, and by the same mechanism).
🟡 What this does **not** settle: the 🟡 stalled `SpaceSize` / `GlareType` /
`Nebura_*` numerics are no closer — their reader was already known to be
`sub_8230D1F8`, and the r0 row never was a second one.
## 🔴 CORRECTION (2026-08-28) — the confidence axis was inverted
Having killed the `r0` rows, the other named false-positive mode was "**107 rows
solve to a base on a 64K boundary — a bare `addis rX, r0, 0xHHHH` with no `addi`
of its own, so any scatter of displacements votes for it**". That reasoning is
wrong, and the measurement says so.
**The test.** The solver now simulates `lis`/`addis rD, r0, HI`, `addi rD, rA, N`
and `or rD, rA, rA` forward through each row's own function and asks whether the
**solved base ever lands in the solved register**. That is positive confirmation
from the instruction stream, independent of the displacement vote.
| | confirmed |
|---|---|
| bases on a **64K boundary** ("low confidence") | **107 / 107** |
| bases with a non-zero low half ("trustworthy") | **8 / 154** |
A 64K-boundary base is not evidence of a weak vote — it is the case where the
compiler needed **no second instruction**, so `addis r11, r0, 0x820B` stands in
the code in full and the base can be read off directly. A non-zero low half
usually means the base was built in the **caller** or loaded from memory, which
the simulation cannot see; a miss there is silence, not a refutation. (The
control, `sub_82341A20 r30 = 0x82088F94`, is one of those silences — it is
validated by its 217/226 resolution and by the disc, not by this test.)
🔑 **The control that settles it: every row the corpus independently validated
against the disc has a 64K-boundary base.**
| row | base | what it is, verified elsewhere |
|---|---|---|
| `sub_822814D8` r11 | `0x820B0000` | debriefing keys, 21 `STAGE_RESULT` fields |
| `sub_8227A3A0` r11 | `0x820B0000` | career keys, `OVERVIEW` 9 / `EX_OVERVIEW` 7 |
| `sub_82286BC8` r11 | `0x820B0000` | save-screen keys ([[savegame-format]]) |
| `sub_8219E560` r11 | `0x820A0000` | leaderboard, 13 records + 5 fields |
| `sub_822215D0` r11 / r10 | `0x820A0000` | the 205-name `PG*` HUD roster ([[hud-config]]) |
| `sub_822E3EC8` r11 / r10 | `0x820B0000` | shader constants + material slots ([[xbg7-mesh]]) |
| `sub_823AE908` r11, `sub_823BDAA8` r11 / r10, `sub_823C0260` r11 | `0x820B0000` | the S16 boss collision, frames and motions ([[collisionset]], [[stage16-boss]]) |
| `sub_82315AE8` r11 | `0x820B0000` | the S16 boss loader, 19/19 field names |
Thirteen rows over ten functions. Meanwhile the dense-short-string false
positives the corpus *did* name — the `r31 = 0x8202xxxx` rows on
`sub_82341A20`, `sub_8230D1F8`, `sub_822F9498`, `sub_823AE908` — all sit in the
class that was called trustworthy. **The axis pointed the wrong way in both
directions.**
### ✅ What the 0x820B0000 cluster actually is: duplication, not error
82 rows carry base `0x820B0000`, and **60 of them are one function emitted 60
times**. Each is **exactly 491 instructions**; diffing any two, **two
instructions differ**, both of them a global data pointer:
```
9 828110FC addi r30, r11, 14272 | 8281250C addi r30, r11, 15552
487 82811874 addi r3, r11, -13024 | 82812C84 addi r3, r11, -12984
```
Their sequences of string addresses are **identical, all 60** — the same 40
resource names in the same order, written into a per-copy global through
`sub_8217FA08(dest, name, -1)` in 24-byte strides. That is a static array
duplicated once per translation unit, not sixty tables. The index is inflated by
**duplication**, which the resolution ratio cannot show and the confirmation test
does not care about.
The roster itself: 30 `rou_*`, 6 `mob_*`, 3 `rob_*`, 1 `rot_*`. **38 of the 40
are `GameResourceID` values on the disc** (480 distinct, each used once) —
[[collisionset]] owns that prefix vocabulary and the `GameResourceID` link; what
it does not say is that the image compiles a fixed 40-name subset of them.
🟡 The two that are not: **`rot_n001`** — and no disc `GameResourceID` uses the
`rot_` prefix at all (`eff` 197, `rou` 172, `mob` 71, `wep` 23, `rob` 4, `stg*` 9)
— and **`rou_e202`**, whose siblings `rou_e201` and `rou_e901` are both present.
Two names the image carries that this disc field never uses.
🟡 Not settled: what the 60 globals are read by, and what selects 40 of the 172
`rou_*` ids.