diff --git a/harness/mame/BRINGUP_LOG.md b/harness/mame/BRINGUP_LOG.md
index 5490359..4f29fda 100644
--- a/harness/mame/BRINGUP_LOG.md
+++ b/harness/mame/BRINGUP_LOG.md
@@ -197,11 +197,17 @@ percentage counts uninitialised bitmap data because the active pixels are never
 
 ### RAM dump (frame 200, via the shared RAM pointer)
 
-`vt1200-ram-200.bin` is **262,144 bytes = 256 KiB** — and that size is itself a finding,
-because the map range `0..0x1fffff` with 8 address units per byte means **the driver
-only models 256 KiB of main RAM**. The real VT1200 has 1 MiB onboard plus up to
-3 × 1 MiB SIMMs (service guide), and POST runs a memory test. **Enlarging the RAM
-mapping is now a prime suspect and is a cheap experiment.**
+`vt1200-ram-200.bin` is **262,144 bytes = 256 KiB**.
+
+> **CORRECTION (2026-10-16).** The 256 KiB figure above is **stale** — it is from an
+> early dump, and the inference built on it ("the driver only models 256 KiB") is
+> **wrong**. The driver today maps `map(0x00000000, 0x01ffffff)`; on this space at
+> 8 address units per byte that is `0x2000000` units = **0x400000 bytes = 4 MiB**,
+> confirmed empirically (`machine.memory.shares[':mainram'].size == 4194304`). The
+> old range was `0x1fffff` (256 KiB) — one extra digit. So the mapping is already
+> 4 MiB and does **not** need enlarging. This stale line misled a reader once; keep
+> the correction with it. (The separate question of what the firmware *concludes*
+> about memory — the SIMM presence bits at `@0x5000000` — is unaffected.)
 
 Contents of what we do model: full of 32-bit **ROM pointers** (`0x3FD24A90`, `0x3FD2C800`,
 …) and resident strings (`$Header: init.c,v 1.3 …`, `DWT TCP/IP Rev 1.0`,