From 55cf122edd9b4ab369f75cdda5bf9f9aeaf55625 Mon Sep 17 00:00:00 2001 From: SDD Date: Fri, 16 Oct 2026 13:09:37 +0300 Subject: [PATCH] docs: correct the stale 256 KiB RAM claim in BRINGUP_LOG The '256 KiB / driver only models 256 KiB of main RAM' note was from an early dump and is wrong. The driver maps 0x00000000-0x01ffffff, which on this bit-addressed space is 0x2000000 units = 0x400000 bytes = 4 MiB, confirmed empirically (mainram share size == 4194304). Keep the correction with the original so the stale figure cannot mislead again. --- harness/mame/BRINGUP_LOG.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) 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`,