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).
49 lines
2.5 KiB
Plaintext
49 lines
2.5 KiB
Plaintext
THE REPLY MODEL WAS WRONG. This is the most consequential correction of the
|
|
session and it explains the ERR8/ERR10/ERR14 inconsistencies and several
|
|
retractions.
|
|
|
|
1) SUCCESSFUL create AND arm SEND NO PACKET AT ALL.
|
|
Measured with a strict one-request-per-read probe on valid ids:
|
|
create -> (no packet) and the resource really is created
|
|
arm -> (no packet) when it succeeds
|
|
put -> BadMatch packet when it fails
|
|
Only ERRORS produce a packet. So "no-reply" in earlier runs meant SUCCESS,
|
|
not a lost reply, and my reader was silently consuming nothing.
|
|
|
|
2) HARDCODED IDS ARE INVALID. The client id base differs per connection
|
|
(0x004xxxxx, 0x005xxxxx, 0x006xxxxx were all observed). Every request using
|
|
a literal id such as 0x0047xxxx or 0x0048xxxx was rejected:
|
|
create id=0x00470001 -> BadIDChoice
|
|
create id=0x00470002 -> BadIDChoice
|
|
create id=0x00470100 -> BadIDChoice
|
|
create id=0x00480002 -> BadIDChoice (also has bit 19 set)
|
|
while c.new_id(...) works. Consequences: many sequences in earlier turns
|
|
created NOTHING and then "measured" arm/put against a non-existent resource;
|
|
the ERR14 results and several contradictions come from this.
|
|
|
|
3) ERROR PACKET LAYOUT (from a raw hexdump, no parsing assumptions):
|
|
type=0 | error_code | sequence | bad_value | minor | major=0x81
|
|
e.g. 00 0e 03 00 | 02 10 47 00 | 08 00 81 00 -> code 14, minor 8 (create)
|
|
So the error vocabulary in the tooling was correct; the ATTRIBUTION was not,
|
|
because with several requests outstanding the first packet read may belong to
|
|
an earlier request.
|
|
|
|
RE-VERIFIED WITH THE CORRECT MODEL (valid ids, one request per read):
|
|
|
|
w9=0x100 (byte8=1): create silent OK, arm silent OK, put = BadMatch
|
|
w9=0x300 (byte8=3): create silent OK, arm = BadMatch, put = BadMatch
|
|
|
|
and on the arm path the shared lookup still SUCCEEDS in both cases:
|
|
|
|
w9=0x100 : H_STORE -> K -> L(a7=FFFFFFFF) -> N(jrlt) -> P_6BBE2_SUCCESS
|
|
w9=0x300 : H_STORE -> K -> L(a7=FFFFFFFF) -> N(jrlt) -> P_6BBE2_SUCCESS
|
|
|
|
So for arm the lookup returns 0 in both cases and the BadMatch with byte8=3 is
|
|
produced later, in slot 20's body. Instrumenting slot 20's four MOVK 0x8 sites
|
|
(0x6ABD2, 0x6AC5C, 0x6AC96, 0x6ACD4) with valid ids: NONE of them fires.
|
|
|
|
NEXT: find the callee in slot 20's post-lookup body that returns 8 -- candidates
|
|
are the DD dispatcher 0x7E80008 and the per-element helpers -- now that valid ids
|
|
and the no-reply model are in place. Every earlier measurement that used a
|
|
literal id must be considered void until re-run.
|