Hi guys, great to see some action in this thread 😀

Personally, I'm not super interested in seeing benchmarks against PCem, because I know what to expect from both. But here's the thing: Not everyone does.
Maybe getting the word out there would also help getting some eyeballs on qemu in general.
OTOH I don't know if this confrontational approach is a very good way to reach that goal. On this thread, you're preaching to the choir for the most part, and on the other threads it's easy to irk ppl off by rubbing qemu to their face...
Getting some user-friendliness in first also would not be a bad thing. Stating the obvious here but right now, the barrier of entry to qemu-3dfx is pretty damn high.
(This situation isn't wholly unique to qemu-3dfx. Those qemu vfio setups need a similar kind of dedication to get up and running. They're actually even worse, because you need specific hw.)

There's another thing that springs to mind: Maybe it would be time to do some restructuring?
This thread has been going for quite a while and it's getting pretty hard to read for any newcomers (I should know, I've read it 😀

Let's see, in recent times there's at least:
- Configuring Win98 guest for qemu-3dfx use
- Win9x 2d driver for virtual machine guest use
- QEMU(-3dfx) and PCem performance considerations, with benchmarks

Before that, there were long stretches dedicated to simply getting the thing compile.

It is OpenGL for UT2003. Where have you been in the last 2 years?

I never saw this thread, i could overlook it, but maybe it was even mentioned in this thread, it would be nice link al related threads and post in 1st post, they really are in couple of other topic.. That is part which i really dont understand, you are doing promotion this way, but in otherhand you dont want to promote it by releasing complete builds, to make it much easier to use.. to get much more users / fame / attention.

I don't have a great desktop CPU to show off the better part of PCem. I halted desktop upgrade indefinitely. My best CPU is on thin & light laptop, the Ryzen 2500U, but PCem is hopeless on any mobile CPU

Im not using laptops, simply because of headaches from their noise, unless they are fanless as your 15W Ryzen could be.. but after that they were usually quite slow, especially at GPU side.. and when i really work, i need lots of windows and monitors real estate, so when i using laptops, i have it on stand and 2 external monitors beside, external mouse and keyboard, so its desktop like regardless, only noisier and transportable. During travelling, when i get free plug in train or on business trip in hotel (but again typically connected to TV screen because simply bending in front of a laptop without some stand is far from ergonomic), it make sense, but other in all other circumstances, handheld style gaming device is better and at hotel could be often connected to TV too.
I dont thing that Ryzen 2500U is something too much slow, if Geekbench score is not lying, its ~ half of not so old Core i7 7700K performance, at least for the while in turbo, before throttling etc.

I dont thing that people are shy to post PCem numbers, i thing that they dont need to, because you can simply google, results of real HW which is emulated, on old site. If is not emulated at full speed, it make no sense to emulated such HW and you need to emulate something slower, which you can run at full speed. Its like resolution and details in games.
Regardless, i would like to see comparison of these on same HW.. i dont mind if PCem framerate would be 5 FPS, unplayable etc, this is reality. I even would make such benchmark, if would have working build of both.. I added some virtualization results to my Dos Fast CPU + GPU benchmarking thread (sheet), there is even some Qemu, but because of Qemu bug, i never was able to run 640x480 or higher resolution: https://docs.google.com/spreadsheets/d/1QPf4V … t#gid=919349920
Im not telling that PCem has not bugs, for example its loading Q2Dos for minute or two, there has to be something wrong with disk subsystem, i did some benchmarking and i got realy strange results, maybe it is fixed in new version, maybe not.. I have to check their forum.

Perhaps I was so wrong and those games are indeed playable with Core i9 9900K, all one needs is 30fps, anything more is superficial.

30 FPS means playable, what is big thing, yeah its console quality, its Doom quality (35FPS lock).. i dont mind more, that is why i have nice 144 Hz monitor, but i also like sit and play and not sit and trying to make game whole setup running for very long time.

I think we are there now, it is no longer just a dream with QEMU, and only with QEMU for now

Maybe, or probably, but how many people can enjoy it? People have problems to build it, its not unstreamed in QEMU, there is lots of quite stranger and more alien thing, unstreamed for while. When late its not easy to setup it right for Glide.. and if im not wrong anything with OpenGL is not public.. So you are there, we are not, few of us is there maybe with Glide. BTW made someone here some compatibility matrix, what is working and what is not?

I dont thing that you need to make lots ofvideos yourself, you only need to make package easily to use to users, i sure that somebody will make some video and compatibility list.

I dont thing that idea of virtualization of Win98 machine, is not welcome - its not Amiga overpriced HW old problem or some you have to use real HW etc.. Such people would ignore these thread, whole virtualization stuff, Dosbox etc.
I would say that is communication problem, simple to use things are usually successful and vice versa.. and they could be very complex inside, which should remain for most of users blackbox.
Geforce 6 line still has official Windows 98 support, with physical Win98 you get up to X79 board with still good enough for new games 6 six core + HT Core i7 for gaming and native PCI sound card, which is working in Dual boot in Dos / Win98.. if dont need Dos Sound you can get even higher, i dunno where is the limit, even Z170,Z370 is able to run Win98 fine... I have whole thread about it:
X58/i865/V880 - Yamaha7x4/AureaV1/2 pure Dos7.1- compatibility list/research/ ultim. drivers configs, WIP- gurus needed

and there are clever people which would be probably able to make some bridge to make Dos sound working with every MB with PCI slot..
PCie-to PCI, PCI to ISA, # of slots multipliers - bridges, risers, backplanes, research, especially for DOS, WIP.

As your pushing on SW side, they are pushing on HW side. SW site has to ultimately Win, but we are not there yet, because of bugs and missing features.. Virtualbox and Vmware, had not 3D support in Dos / Win9x and good Dos sound.. and already wrote lots about Qemu and linked and reported couple of annoying Dos bugs and 3D is very hard to get working and PCem is slow - but still the best.

kjliew wrote on 2021-01-09, 21:29:

To successfully accelerate Win98/ME guest with KVM/WHPX, there are several tricky parts. 1. You can't use cirrus-vga or just pla […]
Show full quote

mr.cat wrote on 2021-01-09, 20:06:

The better drivers (bearwindows or vmware ones from 8.3.19 tools iso) don't seem to work, as you said.
Also, with -enable-kvm I consistently got a black screen, so had to ditch that too. But this might be dependant on host hw.

To successfully accelerate Win98/ME guest with KVM/WHPX, there are several tricky parts.
1. You can't use cirrus-vga or just plain VGA (planar I/O access) with KVM/WHPX. You have to use VBEMP 9x or VMware SVGA and I recommend the former. The main blocker to get around for starting from scratch is to stay with TCG (slow) until the proper display driver is installed to obtain 256-color or 16-bit color desktop. Once you got there, you are in LFB mode. Then on next boot, you can enable KVM after step #2 (IMPORTANT)
2. Disable Win98 startup logo. Edit MSDOS.SYS and place "Logo=0" in the [Options].

Step #1 is very painful, so once it is done, any sane mind would not want to repeat that. So please back it up with an imaging tool. I use fsarchiver with Linux-based rescue LiveCD. QEMU KVM can boot up the LiveCD and re-image Win98 in 5 mins (compared to 35mins up to an hour for setup #1) on a reasonably fast SSD storage.

In any circumstances that you were forced into Win98 Safe Mode, KVM/WHPX would just crash. So just keep in mind to stay with TCG if Safe Mode was really needed. Otherwise, it is significantly faster to restore the installation from image.

Hey, did I understood this right? My QEMU finally works with this 3dfx emulation without these steps, so they are necessary? And second question: How did you set up QEMU to works with XvT?

OSH wrote on 2021-01-20, 23:36:

kjliew wrote on 2021-01-09, 21:29:

To successfully accelerate Win98/ME guest with KVM/WHPX, there are several tricky parts. 1. You can't use cirrus-vga or just pla […]
Show full quote

mr.cat wrote on 2021-01-09, 20:06:

The better drivers (bearwindows or vmware ones from 8.3.19 tools iso) don't seem to work, as you said.
Also, with -enable-kvm I consistently got a black screen, so had to ditch that too. But this might be dependant on host hw.

To successfully accelerate Win98/ME guest with KVM/WHPX, there are several tricky parts.
1. You can't use cirrus-vga or just plain VGA (planar I/O access) with KVM/WHPX. You have to use VBEMP 9x or VMware SVGA and I recommend the former. The main blocker to get around for starting from scratch is to stay with TCG (slow) until the proper display driver is installed to obtain 256-color or 16-bit color desktop. Once you got there, you are in LFB mode. Then on next boot, you can enable KVM after step #2 (IMPORTANT)
2. Disable Win98 startup logo. Edit MSDOS.SYS and place "Logo=0" in the [Options].

Step #1 is very painful, so once it is done, any sane mind would not want to repeat that. So please back it up with an imaging tool. I use fsarchiver with Linux-based rescue LiveCD. QEMU KVM can boot up the LiveCD and re-image Win98 in 5 mins (compared to 35mins up to an hour for setup #1) on a reasonably fast SSD storage.

In any circumstances that you were forced into Win98 Safe Mode, KVM/WHPX would just crash. So just keep in mind to stay with TCG if Safe Mode was really needed. Otherwise, it is significantly faster to restore the installation from image.

Hey, did I understood this right? My QEMU finally works with this 3dfx emulation without these steps, so they are necessary? And second question: How did you set up QEMU to works with XvT?

Hi OSH! Yes it's a good idea to have ACPI and VBEBM in the guest.
A nice thing about these virtual machines is that you can test all kinds of setups and get back to where you started easily, if needed.
(That is a sweet sweet luxury we didn't have in the 90's!)

Are you using -enable-kvm to launch qemu-3dfx?
My understanding is that the cirrus drivers know nothing of these hw virtualization features, and so they won't really work with KVM or WHPX. kjliew explains it here.
The keywords there being, *host accelerated*.

Geforce 6 lines do not have Win9x driver support. I go by official source. Otherwise, I would have kept my Nforce 630i/GeForce 7150 IGP motherboard for old Windows games with Core 2. If you want to hack the drivers, then it is your choice. I stand corrected.
Edit: Actually Geforce 6 lines do have official driver. I kept forgetting that IGP for Intel CPUs is GeForce 7 series

By the way, I do hope someone can leak the unofficial drivers of i910/i915 IGP that fully work on Win98. I knew they exist. 😜

Yes, I agree. If one cannot get QEMU to work, then PCem is still the best you can have for now.

Frankly, getting things to work with awkward ways is just not my cup of tea, such as booting WinXP on Ryzens, stubbing DOSBox with HXDOS extender to get sound for DOS games under real DOS, putting an ISA sound card over PCI over PCI-e bridge etc. just to name a few. There are folks who will follow 30 steps guide in PC game wiki to get the games work on Windows 10, but not me, that's just me. I have no means to offend anyone, I am sorry if I did it unintentionally.

I wonder a bit that any of folowers in this thread who make QEMU compiled and working too (is here someone else than kjliew himself? I'm lost in thread, it's quite long and I didn't remember what was on begining 2 years ago) didn't write some article on homepage or blog with some step by step how to compile and put all things together + upload own compiled binaries for those who doesn't have enough time to waste on it (what was once done before) and link it in 1st page here... 😀

BTW someone else may like to try awkward ways to run old systems native on new HW, not everything can be virtualized at full speed/functionality, there are some HW limits like huge overhead on VMEXIT calls...

RayeR wrote on 2021-01-21, 04:30:

I wonder a bit that any of folowers in this thread who make QEMU compiled and working too (is here someone else than kjliew himself?

🙋
Yep. Surely I'm not the only one? Here's the recipe I used for compilation back in December:
Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

For guest configuration the necessary steps can be found in the later posts this thread (mostly applies to Win9x though - Win2k/XP wasn't discussed much)
That was the hard part, at least for me...I only suffered WinME briefly when it came out. I was already going into Linux direction at that point, and never installed Win9x/ME.
Note that my testing hasn't been very extensive. Also there haven't been much talk about WineD3D tricks that may be necessary for Direct3D apps.

RayeR wrote on 2021-01-21, 04:30:

BTW someone else may like to try awkward ways to run old systems native on new HW, not everything can be virtualized at full speed/functionality, there are some HW limits like huge overhead on VMEXIT calls...

Its good to have different approaches. The end user can then decide for themselves what's best for them.
And virtualization is a somewhat moving target too. There are some future hw trends emerging like FPGA's, a possible move to different architectures etc.
But this API wrapping bypasses much of what happens at the hardware level, so it's quite a nice way to future-proofing.

mr.cat wrote on 2021-01-21, 05:12:

🙋
Yep. Surely I'm not the only one? Here's the recipe I used for compilation back in December:
Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

🤫 (whispering ... ) you might be rubbing qemu to someone's face ... 🤣 🤣

Thanks to the disease spread by Facebook, Instagram etc. these days. 🤣

kjliew wrote on 2021-01-21, 06:01:

mr.cat wrote on 2021-01-21, 05:12:

🙋
Yep. Surely I'm not the only one? Here's the recipe I used for compilation back in December:
Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

🤫 (whispering ... ) you might be rubbing qemu to someone's face ... 🤣 🤣

Thanks to the disease spread by Facebook, Instagram etc. these days. 🤣

Whoops! Gotta be mindful of that before we get queries for "if you got qemu rubbed to your face, report back here" 🤣
Anyways, my 0.02 eurocents to this is that "if you build it they come" doesn't really work, until it's easy enough for an average Joe.
Then you'll start to see the attention this project deserves...

kjliew wrote on 2021-01-21, 01:57:

Frankly, getting things to work with awkward ways is just not my cup of tea..

It really depends if there is other way, often isnt but in my case it is. Just distribute complete Qemu build at least for Windows with some basic disk image and qemu starting line, as RobertMo once did, its not too much work, main problem is building.

I wonder a bit that any of folowers in this thread who make QEMU compiled and working too?

I once build it right, but it was 4.xx, with 5 or 4.1, 4.2 not sure, i wasnt so lucky, especially with manualy editing files to make sound patch working. There are also some builds too download from RobertMo, but even with minimal Dos disk image, but there was some Dos related problem, not working EMS, Himem or something like that in Dos, for Windows 98 it was working, but not without acceleration, when i tried to make MS VM acceleration working i always failed, crash after user login.

BTW even Qemu pass through is not ideal for Dos, i already linked errors with virtual machine errors, but also real PCI sound card passthrough is not working with DOS.

mr.cat wrote on 2021-01-21, 05:12:

🙋 Yep. Surely I'm not the only one? Here's the recipe I used for compilation back in December:
Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

Thanks, yeah I was intentionally a bit over... this, I know at least ruthan and you was playing with it with some success too.
You already mentioned that it become hard to get in for newcomers. So any reason why to not upload a binary and some better documentation than scattered thread (yeah 27 pages is still nothing compared to some cool threads on Win-raid and MSFN wit 400+ pages)? I understands why bins are not much distributed for Linux as there are many differences across the distros, kernels etc. but why not for Windows? The disk image wouldn't be problem, just would nice to have compiled guest files.
I'm personally not enough motivated to go in compiling (rather just curious about reached performance and rsults and have a lot of work on own projects) as I'm primary aimed on DOS sound emulation and some older Win D3D/GL games still can run native...

mr.cat wrote on 2021-01-21, 05:12:

And virtualization is a somewhat moving target too. There are some future hw trends emerging like FPGA's, a possible move to different architectures etc.

Don't expect miracles from FPGAs, they had several speed limitations compared to "hardwired"silicon and top models are quite expansive. Currently it's good way to emulate various 8bits, Amiga, Consoles but not a Pentium II PC with 3Dfx...
Doing API passthrough is of course best thing to do, for systems using APIs but DOS stuff handle HW directly and then it's much slower for virtualization. Except as ruthan mentioned passing the whole HW on PCI bus but not all systems supports VT-d I/O.

BTW I recently tried DosBox-X with stubbed minilinux booted from dos within 1s and got quite decent performance 42FPS in Q1 1024x768 (and with sound support).

Updated 1st post.

OpenGlide fork optimized for QEMU is now available. This is mostly meant for Linux folks, especially ARM SBC/RPi4 community where 1st-party Glide pass-through can be faster than 3rd-party Glide from Windows guest on top of MESAGL pass-through. For Linux x86/x64 with KVM, no big deal on either ways of pass-through from my testing, so just pick whichever is the most compatible for target games. OpenGlide can be used in either Host or Guest depending on compilation. Native compilation is used for Host and cross-compilation (or native compilation in VM) is used for Guest.

If one is building this for ARM, then it is recommended to use recent GCC compiler with SIMD auto-vectorizing optimization. The x86-64 enjoys at least SSE2 by default and pixel operations are automatically vectorized with SIMD instructions with "-O2" or higher.

RayeR wrote on 2021-01-22, 05:22:

mr.cat wrote on 2021-01-21, 05:12:

And virtualization is a somewhat moving target too. There are some future hw trends emerging like FPGA's, a possible move to different architectures etc.

Don't expect miracles from FPGAs, they had several speed limitations compared to "hardwired"silicon and top models are quite expansive. Currently it's good way to emulate various 8bits, Amiga, Consoles but not a Pentium II PC with 3Dfx...

Actually I was thinking about Intel purchasing Altera and more recently, AMD buying Xilinx. It's one way of lowering the power consumption in the Cloud I suppose, but it's possible that FPGAs will have a bigger role in the future.
The point was that we don't know what the future hw will look like. It looks there is already some arm work underway..

As for docs & binaries, my guess is that there is a lack of time and/or interest. This is an enthusiast project and not on the list to gain any Red Hat funding, after all.
If you've done any coding you know how time consuming that is..and for most folks documentation is just boring as hell, so it's done last.

If someone will succeed to build Qemu 5.2 3Dfx for windows with help of new instructions, pleas share it.. ideally with all resource Qemu file needed to run it, because if remember correctly its other step which is needed, andwhich is not described and its not as simple as it could seem.

Ok, ok.. i did that mistake again, that i tried it by myself..
I still dont thing that is right way to make user compile it, but there some notes:
- without some msys2 setup tutorial are these notes (with all needed packages), i dont want to say useless, but lest say far from complete..
- it would be nice somehow enhance mkdir command, to overwrite directories, if already exist to not force user to have to delete them // small thing but, if you are trying to create some tutorials and installation package for more 10+ users, from experience every details count and in each step every user can halt
- during files extraction there is lots of errors because of Linux symlinks, but would be good to note to Windows users, that these errors are fine..
- i would be nice to point how to select proper target, because i did it long time ago, so i got all of them..
- i had some setup from the past and executed last step:
../qemu-5.2.0/configure && make
i got: ERROR: Cannot find Ninja
because im not more newbie with it, i know that i need download some package and it has some build in linux package system, so i googled:
pacman -S mingw-w64-x86_64-ninja
- i ran it again, it compiled for while, but ended with:
Found ninja-1.10.0 at C:/Progamy/msys64/mingw64/bin/ninja.exe
WARNING: Could not create compilation database.
/mingw64/bin/ninja build.ninja && touch build.ninja.stamp
ninja: error: build.ninja:25741: multiple rules generate ../qemu-5.2.0/default-configs/devices/aarch64-softmmu.mak [-w dupbuild=err]

make[1]: *** No rule to make target 'multiboot.bin', needed by 'all'. Stop.
make: *** [Makefile:206: pc-bios/optionrom/all] Error 2

- Im also not know, if this build would be good enough for WHPUX, any other Windows acceleration possiblity or not.

There are some details:

So tutorial is better, at least no more awkward sound patching but far from be good, it need more work..

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

Actually I was thinking about Intel purchasing Altera and more recently, AMD buying Xilinx. It's one way of lowering the power consumption in the Cloud I suppose, but it's possible that FPGAs will have a bigger role in the future. The point was that we don't know what the future hw will look like. It looks there is already some arm work underway..

Yes I know intel bougth Altera 5 years ago and I had also some expectations but I don't see any of such technology was used in standard x86 CPUs. And I think same will be for AMD.
FPGAs are here for decades so we can guess how it will develop further. I don't see any significant speed up, rather they will increase number of cells and can contain some specific HW core blocks...

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

As for docs & binaries, my guess is that there is a lack of time and/or interest. This is an enthusiast project and not on the list to gain any Red Hat funding, after all.
If you've done any coding you know how time consuming that is..and for most folks documentation is just boring as hell, so it's done last.

Sure, I did ( http://rayer.g6.cz/programm/programe.htm ). I know this take some time but sometimes when doing some complex process I found usefull to write a notes about all depencies, prerequsities, configuration etc. so when I return to project some years later I then quickly know how to setup and get in again. I think that the documentation of QEMU build is not needed to be made by author as he rather spends time with developing but maybe done by users who successfully replicated the process. And I really think that there are better ways to keep knowledges than expanding thread (not needed to be Github)...

RayeR wrote on 2021-01-22, 18:38:

Yes I know intel bougth Altera 5 years ago and I had also some expectations but I don't see any of such technology was used in standard x86 CPUs. And I think same will be for AMD.
FPGAs are here for decades so we can guess how it will develop further. I don't see any significant speed up, rather they will increase number of cells and can contain some specific HW core blocks...

FPGAs don't make much sense in their current form because of all kinds of restrictions (not the least of which is cost, as you mentioned - but even this can change).
But because of Moore's law (and the competition getting heated again) they will be forced to investigate all kinds of solutions. This may well be one area of interest.
Anyways, hw virtualization is the tech you need for speed, whatever it will be in the future. If you demand accuracy, CPU-based solutions are probably the way to go. The speed isn't a problem for a lot of older stuff.

RayeR wrote on 2021-01-22, 18:38:

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

As for docs & binaries, my guess is that there is a lack of time and/or interest. This is an enthusiast project and not on the list to gain any Red Hat funding, after all.
If you've done any coding you know how time consuming that is..and for most folks documentation is just boring as hell, so it's done last.

Sure, I did ( http://rayer.g6.cz/programm/programe.htm ). I know this take some time but sometimes when doing some complex process I found usefull to write a notes about all depencies, prerequsities, configuration etc. so when I return to project some years later I then quickly know how to setup and get in again. I think that the documentation of QEMU build is not needed to be made by author as he rather spends time with developing but maybe done by users who successfully replicated the process. And I really think that there are better ways to keep knowledges than expanding thread (not needed to be Github)...

Cool, thx for the link.
EDIT: Just took a peek at the site - so hello 90's, you're back, better than ever? 😁
Wow man, you've got a treasure trove over there. Got some serious flashbacks, no headache though 😁

What you described certainly sounds like an organized way to do your coding.
You're right of course there is this one thing, the churning out code, and there is all this "other stuff" around it that goes into making the thing actually accessible...

Hmmm, was that a subtle way of asking me to write some docs? 😁
Well, there's no harm in asking...My own goal regarding this project was simply to get a guest going in some form (I think I've reached that).
Currently I have no plans to advance the docs side beyond what we have in this thread, but at least others can now take a look and see what was needed.

@ruthan: Did you take a look at robertmo's Windows compilation guides if they help any? I think there are at least some switches that are needed for Windows.

@ruthan: Did you take a look at robertmo's Windows compilation guides if they help any? I think there are at least some switches that are needed for Windows.

Not really i have even my own guides, but dit not open them.. i guess that with right target it would work, but i gave it exactly 10 minutes no more, to check progress of guide..

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

... This is an enthusiast project and not on the list to gain any Red Hat funding, after all.

Perhaps Apple could send me an M1 MacBook 13" to further my work into MacOS and Metal as an inspiration. 😁 😁

I don't know how well Rosetta binary translation would work on old Windows games from the late 90's til 2001's era. If it works, then it is no doubt the best option. DOSBox dynamic_x64 is the fastest CPU recompiler I have seen. I have measured scenarios that it could be as good as WHPX on Windows. Unfortunately, it doesn't work for ARM/AArch64. DOSBox dynarec, which is portable across multiple architecture, is slow, but for most of the DOS games, good enough. PCem has recently added ARM64 backend but without Voodoo. I can't talk much about it, their "fanboy-ant" community cannot swallow the facts 😜 🤣 for an open & direct academical scrutiny

QEMU has a strong "pro" developer community that don't crave to play old Windows games, but they are fully behind ARM/AArch64 ecosystem. QEMU TCG is well tested and optimized. No one had ever created a 3.2GHz ARM CPU. Using my 10X rule for dynarec, it could reach the performance of 300MHz CPU with TCG. 1st-party API pass-through such as Glide and OpenGL would have made quite a number of games playable on Apple M1. 3rd-party API pass-through such as WineD3D in my estimation may not offer good performance to be playable. (Unless some efforts spent to make at least D3D9 1st-party pass-through with MESA Gallium9 ..... hint ... hint 😜)

Otherwise, I am looking forward to get my hands on Pinebook Pro or anything better for evaluation.

kjliew wrote on 2021-01-22, 22:53:

I don't know how well Rosetta binary translation would work on old Windows games from the late 90's til 2001's era. If it works, then it is no doubt the best option. DOSBox dynamic_x64 is the fastest CPU recompiler I have seen. I have measured scenarios that it could be as good as WHPX on Windows. Unfortunately, it doesn't work for ARM/AArch64. DOSBox dynarec, which is portable across multiple architecture, is slow, but for most of the DOS games, good enough. PCem has recently added ARM64 backend but without Voodoo. I can't talk much about it, their "fanboy-ant" community cannot swallow the facts 😜 🤣 for an open & direct academical scrutiny

AFAIK, if I understand correctly your comment, Rosetta 2 does not work this way. Rosetta 2 only "translates" 64 bit intel macOS apps/games for the M1, not Windows apps/games. Even WINE through Rosetta 2 wouldn't be practical for Windows games.

DOSBox had really good results both through Rosetta 2 and with a native version for M1. Yes, the dynamic core is fantastic but still needs more work, but works well actually until it has a segfault in Windows 98 after certain things are done on it (considering the DOSBox-X branch, actually it is their biggest hurdle to beat and be able to run Windows 98 and its game with a dynamic core).

PCem should fly and beat them all with an M1 build, but I didn't knew it did not have Voodoo yet. I tried all formulas to give my middle finger to VMware: QEMU, DOSBox, PCem. QEMU lets me play almost all the games, except one or two titles that require 3D acceleration. DOSBox has it but its slow. Same with PCem; They just don't do well on an Intel Mac, but are miles better on an M1 Mac.

And no, I am not a PCem fanboy. I am not a fanboy of any emulation in particular, I try them all when I want and choose the one that serves my desires at the moment I want to play something. For now, I still have an Intel Mac so I am stuck with VMware (has DX9 and 3D accel), while my iPad Pro runs UTM (QEMU GUI frontend app) well but without any 3D acceleration.

I understand the reasons why you dropped macOS support but Glide wasn't functional for mac anyway, I couldn't even find the libglide library for Glide support on macOS hosts running DOSBox-X.