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).
50 lines
2.4 KiB
Plaintext
50 lines
2.4 KiB
Plaintext
TWO ROUTES TESTED: slot 11 as a class-3 bind, and a second allocator for the
|
|
op-1 object. Both negative, with reasons.
|
|
|
|
1) SLOT 11 as bind. slot 11 requires exactly 3 words = 2 payload ids.
|
|
(0x667CE SUBK 0x3 ; JREQ). It performs TWO lookups (0x667EC and 0x66810,
|
|
both CALLA 0x7EA6FA0) before calling the bind helper.
|
|
|
|
Earlier attempts used a fresh id as the second operand, which was invalid.
|
|
This run used TWO EXISTING class-2 resources:
|
|
|
|
A=0040C000 id=0040C000 class=2 w=64 h=64 b36=00000000 b40=00000000
|
|
B=0040D000 id=0040D000 class=2 w=64 h=64 b36=00000000 b40=00000000
|
|
|
|
slot11 [A,B] -> ERR14 (BadIDChoice)
|
|
slot11 [B,A] -> ERR14 (BadIDChoice)
|
|
|
|
after: A unchanged, B unchanged (both still class 2, b40 = 0)
|
|
query A: REPLY query B: REPLY
|
|
put A: ERR10 put B: ERR10
|
|
|
|
So slot 11 rejects even two valid, queryable resources. The lookups it does
|
|
are typed: call #1 pushes the literal 0xffff, call #2 pushes 0
|
|
(0x667E2 SUB A7,A7 ; 0x667E4 MOVE A7,*A14+). Neither class-2 resource
|
|
satisfies those types, so slot 11 is not the class-3 bind: its operand types
|
|
are fixed by the handler and are not carried in the request.
|
|
|
|
2) SECOND ALLOCATOR for the op-1 object. If a second allocator registered the
|
|
class-3 object's id, the id would appear somewhere near it.
|
|
|
|
create op=1 C=0040E000 object=003FD110
|
|
id@0=00000000 class=3 w=64 h=64 b36=00000000 b40=00383950
|
|
ID 0040E000 found near the object: NOWHERE within +/-0x4000 (32 KiB
|
|
scanned in 0x400 blocks, centred on the object)
|
|
|
|
So the op-1 object is not registered anywhere near itself. Combined with the
|
|
earlier full-object scan (id absent from its first 0x100 bytes), the class-3
|
|
object carries no id at all, in any location found so far.
|
|
|
|
3) Side observation that constrains the next step: PUT_TILE's lookup is typed
|
|
too (slot 19 pushes MOVK 0x3 immediately before the lookup), and a
|
|
class-2 resource that is present and queryable still yields BadMatch. So the
|
|
gate is the lookup TYPE/CLASS match, not mere existence -- and the type is
|
|
carried inside the handler, not in the request fields tried so far.
|
|
|
|
NEXT LEVER (not yet tried): element+0x28 is the field export treats as the
|
|
source image (0x1B238 MOVE *A5(0x28),*A11(0x610)); it is 0 at export time.
|
|
A write watchpoint on element+0x28 across create/arm1/arm2 would show whether
|
|
any slot-20 field sets it (i.e. whether the source is supplied by EXECUTE
|
|
rather than by PUT_TILE).
|