diff --git a/harness/mame/BRINGUP_LOG.md b/harness/mame/BRINGUP_LOG.md
index cedf170..e96e7dd 100644
--- a/harness/mame/BRINGUP_LOG.md
+++ b/harness/mame/BRINGUP_LOG.md
@@ -857,11 +857,53 @@ remaining candidates:
 **Honest status: level 1 is NOT passing.** Video memory is located, correctly mapped and now
 proven to round-trip a walking-bit pattern; the test's remaining requirement is not yet met.
 
+## Error strings come from a STATUS-CODE DISPATCHER, not from addresses (2026-10-16)
+
+Following the level-1 error path in Ghidra corrects a wrong turn I had taken.
+
+The block immediately before the error handlers is a switch on a status code:
+
+```
+07fbe0c6: MOVE *A13(0xffe0),A8,0x1   ; A8 = status code set by the test
+07fbe0ca: JREQ 0x07fbdfd0            ; code 0  -> (no error)
+07fbe0cc: DEC A8 / JREQ 0x07fbce12   ; codes 1..8 -> ROM CHECKSUM handler
+07fbe0fc: SUBI -0xff88,A8 / JREQ 0x07fbcf40
+07fbe104: SUBI -0xff80,A8 / JREQ 0x07fbcfe0   ; <- VIDEO MEMORY handler
+07fbe10c: SUBI -0xff00,A8 / JREQ 0x07fbd02a
+...
+```
+
+So each error string is selected by a **code**, and the values printed alongside (e.g.
+`0x40000C`, `0x4000C0`) are **constants in the message**, not addresses.
+
+**Correction.** My earlier claim that "the video RAM test fails at bit `0x040000C0`" rested on
+reading `a11` at the printer breakpoint. `a11` is a stale local, and `0x40000C` turned out to
+be a printed constant that also appears in the ROM-checksum path. **That inference was
+unsound and is withdrawn.** The video RAM test's failing address is not known.
+
+**Useful landmarks now mapped (Ghidra addresses):**
+
+| what | address |
+|---|---|
+| the level-1 test routine | `0x07FBCB02`-`0x07FBE21B` |
+| status-code dispatcher | `0x07FBE0C6` |
+| VIDEO MEMORY error handler | `0x07FBCFE0` (reached only for its one code) |
+| ROM CHECKSUM error handler | `0x07FBCE12` |
+| hex-format + draw helper | `0x07FBBF96`-`0x07FBC015` |
+
+**Method note, worth keeping.** A register snapshot at a call is not evidence of an argument.
+Read the **call site in the ROM** — which is what Ghidra just made easy, and what I should
+have done before chasing an address for several rounds. Ghidra and `smart34010` agree
+instruction-for-instruction on every range checked, so the two disassemblers cross-validate.
+
+**Next:** find where the test **sets** `*A13(0xffe0)` to the video-memory code — that
+assignment is the actual failing comparison, and it is the thing to fix.
+
 ---
 
 ## Next steps
 
-1. Map video memory across the FULL extent the bank walk reaches (bit 0x200000C0 and
-   beyond) -- the last bank is currently unmapped.
-2. Pin the unit of the reported address (0x0040000C): bank base vs failing offset.
-3. Re-run the console check (cap.lua) after each change; it reports the failing address.
+1. Find where the test SETS *A13(0xffe0) to the video-memory code -- that assignment
+   is the failing comparison.
+2. Everything else is in place: console capture (cap.lua), video memory located and
+   mapped, Ghidra project seeded and saved (25 functions).