re: the new-game path completes, the intro is only weakly identified, and
this container kills long runs Three results, and the middle one is deliberately not upgraded. First: NEW GAME -> DIFFICULTY -> NORMAL -> SELECT DATA -> pick a slot -> a movie plays, with no crash. The previous run's throw at 0x82307128 is therefore not inherent to the menu path -- the same six presses got through it -- which fits the incomplete-cache trigger the corpus already names. n=1 either way, and the note says so. Worth recording because one observation had already hardened once into "A on NEW GAME hangs", and it would have hardened again into "the new-game path crashes". Second: with the path open, the manifest's MS00A -> S00A.wmv finally got a runtime test, and it did NOT reproduce the quality of the attract-movie identification. The first four samples give a clean monotonic S00A playhead of 2, 6, 9, 13 s and the strongest frame matches at 0.916, but the run as a whole is not one advancing timeline, most frames sit at contrast 23-37 where this page's own rule says discrimination is poor, and one high-contrast frame prefers ADV. So it stays amber: consistent with S00A, corroborating the manifest decode, not confirming it. A clean answer needs the 30fps x11grab route rather than 5-second screenshots. Third, and it bounds the rest: the emulator vanished at ~145 s with no crash line in its own log, last entries routine MEM-WATCH at 1.15 GB RSS. Second time this session -- the other was ~50 s into a boot. That is an external kill on a box with ~1 GB free and swap exhausted, not a guest fault. METHOD and the handoff's residue table both now say dynamic experiments here have to fit in about two minutes of guest time, which is why the DELTASABER plates went unseen again: they need a mission load and the run never got there.
This commit is contained in:
@@ -117,3 +117,20 @@ more.
|
||||
This boot opened the main menu on **`NEW GAME`**. Running tally across four
|
||||
boots of the same harness: `TUTORIAL`, `TUTORIAL`, `NEW GAME`, `NEW GAME`.
|
||||
Unchanged conclusion: **do not hardcode it.**
|
||||
|
||||
### The `NEW GAME` path completes — the `SELECT DATA` crash is state, not path
|
||||
|
||||
A second run of the same path, 2026-08-28, **did not crash**:
|
||||
|
||||
```
|
||||
NEW GAME → DIFFICULTY → (Ⓐ on NORMAL) → SELECT DATA → (Ⓐ on a slot) → a movie plays
|
||||
```
|
||||
|
||||
The previous run's throw at `PC 0x82307128` is therefore **not inherent to this
|
||||
menu path** — the same six presses got through it. That is consistent with the
|
||||
trigger `title-crash-stl-tree.md` already names (an incomplete on-disc cache) and
|
||||
with nothing about `NEW GAME`. 🟡 n = 1 either way; do not read it as "fixed".
|
||||
|
||||
Worth recording because the first observation could easily have hardened into
|
||||
"the new-game path crashes", which is what "A on NEW GAME hangs" had already
|
||||
become once.
|
||||
|
||||
Reference in New Issue
Block a user