mirror of
https://git.k-space.ee/arti/vt1200.git
synced 2026-10-30 12:03:54 +02:00
Add the terminal's actual input parts to the harness as device models on the already-modelled SCN2681 at DUART2: a DEC LK401 keyboard (channel A, 4800 8N1) and a DEC VSXXX-AA mouse (channel B, 4800 8O1), both driven by MAME's host input and wired bit-by-bit to the DUART (rx_a_w/rx_b_w and a_tx_cb/b_tx_cb). Route: the docs, not MAME's lk201. MAME's lk201 device executes the 68HC05 firmware 23-001s9-00.bin, which is not in our ROM set (the downloaded zip only carries the 8051 23-004M2-00.bin, MAME's unused second region), so route 1 is unusable without sourcing that ROM. The models follow PROTOCOL.md: the keyboard answers FD with the 4-byte self-test and reports documented keycodes honouring the division modes; the mouse answers T with its 4-byte self-test and streams 3-byte incremental reports. One physical-layer detail was required: the SCN2681 receiver mis-samples the first byte after a receiver reset unless the line is explicitly idle-high before the start bit. Both models now hold TxD at mark when idle (which is faithful anyway) -- isolated evidence: bit-banging 0x55 into rx_a_w gives RHRA=D5 with no idle-high, RHRA=55 with four idle-high bits. Verified (VT1200_SKIP_LEVEL1=1, input_inject.lua): the OS reads the keyboard keycode 0xC2 (A) and ~900 bytes of VSXXX reports (dx=+16/+32); after the self-test it switches the mouse to stream mode; the X11 cursor arrow is visible at frame 4400 and has moved by frame 4600. Nothing was tuned for the level-0 I/O data-path test: with no env the boot still fails it honestly and the regression baseline is unchanged (PC=3FDCE400 samples=198, 3 PCs). VT1200_IO_PATH_STUB=1 (53/75) and the skip run (Terminal Manager at frame 3000) are also unchanged. ROM md5 unchanged. See harness/mame/INPUT_REPORT.md.