serial: pipe:vrio named-pipe transport, no com0com needed

NamedPipeTransport connects as a client to vRIO's \\.\pipe\vrio (the
DOSBox-X fork's role) and speaks the shared typed-frame contract
(PipeFraming: 0x00 data / 0x01 modem lines, null-modem crossed). The COM
path's DTR reset pulse is replayed in-band on connect. Peer disconnects
and framing violations surface as the 0-byte transport-closed read the
link already understands.

RioTransportFactory routes endpoint strings — pipe:name (vRIO's own
picker syntax) to the pipe transport, everything else to
SerialPortTransport — and is wired into RioCoordinator and all three
RioSerialMonitor modes, so profiles (RioComPort/DefaultRioComPort) and
the bench tools take pipe endpoints anywhere a COM name went.

Gotcha baked into the design: named pipes here have 0-byte buffers, so a
write blocks until the peer reads it, and vRIO also writes its lines
frame before reading — the on-connect pulse frames are therefore queued
as overlapped writes (pipe writes drain in issue order, preserving the
edge positions) instead of blocking the constructor into a mutual
write-first deadlock.

Verified end-to-end against the real VRioDevice + VRioPipeService over
\\.\pipe\vrio: version 4.2 + check replies, 137 analog polls, lamp
commands ACKed, zero framing errors. 322 tests green, both flavors.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Cyd
2026-07-30 10:14:13 -05:00
co-authored by Claude Fable 5
parent 3512c89dca
commit 9cca7c77bd
11 changed files with 670 additions and 9 deletions
+13
View File
@@ -52,3 +52,16 @@ 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.