mirror of
https://git.k-space.ee/arti/vt1200.git
synced 2026-10-30 12:03:54 +02:00
102 lines
4.6 KiB
Markdown
102 lines
4.6 KiB
Markdown
# Level-1 test sequence — and which tests need real peripherals
|
||
|
||
Source: `docs/EK-V1000-SV-002_service-guide.txt`
|
||
(Table 2–2 = "the 15 level 1 tests", Table 2–4 = NCP test numbers,
|
||
Table 2–5 = P3 mode bits, Table 3–4 = screen error messages).
|
||
|
||
## The 15 level-1 tests (Table 2–2)
|
||
|
||
Listed in the guide as two columns; the true execution order is not certain from
|
||
this table alone. Reading the columns separately:
|
||
|
||
| Left column | Right column |
|
||
|---|---|
|
||
| Video RAM test | DUART1 timer test |
|
||
| Video test | Keyboard port test |
|
||
| NVR checksum test | Mouse port test |
|
||
| Ethernet address ROM test | DUART2 timer test |
|
||
| Option RAM test (if present) | Ethernet port (LANCE) test |
|
||
| Host port test | Mouse test |
|
||
| Printer port test | Keyboard test |
|
||
| Image test (if installed) | |
|
||
|
||
## The distinction that matters: port tests vs device tests
|
||
|
||
These are **different tests**, not two names for the same thing.
|
||
|
||
| Test | Error code | Requirement |
|
||
|---|---|---|
|
||
| Host port test | 15 | host UART **local loopback** — no external equipment |
|
||
| Printer port test | 16 | printer UART **local loopback** — no external equipment |
|
||
| Keyboard **port** test | 18 | keyboard UART **local loopback** — no device |
|
||
| Mouse **port** test | 19 | mouse UART **local loopback** — no device |
|
||
| DUART timer 1 / 2 | 17 / 21 | the DUARTs themselves |
|
||
| Ethernet port (LANCE) test | 24 | the LANCE chip's own loopback |
|
||
| **Keyboard test** | **27** | **the real keyboard** |
|
||
| **Mouse test** | **26** | **the real mouse / tablet** |
|
||
|
||
The guide's own wording draws the line:
|
||
|
||
> **Host Port Test** — Verifies the internal data paths of the host port's universal
|
||
> asynchronous receiver transmitter (UART) **by using its local loopback mode**. If you
|
||
> also choose the external loopback test, this test checks the driver and receiver
|
||
> hardware as well.
|
||
|
||
> **Keyboard Port Test** — Verifies the internal data paths of the keyboard UART **by
|
||
> using its local loopback mode**. **There is no external loopback test for the keyboard
|
||
> port.**
|
||
|
||
> **Keyboard Test** — **Firmware requests that the keyboard do its self-test** and
|
||
> display any error code.
|
||
|
||
> **Mouse Test** — **Firmware requests that the mouse or tablet do its self-test** and
|
||
> display any error code.
|
||
|
||
So a *port* test drives the UART and needs nothing attached. A *device* test asks the
|
||
attached device to run its own self-test and report back — which **requires the real
|
||
device on the other end of the serial line**.
|
||
|
||
External loopback is always a **separate opt-in**, not the default: P3 mode bits
|
||
(Table 2–5) are `bit 0` = host port, `bit 1` = printer port, `bit 2` = mouse port,
|
||
`bit 3` = LANCE. Default (P3 = 0) is local loopback only.
|
||
|
||
## The peripherals are serial devices, on DUART2
|
||
|
||
The VT1200 keyboard and mouse are serial devices, and the ROM's own test list names
|
||
their ports directly:
|
||
|
||
```
|
||
E - DUART1, CHANNEL A (HOST)
|
||
H - DUART2, CHANNEL A (KEYBOARD)
|
||
I - DUART2, CHANNEL B (MOUSE)
|
||
```
|
||
|
||
So DUART1 = host + printer, DUART2 = keyboard + mouse — matching the split already
|
||
used in `harness/mame/vt1200.cpp`.
|
||
|
||
## Consequence for this project
|
||
|
||
1. **The current gate is not a peripheral problem.** The host port test (error 15) is
|
||
host-UART local loopback. It needs no external responder, and the host is not a
|
||
keyboard or mouse in any case. This confirms the "ORCHESTRATOR CORRECTION" in
|
||
`harness/mame/DUART_REPORT.md`.
|
||
2. **But two level-1 tests do need the devices** — *Keyboard test* (27) and *Mouse test*
|
||
(26) are in the level-1 list. The harness will have to model the LK201-style keyboard
|
||
and mouse. Best source for that is **not invention**: capture the real devices'
|
||
serial behaviour from the live terminal, the same way the earlier live-hardware work
|
||
captured other traffic.
|
||
3. **Keep the models from leaking between tests.** The port tests are loopback; if a
|
||
keyboard model answers during the *keyboard port* test, that test can pass for the
|
||
wrong reason (and the reverse). The existing DUART TX→RX loopback wiring is already
|
||
selectable per DUART for exactly this reason (`VT1200_DUART_LB1`/`LB2`).
|
||
|
||
## Related open question (level 0)
|
||
|
||
`DUART_REPORT.md` §3 reports that the **level-0** I/O data-path test (`L3FDCE470`) writes
|
||
`0xE1` to DUART2 channel A and then requires a **10-byte reply**. On real hardware the
|
||
keyboard channel is answered by the keyboard. Note the anomaly: level 0 currently
|
||
**passes** with the *board model* (which fabricates read values) but **fails** with a
|
||
*real* DUART (which correctly reports "no data") — i.e. the fake is accidentally
|
||
satisfying the test. Resolve when the DUART work resumes: either it is a loopback the
|
||
firmware drives itself, or it needs the keyboard device model.
|