188e911ec7
A Stage 02 run froze at TIME 01:02 with a radio line caught mid-word. The emulator was alive at ~200% CPU with its main thread in state R, two screenshots six seconds apart were byte-identical, and the log ended in a spin: 1171 of the run's 1200 "host resume was refused" lines are the single pair F80002AC -> F8000240, starting at the line immediately after F80002AC is created, and the log never grows again. The commit that added that warning records what normal looks like - about 7 in a whole boot - so this is a 150x anomaly on one pair rather than noise. F8000240 itself appears exactly once outside the spin, at creation, and calls nothing. Eleven of the frozen process's 79 host threads have zero CPU, four of them consecutive late-created guest threads - the same signature as the lost resume that c1b57f93b fixed for the title screen. That fix IS in this build, so either there is a second window in that race or this only looks alike. The inference is named as one: nothing here maps a guest handle to a host tid, so "the zero-CPU threads are the ones being resumed" is a reading of two consistent observations. And the refusals could equally be the game's reaction to a worker stuck for another reason - log_mask=13 has the Kernel channel disabled, so not one of F8000240's waits is visible. The next experiment is written down concretely: reproduce with LOG_MASK=12 LOG_LEVEL=3 and map the handle to a tid. Also caps ob_hunt's survivor listing at 40 - an aborted run printed all 21482 and buried the line that mattered. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
Runtime-capture harness (sylph-re container)
Screenshot-driven scripts for reading the running retail game's menus under Xenia
Canary + lavapipe, headless. They assume the container helpers screenshot,
vgamepad, pad are on $PATH and HOME=/sylph-home/re.
| Script | What it does |
|---|---|
skip_intro.sh |
Boot → main menu, unattended. Taps A only while the intro movie is actually playing (frame-to-frame RMSE), then once at the PRESS Ⓐ BUTTON title. Static logo screens are left alone, so a stray tap can never land on NEW GAME. |
wait_title.sh |
Older variant: wait for the title (green Ⓐ glyph at px 625,618) and tap A. Superseded by skip_intro.sh. |
step.sh |
One Arsenal navigation step (down/up/next/prev/none) + a compact capture: weapon list stacked over the DATA SHEET. |
sweep.sh |
Walk a whole weapon-type list, capturing only rows that show a DATA SHEET — locked rows (a "Conditions to Develop" panel) are detected by the brightness of the Range Class label box and skipped. |
type.sh |
Change weapon-type tab N times (RB) and report the header strip. |
hp.sh / cyc.sh |
Hangar hard-point carousel: cyc.sh steps it (d-pad down, not left/right) and captures the Name + DATA SHEET. |
Input timing under lavapipe: the game polls input at its own low frame rate, so a 60 ms d-pad tap is dropped roughly half the time. 200 ms is reliable; 300 ms starts to auto-repeat (two rows per press).
Findings produced with these: docs/re/weapon-datasheet-runtime.md.
Guest-memory tools (no screenshots)
| Script | What it does |
|---|---|
gmem.py |
Read the live guest address space out of /dev/shm/xenia_memory_* (Xenia's backing file), addressed by guest VA. find / read / words. |
weapon_runtime.py |
Solve the Weapon/Shell struct layouts against the disc records and read the fields the disc defaults. |
unit_discover.py |
Find which runtime class carries a set of ID strings, assuming no vtable: tallies the word at pointer_site - k across distinct IDs. |
unit_runtime.py |
Same solver for the unit\UN_*.tbl definition objects (vtable 0x820af844). Unions several snapshots — unit definitions are per-stage. |
schema_order.py |
Merge a sub-record's field-declaration order across all tables (topological sort); the layout check that pins fields no table ever values. |
order_check.py |
Test offset = base + 4*index for one table's sub-record against solver output. |
grab_tutorial.sh |
Cold-boot Canary, walk to the Nth TUTORIAL entry, wait for the stage load, snapshot guest RAM. One emulator per capture — backing out of a loaded mission wedges it. |
Snapshot first — cp --sparse=always /dev/shm/xenia_memory_* snap.bin (~2 s) — and
point $GMEM_FILE at the copy; the running emulator pegs every core under lavapipe.