From 3a1d10e9bbb768283ae49308cec7ec71872a847f Mon Sep 17 00:00:00 2001 From: SDD Date: Fri, 16 Oct 2026 10:40:24 +0300 Subject: [PATCH] docs: consolidate level-1 investigation state; stack walk reaches the framework not the test --- debug.log | 18 ++------------- harness/mame/BRINGUP_LOG.md | 39 +++++++++++++++++++++++++++++++++ harness/mame/dispatch_walk.lua | 40 ++++++++++++++++++++++++++++++++++ 3 files changed, 81 insertions(+), 16 deletions(-) create mode 100644 harness/mame/dispatch_walk.lua diff --git a/debug.log b/debug.log index f9a6d0a..c86443d 100644 --- a/debug.log +++ b/debug.log @@ -1,21 +1,7 @@ MAME debugger version 0.289 (mame0289-dirty) Currently targeting vt1200 (VT1200 X terminal (v2.2 firmware)) Breakpoint 1 set -PRINT pc=3FDE00C0 a9=3FDCA8E8 a11=0040000C a5=00000000 +DISPATCH sp=00005280 w=00001580 00000000 00000001 3FDF8A20 000016B0 00001560 00000000 00000000 -PRINT pc=3FDE00C0 a9=3FDC98F8 a11=0040000C a5=00000000 - -PRINT pc=3FDE00C0 a9=004001C8 a11=00000000 a5=00000000 - -PRINT pc=3FDE00C0 a9=00C0000C a11=00000000 a5=00000000 - -PRINT pc=3FDE00C0 a9=0100000C a11=00000000 a5=00000000 - -PRINT pc=3FDE00C0 a9=0140000C a11=00000000 a5=00000000 - -PRINT pc=3FDE00C0 a9=0180000C a11=00000000 a5=00000000 - -PRINT pc=3FDE00C0 a9=01C0000C a11=00000000 a5=00000000 - -PRINT pc=3FDE00C0 a9=00000000 a11=0200000C a5=00000000 +DISPATCH sp=00005280 w=00001580 00000100 00000000 3FDF90E0 000016B0 00001560 00000000 00000000 diff --git a/harness/mame/BRINGUP_LOG.md b/harness/mame/BRINGUP_LOG.md index 7a7384c..788861b 100644 --- a/harness/mame/BRINGUP_LOG.md +++ b/harness/mame/BRINGUP_LOG.md @@ -934,3 +934,42 @@ caller is what still needs finding. 1. Find the CALLER of FUN_rom_07fbd000 and the status code it passes -- that is the failing test. Use smart34010 for call targets (Ghidra's CALLA does not resolve). 2. Optionally fix Ghidra's CALLA operand handling to get a usable call graph. + +## Where the level-1 investigation stands (2026-10-16, end of this stretch) + +**Not solved: level 1 still fails, no picture.** + +Solid and committed (these do not need redoing): + +* **Address units** — from MAME's source: the TMS34010 program space is + `memory_access<32,1,3>`, so map units are **bits** and bytes = bit >> 3; a handler on an + entry at `base` receives `(bitaddr - base) >> 4`. Precedence is plain last-wins. +* **Instruments** — the catch-all is trustworthy (closed cross-check: moving a probe to the + right address shifted exactly 183,536 accesses out of it). `VT1200_BOARD_LOG`, + `VT1200_LOG_UNMAPPED`, `VT1200_CAL`, `VT1200_VRAMLOG` all work. **Watchpoints do not work + headless**; `bpset` does. +* **Video memory** — located at bit `0x04000000` (~110 KiB first bank), mapped, and proven to + round-trip a walking-bit pattern. It is **not** the missing piece: the test still fails + with it mapped and round-tripping. +* **The level-1 video RAM test** — characterised: a walking-bit data-bus test (8,208 writes, + 8,208 read-backs, 4,096 offsets). +* **Console capture** — `cap.lua`, breaking at the printer `3FDE00C0` and logging `a9`/`a11`, + gives the firmware's own self-test narration. +* **Ghidra** — project seeded and saved (25 functions) and it cross-validates `smart34010` + instruction-for-instruction. Caveat: **Ghidra's `CALLA` targets do not resolve**, so its + call graph is empty — use `smart34010` for call targets. + +Withdrawn after being shown wrong: "the test fails at bit 0x040000C0" (the value came from a +stale register; the error strings are selected by a **status code**, and the numbers printed +with them are message constants, not addresses). + +**The open question, stated cleanly:** which level-1 test raises status code 22 (video +memory), and what condition makes it raise it. The error dispatcher is +`FUN_rom_07fbd000` (Ghidra `0x07FBD000`-`0x07FBE201`), it takes the code as an argument, and +the stack at the dispatcher shows the **error-reporting framework**, not the test that +produced the code — so the test must be found another way. + +**Suggested next approach** (not yet tried): intercept where the status code is *stored* +rather than where it is consumed — the framework keeps the code in a global, so watch the +global for transitions to 22 and take the PC there. That would land inside the failing test +directly. diff --git a/harness/mame/dispatch_walk.lua b/harness/mame/dispatch_walk.lua new file mode 100644 index 0000000..722075d --- /dev/null +++ b/harness/mame/dispatch_walk.lua @@ -0,0 +1,40 @@ +-- Dump the call chain when the level-1 error dispatcher runs. +-- +-- The dispatcher reads the failing status code from its ARGUMENT (*A13(0xffe0)), +-- so the routine is a function and its caller is the failing test. Breaking at +-- the dispatcher and walking the stack gives us that caller's return address -- +-- a ROM bit address we can convert to a file offset and disassemble. +-- +-- Dispatcher: Ghidra 0x07FBE0C6 -> file 0x17E0C6 -> bit 0x3F200000 + 0x17E0C6*8 +-- +-- DW_FRAMES=600 vt1200 ... -autoboot_script harness/mame/dispatch_walk.lua + +local machine = manager.machine +local cpu = machine.devices[':maincpu'] +local dbg = machine.debugger + +if not dbg then + print("ERROR: debugger not enabled; pass -debug") + machine:exit() + return +end + +local DSP = os.getenv("DW_PC") or "3fdf0630" +-- Print SP and a window of stack words once, then keep going. ROM bit +-- addresses (0x3F2xxxxx-0x3FFFFFFF) among them are return addresses. +dbg:command(string.format( + 'bpset %s,,{ printf "DISPATCH sp=%%08X w0=%%08X w1=%%08X w2=%%08X w3=%%08X w4=%%08X w5=%%08X w6=%%08X w7=%%08X\\n", sp, d@sp, d@(sp+20h), d@(sp+40h), d@(sp+60h), d@(sp+80h), d@(sp+0a0h), d@(sp+0c0h), d@(sp+0e0h) ; g }', DSP)) +print("breakpoint armed at dispatcher " .. DSP) + +local maxframes = tonumber(os.getenv("DW_FRAMES") or "600") +local n = 0 +emu.register_frame_done(function() + n = n + 1 + if n >= maxframes then + print("done (" .. n .. " frames)") + machine:exit() + end +end, "vt1200-dispatch") + +dbg.visible_cpu = cpu +dbg.execution_state = 'run'