dwt/screenshot: --field even for the real unit's line-interleaved framebuffer; the capture now matches the glass

dwt/notes/REAL_UNIT.md

@@ -79,3 +79,31 @@ 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.