Files
TeslaRel410/emulator/rio.conf
T
CydandClaude Fable 5 e13575d3ac Phase 2: FIFO transport working + RIO validated on real hardware
RIO (Phase 5) validated with real hardware: with a physical RIO on
COM1 and serial1=directserial realport:COM1, the game's 1996 RIO
driver talks to the board — the 'RIO never came back' error is gone
and expected activity was seen on the RIO board.

VPX FIFO fast path decoded (OUTSW.ASM + capture): after i860 boot the
render protocol pumps 16-bit words to a FIFO data port seen as
0x154/0x155 byte writes, payload starting with the 4-byte action. The
device now extracts FIFO message actions (confirmed vr_init=0 with the
args string, vr_create=1 with node type 0x2D) and echoes replies with
handler-specific overrides from board source VR_REMOT.C (init/statistics
reply action = 1).

Blocked on one unknown: velocirender_sync checks the init reply against
a constant that is neither 0 nor 1, so the Rel 4.10 board differs from
the DPL3 dev source. Needs the Rel 4.10 LIBDPL source or disassembly of
BTL4OPT.EXE at the format string (file offset 0x107772). Device has a
VPX_INIT_REPLY experiment hook for candidate values.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 23:41:49 -05:00

31 lines
765 B
Plaintext

[sdl]
output=opengl
[dosbox]
memsize=32
machine=svga_s3
[cpu]
core=normal
cputype=pentium
cycles=20000
# Phase 5 VALIDATED 2026-07-02: with a real RIO on the host's COM1, this
# passthrough makes the game's 1996 RIO driver talk to the physical board —
# the "RIO never came back from check request?" error disappears and the
# expected activity is observed on the RIO board.
[serial]
serial1=directserial realport:COM1
serial2=disabled
[autoexec]
mount c "image"
c:
set L4CONTROLS=RIO,KEYBOARD
set L4TIMER=
set BLASTER=A220 I5 D1 H5 P330 T6
set VIDEOFORMAT=svga
set TEMP=c:\
set DPLARG=/tranny~.\vrendmon.btl~/i860~.\vrnostex.mng~/device~0x150~/video~svga~/pipes~1~/qual~0x14~/system_tex~0~
32rtm.exe -x
btl4opt.exe -egg test.egg
32rtm.exe -u
echo RIO-DONE
pause