mr.cat wrote on 2021-01-09, 22:16:

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):

I realize where you were at trouble. Sigh ... a common myth of retro folks. ACPI is actually a good thing. You didn't force ACPI installation during Win98 setup invocation. Unlike the other UI-fancy PC emulation 😜, QEMU PC platform emulation is based on clean implementation of PC BIOS or OVMF UEFI. It is a no-fuss, minimalist concept. If you were familiar with IBM PC BIOS legacy, then you would know what I mean. So ACPI is preferred since this is the essential PnP and device discovery for modern PC firmware. The obsolete pre-ACPI PnP standard is likely just a stub.

You need to force ACPI installation for Win98 Setup invocation with:
**SETUP /NM /PJ**

Otherwise, Win98 PnP detection will not discover the existence of PCI bus.

You can add PCI bus later manually, through add device wizard, im using it a lot which Windows 98 KVM machines..
In device manager set driver for Plug&Play Bios manualy to PCI Bus, after device detection will start working..

Thanks guys. This is actually my first Win98 install, that's part of the problem..
Yes ACPI is a very good thing to have 😁

EDIT: ..or at least it would be, if it worked.
With ACPI enabled (re-installed from scratch with the /NM /PJ switches) , I got the bearwindows drivers (the 32MB variant from 2014) installed and the display mode can consequently be changed to 800x600x16bit or whatever.
But some vital ingredient must still be missing, because just launching "command" will mess the screen up (to double size & wrong colors). wglgears also immediately segfaults etc.
(This with -device vmware-svga,vgamem_mb=32 and kvm disabled)

EDIT2: Got it working at last. I did see some glitchy weirdness at first, that was resolved by adding the kernel drivers (fxmemmap.vxd and fxptl.sys, see the first post) that were missing.
In a Win9x guest they go to Windows SYSTEM directory.
(There was no mention about kernel drivers in my original December post with the win98 recipe, but it's now added)
The binaries for these can also be found in wrapper/drv directory (they are in a hex dumped form, I assume that is because they live on GitHub).

I have OpenGL sort of working now, but I can't seem to get it to see openglide.
On the linux side where does the qemu binary expect the openglide libraries to be (I'm using Debian buster)?

I've also noticed that directdraw doesn't work at all. Even for simple games that don't use any 3dacceleration. You guys have any tips for workarounds for this? Normally I'd just use one of the newer implementations of WineD3D, but i'm having difficulty finding a ddraw.dll wrapper that'll work on win98.

A third thing to note, I've noticed that if you try and render a OpenGL game in a window it ignores it's window position and just renders in the bottom left corner. This also seems to cause visual garbage in the rest of the window, is windowed support something that's just not possible with this solution?

Thanks for your help.

t9999clint wrote on 2021-01-11, 11:38:

I have OpenGL sort of working now, but I can't seem to get it to see openglide.
On the linux side where does the qemu binary expect the openglide libraries to be (I'm using Debian buster)?

The default location is /usr/local/lib, if you compiled OpenGlide yourself.
AFAIK it uses dlopen() to find it so...man dlopen?
Also, LD_DEBUG=libs can sometimes help to find out how the libraries are loaded (just add it on the command line, before the command).

t9999clint wrote on 2021-01-11, 11:38:

I've also noticed that directdraw doesn't work at all. Even for simple games that don't use any 3dacceleration. You guys have any tips for workarounds for this? Normally I'd just use one of the newer implementations of WineD3D, but i'm having difficulty finding a ddraw.dll wrapper that'll work on win98.

Which games for example? If it's early DirectX (1-7), just copying the dlls isn't going to work (WineD3D's own readme has the details).
There is a longer explanation on that problem here:
https://web.archive.org/web/20151224173752/ht … ineD3DOnWindows

Also there is the fact that the oldest OS that is mentioned on WineD3D web page is Win2k, I don't know what witchery is needed for Win9x but seems it can be done:
Re: QEMU MESA GL pass-through for OpenGL games

It won't work for any game that isn't using OpenGL to initialize fullscreen.
Starcraft, Diablo, NFS 2, WinQuake, Quake II, etc...
I'm trying this with the VMWare display and drivers, should I be trying with something else? Or is this expected behavior with this method.

t9999clint wrote on 2021-01-13, 18:05:

It won't work for any game that isn't using OpenGL to initialize fullscreen.
Starcraft, Diablo, NFS 2, WinQuake, Quake II, etc...
I'm trying this with the VMWare display and drivers, should I be trying with something else? Or is this expected behavior with this method.

Ah ok thx, I see what you mean now. It will say something like "linked to missing export DDRAW.DLL:DirectDrawCreateEx."
I may be mistaken but from that other thread I got the impression kjliew cooked his own version of WineD3D to get around some ddraw issues.

He did but I don't think he shared it anywhere, or explained how made them.

Here is some post where is writing about not Glide games, OpenGL preview..
Re: KVM(QEMU) Win98 videocard passthrough.I finally got it working- with full 3D API support Quake III 1600x1200 90+ FPS

ruthan wrote on 2021-01-13, 21:16:

Here is some post where is writing about not Glide games, OpenGL preview..
Re: KVM(QEMU) Win98 videocard passthrough.I finally got it working- with full 3D API support Quake III 1600x1200 90+ FPS

Thanks ruthan, but isn't that simply the MesaGL implementation that is now included with qemu-3dfx? Or was there some point that I missed?
WineD3D handles the calls from a Direct3D app to MesaGL, but the problem is that some games try to use DirectX calls that aren't available in (vanilla) WineD3D.

t9999clint wrote on 2021-01-13, 18:05:

It won't work for any game that isn't using OpenGL to initialize fullscreen.
Starcraft, Diablo, NFS 2, WinQuake, Quake II, etc...
I'm trying this with the VMWare display and drivers, should I be trying with something else? Or is this expected behavior with this method.

Which version of Diablo? diablosw.exe (md5sum: b3e9a4b1cfb0353fc6455f494f192bdb) seems to "just work" (using bearwindows drivers, no WineD3D needed).
For NFS2, only the SE version has Glide support. I don't think WineD3D is needed for these.

EDIT: Just to clarify, these pure GDI and DirectDraw programs use a different code path. You can see that pretty clearly if you take a look at the qemu console.
(if there are no telltale messages about wrapper activation, the app could then probably run on vanilla qemu just as well)

kjliew wrote on 2021-01-11, 09:47:

I realize where you were at trouble. Sigh ... a common myth of retro folks. ACPI is actually a good thing. You didn't force ACPI […]
Show full quote

mr.cat wrote on 2021-01-09, 22:16:

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):

I realize where you were at trouble. Sigh ... a common myth of retro folks. ACPI is actually a good thing. You didn't force ACPI installation during Win98 setup invocation. Unlike the other UI-fancy PC emulation 😜, QEMU PC platform emulation is based on clean implementation of PC BIOS or OVMF UEFI. It is a no-fuss, minimalist concept. If you were familiar with IBM PC BIOS legacy, then you would know what I mean. So ACPI is preferred since this is the essential PnP and device discovery for modern PC firmware. The obsolete pre-ACPI PnP standard is likely just a stub.

You need to force ACPI installation for Win98 Setup invocation with:
**SETUP /NM /PJ**

Otherwise, Win98 PnP detection will not discover the existence of PCI bus.

Also, the system will idle at 100% CPU utilization if you don't force ACPI during installation! So indeed, you really do want to enable this.

t9999clint wrote on 2021-01-11, 11:38:

I've also noticed that directdraw doesn't work at all. Even for simple games that don't use any 3dacceleration. You guys have any tips for workarounds for this? Normally I'd just use one of the newer implementations of WineD3D, but i'm having difficulty finding a ddraw.dll wrapper that'll work on win98.

I just noticed this post by wadrasil:
Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

So vmware drivers are always stuck in 32-bit color mode, maybe this is your problem?
EDIT: This might have been done on purpose, for performance reasons. These vmware drivers can be an alternative if the app can support 32-bit color.
Do note though, that you will also have to use virtualized usbmouse to make use of them. So the guest should have drivers for usb.

Using VMWare drivers they don't launch at all. Diablosw or otherwise.
Using bearwindows drivers they just crash whenever I try to launch them. Easiest way to replicate this is by opening a command.com window.

What drivers are other people using? Care to share a zip?

Yes, I would be very interested in that too. Is there a specific version that should be used? And is vmware-svga the way to go, or maybe something else?
I've only tested the bearwindows (VBEMP) drivers (2014.02.14) so far since this was kjliew's recommendation. They have their own set of problems, as you said...just launch "command" and see it crash and burn...
At least some of the problems are outlined on their website, I guess writing drivers is just *hard*.

Btw t9999clint did you have any luck with the test programs (wglgears.exe, and the test exes from the SDK)? Those should be tried first to ensure everything is in place, before bothering with WineD3D.

VBEMP Win9x does not support windowed DOS prompt on Win98/ME, VBEMP NT does on Win2K/XP. If you need to run DOS programs or DOS BATCH scripts by clicking on the files from Windows Explorer, then do this. Or just run them from a fullscreen MS-DOS prompt. It is a well-known limitation, even on real hardware, for folks who hated anything so badly that it is OK to run their $$$ GPUs without supported drivers.

You don't launch Windows programs from .BAT files, do you? There is no 3Dfx Voodoo SST envvars to worry here. If you really have to do so, then use PIF to make the BAT start in fullscreen.

That was a (yet another) great tip, kjliew. Thx!!

Now if I understood the purpose of this procedure correctly, it's so that everything is opened fullscreen by default.
So as the final step the pif should edited so that the Fullscreen setting is enabled.
This bit was missing in the recipe given in the link, and it's quite crucial so that's why I'm spelling that out here.

With that PIF trick, I think most of the VBEMP naughtyness is now gone. I haven't tested very extensively, but the guest works quite smoothly and haven't seen any more of those funky color effects or crashing in Win98 guest.
Enabling kvm is also (pardon the pun) a real game changer!

There is still at least one remaining problem with kvm and VBEMP drivers: Qemu hangs on shutdown (must be forced to close).
I think this was mentioned before (but no workaround). Not a major issue though.

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

There is still at least one remaining problem with kvm and VBEMP drivers: Qemu hangs on shutdown (must be forced to close).
I think this was mentioned before (but no workaround). Not a major issue though.

Very good observation 👍 !

I had lived with this for many years without solution ( ... and next VM boot will kick off SCANDISK). Before Windows 10, QEMU was just a toy to play around, I wasn't serious in using it to play old games. By accident, I noticed that some time the Win98 VM will shutdown cleanly so I tried to figure out what made it do so.

Hence, here comes the final trick:
- Disable shutdown logo ( remove, rename LOGOW.SYS in C:\WINDOWS)
- Create a 2-line _STARTUP.BAT in C:\WINDOWS:

1@echo off
2exit

Create a PIF and add it to "Start->Programs>StartUp" so that it is run automatically in "Fullscreen" and "Close on Exit".

Great, I'll try that! I actually tried removing LOGOW.SYS, so I see I was half-way there already. But that didn't help on its own.

EDIT: Got it fixed. This is a quite nice workaround actually, I was expecting the fix to require some win.com hacking or somesuch.
My original Dec-13 post has also been updated, for any fellow sufferers to oogle. Keep the faith and keep on chugging along, and you'll get there eventually 😁

t9999clint wrote on 2021-01-11, 11:38:

I have OpenGL sort of working now, but I can't seem to get it to see openglide.

Hmmm. Sort of working, let me guess: slowly, right?
I think these old Windows versions had their own soft-rendered version of OpenGL which is what you're seeing here.
If there are no messages on qemu console, that is the reason. Which means that opengl32.dll stub is not doing its thing, for some reason.

Is it possible that you're using vanilla qemu by accident? Could happen if you have vanilla qemu installed and you're launching qemu binary without path.
In that case just try using the whole path to the binary and see if that helps.