docs: consolidate level-1 investigation state; stack walk reaches the framework not the test

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
 

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.

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 <mame> 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'