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
TURN RECORD: WITH org=1 THE EXPORT DIES AT A FOURTH BadValue SITE, AFTER ALL THE
|
|
CHECKS I HAD BEEN INSTRUMENTING.
|
|
|
|
A) org=1 RE-RUN OF THE EXPORT HANDLER (full working sequence, elem+0x28=002909B0)
|
|
EX_LK ret=00000000 obj=003FD7D0 ; lookup OK
|
|
EX_F5 f5=01000101 ; byte5 != 0, BadMatch route skipped
|
|
EX_CK1 req=00000000 obj=00000040 ; src_x < width -> pass
|
|
EX_CK2 req=00000000 obj=00000040 ; src_y < height -> pass
|
|
EX_CK3 c0=00000040 e0=00000040 ; w,h non-zero -> pass
|
|
and NONE of EX_BADVALUE_1/2/3 fired.
|
|
Export still returns err2 and RP (0x1B296) never fires.
|
|
|
|
B) THE SITE THAT ACTUALLY REJECTS
|
|
slot21 listing, 0x62F0E:
|
|
0x62F0E A5 = *A13(0xa0)
|
|
0x62F12 JRLE 0x62F18 ; A5 <= 0 -> BadValue
|
|
0x62F14 A8 = A7
|
|
0x62F16 JRGT 0x62F40 ; A7 > 0 -> continue to the render
|
|
0x62F18..0x62F1A MOVK 0x2,A5 -> BadValue
|
|
where A7 is computed just above as a difference between a request field and a
|
|
looked-up object field (0x62EFA: A7 = obj->0xa0 - frame[0x80];
|
|
0x62F06: A7 = frame[0xc0]), i.e. a remaining-extent/clip computation.
|
|
|
|
C) TESTED EVERY GEOMETRY AT org=1 -- ALL REJECT IDENTICALLY
|
|
32x32, 63x63, 1x1, 64x32, 32x64 -> err2, and the trace always stops right
|
|
after EX_CK3, never reaching the render driver.
|
|
So the value tested at 0x62F12 is <= 0 no matter what source rectangle I ask
|
|
for, which points at a failing comparison against a looked-up object field
|
|
rather than at my width/height.
|
|
|
|
FINAL STATE
|
|
* Import half: complete, client-driven, verified by QueryResource.
|
|
* Export request: all instrumented checks pass; the handler rejects later, in a
|
|
remaining-extent computation, before the render driver.
|
|
* With org=4 the renderer IS reached but element+0x28 was cleared by the
|
|
handoff, so src_base is 0; with org=1/3 element+0x28 survives but export
|
|
never reaches the renderer.
|
|
* src_base (rp+0x610) has never been non-zero.
|
|
|
|
STATUS. NO client-chosen XIE image. The 64x64 window is unchanged in every
|
|
run; solid-white and solid-black captures differ only by the Terminal Manager's
|
|
own figures and the cursor; xshow (core X) remains the only viewer that has
|
|
displayed an image.
|