Networking M1: pod boots on the network path (no -egg) under emulation

NE2000 + Novell ODI chain (lsl/NE2000 MLID/odipkt) works against the
emulated card (odipkt at SINT 0x60, Ethernet_II). netnub -f btl4opt spawns
the game as btl4opt
This commit is contained in:
Cyd
2026-07-04 21:43:00 -05:00
parent 5e0f9c8061
commit 49bc526732
+40
View File
@@ -96,6 +96,46 @@ interface they expect.
with the ported/emulated Mac ops console; multi-pod coordination
(HostConnected/Disconnected, mission review, camera ship).
## Milestone 1 — DONE (2026-07-04): pod boots on the network path
Verified end to end under DOSBox-X (slirp backend), no `-egg` bypass:
- `[ne2000] ne2000=true, nicbase=300, nicirq=3, backend=slirp` → NE2000
emulated at Base=0x300 irq=3; slirp 4.9.1 initialized.
- **The Novell ODI chain works against the emulated NE2000**, no external
packet driver needed: `lsl` → `ne2000` (Novell/Eagle NE2000 MLID v1.53,
from NWCLIENT) → `odipkt` (FTP Software ODI packet driver). ODIPKT
installed at **SINT 0x60**, MLID NE2000, MAC CE:3D:72:67:38:69, frames
Ethernet_II (board 1) + 802.2 (board 2).
- GOTCHA: the ODI tools read `NET.CFG` from the directory the `.COM` loads
*from*, and the stock `NWCLIENT\NET.CFG` says `Link Driver LNEPCI` — with
no NE2000 section the MLID defaults to 802.2-only and odipkt fails
("An MLID could not be found"). Fix without touching ALPHA_1: keep an
emulator `NET.CFG` (`Link Driver NE2000` + `FRAME Ethernet_II`) beside
copies of lsl/ne2000/odipkt on a scratch drive and load from there.
- `netnub -f btl4opt` (no egg) launches the game as `btl4opt -net 250224`,
sets up the game↔netnub channel at **INT 0x61** (separate from odipkt's
0x60), initializes the network manager ("Changing blocking from 0 to 1"),
and the game boots through the VPX handshake to an open (blank) render
window — **waiting for a console to deliver a mission egg.**
Working scratch files: `scratchpad/net_stageB.conf`,
`scratchpad/net/{NET.CFG,LSL.COM,NE2000.COM,ODIPKT.COM}`. Launch env:
VPXLOG + VPX_RESPOND=1 + VPX_RENDER=1 (VPX board must answer or the game
exits before networking).
## Console side: a Mac emulator stands in for the ops console (user, 2026-07-04)
The user is building a **Mac emulator running the real 410console** as the
console peer (instead of a from-scratch Python stand-in). This merges the
networking and console-port workstreams: the real console software will
connect to the pod and push eggs. Implication for topology — two separate
emulators (DOSBox pod + Mac console) must share an L2 segment, which slirp
(NAT, per-process isolation) cannot bridge. **Plan: move the pod's NE2000
to `backend=pcap` on a host-only/loopback adapter; bridge the Mac emulator
to the same adapter; pod=200.0.0.113, console=200.0.0.1 on 200.0.0.0/24.**
Then milestone 3 (protocol) can be captured live from the real console
traffic rather than reverse-engineered blind.
## Open questions / notes
- Exact TCP listen port(s) — not in the source grep; get from NETNUB.EXE
or a capture at milestone 3.