vt1200/xie/README.md

XIE sources: xieperf, XIElib and the sample server extension

STATUS (updated): a client-chosen XIE image IS displayed on the VT1200. The working path is XieCreateImage -> XieCreatePhoto -> XiePutTile -> XieExport(photomap -> depth-1 Pixmap) -> XCopyArea(pixmap -> window), run with VT1200_ACCEL=1 and the compression poke in harness/mame/xie_fix.lua. Two faults were removed: the accelerator's output-FIFO read pointer was never reset between transfers, and dwt/screenshot.py needs --real (1280 wide, 256-byte stride) for the VR319 default. See evidence/XIE_IMAGE_DISPLAYED.md and evidence/png/xie_window_tiles.png. Everything below this banner that says "NO client-chosen XIE image displayed" is historical and is superseded; the corrections are listed in that report.

Vendored copy of the XIE (X Image Extension) sources from X11R6.1 (X Consortium, March 1996). The point of interest is xieperf, the XIE test/benchmark client, which is the natural first client to point at the VT1200's DECwindows server because that server advertises a Xie extension:

$ xdpyinfo -display 192.168.99.2:0
...
number of extensions:    2
    ServerManagementExtension
    Xie
...
vendor string:    DECWINDOWS DigitalEquipmentCorp.
version number:    11.0
...
depth of root window:    1 plane

What is here

path	contents
xc/programs/xieperf/	xieperf client: 35 .c files, xieperf.h, Imakefile, xieperf.man, and the images/ test images (image.001–image.014)
xc/lib/XIE/	XIElib, the client library xieperf links against
xc/include/extensions/XIE*.h	XIE.h, XIEproto.h, XIEprotost.h — wire protocol and client API headers
xc/programs/Xserver/XIE/	the X11R6 sample server-side XIE implementation (reference only; not needed to build xieperf)
xc/doc/hardcopy/XIE/	XIE protocol spec, XIElib spec and sample-implementation architecture, as plain text

280 files, about 8.3 MB. PostScript copies of the documents were dropped; the .txt renderings are kept.

Provenance

Downloaded 2026-11-01 from the official X.Org release archive:

• https://www.x.org/releases/X11R6.1/tars/xc-1.tar.gz — xc/programs/xieperf, xc/lib/XIE, xc/include/extensions/XIE*.h, xc/programs/Xserver/XIE
• https://www.x.org/releases/X11R6.1/tars/xc-3.tar.gz — xc/doc/hardcopy/XIE (documents)

Checksums of the original tarballs:

d138b68392d4ca49939fd0da46180763a23e82838fb30cb964ed2c5bc6d6c8d6  xc-1.tar.gz
cec75d6ae72d437783c72c2892d637a8a2acfd0f2088358ed024064a1a687976  xc-2.tar.gz
a980821b36607773eba8735ad5608e03c503fe139656f4e3beb64c1b5049fab9  xc-3.tar.gz

xc-2.tar.gz holds the same specs as nroff sources under xc/doc/specs/XIE/; it was not needed for this copy.

Other places the same tree is available:

• Browsable single files (Debian's vnc4 source package bundles an XFree86 4.3-era xc): https://sources.debian.org/src/vnc4/4.1.1%2BX4.3.0-37.6/unix/xc/programs/xieperf/ and https://sources.debian.org/src/vnc4/4.1.1%2BX4.3.0-37.6/unix/xc/lib/XIE/
• XFree86 3.3.6 mirror: https://github.com/ljmccarthy/XFree86-3.3.6
• X11R6 (1994) and later releases: https://www.x.org/releases/X11R6/, https://www.x.org/releases/X11R6.1/, https://www.x.org/releases/X11R6.4/

XIE was removed from the reference X11 distribution in X11R6.7 (2004), so there is no current distro package for xieperf.

Licence

X Consortium / MIT-style terms for the X11 code, plus the AGE Logic notice on the XIE sources. Both are reproduced at the top of every source file and in xieperf.man; the AGE Logic terms permit use, modification and sale provided the notice is preserved.

Using it against the VT1200 — status

It builds and connects, and it does identify the server, but it cannot yet run the test suite: the VT1200 implements XIE protocol 2.3, while xieperf speaks 5.0. Verified against 192.168.99.2:0:

xieperf - XIE performance program, version 1.0

XIE V2.3
FULL server
Screen visual class is StaticGray
Colormap has 2 entries
Effective depth is 1-bit
...
Class name: ColorAlloc
X Error of failed request:  BadLength
  Major opcode of failed request:  129 (Xie)
  Minor opcode of failed request:  0 ()

The request that kills it is the client's 5.0 QueryTechniques (minor 2). In 2.3 that slot is not QueryTechniques: the ROM dispatch table says slot 2 accepts exactly one word and returns success without a reply, while the 5.0 request is two words and gets BadLength. So xieperf hangs at one word and dies at two.

The ROM analysis (GHIDRA_XIE.md) found 46 request slots, 25 implemented. Only slot 1 can be matched to its 5.0 counterpart; the numbering is otherwise not 5.0's. No slot implements QueryTechniques or any technique-capability reply, so -showtechs cannot work against this server.

Raw X11 probes (no XIElib) plus the ROM table give this map:

minor	5.0 request the client thinks it is	what 2.3 slot N actually does
1	QueryImageExtension	same request (2 words); replies 2.3, class 0x20, 8 levels
2	QueryTechniques	1 word, success with no reply; not a query
6	QueryColorList	1 word (bare header) → reply, length 0 (no argument)
11	QueryPhotomap	3 words (5.0: 2); id at byte 4 → BadIDChoice if null
23	GetClientData	not implemented → BadRequest
24	QueryPhotoflo	4 words (5.0: 3); id at byte 4 → BadIDChoice if null

BadLength always arrives with minor_op = 0 because the handlers return 16 to the dispatcher and the generic error path has no minor to report; errors XIE sends itself do carry the real minor (minor 23 reports BadRequest with minor_op 23). So the 0 in the error is a server-side artefact, not evidence about which request failed.

The full evidence is in evidence/ (xie_wire_probe.txt, xieperf_showtechs_vt1200.txt, xieprobe_vt1200.txt) and ghidra-evidence/ (dispatch_table.txt, listings.txt, length_sweep_wire.txt).

So: the extension is real and answers XIE requests; xieperf 5.0 is the wrong client for it. A minimal 2.3 session client now exists:

./xiectl23.py        # against 192.168.99.2:0

extension present=1 opcode=129 first_event=64 first_error=0
init   (1,2w): REPLY len=8  010102000800000002000300...
qdefs  (3,2w): REPLY len=0  0141030000...
qevents(6,1w): REPLY len=0  010004000000000002000000 01000000 01000000 01000000
term   (2,1w): TIMEOUT                 # Success, no reply

Order matters: QUERY_EVENTS returns 2,1,1,1 only after INIT_SESSION; sent alone it returns zeroes. In the INIT reply only major 2 / minor 3 are stable across connections; the tail words vary, so do not parse them as a fixed capability record.

That is the session half. Live probing has since established the resource rules: the per-connection id base/mask, the reserved bit in new ids, slot 8 op 2 as a working create, and the exact reason slot 21 refuses to export (BadMatch from resource flag +0x28). The exportable object lives in the photoflo/pipeline layer, not in slot 8. See evidence/xie_create_export_probe.txt, GHIDRA_XIE_IMAGE_PATH.md and GHIDRA_XIE_PIPELINE.md (when present).

Is there an XIE client inside the ROM?

No. The ROM contains the XIE server only. A MAME trace with a breakpoint on XieProc (0x3F525CC0) saw zero hits in three runs:

run	configuration	XieProc hits
plain boot → level-0 diagnostics	1200 frames	0
VT1200_SKIP_LEVEL1=1 → OS/Terminal Manager	4500 frames	0
forced jump into the Scalution test (0x35EA8)	900 frames	0
control: same tracer on the menu idle PC	60 frames	4,634,965

The control run matters: MAME discards debugger printf output unless it is started with -debuglog, which is why the first zeroes were not yet trustworthy. With -debuglog the control fires, so the zeroes are real.

The “5 - Scalution Test” is a hardware diagnostic: its body writes the image-option/scaler registers (0xCA2B0, 0xCA330, 0xCA3A0, 0x5600020, 0x5600030, 0x5600100) directly. It never calls the server or builds an XIE request. The ROM’s only Xie strings are the server registration messages.

So there is no working 2.3 client sequence to replay. The client in this directory is ours, and the PUT_TILE band gate still has to be settled from the server model plus live probes. Report: MAME_XIE_TRACE.md; reusable tracer: harness/mame/xie_trace.lua.

Clients and tools in this directory

file	what it is	status
xiectl23.py	minimal XIE 2.3 session client: INIT_SESSION → QUERY_OP_DEFAULTS → QUERY_EVENTS → TERM_SESSION	verified against the VT1200
probe23.py	live raw-X11 probe with a persistent connection: session, defaults, raw slots, create/sweep	used for all wire evidence
xshow.c / xshow	1-bit image viewer using core X11 PutImage; reads the window back and compares on-pixel counts	verified on the VT1200 (MATCH), not XIE

xshow is the display half and an honest fallback, not a pure XIE image client. The XIE path itself is now much further than the session: the create request with a non-zero level word at byte 28 (2 = 1 bpp) produces an exportable resource, and slot 21 exports it into a real X window + GC with no error.

Slot 20 arms the resource's bands. The request that succeeds is 35 words with id@4, byte8 = 64, byte12 = 2, byte14 = 1, byte16 = 1, byte13 = 1 (mode). After that, PUT_TILE no longer returns BadAccess; it reaches the class check:

• class-2 resource (create op 2) → BadMatch: PUT_TILE passes class 3.
• class-3 resource (create op 1) → BadIDChoice.

So the target is a class-3 resource with byte 40 == 0. WITHDRAWN — the byte-40 rule was a misreading. Measured instead:

• create op 1 and create op 2 call the same routine (file 0x678DA); the only op-dependent value it passes is (op == 2) ? 1 : 0, and op is also the level loop count (DSJ at 0x67A24).
• create op 1 → object class 3 but id@0 == 0: the ID is stored nowhere in the object, so the table lookup can never find it → BadIDChoice.
• create op 2 → object class 2 with id@0 set → addressable.
• Only payload word 1 is accepted as the ID (any other position → create BadIDChoice).
• Byte 40 is a copy-out field: the helper (file 0x66FA0) copies *obj(0x140) out when the caller passes a non-NULL out-param, and only the NULL-out-param variant tests it — raising 0xE, not 0x8. So patching byte 40 could never have fixed PUT_TILE, which is what was measured.

So the real missing piece is the request that both selects class 3 and stores an ID. Evidence: evidence/class3_id_not_stored.txt.

The create opcode space is exhausted

Every accepted create opcode has now been tested at its own required length:

op=1  12 words  create OK   allocates   query BadIDChoice  put BadIDChoice
op=2  12 words  create OK   allocates   query REPLY        put BadMatch
op=3            BadIDChoice
op=4   6 words  "OK"        allocates NOTHING, ID never addressable
op=5   7 words  "OK"        allocates NOTHING, ID never addressable
op=6  >=6 words "OK"        existing resource left intact and queryable

op 4 and op 5 are not creates — both begin by looking up an existing resource (op 4 looks up payload word 2 through 0x7EA6FA0; op 6 looks up payload word 1 through 0x7F174A4). Only op 2 yields an addressable resource, and its class is 2. So no create opcode produces a class-3 resource registered by ID. Evidence: evidence/create_opcode_sweep.txt.

Slot 11 is not the class-3 bind

slot 11 needs exactly 3 words (2 ids) and performs two typed lookups (call #1 pushes the literal 0xffff, call #2 pushes 0). With two valid, queryable class-2 resources:

A=0040C000 class=2 b40=0     B=0040D000 class=2 b40=0
slot11 [A,B] -> BadIDChoice (14)
slot11 [B,A] -> BadIDChoice (14)
after: both unchanged, both still queryable, put -> BadAccess (10)

The operand types are fixed inside the handler, so slot 11 cannot be steered to a class-3 bind from the request. Evidence: evidence/slot11_bind_and_second_allocator.txt.

The element is created by EXPORT, not filled by PUT_TILE

element = *( *(res+44) + 0xd8 ) is 0 after create, after arm1, and after PUT_TILE; it only becomes non-zero inside EXPORT (0x1B234: EX_BAND a5=003DC4B0 elem@d8=003FDA10). No write to element+0x28 was ever observed. So PUT_TILE does not populate the element — EXPORT builds it — and the source image pointer it copies stays 0. Evidence: evidence/element_pointer_timing.txt.

Export resolves the resource; only src_base is empty

Values written by the export copy block (0x1B296), named against the firmware's own dump strings:

rp+0x5a8 = 0x0040C000   src_res_id   -> our resource, correctly resolved
rp+0x5d0 = 64           src_width
rp+0x5f0 = 64           src_height
rp+0x610 = 0            src_base     <-- the pixel buffer: MISSING
rp+0x738/0x758 = 64/64  dst_img PWIDTH/PHEIGHT

So EXPORT is not failing to find the resource — it has the id and the 64×64 size. The single empty field is src_base, loaded at 0x1B238 (MOVE *A5(0x28),*A11(0x610)), which no write watchpoint ever saw written. The missing datum is a pixel buffer for the source image, produced only by the import. Evidence: evidence/export_renderparams_map.txt.

slot 47 is a byte-swapped dispatch trampoline — and is unreachable

file 0x697B4 swaps the bytes of request words at bit offsets 0x10/0x18, 0x20/0x28, 0x30/0x38, then re-dispatches through the same table at 0xD3F90 (SLL 5 ; ADDI 0xd3f90 ; MOVE *A11,A11 ; CALL A11).

Tested and closed: with breakpoints on the trampoline body (0x3F54BFF0 table read, 0x3F54C000 CALL — count 36→38, no command errors), minor 47 returned BadRequest for plain and byte-swapped argument words, and the trampoline never executed (0 TRAMP hits). So there is no client-reachable byte-swapped request family. It is also self-referential: the swaps cover offsets 2–7 only, never the minor byte at offset 1, so a client request for minor 47 could only re-enter it.

The default handler 0x64C3C (shared by every unimplemented slot and by slot 0) is the BadRequest responder — which is why probing unimplemented slots returned ERR1. Evidence: evidence/trampoline_unreachable.txt.

src_base sweep across every remaining slot — none writes it

Each remaining implemented slot was exercised at its own required length with [resource_id, 0, 0…], in a full create→arm1→<slot>→PUT_TILE→arm2→EXPORT sequence, reading rp+0x610 from the export breakpoint and diffing the window against its pre-export content:

slot 18,40,44,33,14,15,9,13,24 :  src_base = 00000000   window changed = False

Every export still resolves the source id and the 64×64 geometry (5a8=<id> 5d0=40 5f0=40), and 610=0 in every case. Coverage is now complete: every implemented slot (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 18 19 20 21 22 24 33 40 43 44, plus the BadRequest default and the unreachable trampoline) has been exercised against a created resource.

This is not a proof of impossibility: only one argument shape per slot was tried. Evidence: evidence/src_base_sweep_all_slots.txt.

Multi-operand shapes fail at the same typed-lookup wall

The bind-family handlers (33 40 44 18) and 43 were then given two and three live ids. Two findings:

• The third operand is an id, not a flag: slot33 [A,B,t] for t=1..9 returns BadIDChoice with bad = t (and t=0 → BadValue).
• With three valid ids the lookup still fails, because it is typed:

slot33 [A,B,A] / [A,B,B] / [A,B,C] / [A,A,A] -> BadIDChoice, bad = 3rd id
slot40 [A,B,A] / [A,B,B]                     -> BadValue,    bad = A
slot44 [A,B,A,0] / [A,B,B,0]                 -> BadValue,    bad = A
slot18 [A,B,0]                               -> BadMatch
slot43 [A,B,0...]                            -> BadValue

Every multi-operand request fails at a typed lookup of one of its own operands: the operand exists and is queryable, but lacks the class the handler requires. That is the same wall as PUT_TILE, reached from four more directions. src_base stayed 0 and no window changed. Evidence: evidence/multi_operand_shapes.txt.

The single wall, restated precisely

Every client-reachable path — single- and multi-operand, all implemented slots — fails for one reason: the server's resource model requires a resource class that its create path will not issue with a stored id (create op 1 builds a class-3 object but leaves id@0 = 0). Until that class can be created addressably, no request reaches an import that would set src_base.

Why that class cannot be created addressably — CORRECTED

Superseded. The "mutually exclusive" argument below is wrong: op=1 does reach the registering body. Measured with breakpoints on 0x67B04/0x67B34, create op=1 registers id 0040C000 → object 0036A950, which is a class-1 photoflo (id@0 set, w=3259088 h=1, query → BadAccess). create op=2 registers a class-2 resource (003FD7D0, w=64 h=64, query → REPLY). The class-3 object seen earlier (class 3, id@0 = 0) is an intermediate that is never the registered object. So the accurate statement is: the id is registered to a class-1 photoflo or a class-2 resource; no create opcode registers a class-3 object. Evidence: evidence/registration_hits_corrected.txt.

Registration audit: only class 1 and class 2 ever get an id

A full audit with breakpoints on 0x67B04 (ID store) and 0x67B34 (register):

arm1 / put / arm2 / slot43 / export / arm1(photoflo) / put(photoflo) -> 0 hits
create op=2  id=0040C000 -> REGIDSTORE obj=003FDA10  (class 2, query REPLY)
create op=1  id=0040D000 -> REGIDSTORE obj=00385890  (class 1, query BadAccess)

Registration happens only inside create, and only those two object kinds ever receive an id. The class-3 object built by the allocator (file 0x6CA82) never appears in a REGIDSTORE.

Walking the photoflo's +0x160 chain the way export does (0x1B230 MOVE *A5(0x160),A5):

lvl0 00385890 id@0=0040D000 class=1   p44=00386010   <- resource-like
lvl1 00386010 id@0=003859D0 class=80  p44=00386290   <- first word is a pointer
lvl2 00386290 id@0=00386150 class=144 p44=003C7150
lvl3 003C7150 id@0=003863D0 class=144 p44=00000000   chain ends

Only lvl0 has a resource layout; from lvl1 the first word is a pointer and the "class" byte is 0x50/0x90, so those are internal blocks, not resource structs, and carry no client id. So there is no client-visible id whose registered object is class 3 — the two ids a client can obtain are registered to class 2 and class 1. Evidence: evidence/photoflo_chain_no_id.txt.

The armF state gets furthest: BadAccess instead of BadMatch

Tracing the one configuration never followed before (I = image, F = photoflo):

create I 0x40C000 -> REGIDSTORE id=0040C000 obj=003FDC50 ; REGISTER
create F 0x40D000 -> REGIDSTORE id=0040D000 obj=00388090 ; REGISTER

arm F then PUT_TILE I  ->  S19LOOK a8=0000000A   (BadAccess,  10)
arm I then PUT_TILE I  ->  S19LOOK a8=00000008   (BadMatch,    8)
PUT_TILE F (unarmed)   ->  S19LOOK a8=0000000E   (BadIDChoice, 14)

Arming the photoflo genuinely moves the typed lookup past the stage that yields BadMatch and stops it at a BadAccess check — a real state difference and the furthest any configuration has reached. No configuration reached the handoff (0x6B640) or wrote src_base; the registration sites get 0 hits outside create.

Caveat, recorded because it invalidates a column I have been quoting: the LOOK breakpoint at 0x6BA38 prints cls=01 for both the armF and armI cases, and earlier printed an incrementing 01,02,03 across calls. So A7 there is the export element, not the resource struct — its cls/b40 columns are not resource fields. Only S19LOOK's return code (a8 at 0x6A7B4) is trustworthy. Evidence: evidence/armF_lookup_codes.txt.

Three more assumptions tested and falsified

Chasing the BadAccess, three structural guesses were each disproved within one step — recorded so nobody repeats them (evidence/three_wrong_assumptions.txt):

1. 0x7F638C2 is not the allocator — file 0x1238C2 is a printf-style logger (format descriptors 0x3fb1cea0 etc.). The real allocation is 0x7EACA82 → file 0x6CA82.
2. 0x7F174A4 is not the XIE resource lookup — file 0xD74A4 indexes a table at 0x21FFE0 by N = (id & 0xFFF00000) >> 12, bounds-checked against a count of 16 at 0x225870. That is the core-X client index; for our ids N = 1024, out of range, bucket reads 0.
3. @0x1AD980/@0x1AD990/@0x1AD9A0 are not XIE list heads — they read 0x02000002, 0x04000200, 0x00000400, and following them as pointers reads zeros.

The direct observations stand (S19LOOK a8 = 0x08 / 0x0A / 0x0E at 0x6A7B4), but every explanation built on those three functions is now void.

The slot-19 lookup is file 0x6B966 — and it does not produce the 0x8

rom:0006a7ae CALLA 0x07eab966 → file 0x6B966 (not the 0x66FA0 helper). Its flow:

6B990 CALLA 0x07F174A4          ; returns an object pointer
6B99A JRNE 0x6BA8C             ; null -> MOVK 0xe (BadIDChoice)
6BA8C A8 = object->byte4       ; class byte
6BA90..6BA9C  class 1 -> 0x6B9C4 ; class 2 or 3 -> 0x6BA1E ; else 0xe
6BA1E arg3==NULL ? require object->byte40 == 0 (else 0xe) : copy byte40 out
6B9C4 (class 1) requires arg3 != NULL, then a two-step byte8->byte8 /
      byte12->byte8 deref

It raises only 0xE and 0xA — there is no 0x8 route before 0x6BBC0.

Measurements that contradict a simple story, recorded as-is:

• sweeping request payload word 5 (the arg6 the code branches on) over 0,1,2,0x100,0x10000,0x80000000,0xFFFFFFFF,0xFFFFFFFE gives BadMatch every time — arg6 has no observable effect;
• the 0xE-build site (0x6BA86) did fire during a put whose reply was ERR8;
• the 0xA site (0x6BAC6) and an in-function MOVK 0x8 site (0x6BB4C) did not fire during that put;
• the shared reply helper 0x7EFFA5E did not fire at all.

So the ERR8 the client receives is not produced by any site we can see, and site-based attribution is unreliable. Evidence: evidence/lookup_is_6B966.txt.

Bounded next step: disassemble the remainder of 0x6B966 (0x6BBC0..0x6BBE4) and the 0x6BAEA path, logging A8 at every return, to find the 0x8's true origin. Until that is known, BadMatch cannot be interpreted.

Both properties the import needs are decided in the same routine (file 0x678DA):

679A2 SUBK 0x2,A11 ; MOVK 0x1,A11
679A6 JREQ 0x679AA          ; op==2 -> flag 1
679A8 SUB A11,A11           ; else  -> flag 0
...
6CAF6 JREQ 0x6CAFC
6CAF8 MOVK 0x2,A11          ; flag!=0 -> class 2
6CAFC MOVK 0x3,A11          ; flag==0 -> class 3      <-- 6CAFE stores it
...
67A20 MOVE *A9(0x20),A11    ; A11 = op
67A24 DSJ A11,0x67AFC       ; op-1 != 0 -> jump to the REGISTERING body
67A28 ...                   ; op-1 == 0 -> photoflo path
67B04 MOVE *A9(0x40),*A11(0x0)   ; ID -> obj+0
67B34 CALLA 0x07F16CA2           ; register in the resource table

• op = 1 → flag 0 → class 3, but DSJ falls through to the photoflo path (0x7F63A30, 20 words, error string "error allocating photoflo"), so the ID is never stored and never registered.
• op = 2 → flag 1 → class 2, and DSJ jumps so the ID is stored and the resource registered.

PUT_TILE requires class 3 (slot 19 pushes MOVK 0x3 before the typed lookup), and the only class-3 producer never registers. So the import is unreachable — not because a request shape is missing, but because the two properties the lookup requires cannot coexist in the implementation.

op=4 was also ruled out: it increments a counter on the target (obj word at byte 6: 1→2→3 after two calls, no new allocation) and PUT_TILE stays BadMatch at every count. Evidence: evidence/class3_registration_impossible.txt.

MAME trace: the limit we reached

A single MAME instance on the host tap (-networkprovider taptun, -cfg_directory harness/mame/cfg-net) makes the emulated terminal available at 192.168.99.2, and harness/mame/xie_resource.lua traces XieProc requests and the resource lookup. With -debuglog, every request appears as XIEHIT buf=... 0181 0002 ..., and the lookup check prints LOOK a7=... id=... class=... b36=... b40=....

Results:

• PUT_TILE can be forced through the class check with a debugger branch skip (0x6BAF6 → 0x6BBCE); it then returns success — a false success, see below.
• The exported window is still independent of the tile data: solid-white and solid-black tiles produce the same 64×64 pattern. That pattern is the XIE export default/dither, not the supplied pixels. WITHDRAWN.
• Therefore the missing piece is the band/execute format (the photoflo element/bind layer), not just the class check. The class skip only lets the request through; the data never reaches the export sink.

Correction: export has never painted anything

The 8888…2222… pattern is the window's own default background, not XIE output. Measured on one instance, one connection, 64×64 window:

BASELINE (window created+mapped+GC, NO export)  nz=512 first=88888888888888882222222222222222
AFTER    (create→arm1→PUT_TILE→arm2→EXPORT)     nz=512 first=88888888888888882222222222222222
identical to baseline: True

So every white-vs-black comparison was vacuous. The measured reason export draws nothing: the chain is intact but has no source image —

EXPORTENTRY
EXPORTFLAG f=01                       ; global @0xA6220 non-zero, render path taken
EX_BAND a5=003DC4B0 elem@d8=003FDA10  ; photoflo→band→element IS present
EX_ELEM a5=003FDA10 f28=00000000      ; element+0x28 == 0  → no imported image

The driver copies element+0x28 into the render params (0x1B238 MOVE *A5(0x28),*A11(0x610)), and the per-element render loop (0x1BC38..0x1BF30, element types 1–5 = crop/scale/rotate/mirror/export) is never reached. Because the import never runs (PUT_TILE → BadMatch), nothing fills element+0x28. Evidence: evidence/export_paints_nothing.txt, evidence/export_chain_trace.log.

The correct acceptance test is therefore "export output differs from a no-export baseline", not "export matches a known pattern".

A band dump at slot 20's comparison (0x6AB88) shows the arming state f1=01 f2=02 f4=00010000 f8=0 f12=0 f16=0. The second execute produces no BAND line at all: it fails in the lookup/state path before the band comparison, so no choice of the 35-word comparison fields can reach it.

The 0x6BA38 pointer was then tested as the resource: a second connection's before/after peek at the same address (0x003FDA10) returned the terminal message string "Connection request from IP host 192.168.99.1", identical before and after PUT_TILE. So that breakpoint is an unrelated lookup, not the XIE resource; the requested resource diff cannot be obtained with it. GHIDRA_XIE_IMPORT.md's mapping of that path is therefore wrong. Evidence: evidence/mame_look_not_resource.txt.

The real resource was then located by scanning the XIE table entry for the client id (id followed by handler pointer 0x3F566ED0; resource pointer at +12). At 0x003FDC50, the struct is id | class=02 | width=64 | height=64 | band-ptr@36 | ptr@44. Its band record is at resource+36 (0x008FE730). A full before/after diff around PUT_TILE shows:

• resource struct: byte-identical
• band record: byte-identical
• XIE globals 0x1AD800..0x1ADB00: no changed bytes
• second slot-20 execute: still BadMatch

So the post-put gate is not in the resource, the band record, or that global block. Evidence: evidence/mame_state_diff.txt.

Write watchpoints during PUT_TILE then identified the gate:

WPHIT res  addr=003FDC80 data=00000000   ; resource byte 48 = 0
WPHIT band addr=008F6750 data=00000001   ; band byte 12 = 1

Slot 20 ANDs band+0x60 (byte 12) with request byte 16 and requires zero, so after the put the second execute must use v16 = 0:

arm1 v16=1 -> OK
put          -> OK
arm2 v16=0 -> OK
arm2 v16=2/3/4/0x10 -> BadMatch

That solves the arm-2 gate. Export is still independent of the pixels: solid-white and solid-black both give nz=512 first=88888888…2222…. The band sink pointer band+0x30 is zero; poking it to the resource’s +44 pointer did not change that.

Slot 7 {op=1, type=0, id} was then tested as the bind: with it PUT_TILE returns BadIDChoice, and the export pattern is unchanged. So slot 7 is not the sink bind either. Evidence: evidence/mame_bind_slot7.txt.

Static decode of the payload handoff 0x7EAB640 (file 0x6B640) shows it is the import-element executor: it selects element type 1/2/3 from client+8, takes the band subobject at band+0xd8, calls 0x7E80008, and clears the transient payload pointer at band+0x28. band+0x30 is not used by the handoff at all. So the band sink assumption was wrong; the missing piece is the three-element pipeline definition and its export element, not the handoff target. Evidence: evidence/payload_handoff_6b640.txt.

A bit/byte correction matters: *A9(0xd8) is byte 27. The create writes the band record pointer at byte 27 of the +44 array (u32@27 = 0x003FDA10); the +36 array has zero at that byte but slot 20 does not use it for the handoff. So the handoff itself is not a no-op; the element array used by slot 20 is the one that lacks the record.

Attempting a three-element pipeline (create with band count 3 and levels [2,2,2]) makes arm 1 fail BadMatch; the one-band path works but export is still data-independent.

Populating the +36 element record by rdebug poke (r36+27 ← 0x003FDA10, the valid band record from the +44 array) also leaves export unchanged: solid-white and solid-black both give nz=512 first=88888888…2222…. So the export path is not driven by that element array either. Evidence: evidence/element_poke_no_effect.txt, evidence/pipeline_3_elements.txt.

Calling slot 21 before PUT_TILE also gives the same pattern. Slot 21 allocates a 0xC8-byte export context, calls 0x7E5B152, then frees the context at 0x630B0; the export process block reads the band’s transient payload pointer at band+0x28 (byte 5), which slot 19 clears after the handoff. No ordering of the current requests captures the tile. Evidence: evidence/export_before_put.txt.

The device-dependent dispatcher 0x7E80008 (file 0x40008) was instrumented at its CALL A11 (0x40086): no DDCALL occurred during PUT_TILE. The tile data does not reach a DD element worker at all; the dispatcher’s early type checks reject before the worker call, or the handoff does not reach it.

Instrumenting the whole path then showed the stronger result: with XIEHIT confirming that minor 19 reaches XieProc, none of the slot-19 entry (0x6A76E), the handoff (0x6B640), or the DD dispatcher breakpoints fire. The “PUT_TILE OK” is the debugger branch-skip taking an early return, not an import. The earlier put OK results are therefore not evidence of import, and the minor-19 handler mapping itself needs re-verification. Evidence: evidence/class_skip_false_success.txt, evidence/no_dd_worker.txt.

The live dispatch table then confirmed entry 19 is correct (0x3F553B70 → file 0x6A76E), and with the branch skip removed the real trace is:

XIEHIT ... 1381 0088 ...     ; minor 19 reaches XieProc
S19ENTRY                     ; 0x6A76E reached
S19LOOK a8=00000008          ; lookup returns BadMatch
put -> ERR8 bad=id minor=19
no S19HANDOFF                ; 0x7EAB640 never called

So the real path is blocked at the lookup: it needs a class-3 resource that is registered by ID. Evidence: evidence/dispatch_entry19.txt.

Superseded: the "byte 40 == 0" requirement stated here and below was a misreading. Byte 40 is a copy-out field, and the actual reason class 3 is unreachable is that create op 1 never stores the ID at obj+0. See evidence/class3_id_not_stored.txt and the correction near the top of this file. The paragraphs that follow record what was tried under the wrong assumption; they are kept for history, not as conclusions.

The bind/copy helper 0x672A4 explains why no class-3 resource qualifies: for class 2 or 3 it executes resource+0x140 = source pointer (0x673F4). Slot 11 is a two-resource bind (lookup id@4, lookup id@8, call 0x672A4), so any class-2/3 resource created or bound through this helper has a non-zero byte 40. No request in the recovered set produces class-3 with byte 40 clear; slot 43 calls the same helper, and its type descriptors/inputs remain the only untried route. Evidence: evidence/bind_672a4.txt.

Slot 43 with the source id duplicated as its destination field ([A, A, 0…]) partially changes the resource — the lookup error moves from BadMatch to BadAccess once — but the state is unstable: with slot-20 arming it returns to BadMatch, and the real PUT_TILE never passes. No class-3 resource with byte 40 = 0 and a usable band is produced. Evidence: evidence/slot43_self.txt.

Instrumenting slot 43 directly (0x65BD0 object, 0x65C46 ID store) for [A, 0] gives:

S43OBJ a8=00385D90        ; object allocation hit
S43ID                     ; ID store NEVER hit
slot43 -> BadValue
query 0 / put 0 -> BadIDChoice

The hit object is a temporary process block; poking its first word to a valid ID B still leaves B unaddressable (BadIDChoice). Slot 43 fails before the ID store, so it does not create an addressable class-3 resource. Evidence: evidence/slot43_instrumentation.txt.

A later attempt to locate the live resource by a field-filtered scan also failed: the 0x60000..0x180000 hits were class-0 copies, and 0x3E0000..0x400000 contained no matching struct. The resource pointer is not stable across runs, so the class-byte patch could not be applied to the real resource. Evidence: evidence/resource_scan_fail.txt.

A deterministic capture at 0x6CC0E (RESPTR a7=…) finally gave the real pointer. For an op-1 (class-3) resource, byte 40 was 0x003C73D0; patching it to 0 still made the real PUT_TILE return BadIDChoice:

resource 0x003FDC50 class 3, byte40 0x3C73D0 -> 0
put -> ERR14   S19LOOK a8=0000000E (BadIDChoice)   no S19HANDOFF

So a class-3 resource is not in the lookup table slot 19 searches, even with byte 40 forced to 0. The class-3 namespace is separate; patching the struct does not register it for PUT_TILE. Evidence: evidence/class3_b40_patch.txt.

The remaining gap is the destination/sink for the tile data and the export draw path. Evidence: evidence/mame_put_gate.txt, evidence/mame_put_watchpoints.log.

That leaves the same conclusion as before, now with a concrete invalidated assumption: the post-PUT_TILE state is not reachable through the recovered addresses, and the 2.3 element/state format remains unknown.

Evidence: evidence/xie_export_window_vt1200.png, evidence/xie_export_crop.png, evidence/mame_xie_resource.log, evidence/mame_band_arm2.log, evidence/mame_look_dump.log.

This is the honest ceiling of the current work: the server is understood well enough to create, arm, put and export, but the undocumented pipeline element format is still required to make the exported image be the client's pixels. A working DEC XIE 2.3 client library or protocol document is the missing external input; nothing in the ROM supplies it (MAME_XIE_TRACE.md shows the built-in image test drives hardware directly and never calls XIE).

./xiectl23.py                       # XIE 2.3 session
./probe23.py defaults               # set/query op defaults
./probe23.py cs7 0xC0AAAA 0xFFFF    # create probe + resource sweep
gcc -O2 -o xshow xshow.c -lX11
./xshow -display 192.168.99.2:0 -pattern checker -seconds 30

Other server properties that will matter once a 2.3 image client exists:

• Depth 1 / StaticGray. The VT1200 root is 1 bit deep, so pipelines that end in ExportDrawable must match that visual (ConvertToIndex/Dither/ Point); ExportPhotomap tests display nothing.
• Image files. Run from this directory or pass -images xc/programs/xieperf/images.

DEC documentation

docs/dec/ holds DEC's own manuals, downloaded rather than guessed at:

• DECimage-1200-install-use-...pdf — the closest DEC document to this server. Appendix C says the terminal "uses a subset of the XIE protocol", lists the supported functions (session/resource/transport/geometric/process control) and the pipeline restrictions.
• VT1200-user-guide-...pdf and VT1200-release-notes-V2.0-...pdf — no XIE content, but they establish what the base terminal documents.
• DTJ-1991-v03-04-...pdf — DEC Technical Journal article on the bitonal image accelerator, citing X Image Extension Concepts, Version 2.4.
• VXT2000-user-information-XIE3.0.pdf — the later DEC terminal that explicitly documents XIE protocol 3.0.
• DECwindows-Motif-OpenVMS-XIE-support.pdf — DECwindows Motif shipped XIE 3.0 (XIE$SHRLIB.EXE + headers), not 5.0 and not the VT1200's 2.3.

See docs/dec/README.md for quotes, part numbers, provenance, and the software-media checks. DEC did not publish the 2.3 wire encoding in these manuals, and the surviving Ultrix UWS tapes checked carry no XIE development kit. So request numbers and lengths still come from the live probes and the ROM analysis.

The closest surviving source is already in this tree: xc/programs/Xserver/XIE/ is DEC/AGE's server-side implementation (protocol 5.0, session.c by Dean Verheiden, AGE Logic, 1993), the direct descendant of the ROM's dispatcher. It is the structural map the Ghidra work is using.

Building

It builds on a modern toolchain, without imake, using the host's X11 headers and libraries:

./build.sh
# built: .../xie/build/xieperf/xieperf

Requires gcc, libX11-dev, libXmu-dev (and ar). build.sh stages the XIE headers as <X11/extensions/...>, compiles xc/lib/XIE into build/libXIE.a, then compiles and links the 35 xieperf sources against it with -lXmu -lX11 -lm.

Flags that matter: -std=gnu89 keeps the K&R-era source legal on GCC 16, -fcommon preserves its tentative definitions, and -w hides the expected prototype warnings. This was verified with GCC 16.2.1.

The original imake build (Imakefile: $(XIELIB) $(XMULIB) $(XLIB), MathLibrary) still works in an X11R6.1 tree, but needs the whole imake configuration.

Local fixes for DECwindows and modern libX11

Two changes were made to the vendored xc/lib/XIE/init.c (both marked with comments in the source):

1. Display-lock deadlock. XieInitialize holds the display lock and then calls XInitExtension, a public Xlib function that takes the same lock. Old single-threaded Xlib made LockDisplay a no-op unless XInitThreads had been called, so the bug was invisible; on a modern threaded libX11 it self-deadlocks in pthread_mutex_lock inside XQueryExtension. The lock is now dropped around XInitExtension and re-taken afterwards.

2. Extension name. XIE's canonical name is "XIE", but DECwindows registers it as "Xie", and extension names are case-sensitive. On the VT1200:

   XQueryExtension("XIE") = 0
   XQueryExtension("Xie") = 1, opcode=129 event=64 error=0
   

   XieInitialize now tries "XIE" and falls back to "Xie".

Without both fixes xieperf either hangs or reports XIE not supported on this display! — neither reflects the server's actual XIE support.

Upstream bug: -showtechs alone prints usage

In xieperf.c the -showtechs branch sets showTechs but not foundOne, and main calls usage() when foundOne is false. So this is not a build problem:

./xieperf -display 192.168.99.2:0 -showtechs        # prints usage, exits
./xieperf -display 192.168.99.2:0 -showtechs -all   # works; -all sets foundOne

-showtechs only prints the capability list and exits before running any test, so the extra -all has no other effect.

The BadMatch gate: object->byte8 must equal 3

The 0x8 is now located. At 0x6BAF4 the lookup compares one byte of the object against the literal 3 that slot 19 hardcodes:

6BAEE MOVE *A13(0xff40),A11,0x0   ; = 3
6BAF2 MOVE *A7,A7,0x0             ; 8-bit field
6BAF4 CMP A7,A11
6BAF6 JREQ 0x6BBCE                ; equal -> selector dispatch
6BAF8 ... MOVK 0x8                ; else BadMatch

Measured at the CMP: GATE a7=00000001 a11=00000003. This is exactly the branch once "skipped" with pc = 0x3F55DE70 to make PUT_TILE report success — that was never a real path, and we now know what it bypassed.

byte8 is arm-controlled: the arm request sets it to the 16-bit field at payload bytes 8..9 (v12), measured v12 = 0,1,2,3 → byte8 = 0,1,2,3, with arm = OK for v16 ∈ {0,1} and arm = ERR8 for v16 ∈ {2,3}.

Correction: BadAccess(10) is the unarmed path, not progress. w9=0x100 with no arm gives put = ERR10 and the gate is never reached; with w9=0x300 the arm fails, so the put was simply unarmed. With v12=3 armed (byte8=3) the gate is still not reached and neither 0x8 site fires, yet put returns ERR8 — and sweeping the tile geometry (64×64, 1×1, 63,63, 128×128, …) changes nothing. So ERR8 has at least two origins in slot 19, and the one that fires with byte8=3 is earlier than the lookup.

Evidence: evidence/badmatch_gate_located.txt, evidence/arm_sets_byte8.txt.

byte8 cannot be raised by any request except create

Clean instrumentation (harness/mame/xie_min.lua, one breakpoint) and corrected field offsets (byte N = ptr + N*8, since ptr is a bit address). byte8 was previously read at ptr+8, which is byte 1 — those numbers were wrong and are superseded.

Verified mapping from create word 9:

w9 = 0x000 0x100 0x200 0x300 0x400
b8 =   0    1     2     3     4
b9 =   1    1     1     3     1        (b9 = (b8==3) ? 3 : 1)

Sweeping every other implemented request against a w9=0x100 (byte8=1) resource:

slot 43 (len 10) BadValue     b8 1 -> 1
slot 44 (len  5) BadValue     b8 1 -> 1
slot 40 (len  4) BadValue     b8 1 -> 1
slot 33 (len  4) BadValue     b8 1 -> 1
slot 24 (len  4) REPLY        b8 1 -> 1
slot 19 (len  8) BadAccess    b8 1 -> 1

No implemented request moves byte8. Only create does, via word 9's high byte. With the arm sweep (v12 = 0..6 × v16 = 0..3, 28 shapes) the measured incompatibility stands:

byte8=1 -> arm OK,  put = BadMatch   (gate: 1 != 3)
byte8=3 -> arm ERR8 (all 28 shapes), put = BadAccess (unarmed)

So within the client-reachable request set, byte8 cannot be raised to 3 while keeping the resource arm-able. The import cannot reach the handoff, src_base stays 0, and EXPORT has nothing to draw. Evidence: evidence/byte8_slot_sweep.txt.

Harness note: with several requests outstanding on one connection the reply stream misaligns (arm/create replies are often not read back). That does not affect these results — byte8 and the slot-19 error come from independent reads — but future runs should drain between requests or use one request per connection.

The wall in code: arm needs byte8==1, import needs byte8==3

Found by bisecting slot 20's body with generated bit addresses (harness/mame/xie_min9.lua, bit = 0x3F200000 + file*8 — hand arithmetic had produced several wrong addresses earlier), valid ids, no-reply model:

w9=0x100 v14=1 : JREQ_6AB82 -> TGT_6AC34 -> EXIT_6AFDC   -> SILENT (success)
w9=0x100 v14=2 : JREQ_6AB82 -> TGT_6AC34 -> E8_2_6AC5C   -> BadMatch
w9=0x300 v14=3 : JREQ_6AB82 -> TGT_6AC34 -> E8_4_6ACD4   -> BadMatch
w9=0x300 v14=1 : JREQ_6AB82 -> TGT_6AC34 -> E8_4_6ACD4   -> BadMatch

The discriminating check:

6ACBE MOVE *A11(0x40),A7,0x0     ; A7 := object->byte8
6ACC2 DSJS A7,0x6ACD2            ; byte8==1 -> OK chain
...
6ACCA MOVE *A9(0x68),A7,0x0      ; request byte 13 (mode)
6ACCE SUBK 0x3,A7
6ACD0 JRNE 0x6AD34               ; mode != 3 -> OK path
6ACD2 MOVK 0x8                   ; else BadMatch

So:

request	requires
arm (slot 20)	object->byte8 == 1 (0x6ACBE)
import (slot 19)	object->byte8 == 3 (0x6BAF4)

and evidence/byte8_slot_sweep.txt shows no request changes byte8 except create (word9>>8). With the client-reachable request set, a resource cannot be both arm-able and import-eligible — which is why every configuration ends in BadMatch / BadAccess / BadIDChoice, src_base never becomes non-zero, and EXPORT has nothing to draw.

(The v14 value is validated separately at 0x6AC5C; mode != 3 is required at 0x6AD0.) Evidence: evidence/arm_requires_byte8_eq1.txt.

Closure: no request writes byte8

A write watchpoint on the created resource's byte8, armed across a complete cycle with valid ids and the no-reply model:

create  -> silent (success)          obj = 003FDC50
watch installed at 003FDC90          byte8 read-back = 1
arm1    -> silent (success)
put     -> BadMatch
arm2    -> BadMatch
export  -> silent (success)

byte8 WRITE EVENTS AFTER CREATE: 0

Nothing after create writes byte8. So the only route to byte8 == 3 is create word9 = 0x300, and such a resource cannot be armed; an unarmed resource's import returns BadAccess without reaching the gate.

Conclusion, with evidence: a byte8 transition into the importable state is not reachable from the client request set. The import cannot be driven, src_base stays 0, and EXPORT has nothing to draw. This closes the last request-level door in this investigation.

Residual possibilities are all outside that set: an internal path the watch never observed (nothing writes it in a normal cycle), an unimplemented minor, or the real DEC 2.3 sequence differing entirely — which its documentation would state. Evidence: evidence/byte8_write_watch_closure.txt.

The three residual items, tested

The previous closure was limited to one watchpoint on one resource; all three residuals are now tested (evidence/residual_items_tested.txt):

1. Static search for internal byte-8 writers across every disassembled XIE handler. Exactly one candidate exists — slot 20 0x6ABF6..0x6AC00 (*A11(0x40) |= request payload byte 16) — and it is dead code: it is guarded by *A13(0x40) != 0 at 0x6AB82, while *A13(0x40) is only assigned later at 0x6AD92 from a freshly allocated params block. The measured fired-path confirms every arm goes 0x6AB82 → 0x6AC34 and never enters that block.
2. Runtime watch on a w9=0x300 resource (the type the import wants) across four arm attempts, all BadMatch: 0 write events.
3. Unimplemented minors as an alternate import path: all 21 unassigned minors × lengths 2,3,4,6,8,12 = 126 requests, every one BadRequest.

So there is no executing internal writer, no runtime writer, and no second import entry point. The byte8 transition into the importable state is unreachable from the client, src_base stays 0, and EXPORT has nothing to draw.

Slot 43 decoded: a reporting request, not an image source

Length is exactly 10 words. It reads two resource ids (payload words 0 and 1, looked up through 0x7EA6FA0 at 0x65640) plus two ROI fields (words 4 and 5), falling back to the resource's own width/height at *A13(0x1c0)+0x80/0xa0.

The "descriptor tables containing 3.0 / 438.0" are arrays of IEEE doubles, not descriptors — 0x3F533740 reads 00 00 00 00 00 00 08 40 = 3.0, and each MOVI points 8 bytes further into the same array. Each load is followed by two MOVE *A8+,*A14+ (one double) and a call into the printf family (0x7FC1CE6 / 0x7FC18F6 / 0x7FC1CDE), the same helpers used by the export timing print and by the logger at 0x7F638C2.

Tested live with valid ids and the no-reply model — 17 payload shapes, including doubles in every position, single-id and two-id forms, and ROI-shaped values: every one returned BadValue. Its exact ROI preconditions were not reconstructed, but its body is printf-dominated and nothing observed connects it to src_base or to any image data plane. It is therefore not credible as the image-source element. Evidence: evidence/slot43_decoded.txt.

Direct watch on the src_base slot, and slots 15 / 22

The src_base slot itself (rp+0x610) was watched, with rp captured at the export breakpoint (0x1B296, A11 = rp) — rp = 00913330, slot = 00913940.

create/arm1/put/export#1   put BadMatch, export#1 BadMatch
slot15 [id,0]              silent (success)
slot22 [id]                silent (success)
slot15 [id,id]             silent (success)
arm2, export#2             silent (success)

rp+0x610 after export#1 = 00000000
rp+0x610 after export#2 = 00000000

18 writes at 00913940; only XIE writer is pc=3F2D91F0 (file 0x1B23E, the known
`MOVE *A5(0x28),*A11(0x610)` copy) and it writes 0. The 0x55/0xB055/0x90E6
values are heap-fill and allocator metadata.

Slots 15 and 22 are permissive (they accept [id,0], [id,id], [id]) but neither produces a non-zero write to src_base. Also confirmed: export returns BadMatch if arm2 has not been issued, and is silent/success once it has — consistent with the earlier arm2 gate.

So the source image buffer is never produced, by any path watched. Evidence: evidence/srcbase_watch_and_slots15_22.txt.

Slot 43 excluded: it validates doubles and prints, it does not source images

BadValue comes from a double comparison against its table: it loads a double (0x3F533740 = 3.0, 0x3F533780, 0x3F533900, … successive 8-byte entries) and calls 0x7FC1CE6 / 0x7FC18F6 / 0x7FC1CDE:

658B8 CALLA 0x07FC1CDE
658BE JREQ  0x658CA     ; equal -> continue
658C0 MOVK  0x2,A7      ; else BadValue

Its one element-chain block copies each element's +0x1a8 into a frame-local array for printing (659E2 *A11(0x140) = *A7(0x1a8), with A11 = A13 + i*4), not into the resource. Every store goes to frame locals or the params block; it never writes resource+0x140, never writes rp+0x610, and allocates no image buffer.

Empirically, with a write watch on the real src_base (rp = 0091F090 → 0091F6A0), four slot-43 shapes all returned BadValue and the 64 watch events were all 00000000 or 00000055 (allocator fill) from export's own copy (pc=3F2D91F0) and allocator PCs — no non-zero image pointer.

So slot 43 is a reporting/describe request and cannot be the source of the image. This closes the last implemented slot whose acceptance condition was unresolved. Evidence: evidence/slot43_excluded.txt.

Slot 43: acceptance precondition still not satisfied (honest status)

The table is little-endian doubles (TMS34010 is LE): 0x3F533780 = 3.0, 0x3F5337C0 = 871.0, 0x3F533800 = 873.0, 0x3F533840 = 217.0, 0x3F533880 = 219.0.

Logging the two frame locals pushed as the operand pair at the double-compare sites (0x656B0 = "CMP740", 0x658B8 = "CMP900"):

[id,0,0,0,...]        BadValue   CMP740 a0=00000000 a1=00000000
[id,0,3.0hi,0,...]    BadValue   CMP740 a0=00000000 a1=00000000
[id,0,0,3.0hi,0,...]  BadValue   CMP740 a0=FFF7D264 a1=BFE800FF

CMP900 — the site that raises BadValue at 0x658C0 — never fired, so the rejection happens earlier than the comparison I was chasing, and the doubles are not read from the payload words tried.

Status of the slot-43 claim: it is excluded on code reading (a per-element reporting loop copying element+0x1a8 into a frame-local array, then printf) and on watched evidence that no slot-43 request produced a non-zero write to src_base — not on a completed, accepted request. Its exact acceptance precondition remains unknown. This is recorded rather than glossed: the implemented surface is not fully exercised until that precondition is found. Evidence: evidence/slot43_compare_operands.txt.

The render driver itself returns 2 to slot 43

Instrumented slot-43 tail (9 breakpoints, generated addresses, valid ids, isolated connection, create drained first):

T_LOOKUP_OK  0x65646              lookup returned 0
T_RENDER_RET 0x65BFE              a8 = 00000002   <-- the DRIVER returned 2
T_JREQ       0x65C02              non-zero path
T_FREE       0x65C06
(T_MERGE     0x65C46 did not fire)

So slot 43 calls 0x07E5B152 (file 0x1B152, the render/export driver) and that call returns 2 — which is what the client sees as BadValue. Neither of slot 43's own MOVK 0x2 sites is involved.

The single MOVK 0x2 in the driver's first 240 instructions (0x1B360) is an element type write (MOVB *A11,*A5(0x58)), not an error code, so the 2 comes from another exit of 0x1B152.

Caveat recorded: after T_FREE (0x65C06) the code falls through to 0x65C46, yet that breakpoint did not fire. Either it was dropped (despite only 9 armed) or the free call does not return normally; I did not resolve which, so the tail path after 0x65C06 is not fully established.

What is established: the failure is inside the render driver, not in slot 43's checks, not in the import lookup, and not the byte8 gate. An accepted slot 43 would drive the render path directly. Evidence: evidence/render_driver_returns_2.txt.

The manual (EK-V120I-IN-001) and the documented display path

docs/EK-V120I-IN-001_installing-DECimage-1200.txt — Appendix C, Table C–1 — gives the semantic model this project had been inferring:

• supported requests: INIT_SESSION, SET/QUERY_OP_DEFAULTS, TERM_SESSION, CREATE_BY_VALUE, CREATE_BY_REFERENCE, DELETE_RESOURCE, QUERY_RESOURCE, EXPORT, FREE_EXPORT, QUERY_EXPORT, SET/ABORT_TRANSPORT, PUT_TILE, PUT_STREAM, SCALE, ROTATE, MIRROR, CROP, EXECUTE_PHOTOFLO, ABORT_PHOTOFLO, BIND_PHOTOFLO, TAP_PHOTOFLO, SELECT/QUERY_EVENTS;
• "Always use pipelines"; elements limited to scale, crop, rotate, mirror, export, at most one of each, must always end with export, prefer that order, max 15;
• XIEP_EXPORT "Creates a new server PIXMAP resource object", and images are displayed "by copying from a pixmap … using XCopyArea or XCopyPlane";
• SET_OP_DEFAULTS: "Bits/pixel parameter value must be 1";
• rotate only 0/90/180/270; width/height must be 0 or match the rotated source; tap only on an empty pipeline; no DCT; no server→client transport;
• errors: "The client receives a Bad Request or Bad Match or Bad Value X error … Do not invoke an XIE protocol request that is implemented, but violates its restricted use."

That last point reframes much of this investigation: BadMatch/BadValue are documented, expected responses to a restriction violation (including "create non-bitonal image objects"), not bugs — and byte8 is most likely the bits/pixel field, which must be 1.

Implemented the documented display path (evidence/export_query_copyarea.txt): EXPORT → QUERY_EXPORT (op 3/4 reply, 64×64 + pointers + resource id) → XCopyArea → GetImage. The export context reply does not carry a usable pixmap XID — its id-like field varies per run (0x00920101, 0x00380101, 0x00330101, 0x00360101) and looks like a heap pointer; XCopyArea rejects each with BadDrawable. Window unchanged for solid-white and solid-black.