From bc7faba43df51faefcef63335620607ca640d4a9 Mon Sep 17 00:00:00 2001 From: Matthew Stanley <1379tech@gmail.com> Date: Mon, 22 Jun 2026 20:34:26 -0700 Subject: [PATCH] =?UTF-8?q?docs:=20loader=20hunt=20result=20=E2=80=94=20sp?= =?UTF-8?q?lash-advance=20code=20is=20a=20LATE=20CD=20DMA=20load=20the=20r?= =?UTF-8?q?ecomp=20never=20gets?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit wtrace 0x80107000-0x80108000 on a fresh oracle: only BIOS zeroing (0xBFC0D864) hits via CPU stores; the real 0x80107268 code is ZERO at oracle frame 2289 but present by 3960 with ZERO CPU stores carrying it => installed by CD DMA (ch3 CD->RAM), LATE (mid-splash ~frame 2289-3960), not at initial boot. So CD is NOT fully ruled out: the early 0x41800 load works but this later 0x80107xxx overlay DMA is the one the recomp never receives (region zero even at frame 78k). Refined model: the state-0 splash loop initiates/waits on a 2nd CD load that brings the advance task; on HW the DMA completes and drives state 2<->1; recomp's never lands so state stuck 0. Next: fix cd_read_log cross-tooling (Rule15), restart recomp w/ from-boot CD logging to see if it issues the 0x107xxx read at all, and trace the state-0 loop's CD cmd+DeliverEvent right before the load on both. cd_read_log cross-compare currently blocked (beetle lacks it; recomp dump empty once). Co-Authored-By: Claude Opus 4.8 --- docs/TOMBA2_SPLASH_ATTRACT_PLAN.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/docs/TOMBA2_SPLASH_ATTRACT_PLAN.md b/docs/TOMBA2_SPLASH_ATTRACT_PLAN.md index bf2940b1..5d402548 100644 --- a/docs/TOMBA2_SPLASH_ATTRACT_PLAN.md +++ b/docs/TOMBA2_SPLASH_ATTRACT_PLAN.md @@ -133,3 +133,28 @@ The cd_read_log ring (256 entries) has already evicted the early loads, so captu it to a different address (relocation/base divergence). - Also dump the full early CD read log from boot (restart with cd logging) to see if a CD read to 0x107xxx happens on the oracle but not the recomp. + +## LOADER HUNT RESULT (2026-06-22 sess2) — it's a CD DMA load, late, that the recomp never gets +Armed `wtrace 0x80107000..0x80108000` on a fresh oracle from frame 411. Findings: +- The ONLY CPU-store writes caught to the region were the BIOS RAM-zeroing pass (PC `0xBFC0D864`, + ra `0xBFC06BBC`, writing 0x00000000 to `0xA0107C00+` at frame ~848). NOT the code install. +- The real code at `0x80107268` is **still ZERO at oracle frame 2289**, but **present by frame 3960** + — and the wtrace caught **ZERO CPU stores** carrying those code bytes. ⇒ the splash-advance code + is installed by **CD DMA (channel 3, CD→RAM)**, not CPU stores. It loads LATE (≈frame 2289–3960), + i.e. DURING the splash, not at initial boot. +- So **the CD is NOT fully ruled out** after all: the EARLY load (`0x41800+`, 250 sectors) works, but + this LATER DMA load of the `0x80107xxx` overlay is the one the recomp never receives (its region + stays zero even at frame 78k). cd_read_log cross-compare blocked by tooling (beetle has no + `cd_read_log`; recomp dump came back empty once — Rule 15 follow-up). + +### Refined model + next step +Likely chicken-and-egg / CD-completion: the splash state-0 loop (both run) initiates or waits on a CD +load that brings in the `0x80107xxx` advance task; on HW the DMA completes (~frame 3960) and the task +then drives state 2↔1; on the recomp the load never lands so state stays 0. This points back at the +**CD/DMA + completion-event path for a SECOND (mid-splash) load**, distinct from the working first load. +NEXT: (1) fix/confirm cd_read_log on the recomp + add it to beetle (Rule 15) so we can diff CD reads; +(2) restart the RECOMP with full from-boot CD logging and check whether it ever issues a read whose +DMA dest covers `0x107xxx` — if NO, a code-path/branch divergence skips the load (the state-0 loop +never reaches the load trigger); if YES-but-data-absent, a CD/DMA targeting or completion bug drops it. +(3) On the oracle, trace what the state-0 loop does right before the load fires (the CD command + +DeliverEvent/CdSync) and compare the recomp's same loop.