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).
41 lines
2.1 KiB
Plaintext
41 lines
2.1 KiB
Plaintext
TURN RECORD: THE EXPORT PATH ENDS IN AN UNCONDITIONAL BadValue REPORT.
|
|
|
|
Traced with the genuine DEC 2.3 client (decclient, org=BandByPlane):
|
|
|
|
J884 b9=01 ; rp byte 9 non-zero -> JREQ NOT taken
|
|
CONT_1B888 ; normal continuation
|
|
J9F2 a8=00000000 ; the call at 0x1B9EC RETURNED 0 (success)
|
|
ERR_1BA30 ; ...and execution then jumps to 0x1BA30 anyway
|
|
ERR_1BA68 MOVK2 ; 0x1BA68 MOVK 0x2,A11 -> report BadValue
|
|
DRIVER_RET a8=00000002 ; the driver returns 2; the export handler
|
|
; (0x630BC: A5 = *A13(0x120); JREQ -> success)
|
|
; therefore reports BadValue to the client
|
|
|
|
The code at the junction (file 0x1B9D4..0x1B9F2):
|
|
0x1B9D4 push MOVK 0x2 ; operation code 2
|
|
0x1B9D6..0x1B9EA push five frame values
|
|
0x1B9EC CALLA 0x07E5BBCA ; the actual export-to-drawable operation
|
|
0x1B9F2 JR 0x0001BA30 ; UNCONDITIONAL jump into the report/cleanup block
|
|
and 0x1BA30 is:
|
|
0x1BA30 CALLA 0x07F67F38 ; 0x1BA44 CALLA 0x07E75EA8 (called with 0xa6000, frees rp)
|
|
0x1BA60 CALLA 0x07EA45FE
|
|
0x1BA68 MOVK 0x2,A11 ... 0x1BA78 CALLA 0x07E7FE96 ; send BadValue
|
|
|
|
So on this path the driver performs the operation, gets 0 (no error), then jumps
|
|
unconditionally into a block whose only exit is "report BadValue (2) and return
|
|
2". The export handler faithfully propagates that 2.
|
|
|
|
This is consistent with the terminal firmware's export-to-drawable being
|
|
unimplemented (or gated behind a precondition that is always false here), rather
|
|
than with any defect in the client, the request, the drawable, the GC, the depth
|
|
(1), the geometry, the photomap attributes or the imported data.
|
|
|
|
EVIDENCE ACCUMULATED ACROSS THE INVESTIGATION
|
|
import: element+0x28 = 0xFF white / 0x00 black ; QueryResource comp_COUNT=1
|
|
request: passes every check in DEC's portable server source
|
|
clients: hand-rolled AND DEC's own 2.3 client fail identically at this point
|
|
window: depth 1 (root is depth 1), drawable, and proven paintable by core X
|
|
|
|
STATUS. NO client-chosen XIE image has ever been displayed. xshow (core X) is
|
|
the only viewer that has shown one.
|