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).
54 lines
2.6 KiB
Plaintext
54 lines
2.6 KiB
Plaintext
TURN RECORD: THE src_base CHAIN IS FULLY IDENTIFIED, AND THE IMPORT DOES PRODUCE A
|
|
SOURCE -- BUT THE TRANSPORT ORGANIZATION DECIDES WHETHER IT SURVIVES.
|
|
|
|
A) WHERE src_base COMES FROM (static)
|
|
0x1B238 MOVE *A5(0x28),*A11(0x610)
|
|
i.e. rp+0x610 = *(element + 0x28 bits). Measured at that store during a
|
|
working export:
|
|
SRCBASE_ST a5=003FD590 elem28=00000000 rp=009261D0
|
|
RP a11=009261D0 src_base610=00000000
|
|
So the renderer reads the source pointer straight out of the band element.
|
|
|
|
B) THE IMPORT **DOES** WRITE IT
|
|
Instrumented slot 19 during a successful PutTile (mode=3):
|
|
S896 plane_mask=00000001
|
|
S8A0 bit0test
|
|
S8A4_import_loop
|
|
S98E_ELEM28_STORE val=00982B70 <-- element+0x28 written
|
|
S9A2_handoff_call
|
|
H_ENTRY
|
|
SAA28_skip_exit
|
|
and then element+0x28 = 00000000 again. The handoff clears it at
|
|
0x6B8D6 (`SUB A9,A9 ; MOVE A9,*A11(0x28)`) on the path it takes there.
|
|
|
|
C) THE HANDOFF'S PATH IS CHOSEN BY component_organization
|
|
The handoff dispatches on (*(byte36))[1] (0x6B83A, bit offset 8 = BYTE 1).
|
|
byte36 is the transport context, and its byte 1 = component_organization.
|
|
Measured, after SetTransport(mode=3) + PutTile:
|
|
org=1 transport ok puttile ok elem+0x28 = 0098CAB0 (SURVIVES)
|
|
org=3 transport ok puttile ok elem+0x28 = 0098CAB0 (SURVIVES)
|
|
org=4 transport ok puttile ok elem+0x28 = 00000000 (CLEARED)
|
|
org=2 transport BadMatch puttile BadAccess
|
|
So XieK_BitByPlane (4) -- the value I had been using -- is exactly the one that
|
|
makes the handoff clear the source pointer.
|
|
|
|
D) BUT WITH org=1/3 THE EXPORT FAILS EARLIER
|
|
org=1 or 3 with plane_mask=1: elem+0x28 = 0098DB10 (non-zero), then
|
|
export -> err2 and the renderer breakpoint (RP 0x1B296) NEVER fires,
|
|
i.e. the export handler rejects before reaching the render driver.
|
|
org=4: elem+0x28 = 0, export -> err2, RP fires with src_base 0.
|
|
So the two halves of the failure are complementary: the setting that keeps a
|
|
source also breaks the export request path, and vice versa.
|
|
|
|
E) ALSO MEASURED
|
|
plane_mask must be 1; 0xFFFFFF fails the transport (BadMatch) and PutTile
|
|
(BadAccess) for both org=1 and org=3.
|
|
|
|
STATUS. NO client-chosen XIE image. The 64x64 window is unchanged; src_base has
|
|
never been observed non-zero at the renderer.
|
|
|
|
This is the most precise statement of the wall so far: the import produces a real
|
|
source buffer (0098CAB0 / 0098DB10) inside the element, and the only thing that
|
|
destroys it is the handoff branch selected by component_organization -- while the
|
|
value that preserves it also makes Export bail out before the renderer.
|