jan/rrt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Decode infrastructure chooser asset families

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 15:09:08 -07:00
commit 3ae6431f74
3 changed files with 78 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

28
docs/rehost-queue.md
View file

@ -152,13 +152,27 @@ Working rule:
`0x0002 / 0xff` as the grounded save-side bridge-specific two-child candidate class above
`0x0048a1e0/0x0048dcf0`, with the remaining unknown narrowed to the upstream chooser that emits
that class before the attach/rebuild path runs.
- That upstream chooser is grounded now too: direct disassembly of `0x004a2c80..0x004a37de`
shows a dense infrastructure composition strip repeatedly calling `0x0048a1e0`, branching on
`[this+0x226]`, selector bytes `[this+0x219]/[this+0x251]`, bit `0x20` in `[this+0x24c]`, and
lookup tables `0x621a44..0x621a9c`, then routing follow-on through
`0x0048a340/0x0048f4c0/0x00490200/0x00490960`. So the remaining infrastructure question is no
longer “is there an upstream chooser?” but “which lookup-table families inside that chooser map
to the grounded `0x0002 / 0xff` bridge class and the `0x0055 / 0x00` BallastCap class?”.
- That upstream chooser is grounded now too as paired siblings: direct disassembly shows
`0x004a2c80` routing the `DT` family and `0x004a34e0` routing the `ST` family, with both
repeatedly calling `0x0048a1e0`, branching on `[this+0x226]`, selector bytes
`[this+0x219]/[this+0x251]`, bit `0x20` in `[this+0x24c]`, and lookup tables `0x621a44..0x621a9c`,
then routing follow-on through `0x0048a340/0x0048f4c0/0x00490200/0x00490960`. So the remaining
infrastructure question is no longer “is there an upstream chooser?” but “how do the save-side
classes select the `DT` versus `ST` chooser sibling, and then which lookup-table families inside
that sibling map to the grounded `0x0002 / 0xff` bridge class and the `0x0055 / 0x00`
BallastCap class?”.
- Those lookup tables are decoded now too: `0x621a44/0x621a54` feed `BridgeST` caps/sections,
`0x621a64` feeds `TunnelST` cap/section variants, `0x621a74/0x621a84` feed `BridgeDT`
caps/sections, and `0x621a94` feeds `TunnelDT` variants, while fixed literals
`0x5cb138/0x5cb150` are `BallastCapDT/ST` and `0x5cb168/0x5cb180` are `OverpassDT/ST`. So the
remaining infrastructure question is no longer table discovery; it is the selector-byte mapping
from `[this+0x219]/[this+0x251]/[this+0x252]` onto those decoded families and then onto the
grounded `0x38a5` prefix classes.
- One selector byte is partly grounded now too: when `[this+0x219]==2`, the chooser jump tables
stop using the general bridge families and instead route `[this+0x252]` through fixed
`BridgeDT/BridgeST` suspension-cap literals for `R10`, `L10`, `12`, `14`, `16`, and `18`.
So the remaining infrastructure selector problem is mostly `[this+0x219]/[this+0x251]` family
choice plus the exact save-side class mapping for the BallastCap branch.
- Reconstruct the save-side region record body on top of the newly corrected non-direct tagged
region seam (`0x5209/0x520a/0x520b`, stride hint `0x06`, `Marker09` record stems) now that the
`0x55f3` payload is known to be fully consumed by the embedded profile collection on grounded