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).
61 lines
3.0 KiB
Plaintext
61 lines
3.0 KiB
Plaintext
WHAT EXPORT ACTUALLY HAS -- render-params map, and the one missing field.
|
|
|
|
Breakpoint after the export copy block (0x1B296, file) prints the values the
|
|
driver just wrote into the render-params block:
|
|
|
|
RP 5a8=0040C000 5d0=00000040 5f0=00000040 610=00000000
|
|
6f8=00000000 718=00000000 738=00000040 758=00000040
|
|
|
|
Named against the firmware's own dump format strings (file 0x1C8B6..0x1CA79,
|
|
which print in this order: floID, flo, active, crop, scale, rotate, mirror,
|
|
export, func_count, src_img[][PWIDTH/PHEIGHT], dst_img[][PWIDTH/PHEIGHT],
|
|
src_res_id, src_delete, src_base, src_width, src_height, comp format, pGC,
|
|
pDraw, drw_x, drw_y, PxlsPerScn, NumOfScns, src_x, src_y, src_w, src_h,
|
|
rot_indx, x_mirror, y_mirror):
|
|
|
|
rp+0x5a8 = 0x0040C000 src_res_id -> OUR RESOURCE, correctly resolved
|
|
rp+0x5d0 = 64 src_width
|
|
rp+0x5f0 = 64 src_height
|
|
rp+0x610 = 0 src_base <-- the pixel buffer: MISSING
|
|
rp+0x738 = 64 dst_img PWIDTH
|
|
rp+0x758 = 64 dst_img PHEIGHT
|
|
rp+0x6f8 / 0x718 = 0 (pipeline intermediate width/height, unused with no
|
|
crop/scale element)
|
|
|
|
So EXPORT is not failing to find the resource: it resolves the source resource
|
|
id and its 64x64 size correctly. The only empty field is src_base, which is
|
|
loaded at 0x1B238 as `MOVE *A5(0x28),*A11(0x610)` -- i.e. element+0x28, which
|
|
we measured as 0 (evidence/element_pointer_timing.txt), and which no write
|
|
watchpoint ever saw being written.
|
|
|
|
CONCLUSION: the single missing datum is a pixel buffer base for the source
|
|
image (src_base / element+0x28). The only request that would produce it is the
|
|
import (slot 19 PUT_TILE), which cannot enter because its typed lookup
|
|
requests class 3 and no addressable class-3 resource is producible.
|
|
|
|
Band array (*(res+44) = 0x003DC4B0) dumped immediately before EXPORT:
|
|
|
|
+000: 00000000 00000000 00050029 40002005
|
|
+010: 00000000 00050029 40002005 48000000
|
|
+020: 00050029 40002005 48000000 48003DC5
|
|
+030: 40002005 48000000 48003DC5 10003DC5
|
|
+040: 48000000 48003DC5 10003DC5 00004007
|
|
+050: 48003DC5 10003DC5 00004007 00000000
|
|
+060: 10003DC5 00004007 00000000 18000000
|
|
+070: 00004007 00000000 18000000 3FB90900
|
|
|
|
Note element+0x28 is NOT at band_array+0xd8 (that read yields 0x40 etc.); the
|
|
element pointer EXPORT uses is reached after the 0x1B230 `MOVE *A5(0x160)`
|
|
deref chain, so the earlier "element = *(res+44 + 0xd8)" shortcut was wrong.
|
|
The authoritative element pointer is the one EXPORT loads at 0x1B234
|
|
(EX_BAND a5=003DC4B0 elem@d8=003FDA10).
|
|
|
|
SIDE FINDING -- slot 47 is a dispatch trampoline, not a request:
|
|
file 0x697B4 swaps the bytes of request words at bit offsets 0x10/0x18 then
|
|
0x20/0x28 then 0x30/0x38, then does
|
|
MOVE *A10(0x8),A11 (byte 1 = minor) ; SLL 5 ; ADDI 0xd3f90 ;
|
|
MOVE *A11,A11 ; CALL A11
|
|
i.e. it re-dispatches through the SAME table at 0xD3F90 after byte-swapping
|
|
the first argument words. It is the byte-swapped entry point for other
|
|
requests, which is why a plain 3-word probe of minor 47 returned BadRequest.
|