From b5fe6935e10d59ddb638841096b8346532790053 Mon Sep 17 00:00:00 2001 From: Arti Zirk Date: Fri, 30 Oct 2026 01:35:58 +0200 Subject: [PATCH] NETWORK_REPORT: CSRG tree provenance; IDON clearing shown to be optional original-bsd spans 1979..4.4BSD-Lite2 and carries the same if_ether.c string as the ROM. Its pmax (DECstation) if_le.c clears IDON before STRT, Linux does too, but NetBSD's lance.c does not -- and neither does the VT1200 firmware itself (0x3FDDCBE0 writes CSR1/2/3 then 0x7F41 and the live path goes INIT -> poll IDON -> 0x0042 with no IDON clear). Since the firmware works on the real machine, the IDON hypothesis is dead and the descriptor length encoding (section 50) is the remaining explanation. --- harness/mame/NETWORK_REPORT.md | 74 ++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) diff --git a/harness/mame/NETWORK_REPORT.md b/harness/mame/NETWORK_REPORT.md index 01f9557..2dd7333 100644 --- a/harness/mame/NETWORK_REPORT.md +++ b/harness/mame/NETWORK_REPORT.md @@ -3575,3 +3575,77 @@ minutes. Path-limited queries are immediate and were used instead: git log --diff-filter=A --format='%ad %h' --date=short -- sys/dev/isa/if_le.c git show :sys/netinet/ip_icmp.c ``` + +## 52. CSRG tree (`original-bsd`) — the firmware's own lineage, and IDON settled + +`/home/arti/code/original-bsd` is the CSRG source tree: history back to +**1979-12-04** (`3bsd version`), last commit the final CSRG delta (4.4BSD-Lite2). +180 MB, so full-tree searches are instant — the right tree for provenance +questions. + +### 52.1 Same ARP code, one release older + +``` +sys/netinet/if_ether.c:409: + "arp: ether address is broadcast for IP address %x!\n", +``` + +identical to the string in the ROM and to the 386BSD import, and unlike modern +NetBSD's "link address" wording. + +### 52.2 LANCE drivers present in 4.4BSD + +``` +sys/hp300/dev/if_le.c sys/luna68k/dev/if_le.c +sys/pmax/dev/if_le.c sys/sparc/sbus/if_le.c +sys/news3400/if/if_lance.c +``` + +The **pmax (DECstation)** driver is the closest sibling to a DEC-built terminal +stack, and its init sequence is (`sys/pmax/dev/if_le.c:405-419`): + +```c +LEWREG(LE_CSR1, ...); LEWREG(init_block_addr_low, ...); +LEWREG(LE_CSR2, ...); LEWREG(0, ...); +LEWREG(LE_CSR3, ...); LEWREG(0, ...); +LEWREG(LE_CSR0, ...); LERDWR(ler0, LE_INIT, ...); +do { ... } while ((stat & LE_IDON) == 0); +LERDWR(ler0, LE_IDON, ...); /* clear IDON by writing 1 */ +LERDWR(ler0, LE_STRT | LE_INEA, ...); +``` + +So 4.4BSD and Linux both clear `IDON`; NetBSD's later driver does not. + +### 52.3 What the VT1200 firmware itself does — and why that settles it + +The firmware's own init (`io5800_5900_init`, `0x3FDDCBE0`) writes only: + +``` +RAP=1 -> init block low RAP=2 -> init block high +RAP=3 -> 0 RAP=0 -> 0x7F41 +``` + +`0x7F41` = `INIT | INEA | (all status bits written as 1 to clear them)`. The +poll and start live in its caller, and the live path captured in `LANCELOG` +(section 3) is: + +``` +CSR0 = 0x0001 (INIT) -> poll IDON (0x0181) -> CSR0 = 0x0042 (STRT|INEA) +``` + +**No `IDON` clear anywhere** — and this firmware demonstrably runs the terminal's +network stack on real hardware. + +Therefore clearing `IDON` is *optional*, confirmed from three directions: +a shipping driver that omits it (NetBSD), two that include it (4.4BSD pmax, +Linux), and the firmware itself, which omits it and works. + +### 52.4 Result for the hardware question + +Section 49.2's `IDON` hypothesis is now **dead**, and section 50 is left as the +only explanation that fits all the evidence: the descriptor length fields must be +`0xF000 | -len`, our payload's were not, MAME masks the difference in +`get_buf_length()`, and a chip rejecting both descriptor sets produces exactly +the measured state (`TDMD` never cleared, no `TINT`, no `RINT`, `ERR` clear). + +`lance_fixlen.coff` remains the payload to run on the machine.