CydandClaude Fable 5
97caf124a6
Phase 10: RIO hardware exists only on pods + dev boxes, so production is one RIOJoy copy inside each podized game folder, no resident tray. ConfigLocator makes a config.json beside the exe win over %APPDATA%; --exit-with <exe|pid> (CompanionTarget/CompanionExit, 60s startup grace) tears down and quits when the game exits; a starting --exit-with instance waits up to 15s for the predecessor mutex instead of silently exiting. deploy/build-pod.ps1 emits the ~4.5MB drop-in (app + portable config wrapping the profile + start script, no drivers) - verified against the shipped Descent profile. 455 tests; PLAN.md Phase 10 + INPUT-INTEGRATION.md pod section. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
76 lines
4.7 KiB
Markdown
76 lines
4.7 KiB
Markdown
# 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`](src/RioJoy.Core/) | Protocol, profile model, input mapper, HID feeder (class library) |
|
||
| [`src/RioJoy.Tray`](src/RioJoy.Tray/) | Background tray application |
|
||
| [`tests/RioJoy.Core.Tests`](tests/RioJoy.Core.Tests/) | xUnit tests for the protocol core |
|
||
| [`driver/`](driver/) | `RioGamepad` virtual HID driver (KMDF + VHF) — replaces vJoy |
|
||
| [`tools/RioJoySmokeTest`](tools/RioJoySmokeTest/) | On-cabinet end-to-end check of the feeder → driver path |
|
||
| [`tools/XcfRegionExtract`](tools/XcfRegionExtract/) | Extracts cockpit label regions from `riojoy.xcf` → `regions.json` |
|
||
| [`docs/PLAN.md`](docs/PLAN.md) | Full modernization plan |
|
||
| [`docs/PROTOCOL.md`](docs/PROTOCOL.md) | RIO wire format + `iRIO` input-map reference |
|
||
| [`docs/FEEDBACK.md`](docs/FEEDBACK.md) | Game→cockpit feedback endpoint (lamps + plasma over pipe/UDP, rumble) |
|
||
| [`docs/INPUT-INTEGRATION.md`](docs/INPUT-INTEGRATION.md) | Integrator's guide: cockpit→game — routing kinds, pad/axis mapping, profile building |
|
||
| [`docs/OUTPUT-INTEGRATION.md`](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/`](https://gitea.mysticmachines.com/VWE/TeslaRel410/src/branch/main/restoration) archive — board photos, schematics, GAL decode (`restoration/rio-hardware`) and the RIO 4.3 board firmware (`restoration/rio-firmware`) |
|
||
| [`docs/reference/`](docs/reference/) | Cockpit overlay art & the legacy labeling pipeline |
|
||
| [`legacy/`](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`](driver/README.md)).
|
||
|
||
```sh
|
||
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`](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`](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`](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.ini` importer, 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). See [`docs/PLAN.md`](docs/PLAN.md) for the full roadmap.
|
||
|
||
## Testing without hardware: vRIO over a named pipe
|
||
|
||
The [vRIO](https://gitea.mysticmachines.com/VWE/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`](src/RioJoy.Core/Serial/PipeFraming.cs)
|
||
on this side and vRIO's `PipeFraming.cs` / the DOSBox-X fork's
|
||
`serialnamedpipe.h` on the others.
|