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/xie23
T
History
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
..
include/dec/extensions
feat(xie): a client-chosen XIE image is displayed on the VT1200
2026-11-01 23:22:25 +02:00
man
feat(xie): a client-chosen XIE image is displayed on the VT1200
2026-11-01 23:22:25 +02:00
README.md
feat(xie): a client-chosen XIE image is displayed on the VT1200
2026-11-01 23:22:25 +02:00

README.md

DEC XIE 2.3 development kit (recovered from DEC OSF/1 media)

XieProto.h declares the protocol this directory was recovered for:

#define XieK_MajorVersion   2
#define XieK_MinorVersion   3

This is the DEC XIE, not the X Consortium/MIT lineage: the header is DEC's own (Copyright 1989-1991 by Digital Equipment Corporation ... and the Massachusetts Institute of Technology), lives under include/dec/extensions/, and its revision log says "Update to XIE VN/ALPHA_BL1 baselevel, 92/04/06".

It is the artefact the VT1200 work needed: the terminal speaks XIE 2.3 with 46 minor slots, and XieProto.h gives that numbering and the request structures.

Provenance

Recovered 2026-11-01 from DEC OSF/1 install media at https://fsck.technology/software/DEC-Compaq/Digital%20OSF1%20Install%20Media/. Those CDs are UFS1 images, not ISO-9660; they mount with mount -t ufs -o ro,loop,ufstype=old, and the install kits inside are compress(1)-ed tar archives.

local path came from original member
include/dec/extensions/Xie*.h DEC OSF/1 2.0 (DECstation) media, X11 development kit BL8_2kits/f109.OSFXDEV200.tar.Z → ./usr/include/dec/extensions/
lib/osf1-2.0-decstation/libXie.a same kit ./usr/lib/libXie.a
man/*.3X (84 pages) DEC OSF/1 2.0 (DECstation), man-pages kit BL8_2kits/f131.OSFMANWS200.tar.Z → ./usr/share/man/man3x/
lib/osf1-1.2-alpha/libXie.a DEC OSF/1 1.3a (AXP) OS CD, X11 dev kit ALPHA/BASE/OSFXDEV120
lib/osf1-1.2-alpha/libXie.so DEC OSF/1 1.3a (AXP) OS CD, X11 runtime ALPHA/BASE/OSFX11120 → ./usr/shlib/libXie.so
server/osf1-1.2-alpha/lib_dec_xie.so DEC OSF/1 1.3a (AXP) OS CD, server kit ALPHA/BASE/OSFSER120 → ./usr/shlib/Xserver/lib_dec_xie.so

Media used (local copies, outside the repo):

/home/arti/code/k-space/dec-media/osf1-2.0-decstation.zip   125,721,389 bytes
/home/arti/code/k-space/dec-media/osf1-1.3a-os.iso         614,711,296 bytes

Protocol request minor opcodes (XieProto.h)

 1 InitSession           12 AbortPhotoflo         23 Import
 2 TermSession           13 ExecutePhotoflo       24 QueryExport
 3 QueryEvents           14 TapPhotoflo           25 Area
 4 SelectEvents          15 AbortTransport        26 AreaStats
 5 SetOpDefaults         16 GetStream             27 Arith
 6 QueryOpDefaults       17 GetTile               28 CalcHist
 7 CreateByReference     18 PutStream             29 ChromeCom
 8 CreateByValue         19 PutTile               30 ChromeSep
 9 DeleteResource        20 SetTransport          31 Compare
10 QueryResource         21 Export                 32 Constrain
11 BindPhotomap          22 FreeExport             33 Crop
                         34 Dither   37 Luminance  40 Mirror  43 Rotate
                         35 Fill     38 MatchHistogram 41 Point 44 Scale
                         36 Logical  39 Math       42 PointStats 45 Translate
                                                   46 LastRequest

Fixed packet sizes are declared alongside (sz_xieCreateCppReq 24, sz_xiePutTileReq 32, sz_xieCreatePhotoReq 48, sz_xieSetOpDefaultsReq 20, ...), and the full request/reply structs follow them in the same header.

Cross-check against the live VT1200 (observed by the peer session)

VT1200 slot observed behaviour this header says
1 2 words, replies 2.3 InitSession, sz_xieInitSessionReq 8
2 1 word, success, no reply TermSession, sz_xieTermSessionReq 4
6 bare header, empty reply QueryOpDefaults, sz_xieQueryOpDefaultsReq 4
11 3 words, id at byte 4 BindPhotomap
19 PUT_TILE, 8+ words PutTile, sz_xiePutTileReq 32
20 fixed 35-word request SetTransport
21 16 words Export
23 BadRequest (not implemented) Import
24 4 words, id at byte 4 QueryExport

Every slot lines up, which is what makes this the period numbering rather than a coincidence.

What is here

include/dec/extensions/  XieProto.h XieLib.h XieAppl.h XieDdx.h
                         XiePipeInterface.h XieUdpDef.h XieFloat.h
lib/osf1-2.0-decstation/ libXie.a               (MIPS/DECstation, 150,252 bytes)
lib/osf1-1.2-alpha/      libXie.a libXie.so     (Alpha, Feb 1993)
server/osf1-1.2-alpha/   lib_dec_xie.so         (Alpha X server XIE module,
                                                 XieDixProc / SProcXie*)
man/                     84 Xie*.3X man pages   (DEC 1992 client API reference,
                                                 with C examples)

md5

0e75e976c8775ecf3edf36d11814b6bb  include/dec/extensions/XieAppl.h
235c34478efd18f3c50ff02b4bc1865d  include/dec/extensions/XieDdx.h
35cbcb18037d7cedb6cc3b27c13807a1  include/dec/extensions/XieFloat.h
fdcff8c986142092c6caf621e1aee4a0  include/dec/extensions/XieLib.h
8644b708a1c0124d473e0c401beec344  include/dec/extensions/XiePipeInterface.h
ea36374201767e926d23e77f8a778677  include/dec/extensions/XieProto.h
3b9ce78a243dc043749dd16c36301a18  include/dec/extensions/XieUdpDef.h
08cee42c88c71e15c3bc25faefff269c  lib/osf1-1.2-alpha/libXie.a
8d24d55b571e61a2f544bc040eb7536b  lib/osf1-1.2-alpha/libXie.so
09f483d8570fd1f899c78439ccd6a4b1  lib/osf1-2.0-decstation/libXie.a
eb4135366a136a4de03cb5e3ba83dc57  server/osf1-1.2-alpha/lib_dec_xie.so

Negative results worth not repeating

  • DEC OSF/1 1.3a layered-products CD (Dec 1992): 14 products (AVO410 CXX120 DFA330 DMG320 DNA100 DPO500 FUS120 GKO510 KPC100 KPF100 ODB110 PHO240 XML200 XXA100) — no XIE, no DECimage.
  • Tru64 UNIX 4.0F ships XIE 5.0 only (xieMajorVersion 5), and its four X11/extensions/XIE*.h are byte-identical to the MIT X11R6.1 copies.
  • Ultrix CONDIST Oct93–May95 (VAX + RISC): DECimage appears only as "DECimage Character Recognition 1.1" (UPI MH5AA, /irs110).
  • Ultrix 4.5 OS kit (85 subsets, 13,679 members): no XIE file, no libXie.
View Git Blame Copy Permalink