If you mean PCem, yes, that's generally going to be faster than 86Box, for a few reasons:
- We ship (and compile with) the old recompiler by default, because the new recompiler has some as of yet unfixed regressions (the Mapedit 8.x performance drop);
- More accuracy in some parts, including but not limited to added segment limit and presence checks in a lot of places where PCem omitted them but are required by eg. graphics card drivers (SimCity 2000 on Windows 3.1x with Trio64 drivers is one thing that breaks in case of their absence, NT 3.1 on some S3 cards being another).

DosBox is a very different type of emulator from 86Box or PCem. It does high level emulation of DOS and the BIOS, and has sort of a loose handling of CPU speed, whereas PCem and 86Box utilize original BIOS images and operating systems and attempt to run the configured systems at something reasonably close to the original clock speed and timings. I think direct comparisons there are a bit hard to do, as they have different goals.

Vanilla DOSBox is more intended to run DOS games straight away with Windows 9x being totally unsupported. DOSBox-X, on the other hand, is a fork with the intention of being more accurate and has complex INI settings as a result but it still doesn't provide something closer to a proper PC experience compared to PCem or 86Box.

Thanks a lot , specially Battler for such detailed answer 😀 There is so many options nowadays that is great to have some clarity now.

So far I am very happy with PCEM (apologies for calling it PCEMu all the time 😀 ), but I was reading people being able to reliably emulate a P2 400 (My CPU is a 12700K) but I can't get 100% emulation speeds on for that no matter what I try. The most reliable emulation I got was 223MMX plus voodoo 3, with that I can Unreal gold full speed, and it is exactly the same experience I used to have in real hardware. If I jump to P2, even at 266 there is some degree of dips. Is this consistent with everyone experience? Wondering if I am doing something wrong in terms of configuration.

This is the hw specs of the machine on PCEM with the P2 config:

- Gigabyte GA-686BX
- CPU (between P2 233 and P2 350)
- Voodoo 3 , 2 render threads
- Soundblaster 16
- W98 SE

This is the hw specs of the machine on PCEM with the P1 config:

- ASUS P55TVP4
- P223 MMX
- Voodoo 3 - 2 Render threads
- Soundblaster 128
- W98 SE

Thanks a lot in advance!

I can do a P2 300 in PCem in pretty much all* cases with my ryzen 5700x; can go even higher with some games (Tip: you can change the CPU on the fly while the machine is running).
A 12700k has about 20-25% higher single-core performance, so it should have no issues. One or a combination of the following could be the reason:

1. The builds from github are much slower, IINM because of compiler changes. Use v17 (unless you know how to compile the current source with the same compiler settings as v17; I have no expert knowledge of compiling. If it's doable, I'd really like to have your personal builds then 😁).
2. The windows power plan is causing the clock speed to not ramp. Set it to at least "High performance".
3. PCem might be using the E-cores. Launch it with its core affinity set to only use the P-cores. Since you're using a voodoo3 with 2 threads, you need at least 4 cores in total; although I'd suggest to set the affinity to all 8 cores regardless.

*It must be noted that PCem's dynarec has compatibility bugs with certain games that causes the emulation speed to tank heavily. I haven't tested Unreal though.

For such cases, you can switch to 86box NDR (New Dynamic Recompiler) 32-bit. It's not as fast as PCem v17 (although is quite close), but faster than the regular 86box builds. If the compatibility issues persist, then I'd suggest regular (ODR) 86box 32-bit.

An alternative to switching to 86box, would be to disable the cache in the PCem emulated system's bios (which disables the dynarec), but that would render it slower even than ODR 86box.

eddman wrote on 2023-10-13, 09:05:

I can do a P2 300 in PCem in pretty much all* cases with my ryzen 5700x; can go even higher with some games (Tip: you can change […]
Show full quote

I can do a P2 300 in PCem in pretty much all* cases with my ryzen 5700x; can go even higher with some games (Tip: you can change the CPU on the fly while the machine is running).
A 12700k has about 20-25% higher single-core performance, so it should have no issues. One or a combination of the following could be the reason:

1. The builds from github are much slower, IINM because of compiler changes. Use v17 (unless you know how to compile the current source with the same compiler settings as v17; I have no expert knowledge of compiling. If it's doable, I'd really like to have your personal builds then 😁).
2. The windows power plan is causing the clock speed to not ramp. Set it to at least "High performance".
3. PCem might be using the E-cores. Launch it with its core affinity set to only use the P-cores. Since you're using a voodoo3 with 2 threads, you need at least 4 cores in total; although I'd suggest to set the affinity to all 8 cores regardless.

*It must be noted that PCem's dynarec has compatibility bugs with certain games that causes the emulation speed to tank heavily. I haven't tested Unreal though.

For such cases, you can switch to 86box NDR (New Dynamic Recompiler) 32-bit. It's not as fast as PCem v17 (although is quite close), but faster than the regular 86box builds. If the compatibility issues persist, then I'd suggest regular (ODR) 86box 32-bit.

An alternative to switching to 86box, would be to disable the cache in the PCem emulated system's bios (which disables the dynarec), but that would render it slower even than ODR 86box.

Apologies for the late reply. I really appreciate how comprehensive it is!

I followed your advice and pinned PCEM v17 to the p-cores and it surely performs much better! I can do Unreal gold 100% p2-450 now. The slowdown dips in w98 when opening a folder are normal? I think I read somewhere that it was the case.

solemgar wrote on 2023-10-21, 14:07:

The slowdown dips in w98 when opening a folder are normal? I think I read somewhere that it was the case.

I don't know if it's normal or something that can be fixed in the code, but it happens for everyone, so for now it's just how it behaves.

eddman wrote on 2023-10-21, 20:00:

solemgar wrote on 2023-10-21, 14:07:

The slowdown dips in w98 when opening a folder are normal? I think I read somewhere that it was the case.

I don't know if it's normal or something that can be fixed in the code, but it happens for everyone, so for now it's just how it behaves.

Thanks! then i think all is running properly now. It is still mind blowing for me that I can recreate the experience of running 3dfx games in win98 like I used to do as a kid!

Personally, I'm using PCem v17 right now on an Intel Xeon system running XP SP3.
I was going to give 86Box a try, too, but it refuses to run..

Edit: My bad, I've just realized that things seem to be solved already.
Ok, so I'll just provide some general tips for Windows 9x instead.
- There's KernelEx project to increase compatibility with newer applications

- Windows 9x sometimes does cause 100% CPU load. Tools like Rain or amnhltm may help here.
HALTing DOS and Windows 98?

- Using an AWE32/AWE64 may "accelerate" sound/directsound in Windows 9x. They also do MIDI via EMU 8000 Synthesizer .
For SB16, there's an ASP chip that can assist in decompression of WAVE files (requires older VXD driver). Maybe 86Box etc have that emulated by now.

I have been using 86box for DOS emulation, and I think for DOS is offers a number of really nice advantages over PCem.

1. Better integration with MUNT and fluidsynth IMO
2. Support for mpu-401 emulation with real mode
3. Support for overscan which is really nice for original IBM and early CGA and EGA PCs
4. Support for more types of upgrades and peripherals like different storage controllers, RAM upgrade cards, ect (no necessary but does make the experience richer IMO).

With 86box I find I can accurately emulate (for every piece of the hardware and configuration) lots of different computers and that's awesome.

In the most recent builds of 86box I have found Tandy sound emulation is mostly broken. I use PCem to emulate what is roughly a Tandy 1000hx for all of my tandy games. Neither emulator supports the later Tandy 2000/3000/4000 computers with more sophisticated tandy graphics/sound/286 processors ect. which is not strictly required but would be nice. Even at 16mhz, the 8088 is kind of sluggish for later games like Zak McKraken ect where a 286 at 12 mhz would be perfect.

I have also run into problems recently with late era DOS games that use FMV. In DOS 6.22 I can't get NFSSE, Star War Tie Fighter, and the CD release of magic carpet to install. I don't know exactly why that is.

Another problem with 86box and PCem both is the support for shaders is pretty awful/basically unusable. I play all my games with raw pixels, but if it was supported, I would use more advanced CRT shaders for emulating different kinds of dot pitch/shadows masks ect.

For people who just want to play games and don't care about the nerdy shit that doesn't really effect the experience, I think Dosbox pure is probably the best emulator for features IMO. The integration with MUNT/fluid synth is great, it emulates all the same sound cards/video cards (mostly) and the shader support in retroarch as good as it gets.

Dosbox-x is a great emulator but since it sits somewhere between PCem/86box and mainline dosbox I don't really use it.

Thread cleanup.
If you want to discuss that other project (not giving it advertising by naming it but it involves 3dfx and qemu) do it in another thread dedicated to that project or preferably in the github of the project.

Saying that I'd rather it not be brought up on vogons for numerous reasons, here are a few:
The banned user frequently links back to vogons to further his "truth" by taking posts out of context.
Supporters of said project or new users will inevitably flock here to fan the flames.
Users get the impression we support the project by allowing discussion here and by offering support we would.
Discussion on a project where the dev is banned isn't fair to the banned user especially when the subject inevitably involves discussion about said user.

I would rather keep the discussion on the topic at hand , it was not my intention to bring up any controversy (although being new , appreciate the history lesson).

I think I'll give another spin to 86box, although so far pcem produced the best results for me.

For shader support, do I understand RetroArch is the way to go? I am all for making dos games "prettier". I really struggle with RetroArch interface. It feels like when you already have set it up the way you like , any change makes it fall like a house of cards.

I have been using 86box for a few years since I got into M1 Macs, and their support on it has been stellar since day one, thanks to coldbrewed, battler and others.

About its performance, it performs as expected. I have four machines, spanning across the 90's, an early 90's dos/w311, mid 90's win 95, late 90's win 98 and win Mistake Edition. Only the last two have voodoo 2 emulation. These four machines have different configurations for each machine I owned in such periods.

When I got into M1, I was searching for a solution that could let me play favorite games like Grand Prix 3 and FIFA 99. 86box did the job. I can play both perfectly with Parallels and Win 11 arm64, no problem, but 86box lets me play with the Win 98 atmosphere and nostalgia. And is pretty straightforward to use, mount the machine, install the operating system and games, like it was in 90's. Best I can do (in a M1) is a Pentium II 266 MHz with 128mb ram and voodoo 2 12mb. And runs very well, very well.

PCem never really had an official mac port despite some great efforts from users like kyr0 to make it run, but my games were kinda bad. Can't talk about UniPCEM either since I never really used it.

As for DOSBox-X, I did have a fair share of years using it. I feel it was a lot slower than 86box and limited. It does not run optimally GP3 and FIFA 99 as 86box can do.

Been doing such researchs since 2019, trying, testing, taking notes, and all these years paid off when I came to a solution that works for all my childhood games. They're spread between the four 86box machines, for 80's and 90's games. The 2000's games were put in Parallels Win 11 vm since they're quite more demanding. The game count goes beyond 120 games and still adding more.

@solemgar: I think you should give 86box a good chance and contact the people at their discord for more tips to improve. PCem afaik isnt being actively developed nor being developed at the same rate 86box has been in the recent years. What is your host machine configuration? So we can find a sweet spot 86box machine for you.

- eddman: Actually, I wonder if the chain-4 changes to (S)VGA are the true reason for the current code of PCem being slower, in addition to the fact release builds are compiled with PGO (profile-guided optimization) likely tailored for common usage cases. One should actually compare PCem v17 vs. 86Box NDR vs. PCem v18, perhaps the latter two match. I've compiled PCem before (during the v17 and earlier era) with newer compilers and I haven't seen that much speed differences. But I'm beginning to wonder if perhaps the slowdowns are related to the chain-4 changes because we also ported those to 86Box so that would explain why both 86Box and PCem v18 current code are slower than PCem v17. Also because of how the chain-4 translation is done - basically a handful of functions with case blocks and calculations get called for every pixel of every (S)VGA line and I had previously experienced adding any extra calculation there at all reducing performance - 86Box used to have the inversion and conversion to grayscale there and the performance loss was noticable.

Battler wrote on 2023-11-06, 04:45:

- eddman: Actually, I wonder if the chain-4 changes to (S)VGA are the true reason for the current code of PCem being slower, in addition to the fact release builds are compiled with PGO (profile-guided optimization) likely tailored for common usage cases. One should actually compare PCem v17 vs. 86Box NDR vs. PCem v18, perhaps the latter two match. I've compiled PCem before (during the v17 and earlier era) with newer compilers and I haven't seen that much speed differences. But I'm beginning to wonder if perhaps the slowdowns are related to the chain-4 changes because we also ported those to 86Box so that would explain why both 86Box and PCem v18 current code are slower than PCem v17. Also because of how the chain-4 translation is done - basically a handful of functions with case blocks and calculations get called for every pixel of every (S)VGA line and I had previously experienced adding any extra calculation there at all reducing performance - 86Box used to have the inversion and conversion to grayscale there and the performance loss was noticable.

Thanks everyone and thanks Bruninho for your help and patience ! Don't get me wrong about 86box , I think it's an impressive software as well. It is just probably I am not doing somethingwell. I just run a new test using the latest 86box nightly (new recompiler) and here are the results compared with pcem17 straight from the website.

As you can see in the test, pcem17 runs 100% and 86box hovers around 70% with a voodoo 3 3000, same config (4 threads). PCem can drive a 450 mhz p2, and 86box is running a 350mhz p2

As with previous suggestions, core affinity is set to the first 8 pCores to avoid them landing on a eCore.

My host config is a i7-12700k, no overclocking, 4080 RTX. I run the VMs from a NVME drive. Is there any other specific config you would like me to share?

EDIT: I realized I was using 64bit version of 86box, so tried the 32bit version as well, but numbers are similar, maybe a bit better.

Battler wrote on 2023-11-06, 04:45:

- eddman: Actually, I wonder if the chain-4 changes to (S)VGA are the true reason for the current code of PCem being slower, in addition to the fact release builds are compiled with PGO (profile-guided optimization) likely tailored for common usage cases. One should actually compare PCem v17 vs. 86Box NDR vs. PCem v18, perhaps the latter two match. I've compiled PCem before (during the v17 and earlier era) with newer compilers and I haven't seen that much speed differences. But I'm beginning to wonder if perhaps the slowdowns are related to the chain-4 changes because we also ported those to 86Box so that would explain why both 86Box and PCem v18 current code are slower than PCem v17. Also because of how the chain-4 translation is done - basically a handful of functions with case blocks and calculations get called for every pixel of every (S)VGA line and I had previously experienced adding any extra calculation there at all reducing performance - 86Box used to have the inversion and conversion to grayscale there and the performance loss was noticable.

I don't know about the chain-4 changes to (S)VGA. My experience with post-v17 PCem has been through the builds from the Action tab of the github page. I don't have exact numbers but they were maybe 20-30% slower than v17, which might be slower than 86box too. Haven't done any recent tests.
I was basing it on other people's posts that it's compiler related, but maybe it's the code itself.

There is this though: https://github.com/sarah-walker-pcem/pcem/issues/197

Could it be related? Although I don't know if that's about the post-v17 regression, or the dynarec regression introduced in v15.

IIRC the 32 bit builds run better on Windows, yes. I just don't remember why.

I just needed to know which host cpu you had - since the entire emulation runs in a single core of that cpu. Refer to the geekbench's single core score of your CPU:

https://browser.geekbench.com/processors/inte … -core-i7-12700k

You're attempting a P2 450MHz with Voodoo 3000, You can maybe lower the P2 clock a bit to find out a sweet spot by trial and error (I mean, until you achieve a more constant 100% with proper speed for the games). If that is not enough, going from a Voodoo 3 to a Voodoo 2 12MB should be, and also this config should also perform better in PCem v17 for you. Unless you have a game that specifically requires a Voodoo 3 (I don't think any game does, as long as they are 3dfx compatible any voodoo will work).

The entire emulation is not single core. The guest CPU emulation is single core, but accelerated non-voodoo cards (Trio, Virge, etc.) have their own thread, and voodoo cards have at least 2 threads. A v2 in SLI can go up to 9 extra threads. The UI, CD audio, MIDI and each network card also have their own threads.

Right, but the entire emulation depends of his host cpu single core performance. Multi core performance helps nothing with emulation. It's pretty simple.

https://86box.readthedocs.io/en/latest/usage/ … tem-will-handle