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).
114 lines
4.2 KiB
Plaintext
114 lines
4.2 KiB
Plaintext
XIE 2.3 resource creation / export probe (live, 192.168.99.2:0)
|
|
================================================================
|
|
|
|
Client: xie/probe23.py (raw X11, same connection for the whole sequence).
|
|
Each request is preceded by minor 1 (INIT_SESSION, declare 2.3).
|
|
|
|
Resource IDs
|
|
------------
|
|
The X setup reply gives a per-connection resource-id base and mask. One
|
|
observed connection:
|
|
|
|
id_base = 0x00C00000 id_mask = 0x000FFFFF
|
|
|
|
A legal XIE resource id is `base | (n & mask)`, and the slot-8 create handler
|
|
additionally rejects ids with bit 19 set:
|
|
|
|
rom:00067936 MOVE *A9(0x40),A11,0x1 ; request id (byte 8)
|
|
rom:0006793e ANDI -0x100000,A11 ; compare with client resource base
|
|
rom:00067950 BTST 0x13,A11 ; bit 19 must be clear
|
|
-> BadIDChoice (14) if either check fails
|
|
|
|
So `0xC0AAAA` is a usable id; `0xCAAAAA` is not.
|
|
|
|
Slot 8 op 2 creates a resource
|
|
------------------------------
|
|
Request is exactly 12 words:
|
|
|
|
word 0 (byte 4) op = 2
|
|
word 1 (byte 8) new resource id
|
|
word 2 (byte 12) param A (must be non-zero)
|
|
word 3 (byte 16) param B (must be non-zero)
|
|
bytes 42/43/44 8-bit fields (read as three SETF 8 fields)
|
|
|
|
Wire result:
|
|
|
|
slot 8 op=2, id=0xC0AAAA, A=64, B=64 -> NO PACKETS (success)
|
|
then slot 24 (query, id, 0, 0) -> REPLY, length 0
|
|
|
|
Slot 8 op 1 also succeeds, but the resulting resource answers query 24 with
|
|
BadAccess (code 10); its byte +0x29 is non-zero.
|
|
|
|
Slot 19 (PUT_TILE) on the created resource
|
|
------------------------------------------
|
|
Header used: {id, x, y, w, h, count, flags} + data.
|
|
Slot 19 hard-codes a lookup type of 3.
|
|
|
|
op-1 resource -> BadIDChoice (14) (not type 3 / not found)
|
|
op-2 resource -> BadAccess (10) (found, but the access flag is set)
|
|
|
|
Slot 21 (EXPORT) on the created resource
|
|
----------------------------------------
|
|
Request is exactly 16 words; id at byte 4, then parameters.
|
|
Both op-1 and op-2 resources return:
|
|
|
|
ERROR code=8 (BadMatch), bad=id, minor_op=21
|
|
|
|
The handler tests resource byte +0x28 bit 0 before anything else:
|
|
|
|
rom:00062d88 MOVE *A13(0x20),A11,1
|
|
rom:00062d8c SETF 1,0,0
|
|
rom:00062d8e MOVE *A11(0x28),A7,0
|
|
rom:00062d92 JRNE ok
|
|
-> SendError(code=8, bad=id)
|
|
|
|
So slot 8 create does not produce an exportable resource.
|
|
|
|
Tried without effect
|
|
--------------------
|
|
- all 8-bit create fields 0..3 in combination (64 combos per op):
|
|
export still BadMatch for every combination.
|
|
- slots 15/43/18 as post-create mutators: export still BadMatch.
|
|
- slot 7 op 1/2 with a core drawable (root 0x8006B) as the second id:
|
|
BadIDChoice on that id — slot 7 only looks up XIE photo resources.
|
|
|
|
Conclusion
|
|
----------
|
|
The create path for an *exportable* resource (the `+0x28` bit-0 object) is in
|
|
the photoflo/pipeline layer (slots 20/43 and the resource class codes), not in
|
|
slot 8. That layer is what GHIDRA_XIE_PIPELINE.md is recovering.
|
|
|
|
Update after GHIDRA_XIE_PIPELINE.md
|
|
-----------------------------------
|
|
The `+0x28` bit is **"level array defined"**, not a missing capability. The
|
|
create request's level word at byte 28 must be non-zero; `2` means 1 bpp:
|
|
|
|
create: op=2, id, w=64@12, h=64@16, level[0]=2@28
|
|
byte41=1 (one band), rest zero
|
|
-> NO PACKETS (success), query 24 answers (empty)
|
|
|
|
With that, slot 21 no longer returns BadMatch. The export sequence that
|
|
succeeds against the live server is:
|
|
|
|
create XIE resource (above)
|
|
core X CreateWindow 64x64 + MapWindow + CreateGC
|
|
slot 21, 16 words:
|
|
[id, window, gc, 0, 0, 64, 64, 64, 64, 0, 0, 0, 0, 0, 0]
|
|
-> NO PACKETS (success; window is mapped)
|
|
|
|
So the XIE create + export path works. The window is **empty** because pixel
|
|
import is still blocked:
|
|
|
|
slot 19 PUT_TILE, class-2 resource -> BadAccess (code 10)
|
|
slot 19 PUT_TILE, class-3 resource -> BadIDChoice (code 14)
|
|
band count 3 / three levels does not change either result
|
|
|
|
Slot 19 hard-codes lookup type 3; the class-2 resource is found but denied, the
|
|
class-3 resource is not found. The missing piece is the exact target/binding
|
|
for `PUT_TILE` (or the correct import request for the class-2 sink). That is
|
|
the only reason the exported window has no picture.
|
|
|
|
Reproducer: `./probe23.py export 5` creates and exports the resource; the
|
|
window is visible for 5 seconds.
|
|
|