Files
vt1200/harness/mame/xie_trace.lua
T
arti d8d54bb990 feat(xie): a client-chosen XIE image is displayed on the VT1200
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).
2026-11-01 23:22:25 +02:00

81 lines
2.8 KiB
Lua

-- xie_trace.lua -- capture XIE 2.3 request buffers as they reach the server.
--
-- The breakpoint sits INSIDE XieProc, immediately after it loads
-- A9 = client->requestBuffer (0x64BA2) and before it reads stuff->opcode,
-- i.e. at Ghidra 0x64BA8 = bit 0x3F525D40. At that point A9 is the request
-- buffer pointer, so the whole request can be read with w@ (16-bit words, which
-- is the CPU's native access width on this bit-addressed space).
--
-- M=/home/arti/code/k-space/mame0289/vt1200
-- XIE_FRAMES=1500 $M vt1200 -rompath harness/mame/roms -video none -sound none \
-- -nothrottle -debug -debugger none \
-- -autoboot_script harness/mame/xie_trace.lua -autoboot_delay 0
--
-- Env:
-- XIE_FRAMES frame budget (default 1500)
-- XIE_WORDS request words dumped per hit (default 8 = 16 bytes)
-- XIE_JIT if set, jump to this bit address at XIE_AT (debugger entry)
-- XIE_AT frame at which XIE_JIT is taken (default 400)
local function hex(v, w) return string.format("%0" .. (w or 8) .. "X", v) end
local machine = manager.machine
local cpu = machine.devices[':maincpu']
local dbg = machine.debugger
if not dbg then
print("XIE ERROR: debugger not enabled; pass -debug")
machine:exit()
return
end
local FRAMES = tonumber(os.getenv("XIE_FRAMES") or "1500")
local WORDS = tonumber(os.getenv("XIE_WORDS") or "8")
local JIT = os.getenv("XIE_JIT")
local AT = tonumber(os.getenv("XIE_AT") or "400")
local IDLE = 0x3FDCE400 -- level-0 diagnostics menu idle loop
-- XieProc interior: A9 = request buffer. XIE_TRACE overrides it, which is only
-- useful as a control: point it at a hot PC (e.g. the menu idle 3FDCE400) and
-- confirm the breakpoint+printf machinery actually fires.
local TRACE = tonumber(os.getenv("XIE_TRACE") or "0x3F525D40")
-- XieProc entry (count only)
local ENTRY = 0x3F525CC0
local action
if WORDS == 0 then
-- control mode: prove the breakpoint fires at all
action = '{ printf "XIEHIT pc=%08X\\n", pc ; g }'
else
local args = {}
for i = 0, WORDS - 1 do
args[#args + 1] = string.format("w@(a9+%d)", i * 16)
end
local fmt = "XIEHIT buf=%08X"
for i = 0, WORDS - 1 do fmt = fmt .. " %04X" end
fmt = fmt .. "\\n"
action = string.format('{ printf "%s", a9, %s ; g }', fmt, table.concat(args, ", "))
end
dbg:command("bpset " .. hex(TRACE) .. ",," .. action)
print("XIE: breakpoint at " .. hex(TRACE) .. " -> " .. action)
if JIT then
dbg:command("bpset " .. hex(IDLE) .. ",,{ pc = " .. JIT .. " ; g }")
print("XIE: entry jump armed at " .. hex(IDLE) .. " -> " .. JIT)
end
local frames = 0
emu.register_frame_done(function()
frames = frames + 1
if frames % 100 == 0 then
print(string.format("XIE: frame %d pc=%s", frames, hex(cpu.state['PC'].value)))
end
if frames >= FRAMES then
print("XIE: done at frame " .. frames)
machine:exit()
end
end, "vt1200-xie-trace")
dbg.visible_cpu = cpu
dbg.execution_state = 'run'