diff --git a/dwt/evidence/real-unit-now.png b/dwt/evidence/real-unit-now.png
new file mode 100644
index 0000000..4b312e1
Binary files /dev/null and b/dwt/evidence/real-unit-now.png differ
diff --git a/dwt/notes/REAL_UNIT.md b/dwt/notes/REAL_UNIT.md
index a5cacb7..ba2c42f 100644
--- a/dwt/notes/REAL_UNIT.md
+++ b/dwt/notes/REAL_UNIT.md
@@ -62,3 +62,20 @@ will tell us whether the linked ranges are free before anything runs.
   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.