docs: XMapWindow is 0x3FD64F60; 0x3FD645B0 is XRaiseWindow (ConfigureWindow opcode 12) #1

New Issue

2026-11-12T07:22:34+02:00

2026-11-12 07:22:34 +02:00

dwt/notes/GUI_APPS.md (lines 79 and 179) and dwt/notes/CROSS.md (line 365) list XMapWindow(d,w) at bit 0x3FD645B0. That entry does not map a window.

Disassembling the v2.2 ROM at the entry (dis34 -b 3FD645B0 -s 0x16C8B6 vt1200_v22.bin):

3fd64710: movk 12, a7
3fd64720: movb a7, *a10            ; X11 opcode 12 = ConfigureWindow
...
3fd64850: movi 0x40, a5
3fd64870: move a5, *a10(0x40), 0   ; value-mask 0x40 = CWStackMode
3fd648a0: move a7, *a10(0x60), 1   ; value 0 = Above

It sends ConfigureWindow with CWStackMode=Above: it raises an already-mapped window and never sends MapWindow.

The actual MapWindow request is at bit 0x3FD64F60:

3fd650c0: movk 8, a11
3fd650d0: movb a11, *a10           ; X11 opcode 8 = MapWindow, length 2
3fd65120: move *a13(0xffc0), *a10(0x20), 1 ; window arg

The termtris branch's apps/termtris/src/vt1200/xlib.h already uses VT_XMAP = 0x3FD64F60 and its windows map correctly.

Impact: a client that follows GUI_APPS and calls only 0x3FD645B0 sends no MapWindow; any window that appears afterwards comes from some other call (or is an already-mapped window). The M3 client in tms-c-compiler used 0x3FD645B0 under the XMapWindow name, so its window evidence needs re-checking against opcode 8.

Requested fix:

change the two GUI_APPS.md rows and CROSS.md to XMapWindow = 0x3FD64F60;
document 0x3FD645B0 as XRaiseWindow (or the raise half of XMapRaised);
add a one-line dis34 check to the harness docs pinning opcode 8 vs opcode 12, so the names cannot drift again.

`dwt/notes/GUI_APPS.md` (lines 79 and 179) and `dwt/notes/CROSS.md` (line 365) list `XMapWindow(d,w)` at bit `0x3FD645B0`. That entry does not map a window. Disassembling the v2.2 ROM at the entry (`dis34 -b 3FD645B0 -s 0x16C8B6 vt1200_v22.bin`): ``` 3fd64710: movk 12, a7 3fd64720: movb a7, *a10 ; X11 opcode 12 = ConfigureWindow ... 3fd64850: movi 0x40, a5 3fd64870: move a5, *a10(0x40), 0 ; value-mask 0x40 = CWStackMode 3fd648a0: move a7, *a10(0x60), 1 ; value 0 = Above ``` It sends `ConfigureWindow` with `CWStackMode=Above`: it raises an **already-mapped** window and never sends `MapWindow`. The actual `MapWindow` request is at bit `0x3FD64F60`: ``` 3fd650c0: movk 8, a11 3fd650d0: movb a11, *a10 ; X11 opcode 8 = MapWindow, length 2 3fd65120: move *a13(0xffc0), *a10(0x20), 1 ; window arg ``` The `termtris` branch's `apps/termtris/src/vt1200/xlib.h` already uses `VT_XMAP = 0x3FD64F60` and its windows map correctly. Impact: a client that follows GUI_APPS and calls only `0x3FD645B0` sends no `MapWindow`; any window that appears afterwards comes from some other call (or is an already-mapped window). The M3 client in `tms-c-compiler` used `0x3FD645B0` under the `XMapWindow` name, so its window evidence needs re-checking against opcode 8. Requested fix: - change the two `GUI_APPS.md` rows and `CROSS.md` to `XMapWindow = 0x3FD64F60`; - document `0x3FD645B0` as `XRaiseWindow` (or the raise half of `XMapRaised`); - add a one-line `dis34` check to the harness docs pinning opcode 8 vs opcode 12, so the names cannot drift again.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: arti/vt1200#1