Local Emerald visible-progress probe

Method

A temporary host driver uses public core APIs (deleted after use; lives outside version control). It boots the local user-supplied ROM with bios::boot, selects CartridgeHardware::Rtc and SaveDevice::Flash128, fixes the RTC to [24, 1, 1, 1, 12, 0, 0] without advancing it, enables scanline rendering, and calls Machine::run_until_vblank(400000) once per frame. Input snapshots apply after each VBlank capture, before the next machine step. Frames dump as checksums plus a final PPM for visual reading. No ROM bytes, screenshots, or extracted code are committed.

Three schedules were used:

No input (attract mode).
advance: periodic A/Start taps (A for 10 of every 120 frames, Start for 10 of every 120 frames offset by 60) to walk through title, menu, and dialogue.
sweep: deterministic rotation holding each button 20 frames in turn.

Observed visible progress

No-input attract mode renders the title screen, the Pokémon logo, the NEW GAME / OPTION menu, the Prof. Birch scene, and legible dialogue text (Hi! Sorry to keep yo, Welcome to the world of POKéMON!). Menu and dialogue text, the Birch sprite, and the spotlight composite correctly.

The advance schedule reaches further: Birch dialogue, the And are you? gender prompt, and — at 12,000 frames — the in-game start menu (BAG A SAVE OPTION EXIT) over the overworld with the player sprite in a room. Frame checksums evolve continuously through the run; PC samples alternate between the 0x080008c6–0x080008cc wait loop and game code (0x082e6dcc, 0x082e6dce).

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 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 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.

Second-game data point

A local FireRed ROM (16 MiB) faults during boot init, after about 1.19 million steps with --rtc --save-type flash128:

PC=0x081e37d2 CPSR=0x0000003f System/Thumb
r0=0x09fe2ffe r1=0x00000020
read-only memory at 0x09fe2ffe

A dynamic trace shows boot code spilling 0x09fe20f8, 0x04000204 (WAITCNT), and 0x09fe2ffe to the stack, writing 0x1800 to WAITCNT, then STRH r1,[r0] of 0x20 to 0x09fe2ffe. That address is ROM window 0x09 past the 16 MiB EOF; the bus reports ReadOnly. On hardware the 0x09 window mirrors 0x08 and ROM writes are ignored. The following instruction stream also loads halfwords from 0x09fe20f8, so reads past EOF would fault next under the current policy. Without --save-type the same ROM faults earlier at 0x0e005555 (unmapped memory), i.e. it also expects Flash save hardware. Both failures are recorded, not fixed: mirror folding plus write-ignore semantics need independent hardware evidence and a deliberate policy decision against the explicit-error convention. See the usability roadmap for sequencing.

References

GBATEK memory map: three 32 MiB ROM windows at 0x08/0x0a/0x0c with wait states 0–2.
mGBA memory at c30aaa8f: out-of-bounds ROM loads log a game error and return (address >> 1) & 0xFFFF; ROM stores go through patch infrastructure. Precedent for non-fatal handling, not a hardware measurement. Not copied.

4.1 KiB Raw Blame History Unescape Escape