From 52744cbd03f9e0053b62c06c33de50f0d4ff6144 Mon Sep 17 00:00:00 2001 From: SDD Date: Fri, 16 Oct 2026 10:27:32 +0300 Subject: [PATCH] harness: correct video memory to bit 0x04000000; log the failing address; level 1 still fails --- debug.log | 25 +++++++++++++++++++------ harness/mame/BRINGUP_LOG.md | 37 ++++++++++++++++++++++++++++++++++--- harness/mame/cap.lua | 2 +- harness/mame/vt1200.cpp | 11 ++++++++++- 4 files changed, 64 insertions(+), 11 deletions(-) diff --git a/debug.log b/debug.log index 573c3f6..f9a6d0a 100644 --- a/debug.log +++ b/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 + diff --git a/harness/mame/BRINGUP_LOG.md b/harness/mame/BRINGUP_LOG.md index 1146b09..071445c 100644 --- a/harness/mame/BRINGUP_LOG.md +++ b/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. diff --git a/harness/mame/cap.lua b/harness/mame/cap.lua index 0cc6812..44d97db 100644 --- a/harness/mame/cap.lua +++ b/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 diff --git a/harness/mame/vt1200.cpp b/harness/mame/vt1200.cpp index 522aea8..beaed32 100644 --- a/harness/mame/vt1200.cpp +++ b/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).