GXT120P (Matrox Mystique) 3D engine on obsidian - prediction log. Author: Claude Opus 5.5 (claude-opus-5-5). Series letter: G. Written after seeing lsdev/lscfg/ODM for mga0 and the import lists and version strings of mgadd and loadddx, BEFORE reading the RCM headers, checking video memory or disassembling anything. Format: ID [confidence] claim. See ../../PREDICTIONS-GUIDE.md. --- round 1 --- G01 [0.60] The card has 2 MB of video memory (not 4 or 8). G02 [0.55] The X server on :0 runs at a default depth of 8 bits. G03 [0.70] sys/aixgsc.h defines a MAKE_GP command for aixgsc(). G04 [0.45] No ODM attribute of mga0 (CuAt/PdAt) states the video memory size. G05 [0.65] There is no /dev/mga0 device file; user programs reach the card only through the LFT/RCM path. G06 [0.30] loadddx contains code that writes the drawing engine's DWGCTL register (MGA control aperture offset 0x1C00), i.e. IBM used the engine for 2D. Tue Oct 13 10:06:16 PM MDT 2026 === OUTCOMES (round 1, scored 2026-10-13, partly) === G01 HIT [0.60] ict's photo (2026-10-13): two NEC D481850GF-A10 SGRAMs (8 Mbit, x32) = 2 MB; upgrade connector empty. Nothing on the box reports it: no ODM attribute, no driver string, no X log line. G02 UNPROVEN [0.55] X starts with no -d option (/usr/dt/config/Xservers -> xserverrc); xdpyinfo on :0 needs the root-owned auth file. G03 HIT [0.70] /usr/include/sys/aixgsc.h:51 "#define MAKE_GP (GSCIO | 1)", used via ioctl(fd, HFHANDLE, &gsc_handle). G04 HIT [0.45] CuAt/PdAt for mga0 have bus_mem_start (0xfa000000, width 0x2000000) and display modes, no memory size. G05 HIT [0.65] no /dev/mga*; /dev/lft0 (root 0600) and /dev/rcm0 (0666) are the way in. G06 HIT [0.30] scan.py over loadddx's .text: 21 stores at 0x1c00 (DWGCTL) plus 25 at 0x1d00 (DWGCTL+GO), 56 FCOL, clip registers, XYSTRT/XYEND+GO (blits). Heuristic (displacement match), but the cluster is unmistakable. IBM's X driver does use the engine for 2D. No stores to DR0-DR15, ZORG or the 0x2Cxx texture registers. Not predicted: the chip is an MGA-1164SG-A (Mystique 220), not the 1064SG the PCI ID suggested. 75 accesses to OPMODE (0x1e54), mostly byte loads: that's where the bus byte-swapping lives. The X server isn't started with -x GLX on this adapter. --- round 2, after decoding loadddx's sb_ScreenInit (MAKE_GP with access 3|4, one range, pData 32 bytes; pData+0x14 compared with 0x2b101a05; registers at BaseAddr, framebuffer at BaseAddr+8 MB) and finding aixgsc in /usr/lib/rcm.exp. Before running anything. --- G07 [0.85] A program built with -bI:/usr/lib/rcm.exp links and the GSC_HANDLE ioctl on /dev/rcm0 (as claude, not on the console, X running) succeeds. G08 [0.75] MAKE_GP from that ssh session, with X holding the card, fails with an error (no hang, X keeps running). G09 [0.60] The word at pData+0x14 that MAKE_GP returns is 0x2b101a05 (the device id) when it succeeds. G10 [0.50] Reading STATUS (0x1e14) as a big-endian word gives a value whose engine-busy bit isn't where the little-endian docs put it (bit 16), i.e. the registers are byte-swapped. Tue Oct 13 10:55:59 PM MDT 2026 === OUTCOMES (round 2, scored 2026-10-13) === G07 PARTIAL [0.85] links with -bI:/usr/lib/rcm.exp; GSC_HANDLE as claude over ssh fails with EBUSY (16) while X runs, succeeds (handle 0x85011023) once ict stopped dtlogin. G08 PARTIAL [0.75] it failed harmlessly with X up, but one step earlier: GSC_HANDLE itself, so MAKE_GP was never tried. G09 HIT [0.60] pData[5] = 0x2b101a05. G10 MISS [0.50] FIFOSTATUS reads 0x00000220 (32 free, BEMPTY bit 9) and STATUS 0x00020024 (DWGENGSTS bit 16 clear): the doc's bit positions, read as plain big-endian words. The card swaps for us. Bytes too: the drivers use stb 0x3c00 / 0x3c0a at the documented addresses. Not predicted: no console or root needed at all: an ssh session can become the graphics process. pData is {250, 330, 1024, 1280, 60, 0x2b101a05, 3, 0} = screen mm h/w, height, width, refresh, device id, PCI revision 3 (the 1164SG); mapped at 0x30000000, length 32 MB. MACCESS/PITCH/YDSTORG read 0xffffffff (write-only). --- round 3, X still stopped, before writing anything to the card --- G11 [0.80] The framebuffer at base+8 MB holds the LFT console at 1280x1024x8: a dump shows readable text. G12 [0.65] Palette entry 0 is black and the console's pixels use at most 16 distinct indices. G13 [0.75] A 2D solid fill (TRAP|SOLID|ARZERO|SGNZERO|SHIFTZERO, BOP copy) with PITCH/YDSTORG/clip set by me shows up in readback, right place, right colour, on the first try. G14 [0.55] With MACCESS set to 16 bpp and PITCH 640 (the CRTC never told), Gouraud (atype I) triangles render a smooth 5:6:5 gradient into VRAM that reads back correctly. G15 [0.40] Z-buffered drawing (atype ZI/I with ZLT) occludes correctly on the first attempt. G16 [0.35] A rotating Z-buffered Gouraud object, 640x480x16, renders at >= 15 frames/s on the engine (draw time only, no readback). Tue Oct 13 11:04:00 PM MDT 2026 === OUTCOMES (round 3, scored 2026-10-13) === G11 MISS [0.80] the framebuffer is at base+8 MB and is 1280x1024x8, but there was no text to read: the LFT screen was blank except a 16-pixel cursor line (row 74, x 0-7 and again at x 640-647). G12 PARTIAL [0.65] only 2 indices in use (0 and 2), but entry 0 is (64,64,64), mga0's ksr_color1 0x00404040, not black. G13 HIT [0.75] both fills read back at exactly (100,100)-(299,199) and (120,300)-(152,306), right indices. G14 HIT [0.55] x-only red and y-only green ramps read back as 0,16,32..248 every 16 pixels; RGB triangle smooth. G15 HIT [0.40] two triangles crossing in depth: the visible boundary is at y=228, computed crossing y=227.3. G16 HIT [0.35] torus, ~700 Z-buffered Gouraud triangles/frame at 640x480x16: median 19.6 ms/frame = 51 fps. Not predicted: the framebuffer aperture is NOT byte-swapped (16-bit pixels sit little-endian in memory), unlike the registers. 2D solid fill at 8 bpp: 439 Mpixel/s. Triangle coverage is pixel-exact against XAA's Bresenham rule (26700 of 26700 pixels). CPU-only setup (no register writes) is 6.8 ms of the 19.6 ms frame.