forked from opencode.energia.arti.ee/vt1200
arti
d8d54bb990
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).
53 lines
3.1 KiB
Plaintext
53 lines
3.1 KiB
Plaintext
HUNT FOR THE ELEMENT-LIST HANDLER: NO VARIABLE-LENGTH ELEMENT REQUEST EXISTS
|
|
IN THE IMPLEMENTED SURFACE.
|
|
|
|
A) STATIC: every handler's length gate was extracted and classified
|
|
slot 0 EXACT(4) slot 1 EXACT(2) slot 3 EXACT(2) slot 4 EXACT(2)
|
|
slot 5 EXACT(5) slot 7 EXACT(4) slot 8 MIN(>=3) slot 9 EXACT(3)
|
|
slot 10 EXACT(3) slot 11 EXACT(3) slot 12 EXACT(2) slot 13 EXACT(2)
|
|
slot 14 EXACT(4) slot 15 EXACT(3) slot 18 MIN(>=4) slot 19 MIN(>=8)
|
|
slot 20 EXACT(35) slot 21 EXACT(16) slot 22 EXACT(2) slot 24 EXACT(4)
|
|
slot 33 EXACT(4) slot 40 EXACT(4) slot 43 EXACT(10) slot 44 EXACT(5)
|
|
Only slots 8, 18, 19 accept a variable length. A photoflo-create request
|
|
carrying "the supplied list of elements" (xieSIarch.txt 8.3.3.1 / 8.3.4.1)
|
|
would have to be variable length or a very large fixed layout.
|
|
|
|
B) SLOT 20 IS THE ONLY LARGE FIXED REQUEST: length must be EXACTLY 35 words
|
|
0x6AA6E MOVE *A9(0x10),A7,0x0 ; request length
|
|
0x6AA72 CMPI 0x23,A7 ; 0x23 = 35
|
|
0x6AA76 JREQ 0x6AA7E else MOVK 0x10 (BadLength)
|
|
It then does the generic resource lookup (0x7EAB966) on w0 with byte13 as a
|
|
class argument, and loops over up to 3 band-array elements (*A5(0xd8)).
|
|
|
|
Measured (photoflo + image both registered, 35-word payload, 32 data words):
|
|
w0=FLO w2hi=0 -> err2 (BadValue) renderer trace: (none)
|
|
w0=FLO w2hi=1 -> err8 (BadMatch) renderer trace: (none)
|
|
w0=FLO w2hi=2 -> err8 (BadMatch) renderer trace: (none)
|
|
w0=FLO w2hi=3 -> err8 (BadMatch) renderer trace: (none)
|
|
w0=IMA w2hi=2 -> err8 (BadMatch) renderer trace: (none)
|
|
No TYPE1..TYPE5 store fired, the RP (0x1B296) breakpoint never fired, and the
|
|
GATE never ran. So slot 20 rejects before building anything.
|
|
|
|
C) THE TWO VARIABLE-LENGTH HANDLERS DO NOT FIT EITHER
|
|
slot 8 MIN(>=3): parses 4 request words, has NO element loop, and an
|
|
over-long payload simply fails to register (length sweep 11..27).
|
|
slot 18 MIN(>=4): the only handler that touches *A7(0xd8) and writes
|
|
element+0x20, but it returns BadAccess(10) with the resource id for
|
|
BOTH a class-2 resource and a class-1 photoflo.
|
|
|
|
D) CONSEQUENCE
|
|
Within the request surface this server implements and that I can drive, there
|
|
is no request that accepts a list of elements with phototags, no request that
|
|
writes the element record, and no request that makes the renderer produce a
|
|
non-zero source (src_base = rp+0x610 has been 00000000 in every run).
|
|
|
|
STATUS. No client-chosen XIE image. The window has never differed from the
|
|
no-export baseline; solid-white and solid-black readbacks are identical; xshow
|
|
(core X) is the only viewer that has displayed an image.
|
|
|
|
WHAT IS STILL MISSING, precisely: the WIRE ENCODING of the photoflo element list
|
|
(phototag / element type / parameter field order and the DAG connection fields)
|
|
plus the minor opcode of the request that carries it. xieSIarch.txt documents
|
|
the semantics (7.3 Photo Element Definition; 8.3.4.1 Create) but is a server
|
|
architecture document and does not specify the protocol encoding.
|