# 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`:

```text
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](../usability-roadmap.md) for sequencing.

## References

- [GBATEK memory map](https://problemkaputt.de/gbatek-gba-memory-map.htm):
  three 32 MiB ROM windows at `0x08`/`0x0a`/`0x0c` with wait states 0–2.
- [mGBA memory at c30aaa8f](https://github.com/mgba-emu/mgba/blob/c30aaa8f/src/gba/memory.c):
  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.