Add TeslaRel410 (original 4.10 games under DOSBox-X emulation)
- Ecosystem doc: new section on the TeslaRel410 project — custom DOSBox-X fork HLE-emulating the Division VPX board to run the original, unmodified Tesla 4.10 BattleTech/Red Planet DOS binaries on current Windows 10 pod hardware (RIO COM1 / plasma COM2 passthrough). Networking facts for SiteLink: WATTCP (real TCP/IP) via NetNub over emulated NE2000 bridged by pcap -> routable in principle; BOOTP is broadcast -> site-local provisioning. - Clarified BT411 and RP411 as the two native Win32 Tesla 4.10 reconstructions (per operator), complementary to the emulation path. - Brainstorm: new game-linking subsection for the emulated originals + open question 11 (NetNub cross-subnet addressing, 30 Hz sim latency tolerance). - CTCL naming note: provenance question is out with VWE veterans. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Claude Fable 5
@@ -30,8 +30,9 @@ live in the docs below.
|
||||
|------|------|
|
||||
| `TeslaSuite` | TeslaConsole (operator console), TeslaLauncher (pod service), the Console↔Pod RPC contract, SecureConfig provisioning, and **vPOD** (virtual pod — our cross-site test double). |
|
||||
| `firestorm` | BattleTech: Firestorm — the MW4/Gameleap-engine game the 16 cockpits run. DirectPlay 4 multiplayer. Contains the drafted 16→32 player-cap plan that a two-bay link needs. |
|
||||
| `RP411` | Red Planet (MUNGA engine, Win32/DX9 port). Console-controlled via Munga protocol, TCP 1501. |
|
||||
| `BT411` | Classic arcade BattleTech (Tesla 4.10) reconstruction on the RP411 engine. Console streams the mission egg over TCP; pods mesh with each other. |
|
||||
| `RP411` | Classic Red Planet — Tesla 4.10 reconstruction as a native Win32 port (MUNGA engine + L4 platform layer, DX9). Console-controlled via Munga protocol, TCP 1501. |
|
||||
| `BT411` | Classic BattleTech — Tesla 4.10 reconstruction on the shared RP411/MUNGA Windows engine. Console streams the mission egg over TCP; pods mesh with each other. |
|
||||
| `TeslaRel410` | The original 1994–96 Tesla 4.10 source/content archive **plus a custom DOSBox-X emulator** (HLE of the Division VPX render board) to run the *original unmodified DOS games* on today's Windows pod hardware — cockpit RIO and plasma passed through on COM1/COM2, pod networking via emulated NE2000. |
|
||||
| (local `PQS/`) | Pod Queue System — PHP/MySQL front-of-house: registration, callsigns, queue, and the HTTP endpoints the game/console poll for the next mission + roster. |
|
||||
|
||||
## Status
|
||||
|
||||
+23
-1
@@ -153,10 +153,28 @@ Fine between trusted operators, but do it deliberately:
|
||||
- Console-must-stay-connected quirk means the WAN link drop kills the match — argues for
|
||||
running the BT console *at the site with the most pods*, or fixing the engine bug.
|
||||
|
||||
### Red Planet
|
||||
### Red Planet (RP411 reconstruction)
|
||||
- Same console-directed model (Munga TCP 1501). Park until BT411 learnings land — shared
|
||||
engine lineage means most answers transfer.
|
||||
|
||||
### Original Tesla 4.10 games under emulation (TeslaRel410)
|
||||
- When the DOSBox-X/VPX emulator matures, the *original* BT/RP binaries land on
|
||||
current pod hardware speaking their original network stack: **WATTCP (real
|
||||
TCP/IP) via NetNub**, surfaced through NE2000-emulation bridged onto the bay LAN
|
||||
via pcap. Because it's plain IP with the emulated pod holding a real bay address,
|
||||
the routed-VPN model extends to them *in principle* unchanged.
|
||||
- Site-local pieces: BOOTP (broadcast) needs an answerer or static config per site —
|
||||
same "provision locally, play routably" pattern as everything else.
|
||||
- Unknowns to test (cheap — emulator instances run on any PC, no cockpit needed):
|
||||
NetNub discovery/mesh addressing across subnets, and the latency tolerance of a
|
||||
30 Hz 1996 lockstep-era sim. Fold into the Phase 0 netem lab once the emulator
|
||||
reaches its networking phase (PLAN.md Phase 6).
|
||||
- Strategic note: BT411/RP411 (native, netcode we can patch) and TeslaRel410
|
||||
(faithful, netcode frozen in 1996) are complementary. If the original protocol
|
||||
proves WAN-hostile, the answer may be "emulated originals for local play, native
|
||||
reconstructions for cross-site" — SiteLink shouldn't promise WAN play for the
|
||||
emulated path until measured.
|
||||
|
||||
## 6. Shared services (the `10.0.0.0/24` rack)
|
||||
|
||||
| Service | Notes |
|
||||
@@ -211,6 +229,10 @@ worth a small design of its own later.
|
||||
whether federation (§4.3) is ever needed.
|
||||
10. **WAN-drop behavior** — for each linked flow, what breaks when the tunnel drops
|
||||
mid-match, and does the bay cleanly fall back to stand-alone?
|
||||
11. **NetNub over routed subnets (TeslaRel410)** — how do the original 4.10 games
|
||||
discover/address each other (read `CODE\*\MUNGA_L4\NETNUB\` + `L4NET` lineage)?
|
||||
Broadcast-dependent or console-directed like their descendants? And what RTT does
|
||||
the 30 Hz 1996 sim tolerate?
|
||||
|
||||
## 9. Phased roadmap (strawman)
|
||||
|
||||
|
||||
@@ -77,7 +77,8 @@ machines on the internet.
|
||||
constants are `_ECTCL_Console` / `_ECTCL_Launcher`; the API is Tesla-centric
|
||||
(`CTCL_GetTeslaCount`, `STeslaInfo`, `MAX_TESLAS 16`, `MAX_CAMERAS 4`) and
|
||||
coin-op-aware (`CTCL_CoinDisplay`). So "Console↔Tesla Control Layer/Link" is our
|
||||
best reading — treat it as inference, not fact.
|
||||
best reading — treat it as inference, not fact. *(Provenance question is out
|
||||
with VWE veterans — update here when word comes back.)*
|
||||
- **Game-agnostic:** app-type constants `_EAT_MW4` and `_EAT_RP` (`ctcl_params.h`)
|
||||
— the same control layer drives both Firestorm and Red Planet. One layer for
|
||||
SiteLink to reason about, not two.
|
||||
@@ -92,7 +93,7 @@ machines on the internet.
|
||||
- **2016 release integrated Mumble** for voice (FS507D postinstall) — cross-site voice is
|
||||
a solved problem: one Mumble server on the shared network.
|
||||
|
||||
### BT411 (classic BattleTech, Tesla 4.10 reconstruction)
|
||||
### BT411 (classic BattleTech — Tesla 4.10 reconstruction, native Win32)
|
||||
- **Console-push model over plain TCP:** the console connects to each pod's `-net <port>`
|
||||
listener (convention 1501/1601), streams the mission egg in 1040-byte framed chunks,
|
||||
then sends `RunMission` twice (`BT411\tools\btconsole.py` documents the full wire
|
||||
@@ -104,10 +105,45 @@ machines on the internet.
|
||||
the `[pilots]` list carry literal IPs? → see BRAINSTORM open questions).
|
||||
- Status: entity/movement replication works; cross-pod combat in progress.
|
||||
|
||||
### Red Planet (RP411 / RP 4.11.4)
|
||||
- MUNGA engine, console game-control via **Munga protocol, TCP 1501** (vendored
|
||||
`Munga Net.dll` in TeslaConsole). Same console-directed model as BT411 (shared engine
|
||||
lineage — `MUNGA_L4\L4NET.CPP`).
|
||||
### Red Planet (RP411 — classic Red Planet, Tesla 4.10 reconstruction, native Win32)
|
||||
- Same lineage as BT411: the classic Tesla 4.10 title carried forward as a native
|
||||
Win32 port (MUNGA engine + L4 platform layer, DX9). Console game-control via
|
||||
**Munga protocol, TCP 1501** (vendored `Munga Net.dll` in TeslaConsole 4.11.4).
|
||||
Same console-directed model as BT411 (shared `MUNGA_L4\L4NET.CPP`).
|
||||
|
||||
### TeslaRel410 — the *original* Tesla 4.10 games under emulation
|
||||
The third route to the classic titles (`C:\VWE\TeslaRel410`): don't port the game —
|
||||
**emulate the 1996 pod computer** and run the original, unmodified DOS executables on
|
||||
the current Windows 10 cockpit hardware. Full plan: `TeslaRel410\emulator\PLAN.md`.
|
||||
|
||||
- **What it is:** archival snapshot of the 1994–96 Tesla:BattleTech and
|
||||
Tesla:Red Planet source + content (Borland C++ 5.0 / TASM, MUNGA + MUNGA_L4), plus
|
||||
complete runnable DOS installs (`sda4\BTLIVE`, `sda4\RPLIVE`).
|
||||
- **The approach:** a custom **DOSBox-X fork** whose main addition is a
|
||||
high-level-emulation device impersonating **Division Ltd.'s VPX render board** at
|
||||
its host interface (INMOS C012 link adapter, polled I/O at port 0x150) and
|
||||
rendering via OpenGL. The cockpit's real **RIO (COM1)** and **plasma display
|
||||
(COM2)** are passed through to physical serial ports so the game's own 1996
|
||||
drivers run the actual cockpit hardware; SB16 emulation feeds the speakers.
|
||||
- **Ultimate goal:** deploy to the current pods — power-on → attract mode, playable
|
||||
in the cockpit (plan estimates ~3–5 months focused work; gauges deferred).
|
||||
- **Networking — the SiteLink-relevant part:** the original pods networked over
|
||||
Ethernet using **WATTCP (DOS TCP/IP, with BOOTP) via VWE's NetNub layer**
|
||||
(`CODE\*\MUNGA_L4\NETNUB\`). The emulator exposes this through **NE2000 emulation
|
||||
bridged via pcap** — i.e. the emulated game gets a real presence on the bay LAN
|
||||
with its own MAC/IP. Consequences:
|
||||
1. It's plain IP — in principle it routes across a SiteLink VPN like any other
|
||||
bay host (an emulated pod could be a `10.0.y.x` address).
|
||||
2. **BOOTP is broadcast** — the boot-time address assignment is site-local; each
|
||||
site needs its own BOOTP answerer (or static WATTCP config). Same pattern as
|
||||
SecureConfig beacons: provisioning local, play routable.
|
||||
3. Pod-to-pod/console addressing inside NetNub (discovery, mesh formation,
|
||||
latency assumptions of a 30 Hz 1996 sim) is unverified for cross-subnet play —
|
||||
open question, testable cheaply since emulator instances run on any PC.
|
||||
- **Relationship to BT411/RP411:** two complementary strategies for the same
|
||||
titles — native reconstruction (BT411/RP411, modern netcode we control) vs
|
||||
faithful emulation (TeslaRel410, original binaries, original protocols). SiteLink
|
||||
should assume *both* may want cross-site play eventually.
|
||||
|
||||
### PQS — Pod Queue System (front of house)
|
||||
- XAMPP (Apache/PHP/MySQL) app: registration, callsigns, combined queue displays,
|
||||
|
||||
Reference in New Issue
Block a user