diff --git a/harness/mame/NETWORK_REPORT.md b/harness/mame/NETWORK_REPORT.md index 430eb33..42fe12d 100644 --- a/harness/mame/NETWORK_REPORT.md +++ b/harness/mame/NETWORK_REPORT.md @@ -4726,3 +4726,43 @@ re-enable the display until POST is done. cycle during it. `jump` and `reboot` both transmit their reply and wait for the descriptor to complete before transferring control, so the host always gets its acknowledgement first. + +### 72.4 There is no vendor reboot to jump to (checked in Ghidra) + +The diagnostics menu looked like the obvious place for a supported restart, so +the ROM was read in the Ghidra project (`ghidra/vt1200.gpr`, TMS34010). The +complete menu is at `rom:0x07fb9532` (byte addresses in the image; the string +address is bit `0x3FDC…`): + +``` +VERSION 2.08 - SELECTED TEST TYPE: +A[x]/Y - ROM TEST (x = bank select)/NVM C - LANCE TEST +D - KEYBOARD TEST E - DUART1, CHANNEL A (HOST) +F - DUART1, CHANNEL B (PRINT) G - DUART1 TIMER +H - DUART2, CHANNEL A (KEYBOARD) I - DUART2, CHANNEL B (MOUSE) +J - DUART2 TIMER K - MOUSE/TABLET TEST +L - VIDEO TEST M - ETHERNET ROM TEST +N - VIDEO MEMORY TEST O - LOOPBACK MODE (TOGGLE) +P[x] - PATTERN W[x] - CONTINUE FOREVER / LOOP ON ERROR +X - RESET THE PRESENT SELECTION Z - RUN THE TEST SELECTION +Q - SELECT ALL TESTS U/V - BUILD LNKTABLE/RUN BUS PATH CHECK +S[x] - SELECT FCC MODES T[x] - IMAGE / MENU / DISPLAY INT +``` + +* **No reboot/restart entry.** `X` resets the *test selection*, not the machine. +* The string `REBOOT` does not occur anywhere in the 1.75 MB image, and neither + does `RESTART` as a menu action (the two hits are "Terminal Manager XIO error… + restarting…" and "server restarted" — OS messages). +* The reset entry `0x3F200040` appears as a constant **twice** in the whole ROM, + at `rom:0x07e40c2e` and `rom:0x07e40c64`, inside the early handler region, and + both reduce to a compare against `0x40` (`ANDI 0xffff` / `CMPI 0x40`). Neither + transfers control there. + +So the firmware never reboots itself; a reset is the hardware reset line. The +`reboot` command's jump to the reset vector is therefore the *only* software +path, and the measured ~88 s is the cost of that path — POST runs in full, with +the screen blank while it reprograms the video window. + +If a faster return than that is ever needed, the alternative is not a reboot but +a hand-back of the chip while the OS keeps running (section 64): the display and +the OS survive, the network does not.