Wow, what am amazing project! Brilliant work in getting this working. 😀

I've seen KVM, WHPX and HAXM mentioned here. I agree with others here that it would be useful to also have this work properly with HAXM, since not all editions of Windows 10 include Hyper-V and thus WHPX. Also, a lot of Windows users are not on Windows 10 yet, and perhaps won't ever upgrade to Windows 10.

Would this also work with Apple's Hypervisor.framework on macOS and Xen on other systems, since QEMU supports those virtualization accelerators as well?

I understand that Xen might not add a lot of value for Linux users, since KVM support already works at least as well. But it might be nice for people who run BSD or OpenSolaris systems with Dom0 kernels. (I admit, this would be a very small niche that might not be worth investing much effort in.)

Also, it would be great if the sound emulation code from DOSBox could be ported to QEMU. I know QEMU already supports SB16 emulation, but isn't the implementation in DOSBox far superior? Also, it would be cool to have QEMU support the other emulated sound devices from DOSBox as well, such as the GUS. Since both QEMU and DOSBox share the same GPLv2 license, it would be no problem to share code back and forth between both of them.

High quality legacy sound emulation coupled with hardware-assisted virtualization and problem-free 3Dfx Glide pass-through may very well be the Holy Grail of retro gaming on modern PC hardware! 😁

I did not own or have any MacOS system at my disposal. Someone would need to help to check it out on the MacOS side. I can definitely take a look at Intel HAXM support, but I won't be able to fix anything on the Intel HAXM side.

robertmo wrote:

I wonder why whole huge QEMU works with HAX and it is only that tiny piece of code of glide passthrough that doesn't.

Because glide passthrough introduces new MMIOs which force VMEXIT from the hardware virtual machine for QEMU to perform device emulation. The VMM needs to decode the instruction to extract relevant information and passes them to the device emulation layer. Typically, correctly decoding the instruction would also give the clue for the VMM to resume execution on the hardware virtual machine at next instruction. Otherwise, the hardware virtual machine would have stalled and halted. This is an over-simplified description as VMEXIT also involved other synchronization between the hypervisor and VMM.

Software rendering in DOS mostly involves CPU writing to framebuffer, and in QEMU implementation this does not force VMEXIT until the display timer function triggered for screen update. And, you're right, today's accelerated VM can be very fast for software rendering in the Pentium era because CPUs today run at GHz with high-speed memory.

Please provide details on your QEMU version and Intel CPU model. I couldn't get WHPX/HAXM to work in DOS on my laptops with Intel CPUs, a Haswell (4000-series) and a Skylake (6000-series). WHPX works for Win98 and Win2k. HAXM didn't work for Win98 when I tried it last time, and I didn't bother for it anymore and moved to WHPX. Is Pyl (Dust) using DOS4GW?

WHPX works on my AMD FX8300 desktop for any OS'es I thrown at it.

digger wrote:

Would this also work with Apple's Hypervisor.framework on macOS and Xen on other systems, since QEMU supports those virtualization accelerators as well?

I hope someone else would volunteer to check it out and report back.

digger wrote:

Also, it would be great if the sound emulation code from DOSBox could be ported to QEMU. I know QEMU already supports SB16 emulation, but isn't the implementation in DOSBox far superior? Also, it would be cool to have QEMU support the other emulated sound devices from DOSBox as well, such as the GUS.

QEMU already supports SB16 and GUS. Never tried out GUS in QEMU, but you're right, DOSBox sound hardware emulation is far superior. However, when it comes to Windows, SB16 and GUS would mean nothing anymore. I think QEMU community favors AC97 and HDA which are industry open specification, well understood and vendors agnostic drivers support. A3D/EAX/Sensaura 3D positional audio has never really taken off to be significant in the games industry.

Suggested specs for a full speed DOSbox machine?
pyl uses dos4gw

What's the system requirement for Pyl (Dust)?
Have you tried QEMU TCG and what kind of performance were you getting from QEMU TCG?
Well, I am asking this because early DOS Glide games are poorly coded in an awkward way, mostly on LFB/depth buffer operations, that makes them not benefiting much from going into VM acceleration.

It will be helpful if you can check out the game with QEMU TCG and report if you get any "WARN xxx" from QEMU console of peculiarity. And, you also need to make sure that LFB mode using shared memory works with QEMU TCG. If the game requires MMIO handler for LFB, then VM acceleration would never work for it.

So far, here's the list of DOS Glide games that WHPX acceleration on AMD FX8300 does not make any difference:
- Tomb Raider 1, low CPU requirement, perhaps very weak CPU such as AMD C-60 or Celeron 847 would make a difference if any.
- Carmageddon 1, TCG is faster with Voodoo Graphic mode.
- Extreme Assault, no difference. SW rendering works very well with WHPX acceleration.

These DOS Glide games works with WHPX acceleration:
- Blood 1, but has "slow-motion" effect. KVM is fine though, very fluid animation (Core-i3/Intel Graphics/OpenGlide).
- Redguard, but has "slow-motion" effect. Haven't tried this on KVM if the "slow-motion" would go away with KVM.
- Archimedean Dynasty, very fast and smooth 80~100fps, not sure if this would be too fast. TCG can sustain 25~35fps which is still highly playable.

BTW, you can also run the game from Win98 DOS. The DOS guest wrapper GLIDE2X.OVL works from Win98 DOS, too. This is something I would try since WHPX works for Win98 on Intel CPU.

OK, I got the fix for Intel HAXM. It is working now on my Core i3 laptop for DOS4GW.

I think Intel HAXM VMM has issue handling MMIOs encoded in CMP instruction such as "cmp dword ptr [mem], imm". When the mem is not memory but MMIO that forces an VMEXIT, it seems to repeat the same instruction and end up in never-ending loop of VMEXIT and replay the same instruction. Perhaps someone should also file a bug in Intel HAXM github.

The Watcom compiler would generate such instruction, but not GCC which produced the DLLs used in Windows. (Screw the Watcom, too 😠 !) GCC would generate "mov reg, dword ptr [mem]; cmp reg, imm" and this works for Intel HAXM.

Anyway, I can workaround the compiler issue by rewriting the code to generate similar code as GCC would do.
Attached the fixed GLIDE2X.OVL.
Update: DOS OVL guest wrapper fix available in 1st post.

kjliew wrote:

WHPX works for Win98 on Intel CPU.

Are you sure about it?

because earlier we concluded that it doesn't work:

kjliew wrote:

robertmo wrote:

geting this soon after starting (without boot image while qemu looks for boot disk) or with a simple "dir" when booted to dos w […]
Show full quote

geting this soon after starting (without boot image while qemu looks for boot disk)
or with a simple "dir" when booted to dos with no autoexec.bat
or lots of other cases at the exact same moment generally at the very beginning of different types of boot of windows
qemu-system-x86_64.exe: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2
qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor

I got the same error on my Intel Core-i3 laptop, too.

Yes, WHPX works for Win98, it works on my AMD FX8300 desktop, Core i7-6xxx laptop and Core i3-4xxx laptop. All running Windows 10 x64 1803, recently updated to 1809. It's the "DIR" that is not working. I can also do "CD" somewhere and run PCPBENCH. You need to make sure the Win98 VM is all setup with either VMWare SVGA or VBEMP9x driver to avoid standard VGA mode before enabling WHPX. I typically use 800x600x16bpp, Cirrus PCI or standard PCI VGA won't work.

This game, Pyl (Dust), is very strange to me. I cannot explain why it is so slow even on TCG as reading/writing LFB when LFB is just a shared memory should be pretty fast with QEMU TCG. I tweaked my local QEMU to direct all LFB operation into shared memory, ignoring all the rendering glitches, and yet it is still very slow in-game. The menu, the text briefing and the opening where the spider is moving, all rendered at over 30fps even with TCG. Even in Turok 2 staring on the wall will give me over 30fps with TCG, but this one just around 7~9fps. Where did the game spend all the CPU time? I disabled sound completely, set to None, and yet nothing improved. It doesn't seem to me that this game has super detailed polygonal models or vast world map.

WHPX does not work for Pyl., it hung at "Loading...." after starting a new game. Glide traces showed repeated calls on guFogTableIndexToW(). Glidos had debugged similar issue on Pyl, too, not sure if he ever had a fix on this. Another craziness of low FPS DOS Glide game on QEMU is Tie'Break Tennis, but I didn't spend a lot of time on that game.

Though I haven't checked it out myself, I know that this game is also not playable on DOSBox with glide pass-through. Did you get a chance to try other emulator such as PCem?

kjliew wrote:

OK, I got the fix for Intel HAXM. It is working now on my Core i3 laptop for DOS4GW. […]
Show full quote

OK, I got the fix for Intel HAXM. It is working now on my Core i3 laptop for DOS4GW.

I think Intel HAXM VMM has issue handling MMIOs encoded in CMP instruction such as "cmp dword ptr [mem], imm". When the mem is not memory but MMIO that forces an VMEXIT, it seems to repeat the same instruction and end up in never-ending loop of VMEXIT and replay the same instruction. Perhaps someone should also file a bug in Intel HAXM github.

The Watcom compiler would generate such instruction, but not GCC which produced the DLLs used in Windows. (Screw the Watcom, too 😠 !) GCC would generate "mov reg, dword ptr [mem]; cmp reg, imm" and this works for Intel HAXM.

Anyway, I can workaround the compiler issue by rewriting the code to generate similar code as GCC would do.
Attached the fixed GLIDE2X.OVL.

Wow, that's some impressive low-level software engineering. 😮 As a high-level Java/Kotlin deloper by profession, I can't help but be a bit envious of your knowledge of such close-to-metal programming and debugging. 😉

Thanks for getting HAXM working so quickly. 😀 This will provide a nice alternative for Intel CPU owners who use a Windows version other than Windows 10 x64 Pro or Enterprise.

Any macOS users here willing to test kjliew's work with QEMU and Apple's Hypervisor.framework ("-accel hvf")? 😀

Will this run on Hackingtosh? Mac HW is overpriced, i had MacMini but i get rid off it, because was noisy as hell.. VIrtual box and Vmware workstation is funning fine on them.

hvf was added together with whpx in qemu 2.12 as experimental so i wouldn't expect much from it for now.
haxm was added in qemu 2.9 for windows and in qemu 4.0 for linux

kjliew wrote:

WHPX does not work for Pyl., it hung at "Loading...." after starting a new game.

got the same with HAXM.

kjliew wrote:

I know that this game is also not playable on DOSBox with glide pass-through.

well.. I have finished it in dosbox on a Phenom 9550. I had to play this game to be able to verify my translation was correct Pył, Pyl, Dust English language version
I have started on a Pentium III 450 MHz with Voodoo 3, but decided to play in dosbox to test its compatibility at the same time too (in higher resolution as a side effect 😉 ).
It was just a matter of walking while looking at floor and adjusting viewable distance depending on what you wanted to do and saving a lot 😉

hello everyone =)
i seen that post read first msg, and some other , i see its most fast 3dfx emu / wrap?

sorry noob , completely out of idea what going on here .

How to use that thing?

well first step would be to install qemu and have fun with it a bit

This game (Pyl or Dust) is a very good test case for AUX/DEPTH buffer locking. DgVoodoo2 is probably the only Glide wrapper that would support this. I was able to tweak the LFB implementation with shared memory to support AUX/DEPTH buffer. Before this, any games that lock AUX/DEPTH buffer would automatically use MMIO handlers for AUX/DEPTH buffer, only FRONT/BACK buffer will be handled through shared memory. I am also able to get OpenGlide to work on this game, using MMIO handlers, since OpenGlide does not support AUX/DEPTH locking. Visual effects relying on AUX/DEPTH buffer will be missing (for eg. smoke), but textures, lighting and the rest seemed to be OK. Lens view seemed OK, but I wasn't familiar with this game enough to conclude if dummy AUX/DEPTH buffer readback would affect the gameplay.

There is slight improvement in FPS using the new LFB implementation with dgVoodoo2, and staring at wall would give 30FPS and on places where field of depth is close (don't look at smoke!) would see FPS around 17~22FPS. Not so great. Reducing fog distance in the Graphics Option would help FPS, too. OpenGlide with MMIO handlers would have similar results. too, albeit missing some visual effects.

It seems to me that this game maybe banging on CPU to perform special effects with per-pixel operation. This will be hard on CPU emulation. So far, I can't get this game to work with WHPX/KVM acceleration. Typically, CPU computation intensive workload would see huge improvement with WHPX/KVM when it works. Until then, I don't know if this is the main issue of the sluggishness.

Extreme Assault and Archimedean Dynasty are 2 other games with AUX/DEPTH locking. They do AUX/DEPTH write-lock to paint the overlaid HUD. Perhaps, there is nothing fancy on the HUD required for the per-pixel operation. AD seems to only do this once on the start of a mission. That explains why it runs so fast on WHPX even though MMIO handlers are in placed for accessing AUX/DEPTH buffer. On the contrary, Pyl does AUX/DEPTH read-lock, and my guess, it uses the read-back to do per-pixel environment special effects that iterate on every frame.

Does it work with static linked games?
i think it can be done somehow, if not currently.
maybe just my dreams, or noobish ideas 🤣

deep thinking on that -> http://www.zeus-software.com/forum/viewtopic. … hp?p=8491#p8491

robertmo wrote:

kjliew wrote:

WHPX does not work for Pyl., it hung at "Loading...." after starting a new game.

got the same with HAXM.

If you choose to load game instead of new game the "Loading...." screen slowly disappears to reveal black screen.

Alright, I got Pyl working with WHPX/HAXM acceleration. Frame rate seems to improve about 2x across the board. But don't rejoice too early, even with 2x frame rate across the board, having smoke or other CPU intensive effects would still be slow. Anyway, what more can we expect when doubling the performance would mean from 6~7FPS to 12-14FPS. Overall, I would say the game feels smooth with acceleration, compared to TCG.

I wonder what the minimum/recommended system requirement is to play this game back then in 1999 as the game debut. Was it something like Pentium 3 500MHz with Voodoo2?

Patch and guest wrappers prebuilt binaries updated in 1st post.

Many thanks to robertmo for his courtesy for getting Pyl to run on QEMU. As a result, I am able to improve shared memory LFB mode to support AUX/DEPTH buffer, which is critical for QEMU acceleration. QEMU Glide pass-through issue with Intel HAXM is fixed. So far on Windows 10 x64, I had tested Intel HAXM with DOS and Win2k VM. Intel HAXM does not like Win98 at all.

I had only done minimum Intel HAXM testing opportunistically. if someone had done more thorough testing with Intel HAXM including older or 32-bit Windows, you are welcome to report back your results.