RP experiment finding: RP runs on the BT pod emulator (shared MUNGA stack) but
its cockpit VDB heads mis-decode. Root causes captured live (VDB_PALDUMP +
vpxresp log): (1) framebuffer identical to BT (mode 0x111, 640x480); (2) RP
loads pal0 (BT's dynamic color-radar palette) as ALL ZEROS -> radar head black;
(3) RP actively drives the VGA-DAC pixel-mask register that BT leaves at 0xFF,
and pal_draw ignored it -> likely the MFD garble.
Device change: pixel-mask writes now log their VALUE on change
("# VDB pixel-mask[gN] = 0xXX"); pal_draw ANDs the palette index with the
group mask under VDB_APPLYMASK=1 (default off = BT-identical); masks default to
0xFF in vdb_reset so an un-driven group still decodes. Built clean under MINGW64.
Also: Mac Console 4.10 retired from regular use (host .NET console is the daily
driver); tap2_mirror.py PARKED with revive notes for console A/B only. The
SendToRxAdapters registry stays set (serves the .NET host console).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Answering "why doesn't the binary honor the 30s -- it exits in a few seconds":
disassembled the StopMission close in all four BTL4OPT builds (BTLIVE May-96,
BTRAVINE Sep-96, BTDAVE, Rel410) -- BYTE-IDENTICAL, so nothing regressed. The
dispatched (outer) handler is a re-entrant two-stage close: first StopMission
schedules itself +~3s (3.0f) and returns; the +3s re-entry runs cleanup then
calls the inner L4Application handler which lights the egress lamps and
schedules a +30s LightsOut/exit (30.0f). The 30s is scheduled after teardown
begins, so the exe is recycled by GO.BAT before it fires -- observed egress
window = ~3.4s = the 3.0f stage. The operator's remembered ~20-30s "lights on"
is entry lighting (floor lamp on game-ready->drop, 21s measured) + the
between-games boot gap, not a post-mission hold. Corrects my earlier
"authentic 30s hold" note. Tools: scratchpad btdis2.py + stopmission_cmp3.py.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Disassembled BTL4OPT.EXE StopMissionMessageHandler (@0x47b864): it turns
the RIO egress lamps on (the "LightsOut"-named routine, flag=1) and
schedules the lights-out/exit for now + 30.0*timebase + 0.5 (30.0f const
@0x47b8e4). So the customer-egress window is a hardcoded ~30s timer in
the GAME, not the console and not any INI/env value -- exactly matching
the operator's memory (StopMission -> floor lights on -> ~30s hold ->
lights off -> exit -> BAT restart). Answers "the delay must be somewhere":
it is compiled in. Noted the reconcile-with-3.4s-measured task (the
tapped 154.9s sweep was likely teardown; a 90s+ tap past mission end
settles wall-time). Disasm helper: scratchpad btdis2.py.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Measured Console 4.10 through the mirror: mission end to lights-off is
3.4s, identical to the TeslaConsole, with the Mac printer spooling to a
file. No egress-delay key exists in any console INI. Best explanation
for the remembered venue window: the console closes after spooling the
score sheet, and on period hardware that was a 9600-baud serial print
taking tens of seconds -- the floor lights stayed on for the print
duration. The hold itself is genuinely console-gated (pod holds
indefinitely when no close arrives).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
With SendToRxAdapters serving the host .NET console, the SheepShaver Mac
console was deaf (pod frames go up instead of out to TAP members). The
mirror daemon turns TAP2's free application side into a userspace bridge
port: pod frames destined for the Mac are written into TAP2 (bridge
forwards them to TAP1/SheepShaver), and a reader thread drains the
unicasts the bridge's poisoned MAC table steers into TAP2 and re-injects
them where the pod's pcap hears them. Loop guards: no pod-sourced
re-injection + short frame-hash dedup. Verified live: Console 4.10
readied the pod through the mirror while the .NET console path stayed
intact -- operator can now alternate between the 1996 Mac console and
the modern one without touching the driver config.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
RIO tap capture of a full TeslaConsole mission cycle: LampFloor 0x3E +
entry cluster (0x16/0x17/0x1e) bright at game-ready (customer entry),
off at mission drop, bright again at mission end (the state=2 hold),
all swept off the moment StopMission arrives, then game exit. The
egress window is purely the gap between mission end and the console's
StopMission send (measured 3.4s with TeslaConsole vs Console 4.10's
proper customer-exit delay) -- not a game timer, not the exit code.
Confirms the operator's remembered sequence byte for byte and pins the
TeslaSuite fix: a configurable delay before StopMission.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Wire + source answer to "what happens after the mission ends": the game
fades to the black hold, commands the RIO egress lamps (T 84 LampRequest
caught on the serial tap), and holds while its StateResponse to the
console's 1/s StateQuery flips to state 2. The hold ends only when the
console sends Application__StopMissionMessage with an ExitCodeID -- a
full remote-operations menu (run game/test patterns/ResetRIO/Norton/
SoftwareReset/camera/mission review) that the game hands to netnub as
its exit code for the pod loop to dispatch. The egress-hold length is
entirely the console's decision. Also documented the seat-trim-inside-
hull z-fighting lookalike (not a render bug).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The TeslaSuite console connected near-instantly over the new host
bridge, queued and ran a real 2-minute mission on the DOSBox pod, and
the mission exited on time. Wire-logged recycle: clean FIN/RST teardown
at mission end, console SYN-retrying 11s later, riding through dead-air
and connection-refused (pre-TCP_LISTEN) phases, reconnected 54s after
teardown with zero operator interaction. Modern console + net_loop.conf
pod = fully autonomous mission loop.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Windows host apps can now talk to the pod directly: static 200.0.0.1/24
on the Network Bridge adapter plus the Npcap SendToRxAdapters registry
value for the bridge GUID (driver-start read, so bounce the npcap
service and relaunch the pod). Verified with a host TCP connect to
200.0.0.113:1501. Documented the trade (pod frames go up to the host
stack INSTEAD of out to the TAP members -- SheepShaver console is deaf
while set), the revert, and the future both-at-once fix (Npcap >=1.83
user-mode DLLs + a second per-handle MODE_SENDTORX send handle in the
fork's pcap backend). Groundwork for the TeslaSuite .NET console
driving the DOSBox pod.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Three-mission live session on net_loop.conf: the pod side is fully
retail-faithful (netnub auto-relaunches on mission end AND console
disconnect, ~60s cycle). Console 4.10's between-missions dead-end is
app-level: its TCP receives FIN+RST from the fresh netnub yet the app
never re-queries; only an app relaunch (endpoints rebuilt from the INI)
recovers it. Selecting a printer in the Chooser makes the app launch
much faster (Printing Manager stalls without one) but does not change
the dead-end. Documented the working operator rhythm and the plan for
bridging the host-side .NET console onto the pod LAN (bridge adapter
IP 200.0.0.1/24, possible Npcap SendToRx for pod->host hairpin).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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>
Console queues a mission -> egg over the wire -> pod loads + runs it -> all
cockpit heads render -> mission ends on the console timer. Four fixes:
1. ne2000.cpp: don't BX_PANIC on the TCR inhibit-CRC / auto-tx-disable bits.
A full production boot runs the packet driver's internal loopback
self-test, which sets those bits; Bochs' NE2000 aborted the whole
emulator. Record them in TCR state instead (harmless for an emulated NIC;
pcap/host does framing+CRC). Also fixes a latent coll_prio bit-4 vs bit-3
round-trip bug. Committed copy in vpx-device/.
2. Confirmed the mission-load page fault (00FF:219D) was RIO-OFF; booting
with the RIO live (net_full.conf) loads and runs the mission cleanly.
3. net_loop.conf + net-boot/loop.bat: GO.BAT-style loop so the pod stays
connected to the console and picks up missions as they're queued (the
real pod relaunches netnub after each mission/idle disconnect).
4. HEADLINE: blank MFD/radar heads were an I/O port collision. The VDB
video splitter is hardwired at 0x300-0x31A (palettes 0x300/0x308/0x310);
the NE2000 at nicbase=300 swallowed the game's VDB palette writes ->
vdb_pal stayed zero -> pal_draw decoded every head to black. Same VDB
spam corrupted NIC RX, dropping the console EndMission (mission overran
its timer). Fix: move the NIC to 0x340 (DOSBox nicbase=340 + DOS NET.CFG
PORT 340; must agree). VDB keeps 0x300. Config-only, no rebuild.
Adds: net_full.conf, net_loop.conf, net-boot/ (ODI drivers, NET.CFG@340,
loop.bat, README), vpx-device/{ne2000,ethernet_pcap}.cpp; updates NET-NOTES.md.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Captured a real mission egg delivered from the SheepShaver console to the
DOSBox pod on TCP 1501, no -egg bypass: 8x ReceiveEggFileMessage chunks,
7514 bytes, reassembled byte-perfect (declared notationFileLength=7514).
The egg is the operator's own mission (BattleTech / cavern / night /
freeforall, pilot "cyd", vehicle madcat). This closes the networking
workstream end to end.
- net-tools/decode_egg.py: reassemble an egg from a captured console->pod
TCP payload hex dump (skips interleaved StateQuery polls).
- net-tools/captured_cavern_mission.egg: the delivered egg.
- NET-NOTES.md: milestone writeup + the pod's mission-LOAD crash. The pod
faults loading the mission (page fault, wild ptr 0xFF008B5B, exception
000E at game 00FF:219D, NetNub Munga exit 14) -- a game-side bug in the
mission-load path, separate from networking. Leading suspect: RIO was
disabled for this run and the player vehicle/control setup derefs null.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The emulated SheepShaver console and DOSBox pod now exchange the live
console protocol on TCP 1501. Required chain: rebuild the DOSBox pcap
backend + launch with C:\Windows\System32\Npcap on PATH (npcap DLL
location); a two-TAP Windows bridge (single shared TAP fails); TAP2
MediaStatus=Always-Connected; and binding the pod's pcap to the BRIDGE
MINIPORT (not a member TAP -- member-injected frames aren't re-forwarded),
via realnic=DB5521D (letter-leading GUID fragment; leading-digit is parsed
as an interface index). Captured + decoded the real protocol values
(StateResponse clientID=5/flags=1/host=0/state=1/app=1=BattleTech), which
corrects the earlier synthetic guesses. Full writeup in NET-NOTES.md.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Records that Router mode is NAT (won't reach the pod) and the console<->pod
link needs bridged TAP on both ends: console TCP/IP manual 200.0.0.1, pod
DOSBox-X switched from slirp to pcap on the same segment.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
PEF imports (InterfaceLib/MathLib/ObjectSupportLib only; no AppearanceLib,
no Open Transport libs) plus the resource-fork "MacTCP or OpenTransport"
Gestalt check show it is a classic PPC PowerPlant app: runs System 7.1.2
through Mac OS 9 (practical floor 7.5), classic MacTCP API but happy with
either stack. Recommended SheepShaver target: System 7.5.5/7.6.1 with a
7100/7500/8500 old-world ROM, TCP/IP set to 200.0.0.1.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Decoded the console<->pod message layout from the MUNGA framework headers
(the send/recv impl did not survive -- only headers + a test harness):
NetworkPacket = 16B NetworkPacketHeader + a Receiver::Message; the egg is
delivered as ReceiveEggFileMessage chunks (seq/totalLen/thisLen +
notationData[1000]), a full egg packet = 1040B (matches the VPX nb<=1040
cap). Console splits the mission notation file into <=1000B chunks; pod
reassembles + ACKs. Two bytes-on-the-wire details (stream framing +
PPC/x86 endianness) flagged for the first live capture. Full byte tables
in NET-NOTES.md.
Also moves the extracted console software (Console 4.10 PPC app + per-venue
Console.ini + fonts/logs, resource forks preserved) into
410console/4_10-console-extracted/.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Console 4.10 (PowerPC PEF/CodeWarrior) + Console.ini extracted from the
.sit. Console.ini answers the open protocol question: the console<->pod
TCP port is 1501. Full cockpit endpoint roster recorded; our emulated pod
200.0.0.113 is the cockpit Puck. The real 6100 does not boot but is no
longer needed -- run Console 4.10 under SheepShaver. Only remaining
protocol unknown is the on-stream message framing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The ops console is a Power Macintosh 6100/66 (PowerPC) -> SheepShaver, with
the caveat that the 6100 ROM is incompatible (use a 7100/7500/8500 old-world
ROM; PPC apps are ROM-agnostic). Plan to leverage the real 6100: image its
drive for a faithful SheepShaver console and/or bridge it live to the
pcap-pod to capture the real egg protocol.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
The pods do TCP/IP over Ethernet (WATTCP + NetNub real-mode server;
ops console is master, pushes mission eggs to pods over TCP). Pod is a
static host on an isolated 200.0.0.0/24 LAN (200.0.0.113, console
200.0.0.1); -egg is the dev bypass of this path. Fork already has NE2000
+ pcap/slirp backends; since the emulated card is NE2000 not PCI Lance we
skip the Novell ODI chain and load a Crynwr NE2000 packet driver directly.
NET-NOTES.md has the full architecture + milestone plan (headline goal:
host-side stand-in console pushes an egg over the wire, no -egg bypass).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CydandClaude Fable 5