From 8a00cef5566da30b51cfc4a6fdb859d8f1788d7c Mon Sep 17 00:00:00 2001
From: SDD <sdd@local>
Date: Fri, 16 Oct 2026 10:38:16 +0300
Subject: [PATCH] docs: Ghidra CALLA targets do not resolve (empty call graph);
 smart34010 is authoritative for call targets

---
 ghidra/vt1200.lock          |  9 +++++++++
 ghidra/vt1200.lock~         |  0
 harness/mame/BRINGUP_LOG.md | 35 +++++++++++++++++++++++++++++++----
 3 files changed, 40 insertions(+), 4 deletions(-)
 create mode 100644 ghidra/vt1200.lock
 create mode 100644 ghidra/vt1200.lock~

diff --git a/ghidra/vt1200.lock b/ghidra/vt1200.lock
new file mode 100644
index 0000000..1f810e4
--- /dev/null
+++ b/ghidra/vt1200.lock
@@ -0,0 +1,9 @@
+#Ghidra Lock File
+#Fri Oct 16 10:37:43 EEST 2026
+<META>\ Supports\ File\ Channel\ Locking=Channel Lock
+Hostname=sid
+OS\ Architecture=amd64
+OS\ Name=Linux
+OS\ Version=7.2.4-arch1-2
+Timestamp=10/16/26, 10\:37\u202FAM
+Username=arti
diff --git a/ghidra/vt1200.lock~ b/ghidra/vt1200.lock~
new file mode 100644
index 0000000..e69de29
diff --git a/harness/mame/BRINGUP_LOG.md b/harness/mame/BRINGUP_LOG.md
index e96e7dd..7a7384c 100644
--- a/harness/mame/BRINGUP_LOG.md
+++ b/harness/mame/BRINGUP_LOG.md
@@ -899,11 +899,38 @@ instruction-for-instruction on every range checked, so the two disassemblers cro
 **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.
 
+## Ghidra vs smart34010: which tool to trust for what (2026-10-16)
+
+Both tools disassemble this ROM, and they **agree instruction-for-instruction on every range
+checked**. But they differ in one way that matters, found while following the level-1 test:
+
+| tool | the same `CALLA` instruction |
+|---|---|
+| `tools/smart34010/dis34` | `calla 0x3fde00c0` — full bit address, matches the ROM layout |
+| Ghidra (MCP) | `CALLA 0x000bc018` — does not resolve to any function |
+
+Ghidra's **absolute operands are correct** (`MOVI 0x3fdca990` is a genuine bit address), so
+it is reliable for mnemonic structure, `MOVI` constants, xrefs on data, and decompilation.
+Its **`CALLA` targets do not resolve**, so:
+* Ghidra's **call graph is empty** for this ROM — `function_callers`/`function_callees`
+  return nothing for functions that clearly call others (`FUN_rom_07fbd000` reports 0 and 0);
+* use **`smart34010` for call targets**, and Ghidra for structure and decompilation.
+
+Do not build conclusions on Ghidra's call graph here until that is fixed; the earlier
+"0 callers" results are artefacts of this, not evidence of unreachable code.
+
+### Structural result from this pass
+
+The level-1 error dispatcher is owned by `FUN_rom_07fbd000` (body `0x07FBD000`-`0x07FBE201`),
+and it takes the failing **status code as its argument** (`*A13(0xffe0)` — there is exactly
+one `0xffe0` reference in the routine, the read in the dispatcher, so the code is not set
+locally). The failing code is therefore chosen by **whatever calls this routine** — and that
+caller is what still needs finding.
+
 ---
 
 ## Next steps
 
-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).
+1. Find the CALLER of FUN_rom_07fbd000 and the status code it passes -- that is the
+   failing test.  Use smart34010 for call targets (Ghidra's CALLA does not resolve).
+2. Optionally fix Ghidra's CALLA operand handling to get a usable call graph.