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