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).
58 lines
3.2 KiB
Plaintext
58 lines
3.2 KiB
Plaintext
TURN RECORD: ops 4/5/6 DECODED (CREATE_BY_REFERENCE family), AND SLOT 20 IS THE
|
|
ELEMENT EXECUTOR.
|
|
|
|
A) ops 4/5/6 ARE LENGTH-KEYED (static, then confirmed on the wire)
|
|
Each routine opens with the same prologue and compares the REQUEST LENGTH:
|
|
op4 0x676CA: MOVE *A9(0x10) = length ; SUBK 0x6 ; -> must be 6 words
|
|
op5 0x67B46: SUBK 0x7 ; -> must be 7 words
|
|
op6 0x67DA8: SUBK 0x6 ; -> must be 6 words
|
|
Wire confirmation (asserting replies):
|
|
op=4 len=12 -> err16 (BadLength) <- wrong length rejected
|
|
op=4 len=6 -> not a length error
|
|
|
|
B) WITH THE RIGHT LENGTH THEY VALIDATE AN EXISTING ID AND CREATE NOTHING
|
|
Source = a real op=2 resource (SRC, byte36=0). New id = NEW (never used).
|
|
op=4 [NEW, SRC] -> silent arm(NEW) -> BadIDChoice(14) bad=NEW
|
|
op=4 [SRC, NEW] -> err14 bad=NEW (so w2 is the id it validates)
|
|
op=5 [NEW, SRC] -> err2 (BadValue)
|
|
op=5 [SRC, NEW] -> err2
|
|
op=6 [NEW, SRC] -> err14 bad=NEW
|
|
op=6 [SRC, NEW] -> silent arm(NEW) -> BadIDChoice(14) bad=NEW
|
|
In NO case does the REGIDSTORE breakpoint (0x67B04) fire, and the new id is
|
|
never resolvable afterwards. So these requests are accepted but produce no
|
|
registered resource -- the same "allocate without registering" behaviour seen
|
|
for the by-value path.
|
|
|
|
C) THE REFERENCE MUST BE AN XIE ID, NOT A CORE-X DRAWABLE
|
|
Passing a mapped core-X window (0x70D000) and its GC (0x70D100):
|
|
op=4 [NEW, window] -> silent, then queued errors
|
|
err14 bad=0070D000 (the window id)
|
|
err14 bad=0070D100 (the GC id)
|
|
So the routine does look up a DRAWABLE + GC pair by id -- the create-by-
|
|
reference signature -- but the server's lookup rejects core-X ids.
|
|
|
|
D) SLOT 20 (arm / execute) IS THE ELEMENT EXECUTOR -- it loops over elements
|
|
6AAE4 A7 = *A5(0xd8) ; element pointer for band index
|
|
6AAE8 JREQ 0x6AB46 ; no element -> A7 = 0
|
|
6AB0A A8 = *A7(0x1a8)
|
|
6AB0E CALLA 0x07FC22DE ; 6AB14 CALLA 0x07FC2C34 ; 6AB2A CALLA 0x07FC2C34
|
|
6AB30 CALLA 0x07FC1ACA ; 6AB36 CALLA 0x07FC288A ; 6AB3C CALLA 0x07FC216A
|
|
6AB48 MOVE A7,*A11(0x120) ; A11 = A13 + idx*0x20 -> PER-ELEMENT FRAME SLOT
|
|
6AB5C A11 = *A11(0x120) ; A7 = *A13(0x100) ; A11 += A7 ; store -> accumulator
|
|
6AB6E SUBK 0x3 ; JRC 0x6AACC ; loop over (up to) THREE elements
|
|
So arm walks up to three elements taken from the band array at +0xd8, runs a
|
|
chain of routines on each, and accumulates an output pointer. The element
|
|
pointers ARE populated by create (e.g. 0x3FD7D0), so arm has elements to run
|
|
-- but the element carries no process-block chain (nothing ever wrote one),
|
|
and src_base (rp+0x610) stays 0.
|
|
|
|
E) WHAT THIS SETTLES
|
|
* op 4/5/6 are not the missing "photomap with a band descriptor": they are
|
|
reference-based creation that registers nothing on this server.
|
|
* The import gate's object->byte36 is still never written by any request.
|
|
* The pipeline elements at band_array+0xd8 exist but are empty; nothing in the
|
|
tested request surface adds a process block to them.
|
|
|
|
STATUS. No client-chosen XIE image; src_base (rp+0x610) 0; window still the
|
|
stipple; xshow (core X) is the only viewer that has displayed an image.
|