arti
d8d54bb990
The XIE path now runs end to end: XieCreateImage -> XieCreatePhoto ->
XiePutTile -> XieExport(photomap -> depth-1 pixmap) -> XCopyArea(pixmap ->
window), and the client's tile appears on screen at the client's own window
position, pixel-exact.
TWO FAULTS BEHIND THE LONG DEAD END
1. Device model (harness/mame/vt1200.cpp, opt-in VT1200_ACCEL=1). The
accelerator's output port 0x5600200 returns the pixel stream the firmware
pushed into the FIFO -- the firmware then stores it into the drawable itself
(file 0x125528: MOVE *B6,*B1 ; ADDK 0x10,B1). The FIFO read pointer was
never reset between transfers, so consecutive exports read stale words and
the same fill produced 759 then 516 set pixels. Reset m_fifo_in/out on the
data-register write; the export is now deterministic.
2. Measurement, not the device.
- dwt/screenshot.py without --real reads 1024x1024 at a 128-byte row stride,
but the VR319 default programs 1280x1024 at a 2048-bit (256-byte) pitch.
That is the "shifted" picture; --real is the correct read.
- The earlier "0 differing bytes over 128 KiB" VRAM comparison stepped peek
by 1024 *bit* addresses, so it scanned rows 0..63 only -- never the window
at rows 200..263. Over the real raster the white/black diff is 576 bytes
spanning exactly those rows.
- New instrument: decclient does a server-side XGetImage readback of the
pixmap and window and counts set pixels. That separated "the server never
drew it" from "the framebuffer view is wrong".
EVIDENCE (reproduced twice, the second time from a fresh machine)
no export vs 0xFF : 4096 / 4096 pixels differ
no export vs 0x00 : 0 / 4096 (the window background is black)
0xFF vs 0x00 : 4096 / 4096
0xAA vs 0x0F : 2048 / 4096 (the two stripe phases)
Tile byte 0xAA reproduces as 1-pixel vertical stripes, 0x0F as 4-pixel, with
no shear -- so the placement is right and the pixels are the client's.
Contents: xie/ holds DEC XIE 2.3 headers, 84 man pages and complete
client+server source; a libXie.a and decclient built from DEC's own code; the
XIE probes; and evidence/ with every measurement, including explicit
retractions of the earlier wrong readings (VRAM_IDENTICAL_FOR_BOTH_FILLS and
friends). xie/evidence/XIE_IMAGE_DISPLAYED.md is the report; frames are in
xie/evidence/png/.
The accelerator model stays opt-in: it answers the status poll and relays the
pixel stream, but performs no compositing, so it is a stand-in and the verified
default configuration is unchanged (a no-env run still parks in the level-0
diagnostics menu at PC=3FDCE400).
DEC documentation relevant to the VT1200's XIE server
Downloaded 2026-11-01. These are DEC's own documents, not the X Consortium
XIE 5.0 specification (that one is in ../../xc/doc/hardcopy/XIE/).
| file | what it is | XIE content |
|---|---|---|
DECimage-1200-install-use-EK-V120I-IN-001.pdf |
Installing and Using the DECimage 1200 Video Terminal, EK-V120I-IN-001, February 1991 | The key document. Appendix C ("X Window Image Extensions") states the terminal's XIE server "uses a subset of the XIE protocol", lists the supported functions (Table C–1) and the pipeline/scaling restrictions |
VT1200-user-guide-EK-V1200-UG-001.pdf |
VT1200 Video Terminal User Guide, EK-V1200-UG-001 | No XIE mention (checked: zero matches for XIE / image extension) |
VT1200-release-notes-V2.0-EK-V1200-RN-001.pdf |
VT1200 Video Terminal V2.0 Release Notes, EK-V1200-RN-001, July 1990 | No XIE mention |
DTJ-1991-v03-04-bitonal-image-accelerators.pdf |
Digital Technical Journal Vol. 3 No. 4 (1991), article Hardware Accelerators for Bitonal Image Processing (pp. 11–27) | Describes the DECimage accelerator and the S/XIE client–server split; cites X Image Extension Concepts, Version 2.4 (J. Mauro) in its references |
VXT2000-user-information-XIE3.0.pdf |
VXT 2000+ / VXT 2000 Windowing Terminal User Information, Appendix C | Later DEC terminal; says "The terminal supports Version 3.0 of the XIE protocol" and gives the XIE pipeline constraints for the accelerator |
DECwindows-Motif-OpenVMS-XIE-support.pdf |
HP DECwindows Motif for OpenVMS New Features (Alpha V8.3 documentation set) | States that DECwindows Motif shipped XIE from Motif V1.1, includes XIE$SHRLIB.EXE and C headers, and supports XIE 3.0, "not the adopted standard of V5.0" |
Only PDFs and their pdftotext -layout renderings are kept; the renderings are
searchable and are what the quotes below come from.
What the DECimage 1200 manual says
Appendix C, opening paragraph:
The DECimage 1200 terminal includes X window image extensions (XIE), an extension to the DECwindows server. […] The XIE server for the terminal uses a subset of the XIE protocol to display document-size, bitonal images only.
The supported function list in Table C–1 is grouped as:
- Session services:
XIEP_INIT_SESSION,XIEP_SET_OP_DEFAULTS,XIEP_QUERY_OP_DEFAULTS,XIEP_TERM_SESSION - Resource services:
XIEP_CREATE_BY_VALUE,XIEP_CREATE_BY_REFERENCE,XIEP_DELETE_RESOURCE,XIEP_QUERY_RESOURCE,XIEP_EXPORT,XIEP_FREE_EXPORT,XIEP_QUERY_EXPORT - Transport services:
XIEP_SET_TRANSPORT,XIEP_ABORT_TRANSPORT,XIEP_PUT_TILE,XIEP_PUT_STREAM - Geometric:
XIEP_SCALE,XIEP_ROTATE,XIEP_MIRROR,XIEP_CROP - Process control:
XIEP_EXECUTE_PHOTOFLO,XIEP_ABORT_PHOTOFLO,XIEP_BIND_PHOTOFLO,XIEP_TAP_PHOTOFLO,XIEP_SELECT_EVENTS,XIEP_QUERY_EVENTS
Restrictions stated there: pipelines may use only scale, crop, rotate, mirror
and export, at most one of each, must end with export, and are limited to 15
definitions; decompression is CCITT Group 3/4 with scaled width ≤ 32768;
rotation is 0/90/180/270 only; SET_OP_DEFAULTS bits/pixel must be 1. This
matches the 1-bit StaticGray VT1200 server we are talking to.
What the DEC documents do not give us
DEC's XIE protocol encoding — request numbers, request lengths, reply layouts — is not in these manuals. The DECimage manual documents the supported subset and restrictions, not the wire format. No public copy of the DECimage "X Programmer's Reference Manual" / XIE 2.3 protocol specification was found (the manual list names it, but the document itself is not online in the collections searched).
So the 2.3 wire differences currently come from two sources:
- raw probes against the live server (
../../evidence/xie_wire_probe.txt); - the ROM's own dispatcher, recovered with Ghidra (
../../GHIDRA_XIE.md).
Surviving software media (checked)
DEC software media do survive, but the ones checked do not contain a 2.3 client kit:
- ULTRIX 4.0 UWS tape (
archive.org, itemdec-ultrix-vax-4.0-tapes,UWS_4.0A.tap, 7.6 MB): the setld inventory lists DECwindows X servers, fonts and applications — noXIEproto.h,libXIE,XieInitializeorxieperf. - ULTRIX 4.2 unsupported tape (
dec-ultrix-4.2-unsupported-tape): no XIE strings in the inventory. - ULTRIX VAX 4.2 unsupported CONDIST, August 1992
(
dec-ultrix-vax-condist-1992-08): itscd_contents.datlists unsupported layered products only — no DECwindows or DECimage. - DECwindows Motif for OpenVMS is the product that did ship XIE on the
client side, but it is 3.0: "DECwindows Motif includes the XIE client side
shareable library (
XIE$SHRLIB.EXE) and C language header files", and it "supports V3.0 and not the adopted standard of V5.0". Surviving OpenVMS CONDIST CDs and the Tru64/Digital UNIX Software Product Library (Jan 1999) are therefore 3.0/5.0-era, not 2.3. - DECUS tapes in the bitsavers archive are user-contributed software, not DEC's XIE product kit.
So the answer to "do DEC tape archives survive?" is: media survive, in some quantity, but no archived kit found so far carries the VT1200's XIE 2.3 client library or headers. The 2.3 protocol evidence therefore comes from the ROM and from live probes, not from a recovered DEC SDK.
The closest surviving source: DEC/AGE's server implementation
The X11R6.1 tree in this directory is not just the 5.0 client. It also contains the server-side XIE implementation:
xc/programs/Xserver/XIE/dixie/request/session.c
xc/programs/Xserver/XIE/dixie/request/tables.c
xc/programs/Xserver/XIE/dixie/request/*.c
session.c says "Dean Verheiden -- AGE Logic, Inc March, 1993" and calls
AddExtension(xieExtName, ...) from XieInit(). This is the direct descendant
of the code in the VT1200 ROM, at protocol 5.0 rather than 2.3. It is the best
structural map for the Ghidra analysis: the 26-entry ProcTable5_00[], the
ProcQueryImageExtension reply (8 preferred levels, matching the VT1200's
reply length), and the REQUEST_SIZE_MATCH length checks all have 2.3
counterparts in ROM. The differences are what the Ghidra report is recovering.
Provenance
- https://decdoc.itsx.net/dec94mds/v120iin1.pdf
- https://decdoc.itsx.net/dec94mds/v1200ug1.pdf
- https://decdoc.itsx.net/dec94mds/v1200rn1.pdf
- https://www.filibeto.org/dec/hardware/EK-V1200-UG-001.pdf
- https://www.filibeto.org/dec/hardware/EK-V1200-RN-001.pdf
- https://www.mrynet.com/FTP/os/DEC/dtj_v03-04_1991.pdf
- https://www.filibeto.org/dec/hardware/EK-VXT20-UG-E01.pdf
- https://www.digiater.nl/openvms/doc/alpha-v8.3/83final/decwindows/features/DWINDOWS_NF.PDF
The DECimage and VT1200 files were fetched from the DECdocument mirror at
decdoc.itsx.net; the DTJ issue from the mirror at mrynet.com; the VXT 2000
manual from filibeto.org.
Related DEC-derived material already in this tree
../../xc/doc/hardcopy/XIE/SI/xieSIarch.txt — XIE Sample Implementation
Architecture, credited to DEC and AGE Logic, describing the sample
implementation (the one that became XIE 5.0, not the VT1200's 2.3 server).