forked from arti/vt1200
158 lines
7.2 KiB
Markdown
158 lines
7.2 KiB
Markdown
# 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.
|
||
|
||
### Correction: the framebuffer is 1024x2048, not line-doubled
|
||
|
||
The earlier "the display doubles the even field" reading was wrong. A **256 KiB**
|
||
read (2048 rows x 128 bytes) shows the 1024 image lines sitting on **even rows
|
||
at 1:1**, with the odd rows carrying the mask. The earlier 128 KiB read held
|
||
only the **top 512 image lines**; doubling them stretched the top half and cut
|
||
the bottom — which is exactly the "missing left/bottom" and "line doubled"
|
||
appearance.
|
||
|
||
Correct 1:1 capture:
|
||
|
||
```sh
|
||
python3 dwt/screenshot.py --host 100.103.100.103 --real --out screen.png
|
||
```
|
||
|
||
`--real` means `--rows 0:2048 --field even` and outputs **1024x1024 with no
|
||
resampling**. `dwt/evidence/real-unit-1to1.png` is that capture: Icon Box,
|
||
Terminal Manager, Memory bar, and the `Ethernet Port Error - 24` box at the
|
||
bottom — the whole screen.
|
||
|
||
`--stretch 1280x1024` is only the monitor's 5:4 scaling of the 1024-wide
|
||
framebuffer; it is **not** 1:1 and the nearest-neighbour version produces the
|
||
uneven-pixel artefacts. Use it only for an approximate visual match, not as
|
||
evidence.
|
||
|
||
### Final geometry: 1280x1024, 256-byte row stride
|
||
|
||
The real unit is **1280x1024** with a **256-byte row stride**. Each row's first
|
||
**160 bytes (1280 px)** are the image; the remaining **96 bytes** are a `0x55`
|
||
mask. The earlier "1024x2048, even rows" reading was an artifact of treating
|
||
that 96-byte gap as an alternate row.
|
||
|
||
This is why the 1024-wide reads lost the right quarter: the Icon Box really is
|
||
1280 px wide and its resize buttons are at the far right, outside a 1024-px
|
||
crop. The mask bytes are what looked like "line doubling".
|
||
|
||
Correct 1:1 capture:
|
||
|
||
```sh
|
||
python3 dwt/screenshot.py --host 100.103.100.103 --real --out screen.png
|
||
```
|
||
|
||
`--real` = width 1280, stride 256, 1024 rows, no resampling.
|
||
`dwt/evidence/real-unit-1280-1to1.png` is the full 1280x1024 screen, including
|
||
the Icon Box resize buttons and the `Ethernet Port Error - 24` box.
|
||
|
||
The emulator geometry is unchanged: 1024x1024 with a 128-byte stride.
|