Dungeon Master Nexus — startup status

This is an evidence report for startup, not a specification for a completed Nexus startup screen. Updated 2026-10-27: an authentic Japanese retail cold boot reaches the native PRESS START BUTTON title prompt and, with scheduled retail controller input, the native three-choice title menu in Ymir. The menu was navigated into its Configuration page from a saved diagnostic state. Separate captures show New Game selected and Down selecting Continue, with five TITLE.BIN sprite draws per state compared with the retail screenshots. The verify_nexus_title_sprite_screenshot.py verifier now checks the five-draw Japanese Continue layout and the English New Game and Continue layouts against authentic retail source bytes and captured CRAM. Ymir also completed Continue-to-gameplay with the corpus-retained BKR image whose SHA-256 is 87d041baecca76a629b18b34e13b47adca1d5995a69bcac769aaca54c8f34035: the retail Load screen showed B01 0:16 NORMAL, then entered the four-champion dungeon view. The isolated BKR copy retained its hash after loading. A paired Up-input replay changed the rendered gameplay view. These captures verify the retail reference flow in Ymir only. Firestaff now renders authenticated English and Japanese New Game/Continue/Configuration foreground sprites from regional TITLE.BIN data. English Configuration text pixels match its Ymir capture; final marker RGB remains background-dependent. The shared background, full-screen composition, Firestaff menu destination execution, Continue loading, and gameplay HUD/viewport remain unimplemented or unverified.

Verified initialization order

nexus_v1_init() first selects a hash-verified extracted corpus when DM.BIN and the authentic DGN corpus are available as real loose files. LEV00.DGN is a title/entry resource; the first playable level is LEV01.DGN. A valid co-located retail ISO can then be read as a supplementary source for exact ISO members. If only ISO data is available, the ISO reader is used directly.

After source selection, the engine attempts to read real RLOWFIX.BIN, startup surfaces, FACE.BIN, FONT256.S2D, sound metadata, and other source files. Missing or unbound consumers must not be replaced with synthetic surfaces. Title startup must therefore not report a game position until Saturn’s authentic LEV01 position and direction have been captured and bound to the same runtime source.

Verified startup resources

Deterministic title-state replay (2026-10-26)

The system-wide Ymir 0.4.2-dev capture build on TRV2 was run with --debug, the authenticated Japanese BIOS and retail cue, and the retained title-prompt state in CLI slot 2. The isolated profile mapped that state to savestates/5EA76F972566FE6EB667D092CD494BCF/1.savestate; it was removed after the run. One frame after the successful load, the VDP2 outputs matched the retained title-state reference exactly:

The capture build also emitted big-endian VDP1 and VDP2 register files (32 and 512 bytes respectively) and a register snapshot. That tooling is proposed in Ymir PR #966. This confirms a repeatable authentic VDP2 title-state checkpoint, not the separate VDP1 title-menu command bundle: the one-frame VDP1 outputs did not match that bundle’s frame-497 hashes. It therefore does not admit the menu compositor, input dispatch, title-to-menu transition, or Firestaff presentation.

The same system build was subsequently checked after its VDP1 trace was reattached following save-state loading. The single captured frame produced a complete ymir-vdp1-capture-bundle-v1: capture frame 0 contained 168 command rows, its snapshot cursor was command 168 at address 0x00000cc0, and the bundle reported zero dropped rows. This proves that the Ymir CLI can now retain frame-aligned VDP1 command evidence across this authentic state load. It still does not identify the displayed menu, establish source ownership or palette composition, or authorize a Firestaff renderer.

Ymir PR #966 also contains a bounded VDP2 VRAM/CRAM write tracer and an export receipt. Its system build and the existing title-state VDP1/VDP2 checkpoint were regression-checked on TRV2. The VDP2 write tracer has not yet produced a retained source-to-write witness for this menu, so it is tooling for the next capture rather than an admission signal.

An input-driven retail probe sent the observed Start key route while retaining the VDP2 trace. It produced 92,288 VRAM-write rows with no trace drops, but its captured VDP1 cursor had only seven commands rather than the authenticated title-menu bundle’s 178. It is therefore negative routing evidence, not a title-menu capture; its untracked raw dump was removed after inspection. Do not use those writes to label a menu resource or relax a presentation gate.

scripts/verify_nexus_ymir_title_state_checkpoint.py verifies this narrow checkpoint from caller-supplied retail CUE, BIOS, title-prompt state, and local Ymir dump files. It pins every CUE-referenced retail track and validates the register snapshot schema. The checkpoint pins VDP2 register bytes; it does not use the emitted VDP1 register file as evidence because this capture record has no independent VDP1-register digest. Nothing in this receipt establishes menu or gameplay presentation.

Deterministic Start-to-menu checkpoint (2026-10-26)

Ymir PR #966 adds a frame-aligned Control Pad 1 Start route for the existing state/frame/dump capture path. On TRV2, a fresh temporary profile used the authenticated Japanese retail CUE, BIOS, and title-prompt state in CLI slot 2. It held Start during capture frames 0 through 59 and captured 120 frames with --debug --load-state 2 --capture-frames 120 --dump-memory --capture-start-frame 0 --capture-start-hold 60. The profile and raw dumps were removed after inspection; the displayed title-menu image and VDP1 receipt are retained in nexus_v1_ymir_deterministic_start_menu_20261026.

The capture completed at VDP1 frame 59 with command cursor 178 and 178 rows for that frame. Its complete trace had 10,668 rows from frames 0 through 59, with zero dropped entries. This is the same command count as the retained retail three-choice title-menu capture, so it is reproducible emulator evidence for the observed Start route rather than host-window timing evidence. The VDP2 title checkpoint remained byte-identical to the retained title-state reference:

This makes title-menu capture reproducible without X11 keyboard injection. It does not bind a retail menu resource to a Saturn consumer, prove the final displayed pixels, or permit Firestaff to present a host-built menu. Those production gates remain closed.

Retail title selection captures (2026-10-27)

A historical Ymir capture at VDP1 frame 59 loaded a retained title-prompt state before Start and shows NEW GAME selected. A source comparison against the authenticated Japanese TITLE.BIN in .firestaff/data/nexus reported 1,495 nontransparent matching sprite pixels across five final title draws: 213/213, 213/213, 313/313, 293/293, and 463/463. This is historical source-comparison evidence, not a cold-boot receipt or a result from the current verifier, which validates the Japanese Continue layout only. The retained capture is ymir_nexus_atomic_menu_20261026 on the external evidence disk; its screenshot SHA-256 is 8721cce3354bc20b1cd367fd44be3d4ecc60ca65fa89c7d00654e83f5ad7db23.

A separate authentic Japanese Ymir capture pressed Down for two emulated frames and shows CONTINUE selected at VDP1 frame 8047. The current verifier matched 1,441 pixels across five TITLE.BIN draws (313/313, 186/186, 186/186, 293/293, and 463/463). Its external evidence receipt is ymir_nexus_coldboot_menu_20261027/menu_continue_input_20261027; screenshot SHA-256 741c620e945b5ab3e05f6bc5d182fc4ada9439071b79718f67326bcdd56c6118. Both checks bind source texture bytes, CRAM colors, sprite priority, and individual screenshot pixels. They do not yet reconstruct or admit the full retail frame for Firestaff’s live renderer.

The retail Continue flow was separately observed in Ymir with a 32 KiB BKR image reported as retail-written. Down selected Continue, Accept opened the native Load panel, and accepting its internal-memory entry reached a four- champion dungeon view. The image digest was 87d041baecca76a629b18b34e13b47adca1d5995a69bcac769aaca54c8f34035; the capture receipt notes that its transfer/source chain was not retained. This demonstrates the retail route, not Firestaff’s BKR-to-engine handoff. See nexus-continue-real-bup-20261025.

An independent 2,200-frame no-present replay on 2026-10-26 used the same authenticated Japanese IPL, retail CUE, retained title-prompt state, and the hash-verified four-champion BKR (87d041baecca76a629b18b34e13b47adca1d5995a69bcac769aaca54c8f34035). It scheduled Start, Down, A, and a second A at emulator-frame boundaries rather than through X11. The BKR digest was unchanged after the run. Its final native frame was the Dungeon Master Nexus title image, SHA-256 1c224b148ec5c107569c1c9b30c5dfab24d8110d3e391b0bcb1089cd582dfb13. This is a timing boundary: those inputs occur before the title is receptive and must not be interpreted as a verified menu or Continue route. The temporary profile, dump, and screenshot were removed after inspection.

A later 3,400-frame replay moved the same Start/Down/A/A sequence after the title boundary, but held every control for only eight emulated frames. Its retail endpoint remained the title image (SHA-256 8d495ffa4e8a76ab38a48c3c84a6fcc437db1bc4682aec6ac897609ed2307d95), while the BKR digest again remained unchanged. This is negative timing evidence: an eight-frame post-title hold is not sufficient to establish a retail input transition. It does not authorize a host menu, save route, HUD, or viewport.

A separate 3,400-frame debug replay kept the same post-title frame schedule but extended each Start, Down, A, and second-A press to 60 emulated frames. Its endpoint was still the native title screen, with SHA-256 8d495ffa4e8a76ab38a48c3c84a6fcc437db1bc4682aec6ac897609ed2307d95; the four-champion BKR digest remained 87d041baecca76a629b18b34e13b47adca1d5995a69bcac769aaca54c8f34035. Both runs ended with the same final title-screen image hash. Extending the post-title hold from eight to 60 frames did not change the final endpoint; no claim is made here about intermediate menu or loading transitions. The temporary profile, X display, memory dump, and inspection copy were removed after verification. This remains negative emulator evidence only: it does not establish menu, save, HUD, or viewport parity.

Ymir PR #966 additionally provides --capture-screenshot for the same capture-owned route. It queues a profile-local framebuffer PNG only after the requested frames and memory receipt have completed; it requires both a frame capture and --dump-memory. A 60-frame retail boot check produced both the VDP1 receipt and that PNG. The generated media was discarded after verification and is not a Firestaff asset or parity admission signal.

Ymir PR #966 now also provides --capture-no-present for deterministic runs where an X11/GLX compositor cannot swap GUI frames reliably. A fresh temporary profile on TRV2 loaded the same authenticated Japanese BIOS, retail CUE, and title-prompt state, then completed --load-state 2 --capture-frames 1 --dump-memory --capture-no-present under Xvfb. It wrote a complete memory dump and exited with status 0 in under three seconds. The profile and dump were removed after the check. This proves the capture transport no longer depends on a successful GUI presentation for this state; it does not supply a framebuffer, prove visual parity, or open any Firestaff presentation gate.

The same state was then captured with --capture-screenshot in no-present mode. The completed dump was followed by a 640×448 RGBA PNG with SHA-256 4b19474395c7192e7e68faf82efe0c240c9da213c4cd36c1ad91f31e68c17d82 before Ymir exited. The temporary image was removed after its dimensions and digest were checked. This validates non-present screenshot delivery for future visual comparisons; it is not itself a pixel-parity admission or a Firestaff asset.

Boot VDP2 writer anchor (2026-10-26)

Ymir PR #966 was extended with a bounded direct SH-2 VDP2-write trace and a normal-disc boot capture route. A 60-frame --debug --capture-boot-frames 60 --dump-memory --trace-vdp2-writes run against the authenticated Japanese retail CUE and BIOS recorded one direct master-SH-2 write: PC 0x0602e12e wrote the 16-bit value 0x0000 to VDP2 VRAM bus address 0x05e7fffe at VDP1 frame 21. The current call-site was return address 0x06032c24, targeting the generic word-copy routine at 0x0602e120. The trace had zero dropped entries. Its CSV and receipt hashes were respectively 47b98193f1b7615aad2326f5fc8386b502a214c6a244fece30e3a6580a0efc46 and 7efd6c70e83aea4178fa013ce59dfe7149e05727c26e81b64f736897356646fd.

This is a real SH-2 routine anchor for subsequent disassembly of a retail VDP2 writer. It does not identify the source resource, establish a complete upload sequence, or prove title-menu ownership. The temporary memory dump was removed after the PC, address, width, value, and receipts were checked.

Big-endian SH-2 disassembly of the captured high WRAM identifies the inner call at 0x06032c20: the wrapper masks r4 with 0x0007ffff, maps it into the uncached Saturn bus (0x25e00000 | r4), and calls 0x0602e120 with a one-word count. A static cross-reference at 0x060282d4 calls that wrapper with destination 0x25e7fffe. This explains the recorded address, but its source is a stack temporary. It therefore remains an initialization anchor, not source-resource provenance or permission to draw a host menu.

Delayed title-menu confirm observation (2026-10-26)

An authenticated Japanese retail title-prompt state was replayed in Ymir with the deterministic capture route for 360 frames. Start was held for frames 0..59; Control Pad 1 A was held for frames 240..249. The captured final frame was VDP1 frame 231 with 112 command records, rather than the earlier title-menu capture’s 139 records. A window capture made immediately after the dump showed the retail door-opening transition; its SHA-256 was abdd1e9f65c0999d967fced4dad456856751cd9afcb46080616f617470ffc55a.

This is an observed response to a delayed input schedule, not sufficient proof that A semantically confirms New Game. A matching no-A control was then run from the same retained state with Start held for 0..59 and no other scheduled input through the same requested 360-frame capture. Its final profile-local framebuffer was the native three-choice title menu, with SHA-256 20801648c86a5cbbe2a0e6c9cc90e625579fb52ba41f0b2234a51d3b0b17ecfe. The control capture produced an undropped VDP1 trace (32,028 rows), but its bounded trace buffer ended at frame 179; it therefore cannot be used to compare a final VDP1 command stream to the delayed-A capture. The framebuffer is nevertheless emitted after the requested capture-owned frame loop, so this is evidence that the observed door transition depends on the delayed A schedule rather than on the Start-only title timeline.

This still does not establish which retail menu item A confirms, the next stable game state, source-resource joins, or palette/compositor evidence. Do not enable a host menu, gameplay, HUD, or synthetic confirmation rule from this observation. The temporary screenshots, dumps, profile, and emulator process were removed after their hashes and receipt limits were checked.

The same real state and input schedule was also captured for 600 requested frames. Its final framebuffer showed the retail Now Loading screen (SHA-256 07a6f3a612ca75209cd6308852a7cf25b3d1f35943ce2f5774e720376ef7c61c), and the VDP1 receipt retained 48,380 undropped trace rows through frame 391. This extends the observed route from the door transition to the native loading state. It does not yet reach or bind a stable playable level, the party pose, viewport, HUD, level source, or palette/compositor route; it must not be used to synthesize any of those Firestaff states.

After the no-present capture path was added to Ymir PR #966, the same authenticated state and input schedule was repeated under Xvfb without GUI presentation. The 600-frame run exited with status 0, wrote its memory dump, and saved a 640×448 RGBA screenshot with the same Now Loading SHA-256 07a6f3a612ca75209cd6308852a7cf25b3d1f35943ce2f5774e720376ef7c61c. Its VDP1 trace and receipt digests were respectively d529f883b686b7c3fc83db929e3e1b476527799ca3fbda35ba41a4ef48a1079e and 45d384f8b6d8c4a5ab48941bcea462cbe1624ea57f8679ebfe4f8c8c1baf3a22. The temporary profile, dump, screenshot, process, and result receipt were removed after verification. This independently reproduces the observed loading checkpoint but does not extend its presentation admission.

Ymir PR #966 also adds --capture-save-state N. A real title-prompt capture saved slot 3 after its dump, and a second isolated Ymir process loaded slot 3 and completed a further one-frame dump. This makes long retail transitions inspectable through short, repeatable follow-up captures. The temporary state and both profiles were removed after the round trip; a saved emulator state is diagnostic transport, not a Firestaff asset or an admission signal.

An authenticated 900-frame Start/A capture saved such a checkpoint and reached a 640×448 first-person dungeon viewport with SHA-256 8ede95f1fd777eda69ebcfc91d0268194e501f145306eb1fc2971ed0113a2274. Reloading slot 3 in a fresh isolated process and capturing one frame reproduced the same digest exactly. The image has no party HUD, so it is evidence for this narrow rendered viewport checkpoint only. It does not identify the level or room source, establish input semantics, authorize a host compositor, or prove the HUD route.

On 2026-10-26, the system-wide Ymir build on TRV2 reproduced that route from the retained Japanese title-prompt state: Start held for capture frames 0..59, then A for 240..249, over 900 --debug frames. The framebuffer again hashed to 8ede95f1fd777eda69ebcfc91d0268194e501f145306eb1fc2971ed0113a2274; the isolated four-champion BKR remained 87d041baecca76a629b18b34e13b47adca1d5995a69bcac769aaca54c8f34035. Saving that endpoint in CLI slot 3 and reloading it in a second isolated profile reproduced the framebuffer hash after one frame. Both temporary profiles, dumps, screenshots, and X displays were removed. This verifies the current Ymir capture tooling and the bounded retail viewport route, not a Firestaff renderer, menu consumer, or HUD admission.

Bounded candidate-state-window SH-2 read witness (2026-10-26)

Using the same hash-pinned Japanese retail CUE, BIOS, title-prompt state, and four-champion BKR, an isolated system-wide Ymir run advanced the observed Start/Down/A route, saved a fresh slot-3 checkpoint, and replayed one debug frame from that checkpoint. The source BKR remained 87d041baecca76a629b18b34e13b47adca1d5995a69bcac769aaca54c8f34035 before and after both captures. A bounded SH-2 data-read trace over 0x060476d0..0x06048000 recorded twelve master-SH-2 16-bit reads, all in the 0x06047ca0..0x06047cb6 range, without dropped rows. The captured checkpoint has SHA-256 48ca0feb12432dde6748124a9e639ad4e466efc307520268356a16c00fd5b2ce; the retained CSV has SHA-256 e45ad64fa89ce263b51c0579167a35fcfacdce840a438854b48b8df5100dd9ee.

Disassembly against the retained high-WRAM image identifies two real 16-bit field reads at offsets +4 and +6 from the observed eight-byte records, and the caller dereferences a table entry in the same address range. For example, the trace reads the 0x0124 and 0x00b0 fields from the record beginning at 0x06047cb0; the next observed records have the same packed layout. This is evidence of structured runtime state, not evidence of a particular UI role. The high-WRAM image used for this disassembly has SHA-256 344b6a15bdac95a8e698c9a9ccc336f6f225fb3a4c60eec9788102c57b2e197d.

The raw CSV, its completed Ymir bundle, VDP1 command trace, VDP register snapshot, VDP2 registers, high-WRAM image, and checkpoint are retained in the TRV2 verification store as nexus_v1_ymir_sh2_read_trace_hud_20261026. This is an authentic execution witness for the specified RAM window. It is not an ownership join from a Firestaff source resource to a HUD element, does not label those reads semantically, and does not permit a host HUD, viewport compositor, save route, or input implementation.

SH-2 to VDP1 command handoff (2026-10-26)

Ymir PR #966 now exposes a bounded SH-2 data-write trace independently of the older VDP2-only trace. A two-frame replay from the same authentic checkpoint traced physical VDP1 RAM at 0x05c00000..0x05c80000. It retained 176 master-SH-2 writes with no drops. In frame 0, the master SH-2 completed the command at physical address 0x05c000a0 by writing 0x5000 to offset zero and 0x0018 to offset two. In frame 1, the VDP1 command trace executed the command at VDP1 address 0x00a0 with word 0 0x5000 and word 1 0x0018.

This is a same-checkpoint, temporal CPU-to-VDP1 handoff: it proves that the retail SH-2 authored the VDP1 command consumed on the next captured frame. The two-frame SH-2 write trace and VDP1 command trace have SHA-256 58c9d41740a75063543c70b6cb11e336268cfb47486df1ffdcbe19718f12bc66 and c93f3a8f86263ded3b79d081f15771bce4331ab31ec6a0ce37d3b4691b628f32 respectively. The corresponding completed receipts are retained with the checkpoint. This does not identify the source resource, texture, palette, or semantic role of that command, so it does not by itself admit a Firestaff HUD, viewport, or renderer.

Title-menu VDP1 source-span join (2026-10-19 capture; analyzed 2026-10-26)

A read-only source-join analysis on TRV2 used the retained Ymir v0.4.0 Japanese title-menu VDP1 capture (VRAM SHA-256 0f484877f5c5ef300fcbcaec6948b50c8b7aed7945e448a9f8281b2da46a2f21) and read the Japanese retail CUE/ISO members directly from the authentic Nexus media root. The analysis identified 137 active texture draws: 124 indexed image/CLUT pairs exactly matched to LEV00.DGN, eight direct-color spans matched to LEV00.DGN, and five spans matched to TITLE.BIN. No active draw was left byte-unbound. Of the 124 indexed DGN draws, 108 had a matching static FACE selector; 16 did not.

This narrows source-byte provenance for that single Ymir menu frame. It does not establish SH-2 upload ownership, the semantic use of the 16 draws without static FACE selectors, menu input progression, complete pixel composition, or production renderer permission. It is a different capture from the 2026-10-25 VDP command bundle above. Keep Nexus startup gated until a same-session source, input, command, palette, and displayed-frame route is bound; do not infer that MENU.BPK owns these observed draws or that it is unused in other frames.

The five matched TITLE.BIN source spans fall within the verified TITL resource-directory entry with class-local id 3 (record beginning at file offset 0x0d068, before the MAPD record at 0x0e278). This adds record-level ownership only. The exact subresource role, upload path, and menu label/pixel association remain unbound. The 16 LEV00.DGN draws without static FACE selectors likewise have byte and material matches, but no evidenced semantic owner; do not label them from dimensions or geometry alone.

The BKR parser has been checked against all four hash-pinned images in the private corpus, which are reported as retail-written. It reproduces each 20,480-byte payload hash from the existing read-only Python reader. These images use 64-byte card blocks (512 blocks per 32 KiB image); each game entry claims 354 blocks. The parser deliberately returns payload bytes without interpreting game fields. This supports container-level Continue work but is not yet a save-load path into the Nexus engine. The opaque Saturn capture receipt remains a separate API and is not a BKR parser. The BUP used in the Ymir Continue run has no retained transfer chain, so its retail provenance is reported rather than independently established.

Retail title-menu evidence (2026-10-25)

An isolated Ymir --debug run with the authenticated Japanese BIOS and retail disc reaches the native Nexus title menu. The retained 2026-10-25 screenshot shows the three actual choices: NEW GAME, CONTINUE, and CONFIGURATION, with New Game selected. Its SHA-256 is d1ec79c6b1e3abcd16837781a1212eedb3cb157562356593ab3ce069b18f2ab4. The 2026-10-24 keyboard run records Start opening the menu and confirming NEW GAME entering the dungeon. In a separate fresh-profile attempt, selecting Continue left the screen unchanged because no save was present; that attempt did not verify save loading. Together, these are retail startup/input observations, not Firestaff parity. The capture environment, key mapping, and per-action limitations are recorded in parity-evidence/verification/keyboard-mouse-debug-20261024/README.md.

Firestaff title-menu keyboard state (2026-10-27)

M11 now has a separate state for the observed Japanese retail title menu. The ready title prompt accepts the configured Action input to open the retail menu with New Game selected. Up/Down and W/S now navigate between the three choices. An authentic English retail Ymir replay shows Down selecting Continue; a subsequent Up returns to the original New Game screenshot pixel-for-pixel. F matches the observed Ymir desktop binding for Saturn Start; Enter, keypad Enter, and Space are Firestaff keyboard aliases. These keys feed Action only while the Nexus title is active. At this stage, the menu choice was not drawn; subsequent capture-backed work added regional foreground sprites for selected menu states, while the shared background and full-screen composition remain unbound. Accepting New Game, Continue, or Configuration still does not execute a production destination. Continue execution remains unavailable until Firestaff reads authentic Saturn BKR media; the generic Firestaff save-file mask is deliberately not reused. This is an input-state increment, not title-menu or gameplay parity. See the Nexus input status and menu audit. The paired emulator screenshot hashes and exact replay schedule are in the vertical navigation capture receipt.

Retail Continue with an authentic save (2026-10-25)

A second isolated Ymir --debug run used a reported retail-written 32 KiB Saturn backup image (SHA-256 87d041baecca76a629b18b34e13b47adca1d5995a69bcac769aaca54c8f34035) with the same hash-verified Japanese retail disc and BIOS. The title menu showed NEW GAME, CONTINUE, and CONFIGURATION. Selecting CONTINUE opened the retail LOAD panel, which listed the internal-memory entry B01 0:06 NORMAL. Confirming it displayed Now Loading, then entered the dungeon with the four-champion HUD. The BUP image retained its original SHA-256 after loading.

The isolated profile was /dev/shm/ymir-nexus-real-bup-menu-20261025; the source/transfer chain was not retained, so the save’s retail provenance is reported rather than independently established. The source BUP was copied into that profile and was not edited directly. Ymir 0.4.1 ran with --debug on TRV2 against the Japanese retail cue (SHA-256 878b3bc223bb56e99626dbaa2946d17fb349a2a67a10cd4423742d8ab30b8699). The retained screenshots and their hashes are in parity-evidence/verification/nexus-continue-real-bup-20261025/README.md. This demonstrates the retail save-load route under Ymir with a BUP reported as retail-written. Because its transfer chain was not retained, the save’s retail provenance is not independently established. It does not prove Firestaff implements that title menu or save selection; the production startup route remains blocked by the consumer-evidence gates described below.

On 2026-10-26, a fresh TRV2 Ymir profile copied the same hash-verified four-champion BKR and replayed the retained Japanese title-prompt state with Start at frames 0..59, Down at 180..189, and A at 240..249. At frame 900, the authentic framebuffer showed the native Japanese LOAD panel and its B01 0:06 NORMAL internal-memory row (SHA-256 b95cdc24ae30705648533dba1e1a1a304196a8fbb449bd069df513be85c0928b). A saved checkpoint was loaded into a second isolated profile; A at frames 0..9 then reached a four-character HUD plus first-person viewport at frame 900 (SHA-256 68de1c7898d79d70d7f3b9fd8f220485fd5ffa75b8aefad9f491eeb3d16a2a76). Both profiles retained the BKR SHA-256 87d041baecca76a629b18b34e13b47adca1d5995a69bcac769aaca54c8f34035. This authentic two-stage route binds a real UI checkpoint and HUD witness for future capture consumers; it does not yet admit a Firestaff menu compositor, HUD compositor, or save-format implementation. The profiles, dumps, screenshots, and X displays were removed after verification.

Firestaff’s source-level startup helpers do not implement the retail title menu. nexus_v1_startup_boot_handle_input uses the synthetic warning/title schedule and selects a host save or champion action from the available slot mask. That helper logic is not proof of a reachable production menu: the authentic launch route remains blocked by its menu-surface and consumer evidence gates, as described below. The retail title instead opens its three-choice menu before New Game or Continue proceeds. Configuration behavior and the Saturn consumer that draws the retail menu have not yet been bound to a same-session VDP1/VDP2 capture. Do not treat the existing host save/champion panels as equivalent to the retail title menu, and do not synthesize the missing choices or Saturn presentation from decoded MENU.BPK surfaces alone.

Runtime boundary

firestaff_nexus must not present a host-built title, champion menu, portrait placement or a text footer as though it were Saturn output. M11 handoff and viewport remain fail-closed until authenticated Saturn captures bind the relevant resource, palette, destination, input action, and timing. Startup has separate gates for title presentation, title-to-menu dispatch, menu surface presentation, New Game/Continue selection, and start-pose/level handoff. Passing a decoder or later handoff gate does not prove the earlier transitions.

Champion portraits are a later champion-select consumer question, not evidence that the title menu is ready. A future champion-select capture must bind a PLRD row to its FACE ordinal, VDP1 command destination, palette/CRAM state, and displayed frame timing. Presence or hash of FACE.BIN alone cannot relax that gate.

Title-menu evidence (2026-10-25)

An isolated Ymir 0.4.1 --debug run with the authenticated Japanese BIOS and retail disc shows the native title menu after holding Start. The screen contains NEW GAME, CONTINUE, and CONFIGURATION; New Game is initially selected. Down selects Continue, and A confirms New Game into the dungeon. A fresh profile with no game save leaves Continue on the same menu and does not prove a save-load route. This establishes retail behavior only; it is not Firestaff parity. Capture details and screenshots are recorded in parity-evidence/verification/keyboard-mouse-debug-20261024/README.md.

The historical direct-CLI probe in parity-evidence/verification/nexus_cli_direct_start_block_20261024/README.md reached the ready title frame but reported menu=0 and levelLoaded=0 after one scripted Return. It did not start Nexus. That receipt names a MENU.BPK PRS3 capture blocker for that build; it should not be read as proof that decoding MENU.BPK alone implements the title-menu transition.

An inspection of the hash-verified Japanese retail MENU.BPK confirms that its 162 PRS3 surfaces decode, and visually identifies save/load panels, Japanese configuration panels, labels, and small button glyphs. The inspected contact sheets did not identify the three English title-menu choices shown by Ymir. This is a content observation, not proof those assets are absent from the game or that MENU.BPK is unrelated to the title menu. Surface ordering, CLUT, consumer, placement, and input-to-action dispatch still require a same-session Saturn trace.

Native title-menu command/source observation (2026-10-27; startup provenance limited)

A retained Ymir menu-state capture has a frame-aligned VDP1 VRAM snapshot and a complete command trace. The available record does not establish that its three-choice screen followed a fresh cold boot in the same run; treat it as a native menu-state reference, not cold-boot-to-menu proof. In that captured menu frame, five textured VDP1 commands reference byte spans that each match exactly once in the authentic Japanese TITLE.BIN: two 24×24 spans at file offset 0x15f6 and three 4bpp text-sized spans at offsets 0x0446, 0x0576, and 0x07d6. The screenshot shows paired selector graphics and three menu labels, making these strong candidate source spans for those visible elements. This observation does not establish each source span’s semantic identity, the Saturn upload route, or the palette’s source owner.

The same capture’s VDP1 VRAM was checked against every decoded surface in the hash-pinned Japanese MENU.BPK (SHA-256 740ab2a864f04b89cddb172ce2560044fcc8c6a7f98ae2fe50461aa8da886636). Although 162 PRS3 surfaces decode, none of the captured textured command source starts falls within an exact matched MENU.BPK surface range. This narrows the current menu asset lead toward TITLE.BIN; it does not prove MENU.BPK is unrelated or that Firestaff can yet compose the menu. The captured data and trace remain external at /Volumes/Extern-disk/firestaff-evidence/ymir_nexus_coldboot_menu_20261027/.

The four distinct 32-byte VDP1 CLUT blocks used by these commands were also compared directly and word-swapped against all 126 hash-accepted Japanese retail files in the local corpus. None matched; five files with unaccepted hashes were excluded. A full VDP1-window SH-2 write trace hit its 250,000-row limit and dropped 45,183,915 master-SH-2 rows, so it cannot establish upload ownership. A second cold boot narrowed tracing to 0x05c29000..0x05c48000 and completed 205,300 rows with zero drops. The final VDP1 VRAM hash matched the visual capture, but the trace values do not reconstruct the final texture spans and the trace has no per-frame markers. Thus the SH-2 writer path and CLUT source remain open.

The narrowed trace provides disassembly anchors in authentic Japanese DM.BIN (SHA-256 3bbca125e0bfb486897e4926541e7c31adbff010d01a9b0c736637f432aad124) under the historical static code mapping 0x06010040: its call-target field is 0x0602623c (file offset 0x161fc), and its caller-return field is 0x06027064 (offset 0x17024). The trace labels write rows with PCs 0x0602625c and 0x0602626c (offsets 0x1621c and 0x1622c), but static SH-2 disassembly exposes an attribution mismatch: 0x0602625c is tst r0,r0, while 0x0602626c is mov.b r5,@r4 inside a loop that advances r4 by 16. The trace reports four-byte writes at both PCs, despite the latter instruction being a byte store. Therefore these PCs and call fields identify a candidate routine for further tracing; they do not yet identify the exact store instruction or authenticate a graphics upload routine. The function also copies a 256-byte block through a helper before modifying its local buffer, but the trace does not join that buffer to the observed texture spans. The separate frame-correlated SCU DMA evidence below joins TITLE.BIN ranges to final VDP1 memory and command reads; it does not resolve this SH-2 trace’s PC attribution or rule out later CPU writes. The four captured 32-byte CLUTs also have no direct or word-swapped exact match in the 126 hash-accepted Japanese retail files, so their palette source remains unbound.

Raw DM.BIN placement in the later Ymir capture

A separate authentic JP Ymir debug capture reached VDP1 capture frame 13,096. Its 1 MiB wram-hi.bin is the raw WorkRAMH image at 0x06000000; the first 256 bytes at 0x06010000 exactly equal bytes 0x0000–0x00ff of the hash-verified retail DM.BIN. The initial SH-2 instructions at that address load the stack pointer and jump to 0x06010014, so this is a concrete raw image placement and entry-vector observation, not a synthetic fixture.

Static SH-2 decoding of the authenticated bytes gives a concrete early boot sequence. The vector at 0x06010000 loads SP=0x060ffffc and jumps to 0x06010014. That entry calls a byte-clear helper at 0x06010026; the helper reads its start and end pointers from 0x060465b0 and 0x060465b4 and writes zero bytes up to the end pointer. The entry then clears the word at 0x06082ea8 and calls the function pointer stored at 0x0601005c, whose retail value is 0x06010f44. If that call returns, the entry branches to a self-loop at 0x06010022. This establishes the static boot path in authentic code; this no-render memory capture does not by itself prove which initializer branches run or what the display shows.

The same image matches DM.BIN at 0x0602623c, 0x0608ba34, and 0x0608b940 when offsets are calculated from 0x06010000. At 0x0608ba46, the matching retail instruction is mov.l r5,@r4; the complete 2,447-row trace records 2,446 four-byte zero writes from that PC into VDP1 CLUT addresses 0x05c01000 and 0x05c01010, plus one earlier two-byte 0x8000 write. The trace has zero dropped rows. In the matched retail body at 0x0608ba34, the routine masks its start pointer with 0x1ffffff0, ORs in 0x40000000, sets the store value to zero, then writes one longword and advances the pointer by 16 bytes until it reaches the computed end. This is a strided initialization clear, not evidence of a palette upload or palette ownership.

This raw image placement must not be conflated with the older frame-12596 title-copy receipt’s static 0x06010040 code mapping. The newer snapshot has different bytes at runtime PCs 0x0602312c, 0x0602625c, and 0x0602626c; thus the old mapping and instruction attribution are capture-specific and do not establish a global DM.BIN executable base. The older SH-2 trace still does not identify its exact store instruction or prove a texture upload. Selected raw evidence is retained at /Volumes/Extern-disk/firestaff-data/nexus-menu-clut-writer-trace-20261027/.

FONT256’s authenticated Character Generator bytes now remain in the engine’s source object for the future Saturn consumer. This does not admit glyph coding, page/PND attributes, layer placement, or text writing; font_loaded remains closed until those parts are bound by the same runtime witness.

Debug boot memory receipt (2026-10-26)

A system-built Ymir 0.4.2-dev run on TRV2 booted the hash-verified Japanese retail cue for 600 deterministic frames with --debug. It used the verified Japanese BIOS (SHA-256 dcfef4b99605f872b6c3b6d05c045385cdea3d1b702906a0ed930df7bcb7deac) and recorded bounded SH-2 writes to 0x05c00000..0x05c80000. The resulting VDP1 VRAM dump is SHA-256 0e0a67c1eec3c0bf61e7358ded889d3df343a5cb7bd1154b6422636d57bf1d74.

The capture used Ymir’s explicit no-render mode so that it could retain real emulated memory and CPU-write evidence without producing a synthetic host frame. It must not be used for visual parity, title/menu placement, or HUD claims. The raw dump and write trace are retained outside the repository on the external evidence volume; only their reproducible receipt is recorded here.

Long boot memory trace (2026-10-26)

A separate Ymir --debug --capture-boot-frames 13000 run retained a full memory snapshot after normal disc boot. The final VDP1 counter was 12947; its complete command trace had four terminal records and no VDP1 trace drops. The bounded source scanner found no supported textured draw commands in that final frame. VDP2 had NBG0, NBG1, and NBG2 enabled (BGON=0x0007, CHCTLA=0x1212). The SH-2 write trace reached its 250,000-row cap and reports 420,006 dropped master-SH-2 rows, so it cannot establish complete writer provenance.

Both NBG0 and NBG1 were 8bpp bitmap layers at VRAM offsets 0x00000 and 0x20000. Comparison with the authentic retail TITLE.BIN and MENU.BPK data found no exact pixel-span or palette joins. The largest partial byte matches were 118 bytes to TITLE.BIN map 4, 99 bytes to a repeated MENU.BPK surface sequence, and 35 bytes to TITLE.BIN maps 1 and 3; these do not prove asset ownership. A diagnostic decode of the captured NBG0 bytes and CRAM shows Japanese date/time settings, the date 2026-10-26, and Cancel / Confirm labels. This looks like a system date/time page and is not evidence that Nexus reached its title menu.

This capture used --capture-no-render: both VDP1 framebuffers are zeroed and there is no screenshot. It is useful as a register and memory checkpoint only; it does not identify what appeared on screen or prove that Nexus reached a particular game menu. The raw files, SHA-256 list, and clearly labelled layer diagnostic previews are retained off-repository.

Captured title-menu frame reconstruction (2026-10-26)

The atomic frame-59 Ymir capture loaded a previously saved Japanese retail title-prompt state, held Start for 60 of 120 capture frames, and dumped memory and the VDP1 trace in the same run. It was not a cold boot. A bounded C replay combines the retained VDP1 display framebuffer, NBG0 8bpp bitmap, CRAM, registers, and verified zero back-screen table. Its output matches all 286,720 pixels of the hash-pinned 640×448 Ymir screenshot exactly. This confirms static composition for the captured menu frame; the screenshot was saved after the memory dump, so exact frame identity is still unproven.

The replay remains capture-only and does not feed the Firestaff viewport or establish cold-boot-to-menu behavior, title-to-menu input handling, or gameplay HUD. Separately, a 13,000-loop cold boot with --capture-no-render stopped on a Japanese date/time settings page. That run has no screenshot and incomplete SH-2 write tracing; it does not prove that Nexus reached the game title. See the boot-dump receipt on the external evidence disk and full capture receipt and SHA-256 identities for the menu-state reproduction command and exact scope.

Deterministic cold boot reaches the native title prompt (2026-10-27)

Ymir 0.4.2-dev was built on TRV2 with the repeatable --capture-pad-input FRAME:BUTTON:HOLD option (submitted to the Yeager Ymir fork in PR #1). A fresh isolated Ymir profile used the authenticated Japanese Saturn BIOS (SHA-256 dcfef4b99605f872b6c3b6d05c045385cdea3d1b702906a0ed930df7bcb7deac) and the real Japanese retail cue /home/trv2/.firestaff/data/nexus/Dungeon Master Nexus (Japan).cue. The isolated profile was marked onboarded to bypass Ymir’s first-run UI; no game state or saved game was loaded.

The deterministic boot schedule pressed Right at frames 700, 720, 740, 760, 780, and 800, then A at frame 830 to confirm the Japanese BIOS date/time screen. It sent Start for 2 frames at frame 7000 to advance past the opening intro, then held Start for 60 frames at frame 9000 on the title prompt. The 9,120-frame rendered capture shows the native PRESS START BUTTON title prompt. It does not show the three-choice NEW GAME / CONTINUE / CONFIGURATION menu. The run loaded no emulator state and no game save, so it verifies cold boot to the title prompt only.

The emulator was Ymir 0.4.2-dev with --debug, built on TRV2 from the branch that adds repeatable --capture-pad-input FRAME:BUTTON:HOLD scheduling. The authentic Japanese cue SHA-256 is 878b3bc223bb56e99626dbaa2946d17fb349a2a67a10cd4423742d8ab30b8699. The controller-scheduler change is submitted to the Yeager Ymir fork in PR #1.

The rendered title-prompt screenshot, complete raw memory dump, source-join report, and bounded SH-2 write traces are retained on the external evidence volume. SHA256SUMS.txt covers the screenshot, all 30 dump files, the Japanese MENU.BPK, the source-join report, and both write-trace captures. The separate three-choice menu screenshot is a retained menu-state reference whose clean cold-boot provenance is not established.

The exact command was:

ymir-sdl3 --debug --capture-boot-frames 9120 --dump-memory --capture-screenshot \
  --capture-pad-input 700:right:2 --capture-pad-input 720:right:2 \
  --capture-pad-input 740:right:2 --capture-pad-input 760:right:2 \
  --capture-pad-input 780:right:2 --capture-pad-input 800:right:2 \
  --capture-pad-input 830:a:2 --capture-pad-input 7000:start:2 \
  --capture-pad-input 9000:start:60 \
  "/home/trv2/.firestaff/data/nexus/Dungeon Master Nexus (Japan).cue"

This closes the Ymir cold-boot-to-native-menu evidence gap. The separate New Game replay also reaches a native 3D viewport, as recorded below. These emulator results do not establish Firestaff menu rendering or control, a stable interactive gameplay route, real-save loading through Continue, or HUD parity. Those remain separate production-parity gates.

Cold-boot follow-up: exact retail FMV frame match (2026-10-27)

A rendered 19,000-frame Ymir run used the authentic Japanese retail disc and Japanese IPL in the isolated TRV2 profile. It loaded no emulator save state or game save; the profile retained its BIOS setup configuration. With --debug --fast-forward, Start was held for two frames at capture-loop frames 9,000, 13,000, and 15,000.

The endpoint screenshot is an exact match to zero-based frame 626 of the authentic Japanese retail DMV0.AVI video. The AVI SHA-256 is eafb4c638db9ffada9e929d82299562e0a9d3eb73fb2a47858c0de0dc0fa57bb; it is RIFF AVI using TrueMotion 1.0 at 320×180 and approximately 15 fps. The native Ymir screenshot is 640×448. Its centered crop image[42:402:2, ::2] matches all 57,600 decoded frame pixels after Saturn RGB5 quantization (& 0xF8), with zero mismatches.

The final VDP1 capture is frame 15,907, with four command rows and 785,986 retained trace rows with zero drops. The video draw at command offset 0x40 uses PMOD 0x0028 (colour mode 5), SRCA 0x8f80 (VRAM byte offset 0x47c00), and SIZE 0x28b4 (320×180), placing the image at y=21–200. Capture-loop frame 19,000 and VDP1 frame 15,907 are separate counters. The SCU DMA trace retained 16,384 rows but dropped 4,485 (trace_data_complete=0), so it cannot provide complete transfer provenance.

This confirms authentic full-screen video output, likely the opening FMV in this boot sequence. It does not prove which input selected or started the video, the three-choice menu transition, a stable playable level, gameplay, or HUD.

The Ymir executable SHA-256 is f5d94ee84762d81e97f950d6cfc4253b4f72c61dc5c4f376b4296235ed46dcc3. At inspection, its source worktree was based on commit 534ed10c6f7f13a3ba752476eea191be3ab553b4 with tracked-diff SHA-256 2442944df961bf0079f61a032b2ca09f3252be4416a28471aee72573b49e4d5d. These identify the observed executable and source worktree state; they do not independently prove the binary was built from that exact source snapshot.

The screenshot, raw Ymir dumps, run log, reproducible RGB5 comparison, and retail TM.BIN disassembly receipts are retained at /Volumes/Extern-disk/firestaff-evidence/ymir_nexus_coldboot_rendered_20261027/rendered_menu_candidate_19000/. The screenshot SHA-256 is 903e710b455df66a1df79adcdf1e1a9a6c8fdc257833f0eed9e80def840d541a; the run log SHA-256 is caf636e378d9888b4c97e01b12ddd864b0564e292fceb6f5ffc97b14f442d282; the DMV0_FRAME_MATCH.txt SHA-256 is 51081a26e28878ac6f90a102fe79c76a51c519d3aba5c23f7e9b4612364d298f; the TM_BIN_AVI_DISPATCH.txt SHA-256 is 884a62d68879edec2239fcafb0addec581c3e27ae252ddc606c4240303658d40; README.md SHA-256 is 42ee176d4a06c539864fbcd4e68a176ea1ea579627be31ea0699faa5d0ade67a; and SHA256SUMS.txt SHA-256 is 6d831e2f30bbf32031ae0586f152a5ee0aef80d67cec0183a76fba8a7ed27ae1. All 37 listed bundle files passed checksum verification. This is diagnostic evidence; it is not a Firestaff asset or a parity admission.

Retail TM.BIN video dispatcher disassembly (2026-10-27)

The authentic Japanese retail TM.BIN is 160,044 bytes with SHA-256 d87485fe6eba1f6e9fbbf487f5fcdd994911136905e6172e5bb5bc0122407eb6. With load base 0x06010000, the three embedded video-name strings map to: DMV0.AVI at file offset 0x1968c / runtime 0x0602968c, DMV1.AVI at 0x19698 / 0x06029698, and DMV2.AVI at 0x196a4 / 0x060296a4.

The module entry routine at file offset 0x00 reads the selector at SH-2 address 0x00200000 at PC 0x0601006c. It branches on values 0, 1, or 2 and loads the corresponding AVI pointer from its literal pool at offsets 0x260, 0x264, and 0x268. It calls the shared playback routine at 0x06010eec; the DMV0 branch passes 0x000a0000 in r5. After the shared playback call returns, the routine makes further calls and reads the word at 0x06029978. If it is not 2, control branches to 0x060100e0. If it is 2, the code tests the word addressed by r14: when nonzero, it clears byte 0x0020000b and branches to 0x060100e0; when zero, it loads a call target from 0x0600026c and calls through that pointer. These are static control-flow observations, not proof of the values used during cold boot or the following menu transition.

The retained excerpt was produced with GNU objdump’s -m sh4 decoder setting. The retail Saturn CPU is SH-2; this evidence claims only the displayed opcode bytes and their compatible control flow, not an SH-4 execution target. The reproducible command and raw output are retained at /Volumes/Extern-disk/firestaff-evidence/ymir_nexus_coldboot_rendered_20261027/rendered_menu_candidate_19000/TM_BIN_AVI_DISPATCH.txt.

This is high-confidence static evidence of a retail three-video dispatcher and shared playback call. Together with the exact DMV0 frame-626 pixel match above, it connects the rendered screenshot to the authentic video path. It does not show which caller sets selector 0x00200000 during cold boot, establish selector 0 as the startup default, identify the Start skip behavior, or prove how the three-choice menu is entered. The load base is supported by the AVI pointer arithmetic and the documented TM overlay mapping at file offset 0x4500 to runtime 0x06014500; it remains a disassembly load hypothesis.

DM.BIN contains resource-string anchors for MENU.BPK, yam\menu.c, FONT256.S2D, and STABG.BIN at offsets 0x373b4–0x373d8, and TITLE.CG / TITLE.BIN at 0x38e6c / 0x38e78. These strings do not identify the title-menu entry routine. The next useful dynamic trace should capture SH-2 call/branch edges and selector/return globals around cold-boot loop frames 6,900–7,100 and 8,900–9,120, then correlate them with Start reads and frame-indexed VDP1 commands.

Complete cold-boot SCU DMA trace (2026-10-27)

A follow-up run used Ymir’s explicit SCU DMA trace route with the same hash-verified Japanese retail cue, BIOS, and deterministic cold-boot pad schedule described above. Ymir was run with --debug --capture-boot-frames 9120 --dump-memory --capture-no-present --capture-no-render --trace-scu-dma. The emulator loaded no save state or game save. Input timing was recorded in the retained run log. The full capture retained 8,399 SCU DMA transfers in an 8,400-line CSV including its header; the manifest reports a 16,384-row capacity, zero dropped rows, no overflow, and complete trace data.

The retained SCU DMA table records transfer metadata; it does not contain the transferred payload bytes. The listed source addresses were compared with the final captured high-WRAM image, final VDP1 VRAM, and the authentic Japanese TITLE.BIN (SHA-256 51f1f18b68acf5993b00ffcb458ef2a7372b21595656f3ed5b95520c9a305fc3, 112,216 bytes). Several final high-WRAM spans at the recorded source addresses match exactly:

The 288-byte source address of transfer 3778 (0x060ab4c6) corresponds to VDP1 VRAM address 0x05c43be0 in the trace, but its final WRAM bytes do not match the cited TITLE.BIN span; its source ownership remains unassigned. The SCU trace records transfer order, source/destination addresses, and counts, not payload bytes or a per-transfer frame number. These comparisons are final-state byte/address evidence from one deterministic run. They do not prove that a DMA payload matched TITLE.BIN or timestamp a transfer to the VDP1 menu frame.

The external evidence bundle is retained at /Volumes/Extern-disk/firestaff-evidence/ymir_nexus_coldboot_menu_20261027/scu_dma_complete_20261027/. Its manifest SHA-256 is 5b2ede0748d3a4b009f4d6d781e1fbc9897c114be270e69a567daf277cefed36; the trace CSV SHA-256 is 718f10d71fcae26437224362abf245f594fdb07d15cb3732ddebbd4d7322039c. The bundle’s SHA256SUMS.txt was checked against every retained artifact. The same trace functionality is proposed in Yeager Ymir PR #2, stacked on its deterministic input capture PR #1.

The retained README does not record the Ymir source revision used to build this capture. The TRV2 worktree inspected during this follow-up has base commit bf68a2fdb13e533e7b6c6c9a511701ec52609220 and an uncommitted tracked diff whose SHA-256 is ec59cfa728cb73f032836eaa5d8782bdfdf1bc1702d906af6b3ef627a2e95082. This identifies the inspected worktree state, but the retained capture does not bind that state to the executable; the exact build revision is therefore unverified.

This adds reproducible evidence linking recorded DMA source addresses to matching bytes in the final WRAM snapshot for the authentic cold boot. It does not prove the payload bytes transferred, label the exact semantic role of each texture, bind the palette source, prove transfer-to-frame timing, or admit a Firestaff title-menu renderer. The existing production gates remain in force.

SCU DMA transfers indexed by deterministic capture frame (2026-10-27)

A follow-up authentic cold-boot run added a zero-based CLI capture-loop frame to every SCU DMA transfer row. It used the same hash-verified Japanese retail disc and BIOS, with no save state or game save. The capture ran 9,120 frames with --debug --capture-no-present --capture-no-render --trace-scu-dma and the same deterministic date/time, intro-skip, and title-prompt inputs documented above. The no-render run has no screenshot and cannot establish displayed pixels.

The SCU manifest reports 7,986 retained transfers, zero dropped rows, and complete trace data. The CSV has 7,987 lines including its header. Transfer rows 3347, 3348, 3350, and 3360 are each indexed to capture-loop frame 7564. At each listed source address in the final high-WRAM snapshot and destination range in the final VDP1 VRAM snapshot, the bytes independently match the corresponding authentic Japanese TITLE.BIN span. The metadata row counts and addresses align these snapshots; the trace itself does not contain transfer payload bytes:

These values are capture-loop frames, not VDP1 frame numbers. The VDP1 receipt for this dump ends at VDP1 frame 8037 with 178 commands for that frame; the run does not provide an exact mapping between the two counters. The data therefore strengthens byte provenance and deterministic timing, but does not assign semantic labels to texture spans, identify palette ownership, or prove a transfer-to-displayed-frame relation.

The raw dump bundle and reproducible receipt are retained at /Volumes/Extern-disk/firestaff-evidence/ymir_nexus_coldboot_menu_20261027/scu_dma_frame_index_20261027/. Its README SHA-256 is 65c2fe206b937c3dc2a4e09cb1626389db458c9b9f5ca89a01b678a044a07c7d, its checksum-list SHA-256 is e9716f9f444789cba25613cab128e8a92a1400a49888f0948e3ac315e359f849, and the SCU CSV SHA-256 is 77e3e2e1e667956092e1fd75b183e5e0929f1dd698d22364171be90561e4a4bb. All 31 dump files were verified after transfer to the external evidence disk.

This capture uses the frame-indexed exporter proposed in Yeager Ymir PR #2. It remains diagnostic evidence; the Firestaff title-menu rendering and interaction gates stay closed.

SCU DMA to VDP1 frame correlation (2026-10-27)

A subsequent run used Ymir’s trace-bundle v4, which records the VDP1 frame index immediately before and after each deterministic capture-loop frame. Four SCU DMA transfers at capture-loop frame 7564 all have VDP1 frame 6890 both before and after the emulated frame. This pins the transfers to VDP1 frame 6890, rather than estimating their VDP1 time from the overall capture length.

The final high-WRAM source spans and final VDP1 VRAM destination spans for transfers 3347, 3348, 3350, and 3360 independently match authentic Japanese TITLE.BIN offsets 0x0446, 0x0576, 0x07d6, and 0x15f6. The trace records addresses, counts, and timing metadata, not the bytes on the DMA bus.

The same run’s final VDP1 frame is 8037. Its 178-command trace has five textured draws at indices 171–175 reading from those four VDP1 destinations: two 192×3 draws at 0x44060, then 64×8 at 0x47de0, 64×8 at 0x479e0, and 64×13 at 0x46f60. The source byte counts and addresses match the transfer destinations and TITLE.BIN joins. A check of the SCU trace found no later SCU DMA writes overlapping these four destination ranges. This correlates the final snapshot bytes with VDP1 command reads in one cold-boot run. It does not prove that the SCU DMA bus transferred those exact bytes, because the trace is metadata-only and later CPU writes are not excluded. CLUT ownership also remains unresolved.

The five corresponding command records in the earlier rendered native-menu capture at VDP1 frame 8050 match these draw words, geometry, and source addresses; only their VDP1 link word differs. That separate rendered capture has the retained menu screenshot at /Volumes/Extern-disk/firestaff-evidence/ymir_nexus_coldboot_menu_20261027/title-menu.png, SHA-256 8721cce3354bc20b1cd367fd44be3d4ecc60ca65fa89c7d00654e83f5ad7db23. The current trace-v4 run used no-render mode and has no screenshot, so it cannot establish its own displayed pixels.

The complete raw capture and receipt are retained at /Volumes/Extern-disk/firestaff-evidence/ymir_nexus_coldboot_menu_20261027/scu_dma_vdp1_frame_map_20261027/. Its README SHA-256 is 5fb18214931b5837b9e7fcaf02d933cc91f7f741d45d59c4fffce6a0033875bb, the checksum-list SHA-256 is ccb38a615a5ae0f5d1dbf514431a2ad17e77f0b21877852e213140b30ac21a18, and the SCU trace CSV SHA-256 is 2b008715262da43fb9d675a87cc92695a36eb64a26a3e014af3dda89a6e7b6e8. All 32 dump files were verified after copying to the external evidence disk. The supporting exporter update is in Yeager Ymir PR #2.

This is stronger source-to-command evidence for the native menu path, but it still does not provide CLUT source ownership or admit a Firestaff renderer.

Sources

• DMWeb Nexus file formats and DMN Data File Decoder.
• src/nexus/nexus_v1_engine.c and src/nexus/nexus_v1_title.c.
• docs/nexus/NEXUS_RUNTIME_CAPTURE.md.
• NEXUS_STRICT_FIDELITY_INVENTORY.md.

Cold-boot title menu and retail menu navigation (2026-10-27)

A rendered Ymir 0.4.2-dev run on TRV2 used the authentic Japanese retail disc and BIOS in an isolated profile. It loaded no emulator state or game save. After confirming the BIOS date/time screen, the deterministic schedule sent Start for two frames at capture-loop frames 9,000 and 13,000, then one frame at 15,000. At 16,000 capture-loop frames, the rendered retail screen is the native three-choice menu: NEW GAME, CONTINUE, and CONFIGURATION. This extends the clean-boot evidence beyond the title prompt; it remains an emulator capture, not a Firestaff menu implementation.

The endpoint was saved as diagnostic emulator slot 3. Reloading that state and advancing two frames with no input leaves the main menu visible. From the same state, one frame of Down moves the selection from NEW GAME to CONTINUE. Two one-frame Down pulses followed by a one-frame A pulse open the native CONFIGURATION page, which displays Music, Sound, Game level, Monster gauge, and Exit. These short replay captures establish that Ymir’s frame-indexed input route drives these visible menu transitions from this authentic retail state. The saved emulator state contains no game save.

The final capture receipt reports VDP1 frame 13,108 and command cursor 168. These are distinct from the 16,000-loop-frame capture counter. The evidence bundle, screenshots, run log, VDP dumps, and saved state are retained on the external evidence disk at /Volumes/Extern-disk/firestaff-evidence/ymir_nexus_coldboot_rendered_20261027/. The cold-boot menu screenshot SHA-256 is 2b64c0baeb8f006f68176eb1f70bc7e4c626db9ec77f2157a1d20daef89387ec; the no-input replay is 4476cc68722372b9f57b237374801a12bcfdac6d2e8aa068f575aa8bc87960c4; the Down replay is 70ef5517ba73309fb63722a2af3c553e7863e02ab10ebf1414bc19a1cf9548a1; and the Configuration replay is dffac2f786b92b543ddfed7b6eb969d50b5f2b7e115a5e1a2423537c01e18427. All 24 retained files in the new bundle pass its SHA-256 manifest.

The original run used --debug --capture-boot-frames 16000 --dump-memory --capture-screenshot --capture-save-state 3 with deterministic Start pulses at frames 9,000, 13,000, and 15,000. The navigation replays used --load-state 3 --capture-frames with no input, Down, or Down/Down/A respectively. The full commands and hashes are recorded in the external bundle README.

This establishes a native retail menu and a narrow menu-navigation route in Ymir after a no-save cold boot. It does not prove the semantic purpose of every input across regions, a stable New Game transition to a playable level, Continue behavior with real save data, Firestaff menu input or destination execution, or gameplay HUD/viewport parity. The English foreground sprite rendering is implemented as described below; the background and full-screen composition remain open.

New Game reaches the native 3D viewport (2026-10-27)

A short Ymir replay loaded diagnostic slot 3 from the no-save cold-boot menu capture, where NEW GAME was selected. It pressed Control Pad 1 A for two capture frames and advanced 1,200 frames with --debug --fast-forward --capture-no-present. The final 640×448 image is the native first-person corridor viewport. Its SHA-256 is 8ede95f1fd777eda69ebcfc91d0268194e501f145306eb1fc2971ed0113a2274, matching the previously retained retail viewport checkpoint.

The complete VDP1 trace retained 137,849 rows with zero drops. The final capture is VDP1 frame 1,005 with 151 command rows; the 1,200-frame Ymir capture-loop counter is separate. The screenshot shows no party HUD. The diagnostic profile was isolated under TRV2 /dev/shm; no retail save or Firestaff data was modified.

The screenshot, VDP1 register/trace receipts, run log, and checksum manifest are retained at /Volumes/Extern-disk/firestaff-evidence/ymir_nexus_coldboot_rendered_20261027/replay_new_game_from_menu/. The screenshot SHA-256 is 8ede95f1fd777eda69ebcfc91d0268194e501f145306eb1fc2971ed0113a2274; the checksum manifest SHA-256 is c10afefda0c76e2786a321b40942939bd252c31dee6bcdfb11f2c8978ee5b845. Every listed artifact passed verification.

This verifies that selecting NEW GAME from the native retail menu reached a native 3D viewport in this run. It does not establish a stable or fully interactive level, exact room/resource identity, the full gameplay input route, the party HUD, or Firestaff presentation parity. Those remain separate gates.

Additional menu-candidate VDP1 source join (2026-10-27)

A separate Ymir debug dump from the authentic Japanese retail corpus records 178 VDP1 commands at frame 8050 with no dropped rows. Its command records are 175/178 identical to the retained title-menu capture at frame 497 when live local-coordinate fields are excluded. The three differences occur at command indices 171, 172, and 177. Because this dump has no paired screenshot or input schedule receipt, it remains a menu candidate rather than a new menu-state admission.

Against the hash-verified Japanese retail corpus, 121 of 137 textured VDP1 commands have informative exact-byte joins, including LEV00.DGN Structure2 spans; 16 command spans remain ambiguous across repeated retail bytes. The real Japanese MENU.BPK decodes to 162 PRS3 surfaces, of which 86 exact whole surface byte sequences are resident in the captured VDP1 VRAM. None of the 137 textured commands starts inside those matched surface ranges. This establishes byte residency and command-source observations only; it does not prove that the menu draws MENU.BPK, identify the remaining command owners, or authorize Firestaff rendering.

Raw capture bytes remain outside Git under /Volumes/Extern-disk/firestaff-data/. Hashes, analyzer output, and reproduction commands are recorded in nexus_v1_menu_candidate_source_join_20261027.

English-version boot attempt and menu-asset residency (2026-10-27)

A separate run used the authenticated English-version ISO and the installed system Ymir executable on TRV2. The earlier empty-profile attempt stalled before reading the game startup file. A follow-up profile reused the Japanese profile’s saved SMPC persistence bytes as emulator setup state, with the English disc and USA 1.01a BIOS. This changed no disc or game-save data.

Ymir logged a read of authentic 0DMSTRT.BIN (SHA-256 8a026f155af27cfd43a33b29f7da5b75ee7b09b2c4f016fc3be1ebb4787d20b6) followed by a CD Block soft reset. It did not log a DM.BIN read. The resulting VDP1 snapshot is frame 12467 with 168 command rows, but the trace ends before the last command’s CMDLINK target and has no END command. The complete-command source join therefore rejects it.

The installed English MENU.BPK matches the authentic retail SHA-256 f2f78dddfe37a5ff414775ae888f164624e987059934b034ba36299cc769d2ca. Of its 162 bounded PRS3 surfaces, 86 have exact byte matches in the captured VDP1 VRAM using direct or word-swapped comparisons; all 86 include a direct match, and none matches only after word swapping. In that frame, 132 commands are textured sprites and none starts inside the matched surface ranges. This proves only that those retail bytes are resident in VDP1 VRAM; it does not prove that the title menu is displayed or that those surfaces are drawn. The regional snapshot analyzer now accepts the authenticated Japanese, English, and French MENU.BPK hashes; its English report records these counts and keeps semantic_admission=blocked. All three authentic regional packages decode all 162 PRS3 surfaces with this analyzer. The VDP2 write trace dropped 1,376,570 rows, and the SCU DMA trace reports unknown overflow, so neither trace establishes complete transfer provenance.

The full capture and analysis are retained on the external evidence volume at /Volumes/Extern-disk/firestaff-data/nexus-english-boot-20261027/english-us-smem-13310/. A later controlled run supersedes that conclusion. Its full VDP1 command list and native English menu are documented below; the earlier run remains useful only as an incomplete capture receipt.

English cold boot reaches the native title menu (2026-10-27)

A fresh controlled run used the authenticated English-version disc image, USA 1.01a IPL ROM, and the installed Ymir 0.4.2-dev executable on TRV2 with debug tracing enabled. The ISO SHA-256 is 16786e6165d8cbf7f6394dd9bc7171fbb561c1ba40b77ad7cba3c275fde2804e, the CUE SHA-256 is b96f01e2f8ce3ab9c8e4a33d5a0c7076cdc1bfd247a85a1454e6c36c8a616f33, and the IPL ROM SHA-256 is 96e106f740ab448cf89f0dd49dfbac7fe5391cb6bd6e14ad5e3061c13330266f. The emulator profile reused Japanese SMPC persistence bytes for setup; no emulator save state was loaded and no game save was present. No disc or save data was modified.

The retained screenshot shows the English-version title screen and all three native choices: NEW GAME, CONTINUE, and CONFIGURATION. Its SHA-256 is 341cb38191bfbb563912d6ef0c6e2989d51eb6136d48fcffee197cafd7264810. A read-only replay of the same-frame VDP1 display framebuffer, NBG0 bitmap, VDP2 CRAM, and registers reconstructs a 320×224 image that matches every RGB pixel when scaled 2× to the screenshot. The registers enable only NBG0 as an 8bpp bitmap (BGON=0x0001, CHCTLA=0x0013). This verifies same-frame composition but does not identify the bitmap’s retail source or admit the capture-only replay as a production renderer. The frame-aligned VDP1 bundle is frame 13106 with 178 command rows, a complete trace, and zero dropped rows. The retail source join binds nonzero texture bytes for 126 of 137 textured draws; the other 11 source spans are all zero and are excluded as uninformative padding. This is partial byte provenance, not complete surface, palette, order, or consumer ownership.

The authentic English MENU.BPK still has 86 of 162 decoded PRS3 surfaces whose bytes occur in VDP1 VRAM, but none of the 137 textured command source starts falls inside those matched surface ranges. The capture therefore does not establish that MENU.BPK supplies the visible menu. The native screen is visible in Ymir, while Firestaff’s production title/menu composition and presentation remain unimplemented or unadmitted by the existing evidence gates.

Ymir’s log records 0DMSTRT.BIN and a CD Block soft reset, but no DM.BIN file-read event. Independently, the captured wram-hi.bin contains an exact 230,669-byte prefix of the authenticated 555,144-byte English DM.BIN at raw dump offset 0x10000; this proves that this prefix was resident in WRAM, not that the full file was loaded or that the log’s read path is understood. The retained evidence is stored outside Git in the local external capture bundle. This establishes the English-version emulator’s cold-boot-to-menu path. It does not establish complete Firestaff menu composition or input, Continue/save loading, or playable-level, viewport, or HUD parity. See the English cold-boot evidence receipt for hashes and reproduction commands.

English retail title-menu sprite ownership (2026-10-27)

Firestaff now has a bounded renderer for the authenticated English NEW GAME and CONTINUE VDP1 sprites described below. It accepts only the exact hash-pinned English retail TITLE.BIN, retains that source buffer with the loaded title, and draws the five captured sprites and their captured palette colors at the verified positions over the existing title framebuffer. This implements those foreground sprites only. The background bitmap remains unbound, and the renderer does not claim full-screen composition, Japanese New Game, Configuration, or destination execution. The runtime menu reducer remains responsible for selection; an unsupported selection is left to the existing title renderer.

A follow-up used a copy of the authentic English menu savestate (a997636cb5b40745e1065827361d3653c07475e716c8397542f36c372514f62b) in a separate Ymir profile on TRV2. The copied savestate, English retail ISO and CUE, and USA 1.01a IPL hashes are recorded in the sprite source receipt. One 12-frame run held no input and retained New Game. A second run held Down for four frames beginning at capture frame 4 and retained Continue. Both frame-aligned VDP1 bundles identify frame 5, contain all 178 command rows, and report zero dropped rows.

The retail TITLE.BIN SHA-256 is a634e8daf2a581df154b454919ee2ed44e937371668219d7cdf6d0983a613e44. For New Game, the five visible VDP1 draws read retail offsets 0x14a6, 0x14a6, 0x0446, 0x0576, and 0x07d6. For Continue, they read 0x0316, 0x14a6, 0x14a6, 0x06a6, and 0x07d6. Their two distinct 16-color palettes match captured CRAM bytes to TITLE.BIN: the icon palette matches uniquely at 0x1486, while the identical text palette occurs at 0x02f6, 0x0426, 0x0556, 0x0686, 0x07b6, 0x0986, and 0x1f06. The capture cannot distinguish which identical text-palette copy was uploaded. Captured dimensions, VDP1 placement, sprite priority, CRAM colors, and VDP2 back-screen composition reproduce all 1,451 visible pixels in each screenshot. The external captures and extracted retail TITLE.BIN are retained at /Volumes/Extern-disk/firestaff-evidence/nexus/nexus_english_menu_source_join_20261027/.

This binds the five English menu sprites and both palette tables to authentic TITLE.BIN data and the captured display colors. Firestaff renders the two verified foreground layouts, but this does not bind the background bitmap, full-screen composition, upload timing, the Configuration page, or the complete menu interaction route. The wider English VDP1 source join remains partial at 126 of 137 informative draws; its remaining 11 spans are zero padding. A byte-for-byte pair comparison of the separate New Game and Continue savestate replays shows identical full VDP2 VRAM, CRAM, and register snapshots at capture frame 5. Their NBG0 bitmap is unchanged (SHA-256 b802a3196a9d2183b336ab5c770028670ed658e8ed9ba582046096fc01d23f91); only the compared VDP1 VRAM, framebuffer, and command trace differ. This isolates the observed selection change to VDP1 state without identifying the shared background’s retail producer. Exact VDP2 hashes and changed-byte counts are in the English sprite receipt. The bounded retail-source scan reports zero exact NBG0 matches across 410 decoded sources from the authenticated English disc members; its result remains source_join=unbound and semantic_admission=blocked. An additional raw-byte scan finds one sparse 1,603-byte overlap between TITLE.BIN (0xa2b6) and NBG0 (0x102b0); the same bytes appear once in the captured SH-2 WRAM-high snapshot. Only 23 bytes are nonzero, and no VDP2 write trace links that buffer to the bitmap, so the overlap remains an unproven producer candidate. Details and hashes are in the English sprite receipt.

Japanese New Game and Continue foreground rendering (2026-10-28)

The Japanese New Game and Continue layouts are admitted only for the authenticated Japanese retail TITLE.BIN (SHA-256 51f1f18b68acf5993b00ffcb458ef2a7372b21595656f3ed5b95520c9a305fc3, FNV-1a64 064414f722d0409c). Firestaff draws five source-bound foreground sprites for both observed Japanese menu selections. The New Game frame 8,050 markers use source offset 0x15f6, with their palette uniquely at 0x15d6; Continue frame 8,047 uses marker source 0x1b36, with its palette uniquely at 0x1b16. Text CRAM palette bytes match seven identical copies in TITLE.BIN (0x02f6, 0x0426, 0x0556, 0x0686, 0x07b6, 0x0986, and 0x1f06). The renderer uses those regional palette bytes and the captured 31/32 blend over the verified black back-screen. It does not substitute English art or color.

verify_nexus_title_sprite_screenshot.py confirms all five source spans, regional palette bytes, and all 1,495 visible New Game texels and 1,441 visible Continue texels against their retained Japanese screenshots. The screenshot’s exact acquisition-frame identity remains unproven. The background, full-screen composition, Configuration page controls, Continue loading, and gameplay HUD/viewport remain open. Both regional Configuration renderers and all three regional title-row mouse selections are source-bound. See the Japanese sprite evidence receipt.

The two captures have byte-identical first 128 KiB of VDP2 VRAM (NBG0), SHA-256 0a3b8b5ba0bd9e9c4b549d136961b44439d2534cbb7060c5bcbdca6da9c53d08, with 18,513 nonzero bytes. No complete decoded Japanese retail source matches that bitmap. A separate, complete frame-tagged VDP2 trace joins a 921-byte raw span from Japanese TITLE.BIN TITL record 2 (0xb438 + 0x46a) to NBG0 offset 0xd404. Retail frame 6,869 clears that span; frame 7,729 writes 608 matching byte lanes, and replaying the intervening writes reconstructs all 921 source bytes. The bound snapshot is frame 8,060. Its 295 nonzero pixels occupy native NBG0 coordinates x=13..307, y=106, the blue divider below the logo in the paired Ymir screenshot. This verifies a partial source-to-VRAM transport, not the full bitmap decode, layer meaning, or presentation. See the NBG0 source-trace receipt.

Authentic Japanese title-menu Down selection (2026-10-27)

A fresh isolated Ymir profile cold-booted the hash-verified Japanese retail disc with the authenticated Japanese IPL. After the established BIOS date/time and title-prompt input schedule, Control Pad 1 Down was held for two frames at capture frame 9,100. The native screenshot shows CONTINUE selected. The run loaded no emulator state or game save; Ymir created a new internal backup-RAM image in the fresh profile. No retail data was modified.

The 8,047 VDP1 frame contains 178 commands, and the command trace is complete with no dropped rows. The final five active texture draws have exact byte matches in the authentic Japanese TITLE.BIN: command 171 at VDP1 source 0x481e0 reads 256 bytes matching offset 0x0316; commands 172 and 173 at 0x42e60 each read 288 bytes matching offset 0x1b36; command 174 at 0x475e0 reads 256 bytes matching offset 0x06a6; and command 175 at 0x46f60 reads 416 bytes matching offset 0x07d6. The command table relocates between runs, so the screenshot verifier selects roles by retail source offset, dimensions, screen position and visible-pixel count rather than command address. The earlier retained cold-boot image with NEW GAME selected has a separate four-draw source-offset observation at TITLE.BIN offsets 0x15f6, 0x0446, 0x0576, and 0x07d6; this verifier does not claim to validate that capture.

The verifier reads TITLE.BIN from the authentic CUE/BIN in memory and checks the Japanese CONTINUE layout plus English NEW GAME and CONTINUE layouts. For each it requires the captured retail offsets, dimensions, positions, and visible-pixel counts, then checks the 4bpp CRAM lookup, priority 5, and 31/32 top-screen ratio over the captured VDP2 back screen. The English layouts each match 1,451 visible pixels. These remain sprite-level source and color joins; whole-screen composition and screenshot-to-dump frame identity remain unproven.

A repeated cold boot with the same schedule retained VDP1 frame 8,060. The frame-aligned VDP1 receipt again contains 178 commands with no dropped rows, and the screenshot has the same SHA-256 as the earlier Continue capture (741c620e945b5ab3e05f6bc5d182fc4ada9439071b79718f67326bcdd56c6118). The current screenshot verifier passes all five sprite roles and all 1,441 visible pixels for this repeat capture. A snapshot-only bitmap-source analysis found zero exact retail-source matches for NBG0’s 131,072-byte bitmap, despite its enabled 8bpp bitmap mode and 1,024 title-palette CRAM word matches. It reports source_join=unbound and semantic_admission=blocked.

The accompanying VDP2 memory-write trace is not complete at the displayed endpoint: its 250,000 retained rows stop at VDP1 frame 7,729 and it reports 1,309,722 dropped rows before frame 8,060. The SH-2 VDP2-write trace also reports 1,046,883 dropped rows. The SCU DMA trace reached its 1,024-row cap without an overflow receipt, so it cannot be treated as complete. These traces do not identify the NBG0 bitmap producer or authorize semantic/display admission. Raw capture files and reports are kept outside Git in the ymir_nexus_menu_vdp2_provenance_20261027 external evidence bundle; its SHA256SUMS.txt validates the retained files.

A follow-up authentic Japanese capture retained a complete SH-2 trace (796,230 rows, capacity 1,000,000, zero dropped) and a VDP2 trace window covering frames 7,550–7,716. An exploratory offline scan reported that the 15,264 width-one VDP2 writes below address 0x20000 at frame 7,716 appear as one ordered sequence in the SH-2 master trace, starting at row 780,966, with one call context (PC 0x06023128, caller return 0x06023176, target 0x06023108). This is a candidate sequence match, not a frame-scoped producer join: SH-2 rows have no frame tags and the retained SH-2 receipt contains no frame bounds. The final VDP2 VRAM snapshot is frame 8,047, after the VDP2 trace ends, so its byte agreement cannot establish which frame produced the SH-2 sequence. The committed analyzer therefore fails closed on this retained bundle instead of reproducing the exploratory attribution.

Read-only Ghidra decompilation of hash-verified Japanese DM.BIN (3bbca125e0bfb486897e4926541e7c31adbff010d01a9b0c736637f432aad124) shows FUN_06023108 as a byte-wise row copier that advances the destination by a runtime pitch; FUN_06023144 dispatches to it for the observed call path. This identifies a plausible retail copy routine but does not prove it generated the frame-7,716 writes, recover the source asset ownership, cover the full 131,072-byte bitmap, or establish renderer semantics. The independent bitmap comparison remains source_join=unbound and semantic_admission=blocked. The analyzer’s rejection is reproducible with scripts/analyze_nexus_vdp2_sh2_write_join.py; raw captures, the exploratory report, and Ghidra output are retained in /Volumes/Extern-disk/firestaff-evidence/ymir_nexus_nbg0_sh2_complete_20261027/. The frame-bounded capture below supplies the missing SH-2 bounds. It also checks for a later but byte-equivalent VDP2 VRAM snapshot by requiring a complete zero-drop VRAM write trace through the snapshot frame.

A frame-filtered repeat capture now records SH-2 writes only during VDP1 frame 7,716. The Ymir receipt reports exact frame bounds 7,716..7,716, 3,866 master rows, and zero dropped rows; the VDP2 trace and VRAM/register snapshot identify the same frame. The analyzer confirms one contiguous ordered match across all 3,866 writes, all 3,866 final byte values agree with the selected-frame VRAM snapshot, and there are zero mismatches. The call chain is 0x06023108|0x06023144|0x06040150. This removes timing ambiguity in the earlier unfiltered SH-2 trace. The raw capture is retained in /Volumes/Extern-disk/firestaff-evidence/ymir_nexus_frame_aligned_20261027/.

A repeat capture added four nested call targets to each SH-2 write row. Its frame-7716 match has the single chain 0x06023108|0x06023144|0x06040150, identifying FUN_06040150 as the active outer caller. Read-only Ghidra xrefs show FUN_06040150 is reached by a computed call in FUN_0601128e at 0x0601153a; the latter is a per-frame runtime loop. This establishes the caller path seen during the capture, but does not assign a title-menu semantic name or identify the copy source. The repeat screenshot is pixel-identical to the prior Continue capture, and the current verifier again matches all 1,441 TITLE.BIN sprite pixels. The extended trace and xref output are retained in /Volumes/Extern-disk/firestaff-evidence/ymir_nexus_callstack_20261027/.

A matched cold-boot menu capture keeps the SH-2 trace filtered to frame 7,716 while continuing to the complete native menu frame 8,047. The bounded VDP2 VRAM-write trace covers the frame window 7,000–8,049, retains 41,443 rows with zero drops, and records no VRAM writes after frame 7,716. The trace contains VRAM writes only, so it does not establish CRAM stability. The final VRAM, CRAM, and register snapshots are from frame 8,047; the complete VRAM write trace therefore establishes that the observed memory bytes remain unchanged through that snapshot. It does not independently bind the PNG to frame 8,047. The SH-2 frame receipt contains 15,264 master rows with exact bounds 7,716..7,716, zero drops, and one contiguous ordered match for all 15,264 byte writes. All 14,784 distinct written VRAM bytes agree with the later, unchanged snapshot. The matching call chain is 0x06023108|0x06023144|0x06040150. The VDP1 receipt identifies menu frame 8,047, with 178 commands and zero dropped rows; the authentic screenshot matches the five verified Japanese TITLE.BIN sprite roles at 1,441/1,441 nontransparent pixels. The screenshot verifier conservatively reports timing as unproven because its PNG does not carry an independent frame number. Raw files, verifier output, trace analysis, and hashes are retained in /Volumes/Extern-disk/firestaff-evidence/ymir_nexus_menu_sh2_bound_20261027/.

This is authentic input-correlated source evidence for the Japanese menu selection state. It does not establish complete TITLE.BIN decoding, mouse hit regions, Firestaff input handling, or full-menu renderer admission. The Japanese Continue foreground sprites have since been admitted and rendered as described above. The full external capture, hashes, and reproduction command are in the Japanese Down-selection capture receipt.

A fresh repeat cold boot on the frame-tracing Ymir fork captured the Continue screenshot and VDP1 receipt in one run. The retained image is pixel-identical to the earlier screenshot, and the complete VDP1 receipt identifies frame 8,047 with 178 commands and zero dropped rows. Its SH-2 trace is byte-for-byte identical to the frame-7716 trace in the paired VDP2 analysis. The screenshot was saved to an ephemeral /dev/shm path recorded in run.log, then retained under the external evidence bundle. Because that retained copy is no longer at the logged full path, verify_nexus_title_sprite_screenshot.py --run-log rejects it; verification without --run-log matches all five authentic Japanese sprites and reports timing=unproven. The log does not bind the screenshot save event to frame 8,047, so exact screenshot-frame identity is unproven. This repeat confirms the menu image and source-write sequence, but it does not replace the paired VDP2 trace or admit a Firestaff renderer. The capture and hashes are retained in /Volumes/Extern-disk/firestaff-evidence/ymir_nexus_menu_frame_windowed_sh2_20261027/.

Full Japanese title-menu capture replay (2026-10-27)

The retained frame-8047 Ymir run now reproduces the complete 320×224 display from its captured VDP1 framebuffer, VDP2 VRAM, CRAM and registers. The C replay matches every pixel in the same-run 640×448 screenshot (286,720 subpixels) after 2× scaling. Its VDP1 trace contains 178 frame-8047 commands and reports zero dropped rows. The VDP1 register receipt also names frame 8047. Five Japanese TITLE.BIN menu-sprite roles account for 1,441 visible texels; the remaining output is accounted for by captured VDP1 direct pixels, captured VDP1 palette pixels and NBG0 overlays. The pixel counts and input digests are recorded in NEXUS_MENU_BPK_VDP1_SNAPSHOT_JOIN.md.

Japanese Configuration selection rendering (2026-10-28)

A --debug Ymir replay loaded the authenticated Japanese retail title-menu state in an isolated TRV2 profile and captured the main menu with Configuration selected. The same-run VDP1 receipt records 168 traced commands and zero dropped rows. Its next command cursor is 168, so the following VDP1 display list begins at 168 * 32 = 0x1500. Five menu sprite records at 0x1560 through 0x15e0 join byte-for-byte to the Japanese retail TITLE.BIN:

The two marker palettes match the retail palette at TITLE.BIN offset 0x1726. Text CRAM palette bytes match the identical retail palette copies at 0x02f6, 0x0426, 0x0556, 0x0686, 0x07b6, 0x0986, and 0x1f06. The verifier scripts/verify_nexus_japanese_configuration_capture.py checks command bytes, source spans, palettes, sprite priority, blend ratio, placement, horizontal flip, and all 1,453 nontransparent pixels against the retained 640×448 image. An isolated C probe ran Firestaff’s production renderer against the authentic Japanese TITLE.BIN; all 1,453 emitted sprite pixels match the Ymir screenshot.

Firestaff renders the five Japanese Configuration-selected foreground sprites and accepts mouse clicks in the source-bound native row rectangle (109,177,104,8). The screenshot, complete VDP1/VDP2 dumps, logs, and hashes are retained under /Volumes/Extern-disk/firestaff-evidence/nexus/nexus_jp_config_selection_preaccept_20261028/. The English Configuration capture and production-renderer check are documented below. The shared title background, full-screen composition, menu destination execution, Continue/save loading, and gameplay viewport/HUD parity remain open.

English Configuration selection rendering (2026-10-28)

A Ymir 0.4.2-dev --debug replay used the authentic English retail Saturn disc, USA 1.01a IPL, and a copied diagnostic profile. The loaded Ymir state opens the native title menu with Continue selected. One Control Pad 1 Up pulse at capture frame 30 selects Configuration. This is a menu-state replay, not cold-boot evidence. The paired screenshot SHA-256 is 725fdfb6ef795606ffeebb34d734dccfc9e813aff9c23a4628149ce61dc76304.

The same-run trace ends at VDP1 frame 59 and contains 178 commands with zero dropped rows. Five commands join to the hash-verified English retail TITLE.BIN (SHA-256 a634e8daf2a581df154b454919ee2ed44e937371668219d7cdf6d0983a613e44):

The marker palettes match the retail palette at TITLE.BIN offset 0x1db6. The text palettes match the seven identical retail copies at 0x02f6, 0x0426, 0x0556, 0x0686, 0x07b6, 0x0986, and 0x1f06. The marker source, palette, position, horizontal flip, VDP2 priority and 31/32 color calculation are verified. The screenshot’s marker RGB also includes the underlying NBG0 image, whose full source and composition remain unbound.

scripts/verify_nexus_english_configuration_capture.py checks the complete VDP1 frame trace, exact source spans, CRAM palettes, registers and all 1,069 visible text pixels. A separate C probe compiled Firestaff’s production renderer against authentic English TITLE.BIN; its 320x224 framebuffer index map matches all 1,459 source-visible sprite texels from the Ymir commands with zero differing pixels. English Configuration row selection and foreground rendering are now enabled. The complete screenshot, dumps, log, reproduction command and hashes are retained under /Volumes/Extern-disk/firestaff-evidence/nexus/nexus_english_config_menu_20261028/.

These capture-backed renderer checks do not establish the NBG0 title background, full-screen composition, or gameplay viewport/HUD parity. The following section records the later M11 New Game loader receipt; reaching that receipt still does not pass the presentation gate. Continue/save loading also remains open.

Retail New Game input reaches the authenticated level loader (2026-10-28)

The authenticated retail menu reducer returns NEXUS_V1_RETAIL_TITLE_MENU_RESULT_START_NEW_GAME when Accept is pressed on New Game. M11 now sends that result to the retail start path for both keyboard/controller Accept and the retail mouse row. The path authenticates the supplied DM.BIN, parses its level-1 record, loads the selected hash-verified LEV01.DGN, validates the retail start cell, and asks the existing source-gated runtime handoff to prepare the viewport and HUD.

The older Firestaff startup-action path is not used as a substitute: its NEXUS_V1_STARTUP_ACTION_NEW_GAME execution opens Firestaff’s champion-select mode. The retail path retains the parser’s authenticated level-start receipt and does not open champion selection. If downstream DGN, viewport, or HUD receipts still block presentation, M11 restores the observed title menu and reports the source-backed blocker; a repeated New Game action can retry the handoff without reloading or inventing a start pose. The parser and launcher probes pass with authentic media. The M11 retail-menu regression also starts the launcher from the real extracted corpus, accepts New Game once through keyboard input and once through the mouse row, and verifies the committed level-1 receipt and (29,47,North) engine pose in both cases. Both paths pass locally with the authentic retail corpus. There is still no Ymir capture of the M11 handoff, and this test establishes the loader route rather than a playable viewport or complete gameplay parity.

Retail Up input changes the first viewport (2026-10-28)

Ymir 0.4.2-dev was replayed on TRV2 from the authenticated Japanese retail New Game menu state, with no retail save loaded. Two runs loaded the same state, accepted New Game for two frames, and advanced 1,800 capture frames to VDP1 frame 1,605. The control run had no further input. The paired run asserted Control Pad 1 Up for one frame at capture frame 1,500.

The control screenshot is byte-identical to the earlier A-only viewport capture (8ede95f1fd777eda69ebcfc91d0268194e501f145306eb1fc2971ed0113a2274). The Up screenshot differs (f1dd18e6aec0560c5144739d17adfdde4c5d67dc9796db0890b9ceac57dc8657). Both selected-frame VDP1 traces contain 151 ordered commands with zero drops; 106 command records have changed words after Up, mainly vertex coordinates. The VDP1 framebuffer differs at 136,598 bytes, and WRAM-HI differs at 956 bytes. This confirms that the retail game reacts to Up after New Game. It does not establish a stable room, exact party coordinates, HUD behavior, or a Firestaff gameplay route.

The DGN join matches 78 of 138 textured draws, with 55 face-owner matches; semantic admission remains blocked. The complete trace also contains pre-frame records after an earlier END command, so whole-file trace auditing rejects it; the selected frame’s extracted command chain passes. Full logs, screenshots, memory dumps, frame audits, and the reproduction command are retained at /Volumes/Extern-disk/firestaff-evidence/nexus/nexus_new_game_capture_20261028/.

Follow-up timing probes show that Up at capture frame 100 is too early: at frame 120 the screenshot is still in the transition and is pixel-identical to the control; only three WRAM-HI bytes differ. Up at frame 400 also leaves the frame-600 screenshot identical to control. Up at frame 1,000 produces the same final screenshot as the frame-1,500 Up run. These probes bound the observed response to after frame 400 and by frame 1,000, but do not identify the exact transition frame. The paired captures are retained in the paired-up-120/, paired-up-400-600/, and paired-up-1000-1800/ subdirectories. The frame-120 SH-2 trace dropped records and is not used.

A separate complete ten-frame high-WRAM SH-2 trace contains 174,354 writes with no drops, but its final screenshot still shows the title menu. Ghidra maps its frequent writers to buffer clearing, entity-grid/list setup, fixed- point transforms, and polygon emission. In the later 1,800-frame dumps, four active type-0x0f rows in the 20-entry entity pool have object tile coordinates (9,24), (7,26), (38,25), and (36,27); these remain unchanged between control and Up. No source evidence binds those rows to the controlled player or identifies a New Game writer for player position and facing. The captured transition therefore still does not provide a safe Firestaff start pose. The complete short trace and the timing-probe notes are retained in startup-sh2-trace-10frames/ and the paired subdirectories above.

New Game loads the retail per-level start record (2026-10-28)

A follow-up Ymir --debug replay traced SH-2 reads and writes in [0x06064000,0x06065000) for 1,800 frames. The accepted run loaded the same New Game-selected state, held A for two frames at capture frame 0, and held Up for one frame at frame 1,000. Its complete trace recorded 61,982 reads and 5,850 writes with zero dropped rows. A no-input replay of the same state and duration recorded 40,295 reads and 3,007 writes, also with zero drops.

Only the accepted run recorded the one-time parser writes to the structure at 0x06064544: words 1, 0x8000, 29, and 47 at offsets +0, +2, +4, and +6, followed by zeroed dwords at +0x0c and +0x10. Ghidra on the hash-verified DM.BIN maps those stores to FUN_0602022c; the function copies the fields from an input record. FUN_06020fee later reads offsets +4 and +6 and passes them, along with other fields, to an indirect initializer. Its caller chain reaches FUN_060110ac from FUN_06010f44. These trace and decompilation receipts bind the values to the accepted New Game execution and the generic level-loader path.

Follow-up static analysis found the source table at DM.BIN+0x39550 (0x06049550 at the analyzed load base). It contains 16 eight-byte entries. FUN_06011984 checks the selected entry’s word at +2, then copies its level, coordinates and angle into the loader structure; it is called from FUN_0601128e. The level-1 bytes are 00 01 00 01 1d 2f 80 00, yielding level 1, enabled flag 1, (29,47), and angle word 0x8000. This agrees with the accepted New Game trace through FUN_0602022c. The (29,47) LEV01 cell is passable in the hash-verified retail DGN, confirming a source-authored level-1 loader coordinate. A separate FUN_060110ac branch writes (32,39) for a zero argument; those stores did not appear in the accepted New Game trace and are not substituted for the selected table entry.

Enabled table entries use angle words 0x0000, 0x4000, 0x8000, and 0xc000, consistent with quarter-turns in a 16-bit angle field. FUN_0601f584 stores the value in an object field, but its analyzed caller chain does not bind 0x8000 to a world axis or Firestaff’s north/east/south/west enum. The native runtime therefore still blocks starting gameplay until that mapping is established. Raw Ymir traces and Ghidra exports are retained externally in nexus_new_game_capture_20261028/config-struct-sh2-trace-1800/ with the no-input control beside it.

Paired left/right input from the New Game scene (2026-10-28)

Two isolated Ymir --debug --fast-forward replays loaded the same retained New Game savestate and scheduled the same A press at frame 0. One pressed left for one frame at frame 1,500; the other pressed right for one frame at the same point. Both captured frame 1,800. The screenshots differ at 216,860 pixels, WRAM-HI at 3,011 bytes, VDP1 framebuffer at 209,996 bytes, and VDP1 VRAM at 3,808 bytes; WRAM-LO and VDP2 VRAM are byte-identical. The generic loader record at 0x06064544..0x0606456f is identical and retains level 1, angle 0x8000, and (29,47). The angle word at WRAM-HI offsets 0x746d0, 0x792be, and 0x9705e is 0x8000 in the no-turn baseline, 0x8064 after left, and 0x7f9c after right. The companion word at 0x746ca changes to +100 and -100. The frame-10 SH-2 trace records PC 0x06010cfa initializing 0x060792be to 0x8000 in FUN_06010cf4, with object base 0x060792b0. An Up/control pair changes the big-endian 32-bit field at object offset +8 (0x060792b8) from 0x003b6000 to 0x003b5c00 while the angle remains 0x8000; the +0 position field remains 0x0024e000. These are 16.16 coordinates: the retail table cell center (29,47) maps exactly to ((29+0.5)*1.25, (47+0.5)*1.25) = (0x0024e000, 0x003b6000). The Up input moves only Y by -0x400, with angle unchanged. In this captured level-1 start, Up therefore moves toward decreasing DGN Y, which is Firestaff North; the retail heading 0x8000 maps to North. The one-frame left/right angle changes (+100/-100) are consistent with that mapping. This binds the level-1 retail start heading, but does not establish mappings for every angle word or the complete gameplay ownership path.

The launcher now parses the selected eight-byte record from hash-verified DM.BIN and admits only this calibrated level-1 heading to a New Game start. It loads the hash-verified LEV01.DGN, checks (29,47) against the loaded cell geometry, and creates the dungeon-start receipt before producing the runtime handoff. Other raw headings remain unmapped and are rejected. The viewport, material, and HUD routes retain their independent evidence gates; this loader change does not establish complete playability. The firestaff target compiled successfully on TRV2. The real-data nexus_v1_launch_smoke_probe passed 22/22 checks, including this launcher start receipt. It does not exercise the interactive M11 route or provide a Ymir capture of that handoff.

A read-only pass through the existing DGN parser on authentic LEV01 shows an open chamber at (29,47) and a single square-type-8 passage at (29,48), bounded by walls at (28,48) and (30,48). The frame-1800 scene shows a narrow opening ahead, visually consistent with facing toward the single passage. A 164-frame left hold instead ends at angle 0x293d and a close wall view, not at the simple expected quarter-turn value; an immediate frame-1665 capture reproduces that result. The long-hold comparison remains confounded and is not used to establish the heading mapping; the paired one-frame input plus exact fixed-point start coordinates provide the level-1 direction evidence. Screenshots, complete memory dumps, reproduction details, and artifact hashes are retained in external evidence at nexus_start_heading_turn_20261028/.

This is a full captured-frame composition check, not a renderer admission. The replay consumes Ymir display and VDP snapshots, not a Firestaff runtime upload from retail assets. The screenshot has no embedded frame number, so exact acquisition-frame identity remains unproven. The Japanese SH-2 read receipt observes a full 31,616-address source pass at frame 6,893 but records no values and dropped 860,856 unrelated master rows; the NBG0 storage join remains partial. Full runtime menu composition, keyboard behavior beyond verified selection, Configuration page controls, save loading, and playable-level/HUD parity remain open. New Game, Continue, and Configuration foregrounds and mouse rows are source-bound for both authenticated regions as described above.

English Configuration page foreground (2026-10-28)

An isolated Ymir 0.4.2-dev --debug run used the authenticated English retail disc and USA 1.01a IPL. A copied diagnostic profile entered the native Configuration page, saved deterministic state slots, and replayed each input from the same menu state. The retail TITLE.BIN SHA-256 is a634e8daf2a581df154b454919ee2ed44e937371668219d7cdf6d0983a613e44. The reproduction captures and raw data are retained in /Volumes/Extern-disk/firestaff-evidence/nexus/nexus-english-configuration-page-evidence-20261028/.

The page defaults are Music ON, Sound STEREO, Game Level NORMAL, and Monster Gauge ON, with Music focused. Up/down changes the focused row; A/Right changes the selected value; A on Exit and B return to the title menu. The captured Ymir foreground has 189 VDP1 commands and zero dropped rows. Its text, values, and animated focus markers join to authentic TITLE.BIN; the production C renderer probe reproduces the complete 320x224 indexed foreground and all 256 palette entries for seven captured states. Run python3 scripts/verify_nexus_english_configuration_page.py <evidence-dir> <TITLE.BIN> to repeat the byte-level checks.

M11 initializes these reducer defaults when it initializes the game view. While Configuration is active, the renderer leaves the back-screen clear instead of reusing the five-plane title image. The authentic capture shows a different scene behind this page, and its DGN/VDP2 background composition is still unbound.

Firestaff’s English- and Japanese-region reducer and renderer draw that authentic page foreground, animate its source-bound focus marker, route keyboard and mouse selection, and return to the title menu on Exit/B. The Japanese configuration foreground uses the hash-verified Japanese retail TITLE.BIN; all 71 retained text, palette, and marker spans used by the page are byte-identical to their English-file counterparts. Its 14 visible text sprites match all 12,518 pixels in the authentic Japanese Ymir screenshot. Run `python3 scripts/verify_nexus_japanese_configuration_page.py