# Does the VT1200 firmware issue XIE requests?  A MAME trace

Short answer: **no.** Over three configurations — level-0 diagnostics, the booted
OS with the Terminal Manager, and a forced jump into the Scalution test — the
server's XIE dispatcher `XieProc` is **never entered**. The built-in image tests
are hardware diagnostics that program the image-option/scaler registers directly.

There is therefore **no ROM-side XIE client sequence to replay**, and the
`PUT_TILE` band question cannot be settled this way.

Everything below is measured, with a control that proves the measurement works.

---

## 1. How the test was triggered, and why the entry point is not the problem

### 1.1 The Scalution test entry

`"error initializing scalution"` lives at file `0x371F2`; its only xref is the
instruction at file `0x36CB6`. Scanning backwards from there for the
`MMTM SP,0x…` prologue (`8F 09`) finds the test's entry at **file `0x35EA8`**
= bit `0x3F1AF540`:

```
rom:00035ea8 MMTM SP,0x154
rom:00035eac MOVE A14,A13
rom:00035eae ADDI 0x6e0,A14
rom:00035eb2 SUB A11,A11
rom:00035eb4 MOVE A11,*A13(0x520),0x1
...
rom:00035ecc CALLA 0x07f67f38          ; 0x127F38  test-framework entry
rom:00035ed2 MOVE A8,@0xa5f00,0x1
rom:00035ee0 MOVK 0x1,A11 / MOVB A11,*A13     ; mode 1
rom:00035ee6 MOVK 0x3,A11 / MOVB A11,*A13     ; mode 3
rom:00035eec MOVK 0x5,A11 / MOVB A11,*A13     ; mode 5
```

It is reached from a descriptor table (`refs to 0x35EA8` = file `0x1AFE8` and
`0x1BA46`), i.e. the "5 - Scalution Test" menu entry, whose label string is
`0x2B5D2` and whose menu table is built by the routine at `0x2A9A8`
(`MOVI 0x3f35ae90` = that label, stored at base + `0xa00000` bits).

**What it does:** the body writes the image-option/scaler hardware directly —

```
rom:00036b02 MOVB A9,0xca2b0            ; scaler control registers
rom:00036b0c MOVB A7,0xca2c0            ;   (0xca270 … 0xca3a0)
rom:00036b7c MOVB A11,0xca330
rom:00036c02 MOVE A11,@0x5600100,0x0    ; image-option registers
rom:00036c0c MOVE A7,@0x5600020,0x0
rom:00036c16 MOVE A7,@0x5600030,0x0
```

No call to the server, no request buffer, no `XieProc`.

### 1.2 Triggering it in MAME

The menu path needs the LK401 keyboard model and a menu map that is not
documented; the diagnostic menu's own key handling was not reversed. Instead the
test was entered by PC assignment from the menu idle loop, the same mechanism
`hello.lua` uses:

```lua
dbg:command("bpset 3FDCE400,,{ pc = 3F1AF540 ; g }")   -- idle -> scaled test entry
```

(Gotcha: the firmware reaches the idle PC `3FDCE400` **from frame 1**, not at
frame 300 — `progress.lua` samples exactly that PC for all 199 frames of the
baseline. So an "enter the test at frame N" breakpoint actually fires at frame 1
unless it is gated on a frame counter.)

---

## 2. The tracer

Script: **`harness/mame/xie_trace.lua`** (new file, this task).
Breakpoint inside `XieProc`, one instruction *after* it loads the request buffer,
so `A9` is the buffer:

```
rom:00064b98 MMTM SP,0x54          <- XieProc entry      bit 3F525CC0
rom:00064ba2 MOVE *A11(0x40),A9,0x1  ; A9 = client->requestBuffer
rom:00064ba6 SETF 0x8,0x0,0x0
rom:00064ba8 MOVE *A9(0x8),A11,0x0   ; <- breakpoint here, bit 3F525D40
```

Action (generated by the script):

```
{ printf "XIEHIT buf=%08X %04X %04X %04X %04X %04X %04X %04X %04X\n",
         a9, w@(a9+0), w@(a9+16), w@(a9+32), w@(a9+48),
             w@(a9+64), w@(a9+80), w@(a9+96), w@(a9+112) ; g }
```

`w@` is used rather than `b@` because the TMS34010 program space is 16-bit wide
and bit-addressed; `+16` bits = the next word.

**Critical harness detail:** debugger `printf` output goes to the *debug
console*, which is discarded unless MAME is started with **`-debuglog`**. Without
it the runs look like "zero hits" whether or not the breakpoint fires. All runs
below use `-debuglog`.

---

## 3. The control run (proof the measurement works)

Same script, breakpoint moved to the menu idle PC, which executes continuously:

```
XIE_TRACE=0x3FDCE400 XIE_FRAMES=60 XIE_WORDS=0 \
  $M vt1200 -rompath /home/arti/code/k-space/vt1200/harness/mame/roms \
     -video none -sound none -nothrottle -debug -debugger none -debuglog \
     -autoboot_script /home/arti/code/k-space/vt1200/harness/mame/xie_trace.lua \
     -autoboot_delay 0
```

Result: **4 634 965 hits** in `debug.log` (`XIEHIT pc=3FDCE400`). The breakpoint,
the action, the memory accessors and the log path all work.

---

## 4. The three trace runs

| run | configuration | frames | `XieProc` hits |
|---|---|---|---|
| A | plain boot → level-0 diagnostics menu | 1200 | **0** |
| B | `VT1200_SKIP_LEVEL1=1` → OS + Terminal Manager | 4500 | **0** |
| C | forced jump into the Scalution test at `0x35EA8` | 900 | **0** |

Logs: `xie/ghidra-evidence/mame/run_a_level0_diagnostics.txt`,
`run_b_os_terminal_manager.txt`, `run_c_scalution_jump.txt`,
`run_d_control.txt`.

Run A's PC stays at `3FDCE400` (menu) throughout; run B ends at
`3F579870` (OS code); run C leaves the menu and runs code at `3F208xxx`
(file `0x109xx`) — so the PC assignment did divert execution. Caveat: a
breakpoint placed on `0x35EA8` itself did **not** fire in run C, so the exact
instruction the jump landed on, and how far the test body executed before
diverting, is not proven. It does not affect the conclusion — the XIE breakpoint
covered the whole run either way.

**No request bytes were captured because no request was ever dispatched.** The
XIE breakpoint would have printed `buf=… 0081 0002 …` (reqType `0x81` = major
opcode 129) if the server had been asked to do anything.

Corroborating static evidence: the ROM contains exactly three strings containing
`Xie` — `"Xie"`, `"XieExtensionInit: AddExtension failed"`,
`"XieExtensionInit: Device Init failed"` — all server-side registration text.
There is no client-side XIE API (no `XieInitialize`/`XieCreatePhotomap`-style
names), which is what a firmware-resident XIE client would have left behind.

---

## 5. What this means for the import problem

The plan "trace the firmware's own XIE client to see the working `PUT_TILE`
sequence" **cannot work**: the firmware has no XIE client, and its image tests
drive the scaler registers instead of the protocol.

That leaves the static picture as the only route to the band/import question:

* `PUT_TILE` (minor 19) requires, from `0x6B966`: resource byte 40 == 0,
  resource byte 36 != 0, and the band bit `1 << band` set in resource byte 8 or
  byte 12 (`GHIDRA_XIE_IMPORT.md` §1).
* Nothing in the create path (`slot 8` → `0x678DA` → `0x6CA82`) writes byte 36,
  so some *other* request must. Slot 43 rebuilds a resource record from another
  resource's bands (`GHIDRA_XIE_IMPORT.md` §3) and remains the best candidate.

### Next probes (unchanged, and now the only path)

1. `PUT_TILE` with **band = 0** (request word 6 = 0) instead of 1.
   `BadMatch (8)` ⇒ byte 36 is set and only the mask is wrong; `BadAccess (10)`
   ⇒ byte 36 is zero and a band must be created first.
2. If (1) fails: `minor 43, len 10, [id, 0…]` on the class-2 resource, then repeat
   (1).
3. If (1) and (2) fail: `minor 7, len 4, [op=1, type=2, id]` (note the field
   order: byte 8 is the *type*, byte 12 the *id*), or slot 20 (35 words).

---

## 6. Confirmed / Inferred / Unknown

**Confirmed**
1. The firmware never enters `XieProc` during POST/diagnostics, during the booted
   OS/Terminal Manager, or when the Scalution test is entered (0 hits in 6600
   frames, with a 4.6-M-hit control proving the tracer works).
2. The Scalution test (`0x35EA8`, bit `0x3F1AF540`) writes image-option/scaler
   registers `0xCA2xx`/`0x56000xx`; it contains no server call.
3. The ROM has no client-side XIE strings; the only `Xie` strings are the
   server's registration messages.
4. Debugger `printf` output requires `-debuglog`; without it, breakpoint actions
   are invisible (this silently invalidated a first round of runs here).

**Inferred**
1. The built-in image tests are board-level diagnostics, not protocol clients.
2. If any code did call XIE it would still arrive at `XieProc` (dix dispatch);
   a private internal bypass is not fully excluded, but nothing suggests one.

**Unknown**
1. Whether slot 43 or slot 20 is the band-materialising request (unchanged).
2. The image-option menu's key map (not needed for the conclusion).

---

## 7. Reproduce

```sh
M=/home/arti/code/k-space/mame0289/vt1200
R=/home/arti/code/k-space/vt1200

# A: level-0 diagnostics
XIE_FRAMES=1200 $M vt1200 -rompath $R/harness/mame/roms \
   -video none -sound none -nothrottle -debug -debugger none -debuglog \
   -autoboot_script $R/harness/mame/xie_trace.lua -autoboot_delay 0
# -> debug.log: no XIEHIT lines

# B: booted OS
VT1200_SKIP_LEVEL1=1 XIE_FRAMES=4500 $M vt1200 <same args>
# -> no XIEHIT lines

# C: forced Scalution test
XIE_JIT=3F1AF540 XIE_FRAMES=900 $M vt1200 <same args>
# -> no XIEHIT lines

# control: breakpoint on the menu idle PC (fires every frame)
XIE_TRACE=0x3FDCE400 XIE_WORDS=0 XIE_FRAMES=60 $M vt1200 <same args>
# -> hundreds of thousands of "XIEHIT pc=3FDCE400" lines in debug.log
```

`xie_trace.lua` env: `XIE_FRAMES`, `XIE_WORDS` (0 = print PC only),
`XIE_TRACE` (breakpoint address override), `XIE_JIT` / `XIE_AT` (optional
debugger entry).