opencode.energia.arti.ee/vt1200
1
0 Fork 0
forked from arti/vt1200
Code Pull Requests Activity

docs: record the instrument disagreement precisely; block video work on a closed cross-check

Browse Source
This commit is contained in:
SDD committed 2026-10-16 10:11:59 +03:00
1 parent b2e0448001
commit 93fb92d807
1 file changed
+34 -1
Download Patch File Download Diff File Expand all files Collapse all files
harness/mame/BRINGUP_LOG.md
+34 -1
View File
@@ -689,8 +689,41 @@ Concrete calibration plan (uses only driver-side logging, which works):
3. That single run fixes the units and the precedence, and every address in this document
can then be normalised.
### 2. Four address conventions, still not reconciled — and two instruments that DISAGREE
**Proven this session:** map precedence is **last-wins**. A logging proxy over
`0x00000000-0x0000FFFF` registered *after* the RAM entry fires (4458 hits, then 22734 over a
longer run), while proxies registered over other ranges do not. So drivers can layer
handlers over real regions — that part is settled and useful.
**The contradiction that blocks everything else:**
| instrument | range | result |
|---|---|---|
| catch-all (registered FIRST, shadowed by RAM under last-wins) | logged `0x400000`-`0x40D7FF` | claims those are **UNMAPPED** |
| layered proxy, registered LAST | `0x00400000`-`0x00400FFF` | **zero hits** |
| layered proxy, registered LAST | `0x00000000`-`0x0000FFFF` | **fires** |
| layered proxy, registered LAST | `0x00200000`-`0x01FFFFFF` | **zero hits** |
The catch-all says `0x400000` is unmapped; but the RAM map covers `0x00000000-0x01FFFFFF`,
and under last-wins RAM must win there — so the catch-all should never have seen it. And a
proxy over exactly `0x00400000` sees nothing.
**Therefore the catch-all's logged addresses are not address-map addresses**, and the
"video memory at 0x00400000" conclusion is **unreliable**. It may still be right, but it has
not been established by a trustworthy instrument.
The blitter's target read straight from the POST code is `0x3600400` (a bit address), which
matches none of the candidate encodings either.
**Until this is closed, no video-memory work can be trusted.** The next step is one *closed*
cross-check: run the catch-all and a layered proxy over the **same** range in the **same**
run, and see which one reports. Whichever is trustworthy calibrates the rest; the other gets
fixed or discarded.
---
## Next steps
FIX THE INSTRUMENTATION FIRST (see above), then model video memory.
CLOSE THE INSTRUMENT DISAGREEMENT FIRST (one cross-check run).
Then model video memory and re-run the level-1 check via the console capture.