forked from arti/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).
40 lines
2.0 KiB
Plaintext
40 lines
2.0 KiB
Plaintext
CREATE OPCODE SWEEP -- all accepted ops tested; none yields an addressable
|
|
class-3 resource.
|
|
|
|
slot 8 (create) dispatch, file 0x668E4:
|
|
6696C DEC A8 ; JREQ 0x66912 op 1 -> 0x7EA78DA
|
|
66970 DEC A8 ; JREQ 0x66912 op 2 -> 0x7EA78DA (SAME routine as op 1)
|
|
66974 SUBK 2 ; JREQ 0x66902 op 4 -> 0x7EA76CA
|
|
66978 DEC ; JREQ 0x66922 op 5 -> 0x7EA7B46
|
|
6697C DEC ; JREQ 0x66932 op 6 -> 0x7EA7DA8
|
|
66980 JR 0x66942 anything else -> BadValue
|
|
|
|
Required lengths, read from each routine's own prologue:
|
|
op 1/2 -> exactly 12 words (0x678F8 SUBK 0xc)
|
|
op 4 -> exactly 6 words (0x676E2 SUBK 0x6 ; JREQ)
|
|
op 5 -> exactly 7 words (0x67B5E SUBK 0x7 ; JREQ)
|
|
op 6 -> >= 6 words (0x67DC0 SUBK 0x6 ; JRNC)
|
|
|
|
Measured (single instance, RESPTR breakpoint at 0x6CC0E as the create tell):
|
|
|
|
op=1 [1,ID,64,64,...] create OK RESPTR 1 query ERR14 put ERR14
|
|
op=2 [2,ID,64,64,...] create OK RESPTR 1 query REPLY put ERR10/ERR8
|
|
op=3 [3,...] ERR14 (BadIDChoice) RESPTR 0
|
|
op=4 [4,newID,existingID,0,0] create OK RESPTR 0 query ERR14 put ERR14
|
|
op=5 [5,ID,64,64,1,1] create OK RESPTR 0 query ERR14 put ERR14
|
|
op=6 [6,existingID,0,0,0] OK RESPTR 0 existing stays REPLY
|
|
|
|
Readings:
|
|
* op 4 and op 5 return OK but allocate NOTHING that the create tell sees, and
|
|
their ID is never addressable, so they are not creates -- both first act on
|
|
an existing resource (op 4 starts with a lookup of payload word 2 via
|
|
0x7EA6FA0 at 0x676FE; op 6 looks up payload word 1 via 0x7F174A4).
|
|
* op 6 leaves the existing resource intact and queryable, so it is not a
|
|
destroy either.
|
|
* op 3 is rejected outright.
|
|
* Only op 2 produces an addressable resource, and its class is 2.
|
|
|
|
Therefore the whole accepted create opcode space {1,2,4,5,6} has been tested and
|
|
none of it produces a class-3 resource that is registered by ID. This closes
|
|
the "try another create opcode" route to the PUT_TILE lookup.
|