CydandClaude Fable 5
6a595cc565
RP's cockpit displays decoded near-empty (top-strip only, a copy off-screen at VRAM 0x100000) while BT's were full. Root cause was NOT the VDB decode (byte split/palettes/stride all correct, proven by BT) but an SVGA bank-switch GRANULARITY mismatch: RP's REL410/RP/GAUGE/L4GAUGE.INI [640x480x16] used granularityInKB=4 vs BT's 64 on the same STB Horizon+ (CL-GD5434). DOSBox-X's CL-GD5434 bank emulation handles 64KB granularity (BT full) but mishandles the 4KB-granular paged gauge writes, scattering them off-screen. FIX (config, no rebuild): RP L4GAUGE.INI granularityInKB 4->64 (matches BT, same card). VERIFIED live: VRAM content scan went from 0x0+0x100000 (top-strip + off-screen) to the FULL framebuffer 0x0..0x90000 populated; radar + upper-center MFD confirmed correct, rest under reference check. Also commits the VDB diagnostic tooling that found it (vpxlog.cpp, all default-off): VDB_SCAN (VRAM content locator -- decisive), VDB_PALDUMP, pixel-mask value logging, VDB_REALSTRIDE + live mode/stride/start logging, VDB_BASE read-base override, VDB_APPLYMASK DAC-mask honoring. Full writeup in VDB-NOTES.md. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
VPX + AWE32 devices — DOSBox-X integration
Our original source for the emulated pod hardware. Kept here under
version control because the DOSBox-X source tree itself
(emulator/src/, ~490 MB) is git-ignored.
vpxlog.cpp— the Division VPX link adapter (INMOS C012 at I/O base0x150), grown through Phase 3: iserver handshake responder, FIFO scene decode, GL Division renderer (gallery shading model), VDB video-head splitter windows.vweawe.cpp— the dual-AWE32 sound device: two vendored EMU8000 cores at 0x620/0x640 (+0x400/+0x800 triplets), rear-card DSP/mixer stub at 0x240, autonomous render thread with direct winmm output. Needs the GM ROM (emulator/roms/awe32.raw) viaVWE_AWE_ROMor SoundFont uploads are refused (banks declareirom=1MGM). Seeemulator/SOUND-NOTES.md.emu8k.cpp/emu8k.h/emu8k_shim.h— EMU8000 wavetable core vendored from 86Box (GPL-2.0-or-later, same license as DOSBox-X), with a minimal shim; local changes are listed in the emu8k.cpp header.
Applying to a DOSBox-X source checkout
Tested against DOSBox-X v2026.06.02, MSYS2 mingw64.
- Copy the devices in:
cp emulator/vpx-device/vpxlog.cpp emulator/src/src/hardware/ cp emulator/vpx-device/emu8k.cpp emulator/src/src/hardware/ cp emulator/vpx-device/emu8k.h emulator/src/src/hardware/ cp emulator/vpx-device/emu8k_shim.h emulator/src/src/hardware/ cp emulator/vpx-device/vweawe.cpp emulator/src/src/hardware/ - Add them to the hardware build — in
src/src/hardware/Makefile.am, appendvpxlog.cpp emu8k.cpp vweawe.cpptolibhardware_a_SOURCES(we inserted them afterglide.cpp; if you edit the generatedMakefile/Makefile.inby hand instead of re-running automake, also mirror the$(OBJEXT)list, the.Podepfile list, and the depfile include markers — grep for howvpxlogappears and copy the pattern). - Call the inits — in
src/src/gui/sdlmain.cpp, declarevoid VPXLOG_Init();andvoid VWEAWE_Init();next to the other*_Init()prototypes; callVPXLOG_Init();right afterGLIDE_Init();andVWEAWE_Init();right afterSBLASTER_Init();(it needs the mixer initialized). - Build:
Output:
cd emulator/src ./build-mingw-sdl2 --enable-debug=heavysrc/src/dosbox-x.exe.
Running
set VPXLOG=C:\VWE\TeslaRel410\emulator\vpxlog.txt
emulator\src\src\dosbox-x.exe -conf emulator\capture.conf
python emulator\analyze_capture.py
With VPXLOG unset the device is inert and the build behaves like stock
DOSBox-X.