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).
37 lines
1.7 KiB
Plaintext
37 lines
1.7 KiB
Plaintext
BAND / ELEMENT STRUCTURE DUMPED, BEFORE AND AFTER A BIND ATTEMPT.
|
|
|
|
Setup: valid c.new_id ids; object pointers taken from the REGIDSTORE breakpoint
|
|
(fix: the log line starts "REGIDSTORE", not "IDSTORE" -- my earlier anchored
|
|
grep silently matched nothing).
|
|
|
|
IMG = 00403000 -> obj 003FD110 class=2 b8=1 b9=1 p44=003DC4B0
|
|
FLO = 00404000 -> obj 00382B90 class=1 b8=0x80 b9=0x32 p44=00386510
|
|
|
|
The IMAGE resource ALREADY has an element pointer at band_array+0xd8, before any
|
|
bind:
|
|
|
|
band[] at 003DC4B0: 00000000 00000000 00050029 40002005 48000000 48003DC5
|
|
elem = *(003DC4B0 + 0xd8) = 003FD7D0
|
|
elem[]: 01050001 00000002 00100000 00000100 00004000 00000000
|
|
|
|
(0x01050001 as bytes = 01 00 05 01; then 2; then 0x00100000; then 0x100 = 256;
|
|
then 0x4000 = 16384. 256 and 16384 are plausibly pitch/geometry values.)
|
|
|
|
The PHOTOflo (class 1) has no element (*(p44+0xd8) reads 0x55555555, the heap
|
|
fill), and its band array is two pointers: 00382CD0 00382F50.
|
|
|
|
BIND attempts:
|
|
slot 11 [img,flo] -> BadIDChoice(14)
|
|
slot 11 [flo,img] -> BadIDChoice(14)
|
|
(both orders rejected here, although the previous turn recorded a REPLY for
|
|
the same request shape -- that difference was not explained)
|
|
|
|
Effect on the photoflo: its p44 changed 00386510 -> 00382E10 and its band array
|
|
became 00382CD0 00386510 ... , i.e. the bind DID touch the photoflo even though
|
|
the request reported an error. The image resource was unchanged.
|
|
|
|
NOT RESOLVED: what the element record's field layout is (its first word 0x01050001
|
|
does not decompose into a recognisable type/flag pair), what the bind is meant to
|
|
write, or how the element chain is meant to be constructed. Without the 2.3
|
|
element encoding these dumps cannot be turned into a conforming pipeline.
|