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).
69 lines
3.7 KiB
Plaintext
69 lines
3.7 KiB
Plaintext
TURN RECORD: NO REQUEST WRITES THE ELEMENT RECORD, AND THE DEC XIE SERVER
|
|
DOCUMENT WAS FOUND (it confirms the missing request shape).
|
|
|
|
A) WATCHPOINTS ON THE ELEMENT RECORD -- ZERO WRITES FROM 33/40/43/44
|
|
Live write watchpoints (proven: stack control fired 3052 times) on
|
|
band_array+0xd8 and the whole element block (+0x800 bits), issuing:
|
|
slot33 [A,B,0] -> err2 elem_changed=False writes=0
|
|
slot40 [A,B,0] -> err2 elem_changed=False writes=0
|
|
slot44 [A,B,1,1] -> err2 elem_changed=False writes=0
|
|
slot43 len 3/5 -> err16 (BadLength)
|
|
Full slot sweep at each handler's REQUIRED length, watching the photoflo's
|
|
p44 block: no slot produced a pipeline element.
|
|
|
|
B) SLOT 43 IS THE ONE THAT REACHES THE RENDERER -- AND STOPS THERE
|
|
Slot 43 requires length EXACTLY 10 (0x65614: MOVE *A9(0x10) ; SUBK 0xa ;
|
|
JREQ). With len=10 and two valid ids:
|
|
reply: err2 (BadValue)
|
|
RP breakpoint at 0x1B296 FIRES: RP a11=00291AF0 src_base610=00000000
|
|
i.e. it enters the export/render driver, finds no elements, and returns
|
|
BadValue. src_base stays 0. TYPE1/TYPE2 (the element-type stores) never fire.
|
|
|
|
C) SLOT 18 REJECTS EVEN A PHOTOFLO
|
|
Slot 18 is the only large handler with a MINIMUM length (>=4) and it does
|
|
touch *A7(0xd8) and write element+0x20. Tested against a class-2 resource
|
|
and against a class-1 photoflo:
|
|
err10 (BadAccess) with bad = the resource id, in both cases.
|
|
So it finds the resource and refuses access; its accepted shape is unknown.
|
|
|
|
D) THE MISSING DOCUMENT WAS FOUND
|
|
xie/docs/dec/xieSIarch.txt (fetched from
|
|
https://ftp5.gwdg.de/pub/xfree86/XFree86/4.2.0/doc/xieSIarch.TXT)
|
|
147 occurrences of "photoflo" -- this is the DEC XIE Server Interpretation
|
|
architecture document, i.e. the right lineage (the X Consortium specs in
|
|
xie/docs/x11r4 have ZERO).
|
|
|
|
What it settles:
|
|
* XIE defines six resources: ColorList, LUT, Photoflo, Photomap,
|
|
Photospace, ROI.
|
|
* 7.2.3 Photomap: stores a complete image; populated by an ExportPhotomap
|
|
element; attributes inherited from that element.
|
|
* 7.2.6 Photoflo (flo-def): "the number of elements received from the
|
|
client" and "an array of pointers to client elements in PHOTOTAG ORDER",
|
|
plus a definition DAG and an optimized DAG.
|
|
* 7.3 Photo Element (pe-def): "the element phototag number received from
|
|
the client" and "the element TYPE received from the client"; class
|
|
Booleans import/process/export; input connections carry the phototag of
|
|
the source element.
|
|
* 8.3.3.1 ExecuteImmediate / 8.3.4.1 Create: "Create a flo-def, copy the
|
|
SUPPLIED LIST OF ELEMENTS to the flo-def while verifying that the list
|
|
is a DAG".
|
|
* 8.3.4.2 Modify replaces element PARAMETERS only; 8.3.4.3 Redefine
|
|
destroys and recreates under the same id.
|
|
|
|
So elements are NOT added one at a time by scale/crop/rotate requests: the
|
|
whole element list arrives in ONE photoflo create/redefine request, each
|
|
element carrying {phototag, type, params}, wired by phototag.
|
|
|
|
E) WHAT THIS MEANS FOR THE REMAINING WORK
|
|
The create path we drive (slot 8, op=1/2) checks only length >= 3 and has no
|
|
element loop, so it is not the photoflo-create request that carries elements.
|
|
The request that does carry them is still unidentified, and this document --
|
|
being a SERVER ARCHITECTURE description -- deliberately does not give the
|
|
wire encoding of that list (phototag/type/param field order), which is what
|
|
a request has to match.
|
|
|
|
STATUS. No client-chosen XIE image. src_base (rp+0x610) 0 in every run; the
|
|
window is unchanged from the no-export baseline; xshow (core X) is still the only
|
|
viewer that has displayed an image.
|