dwt: xtext draws text in a real X window on the VT1200; TFTP retarget fetches the COFF

dwt/notes/REAL_UNIT.md

@@ -322,3 +322,69 @@ no revision or bank difference. The dump is reproducible with:
 ```sh
 python3 dwt/rom_dump.py --host 100.103.100.103
 ```
+
+### X11 text app on the real unit (`xtext`)
+
+`dwt/gui/xtext.asm` is `xhello` plus the text path: `XOpenDisplay("0::0")`,
+`XCreateSimpleWindow` (400x200 at 100,100, black client area), `XLoadFont`,
+`XCreateGC`, `XSetForeground(1)`, `XMapWindow`, then four iterations of
+`XSync` + `XDrawString("HELLO VT1200")` + `XDrawString("text works")` and a
+final `XSync`. Linked at bit `0x01840000`; loaded with
+`dwt/loader/hostload.py --real` and with `--tftp` (below).
+
+Two real-unit loads (pcb `0x00846410`, `0x00843950`) and two TFTP runs
+(pcb `0x008458d0`, `0x0083f5d0`) all returned loader `A8=0`, `entry
+0x01840000`, and left `stage=9`, `strlen=4`, `draw1=0x0c`, `draw2=0x0a`
+(the two `XDrawString` return values are the string lengths). Text is visible
+in `dwt/evidence/real-unit-xtext.png`, `real-unit-xtext-2.png`,
+`real-unit-xtext-tftp.png`, and `real-unit-xtext-tftp2.png`; the same app
+renders in MAME (`dwt/loader/evidence/real-unit-xtext/emulator-xtext-run{1,2}.png`).
+**Several windows are visible in the later screenshots because the owner moved
+windows around**; the app window is identified by its content
+(`HELLO VT1200` / `text works`) and its `stage=9` markers, not by counting
+windows.
+
+What worked, exactly:
+
+* **Font:** `"fixed"` returns **0** from `XLoadFont` on this server (the
+  string exists in ROM as the default-font name, but is not an openable
+  resource). The ROM's built-in DEC font works:
+  `-DEC-Terminal-Medium-R-Normal--14-140-75-75-C-8-ISO8859-1`
+  (`font` marker `0x00850e90`). `XLoadFont` is called for evidence; the GC
+  does not need the id.
+* **GC:** `XCreateGC(d,win,0,NULL)` works. Passing `mask=GCFont (0x4000)`
+  with an `XGCValues` block (font at byte +60) **hung the connection**: the
+  app reached `stage=7` (mapped) but the first `XSync` never returned and
+  `draw1` stayed 0. With mask 0 the server fills the GC from the screen's
+  default GC, whose font is usable, and the draws return 12/10.
+* **Window timing:** one early draw can be lost when the WM reparents the
+  window. The working shape draws repeatedly, with an `XSync` before each
+  pair; four iterations were enough (48 also ran, but the first was still
+  inside `XSync` at the inspection frame).
+* **Saved SP/A14 in RAM is a trap.** The first version saved entry SP/A14 at
+  `0x01894500/20` and reloaded them after every call. The OS heap overwrote
+  those cells (a string `Exiting\n` landed on them), the next call restored
+  SP from garbage and the app died at `XCreateGC`. The callee's `rets 2`
+  already restores SP and A14, so the working version does not restore them
+  from RAM at all. Diagnostic markers were moved into zero padding at the end
+  of the app's own `.text` (`0x01842000`); the earlier cells at `0x01895000`
+  were also overwritten by the heap.
+* **ROM unchanged:** `md5 b46a3e442ccb86134d2356bd70d22fd2`.
+
+Self-contained TFTP delivery of the text app: `dwt/tcpip/tftpr.asm` is
+`tftpc.asm` retargeted to server `100.103.255.254:69` and RRQ `xtext.coff`
+(20-byte request: `xtext.coff\0octet\0`). Served with
+`dwt/tcpip/serve_probe.py 100.103.255.254 --file dwt/loader/build/xtext.coff`
+and loaded with `hostload.py --tftp --real`. Two runs, both verified
+byte-for-byte (`sha256 4f713d33be8a36dfa14be8a3e4a0451bcabc1a12b1b40ddca385697104a63b26`):
+
+```
+17:26:19  RRQ 100.103.100.103:1071 requested 'xtext.coff' (1494 bytes)
+17:26:55  RRQ 100.103.100.103:1081 requested 'xtext.coff' (1494 bytes)
+```
+
+The build name must be <= 8 characters: `tftpc_real` silently fails (no
+`TFTPC_REAL.OUT`); `tftpr` is safe.
+
+Evidence: `dwt/loader/evidence/real-unit-xtext/` (loads, markers, server logs,
+screenshots, emulator runs, `xtext_probe.lua`).