arti/vt1200
1
0 Fork 1
mirror of https://git.k-space.ee/arti/vt1200.git synced 2026-11-03 12:33:16 +02:00
Code Wiki Activity
Files
17dfd24340fe3346433f90457cb48cb8786dff39
vt1200/xie/docs/dec/README.md
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

127 lines
7.1 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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
- <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).
View Git Blame Copy Permalink