arti/vt1200

0 Fork 1

mirror of https://git.k-space.ee/arti/vt1200.git synced 2026-11-03 12:33:16 +02:00

Files

T

arti d8d54bb990 feat(xie): a client-chosen XIE image is displayed on the VT1200

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).

2026-11-01 23:22:25 +02:00

7.1 KiB

Raw Blame History

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, item dec-ultrix-vax-4.0-tapes, UWS_4.0A.tap, 7.6 MB): the setld inventory lists DECwindows X servers, fonts and applications — no XIEproto.h, libXIE, XieInitialize or xieperf.
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): its cd_contents.dat lists 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

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.

../../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).

7.1 KiB Raw Blame History Unescape Escape