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).
49 lines
2.7 KiB
Plaintext
49 lines
2.7 KiB
Plaintext
TURN RECORD: WHERE EXPORT'S BadValue COMES FROM, AND WHY IT IS NOT THE FLOATS.
|
|
|
|
A) EXACT REJECTION SITES IN THE EXPORT HANDLER (server, file 0x62D40)
|
|
BadValue (MOVK 0x2) is emitted at 0x62DCA, 0x62E06 and 0x62E3E, each preceded
|
|
by a comparison of a request word against a field of a looked-up object:
|
|
|
|
0x62DBC A7 = *A9(0x80) ; a request word (16 bytes into the data)
|
|
A11 = *A11(0x80) ; the same offset in the looked-up object
|
|
CMP A11,A7 ; JRC 0x62DF4 else BadValue
|
|
0x62DF8 A7 = *A9(0xa0) / A11 = *A11(0xa0) ; CMP ; JRC else BadValue
|
|
0x62E30 A11 = *A9(0xc0) ; JREQ 0x62E3C ; word == 0
|
|
A11 = *A9(0xe0) ; JRNE 0x62E68 ; and the next word == 0
|
|
else BadValue
|
|
So the rejection is a RANGE/COMPATIBILITY comparison between export operands
|
|
and the resource's own attributes -- not a decode failure.
|
|
|
|
B) THE XieFloatRec HYPOTHESIS IS DEAD
|
|
Sent match_limit and gray_limit as properly encoded 1.0
|
|
(e_sign=0, m_sign=0, exponent=1, mantissa=0x80000000 -> words
|
|
0x00010000,0x80000000) and as 0.0, full 15 data words, everything else
|
|
identical:
|
|
match/gray = 1.0/1.0 -> export err2, src_base 00000000, RP/TYPE5
|
|
match/gray = 0/0 -> export err2, src_base 00000000, RP/TYPE5
|
|
Identical. The floats are not the cause.
|
|
|
|
C) WHY THE LIBRARY WOULD NOT HAVE HELPED EITHER
|
|
The 2.3 client library on disk is MIPS (osf1-2.0-decstation/libXie.a) and
|
|
Alpha (osf1-1.2-alpha/libXie.a). It builds requests by filling the very
|
|
structs already read out of XieProto.h (photo_id, drawable_id, gc_id, src_x,
|
|
src_y, width, height, dst_x, dst_y, photo_lut_id, colormap_id, then the two
|
|
XieFloatRecs), so disassembling it cannot change the byte layout -- only
|
|
confirm it. The failing comparison is server-side range checking, which the
|
|
library does not encode.
|
|
|
|
D) STATE OF THE TWO PATHS (unchanged, re-measured this turn)
|
|
unbound photomap: transport ok, puttile ok, export err2, renderer entered
|
|
(RP + TYPE5) with src_base = 00000000
|
|
bound photomap : bind ok, export err1 x6, execute err1 x6, no renderer trace
|
|
|
|
STATUS. Still NO client-chosen XIE image. The window is unchanged by XIE;
|
|
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.
|
|
|
|
NEXT, concretely: identify which object the export handler looks up at 0x62DBC
|
|
(it is not obviously the photomap) and which of its fields at 0x80/0xa0/0xc0/0xe0
|
|
is being compared, then set the export operands inside those ranges. That is a
|
|
register/field identification in one handler, not a protocol question.
|