From 8c8e0c4e24ad00943c80d61e29273919160bb62f Mon Sep 17 00:00:00 2001 From: Arti Zirk Date: Fri, 30 Oct 2026 01:42:05 +0200 Subject: [PATCH] NETWORK_REPORT: map the last addressed functions (codec table, dispatchers, re-arm) Adds rows for the field-codec dispatcher 0x3F660380 / table 0x1E3D80 (8-byte entries, fn0 at +0, fn1 at byte 4) and its entry-2 pair 0x3F615E00 (convert, a ntohl-style swap) / 0x3F616090 (compare, the in_pcblookup address-test idiom) -- the operations are ordinary BSD, the table-driven codec is firmware specific (no lib/libc/rpc in this tree, no kernel fn-pair table). Adds 0x3F65A570 and 0x3F6A86D0 as firmware-specific (cmpi 0x72 character-coded id; not reachable from any EtherType), and the receive re-arm 0x3F9D17E0 (referenced at 0x3F602EC0/0x3F603100) mapped to lereset/ledrinit. Extends 56.3's coverage statement to match. --- harness/mame/NETWORK_REPORT.md | 66 ++++++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) diff --git a/harness/mame/NETWORK_REPORT.md b/harness/mame/NETWORK_REPORT.md index 3904bfb..965acf1 100644 --- a/harness/mame/NETWORK_REPORT.md +++ b/harness/mame/NETWORK_REPORT.md @@ -3911,3 +3911,69 @@ statement is: That is the honest boundary of the mapping: the protocol stack is 4.4BSD lineage, the driver's *deferred* structure is not. + +## 57. The remaining addressed functions: codec table, dispatchers, re-arm + +Sections 53–56 left four groups out. Each is now either given a counterpart or +recorded as firmware-specific with the reason. + +### 57.1 `0x3F660380` + table `0x1E3D80` — firmware field-codec table + +Structure (section 18): index `*(a13+0xC0)` in 0..16, entry = **8 bytes**, `fn0` +at `+0` and `fn1` at `+0x20` bits (= byte 4); entries 0,1 and 4..15 share one +pair (`0x3F658570`/`0x3F658650`), entries 2/3 point at `0x3F615E00` / +`0x3F616090`. + +**VT1200-specific, no 4.4BSD counterpart.** Checked for the two things it could +be: there is no XDR/RPC directory in this tree (`lib/libc/rpc` does not exist) +and no kernel table of function-pointer pairs indexed by a type code — the only +dispatch tables 4.4BSD has are `inetsw[]` (already mapped, section 53.1) and +`struct domain`, neither of which is a per-field codec. + +### 57.2 `0x3F615E00` and `0x3F616090` — the convert/compare pair + +| ROM | does | nearest 4.4BSD idiom | counterpart? | +|---|---|---|---| +| `0x3F615E00` | swaps a 32-bit packet field to host order, stores it, calls `0x3FB2C140` | `ntohl()` / `ntohs()` byte-order macros (`sys/netinet/in.h`) | **idiom only** — in BSD this is a macro inlined at each use, not a dispatch entry | +| `0x3F616090` | converts two values and compares them, returns 1/0 | `in_pcblookup()`'s address tests, e.g. `if (inp->inp_laddr.s_addr != laddr.s_addr) continue;` (`in_pcb.c:441`) | **idiom only** | + +So the *operations* are ordinary BSD operations, but the *table-driven +{convert, compare} per field type* is the firmware's own design. Neither has a +line-level counterpart. + +### 57.3 `0x3F65A570` and its caller `0x3F6A86D0` + +| ROM | what was established | status | +|---|---|---| +| `0x3F65A570` | four-case compare chain on a type word; reaches the ARP responder; **not reachable from any EtherType** (section 38); zero executions in every trace | **VT1200-specific dispatcher**, no BSD counterpart | +| `0x3F6A86D0` | its caller: extracts byte 1 of the argument and tests it against `0x72` (`cmpi 0x72`), i.e. a character-coded protocol id | **VT1200-specific**, no BSD counterpart | + +### 57.4 The receive re-arm — `0x3F9D17E0` + +Section 30.1 recorded that `0x3F602E00` re-arms the receive buffer, but omitted +the address. It is `0x3F9D17E0`, installed by the driver as the RX re-arm/post +routine (it appears as `movi 0x3f9d17e0` at `0x3F602EC0` and `0x3F603100`). + +| ROM | 4.4BSD counterpart | evidence | +|---|---|---| +| `0x3F9D17E0` | `lereset()` `if_le.c:359` / `ledrinit()` `:337` — the driver's own re-initialisation of the ring | both rebuild the descriptor ring and hand buffers back to the chip; the firmware additionally posts it as a callback, which is the deferred structure noted in 56.2 | + +(Note: an earlier review note referred to this as `0x3F9817E0`; the address in +the ROM is `3F9D17E0`.) + +### 57.5 Coverage, final form + +The mapping now covers, with a cited line or an explicit firmware-specific +entry, every function the report gives an address for: + +| group | mapped to | +|---|---| +| protocol layer | 4.4BSD with quoted lines (53.1, 54, 56.1) | +| driver | `leinit`/`lereset`/`ledrinit`/`lestart`/`leintr`/`lerint` (53.3, 57.4) | +| deferred receive / submit / IRQ glue | firmware-specific (56.2) | +| codec table, protocol-id dispatcher | firmware-specific (57.1–57.3) | + +Section 56.3's statement is therefore extended: *the protocol stack is 4.4BSD +lineage with function-for-function counterparts; the driver maps onto the pmax +`le*` routines; and the deferred I/O structure, the field-codec table and the +protocol-id dispatcher are the firmware's own, with no source counterpart.*