From 4dda1862418775318cee52ad69930b5badb00604 Mon Sep 17 00:00:00 2001
From: Arti Zirk <arti.zirk@gmail.com>
Date: Fri, 30 Oct 2026 16:01:58 +0200
Subject: [PATCH] NETWORK_REPORT: text panel on the unit -- REST=0x0073 shows
 the chip hand-back works

Photo images/20261030_155855.JPG shows CSR0/CSR1=0x07B3, TMD1=0x8300,
RMD1=0x0300, MCNT=0x001C, OK=YES (loopback reproduced with the text build) and
REST=0x0073 = INIT|STRT|TXON|RXON|INEA, i.e. the chip is running again after
the payload's 0x7F41 -> 0x0042 hand-back.

The OS however shows 'Ethernet Port Error - 24' and stays off the network, so
the recovery failure is in the firmware's driver state, not in the LANCE. A
takeover run therefore still costs a power cycle.
---
 harness/mame/NETWORK_REPORT.md | 59 ++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

diff --git a/harness/mame/NETWORK_REPORT.md b/harness/mame/NETWORK_REPORT.md
index fca5f9a..24fa043 100644
--- a/harness/mame/NETWORK_REPORT.md
+++ b/harness/mame/NETWORK_REPORT.md
@@ -4281,3 +4281,62 @@ That is a general hazard of this payload layout: `.text` grows upward from
 **`0x018D0000`**, clear of the end of `.text` by ~2.6 KB.
 
 Any future growth should re-check `build/lance.map` against `MARK`.
+
+## 64. Text panel on the unit: loopback reproduced, chip hand-back works, OS does not
+
+Photo: `images/20261030_155855.JPG`. Panel as drawn by
+`lance_fixlen.coff` (text build, `MARK` moved to `0x018D0000`):
+
+```
+CSR0  07B3      TMD1  8300      MCNT  001C      REST  0073
+CSR1  07B3      RMD1  0300      OK    YES
+```
+
+and five progress dots down the left edge (the payload ran to the RX completion).
+
+### 64.1 The loopback is reproduced
+
+`CSR0 = CSR1 = 0x07B3`, `TMD1 = 0x8300`, `RMD1 = 0x0300` (OWN clear, STP|ENP),
+`MCNT = 0x001C` (28 B = 24 + FCS), `OK = YES`. Identical to the earlier
+white-box run (section 61) and to the MAME reference — the text build changes
+nothing in the test itself.
+
+### 64.2 `REST = 0x0073` — the chip *was* handed back correctly
+
+```
+0x0073 = INIT | STRT | TXON | RXON | INEA
+         (STOP clear, TDMD clear, INTR clear, IDON clear)
+```
+
+So after the test the payload re-programmed the chip from the firmware's own
+init block (`0x7F41`), polled `IDON`, wrote `0x0042`, and the chip responded:
+transmitter on, receiver on, interrupts enabled. **The `INIT` bit still being set
+is normal** — MAME's own `0x7B3` has it too (section 47.2).
+
+In other words the "give the chip back" step works at the chip level. It has
+never been the chip.
+
+### 64.3 What actually stays broken: the OS's Ethernet driver
+
+The screen behind the panel shows the Terminal Manager with
+**`Ethernet Port Error - 24`** at the bottom, and the network is unreachable
+afterwards (ping fails, rdebug port 771 closed).
+
+So the recovery failure is in the **firmware's own network stack**, not in the
+LANCE: the driver noticed the chip disappear during the takeover, marked the port
+failed, and does not re-initialise on its own even when the chip comes back
+enabled.
+
+Practical consequence, recorded so it is not re-litigated: **a LANCE takeover run
+on this machine costs a power cycle.** The restore code stays (it is correct and
+harmless), but the unit will not return to service by itself.
+
+### 64.4 Where that leaves the hardware question
+
+It is answered:
+
+| question | result |
+|---|---|
+| does the firmware's init/ring/descriptor/TDMD sequence work on real silicon | **yes** (sections 61, 64.1) |
+| was the old failure our payload or the chip | **our payload**: descriptor length must be `-len` (`0xFFE8`/`0xFA0A`) |
+| can the chip be handed back to the OS from a payload | **yes at the chip level** (`REST = 0x73`), not at the driver level |