docs(compat): record 40k-frame trap-point validation result
This commit is contained in:
parent
174196cdf7
commit
8a69e837cf
2 changed files with 15 additions and 14 deletions
|
|
@ -36,21 +36,22 @@ the `0x080008c6–0x080008cc` wait loop and game code (`0x082e6dcc`,
|
|||
The `sweep` schedule changes captured output per input (input-dependent
|
||||
execution) but its denser presses stall the intro on a blue field; raw
|
||||
button rotation is worse than sparse taps for menu progress.
|
||||
A 40,000-frame `advance` run completed with exit status zero: no diagnostic
|
||||
through frame 39,999, so the reported `INVALID_ARGUMENT_TRAP` at 37,101
|
||||
captured frames did not reappear on this input path. Blind taps take a
|
||||
different menu path than manual play, so the identical starter-selection
|
||||
scene is not confirmed visited — this validates forward progress and no
|
||||
regression, not the exact user scenario.
|
||||
From about frame 9,000 onward the captures cycle among three checksums
|
||||
(`0x24bdf6c568`, `0x2503d09807`, `0x7983c73704`) with periodic black fade
|
||||
frames, consistent with Start taps toggling the overworld start menu; the
|
||||
scene past frame 12,000 was not visually confirmed. The final frame is
|
||||
black mid-fade (checksum zero).
|
||||
|
||||
A 40,000-frame `advance` run is in progress to check the user's reported
|
||||
starter-selection trap point (37,101 captured frames in their manual run)
|
||||
against the empty-LZ77 correction. Blind taps take a different menu path
|
||||
than manual play, so reaching the identical scene is not guaranteed; a
|
||||
diagnostic-free run still validates forward progress, while any trap gets
|
||||
recorded with full CPU state.
|
||||
|
||||
## Result status
|
||||
|
||||
Execution is diagnostic-free through 12,000 tapped frames (about 1.18
|
||||
Execution is diagnostic-free through 40,000 tapped frames (about 3.9
|
||||
billion machine steps). This establishes visible menus, sprite/dialogue
|
||||
composition, and input-driven progress — not correct gameplay, audio, or
|
||||
saving. The old `INVALID_ARGUMENT_TRAP` at starter selection has not yet
|
||||
been re-encountered because the probe has not reached that scene.
|
||||
saving.
|
||||
|
||||
## Second-game data point
|
||||
|
||||
|
|
|
|||
|
|
@ -198,7 +198,7 @@ An [isolated reproduction](research/emerald-empty-lz.md) identified a zero-lengt
|
|||
The replacement BIOS now returns for that empty stream. Full starter-selection progress after this correction needs user retesting.
|
||||
A later [visible-progress probe](research/emerald-visible-progress.md) renders the title screen, logo, NEW GAME/OPTION menu, Prof. Birch scene, and legible dialogue in attract mode.
|
||||
Sparse A/Start taps reach the gender prompt by 4,000 frames and the in-game start menu over the overworld by 12,000 frames without a diagnostic.
|
||||
A 40,000-frame tapped run is checking the reported 37,101-frame starter-selection trap point; blind taps may take a different menu path.
|
||||
A 40,000-frame tapped run passed the reported 37,101-frame trap point without a diagnostic; blind taps take a different menu path, so the identical scene is not confirmed visited.
|
||||
A local second-game ROM faults in boot init on a halfword store to ROM mirror `0x09fe2ffe` past its 16 MiB EOF; without save hardware it faults earlier on a Flash unlock write. Both are recorded, not fixed.
|
||||
See [the startup result](research/emerald-reset.md) for the bounded run and next investigation.
|
||||
See [cartridge loading](hardware/cartridge.md) for file limits, step budgets, and exit status.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue