New release is out: https://github.com/JHRobotics/softgpu/release … ag/v0.6.2024.36

The biggest new thing is vGPU10 support in VMware. When you set hardware compatibility level to 10.x – 9.x, vGPU9 will be used = OpenGL 2.1. When HW level is 12.x-17.5.x, vGPU10 is used = OpenGL 3.3 to 4.3)

Also I fixed bug for non-English Windows, where squares were displayed instead of national chars and smooth font now works correctly. This version should by more stable than previous, so please write, if not 😀

Once again, I can't thank you enough. Your drivers have really helped me loads to get older games running on my Linux machine in VirtualBox.

Amazing work, keep it up! Will try is as soon as possible because I'm kinda lost in my other projects...

New version of SoftGPU is here: https://github.com/JHRobotics/softgpu/release … ag/v0.6.2024.40

Most of changes are under the hood, but they can solve some glitches known from previous version.

1) Double buffering – on real video card is swapping front buffer is simple and fast operation, usually just change new screen offset on some HW register. But on VMware SVGA not (3D VGA in VMware and VirtualBox). Visible screen buffer is hardcoded on the beginning of video ram and position cannot be changed, you can move framebuffer to RAM, but this operation is slow and cannot be done in rate 60 swaps per second or more. So there comes the hack – framebuffer is leave where it is, but system and games writing to shadow framebuffer and when it is changed, it’ll be copy to real framebuffer.

This reduces glitches and flickering for some Direct Draw games where is used double buffering with combination of relative slow drawing to back buffer – Diablo 1 or The Sims 1 for example.

In 3D this is not as slow as it looks, because I use shortcut and render 3D buffer directly to real framebuffer and read it back to shadow buffer only when it is necessary.

Also, all screen acceleration works only on 32bpp, so I keep VM screen always in 32bpp (real framebuffer is 32bpp too) and update operation from non-32bpp shadow buffer converts colours to 32bpp.

2) HW mouse: When screen is always in 32bpp, HW cursor works in all cases and works in Direct Draw games even when they run in 16bpp (near all of them). But only in VMware. In Virtual Box HW cursor is bugged, I found these bugs, report it and also provide the patches. Zero reaction. Bug report is here: https://www.virtualbox.org/ticket/22096

3) Gamma support: when I examine VMware SVGA DDK, I found gamma support in render state, but support is crappy – it works only in VMware and only in vGPU9 mode. I also implemented gamma in software, but performance penalty is very high – so it is disabled by default, and you can enable it per process.
For example, you can enable software gamma for Quake 3 by this key:

1REGEDIT4
2
3[HKEY_LOCAL_MACHINE\Software\Mesa3D\quake3.exe]
4"SVGA_SW_GAMMA_ENABLED"="1"

When you run in VMware and your VM is in Workstation 9.x HW compatibility (vGPU9), you can enable HW gamma by this key:

1REGEDIT4
2
3[HKEY_LOCAL_MACHINE\Software\Mesa3D\quake3.exe]
4"SVGA_HW_GAMMA_ENABLED"="1"

Please don’t use both SW and HW gamma.

When we are speaking about id Tech 3 engine, there is one quirk – according to specification gamma ramp should contain 3x 256 WORDs (value for every colour for 48bit DAC), but ID tech 3 sets only first 3x 128 WORDs. Driver can use both ways MS or ID. You can switch between them in this registry value:

HKEY_LOCAL_MACHINE\Software\vmdisp9x\GAMMA_QUIRK

Value "2" (default) is Microsoft way:

Value "1" is ID way:

Value "0" is autodetection, but this not working very well.
You must reboot the VM to apply changes when you change this value.

I also hope that this release will be more stable than previous 😀

Successfully built latest qemu 9.10 using your fork! Looking forward to testing. Thank you very much for all the hard work.

Hi, i was out of loop for year or so, its nice to see that project is still continuing, but releases are too not frequent and its still single developer project, it would be nice to see more people working on it, in otherwise than just testing.

For some reason there is only 1 reply to last release here, at least some people reacted by reporting issues right through Gighub.

I seems that Windows 9x era, never would be smooth, i mean just setup virtual machine and install some magic videocard driver and play.. Normally 3D Vmware or VIrtualbox in modern OSes has its bugs, but you simply start the game try it and when its not working, you are done with testing, there are not virtual card setting, no multiple drivers. Its sort of quick and clean.

I already made it working, i read all posts here and read whole documentation and its complex. When there are some registry changes, i not even sure which are for host modern Windows and which are for guest (emulated) machine and i quite fluent in basics, virtualization engines, games, linux.. but i had to google what vGPU9 and vGPU10 that is some Nvidia standardard from 2019 / 2020.

I dont want to discourage you, but i was thinking what to do about it? Wasnt be simple just boot into Linux and setup gpu passthrough, i know posible mostly on desktops and you need additional cables, or setup old HW.. but it dont seems to be so complex in comparison to this.. There its mostly about find right GPU and its driver to run certain game and there is first big hassle to make passthrough working at all.

I really thought about it how make it make, bring some positive, constructives ideas.
First i already offered in the past and its make some control panel, installation CD menu, sort of works like it already but only sort of.
We can make some compatibility list or search for every game on Github if there is some solved issue, its better than nothing.. , but its far from install and play as we are used on old machine.

It seems that with all of complex emulation we would need as always some Frontend.. Ideally simply something which would scan user given game directory, detect know games and setup environment to run them.. and have couple presets for unknow games based on their types/ engines etc. Copy right dlls, set registry, warn user that Vm current settings is not good for target game. Good thing is that such frontend could be coded by someone without low level programming skills, he just need to know recommended settings for particular game by testing, or from some compatibility list, after than its about simple rendering some simple 2D Win9x form application, copy files to right folder, check files within that folder and learn 3 functions for write/edit and delete something to registry.
Simply something like PlayOnLinux for WIne, or Steam proton (much less complex).

I wonder there some NT4 request, how hard it would be support it? Thanks this project its really was 3D capable Windows, there not 3D Acceleration is not working without full machine emulation (86Box).

Just dropped in to say thanks for the SoftGPU. Runs well installing in Windows 98SE running in VirtualBox using Debian 12.

There are some hits and misses (couldn't remember which one - I think Aliens vs Predator 2 is not running) but generally okay. Tried playing Colin McRae 2 and it runs smoothly. Somehow I needed to change the driver in the game to another version of VMSVGA displayed by the game to run smoothly.

Escape from Monkey Island was initially jerky when controlling Guybrush in the beginning but after that, it is running well too.

Edit: Having trouble with Heavy Metal FAKK2 - does not work. Just gray screen but has sound. Eidos's Cutthroats - white screen, has sounds.

Just idea, i was always keeping in mind that Rloew had to multicore support for Win9x:
- would be rendering idea use case to use his package and made something practical with it?

Author himself discussed it here:
https://msfn.org/board/topic/145512-multiproc … upport-in-98se/

Demo is here:
search for MULTCORE
https://rloewelectronics.com/catalog2.htm

There is some his source pack, im not sure if its included, its worth of the shot:
https://archive.org/details/rloewelectronics.com

If not his son available (he were using fathers MSFN account in the past) and there was some MSFN member which is has friendly relashiping with his family and was friend of RLoew, i have bad memory for names, if need im able to find his MSFN account, he did all these *.inf for reporting new MB devices with right names for Win9x.

Update: I found that nickname, it was Lonecrusader and i wrote him.. BTW he donated like 3k $ to keep MSFN site running..

ruthan wrote on 2024-12-24, 19:42:

Just idea, i was always keeping in mind that Rloew had to multicore support for Win9x: - would be rendering idea use case to use […]
Show full quote

Just idea, i was always keeping in mind that Rloew had to multicore support for Win9x:
- would be rendering idea use case to use his package and made something practical with it?

Author himself discussed it here:
https://msfn.org/board/topic/145512-multiproc … upport-in-98se/

Demo is here:
search for MULTCORE
https://rloewelectronics.com/catalog2.htm

There is some his source pack, im not sure if its included, its worth of the shot:
https://archive.org/details/rloewelectronics.com

If not his son available (he were using fathers MSFN account in the past) and there was some MSFN member which is has friendly relashiping with his family and was friend of RLoew, i have bad memory for names, if need im able to find his MSFN account, he did all these *.inf for reporting new MB devices with right names for Win9x.

Last time I checked MULTCORE was not among the public archive. I wonder if anyone had bought and developed anything against it back then.

I think that SDK mainly showed the possibility to utilize additional CPU cores within Win9x environment, and in the MSFN thread rloew had explained all the limitations. Basically program has to manage CPU cores entirely by itself as Win9x won't do that.

Also, from the discussion, he also managed to split DOS7 into different CPU cores, though he said there were no noticeable speed improvement. That was not part of the DEMOCORE/MULTCORE SDK but it appears multithreading in DOS would also be theoretically possible.

The DEMOCORE documentation also pointed to something called "MEMORY64" for designing programs that can access more memory than Windows could manage (as well as being compatible with MULTCORE). Again, I guess programs would also have to explicitly manage those memory similar to Romex Primo Ramdisk's "Invisible Memory".

Still, I'm afraid the Win9x kernel as well as the ACPI code would have to be completely reworked for proper multi-CPU/Core support as in WinNT there were multiprocessor kernel (NTKRNLMP/NTKRPAMP), as well as multiprocessor HALs (like HALMACPI). Current Win9x could be considered using standard kernel (NTOSKRNL) with a Standard PC (HAL), or ACPI Uniprocessor PC (HALACPI) if ACPI-capable.

Well,where is demo, it usually means that its working, i read that thread too.
People mostly expected something like multicore support for existing applications or something like modern Windows cores affinity settings.

There is always some overhead off course, but newer OSes managed it and CPU manufactures too, so its proven way. Maybe as always we can use Linux source as inspiration, Reac OS has a lot of problems, but i never read that multicore support would not work. If WIn9x kernel is not blocking access to other cores or its not blocked by some legacy BIOS boot mode or other hard HW limit, its possible to do it, he already proved it in both DOS and WIndows 9x.

Well Dos - is disk operating systems, it does not do much, you understand more how it works, but Dos mode enable to run some device interprupt command in parallel, for example dir command would be nice candidate to run in multiple threads and compose the results. Or its possible at least run in parallel calls to different interrupts, you make faster some device scanning detection like Hwinfo device detection etc... 2D rendering is similar to 3D rendering, again if its possible to run more putpixels in parallel there woudl be big performance gain, if this mode is not too expensive at resources, every graphics api do this and there is Glide for Dos its probably also doing something like at least at videocard level. I mean at least Voodoo 5 have 2 units (unreleased prototypes has 4) there is Q1DOS / Q2DOS its probably using more than 1 unit.

Anything with lots of similar calls and 3D graphics is probably best scenario for using multithreading / parallels processing.

As far as i understand its possible to create multithreading even on single core cpus, through context switching, which is probably how Win9x handle multiple threads, its called preemptive multitasking.. and after you only need to send some of these calls to other cores anch check if result is available and composite results.

Another point so add to discussion is DR-DOS, it enable to switch between multiple running programs, it extended standard DOS capabilities, they called it Cooperative Multitasking, i was similar to WIndows 3.x "multithreading", it also wasnt preemtive multitasking system and it run as standard MS-DOS extension without explicit Win9x kernel preemptive multitasking / scheduler. DR-DOS also used memory partitioning, to isolate different "apps", in later version it was upgraded to something called VIrtual memory, task switching was done through TSR, 32 bit memory addressing. So there was not kernel multithreading, but there were 2 main components give you ilusssion of full multithreading.. or 2 of 3 main components of it - task scheduling and program switching, "only" preemptive kernel was missing.

Windows NT3 + NT4 code would be very internerting as first MS OS doing it. There was some NT 3.1 source leak (2004) and NT4 code leak in 2020..

By the way wrong evolution way seems to be too many weak cores for desktop, as you can see in this video, when someone finally tried to use high power ARM server cpu for desktop, its shame that we are still waiting for something like Apple already did 2,3 years ago for from normal pc mainboard and cpu companies..
https://www.youtube.com/watch?v=argfZlPZKdY&a … el=JeffGeerling

I had softGPU working perfectly, but after the latest install, every time I go to do the GLChecker, VirtualBox crashes with a message: "The instruction at 0x00007FFFA47AC2B7 referenced memory at 0x0000000000000010. The memory could not be read". I'm running the latest version of VirtualBox (7.1.6) on Windows 11. My machine is an i7-11800H with an RTX 3060 and 64GB of RAM. I'm honestly not sure what is to blame here...an update to VirtualBox, an update to Windows 11, or an update to SoftGPU, but it was working perfectly the other day, and now it always crashes to this message.