# 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:

```sh
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.