Rust-DOS v1.7.4 is available -> https://github.com/dividebysandwich/rust-dos/ … ases/tag/v1.7.4

VFX1 emulation

(Inspired by https://github.com/LeonG-ZA/forte-vfx1-vr)

Enable VFX1 in settings and a headset will appear on the table. You can put it on and take it off at any time - just grab it and put it over your head to wear, and grab it from your head and put it away to remove. Running any VFX1 enabled game will render as stereoscopic 3D inside your VR headset while you are wearing the virtual VFX-1, and will render as left/right eye image on the VR monitor if you remove the VFX-1 from your head.

This is not really something that can be shown with a screenshot - you'll have to try this out yourself.

NOTE: Resolution and FOV are limited to the original as supported by the respective games. This feature only works in VR headsets, it wouldn't make much sense on a 2D screen.

Usable VR keyboard

If you just want to try something out quickly without a connected bluetooth keyboard, there's now a VR keyboard that can be used and grabbed with the VR controllers.

NOTE: The bedroom scene has been updated, please go to the scene list and download the update right inside Rust-DOS.

Improved Vérité and PowerVR support

Several texture and rendering issues are fixed and games should work better across the board.

New logo

By @Dominusprog, thanks!!

## Other fixes and changes:

* Read CD sectors whose EDC fails as errors, so copy protections that check them pass by @kibertoad in https://github.com/dividebysandwich/rust-dos/pull/116
* Round FBSTP as the control word says and store the BCD indefinite for what doesn't fit by @kibertoad in https://github.com/dividebysandwich/rust-dos/pull/117
* Say when a state's drive image has moved, not that the state is of another machine by @kibertoad in https://github.com/dividebysandwich/rust-dos/pull/118
* Document how Windows OpenGL games reach the Voodoo2 by @kibertoad in https://github.com/dividebysandwich/rust-dos/pull/119
* Translate MMX and SSE instructions on x86-64 by @kibertoad in https://github.com/dividebysandwich/rust-dos/pull/120
* Draw 3dfx OpenGL's raster states with variants that fix only the combines by @kibertoad in https://github.com/dividebysandwich/rust-dos/pull/121
* Translate SAHF and FILD of a qword by @kibertoad in https://github.com/dividebysandwich/rust-dos/pull/122
* Start blocks in a page's last 15 bytes on x86-64 by @kibertoad in https://github.com/dividebysandwich/rust-dos/pull/123
* Run SSE arithmetic without loading MXCSR where the guest's matches by @kibertoad in https://github.com/dividebysandwich/rust-dos/pull/126
* Read IDE disk blocks at once in REP INSW and INSD by @kibertoad in https://github.com/dividebysandwich/rust-dos/pull/127

Full Changelog: https://github.com/dividebysandwich/rust-dos/ … v1.7.3...v1.7.4

Glad you liked it.

SVG+PNG

An error is reported in-game by this dos port: DevilutionX DOS port (still being worked on). It shows a dialog box without a crash, but describes an error: "Lua error when loading lua\inspect.lua: table index is NaN". I press the Ok button in the dialog box and the application exits. I tested with both interpreter and dynamic cores. However, the game runs without an error in a version of dosbox-x. The port depends on SDL3 and a modification for multithreading.

I parsed the logs of Rust-DOS for these lines of interest:

hail-to-the-ryzen wrote on 2026-10-17, 16:32:

An error is reported in-game by this dos port: DevilutionX DOS port (still being worked on). It shows a dialog box without a crash, but describes an error: "Lua error when loading lua\inspect.lua: table index is NaN".

You actually stumbled over some of my original (hand-written) FPU code from last year. In my defense, I was writing these instructions off of the book and the FCOM and FCOMP aliases are undocumented. Looking into how dosbox-staging helped. Yet another reminder how just how much knowledge is in dosbox that isn't documented anywhere else.

Your work is appreciated on both fronts! The logging in both software is insightful and simple to parse, along with the powerful debugger and extensive unit tests that are engineered into your emulator. For testing the error, I rebuilt the binary from source, including cross-compiler (v14.2.0), sdl library, related dependencies, and the code for the port itself which is definitely robust. That procedure is reasonably documented but the various versions of each piece together make reproducibility more of an ideal than practice. However, this helped to confirm this above corner case and its sensitivity to number precision. Your unit tests will certainly self-document these above cases and are as invaluable as the formalized commits. As an aside, there is also another interesting base of code here: https://github.com/cyanbun96/qrustyquake. This may be adaptable to a similar pipeline as this above vesa-based port, but it may require a good bit of work on memory and performance constraints. Maybe it is simpler to backport its increased compatibility commits to an existing dos-based port, if only to see the influence of extending the software renderer on the frame rate.

Rust-DOS v1.7.5 has been released -> https://github.com/dividebysandwich/rust-dos/ … ases/tag/v1.7.5

3dfx Voodoo3 and Banshee

Finally, Voodoo 3 emulation! Simply set `machine=svga_voodoo3` or `machine=svga_banshee` . With 3dfx's Voodoo3 driver on Windows 98 SE you get the accelerated desktop, Glide, Direct3D and OpenGL through the ICD. Windows will correctly discover a Plug and Play monitor thanks to an emulated EDID, and the vertical retrace interrupt is there too. Thanks to @kibertoad for this one!

Note: Direct3D on the Voodoo3 needs DirectX 7 or later, as mentioned in the driver's readme. Windows 98 SE comes with 6.1, so install `dx70eng.exe` first. Games that ship 3dfx's MiniGL as `opengl32.dll` in their own folder need that file removed to use the ICD.

ATI 3D RAGE and 3D RAGE II

`machine=svga_ati_3drage` and `machine=svga_ati_3drage2` give you ATI's mach64 GT and GT-B, with the 2D draw engine, 3D triangles, the scaler and the video overlay. Windows 98's own driver runs the desktop, DirectDraw and Direct3D, and Wipeout for 3D Rage (the game ATI bundled with the card) runs through ATI3DCIF.

PowerVR PCX1

Next to the PCX2, there's now `powervr=pcx1` for the first PowerVR chip (VideoLogic Apocalypse 3D), so games with a PCX1-only version, like Tomb Raider's TOMBPCX1.EXE, now work too.

Vérité RISC emulation

Rust-DOS now emulates the Rendition Vérité's RISC processor, and this is the new default (`verite_risc=lle`). Instead of recreating the microcode's commands, rust-dos now runs the card's actual microcode, so games that bring their own, such as CGL titles like Battle Arena Toshinden, Rebel Moon, Flight Unlimited and Hi-Octane, now work alongside Tomb Raider and vQuake. Windows 95 also runs with both Rendition drivers. `verite_risc=hle` is still available in case you need the HLE-only emulation.

Rat Commander

Have a fresh installation of Rust-DOS but no Norton Commander at hand?

Type `RC` at the prompt for Rat Commander, a classic 2-panel file manager with the most importanat features built-in: marking, copy, move, rename, delete, view, edit, menus and mouse support. It can even work with `.ZIP` archives.

More accurate FPU

A series of fixes makes the FPU behave more like the real chip in edge cases: infinities, NaNs and overflow in FADD/FSUB, FPREM/FPREM1 quotient bits, FYL2X of 0 and negative values, FSCALE, FXTRACT, FCHS, out-of-range trig, and several register mixups in FCOM/FUCOM/FXCH. The recompiler now also translates CMOVcc, FSQRT and FIDIV/FIDIVR, and instructions that cross into the next page.

Windows 95/98 system image guide

There's a new guide, [docs/win9x-howto.md](https://github.com/dividebysandwich/rust-dos/ … /win9x-howto.md), that walks you through making a Windows 95 or 98 hard disk image and using it with game packages: as a desktop of its own, with games that run from a folder, and with games that have to be installed.

Other fixes and changes:

* Count IDE data port transfers as disk I/O for cycles=auto by @kibertoad in https://github.com/dividebysandwich/rust-dos/pull/128
* cycles=auto: give a program that keeps Windows busy all the host has by @kibertoad in https://github.com/dividebysandwich/rust-dos/pull/130
* Emulate the 3dfx Voodoo3 and Banshee, with 3D, EDID and the retrace interrupt by @kibertoad in https://github.com/dividebysandwich/rust-dos/pull/131
* Translate CMOVcc, FSQRT and FIDIV/FIDIVR by @kibertoad in https://github.com/dividebysandwich/rust-dos/pull/134
* Translate instructions that run on into the next page by @kibertoad in https://github.com/dividebysandwich/rust-dos/pull/135
* DOSBox configuration imports: rust-dos's own settings in the file now win over the imported ones, DOSBox's S3 is kept and `[rust-dos] machine=` is honored, the prompt says when a game has ended and its drives are back, and the libretro save folder is no longer nested (#129)
* The Windows 95 shutdown message now shows correctly when Windows leaves the screen in a graphics mode
* A windowed DOS box on the Voodoo3/Banshee desktop no longer switches the desktop off
* PCI cards can now share IRQ lines
* FindFirst only returns `.` and `..` when the search asks for directories

Thank you. I ported qrustyquake to DOS via SDL3. It depends on several minor code edits, such as in the video output so the pixel format is correct. It works in a variant of dosbox-x, including the Arcane Dimensions mod (latest version). However, the performance is slow where the advanced feature set is active, while vanilla Quake runs better. It also runs in rust-dos v1.75, but not with the simpler AD mod maps. I believe the heap allocation is not sufficient. There are a few causes for this, including restrictions for accuracy in emulation, but I included an abbreviated log if it is of interest in the future (rust-dos is currently adding emulation that would support qrustyquake for win32 anyways, so this dos port has no advantage here). I also think the dos port has less compatibility with DOS era systems, so it is mainly for testing the advanced features and performance in vesa/32bpp. I also can post details on the patch which is highly experimental at this time. I am currently testing on why the dpmi provider, cwsdpmi (I also tested hdpmi32), is not able to allocate memory above a 32mb level in this setup. I have already tested various combinations of the emulator parameters, too.