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

@@ -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 <commit>: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.