docs(compat): record Emerald visible menus and second-game failure

docs/research/emerald-visible-progress.md

@@ -0,0 +1,86 @@
+# 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.

docs/status.md

@@ -189,15 +189,17 @@ With explicit `--rtc` selection, it also passes Game Pak GPIO configuration and
 With `--save-type flash128`, it also passes Flash identification and reaches a later startup check.
 It now passes disconnected Joybus setup and completes a bounded 600-frame native run without a diagnostic error.
 That run used no scripted input or pixel assertions.
-A later [fixed-time input probe](research/emerald-wave.md) found a wave trigger with its gate disabled.
+A [fixed-time input probe](research/emerald-wave.md) found a wave trigger with its gate disabled.
 Wave support now passes that point and reaches 1,320 frames with scheduled Start/A presses and releases.
 Output differs from a no-input control, but readable menus and gameplay remain unverified.
 Flash writing and host persistence now pass original save/restart/load tests. Emerald saving and reloading remain unverified.
 A user reached starter selection, then reported a BIOS invalid-argument trap.
 An [isolated reproduction](research/emerald-empty-lz.md) identified a zero-length LZ77 header rejected before the length check.
 The replacement BIOS now returns for that empty stream. Full starter-selection progress after this correction needs user retesting.
-Without `--rtc`, cartridge GPIO writes still return read-only diagnostics.
-No title-screen, gameplay, or audible-game compatibility is established.
+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 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.
 The [ROM suite runner](rom-tests.md) has original regressions and a [pinned public ARM baseline](public-arm-tests.md).

docs/usability-roadmap.md

@@ -64,7 +64,8 @@ A reproducible source build or an accessible upstream ROM is needed before recor
 
 Next implementation steps:
 
-1. Inspect visible startup/menu progress and exercise input in the bounded local game run. Record the first demonstrated failure.
+1. Visible startup/menu progress is established: attract mode reaches the start menu and Birch dialogue, and sparse taps reach the in-game start menu by 12,000 frames ([probe](research/emerald-visible-progress.md)).
+   The first demonstrated second-game failure is a boot-init halfword store to ROM mirror `0x09fe2ffe` (recorded, not fixed).
    Use original regressions for any hardware correction; do not invent connected serial devices.
 2. Validate an external game's completed save/restart/load cycle using a disposable `--save-file` path.
    Refine nominal Flash timing and polling only with independent evidence and original regressions.