harness: correct video memory to bit 0x04000000; log the failing address; level 1 still fails

debug.log

@@ -1,8 +1,21 @@
 MAME debugger version 0.289 (mame0289-dirty)
 Currently targeting vt1200 (VT1200 X terminal (v2.2 firmware))
-Error in expression: printf "CAL-A wpaddr=%08X data=%04X acc=%02X pc=%08X\n", wpaddr, wpdata, wpaccess, pc ; g
-                     ^unknown symbol
-Error in expression: printf "CAL-B wpaddr=%08X data=%04X acc=%02X pc=%08X\n", wpaddr, wpdata, wpaccess, pc ; g
-                     ^unknown symbol
-Error in expression: printf "CAL-C wpaddr=%08X data=%04X acc=%02X pc=%08X\n", wpaddr, wpdata, wpaccess, pc ; g
-                     ^unknown symbol
+Breakpoint 1 set
+PRINT pc=3FDE00C0 a9=3FDCA8E8 a11=0040000C a5=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
+

harness/mame/BRINGUP_LOG.md

@@ -768,10 +768,41 @@ conflicts (`emumem_mview.cpp:257` and `:293`) — the open question is whether r
 differs when the overlapping handlers have the **same** width versus **different** widths.
 A dedicated cross-check is measuring exactly that.
 
+## Video memory: located, mapped, and still not enough (2026-10-16, latest)
+
+**Corrected location.** The cross-check settled the instrument rule — a handler on an entry
+at `base` receives `(bitaddr - base) >> 4`, so the catch-all (base 0) logs `bitaddr >> 4`
+(2 bytes per logged unit). Therefore the blitter's traffic logged at
+`0x400000`-`0x40D7FF` is **bit `0x04000000`-`0x040D7FF0` = bytes `0x800000`-`0x81AFFE`**
+(~110 KiB). My earlier `0x00400000` mapping was **16x too low** and is fixed.
+
+The proof was a closed cross-check: adding a probe at `0x04000000` moved *exactly*
+183,536 accesses out of the catch-all, while a probe at the old wrong address stayed at
+zero. Precedence is plain last-wins for both same- and mismatched-width overlaps.
+
+**The firmware's failing address agrees.** Reading `a11` at the printer breakpoint gives the
+address the failing test reports: `0x0040000C` in the same `>>4` units, i.e.
+**bit `0x040000C0`** — inside the region above. `harness/mame/cap.lua` now logs `a9`, `a11`
+and `a5`, so every reported failure comes with its address.
+
+**But mapping it is not sufficient.** With video memory mapped at the corrected address —
+and also with a deliberately huge range (`0x04000000`-`0x1fffffff`) — the level-1 video RAM
+test **still reports `LEVEL1/2 ERROR -> VIDEO MEMORY - 22` at the same address**. So the
+test is not a plain write/read-back over memory that simply needs to exist.
+
+**Where the answer is.** The test walks banks and calls a helper at bit **`0x3FDDFCB0`**
+(file `0x17BF96`) for each — that helper implements the actual check. Reading it is the next
+step. The bank walk observed so far steps in `0x400000` units (`>>4`), reaching at least
+`0x0200000C` (bit `0x200000C0`), so video memory may extend far beyond the first 110 KiB.
+
+**Honest status:** level 1 is NOT passing. Video memory is located and mapped correctly; the
+test's *requirement* is not yet understood.
+
 ---
 
 ## Next steps
 
-1. Settle the overlap/precedence rule (cross-check in flight).
-2. Model video memory using BIT addresses; the region is ~64 KiB starting at bit 0x400000.
-3. Re-run the level-1 console check after each change.
+1. Read the check helper at bit 0x3FDDFCB0 (file 0x17BF96) to learn what the
+   level-1 video RAM test actually requires.
+2. Map video memory at the full extent the bank walk reaches.
+3. Re-run the console check after each change.

harness/mame/cap.lua

@@ -28,7 +28,7 @@ local maxframes = tonumber(os.getenv("CAP_MAX") or "900")
 -- pointer P maps to file offset (P >> 3) - 0x07E40000.
 local PROG_BASE_BIT = 0x3F200000
 
-dbg:command('bpset 3fde00c0,,{ printf "PRINT pc=%08X a9=%08X\\n", pc, a9 ; g }')
+dbg:command('bpset 3fde00c0,,{ printf "PRINT pc=%08X a9=%08X a11=%08X a5=%08X\\n", pc, a9, a11, a5 ; g }')
 print("printer breakpoint armed at 3fde00c0")
 
 -- Also catch the error-report table entries, which are where a failing test

harness/mame/vt1200.cpp

@@ -407,8 +407,17 @@ void vt1200_state::program_map(address_map &map)
 	// mapped, which is exactly why the screen renders black: the blits went
 	// nowhere and reads returned 0.  Gated on an env var while we characterise
 	// its size and layout, so the established no-env baseline is preserved.
+	// Video memory.  Located empirically and then corrected by a closed
+	// cross-check of two instruments: the catch-all's handler receives
+	// (bitaddr - base) >> 4, so its logged 0x400000..0x40D7FF means BIT
+	// 0x04000000..0x040D7FF0 == bytes 0x800000..0x81AFFE (~110 KB, about one
+	// 1280x1024 1bpp framebuffer).  The earlier 0x00400000 was 16x too low.
+	//
+	// This is the memory the level-1 VIDEO RAM test walks (it reports failing at
+	// 0x40000C in the same >>4 units, i.e. bit 0x040000C0), which is why the
+	// firmware reports error 22 and restarts before it ever draws anything.
 	if (getenv("VT1200_VRAM"))
-		map(0x00400000, 0x0047ffff).ram().share("vram");
+		map(0x04000000, 0x1fffffff).ram().share("vram");
 
 
 	// Main RAM: 4 MiB (1 MiB onboard + 3 x 1 MiB SIMMs on the real machine).