ok thanks, it compiled ok now. I got the GTK stuff confused somewhere.
One of the previous posts mentioned needing it to be disabled so that must have tripped me up somewhere.
Now I have something to test with for my Linux system.

Now all that's left is for me to figure out how to cross compile for windows.
I'll get there.

This plus WineD3D and DSOAL-XP could give some interesting results for a WinXP VM. I already use those with a KVM setup with PCI-E passthrough, but it'd be neat to run this without needing a IOMMU compatible mobo and Linux.
In a year or two I can see this stuff being a cool drag and drop solution for Windows 98/XP era gaming with full 3D Video and Audio support.

t9999clint wrote on 2021-01-01, 22:55:

This plus WineD3D and DSOAL-XP could give some interesting results for a WinXP VM. I already use those with a KVM setup with PCI-E passthrough, but it'd be neat to run this without needing a IOMMU compatible mobo and Linux.
In a year or two I can see this stuff being a cool drag and drop solution for Windows 98/XP era gaming with full 3D Video and Audio support.

Yeah, I tested that vfio stuff too a few years back...that was a real PITA to get to work at all, but I guess it works for some folks. This solution seems much nicer, there are a lot of rough edges for sure but it'll get there.
Btw, I recall that in some thread this qemu-3dfx project was described by kjliew (the author) as being an "interim solution". The holy grail for qemu being actual Windows guest drivers for virgl...
There was a poc back in 2017 but I haven't heard anything on that front, so I'm not sure if that project is alive (virgl itself ofc is working, but for Linux guests only).

mr.cat wrote on 2021-01-01, 23:17:

There was a poc back in 2017 but I haven't heard anything on that front, so I'm not sure if that project is alive (virgl itself ofc is working, but for Linux guests only).

Virgl stuff is basically done, but now everything's moving on to Vulkan so it's a little pointless with modern Linux distros. AFAIK virgl is GL only.
Also the windows drivers side has seen zero progress as it looks like no one wants to develop them. Also no one wants to pay for the windows WHQL fees.
Anything regarding gaming is basically ignored by the QEMU community. They only care about their business overlords.

With the current stage of QEMU development, the chance of VIRGL drivers for windows to ever become a thing is basically zero. If by some miracle it does get added, it'll be win10 only.

t9999clint wrote on 2021-01-01, 23:26:

Virgl stuff is basically done, but now everything's moving on to Vulkan so it's a little pointless with modern Linux distros. AF […]
Show full quote

mr.cat wrote on 2021-01-01, 23:17:

There was a poc back in 2017 but I haven't heard anything on that front, so I'm not sure if that project is alive (virgl itself ofc is working, but for Linux guests only).

Virgl stuff is basically done, but now everything's moving on to Vulkan so it's a little pointless with modern Linux distros. AFAIK virgl is GL only.
Also the windows drivers side has seen zero progress as it looks like no one wants to develop them. Also no one wants to pay for the windows WHQL fees.
Anything regarding gaming is basically ignored by the QEMU community. They only care about their business overlords.

With the current stage of QEMU development, the chance of VIRGL drivers for windows to ever become a thing is basically zero. If by some miracle it does get added, it'll be win10 only.

Yeah, those are all very valid points. I totally missed the one about WHQL fees! I guess I've just been pampered with all this Linux/open-source stuff for so long I just forgot about it 🤣 😁
Well, I can't say that I was holding my breath on that anyways... but yeah, so it seems that qemu-3dfx will remain the only game in town for some use-cases.

what do you guys recommend for Glide emulation on the Linux side? Should I just use OpenGlide?
Also if I get this working ok, do you mind if I package it up as a .appimage?

t9999clint wrote on 2021-01-02, 16:45:

what do you guys recommend for Glide emulation on the Linux side? Should I just use OpenGlide?
Also if I get this working ok, do you mind if I package it up as a .appimage?

Yes, OpenGlide works just fine. About the binaries: There have been binaries for the previous versions in this thread, so I would assume it's ok.
(But the guest stubs should also be included.)

EDIT: Maybe you meant if anyone objects distributing .appimages in general? In that case they are welcome to provide an alternative.

ok, so what openglide should I compile, this one? https://github.com/voyageur/openglide
Should I still be using the x11 diff on the first post? It looks like they've added more code since then.

t9999clint wrote on 2021-01-02, 19:54:

ok, so what openglide should I compile, this one? https://github.com/voyageur/openglide
Should I still be using the x11 diff on the first post? It looks like they've added more code since then.

Yes that's the one. You can take a look at the Linux build guide on page 22 for some further info: Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)
The diff isn't needed (I think it should already be in).

Me and Auzner (mostly Auzner) have been making good progress into making a working binary set for this for Linux.
We'll be making sure we document the build process so it's reproducable.
The first release will be as a .appimage but it'll probably require some more testing before that's ready.

Once we get a working build environment for windows, a .zip of a preconfigured qemu build will be available for that too.

hey what video mode am I supposed to run this in for Linux?
my command looks like this...

1./qemu-system-x86_64 -hda /Data/2tb/VMs/W98.img -boot c -soundhw sb16,adlib,pcspk -audiodev pa,id=qemu-3dfx,server=127.0.0.1 -display sdl,gl=on -no-hpet -usb -usbdevice tablet -cpu pentium3 --machine pc -enable-kvm -rtc clock=host,base=localtime -mem-prealloc -net nic,model=rtl8139,macaddr=02:01:04:03:05:01 -net user -m 1G -vga none -device VGA,vgamem_mb=128

So I'm using -display sdl,gl=on
to force sdl and enable gl

and I'm using -vga none -device VGA,vgamem_mb=128
to disable the default settings and use the Standard qemu display with a forced vram of 128 to make full use of the bearwindows vbe9x drivers.

I'm running into crashes anytime any application tries to use a fullscreen mode.
I've tried -vga cirrus
but it's so slow it makes my 486DX2 look fast

t9999clint wrote on 2021-01-09, 18:22:

hey what video mode am I supposed to run this in for Linux? my command looks like this... […]
Show full quote

hey what video mode am I supposed to run this in for Linux?
my command looks like this...

Copy code to clipboard

1./qemu-system-x86_64 -hda /Data/2tb/VMs/W98.img -boot c -soundhw sb16,adlib,pcspk -audiodev pa,id=qemu-3dfx,server=127.0.0.1 -display sdl,gl=on -no-hpet -usb -usbdevice tablet -cpu pentium3 --machine pc -enable-kvm -rtc clock=host,base=localtime -mem-prealloc -net nic,model=rtl8139,macaddr=02:01:04:03:05:01 -net user -m 1G -vga none -device VGA,vgamem_mb=128

So I'm using -display sdl,gl=on
to force sdl and enable gl

and I'm using -vga none -device VGA,vgamem_mb=128
to disable the default settings and use the Standard qemu display with a forced vram of 128 to make full use of the bearwindows vbe9x drivers.

I'm running into crashes anytime any application tries to use a fullscreen mode.
I've tried -vga cirrus
but it's so slow it makes my 486DX2 look fast

Yes, this guest configuration part seems to be quite tedious and I haven't been able to get it right either. Using cirrus works, but it's less than optimal. (See later posts)
I can confirm that -display sdl,gl=on is correct (but ,gl=on can be omitted as kjliew said). I'm not sure if you need -vga none.
The better drivers (bearwindows or vmware ones from 8.3.19 tools iso) don't seem to work, as you said. (See later posts)
Also, with -enable-kvm I consistently got a black screen, so had to ditch that too. But this might be dependant on host hw (EDIT: AMD FX series in my case, and kvm does work with Linux guests).

EDIT: Saw this explanation on reddit (this from apparently a KVM dev called bonzinip):
"Win9x has a timing bug that makes it fail to boot, or divide by zero, under KVM. Just use QEMU in dynamic translation mode. It slows it down enough that the bug won't trigger."

-vga none
This switch is used to disable legacy VGA decoding. It is useful for booting modern OS's such as Win8+ and Linux with OVMF UEFI to fully emulate UEFI class 3 boot. It is usually used with -device virtio-gpu or -device qxl-gpu. It does not make sense with -device VGA, -device cirrus-vga, -device virtio-vga or -device qxl-vga which implies a standard VGA requirement. A VESA dumb buffer 2D driver can rarely make full use of 128MB. QEMU default of 16MB makes a lot of sense and works best.

-display sdl,gl=on|off
The option `gl=on|off` only applies for virtio/virgil3D use cases. It can be omitted and simply use `-display sdl` when booting Windows.

Win98 guest does not work very well with 1GB of memory. QEMU system memory default of 128MB works pretty well for almost all games targeting Win9x. If you really need lots of memory, then the max I would go is 512MB.

mr.cat wrote on 2021-01-09, 20:06:

The better drivers (bearwindows or vmware ones from 8.3.19 tools iso) don't seem to work, as you said.
Also, with -enable-kvm I consistently got a black screen, so had to ditch that too. But this might be dependant on host hw.

To successfully accelerate Win98/ME guest with KVM/WHPX, there are several tricky parts.
1. You can't use cirrus-vga or just plain VGA (planar I/O access) with KVM/WHPX. You have to use VBEMP 9x or VMware SVGA and I recommend the former. The main blocker to get around for starting from scratch is to stay with TCG (slow) until the proper display driver is installed to obtain 256-color or 16-bit color desktop. Once you got there, you are in LFB mode. Then on next boot, you can enable KVM after step #2 (IMPORTANT)
2. Disable Win98 startup logo. Edit MSDOS.SYS and place "Logo=0" in the [Options].

Step #1 is very painful, so once it is done, any sane mind would not want to repeat that. So please back it up with an imaging tool. I use fsarchiver with Linux-based rescue LiveCD. QEMU KVM can boot up the LiveCD and re-image Win98 in 5 mins (compared to 35mins up to an hour for setup #1) on a reasonably fast SSD storage.

In any circumstances that you were forced into Win98 Safe Mode, KVM/WHPX would just crash. So just keep in mind to stay with TCG if Safe Mode was really needed. Otherwise, it is significantly faster to restore the installation from image.

kjliew wrote on 2021-01-09, 21:29:

To successfully accelerate Win98/ME guest with KVM/WHPX, there are several tricky parts. 1. You can't use cirrus-vga or just pla […]
Show full quote

mr.cat wrote on 2021-01-09, 20:06:

The better drivers (bearwindows or vmware ones from 8.3.19 tools iso) don't seem to work, as you said.
Also, with -enable-kvm I consistently got a black screen, so had to ditch that too. But this might be dependant on host hw.

To successfully accelerate Win98/ME guest with KVM/WHPX, there are several tricky parts.
1. You can't use cirrus-vga or just plain VGA (planar I/O access) with KVM/WHPX. You have to use VBEMP 9x or VMware SVGA and I recommend the former. The main blocker to get around for starting from scratch is to stay with TCG (slow) until the proper display driver is installed to obtain 256-color or 16-bit color desktop. Once you got there, you are in LFB mode. Then on next boot, you can enable KVM after step #2 (IMPORTANT)
2. Disable Win98 startup logo. Edit MSDOS.SYS and place "Logo=0" in the [Options].

Step #1 is very painful, so once it is done, any sane mind would not want to repeat that. So please back it up with an imaging tool. I use fsarchiver with Linux-based rescue LiveCD. QEMU KVM can boot up the LiveCD and re-image Win98 in 5 mins (compared to 35mins up to an hour for setup #1) on a reasonably fast SSD storage.

In any circumstances that you were forced into Win98 Safe Mode, KVM/WHPX would just crash. So just keep in mind to stay with TCG if Safe Mode was really needed. Otherwise, it is significantly faster to restore the installation from image.

Thank you kjliew! So this is the one weird trick that Billy Gates hates 😁

EDIT: You weren't kidding when you said it's painful...
I now found out why the graphics drivers cannot be installed, so this may help peeps stuck in 16 color mode (win9x guest):

Here's how:
Go to Control Panel/System/Device Manager. See if there is a yellow exclamation mark in front of "Plug&Play BIOS", if there is, that needs to be resolved first.
Click it open and go to Driver tab, Click "Update Driver"
Select "Specify the location of the driver"
Select "Display a list of all the drivers in a specific location, so you can select the driver you want. "
Click "Show all hardware"
Select "PCI bus" (it's in the "Standard system device" section, so just scroll back a few lines and you'll find it)
Click Next. You will get a warning about driver not being recommended, but click Yes anyway.
The installation should then continue.
On restart, it looks like the guest likes to hang a lot...if that happens just restart qemu and hopefully the guest will sort itself out.

EDIT2:
The guest was missing ACPI, use the switches:
Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

OSH wrote on 2020-12-17, 22:32:

Not yet... I'm simply curious, because kjliew said, it will work on Win98/ME… Actually I'm trying to find a best VM/emulator for playing old Windows 9x games. And I come to conclusion, such software doesn't exist. For one game will be QEMU a good choice, for other Wine or VirtualBox/PCEM…

Retailed version X-Wing vs Tie-Fight 1997 Direct3D

QEMU KVM is the best VM solution for playing old Windows 9x games. You just got to have faith, didn't you?
You can play at *ANY* resolution scaled up from 640x480 at the highest details and view distance and the frame rate remained locked at 30FPS. I was testing the game at 1024x768 upscaled on Win98 VM. Only official XvT 1.1.0 is required to fix the CD detection. X-Wing and Tie-Fight Collector CD 1998 re-releases use the same 3D engine, and so does X-Wing Alliance.

The test including passing through a Logitech USB F310 Gamepad which is required to play the Windows Direct3D version of the games, otherwise they won't start at all. USB host device pass-through is robust and simple for QEMU with Linux.

ruthan wrote on 2021-01-01, 22:54:

@t9999clint - Welcome to the club, so far its designed to be hard and complicated and waste your time in name of so called user education..

It isn't as hard and complicated as you would have thought.

In the end, it will save you a lot of time. Imagine the time to scout E-bay for used parts, maintaining retro PCs and the probability of old electronics break-down due to wear-n-tear. Imagine the long list of patches and tricks to get old Windows games working on Windows 10, hunting down unofficial, community patches and so on. Imagine if the game installation screwed up your machines that you need to reformat and reinstall the OS ..... and so on.

QEMU has saved my time, of course I did put effort to learn to use it proficiently, there is no such thing called free lunch in this world. DOSBox is the best solution for DOS games, I became part VOGONS community because of DOSBox and that was more than 15 years ago, it saved me a lot of time for playing my favorite DOS games. Technologies enabling virtual machines have come along and maturing. Even if Wine can run the games on native Linux, I still prefer to have Wine running from Linux VM to have the isolation that installing those games won't interfere with my main OS, whether it is Linux or Windows 10. I have been looking forward for QEMU to support old Windows games.

If I want to play old Windows games with a machine 20 years later, then I want the absolute best from those games. What's the point of those 20 years if I still have to tune down the graphics details or lower the view distance/texture quality. That is the major let-down of PCem, I don't want a shiny new Core-i9 or Ryzen 5950X to perform like Pentium II 233MHz if I can afford one of those CPUs.

I have the original hardware working really well already, and for more demanding games I have QEMU with Windows XP and a GTX770 passed through to it.
I'm probably not going to be using this method. I'm literally just trying to set this up for the challenge.
But I understand how this will be helpful for many people, especially in the future when compatible hardware becomes rare.
Also most people want a easy drag and drop solution for this stuff. (DosBox but for Windows) If I can move this project to something a little closer to that than I'd be happy.

kjliew,

I've had complaints about your posting to unrelated threads promoting your qemu build. Please keep your qemu build posts to this thread or a seperate thread for games running with qemu.
Also please stop with the pcem bashing, for anyone not familiar with the projects it gives a bad impression of pcem. Your qemu builds work for your purposes and perhaps many others but it wouldn't work for those who use pcem for their purposes. "best" is relative.
There is nothing wrong with the creation of fixes to run games, this is necessary even for games running on their original OS.
Options are a good thing.

Personally I'd rather have to deal with an unofficial patch than use 9x. I prefer to use 9x for gaming only when absolutely necessary since that's is how I dealt with it when I had to use it when it came out. DOS/NT4 for gaming, Internet and work. 9x only when a game needed it. When 2000 came out it was a glorious day. For myself for the few games (2d) that require 9x I'm happier with vmware but there are a couple of games I need qemu for but I'll need to re-evalute those since it's been a few years since I tested them. I'll need to test them with boxedwine as well.

Hopefully boxedwine and winevdm continue to be developed, these are similar to how DOSBox work and remove the pain of dealing with a guest OS.

DosFreak wrote on 2021-01-10, 01:15:

I've had complaints about your posting to unrelated threads promoting your qemu build.

I would love to be enlightened if you could point out a few examples. Out of the blue, I merely demonstrated another option to play games, and options using VirtualBox/VMware have already been tabled. Sometimes, they backfired (especially in the Marvin). I came to realize some folks enjoy tinkering hardware rather than playing games, and some totally despise any forms of emulation as though "real man has real machines". Fair enough, it's their choice.

DosFreak wrote on 2021-01-10, 01:15:

Also please stop with the pcem bashing, for anyone not familiar with the projects it gives a bad impression of pcem.

I thought I had merely spoken out of truth ..... 😁 People who use PCem for their purposes shouldn't be annoyed by mere truth. And I doubt I possess such influencing power to instill bad impression of PCem. Just the same truth that I lack the power to make QEMU pretty for those reluctant to deal with command-line.

DosFreak wrote on 2021-01-10, 01:15:

There is nothing wrong with the creation of fixes to run games, this is necessary even for games running on their original OS.

When did I ever mention it was wrong with the creation of fixes to run games? I sincerely welcome them when they really work. I believe I had made it clear that assuming a patch/fix works on WinXP~Win7 continues to work for Windows 10 is just wrong, especially Windows 10 is on rolling update model. For eg. many nGlide patches for Glide games no longer work for Windows 10. You could argue they are fine, it was my problem. Fair enough, perhaps I don't know or others have undisclosed ways of relaxing Windows 10 security model to make old games work.

DosFreak wrote on 2021-01-10, 01:15:

When 2000 came out it was a glorious day. For myself for the few games (2d) that require 9x I'm happier with vmware but there are a couple of games I need qemu for but I'll need to re-evalute those since it's been a few years since I tested them. I'll need to test them with boxedwine as well.

You did make a point of how disgusting it was to deal with 9x on real machine. I couldn't agree more, that's the purpose served by using virtual machines. I am much happier with QEMU, it's my choice of supporting open source.

DosFreak wrote on 2021-01-10, 01:15:

Hopefully boxedwine and winevdm continue to be developed, these are similar to how DOSBox work and remove the pain of dealing with a guest OS.

I do have high hope for Boxedwine to fill the show as a true DOSBox equivalent for all Windows games.

Finally found the VMWare video drivers, they're a couple of subfolders deep in this this iso...
https://packages.vmware.com/tools/esx/3.5late … windows/x86_64/