TomB, because you are one of the few people here, who did launch QEMU with 3dfx passthrough under Linux, please tell me, how. I compiled QEMU 4.1.1, applied patch, I compiled OpenGlide and copied libglide2x.so to /usr/local/lib, installed Windows 98SE, copied Glidex.dll and Glide2x.dll from DGVoodoo 1.50 into Windows/system and still can't launch test04.exe.
Hi OSH, I'm not TomB but I did some testing on a Linux Mint 20 host and got test30.exe going in a DOS guest, so that's something at least 😁
Since there's even a shiny new version out now for qemu 5.2.0, I'm sure there are others out there itching to try this out as well.
I posted a couple of issues on GitHub about this, but basically what helped was to compile GLIDE2X.OVL manually.
Some minor patching was needed on the qemu side as well. I don't actually *know* the code, so take these with a grain of salt...
- In hw/mesa/mglcntx_linux.c, I added a couple externs that were missing - this one has been fixed in git
- In hw/3dfx/glidept_mm.c, function glidept_write(), on line 928 (case 0xfbc) there's an if clause that must be commented out, or OpenGlide never launches.
- In the same file, line 275, some s->arg[] values were zeroed out for some reason(?) so I gave them some hopefully more sane values.
Hope this helps someone.
EDIT: By "more sane values" I mean something I dug out via trial-and-error, probably not acceptable for general use...something like:
set s->arg[7]=0xfb000000;
(added that line in processArgs(), just before init_window() is called).
EDIT2: Looks like none of this hodgepokery is needed any longer, because kjliew introduced a fix: the guest stubs are now stamped
So, just use the newest git version and make sure guest and host are in sync with each other (using code from the same git level), and you should be set 😁
hi mr.cat, thanks! Can you give me a link to this GitHub section? I desperately try to figure out, how can I launch 3dfx under emulated Windows 98 on Ubuntu, but I see, persons, who can give me an answer, have better things to do in their life. I'll try to check this under DOS...
Hi!
Yeah...I know...this stuff is supercool, but unfortunately also seems to be quite fragile. The github link is infact in the first post of this thread, but here's the direct link to issues:
https://github.com/kjliew/qemu-3dfx/issues
For future reference, here's the exact command line for compilation:
../qemu-5.2.0/configure --enable-opengl --enable-sdl --enable-gtk --target-list=x86_64-softmmu,i386-softmmu --audio-drv-list=sdl,pa --disable-capstone --disable-slirp
This is what I used for launching the guest:
qemu-system-x86_64 -m 64 -net none -display sdl,gl=on -vga cirrus -drive file=qemu_dos.qcow2,format=qcow2
OpenGlide was compiled with SDL (which is the default, so no extra flags were necessary).
If you get assert errors, that probably means that OpenGlide is not launched for some reason. It might be necessary to run "ldconfig" (with sudo?) the first time so that dlopen() can find the .so file.
Thanks, mr.cat, I'll try it! Can you tell me, where you copied libraries for Glide (under HOST and GUEST)?
Well OpenGlide installs its libraries by default in /usr/local/lib, once you run "sudo make install". I'm not sure if there are any other options for host wrapper in native Linux.
On the guest side, the only wrapper that is used in DOS is GLIDE2X.OVL, which I compiled manually using the Linux version of OpenWatcom v2. The Makefile needed some small alterations, namely:
- I changed the directory separator to /
- On line 15, I added the parameter -fo=glideovl.obj
The file GLIDE2x.OVL should be in the same directory where you have test30.exe (or maybe in PATH, I'm not sure). I have them both in C:\
Good luck!
I forgot to mention I'm using robertmo's boot.7z image (see earlier in this thread). I was initially trying to use the version of GLIDE2X.OVL that is included in that file, but the closest that I ever got with that was using an old git version 7459273 (Oct 2019) and qemu3...it got as far as show a still image, but with a lot of FIFO errors. So it seems the guest wrapper must match the code used for qemu.
The Linux compilation problem that I mentioned was fixed in git already by kjliew, so thanks for that 😁
I gave this a quick spin in a Win98 guest (on a Linux host), and was able to run test04.exe and wglgears.exe successfully.
So, for Win98 guest on Linux host:
- First, install some build tools and other packages that are needed:
sudo apt install git gcc g++ build-essential pkg-config m4 make cmake autoconf automake libtool ninja-build
sudo apt install libepoxy-dev libgbm-dev libglib2.0-dev libsdl2-dev libpixman-1-dev libgtk-3-dev
sudo apt install gcc-mingw-w64-i686
- Install OpenGlide: https://github.com/voyageur/openglide (clone the repo and run ./configure && make && sudo make install)
- Install qemu-3dfx: https://github.com/kjliew/qemu-3dfx (just follow the instuctions given in README, you may need to give the sign_commit script run permission if you see Permission denied errors)
- You'll have to install pexports separately, since it's not included with the mingw packages. I think I got the source (pexports-0.47-mingw32-src.tar.xz) here: https://qa.debian.org/watch/sf.php/mingw
- Compile the guest wrappers (the directories wrapper/src and wrapqgl/src). The makefiles need some customizing to get them to jive: Comment out the line with a MINGW32 environment check, and the mingw versions of gcc and dlltool should be used instead of plain gcc or dlltool (the line with CC=gcc should be changed to something like CC=/usr/bin/i686-w64-mingw32-gcc-9.3-win32 instead).
- You may see an error message about i686-pc-msdosdjgpp-gcc, this is the DXE stuff so not needed here. In case you still want to try it out, DJGPP can be built with these scripts: https://github.com/andrewwutw/build-djgpp
- Copy the resulting files glide.dll, glide2x.dll, glide3x.dll and opengl32.dll into guest's Windows SYSTEM directory.
- Do the same with the kernel drivers (fxmemmap.vxd and fxptl.sys, see the first post. fxmemmap.vxd comes from the Glide 2.43 SDK and fxptl.sys can be found in package voodoo2-win2k-10200.exe, for example). Run instdrv.
- Launch qemu with -display sdl and go run test04.exe or whatever. Also, for Win98, use maximum of 512MB memory.
- The guest vm should be configured with ACPI. The easiest way to do this is to use the extra switches for Win98 install: SETUP /NM /PJ
- kvm should be disabled until the guest has been configured. If you experience instability with Win98 guest, try disabling kvm (YMMV, might depend on hw)
- See this post for some guest configuration tricks that are needed: Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)
- If you experience page faults (pointing to KERNEL32.DLL, for example), check the kernel drivers. It may be necessary to run instdrv.
- Use bearwindows (VBEBM) drivers in the guest. This trick needs to be applied: Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)
- If you use KVM with VBEBM drivers, this fixes the problem with shutdown: Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)
Hopefully that's all...Please note that the process is a bit different for newer Windows, kjliew has described it previously in this thread.
I had some confusion about the usage of opengl32.dll, because it is possible to get the Windows native implementation for wglgears.exe. Just check the qemu console and see that you get some messages about wrapper activation.
Many thanks mate!!! I'll try and give you info!
Gave it a go on a WinXP guest too, but it immediately crashes with 0xc0000005 error. The guest vm in question is a bit suspect and I guess I'm not very well qualified for this Windows stuff anyways...
kjliew did mention that Win2k/XP uses a different init mechanism (KMD vs. VXD) although the .dll files are the same, so could be something compiling related too.
If anyone has gotten this to work on a Linux host and Win2K/WinXP guest, feel free to chime in.
For Win2k/XP, it requires the SCM to install the driver before user-space DLL can access it. I uploaded the fx_kdrv.zip in the 1st post. Copy fxptl.sys to %SystemRoot%\system32\drivers and run "instdrv.exe" in the guest OS.
Thanks man, that did the trick.
AFAIK Win2K/XP guests can be used with -enable-kvm, so that's a plus. And although there are vmware, vbox etc. for WinXP guest use already, its always nice to have alternatives.
mr.cat wrote on 2020-12-14, 15:43:AFAIK Win2K/XP guests can be used with -enable-kvm, so that's a plus. And although there are vmware, vbox etc. for WinXP guest use already, its always nice to have alternatives.
If you have Intel CPUs or older AMD CPUs not from Ryzen generations, then Win98 guest can also be used with --enable-kvm.
Win98 guest works great on my Core i3-4010U and Core m3-6Y30 thin-n-light laptops on ArchLinux.
WinME guest works great on any modern CPUs, including Ryzens, and boot a lot faster than Win98 guest.
It is always an advantage to be able to run Win98/ME VMs, they are more compatible with old Windows games and no unofficial patching of games required. This is where VMware/VirtualBox is lacking.
mr.cat I have problem with this part.
mr.cat wrote on 2020-12-13, 21:51:- Install mingw-w64 on the host (package gcc-mingw-w64-i686 I think, and maybe mingw binutils also) - You need to install pexpor […]
- Install mingw-w64 on the host (package gcc-mingw-w64-i686 I think, and maybe mingw binutils also)
- You need to install pexports separately, since it's not included with the mingw packages. I think I got the source (pexports-0.47-mingw32-src.tar.xz) here: https://qa.debian.org/watch/sf.php/mingw
- Compile the guest wrappers (the directories wrapper/src and wrapqgl/src). The makefiles needs some customizing to get it
I had some confusion about the usage of opengl32.dll, because it is possible to get the Windows native implementation for wglgears.exe. Just check the qemu console and see that you get some messages about wrapper activation.
I'm quite unexperienced Ubuntu user, and I make my first steps in compiling programs. So can you more precisely describe, what I should do? I don't know how install pexports, and how compile guest wrappers…
Hi,
So jumping head first into deep Linux waters are we? That's the spirit!
I did omit a lot of "kinda obvious" stuff, but I've now expanded the original post a bit, to include at least the packages that are needed (hopefully I got them all listed!).
Here are some basics, to install mingw-w64:
sudo apt install gcc-mingw-w64-i686
That works only on Debian-based distros though. It seems every distro wants to reinvent the wheel when it comes to managing packages. So check your distro's docs and use the "man" command when in doubt.
As I said, I'm not sure if that one package is enough or if you need something else...if you get error messages like "command not found", you're probably missing some binutils/tools package.
It looks like the binutils package is a dependancy (so it will be installed automatically). Binutils is needed for dlltool at least.
If you get error messages about package installation, you might need to setup some repos, or the package might not be available in the repos at all. In which case it needs to be manually compiled.
As for compiling from source, there is usually a README or INSTALL file or docs directory that describes the procedure.
But *usually* it boils down to just running "./configure && make", sometimes even a simple "make" will do (if the directory has a file named "Makefile", the make command will try to run it).
After that, "sudo make install", can be used to install binaries to some more convenient location.
You can PM me if you need further instuction. Since this thread is not about Ubuntu support, let's keep that stuff to a minimum & I'll update the relevant bits here, if necessary.
Thanks mr.cat! I like to learn new things. 😀 I'll try, and if I have problems I'll PM you!
mr.cat, I sent you PM, but it's still in my Outbox. Maybe your Inbox is full?
OSH wrote on 2020-12-16, 08:25:Thanks mr.cat! I like to learn new things. 😀 I'll try, and if I have problems I'll PM you!
mr.cat, I sent you PM, but it's still in my Outbox. Maybe your Inbox is full?
Ah, sorry. I didn't realize there is a quarantine period for us newbies...
I'm unable to use the private messages section just yet. So no, my inbox isn't full 😁
But as for the question: the wrappers section directories only has a Makefile.in file, and that needs to be customized to be usable in Linux. Maybe some makefile magic could be done to help portability, but it isn't there yet.
You can ofc try to use it, by explicitly giving the filename ("make -f Makefile.in"), but it will most likely just spill out some error messages and not do anything useful.
So, make a copy of it (name it Makefile.linux or just Makefile) and edit in the small changes that I listed earlier.
EDIT: Made some changes to the original post to clarify the Makefile changes. In makefile, lines beginning with # are comments.
I added it here as an attachment also (this one is for wrapper/src), that should make it easier.
Thanks… I'm really embarassed, I had to ask you for help, but I hadn't any other choice. You are the first person, who really helped me. I'll try and give you info. I think, when all will be done, I'll make a guide for other people, how to set up this all thing to use QEMU with 3dfx passthrough under Ubuntu, because it's not a simple thing.
OSH wrote on 2020-12-16, 10:18:Thanks… I'm really embarassed, I had to ask you for help, but I hadn't any other choice. You are the first person, who really helped me. I'll try and give you info. I think, when all will be done, I'll make a guide for other people, how to set up this all thing to use QEMU with 3dfx passthrough under Ubuntu, because it's not a simple thing.
Well no need, these things are not obvious at all until you have sufficient experience, and that takes time. But you have the right attitude! No-one is a blacksmith when they are born, goes an old Finnish phrase 😁
I did everything and I got…
glidept: DLL loaded - glide2x.dll
trace: _grSstControl@4 called
trace: _grSstControl@4 called
trace: _grGlideGetVersion@4 called
glidept: grGlideGetVersion Glide 2.45 - OpenGLide 0.09rc9
trace: _grGlideInit@0 called
glidept: 3b968d4-21:23:25 Dec 16 2020 build WRAPFX32
wr2x_trace: _grSstQueryHardware@4
wr2x_trace: _grSstSelect@4
glidept: grSstWinOpen called, fmt 1 org 0 buf 2 aux 1 gLfb 0xcd1c0000
Speicherzugriffsfehler (Speicherabzug geschrieben) - this means "Memory access error (core dump saved)"
QEMU exited
OSH wrote on 2020-12-16, 21:08:I did everything and I got… […]
I did everything and I got…
glidept: DLL loaded - glide2x.dll
trace: _grSstControl@4 called
trace: _grSstControl@4 called
trace: _grGlideGetVersion@4 called
glidept: grGlideGetVersion Glide 2.45 - OpenGLide 0.09rc9
trace: _grGlideInit@0 called
glidept: 3b968d4-21:23:25 Dec 16 2020 build WRAPFX32
wr2x_trace: _grSstQueryHardware@4
wr2x_trace: _grSstSelect@4
glidept: grSstWinOpen called, fmt 1 org 0 buf 2 aux 1 gLfb 0xcd1c0000
Speicherzugriffsfehler (Speicherabzug geschrieben) - this means "Memory access error (core dump saved)"QEMU exited
Interesting...this doesn't say much to me, but looks like you're pretty close, since OpenGlide is trying to create a window.
One thing that you could do is to ensure is that your host has a working Mesa setup, an easy way to check that is to run glxgears and glxinfo (these are in package mesa-utils).
Although nowadays I think its quite rare to encounter any problems there (or at least I haven't encountered them).
Also, if you can test the DOS stuff, maybe it's worth giving a shot to see if there's any difference.
