QEMU 3Dfx Glide Pass-Through

Schedules and announcements about program releases.

QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-6-27 @ 23:01

Hi,

This opens another new possibility for those keen on getting ancient 3Dfx Glide games to run on Window 10 AS-IS, no fans' patches no-frills way of running the games under Win98/ME on QEMU. DOS pass-through is also possible but it is not implemented yet. DOSBox should be extremely good for 3Dfx Glide DOS games. I have tested several Win9x games/demos which are notoriously hard or impossible to run on Windows 10.

It also run Quake2/GLQuake and perhaps all its kinds and flavors, but there are always better ways to run those games natively. Simply tried out for fun.

Performance, well, on AMD FX8300, I would say it is about a P166MMX. A highly clocked, turbo capable Core-i7 may get you into the level of P200MMX or PII-266. Single thread performance is always dominant in emulation, hence Intel CPU would typically fare better than AMD at similar clock frequency.

The challenge, in order to play with this, you will have to build QEMU on your own for now. This used to be a daunting task, especially on Windows, but with MSYS2/mingw-w64 maturing today, it is not as difficult as it used to be. For hardcore Visual Studio fans, I am sorry, building QEMU with VS is unsupported.

DOS Glide Games
Tomb Raider 1 / Unfinished business
Blood 1
Land of Lore 2 GoD
Carmageddon 1
Extreme Assault
Archimedean Dynasty
Elder Scrolls Redguard
BC3000 A.D. 2.09 Freeware

Windows Glide Games
Mechwarrior 2 31st 3Dfx-enhanced
Titanium Mechwarrior 2 series (31st/GBL/Mercenaries)
NFS 2 SE Demo
NFS 3 Hot Pursuit
Nuclear Strike
Turok 1 Demo
GLQuake
Quake 2
Half-Life 1
Blaze & Blade Eternal Quest
MDK 3Dfx
Myth The Fallen Lord demo

Update:
- Glide pass-through for DOS Glide games.
- Linux support is done. Tested with OpenGlide and NVIDIA propriety driver on Ubuntu 16.04LTS. QEMU must use SDL1/SDL2 for display with "-display sdl". GTK display does not work. GTK display works, and it is currently the best option in Linux as OpenGlide does not steal input focus on spawning Glide rendering window.
- Windows NT/2k/XP pass-through is done. Guest wrapper DLLs use standard VXD on Win9x/ME and KMD on NT/2K/XP.
- Unfortunately, KVM does not work for Glide pass-through, even though Windows 2000 is perfectly accelerated by KVM. Perhaps, the Glide pass-through requires modification to prevent host from peeking into guest memory. This requires changes in both the guest wrappers and Glide pass-through such that the guest wrapper will be copying data instead of host.
Attachments
wrapper_guest-20180906.zip
Prebuilt guest wrappers
(32.09 KiB) Downloaded 5 times
qemu64-3dfx-20180906.tar.gz
QEMU 3Dfx Glide pass-through
(30.39 KiB) Downloaded 3 times
Last edited by kjliew on 2018-9-08 @ 19:07, edited 15 times in total.
kjliew
Member
 
Posts: 202
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby t9999clint » 2018-6-28 @ 00:21

This sounds really interesting, I am very curious to see the performance of this on Linux when that bit is done.
GLIDE passthrough + KVM would be pretty epic.
User avatar
t9999clint
Newbie
 
Posts: 47
Joined: 2014-10-07 @ 14:08
Location: Edmonton, Canada

Re: QEMU 3Dfx Glide Pass-Through

Postby Stiletto » 2018-7-01 @ 14:33

BTW kjliew: due to this development, I've put a bug in the ear of Dege's "competitor" Zeus regarding a 64-bit build of nGlide (closed source), though time will tell if he'll actually do it. Surprised you haven't tested the 32-bit version of nGlide yet though.

If you're feeling really daring, kjliew, you could try making a 64-bit compile of dgVoodoo 1.40 or 1.50 Beta3:
http://www.vogonsdrivers.com/getfile.ph ... state=53,0
http://www.vogonsdrivers.com/getfile.ph ... state=53,0
But the build process sounds quite challenging to begin with, I don't want to think what would happen if you tried...

Even crazier/hilarious, you could try testing:
- Zeckensack 0.84c (OpenGL, glide2x/glide3x, closed source, 32-bit only): http://www.zeckensack.de/glide/
- SvensWrapper (OpenGL, glide2x through a special file/primarily glide3x, closed source, 32-bit only): http://www.svenswrapper.de/english/
- SvensWrapper glide3x-only with GlideXP's Glide2x->Glide3x translator (could possibly work, IDK, I've never tried: https://wenchy.net/old/glidexp/ )
- uGlide (Direct3D, glide2x, closed source, 32-bit only, but recently active: could request they make a 64-bit build tho): http://www.hedgehogeyes.com/uglide.html
- some version of Glitch64 (OpenGL, glide3x, open source, 32-bit only) combined with GlideXP: http://www.vogonsdrivers.com/wrappers/f ... /Glitch64/
- the final release of eVoodoo (Direct3D, glide2x/glide3x, closed source, 32-bit only): http://www.vogonsdrivers.com/wrappers/f ... D/evoodoo/
(for more from before the modern wrapper era, and more mirrors, see: http://www.vogonsdrivers.com/wrappers/files/Glide )
Crazy I know, but I think it'd be funny to see the compatibility testing, and among other things, would be funny to see someone build something new out of Glitch64... you could maybe even build a new different Glide wrapper out of its source, IDK.

PS. don't forget to check on your psVoodoo thread, I sent Glidos a PM about it.
"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto
User avatar
Stiletto
l33t
 
Posts: 4084
Joined: 2002-7-01 @ 21:57

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-01 @ 19:51

Greetings Stiletto, my friend!

Stiletto wrote:BTW kjliew: due to this development, I've put a bug in the ear of Dege's "competitor" Zeus regarding a 64-bit build of nGlide (closed source), though time will tell if he'll actually do it. Surprised you haven't tested the 32-bit version of nGlide yet though.


I wanted to try out nGlide, but the current problem is - it doesn't support windowed mode, and I am having problem with QEMU SDL1/2 windowing code not allowing Glide wrappers to hijack its window :dead: OpenGlide, psVoodoo and dgVoodoo all are supporting windowed mode. When I started to have Glide wrapper rendered into the same QEMU window instead of spawning a new window, which I did initially to get around the problem so that I can focused on the pass-through implementation, only dgVoodoo2 is capable of managing its window sizing on its own, and I don't know what magics Dege had on dgVoodoo2. I have to remove the window sizing code from OpenGlide and PsVoodoo for them to work.

And, thanks for your kind attention on getting in touch with nGlide author, Zeus. I had thought of contacting him myself initially. I had worked with Dege in the past, so I started with him on dgVoodoo2. And there is still a lot to do before checking out other Glide wrappers, I decided to move on with dgVoodoo2.

Stiletto wrote:If you're feeling really daring, kjliew, you could try making a 64-bit compile of dgVoodoo 1.40 or 1.50 Beta3:
http://www.vogonsdrivers.com/getfile.ph ... state=53,0
http://www.vogonsdrivers.com/getfile.ph ... state=53,0
But the build process sounds quite challenging to begin with, I don't want to think what would happen if you tried...

Oh yeah, you read my mind. I was actually thinking of doing this, reviving only the Glide wrapper part of dgVoodoo1.50Beta3. The plan is to get modern GCC to build dgVoodoo1 with GNU Makefile instead of VS. I have already done this for PsVoodoo. DgVoodoo1 is of particular interest because of its accurate implementation of Glide APIs. I remembered I compared its rendering output side-by-side with a real Voodoo2 back then, and for the stuffs that I care, they were mostly indistinguishable.
kjliew
Member
 
Posts: 202
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby Stiletto » 2018-7-02 @ 01:06

For what it's worth, these guys seem to be collecting OpenGlide patches above and beyond what's contained in OpenGlide CVS (I may be mistaken): https://github.com/voyageur/openglide/commits/master

(This might be moot provided I prodded Glidos hard enough :D )
"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto
User avatar
Stiletto
l33t
 
Posts: 4084
Joined: 2002-7-01 @ 21:57

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-06 @ 10:53

Updated patch for QEMU 3Dfx Glide pass-through in 1st post.

For 32-bit build, it is now possible to check out other closed source Glide wrappers (especially those that only support full screen rendering) by having Glide wrapper rendering into its own window. To enable this, create a CFG file from the startup location of QEMU.
Code: Select all
 $ echo "CreateWindow,1" > glide.cfg


So far, here's my own results on Windows 10 x64 with 32-bit QEMU:
- Zeckensack 0.84c - worked fine in full screen, no windowed mode. It stole input focus from QEMU, but can Alt-Tab for QEMU to regain inputs.
- nGlide 2.00 - worked fine in full screen on initial launch, crashed on shutting down Glide. It stole input focus from QEMU, but can Alt-Tab for QEMU to regain inputs.
- dgVoodoo1 - worked fine in its own window. Full screen stole input focus from QEMU and Alt-Tab returned to window mode. So full screen cannot be used due to lack of inputs.

Both full screen and own window rendering have issue with mouse clicks. This is a major problem in full screen mode because the clicks have no other place to go. For own window rendering, as long as the clicks stay within QEMU window, then it is fine, otherwise Glide render window will crash.

I am still looking for solution to these issues. Personally, I highly prefer Glide render into the same QEMU window. Mouse clicks on games just work, better shooting in games where mouse usage matters. And I always prefer to have my games in windowed mode, even though it is just 640x480.
kjliew
Member
 
Posts: 202
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-07 @ 22:10

Updated 1st post with new patch that support Linux on both SDL1/SDL2.
As native 64-bit binary, QEMU TCG is significantly faster than DOSBox dynrec CPU core.
kjliew
Member
 
Posts: 202
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby Stiletto » 2018-7-08 @ 23:47

Weird wrapper tricks suggestion - QEMU 3Dfx Glide pass-through compiled for Windows 2000, running on Win2K Host OS, with Rendition Verite V2200 and BigRRed. :D :D :D

Wish I had a decent desktop, I'd love to try my weirder wrapper suggestions (SvensWrapper+GlideXP, Glitch64+GlideXP, eVoodoo2+3, uGlide) and do some compatibility testing just to see how broken they are. I miss my old days of wrapper compatibility testing :)
"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto
User avatar
Stiletto
l33t
 
Posts: 4084
Joined: 2002-7-01 @ 21:57

Re: QEMU 3Dfx Glide Pass-Through

Postby t9999clint » 2018-7-10 @ 22:04

kjliew wrote:Updated 1st post with new patch that support Linux on both SDL1/SDL2.
As native 64-bit binary, QEMU TCG is significantly faster than DOSBox dynrec CPU core.

Now that sounds like something for me to try this weekend... :happy:
User avatar
t9999clint
Newbie
 
Posts: 47
Joined: 2014-10-07 @ 14:08
Location: Edmonton, Canada

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-15 @ 08:14

Patch updated for more robust Linux support and better handling of QEMU window sizing when _grSstWinOpen and _grSstWinClose are called repeatedly without calling _grSstGlideShutdown (as in 3Dfx Glide TEST27 and TEST30).
kjliew
Member
 
Posts: 202
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-16 @ 05:48

One major advantage of QEMU is the networking support. Thanks to its enterprise grade virtualization, the networking support has to be solid. Quake2 multiplayer just work out-of-box within QEMU. If connecting to external server, even the simplest SLIRP user networking backend works. I also tried out older games, Mechwarrior 2 3Dfx NetMech works with winsock TCP for local LAN play, but this requires more complicated networking setup for QEMU to use tuntap networking. Wow! :happy: However, I couldn't get IPX/SPX to work. The protocol was installed correctly and the games could see it, but the VM could not see each other. I have yet to try hard enough, such as disabling firewall and messing around with router's configuration.

Head-to-head null-modem setup is a swift configuration for QEMU. The serial ports of 2 VMs can be virtually connected through TCP for local LAN play, as simple as that. That was how I tried out MercNet 3Dfx from the Titanium series. Too bad, MercNet does not support winsock TCP, its Internet play over TCP/IP requires connection to Battle.net. So that leaves null-modem as the only multiplayer option for head-to-head play.
kjliew
Member
 
Posts: 202
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby wadrasil » 2018-7-18 @ 01:36

Hello,

I wanted to thank you very much for this work! Thanks! I have not tried using it but i am very excited to try this out.

I wanted to ask a few questions about using this, I apologies if these are simple or rude questions.
Do you plan to or have your patches been submitted to qemu.org?
You stated this works works via a proprietary nvidia driver, has this been tested with the nouveau driver or any radeon drivers?
You mentioned this works via TCG not KVM correct? What guest OS's does this work on or has been tested on?
What command line options are needed for qemu for this to work on the guest?

I have compiled Qemu on arm hosts before and have used qemu-system-x64 to run Windows guests and some games like Starcraft and Diablo and they work fine, wondering if this might work for arm since they have boards with pcie slots now and have open source drivers for nvidia and radeon. Thanks again for this awesome patch!
wadrasil
Newbie
 
Posts: 2
Joined: 2014-8-07 @ 11:18

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-18 @ 19:33

wadrasil wrote:Do you plan to or have your patches been submitted to qemu.org?

Judging from the enterprise nature of QEMU, I am not sure if this patch will be relevant to their mission, and I don't have the time to commit to long-term support for this feature to keep it alive. For now, it would stay as a patch from vogons.org. I have no objection if anyone would try to upstream it.
wadrasil wrote:You stated this works works via a proprietary nvidia driver, has this been tested with the nouveau driver or any radeon drivers?
You mentioned this works via TCG not KVM correct? What guest OS's does this work on or has been tested on?

The 3D acceleration part is offload to host Glide wrappers. For Linux, so far OpenGlide is the only one, and it is wrapping into OpenGL. As long as the drivers provide good OpenGL and OpenGlide is happy, it should work. I have tried the following guest OSes, Win98SE, Win2K SP4 and WinXP SP3. DOS support is coming, but DOSBox is always better on DOS due to its excellent audio hardware emulation.
wadrasil wrote:What command line options are needed for qemu for this to work on the guest?

No command line options are required. Once the patch is applied, the feature is always available. I tried keeping the patch at very minimum to avoid invasive changes to QEMU core and standard device model interfaces. The Glide pass-through itself is implemented as standard QEMU device model. Host Glide wrappers are loaded dynamically upon Glide activation, so as to keep the rest of QEMU functional when Glide wrappers are missing on host. On Windows host where there are more than 1 choice for Glide wrappers, one can switch to different Glide wrappers without restarting QEMU simply by replacing the DLLs.
wadrasil wrote:I have compiled Qemu on arm hosts before and have used qemu-system-x64 to run Windows guests and some games like Starcraft and Diablo and they work fine, wondering if this might work for arm since they have boards with pcie slots now and have open source drivers for nvidia and radeon.

At high-level, if you can get OpenGlide compiled and working on ARM host, then it is very likely that this will work. If OpenGlide can be ported to OpenGL ES, then it could have also worked on mobile graphics such as Adreno or Mali.
kjliew
Member
 
Posts: 202
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-21 @ 07:39

Patch updated, support Glide pass-through for DOS games. So far, here's the list of games I had tested:
- Blood (dgVoodoo2, psVoodoo)
- Tomb Raider I/Unfinished Business (OpenGlide, dgVoodoo2, psVoodoo)
- BC3000AD 2.09 freeware (dgVoodoo2)
- Carmagaddon 1 3Dfx (OpenGlide, dgVoodoo2, psVoodoo)
- Redguard 3Dfx demo (OpenGlide, dgVoodoo2, psVoodoo)
- Extreme Assault 3Dfx demo (dgVoodoo2)
- Archimedean Dynasty 3Dfx demo (dgVoodoo2)

Battle Cruisers 3000 A.D. must be run from Win98 DOS prompt. It is a DOS/4GW app, but I found that it only worked from Win98 DOS prompt and not pure DOS. I couldn't get it to work in Win98 from DOSBox or pure DOSBox, so this is something to cheer about as we can now play this game with 3D acceleration on Windows 10. I think this game was developed with Windows in mind and though it is a protected-mode DOS program, it may have used DPMI service calls specific to Win98 DOS environment. or its non-DPMI code paths were buggy and never tested. I couldn't believe it that a DOS/4GW app didn't find real-DOS the best way to run that it didn't have the deal with the crappy VCPI/DPMI service calls.

Update: More DOS games checked out.
Last edited by kjliew on 2018-7-26 @ 00:40, edited 2 times in total.
kjliew
Member
 
Posts: 202
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby TomB » 2018-7-24 @ 15:42

Did you remove the patch? I'd really like to try this.
TomB
Newbie
 
Posts: 23
Joined: 2005-7-02 @ 19:14

Re: QEMU 3Dfx Glide Pass-Through

Postby wadrasil » 2018-7-24 @ 17:38

I am hoping the latest patch is still available, I was hoping to try this out soon as well. Especially after the last announcement.
wadrasil
Newbie
 
Posts: 2
Joined: 2014-8-07 @ 11:18

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-24 @ 19:22

I am updating the patch. Will re-post shortly.
Updated patch available. I also added pre-built binaries for wrappers on guest OS - 98ME & DOS - especially for folks checking this out on Linux, so that you don't need to setup VM or cross-compiled to DOS/Win32.
The Win32 wrapper DLLs are built with MinGW/GCC. They can be built to target VXD for 98ME or KMD for 2KXP. The FXMEMMAP.VXD and FXPTL.SYS are standard drivers from 3Dfx driver package.
The DOS wrapper OVL requires Watcom to build.

You *CANNOT* use 98ME wrapper DLLs on WinNT/2k/XP guest OS because of the difference in kernel driver architecture (VXD vs KMD).

I expect most people will check out Win98 as guest OS 1st, since this is the most compatible OS for old games, or just plain DOS. However, if the games are new enough to run on Win2k, then they will typically run faster on Win2k, such as Quake2 and Half-Life.
kjliew
Member
 
Posts: 202
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby TomB » 2018-7-25 @ 10:28

Thanks for the patch. I'm trying to build this on Arch Linux and I get the following errors:

Code: Select all
usr/lib/libc.so.6: warning: defined here
  GEN     aarch64-softmmu/config-target.h
  CC      aarch64-softmmu/hw/3dfx/glidept_mm.o
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c: In function ‘guest_memory_read’:
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:126:5: error: unknown type name ‘X86CPU’; did you mean ‘ARMCPU’?
     X86CPU *cpu = X86_CPU(cs);
     ^~~~~~
     ARMCPU
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:126:19: warning: implicit declaration of function ‘X86_CPU’; did you mean ‘BP_CPU’? [-Wimplicit-function-declaration]
     X86CPU *cpu = X86_CPU(cs);
                   ^~~~~~~
                   BP_CPU
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:126:19: warning: nested extern declaration of ‘X86_CPU’ [-Wnested-externs]
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:126:19: warning: initialization of ‘int *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:127:5: error: unknown type name ‘CPUX86State’; did you mean ‘CPUARMState’?
     CPUX86State *env = &cpu->env;
     ^~~~~~~~~~~
     CPUARMState
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:127:28: error: request for member ‘env’ in something not a structure or union
     CPUX86State *env = &cpu->env;
                            ^~
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:130:86: error: request for member ‘eip’ in something not a structure or union
  DPRINTF("Guest vaddr 0x%08x Pagefault read addr 0x%08x len 0x%08x\n", (uint32_t)(env->eip), (uint32_t)vaddr, (uint32_t)len);
                                                                                      ^~
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:39:47: note: in definition of macro ‘DPRINTF’
     do { fprintf(stderr, "glidept: " fmt , ## __VA_ARGS__); } while(0)
                                               ^~~~~~~~~~~
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c: In function ‘guest_memory_write’:
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:137:5: error: unknown type name ‘X86CPU’; did you mean ‘ARMCPU’?
     X86CPU *cpu = X86_CPU(cs);
     ^~~~~~
     ARMCPU
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:137:19: warning: initialization of ‘int *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
     X86CPU *cpu = X86_CPU(cs);
                   ^~~~~~~
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:138:5: error: unknown type name ‘CPUX86State’; did you mean ‘CPUARMState’?
     CPUX86State *env = &cpu->env;
     ^~~~~~~~~~~
     CPUARMState
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:138:28: error: request for member ‘env’ in something not a structure or union
     CPUX86State *env = &cpu->env;
                            ^~
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:141:87: error: request for member ‘eip’ in something not a structure or union
  DPRINTF("Guest vaddr 0x%08x Pagefault write addr 0x%08x len 0x%08x\n", (uint32_t)(env->eip), (uint32_t)vaddr, (uint32_t)len);
                                                                                       ^~
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:39:47: note: in definition of macro ‘DPRINTF’
     do { fprintf(stderr, "glidept: " fmt , ## __VA_ARGS__); } while(0)
                                               ^~~~~~~~~~~
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c: In function ‘processArgs’:
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:312:4: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
    write(fd, s->fbuf, s->flen);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~
make[1]: *** [/home/tom/tmp/qemu-2.12.0/rules.mak:66: hw/3dfx/glidept_mm.o] Error 1
make: *** [Makefile:478: subdir-aarch64-softmmu] Error 2


The errors suggest using ARMCPU instead of X86 is it somehow detecting my cpu architecture wrong? I have an AMD Threadripper 1950x.

I extracted the 3dfx directory from the patch file into the qemu/hw/ directory then ran

Code: Select all
patch -p1 < ./hw/3dfx/3dfx.patch
./configure
make


Am I doing something wrong in the build process?
TomB
Newbie
 
Posts: 23
Joined: 2005-7-02 @ 19:14

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-25 @ 17:28

The Glide pass-through device model only works for target i386-softmmu and x86_64-softmmu. Use "configure --target-list=i386-softmmu" to remove the non-x86 targets from build, and this will also speed up QEMU build time.

I would also recommend that the build should be on a separate folder from the source.
Code: Select all
$ tar xf qemu-2.12.0.tar.xz
$ mkdir build
$ cd build
$ ../qemu-2.12.0/configure --target-list=i386-softmmu
$ make
kjliew
Member
 
Posts: 202
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby TomB » 2018-7-28 @ 12:04

Thanks, that compiled fine and I installed windows98 with your wrapper DLLs. Unfortunately I get a segfault when glide initialises, I'm guessing I need to configure qemu with specific hardware or install some drivers?

I'm using

Code: Select all
qemu-system-i386 -m 1024 -soundhw sb16 --boot order=d -drive file=win9x,format=qcow -vga std


Do I need a different VGA setting for the 3dfx passthrough to work?

(I know that openglide is running correctly because native dosbox works)

edit: I do get this output in the console:

Code: Select all
glidept: DLL loaded - glide2x.dll
glidept: grSstWinOpen called
113434 Segmentation fault 


edit 2: I'm a complete amateur looking through the code but in glidewnd.c, if CONFIG_WIN32 isn't set, init_window doesn't create the window and hwnd is always zero. Should there be a linux version of the call to glide_prepare_window here?
TomB
Newbie
 
Posts: 23
Joined: 2005-7-02 @ 19:14

Next

Return to Release Announcements

Who is online

Users browsing this forum: No registered users and 1 guest