CydandClaude Opus 5
46e108de89
Three endpoint gaps, found building the Descent 3 score overlay - the boxed place|score field the original games drew over the callsign: plasma box <x> <y> <w> <h> draws an outlined box with a blanked interior, the overlay chrome, as one ESC P graphics write. The wire addresses whole bytes horizontally, so the write covers the byte-aligned span containing the box and clears span pixels outside it; documented, with 8-px alignment the advice. Boxes queue FIFO with rows. plasma text gains an explicit font: a third numeric token after the position, with text still following, so `plasma text 2 2 7` still displays "7". Auto-fit picks the font by LENGTH - short text always rendered large, and a "1" that must fit a 12-px box simply could not be sent before. ResolvePosText generalizes the legacy Score-font special case: 0 = auto, nonzero honored. Text coalescing is now per position. The global rule - any queued text superseded every other queued text - meant the documented two-field layout (callsign top, score bottom) could not survive its own send burst: the second field silently ate the first whenever both were queued. A newer text now replaces only a queued text at the same (x,y). 15 new tests; 472 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
RIOJoy
Modern Windows 10/11 interface between the cockpit RIO (Remote Input/Output) board and Windows, as a virtual joystick / keyboard / mouse — the successor to the legacy vJoy-based app, with no vJoy dependency.
The RIO has 72 digital inputs and outputs (lighted buttons) and 5 analog axes (joystick X/Y, throttle, left pedal, right pedal), connected over RS-232 at 9600 8N1. RIOJoy exposes these to games that don't natively know about the cockpit hardware, with per-game profiles. (The native games — Firestorm, Red Planet — talk to the RIO directly and do not use this app.)
Repository layout
| Path | Contents |
|---|---|
src/RioJoy.Core |
Protocol, profile model, input mapper, HID feeder (class library) |
src/RioJoy.Tray |
Background tray application |
tests/RioJoy.Core.Tests |
xUnit tests for the protocol core |
driver/ |
RioGamepad virtual HID driver (KMDF + VHF) — replaces vJoy |
tools/RioJoySmokeTest |
On-cabinet end-to-end check of the feeder → driver path |
tools/XcfRegionExtract |
Extracts cockpit label regions from riojoy.xcf → regions.json |
docs/PLAN.md |
Full modernization plan |
docs/PROTOCOL.md |
RIO wire format + iRIO input-map reference |
docs/FEEDBACK.md |
Game→cockpit feedback endpoint (lamps + plasma over pipe/UDP, rumble) |
docs/INPUT-INTEGRATION.md |
Integrator's guide: cockpit→game — routing kinds, pad/axis mapping, profile building |
docs/OUTPUT-INTEGRATION.md |
Integrator's guide: game→cockpit — lamp address map, plasma display model, recipes |
| RIO board hardware & firmware | Moved to the TeslaRel410 restoration/ archive — board photos, schematics, GAL decode (restoration/rio-hardware) and the RIO 4.3 board firmware (restoration/rio-firmware) |
docs/reference/ |
Cockpit overlay art & the legacy labeling pipeline |
legacy/ |
Original C++/vJoy implementation, kept as reference |
Building
Requires the .NET SDK (8.0 or newer) plus the .NET Framework 4.8
targeting/developer pack, on Windows. The apps target .NET Framework 4.8,
which is in-box on every Windows 10/11 machine — so deployed builds are
framework-dependent and need no runtime install on the target. The driver
builds separately with the WDK (see driver/README.md).
dotnet build RioJoy.sln -c Release
dotnet test RioJoy.sln
Status
Phases 1–5, 9 and 10 are implemented and tested (455 unit tests). Games (or sim
export scripts) can drive the cockpit lamps and plasma display back through the
running app — see docs/FEEDBACK.md. For cockpit cabinets,
RIOJoy deploys bundled per game (deploy\build-pod.ps1, portable config +
--exit-with self-teardown) rather than resident — see the pod section in
docs/INPUT-INTEGRATION.md. The RioGamepad virtual
HID driver is built (KMDF + VHF), test-signed, installed, and verified: it
enumerates in joy.cpl, and the C# HID feeder (DeviceIoControl →
RioGamepad.sys) drives its axes, buttons, and hat end-to-end (see
tools/RioJoySmokeTest). The C# side covers the serial
- RIO protocol core, input mapping + output routing, axis calibration + plasma
display, the tray app + profiles (JSON config,
RIO.iniimporter, three-state auto-switch), and the HID report packer that matches the driver's wire format. Remaining work is on-cabinet (real RIO serial/axis/plasma/auto-switch verification) plus packaging (Phase 6) and the profile editor + overlay generator (Phase 7). Seedocs/PLAN.mdfor the full roadmap.
Testing without hardware: vRIO over a named pipe
The vRIO device emulator can stand
in for the real board with no com0com pair: anywhere a COM port name is
configured — a profile's RioComPort, the app-wide DefaultRioComPort, or the
RioSerialMonitor [port] argument — the endpoint pipe:vrio connects to
vRIO's \\.\pipe\vrio instead (vRIO must have its pipe endpoint open). Serial
bytes and modem lines (including the DTR reset pulse on open) travel as typed
frames over the pipe; the contract lives in
src/RioJoy.Core/Serial/PipeFraming.cs
on this side and vRIO's PipeFraming.cs / the DOSBox-X fork's
serialnamedpipe.h on the others.