arti/vt1200
1
0 Fork 1
Code Issues 1 Pull Requests Wiki Activity

docs: XMapWindow is 0x3FD64F60; 0x3FD645B0 is XRaiseWindow #8

Merged
arti merged 1 commits from opencode.siil.arti.ee/vt1200:fix/issue-1-xmapwindow into master 2026-11-13 11:22:34 +02:00
Conversation 0 Commits 1 Files Changed 5
+45 -15
opencode.siil.arti.ee commented 2026-11-13 11:20:41 +02:00
Collaborator
Copy link
Copy source

Closes #1

What was wrong

dwt/notes/GUI_APPS.md listed XMapWindow at bit 0x3FD645B0 (Ghidra
0x07FAC8B6), and dwt/gui/xhello.asm, dwt/gui/xtext.asm and
dwt/gui/trace_accept.lua repeated the label. That function does not send a
MapWindow request. It sends ConfigureWindow (opcode 12) with
CWStackMode = Above — i.e. it is XRaiseWindow. The real XMapWindow
is bit 0x3FD64F60 (Ghidra 0x07FAC9EC), which sends MapWindow (opcode 8).

This is docs-and-labels only. No call target, no ROM byte, no build output was
changed.

Re-derivation (done before editing)

Both addresses were re-derived from the ROM with tools/smart34010/dis34.
The ROM is unmodified:

$ md5sum vt1200_v22.bin
b46a3e442ccb86134d2356bd70d22fd2  vt1200_v22.bin

0x3FD64F60 — MapWindow, opcode 8:

$ tools/smart34010/dis34 -l -o -b 3FD64F60 -s 0x16C9EC vt1200_v22.bin
3fd64f60:	mmtm   sp, a7,a9,a10,a11,a13	; 098f 0174
...
3fd65080:	move   *a9(0x380), a10, 1	; b72a 0380
3fd650a0:	move   a10, *a9(0x340), 1	; b349 0340
3fd650c0:	movk   8, a11	; 190b
3fd650d0:	movb   a11, *a10	; 8d6a
3fd650e0:	movk   2, a7	; 1847
3fd650f0:	setf   16, 0, 0	; 0550
3fd65100:	move   a7, *a10(0x10), 0	; b0ea 0010

movk 8 is the MapWindow opcode, written to the request buffer at *a10;
movk 2 is the 8-byte request length (2 4-byte units) at byte offset 2.
The window goes to *a10(0x20) (byte 4). This is a MapWindow request and
nothing else.

0x3FD645B0 — ConfigureWindow, opcode 12, CWStackMode:

$ tools/smart34010/dis34 -l -o -b 3FD645B0 -s 0x16C8B6 vt1200_v22.bin
3fd645b0:	mmtm   sp, a5,a7,a9,a10,a11,a13	; 098f 0574
...
3fd646d0:	move   *a9(0x380), a10, 1	; b72a 0380
3fd646f0:	move   a10, *a9(0x340), 1	; b349 0340
3fd64710:	movk   12, a7	; 1987
3fd64720:	movb   a7, *a10	; 8cea
3fd64730:	movk   4, a5	; 1885
3fd64740:	setf   16, 0, 0	; 0550
3fd64750:	move   a5, *a10(0x10), 0	; b0aa 0010
...
3fd64820:	move   *a13(0xffc0), *a10(0x20), 1	; bbaa ffc0 0020
3fd64850:	movi   0x40, a5	; 09c5 0040
3fd64870:	move   a5, *a10(0x40), 0	; b0aa 0040
3fd64890:	sub    a7, a7	; 44e7
3fd648a0:	move   a7, *a10(0x60), 1	; b2ea 0060

Opcode 12 (ConfigureWindow), length 4 (16-byte request), window at byte 4
(*a10(0x20)), value-mask 0x40 (= CWStackMode) at byte 8
(*a10(0x40)), value 0 (= Above) at byte 12 (*a10(0x60)). That is exactly
Xlib's XRaiseWindow. It does not map anything.

The -s offset is the file offset (bit_address >> 3) - 0x07E40000.

Changes

  • dwt/notes/GUI_APPS.md
    • Xlib table: the old row is now
      XRaiseWindow(d,w) | 0x07FAC8B6 | 0x3FD645B0 | ConfigureWindow, opcode 12, CWStackMode mask 0x40, value Above (0);
      a new XMapWindow(d,w) | 0x07FAC9EC | 0x3FD64F60 | opcode 8 (MapWindow), 2 args row is added.
    • The minimum sequence's step 3 is now XMapWindow(d, win) — 0x3FD64F60,
      followed by a paragraph saying 0x3FD645B0 is XRaiseWindow, that it does
      not map, and that the shipped payloads rely on the window being mapped on
      their behalf (they appear framed).
    • New drift check block next to the table with the exact two dis34
      invocations above and the opcodes to expect.
    • Two prose mentions that described the payload as calling XMapWindow are
      corrected to XRaiseWindow (the injection experiment and §10).
  • dwt/notes/CROSS.md — entry-point list now has XMapWindow 0x3FD64F60 and
    XRaiseWindow 0x3FD645B0 (ConfigureWindow/CWStackMode, does not map).
  • dwt/gui/xhello.asm, dwt/gui/xtext.asm — header tables and call-site
    comments relabelled XRaiseWindow; each call now states it raises an
    already-mapped window and does not map it (XMapWindow is 3FD64F60).
    The call targets (calla 3FD645B0h) are unchanged.
  • dwt/gui/trace_accept.lua — the address comment and the breakpoint's
    printed label are RaiseWindow; a 3FD64F60 XMapWindow comment line is
    added to the address list. No breakpoint was added or moved.

Verification

Sweep for the old claim (real output):

$ grep -rn 'XMapWindow.*3FD645B0\|3FD645B0.*XMapWindow' --exclude-dir=.git .
./dwt/notes/GUI_APPS.md:197:`XMapWindow` is `0x3FD64F60` (MapWindow, opcode 8). `0x3FD645B0` is
./dwt/gui/build/xhello.lst:31: 0026                    ;   7FAC8B6 XMapWindow(display,window)     -> 3FD645B0
./dwt/gui/build/xhello.lst:178: 0124 000008F0     0D5F  	calla	3FD645B0h		; XMapWindow
./dwt/gui/build/xtext.lst:17: 0012                    ;   XMapWindow(d,win)                      3FD645B0
./dwt/gui/build/xtext.lst:264: 0188 00000C50     0D5F  	calla	3FD645B0h		; XMapWindow
./dwt/loader/build/xhello.lst:31: 0026                    ;   7FAC8B6 XMapWindow(display,window)     -> 3FD645B0
./dwt/loader/build/xhello.lst:178: 0124 000008F0     0D5F  	calla	3FD645B0h		; XMapWindow
./dwt/loader/build/xtext.lst:17: 0012                    ;   XMapWindow(d,win)                      3FD645B0
./dwt/loader/build/xtext.lst:264: 0188 00000C50     0D5F  	calla	3FD645B0h		; XMapWindow
./docs/superpowers/specs/2026-11-03-termtris-vt1200-design.md:21:  `XMapWindow` (`0x3FD64F60`; `0x3FD645B0` is `XMapRaised`), `XSync`,

The only remaining XMapWindow … 3FD645B0 claims are in the committed build
listings and the historical design spec; the GUI_APPS.md hit is the new
corrective sentence (XMapWindow is 0x3FD64F60).

  • ROM md5 unchanged: b46a3e442ccb86134d2356bd70d22fd2.
  • No payload was rebuilt or re-run for this change; see follow-up.

Follow-up (deliberately not done here)

  • The committed build outputs still carry the old label in their listing
    comments: dwt/gui/build/{xhello,xtext}.{lst,map,bin} and
    dwt/loader/build/{xhello,xtext}.{lst,map,bin}. The brief for this fix says
    not to rebuild them, and hand-editing a .lst would make it disagree with
    the next build. Rebuilding the payloads and re-running the GUI acceptance
    run is follow-up work.
  • dwt/gui/README.md row for xhello.asm still lists XMapWindow among the
    calls (it is not one of the files this fix was scoped to).
  • docs/superpowers/specs/2026-11-03-termtris-vt1200-design.md still calls
    0x3FD645B0 XMapRaised; it is a historical design record and was left
    alone.
Closes #1 ## What was wrong `dwt/notes/GUI_APPS.md` listed `XMapWindow` at bit `0x3FD645B0` (Ghidra `0x07FAC8B6`), and `dwt/gui/xhello.asm`, `dwt/gui/xtext.asm` and `dwt/gui/trace_accept.lua` repeated the label. That function does not send a MapWindow request. It sends **ConfigureWindow** (opcode 12) with `CWStackMode = Above` — i.e. it is **`XRaiseWindow`**. The real `XMapWindow` is bit `0x3FD64F60` (Ghidra `0x07FAC9EC`), which sends MapWindow (opcode 8). This is docs-and-labels only. No call target, no ROM byte, no build output was changed. ## Re-derivation (done before editing) Both addresses were re-derived from the ROM with `tools/smart34010/dis34`. The ROM is unmodified: ``` $ md5sum vt1200_v22.bin b46a3e442ccb86134d2356bd70d22fd2 vt1200_v22.bin ``` `0x3FD64F60` — MapWindow, opcode 8: ``` $ tools/smart34010/dis34 -l -o -b 3FD64F60 -s 0x16C9EC vt1200_v22.bin 3fd64f60: mmtm sp, a7,a9,a10,a11,a13 ; 098f 0174 ... 3fd65080: move *a9(0x380), a10, 1 ; b72a 0380 3fd650a0: move a10, *a9(0x340), 1 ; b349 0340 3fd650c0: movk 8, a11 ; 190b 3fd650d0: movb a11, *a10 ; 8d6a 3fd650e0: movk 2, a7 ; 1847 3fd650f0: setf 16, 0, 0 ; 0550 3fd65100: move a7, *a10(0x10), 0 ; b0ea 0010 ``` `movk 8` is the MapWindow opcode, written to the request buffer at `*a10`; `movk 2` is the 8-byte request length (2 4-byte units) at byte offset 2. The window goes to `*a10(0x20)` (byte 4). This is a MapWindow request and nothing else. `0x3FD645B0` — ConfigureWindow, opcode 12, `CWStackMode`: ``` $ tools/smart34010/dis34 -l -o -b 3FD645B0 -s 0x16C8B6 vt1200_v22.bin 3fd645b0: mmtm sp, a5,a7,a9,a10,a11,a13 ; 098f 0574 ... 3fd646d0: move *a9(0x380), a10, 1 ; b72a 0380 3fd646f0: move a10, *a9(0x340), 1 ; b349 0340 3fd64710: movk 12, a7 ; 1987 3fd64720: movb a7, *a10 ; 8cea 3fd64730: movk 4, a5 ; 1885 3fd64740: setf 16, 0, 0 ; 0550 3fd64750: move a5, *a10(0x10), 0 ; b0aa 0010 ... 3fd64820: move *a13(0xffc0), *a10(0x20), 1 ; bbaa ffc0 0020 3fd64850: movi 0x40, a5 ; 09c5 0040 3fd64870: move a5, *a10(0x40), 0 ; b0aa 0040 3fd64890: sub a7, a7 ; 44e7 3fd648a0: move a7, *a10(0x60), 1 ; b2ea 0060 ``` Opcode 12 (ConfigureWindow), length 4 (16-byte request), window at byte 4 (`*a10(0x20)`), value-mask `0x40` (= `CWStackMode`) at byte 8 (`*a10(0x40)`), value 0 (= `Above`) at byte 12 (`*a10(0x60)`). That is exactly Xlib's `XRaiseWindow`. It does not map anything. The `-s` offset is the file offset `(bit_address >> 3) - 0x07E40000`. ## Changes - `dwt/notes/GUI_APPS.md` - Xlib table: the old row is now `XRaiseWindow(d,w) | 0x07FAC8B6 | 0x3FD645B0 | ConfigureWindow, opcode 12, CWStackMode mask 0x40, value Above (0)`; a new `XMapWindow(d,w) | 0x07FAC9EC | 0x3FD64F60 | opcode 8 (MapWindow), 2 args` row is added. - The minimum sequence's step 3 is now `XMapWindow(d, win)` — `0x3FD64F60`, followed by a paragraph saying `0x3FD645B0` is `XRaiseWindow`, that it does not map, and that the shipped payloads rely on the window being mapped on their behalf (they appear framed). - New **drift check** block next to the table with the exact two `dis34` invocations above and the opcodes to expect. - Two prose mentions that described the payload as calling `XMapWindow` are corrected to `XRaiseWindow` (the injection experiment and §10). - `dwt/notes/CROSS.md` — entry-point list now has `XMapWindow 0x3FD64F60` and `XRaiseWindow 0x3FD645B0 (ConfigureWindow/CWStackMode, does not map)`. - `dwt/gui/xhello.asm`, `dwt/gui/xtext.asm` — header tables and call-site comments relabelled `XRaiseWindow`; each call now states it raises an already-mapped window and does **not** map it (`XMapWindow` is `3FD64F60`). The call targets (`calla 3FD645B0h`) are unchanged. - `dwt/gui/trace_accept.lua` — the address comment and the breakpoint's printed label are `RaiseWindow`; a `3FD64F60 XMapWindow` comment line is added to the address list. No breakpoint was added or moved. ## Verification Sweep for the old claim (real output): ``` $ grep -rn 'XMapWindow.*3FD645B0\|3FD645B0.*XMapWindow' --exclude-dir=.git . ./dwt/notes/GUI_APPS.md:197:`XMapWindow` is `0x3FD64F60` (MapWindow, opcode 8). `0x3FD645B0` is ./dwt/gui/build/xhello.lst:31: 0026 ; 7FAC8B6 XMapWindow(display,window) -> 3FD645B0 ./dwt/gui/build/xhello.lst:178: 0124 000008F0 0D5F calla 3FD645B0h ; XMapWindow ./dwt/gui/build/xtext.lst:17: 0012 ; XMapWindow(d,win) 3FD645B0 ./dwt/gui/build/xtext.lst:264: 0188 00000C50 0D5F calla 3FD645B0h ; XMapWindow ./dwt/loader/build/xhello.lst:31: 0026 ; 7FAC8B6 XMapWindow(display,window) -> 3FD645B0 ./dwt/loader/build/xhello.lst:178: 0124 000008F0 0D5F calla 3FD645B0h ; XMapWindow ./dwt/loader/build/xtext.lst:17: 0012 ; XMapWindow(d,win) 3FD645B0 ./dwt/loader/build/xtext.lst:264: 0188 00000C50 0D5F calla 3FD645B0h ; XMapWindow ./docs/superpowers/specs/2026-11-03-termtris-vt1200-design.md:21: `XMapWindow` (`0x3FD64F60`; `0x3FD645B0` is `XMapRaised`), `XSync`, ``` The only remaining `XMapWindow … 3FD645B0` claims are in the committed build listings and the historical design spec; the `GUI_APPS.md` hit is the new corrective sentence (`XMapWindow` is `0x3FD64F60`). - ROM md5 unchanged: `b46a3e442ccb86134d2356bd70d22fd2`. - No payload was rebuilt or re-run for this change; see follow-up. ## Follow-up (deliberately not done here) - The committed build outputs still carry the old label in their listing comments: `dwt/gui/build/{xhello,xtext}.{lst,map,bin}` and `dwt/loader/build/{xhello,xtext}.{lst,map,bin}`. The brief for this fix says not to rebuild them, and hand-editing a `.lst` would make it disagree with the next build. Rebuilding the payloads and re-running the GUI acceptance run is follow-up work. - `dwt/gui/README.md` row for `xhello.asm` still lists `XMapWindow` among the calls (it is not one of the files this fix was scoped to). - `docs/superpowers/specs/2026-11-03-termtris-vt1200-design.md` still calls `0x3FD645B0` `XMapRaised`; it is a historical design record and was left alone.
opencode.siil.arti.ee added 1 commit 2026-11-13 11:20:41 +02:00
docs(gui): correct XMapWindow and name 0x3FD645B0 XRaiseWindow 6b2ef0690c
arti merged commit 0b3db19cef into master 2026-11-13 11:22:34 +02:00
arti deleted branch fix/issue-1-xmapwindow 2026-11-13 11:22:34 +02:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No labels
Milestone
No items
No Milestone
Assignees
Clear assignees
opencode.energia.arti.ee opencode.siil.arti.ee arti (Arti Zirk)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: arti/vt1200#8