CydandClaude Fable 5
2233441812
The plasma serial2 addition put COM2 (IRQ 3) in conflict with nicirq=3: netnub phase worked, then BTL4OPT opened the plasma port and NIC RX died, so the pod never checked in to the console. NIC now on IRQ 10 in all net confs + NET.CFG INT 10 (both sides must agree). Verified live: two full console missions with plasma running. Also: launch_pod.ps1 prepends the Npcap dir to PATH itself (a bare shell gave "NO PACKET DRIVER FOUND"); net_diag.conf = packet-stack-only boot with the NCSA Telnet suite on E: for DOS-side TCP tests; net_loop.conf promoted to full production parity (sound + plasma + IRQ 10) -- the GO.BAT-style instant netnub relaunch is also what lets the console recover its zombie TCP session between missions (see NET-NOTES). NET-NOTES: full 7/08-09 forensics writeup (TAP RX counter lie, console IP .10, SBK re-upload measured, zombie-session mechanics). LAST.EGG = the operator's missions from tonight's runs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
net-boot — networked pod boot support files
Files the DOSBox pod mounts as D: when booting on the network path
(emulator/net_full.conf, emulator/net_loop.conf). The pod receives its
mission egg from the ops console (SheepShaver) over TCP 1501 — no -egg bypass.
Contents
LSL.COM,NE2000.COM,ODIPKT.COM— Novell ODI stack: Link Support Layer → NE2000 MLID → ODI-to-Packet-Driver shim. WATTCP/NetNub find the packet driver by scanning INT 0x60-0x80 forPKT DRVR(odipkt lands at SINT 0x60).NET.CFG— ODI driver config.PORT 340(see below),INT 3,FRAME Ethernet_II.loop.bat— GO.BAT-style loop: keeps relaunchingnetnub -p -f btl4optso the pod stays connected and picks up whatever mission the console queues.
The 0x340 NIC base (important)
The VDB video splitter board is hardwired at I/O 0x300-0x31A (its palette
registers are at 0x300/0x308/0x310; VDB_BASE in vpxlog.cpp). If the NE2000
NIC is put at the usual nicbase=300 it claims that same range and swallows
the game's mid-mission VDB palette writes → every MFD/radar head decodes to
black, and the VDB traffic corrupts the NIC's registers so the console's
EndMission is lost (the mission overruns its timer). The NIC is therefore at
0x340 in both the DOSBox conf (nicbase=340) and here (PORT 340); they
must agree. The VDB keeps 0x300 (the game hardwires it — on the real pod the
NIC lived at a different base for exactly this reason).
Bridge / pcap notes
See ../NET-NOTES.md for the two-TAP Windows bridge, the bridge-miniport
realnic binding, and npcap DLL path requirements.