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).
44 lines
2.3 KiB
Plaintext
44 lines
2.3 KiB
Plaintext
RENDER-DRIVER CALLER MAP, and why no element type is ever written.
|
|
|
|
My earlier ROM scans were wrong: CALLA stores the BIT address, not the file
|
|
offset (the decode of the slot-21 call site at file 0x63098 is
|
|
5f 0d 90 8a 2d 3f -> CALLA 0x3F2D8A90 = file 0x1B152
|
|
which is the form Ghidra mis-prints as "0x07e5b152"). Scanning for bit
|
|
addresses instead of file numbers yields the real caller list.
|
|
|
|
EVERY reference into the render-driver region targets the ENTRY 0x1B152:
|
|
|
|
caller file 06309A -> 0x1B152 (slot 21 = EXPORT)
|
|
caller file 065186 -> 0x1B152 (slot 33 body)
|
|
caller file 065550 -> 0x1B152 (slot 40 body)
|
|
caller file 065BFA -> 0x1B152 (slot 43)
|
|
caller file 065F54 -> 0x1B152 (slot 44)
|
|
|
|
No reference anywhere targets the per-element blocks (0x1B29A / 0x1B342 /
|
|
0x1B46A-entry / 0x1B4F4-entry / 0x1B582-entry). Those are therefore reachable
|
|
ONLY by control flow inside 0x1B152 itself.
|
|
|
|
Element-type stores, one per type, all the same instruction shape:
|
|
0x1B2B8/0x1B2BA MOVK 0x1,A11 ; MOVB *A11,*A5(0x58) type 1
|
|
0x1B360/0x1B362 MOVK 0x2,A11 ; MOVB *A11,*A5(0x58) type 2
|
|
0x1B46A/0x1B46C MOVK 0x3,A11 ; MOVB *A11,*A5(0x58) type 3
|
|
0x1B4F4/0x1B4F6 MOVK 0x4,A11 ; MOVB *A11,*A5(0x58) type 4
|
|
0x1B582/0x1B584 MOVK 0x5,A11 ; MOVB *A11,*A5(0x58) type 5
|
|
|
|
CONSEQUENCE (structural): the CLIENT does not select an element type by calling
|
|
these blocks -- there is no such call. The type is chosen inside 0x1B152 from
|
|
whatever pipeline/band data it is given. Since our band element record is
|
|
uninitialised (word1 = 0x00000055 heap fill) and no TYPE store ever fires, the
|
|
server finds no elements to add: the pipeline is empty because the band
|
|
descriptor is empty, not because an element request is missing.
|
|
|
|
Five requests can drive the renderer: slots 21, 33, 40, 43, 44. Slots 33/40/44
|
|
are the bind-family handlers that call both the resource lookup (0x7EA6FA0) and
|
|
the bind helper (0x7EA72A4); their operand requirements are what I have not been
|
|
able to satisfy (they reject with BadValue/BadIDChoice before reaching the
|
|
renderer).
|
|
|
|
NET: the missing capability is still the 2.3 encoding of the pipeline/band
|
|
descriptor that these five requests carry. The call-graph is now fully mapped,
|
|
which is real structure, but it does not by itself yield a working request.
|