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.2 KiB
Plaintext
44 lines
2.2 KiB
Plaintext
IMPORT PATH RE-VALIDATED WITH THE TRUSTWORTHY HARNESS. A long-standing model is
|
|
OVERTURNED.
|
|
|
|
Two trials, one connection each, every reply read and asserted, raw bytes shown.
|
|
|
|
trial 1 (white tile) trial 2 (black tile)
|
|
SET_OP_DEFAULTS ack REPLY 01 41 03 00 ... ack REPLY 01 00 03 00 ... (detail differs)
|
|
create 00401000 SILENT(ok) SILENT(ok)
|
|
obj 003FDA10 003FD110
|
|
byte8=1 byte9=1 class=2 byte8=1 byte9=1 class=2
|
|
p44 / elem set, populated set, populated
|
|
arm1 SILENT(ok) SILENT(ok)
|
|
PUT_TILE ERROR 8 ERROR 8
|
|
arm2 ERROR 8 ERROR 8
|
|
EXPORT SILENT(ok) SILENT(ok)
|
|
GATE (0x6BAF4) hits during put: NONE NONE
|
|
RP line a11=00923CB0 src_base610=00000000 a11=009240F0 src_base610=00000000
|
|
byte8 after all 1 1
|
|
QUERY_EXPORT REPLY 01 00 0c 00 04 00 00 00 REPLY 01 00 0c 00 04 00 00 00
|
|
|
|
THE OVERTURNED MODEL:
|
|
I have been reporting since the middle of this session that
|
|
arm requires object->byte8 == 1 (0x6ACBE)
|
|
import requires object->byte8 == 3 (0x6BAF4)
|
|
and that PUT_TILE fails AT that gate.
|
|
|
|
With a harness that actually asserts replies, the gate at 0x6BAF4 is NEVER
|
|
REACHED during PUT_TILE -- zero hits in both trials. So PUT_TILE's BadMatch is
|
|
produced somewhere else entirely, and the entire byte8/gate story (including
|
|
the w9=0x300 experiments) was built on data from the stale-reply era.
|
|
|
|
Also newly verified in this run:
|
|
* arm2 (slot 20, v16=0) returns BadMatch(8) -- it is NOT silent/OK as reported
|
|
earlier;
|
|
* EXPORT is silent(ok) even when PUT_TILE and arm2 both failed;
|
|
* QUERY_EXPORT replies `01 00 0c 00 04 00 00 00` identically in both trials
|
|
(this is its real reply; the 4-word payload follows in the head);
|
|
* src_base (rp+0x610) is 0 in both trials, read at the in-export breakpoint.
|
|
|
|
CONSEQUENCE: the import failure must be re-located from scratch. The next step is
|
|
NOT the byte8 gate. Candidates, now that replies are trustworthy: the lookup at
|
|
0x7EAB966 returning 8, or a check in slot 19 before/after it. S19LOOK-style
|
|
breakpoints must be re-run under this harness.
|