The question was whether this ROM answers "unsupported" for XieK_DCT. It does,
at both layers, and it behaves exactly like an out-of-range scheme value.
SetTransport (minor 20), raw wire request, a fresh bitonal photomap per scheme:
PCM / G31D / G32D / G42D -> accepted
DCT (4) and 5 -> BadIDChoice(14), minor_op 20
So the ROM does not even implement the reference server's IsBitonal_ rules
(G42D is accepted on a 256-level photomap, where XieTransport.c would BadMatch),
but it does refuse 4 and above.
Export (minor 21) with the photomap's compression byte forced to each value
(the server never initialises it -- it holds the heap fill 0x55, which is why
harness/mame/xie_fix.lua pokes file 0x1B256):
0..3 -> pixmap 4096/4096, no X error
4 -> BadValue, nothing drawn
5 -> BadValue, nothing drawn
And the ROM carries no JPEG machinery: no "JPEG"/"DCT" string, and the standard
Annex K quantisation table is absent in both zigzag and natural order (no flat
8x8 either). A DCT codec carries one of those; this ROM carries none.
"DDX_RENDER: unsupported compression scheme" exists in the ROM but did not fire
in these runs, so it belongs to a path these probes do not reach -- recorded as
an open detail rather than claimed as the explanation.
Probes: xie/xiescheme.c (libXie, one scheme per connection) and
xie/xie_schemes_raw.py (raw protocol, exact error codes).
DEC XIE 2.3 (what the VT1200 speaks) defines exactly five, in XieAppl.h:
XieK_PCM 0, XieK_G31D 1, XieK_G32D 2, XieK_G42D 3, XieK_DCT 4. XieK_DCT is
the JPEG/DCT scheme; there is no XieK_JPEG and no TIFF/RLE/LZW constant.
Worth recording because it explains the BadValue/BadMatch history: the server's
ProcSetTransport allows PCM unconditionally, allows G3/G4 only for a bitonal
image outside XieK_Tile mode, and allows DCT only for a NON-bitonal image
outside XieK_Tile and outside XieK_BitByPlane -- anything else is BadValue. A
bitonal 64x64 photomap in Tile mode therefore admits PCM only, which is what
the working client sends. In ProcGetStream/ProcSetStream G31D and G32D are
literally "not yet supported", and DCT/G42D are delegated to the DDX hooks
DdxEncodeDct_ / DdxEncodeG4_ -- i.e. to the board's accelerator.
The X Consortium X11R6.1 lineage (xc/) is a different, larger list: ten
Decode/EncodeTechnique values including JPEGBaseline 10, JPEGLossless 12,
TIFF2 14 and TIFFPackBits 16.
Cross-referenced with DTJ Vol. 3 No. 4 (Fall 1991), "Hardware Accelerators for
Bitonal Image Processing": the ASIC described there is a CCITT (G3-1D, G3-2D,
G4-2D) decompressor plus scaler and rotator -- the scalution hardware -- while
JPEG/DCT is that article's continuous-tone counterpart (citing C-Cube CL550-10,
not the bitonal chip). The two map onto XieK_G42D and XieK_DCT.
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).
arti