vt1200/dwt/notes/REAL_UNIT.md

First contact with the real VT1200

Date: 2026-10-18. Terminal at 100.103.100.103 (static IP, no BOOTP), reached from host 100.103.255.254 on enp197s0f3u1.

Read-only throughout this note — no poke, no jump.

Results

check	result
TCP 771	open
opcode 7	challenge (flag 0x7F) sent, computed reply accepted, Done\n\0
peek 0x3F200000 (8 B)	e9 7a e2 f5 aa aa 55 55 — matches vt1200_v22.bin
peek 0xAECE0 (1 B)	bd — message classes 0,1,2 admitted (emulator: 05)
peek 0x1E8BA0 (4 B)	0x018BF1B0 bits = 3,251,638 bytes free in the heap
screenshot over peek	dwt/evidence/real-unit-canvas.png

The screenshot shows the live Terminal Manager V2.2: Ethernet 08-00-2B-16-4B-5A, IP 100.103.100.103, LAT LAT_08002B164B5A, and five Debug connection from IP host 100.103.255.254 lines in Messages — one per connection made here. That is the read primitive working on real hardware.

Two differences from the emulator, worth knowing

1. The real unit challenges opcode 7. The emulator only challenges opcodes ≥ 2. A plain liveness check therefore exercises the challenge too, and its success is additional evidence that dwt/challenge.py matches the shipped image.
2. Message filter is 0xBD, not 0x05. Levels 0, 1 and 2 are admitted on the real unit; the emulator only admitted 0 and 3.

Geometry

The raw VRAM canvas is 1024×1024, captured correctly. The visible screen is 1280×1024, with the canvas at x=192; dwt/screenshot.py --screen uses the emulator's 1280×901/offset-192×36 defaults and will misplace the bottom on the real unit. The raw canvas is the authoritative artifact; for a faithful screen image use --screen-width 1280 --screen-height 1024 --offset-x 192 --offset-y 0 once the vertical origin is measured.

Next

The remaining unproven step on this unit is the write path: poke/jump and then the COFF loader + create_process. The loader already refuses a target outside a free-list block (status 8), so a first attempt with marker.coff will tell us whether the linked ranges are free before anything runs.

Display geometry and background (measured)

• Framebuffer 1024×1024, 128 bytes/row, LSB-first. A 160-byte pitch shears; 128 bytes is coherent. The 160-byte figure is the total raster (1280/8), not the memory pitch (RENDER_REPORT.md).
• Visible raster 1280×1024 (monitor OSD: 77.2 kHz / 73 Hz; Samsung SyncMaster 770 native 1280×1024). The 1024-wide canvas is displayed 5:4, so dwt/screenshot.py --stretch 1280x1024 matches the screen. --screen's emulator 1280×901 geometry pads/crops and looks line-doubled.
• The 101010 background is real data, not a decode error. It is a 50% stipple: rows alternate 55 (01010101) and ff. The root background has a setting; setting it to 100% white changed the root to solid ff (verified by a fresh grab). The Terminal Manager window kept its own stipple, so its window background is a separate setting (or was taken at creation).
• The bottom message box Ethernet Port Error - 24 is present in VRAM; it is a real terminal error, not a capture artifact.

The TM stipple survives the root-background change

A fresh grab after the root was set to 100% white confirms: root 0xff, TM body still alternating 0x55/0xff rows. So the TM pattern is not the desktop background setting and the manager has no option for it.

The likely explanation is the display fetch, not the data: if the video mode shows only one set of rows (line doubling / interlace), the 0xff rows are what reaches the glass and the 0x55 rows are never shown — which is why the TM looks white while the raw framebuffer looks striped. That also explains why the capture looked "line doubled": it is showing both row sets.

The emulator forces the VR150 monitor position (IP4-IP6 high, 0x70). The real unit's rear switch selects the mode; if it is at another position the firmware may use a different fetch/pattern. Test: set the switch to position 1 (VR150), power-cycle, grab again.

Line-interleaved framebuffer — the "line doubled" answer

The real framebuffer is line-interleaved: even rows carry the image, odd rows carry a 0x55 mask in window areas (and 0xff in the root). The display doubles the even field, so the odd rows are never shown. A linear peek reads both fields, which is why the first captures looked striped and "line doubled".

Evidence: in the Messages area every even row is 0xff/text and every odd row is a uniform 0x55; the root is 0xff on both. After the owner set the background to 100% white and rebooted, the root is 0xff everywhere and the TM's odd rows are still 0x55 — yet the screen is solid white. That proves the odd rows are a non-displayed mask.

Correct capture:

python3 dwt/screenshot.py --host 100.103.100.103 \
    --field even --stretch 1280x1024 --out screen.png

dwt/evidence/real-unit-white2.png is that capture and matches the glass.

This is a display-fetch difference, not a CPU-emulation difference. MAME's driver models a linear 1bpp framebuffer, so the emulator never shows the interleave; the real TMS34010 display controller is programmed for the doubled even field.