QEMU 6.2 + 3dfx patch, freeze or no mouse/kb after login win98

[daerlnaxe]

hi,

Just to signal after have installed all files compiled for the guest, just after login i can't move mouse or use keyboard on windows 10 x64 host.

For the while i found use "-M pc,accel=whpx,kernel-irqchip=off" instead of "-M pc,accel=whpx" stopped the problem, it seems to be a QEMU 6.2 problem. (EDIT: with "-M pc,accel=whpx,kernel-irqchip=off" and half-life, i got a crash i replaced by -accel whpx,kernel-irqchip=off" and it works)

It seems to be in relation with fxmmemap.vxd, if i remove it from "c:\windows\system" it's ok, i compiled it under msys2 as under linux .

It was a big blocking problem to test QEMU-3DFX. I ran Half life yesterday with an average 72fps, but sound is not very good with ac97 for the while with realtek drivers, i'm trying "Avance Logic AC'97-3.26" drivers.

ps: i don't know if i was the problem before but now i can't shutdown properly win98 -> black screen.

[kjliew]

FXMEMMAP.VXD has nothing to do with kbd/mouse. Windows WHPX requires kernel-irqchip=off to disable APIC emulation for legacy Guest OS such as Win98/2K/ME/XP. This is an upstream QEMU issue.

https://github.com/kjliew/qemu-3dfx/wiki#setting-up-windows-98-se-virtual-machine-on-qemu
If you had followed the wiki documentation on how to setup Win98 VM for KVM/WHPX acceleration, then you would not have the shutdown black screen. If you prefer a less hassle process, then don't use Win98 VM. Use Win2K/XP VM for games that don't explicitly require Win98. Half Life is one of those.

This project does not deal with general useability issues from upstream QEMU. The patch does not touch in anyway related to kbd/mouse/audio emulation from QEMU.

[daerlnaxe]

Thanks for the tip i didn't understand why there were this part about msdos.sys then it was the only part i never did, work fine now.

About kernel i understood there were not a common with mouse or kb, but i couldn't verify if os was always ok or frozen, this is why i prefered to say just that. I write if for others in case they encounter the same problem because from the point you pass that it's easy after to appreciate your work.

It's good job.

[kjliew]

It's good job.

Thank you. You just got to have faith, didn't you? 😉

I followed QEMU since its inception and learned everything bits by bits. I am no virtualization expert who claimed to possess vast experience in Linux virtualization/IaaS deployment. For an active FOSS project, it will continue to evolve, new issues arise, issues got fixed etc. I am in no capacity to be the answers for all your QEMU usability inquiries. Upstream QEMU is a good place to start. This is the common sense.

During my participation in VOGONS forums, I posted screenshots of Windows games I tested that worked perfectly before I started my own YouTube channel to do the same with short videos.
https://www.vogons.org/viewtopic.php?f=24&t=72859

Since everything about QEMU seemed to be so great that its performance smokes other amateurish PC emulators and goes against the Moderator's mantra that "virtualization is only good for speed but bad for games compatibility", everything about QEMU for retro games became an act of disparaging for "a very sensitive project" that takes only gospel & glory but no criticism. So in the end, fellow VOGONS-ers lose out on another avenue for retro games. The Moderator didn't pay a shit on it and made everyone happy with source-ports, fans' made patches and building retro PCs. For those who just want to play good old games, good luck with VOGONS!