LSS10999+RayeR: GDI is still pain, there 2 two reasons for this, first is that DIB driver is reading from GPU (when scrolling, it reads block from VRAM, moves pointer of x lines and writes it back). Second is that the DIB engine runs in PM16 and all operations crossing segments are super slow. Other drivers are solving this with HW blit, but in VESA is nothing like that. Solution can be shadow frame buffer in RAM and updating by one way copy to video ram. I’m already doing when emulating double buffering (on VMware), but shadow buffer is still in VRAM, but essence is similar. I can also implement BLIT in PM32 RING-0 (more important is PM32 than RING-0), resp. I can use existing code from HAL, but I think that reading operations from GPU are main bottleneck.

Fortunately, I made the things bit faster by is by implemented my own procedures for working with the mouse cursor, but GDI is still quite slow.

I've tested the newest version (v0.8.2025.53 special edition available for donators) on my ThinkPad X230 and DOS windows work quite well (even in windowed mode, tested only text applications) and window dragging/scrolling/shutdown animation are not as laggy as with VBEMP.
The update modes option from the tray icon worked fine and after performing it - 1366x768 resolution showed up correctly.

In 3DMark2001 SE with default installation settings I got... 241 points 😜 But all game tests did complete.

DX7/DX8/DX9 video tests in DXDiag are working, though of course, the cube spins somewhat slowly.

There are too many options in the installer and too many hardware I have...and not enough time to test everything 😒

I've also enabled the AVX hack, but llvmpipe still shows only 128bit.

JH64 wrote on 2025-08-01, 08:02:

LSS10999+RayeR: GDI is still pain, there 2 two reasons for this, first is that DIB driver is reading from GPU (when scrolling, it reads block from VRAM, moves pointer of x lines and writes it back). Second is that the DIB engine runs in PM16 and all operations crossing segments are super slow. Other drivers are solving this with HW blit, but in VESA is nothing like that. Solution can be shadow frame buffer in RAM and updating by one way copy to video ram. I’m already doing when emulating double buffering (on VMware), but shadow buffer is still in VRAM, but essence is similar. I can also implement BLIT in PM32 RING-0 (more important is PM32 than RING-0), resp. I can use existing code from HAL, but I think that reading operations from GPU are main bottleneck.

Fortunately, I made the things bit faster by is by implemented my own procedures for working with the mouse cursor, but GDI is still quite slow.

Did some tests with the new driver.
- It seems GDI performance is indeed weak. Explorer windows, as well as games such as Solitaire, draw much slower compared to VBEMP9x.
- Mouse cursor may flicker when the system is busy. I don't recall this happened with VBEMP9x, but probably related to GDI performance.
- Scrolling in WordPad may perform a bit better compared to VBEMP9x under some circumstances, but still very slow.
- The background darkening effect when opening the Shutdown dialog, however, does not differ much in drawing time compared to VBEMP9x.

I think this driver's memory test may not be a good idea for baremetal video cards, and better leave it disabled by default in such cases.
- With AMD video cards this will lead to the BSOD you mentioned, requiring the use of "NoMemTest"="1", when setting especially a 32-bit color resolution.
- With nVidia video cards the BSOD doesn't occur but the memory test can mess up the display the moment before Windows actually starts, if startup logo enabled. This is mostly harmless, though.

By the way, Direct3D does work with this driver, and can be tested with DXDIAG. The performance is far from ideal, however.

I just noticed another thing with the new driver, regarding issues with DOS boxes.
- DOS games that tries to change to a fullscreen VGA mode while in a windowed DOS box will fail and stuck in text mode. This includes starting the DOS game's executable directly.
- Making MS-DOS Prompt enter full screen will lead to a totally blank screen with only the text cursor visible, but works normally, as if it's just the text mode fonts were emptied. DOS games, if launched in this state, will work properly. Exiting the game will make text mode fonts visible again.
- The issue above also applies to "Exit to DOS" in the shutdown options. Exiting to DOS directly will lead to an empty text mode, but if I started a DOS game in a fullscreen "MS-DOS Prompt" then exits (which restores text mode), text mode will work normally upon exiting to DOS.

On the other hand, this breakage somehow avoided an annoying issue I'm having on a system that is using an nVidia video card, that it would cause the system to hang for a while, beep, then resume afterwards, whenever I open an "MS-DOS Prompt", and could also happen with certain programs invoked by installers in the background (without actual window). With this driver the issue doesn't happen. On systems with AMD cards this manifests as flickers (screen turning blank for a brief moment) without any hang/beep, and also doesn't happen with this driver.

EDIT: Okay, just read the CONFIG.MD and it seems this particular parameter (DosWindowSetMode) is responsible for controlling the modeset functionality. By default this is 0 so DOS programs cannot set mode, which also prevents any odd behavior that may happen (like nVidia cards touching the CRTC register).

MrMateczko: I’m glad that works. For using AVX in LLVMpipe is needed to set in registry HKEY_LOCAL_MACHINE\Software\vmdisp9x\apps\global\mesa\LP_NATIVE_VECTOR_WIDTH to “256” - sorry to make this complicated, but I’m bit paranoid about CPU registers when the operation system has no idea about they existence.

LSS10999: thanks for testing and comparison with VBEMP9x. About slowness I’m able to underline VRAM with RAM and sending changes to VRAM - this speeds up system GUI but slow down multiple buffering in games and fullscreen application – there are more ways how to solve it, so far, I like the linear framebuffer memory to be mapped partly to video ram and partly to system ram depending on whether it is a system area or flipping surface.

Mouse cursor is hidden between system GUI start drawing and end drawing, normally it is fast enough to be invisible. When system routines for software cursor is used, cursor is only remove from area which is accessed (not whole screen), this reduce flashing effect but isn’t 100 % safe and you can time to time see cursor remains variously across the screen – this is significantly in DD/DX games, because most accelerated application assumes that cursor is hardware accelerated. When I’ll create extra buffering, this effect disappear.

Also, I’ll turn off video ram testing and believe that reported framebuffer is size is real. Problem with DOS window I describe here - you probably already found it (fix is start the DOS games in fullscreen), and I’m not having better solution, with the driver I can forbid the DOS application to exit fullscreen but can’t able to forbid the enter to fullscreen (I wonder what was going through the mind of whoever came up with this behaviour... but rather not 😀 ).

Conclusion what I’ll able to fix (I hope):
- slowness in system GUI
- reduce cursor flashing
- disable VRAM test by default
- better check AMD 16bpp modes
- check state when system has multiple video cards (or one double head) and use only first one (BSOD currently)

What I won’t be able to fix:
- 3D rendering speed (or not much)
- DOS window behaviour

I think I'll fix the things that can be fixed in a few days. The others stay unfixed until something enlightens me 😀

JH64 wrote on 2025-08-02, 21:31:

LSS10999: thanks for testing and comparison with VBEMP9x. About slowness I’m able to underline VRAM with RAM and sending changes […]
Show full quote

LSS10999: thanks for testing and comparison with VBEMP9x. About slowness I’m able to underline VRAM with RAM and sending changes to VRAM - this speeds up system GUI but slow down multiple buffering in games and fullscreen application – there are more ways how to solve it, so far, I like the linear framebuffer memory to be mapped partly to video ram and partly to system ram depending on whether it is a system area or flipping surface.

Mouse cursor is hidden between system GUI start drawing and end drawing, normally it is fast enough to be invisible. When system routines for software cursor is used, cursor is only remove from area which is accessed (not whole screen), this reduce flashing effect but isn’t 100 % safe and you can time to time see cursor remains variously across the screen – this is significantly in DD/DX games, because most accelerated application assumes that cursor is hardware accelerated. When I’ll create extra buffering, this effect disappear.

Also, I’ll turn off video ram testing and believe that reported framebuffer is size is real. Problem with DOS window I describe here - you probably already found it (fix is start the DOS games in fullscreen), and I’m not having better solution, with the driver I can forbid the DOS application to exit fullscreen but can’t able to forbid the enter to fullscreen (I wonder what was going through the mind of whoever came up with this behaviour... but rather not 😀 ).

Conclusion what I’ll able to fix (I hope):
- slowness in system GUI
- reduce cursor flashing
- disable VRAM test by default
- better check AMD 16bpp modes
- check state when system has multiple video cards (or one double head) and use only first one (BSOD currently)

What I won’t be able to fix:
- 3D rendering speed (or not much)
- DOS window behaviour

I think I'll fix the things that can be fixed in a few days. The others stay unfixed until something enlightens me 😀

There's no need to change the DOS window behavior regarding forbidding modesetting by default. It's better this way as this avoids many issues, which is also affecting VBESVGA and it's currently blocking a system from booting Win3.x in 386 Enhanced Mode properly. As for the text mode font getting emptied... not sure what caused it initially, but when I tried exiting to DOS from Windows directly (without starting any fullscreen DOS program) yesterday, I did not get the issue and the DOS command line was working properly.

By the way, is it possible to initialize the back buffer before the system startup? When Windows is right about to start, the screen would briefly flash with some garbled stuffs consisting of whatever that was in the video memory, similar to this issue that I once observed in VBESVGA (now fixed). I did not recall seeing this with VBEMP9x, though.

Don't know under what circumstances would the other parameters (HWDoubleBuffer and MTRR) make any difference. Tried fiddling with this parameter on one system but no noticeable difference in performance...

MTRR should be always set to write combining mode, it brings significant memory transfer speed up (on PCIe systems usually a magnitude higher or more). It can be set by other tool (e.g. with my mtrrlfbe) before win9x boots s no need to implement it in drivers, AFAIK VBEMP implemented this itself. Sometimes on some modrn systems it may happen MTRR are not set properly and then no difference in performace visible. It may be tricky as sometimes there are no enough free MTRRs left for LFB settings...

RayeR wrote on 2025-08-03, 14:06:

Sometimes on some modrn systems it may happen MTRR are not set properly and then no difference in performace visible.

if machine supported more 64 GiB total memory — UEFI set Default memory type (IA32_MTRR_DEF_TYPE MSR 2ffh = 06 0c 00 00 00 00 00 00) to WB, and need patch UEFI to resolve problem. veryfied on Huanazhi X99-TF + Xeon e5-2666 v3.

I tried to check all this. Using the example of the trial version of ColinMcRaeRallyDemo.exe (1998), which has serious compatibility problems with nVidia under Windows 98 + ForceWare 60.86 (and above), which affects ALL PCI-E video cards from nVidia that are compatible with 9x, as well as all PCI\AGP solutions based on the NV40 chip (and above, up to the G7X). Specifically, the main game menu is not displayed (the game itself works flawlessly). Similar problems are found in some other DirectX 6 games.

1) Using "softgpu-0.6.2024.36.iso" managed to make the game work:

Here are used - ddraw.dll, wined3d.dll, winedd.dll and OpenGL32.DLL (SoftWare). The main game menu is displayed correctly, the game works correctly. But there are three significant disadvantages:

- very low performance (About 30FPS);
- there are no anti-aliasing\filtering effects (AA\AF) x16, which makes the image look bad - there are "steps" and constant flickering of textures, objects, and other particles, which is especially noticeable in motion);
- for some reason, the car looks "flattened": for comparison, here is how the car looks on real hardware:

2) Now I tried to use hardware acceleration using the same set from "softgpu-0.6.2024.36.iso" (ddraw.dll, wined3d.dll, winedd.dll), except for the software "OpenGL32.dll" (Instead, it uses the shared system OpenGL32.dll + nvOpenGL.dll version 71.84 from nVidia, OpenGL Version: "1.5.3"). Surprisingly, the game is working (although it is not documented). The main game menu is now fully displayed. However, the game itself is played almost correctly:

What's noteworthy is that it has a very good stable FPS (the same as with native DDRAW.DLL on real hardware) and it seems to correctly apply AA\AF x16. However, there is a significant drawback that you may have already noticed... It's a bit disappointing, isn't it? It's as if it's missing just a little bit to finally work properly with any problematic ForceWare driver, ranging from 60.86 (GL Version: 1.5.1) to 82.69 (GL Version: 2.0.1).

In the new version of "softgpu-0.8.2025.50.iso", there was even a slight regression compared to the version tested above, and the "wined3d.dll" component was completely broken (the game now displays a black screen, although the game itself works and the sound is audible) 🙁

PS: I was able to localize the problem a bit: specifically, any version of "wined3d.dll" newer than "1.7.55.38-sse3" causes a black screen (this is the latest version that still works reasonably well). Versions "wine9x-1.7.55.40-sse3" and "wine9x-1.7.55.45-sse3" already stably cause a black screen, immediately, when starting the game and regardless of the used type of OpenGL (llvmpipe\softpipe\nvOpenGL). At that, after leaving the game, the desktop image no longer appears, until the OS reboot.

update:

I have tested "softgpu-0.8.2025.53.iso" and the "black screen" problem persists in this version as well. It seems to be a global change in "wined3d.dll". To work around this problem, you can roll back "wined3d.dll" to version "1.7.55.38-sse3" (or lower), or disable hardware acceleration in the display settings, and everything will work, but only SoftWare:

RayeR wrote on 2025-08-03, 14:06:

It may be tricky as sometimes there are no enough free MTRRs left for LFB settings...

In this case, the default WB will help.

For those that tested SoftGPU, did it surpass PCem/86box or QEMU-3dfx?

What's the compatibility like on this OpenGlide Win9x fork? Do we know what OpenGL support it requires? I tried using it on my GeForce 4 Ti 4600, but I didn't get far.
I also can't do anything now because the solder balls on the GPU are cracked, sadly.

I created three virtual machines using VirtualBox 7.0.26 (with VboxVGA, VMSVGA (OS listed as Linux), and VboxSVGA (OS listed as Windows 7) video adapters). Three had ICH AC97 sound cards, and three more had SoundBlaster 16. I decided to test several games there and chose NFS 2. However, when launching, I get either this ugly behavior:

or error messages like these (mine are in Russian. Translate if necessary):

I was only able to get it working on the VMSVGA and VboxSVGA virtual machines. What should I do with VboxVGA?
All the virtual machines have the latest SoftGPU drivers. What's causing this?

Is there anything new ready for testing?

I did notice this commit pushed after the latest release that introduced the VESA driver: https://github.com/JHRobotics/vmdisp9x/commit … dd3d05cbeb50c31

So had the known issue (notably 16-bit showing wrong colors on AMD GPUs) fixed?

On the other hand, I just tested on a system with AMD GPU using "Nine" for DX8 and DX9. While D3D8 worked fine, D3D9 appears broken.

On my first testing of D3D9 it got stuck with a small, frozen window on the upper-left corner that I have to use CTRL-ALT-DEL to close it (along with DXDIAG). Subsequent tests of D3D9 directly (skipping previous tests) resulted in the spinning cube having more distorted colors than D3D7/16-bit modes with the screen showing staircase-like flickering.

After closing the DXDIAG window I'm getting an endless amount of "illegal operation" error message about DXDIAG that can only go away by rebooting.

With "Nine", the spinning cube in D3D8 test showed correct colors, while D3D7 (using HAL) is showing incorrect colors like in 16-bit modes. I'm not sure if D3D8 test was on a 16-bit color mode, or it was on 32-bit colors just like the resolution I'm currently using.

I think I should try other combinations if possible, but so far I can't find any option to preserve settings when reinstalling, so I have to make sure to re-add the "NoMemTest"="1" after reinstall, or I'll find myself dealing with freezes/BSODs.

EDIT: I guess the issue is more about my hardware. Tried all three options (HAL, Wine, Nine) for DX9 and no diference -- D3D9 tests behaved the same. I think it's possible that options for DX7 and DX8 will not make much difference, either, but I'm not going to test for now.

Somewhat related: I inquired about support for shadow doorbell buffers in SweetLow's nvme9x driver.

When combined with SoftGPU, I reckon this would really optimize the performance of Windows9x in a VM.

A question regarding "VRAMLimit" option with respect to recent discoveries using X-VESA.

That is, many modern video cards only expose about 16MB of memory to VESA interface (some has 32MB). I wonder if enabling more VRAM than this amount (e.g. 128MB) would be of any actual benefit, that is, whether the video card can actually utilize all the memory (if available) in such circumstances.

I tried setting "VRAMLimit" to "16" on one of my system with the last release of SoftGPU since the video card's VESA BIOS exposed only 16MB. It seems 32MB is the minimum according to DXDIAG, and setting to this from the default (128MB) doesn't make any apparent difference from what I can tell.

EDIT: Some further experiments with NEWAX's /M option suggests the available video memory size can be altered but only with linear framebuffer modes can all those memory be accessed. Usually the default value from the VESA BIOS is the amount of memory accessible via banked framebuffer and this doesn't get changed. However, increasing the memory size from the default VESA BIOS value has side effects while I was experimenting with it, including loss of video signal when certain functions were performed...

When will the update be released?

PS: I'd also like to see support for Windows NT, starting with Windows 2000.

I'm currently migrating my VMs from VirtualBox 7.x to latest QEMU 11 (via libvirt/virt-manager) on my Arch Linux based host as I've been having some stability issues with VBox there.

Latest QEMU no longer has built-in profiles for legacy OSes but the "Generic" (not recommended) profile seems basic enough to set up for such purposes. Some VM options are not directly provided in the virt-manager UI so I need to enable direct XML edit to configure those according to documentations.

The official readme seems to mention only about QEMU 7.x-8.x. With QEMU 11 I've no idea what exactly I should configure the VM's video option for this. I'm using QXL for all Windows VMs at the moment, regardless of support.

Not sure which option did SoftGPU's "QEMU std driver" correspond. On my Win98 VM, SoftGPU installer automatically chose "VirtualBox 7.1.8 and newer" profile but it complained because it reported the GPU being a Legacy non-PCI VGA, so the installation simply copied necessary files to the destination.

When manually updating the default "Standard VGA" driver from Display properties the only matching driver is the "VESA ISA Adapter". It installs and works. At 1280x800 I'm seeing decent framerates with DirectDraw and Direct3D tests, and the UI drawing seems responsive enough, so for now it kind of works on QEMU 11 just not optimal.

EDIT: In my current test case it seems after installing vmdisp9x shutdown is kind of broken... I have to force power off or reset and deal with ScanDisk on next boot. Exact cause is not yet clear.

NB: I just noticed the upstream vmdisp9x.inf contained some commented-out (in progress) lines regarding QXL so it's indeed planned...

Burinis wrote on 2026-05-28, 17:55:

When will the update be released?

PS: I'd also like to see support for Windows NT, starting with Windows 2000.

I'd like to know if it's somehow possible to support Win2000 at least for QXL. The only way I can get more colors on a Win2000 QEMU VM at the moment is to use the VBEMP NT driver which works. QXL only officially supported WinXP and onwards. It doesn't offer 3D support but it at least allowed very responsive 2D functionality for UI and web browsers.

Older NTs like 4.0 or even 3.51 may not be as trivial since they predate proper support of modern DirectX that was since Win95. Win2000 is the first of the Windows NT family to reach feature parity with Win98SE regarding DirectX.

On the other hand, I wonder if the next release will also feature the "smp.vxd" driver.

@LSS10999

Regarding SoftGPU on Windows 2000/XP (and also 98/ME), you can use the Mesa9x opengl32.dll included with SoftGPU 0.8.2025.53:

https://github.com/JHRobotics/softgpu/release … 0.8.2025.53.zip

Look in the "extra" folder for the file mesa-opengl32.7z

I normally use the Mesa23 opengl32.dll from the "sse3-llvmpipe" folder. That build also works on Windows NT 4.0.

It does not work on NT 3.51, though. For NT 3.51 I use the mmx-llvmpipe build instead. It is slower than the SSE3 version, but it works.

I uploaded the PC Player D3D benchmark here using the slower SoftGPU/Mesa9x MMX opengl32.dll, which works even on NT 3.51:

Re: Win NT4 2024+ guide\setup+ WIP +research ; Unofficial DirectX enhancers/wrappers (We have DirectX 9!) (testers nee

download link:
download/file.php?id=247255

The package also works on Windows XP, 2000 and NT 4.0.

It contains files: ddraw.dll, wined3d.dll and opengl32.dll.

For better performance you can replace the included ~11 MB MMX opengl32.dll file with the SSE3 version from the SoftGPU archive. The SSE3 version is over 40 MB.

If you want to use the Wine9x build from SoftGPU, find wined3d.dll and winedd.dll in the archive and rename:

winedd.dll -> ddraw.dll

Then PCPD3DBN.EXE will run in Direct3D mode if these three files are in the same directory:

ddraw.dll
wined3d.dll
opengl32.dll

So basically this is WineD3D + Mesa9x.

I also recently compiled newer WineD3D versions using JHRobotics' Wine9x code as the base. His Wine9x version uses WineD3D 1.7.55, while I compiled newer versions from 1.9.7 up to 11.6.

I uploaded the binaries together with the source code here:

https://github.com/crag-hack/wine9x/releases/tag/wined3d

I recommend compiling them with i686-w64-mingw32-gcc from Ubuntu 24.04, since that is the toolchain I tested.

On Arch Linux you can easily use Ubuntu 24.04 through Distrobox, and on Windows 11 through WSL.

Different MinGW/GCC versions may cause compatibility problems, especially with older Windows versions.

These WineD3D builds also work with the PC Player D3D benchmark and SoftGPU/Mesa9x opengl32.dll. The same combination also works on real hardware.

As for QXL, I do not use it for Windows XP.

For Windows XP, 2000, NT 4.0 and NT 3.51, VBEMP NT from BearWindows is enough for my purposes:

http://bearwindows.zcm.com.au/vbempg.zip

I use the VBE 2.0 variant.

One problem with QXL for retro games is that it does not support some lower color-depth modes such as 256-color or 16-bit modes, and some older games need those.

It does not matter that VBEMP NT itself is only a 2D driver. The 3D rendering is done in software by WineD3D + Mesa9x/llvmpipe on the CPU.

Interestingly, the same setup also works on real hardware.

Here is one of my videos showing Windows Neptune using VBEMP together with Wine9x:

https://youtu.be/-0tt26r97dE

LSS10999 wrote on 2026-09-15, 08:32:

I'm currently migrating my VMs from VirtualBox 7.x to latest QEMU 11 (via libvirt/virt-manager) on my Arch Linux based host as I've been having some stability issues with VBox there.

I understand the love for novelties and Open source, but downgrading from Vbox to QEMU, seem just masochism to me, at least in this specific case.

Upgrade to VMware or try to fix whatever problem you have with virtualbox, instead of giving up HW accelerated 3D for a somewhat ducktaped SW implementation.

Perhaps there isn't any need to "migrate", you can use all of them and you can use all of them at the same time. You aren't married to SW, so there isn't any need to divorce