I did mention that guest CPU emulation is single core dependent, however if you don't have enough cores or set the affinity too low (and enable, say, voodoo), the emulation speed would still drop because now multiple threads are processed by those few cores and they can't handle that. You need both high single-core performance and enough cores.

- solemgar: When comparing performance when emulating a 686 CPU, bear in mind that PCem's timings are less accurate and therefore, less calculation-intensive than ours. This may explain the discrepancy.

- eddman: That could be the dynarec regression after v15. The new dynarec handles very poorly situations where a lot of very small code-blocks are executed and often flushed en masse. It manifests itself in MAPEDIT 8.x for DOS (Wolf3D map editor), when playing MIDI's through Creative WaveSynth in Windows 9x, and it seems in that game as well. The old dynarec handles these situations much better.

@solemgar: according to this page https://www.cpubenchmark.net/singleThread.html

and a research conducted by one moderator from 86box discord server (Efflixi):

What is the best system my computer can run? --- This is hard to answer with 100% certainty because there's too many factors. Th […]
Show full quote

What is the best system my computer can run?
---
This is hard to answer with 100% certainty because there's too many factors. The best we can do is some rough comparisons. https://www.cpubenchmark.net/singleThread.html - Look at that list, while the numbers aren't directly comparable to 86box itself, the higher a cpu is on that list, the faster it will run 86box.

Here's some more comparisons:
~4000 = Pentium II 300
~3400 = Pentium II 233
~2600 = Pentium 200
~1600 = Pentium 75
~700 = 486DX2 66 (assuming the gpu on such a system can keep up)

You're kinda spot on when emulating a PII 350MHz in 86box (unlike PCem where u did a PII 450MHz), because your cpu single thread score is 4,052. Maybe you will be just fine with 300 instead of 350.

I still think a Voodoo 2 is enough rather than using a Voodoo 3 3000, which would improve emulation performance a lot, unless you have any reason to be attached to this card (i.e. "I had this card when I was a kid") which is reasonable; I mounted my 86box machines with the same principle. Again, it is up to you and how you conduct your tests. These are just my two cents based on the data I have here.

And I'll assume Battler is 100% correct in his explanation about the speed discrepancy between PCem and 86box there. I mean, it makes sense.

Bruninho wrote on 2023-11-06, 14:14:

IIRC the 32 bit builds run better on Windows, yes. I just don't remember why. […]
Show full quote

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).

Yeah, I think I can drive a 233 MHZ p2 but I was just curious about how much performance difference is between 86box and pcem17. Not trying to make a point of anything. For older systems I like all the benefits 86box brings.
Edit: Ops, sorry ! I missed the 2nd page of messages! One thing I noticed, for example, 86box present textures better than pcem in Unreal, and I understand now that with more accurate timings the perceived performance is "worse".

Bruninho wrote on 2023-11-06, 16:43:

@solemgar: according to this page https://www.cpubenchmark.net/singleThread.html […]
Show full quote

@solemgar: according to this page https://www.cpubenchmark.net/singleThread.html

and a research conducted by one moderator from 86box discord server (Efflixi):

What is the best system my computer can run? --- This is hard to answer with 100% certainty because there's too many factors. Th […]
Show full quote

What is the best system my computer can run?
---
This is hard to answer with 100% certainty because there's too many factors. The best we can do is some rough comparisons. https://www.cpubenchmark.net/singleThread.html - Look at that list, while the numbers aren't directly comparable to 86box itself, the higher a cpu is on that list, the faster it will run 86box.

Here's some more comparisons:
~4000 = Pentium II 300
~3400 = Pentium II 233
~2600 = Pentium 200
~1600 = Pentium 75
~700 = 486DX2 66 (assuming the gpu on such a system can keep up)

You're kinda spot on when emulating a PII 350MHz in 86box (unlike PCem where u did a PII 450MHz), because your cpu single thread score is 4,052. Maybe you will be just fine with 300 instead of 350.

I still think a Voodoo 2 is enough rather than using a Voodoo 3 3000, which would improve emulation performance a lot, unless you have any reason to be attached to this card (i.e. "I had this card when I was a kid") which is reasonable; I mounted my 86box machines with the same principle. Again, it is up to you and how you conduct your tests. These are just my two cents based on the data I have here.

And I'll assume Battler is 100% correct in his explanation about the speed discrepancy between PCem and 86box there. I mean, it makes sense.

I am following a very similar principle 😀 Actually my preferred card was a voodoo 2 😁
I will play a bit more with the settings and move it down to a voodoo 2

Bruninho wrote on 2023-11-06, 16:43:

@solemgar: according to this page https://www.cpubenchmark.net/singleThread.html […]
Show full quote

@solemgar: according to this page https://www.cpubenchmark.net/singleThread.html

and a research conducted by one moderator from 86box discord server (Efflixi):

What is the best system my computer can run? --- This is hard to answer with 100% certainty because there's too many factors. Th […]
Show full quote

What is the best system my computer can run?
---
This is hard to answer with 100% certainty because there's too many factors. The best we can do is some rough comparisons. https://www.cpubenchmark.net/singleThread.html - Look at that list, while the numbers aren't directly comparable to 86box itself, the higher a cpu is on that list, the faster it will run 86box.

Here's some more comparisons:
~4000 = Pentium II 300
~3400 = Pentium II 233
~2600 = Pentium 200
~1600 = Pentium 75
~700 = 486DX2 66 (assuming the gpu on such a system can keep up)

You're kinda spot on when emulating a PII 350MHz in 86box (unlike PCem where u did a PII 450MHz), because your cpu single thread score is 4,052. Maybe you will be just fine with 300 instead of 350.

I still think a Voodoo 2 is enough rather than using a Voodoo 3 3000, which would improve emulation performance a lot, unless you have any reason to be attached to this card (i.e. "I had this card when I was a kid") which is reasonable; I mounted my 86box machines with the same principle. Again, it is up to you and how you conduct your tests. These are just my two cents based on the data I have here.

And I'll assume Battler is 100% correct in his explanation about the speed discrepancy between PCem and 86box there. I mean, it makes sense.

And one thing more 😀 Any shader recommendation to load on 86box?

solemgar wrote on 2023-11-08, 18:31:

Bruninho wrote on 2023-11-06, 16:43:

@solemgar: according to this page https://www.cpubenchmark.net/singleThread.html […]
Show full quote

@solemgar: according to this page https://www.cpubenchmark.net/singleThread.html

and a research conducted by one moderator from 86box discord server (Efflixi):

What is the best system my computer can run? --- This is hard to answer with 100% certainty because there's too many factors. Th […]
Show full quote

What is the best system my computer can run?
---
This is hard to answer with 100% certainty because there's too many factors. The best we can do is some rough comparisons. https://www.cpubenchmark.net/singleThread.html - Look at that list, while the numbers aren't directly comparable to 86box itself, the higher a cpu is on that list, the faster it will run 86box.

Here's some more comparisons:
~4000 = Pentium II 300
~3400 = Pentium II 233
~2600 = Pentium 200
~1600 = Pentium 75
~700 = 486DX2 66 (assuming the gpu on such a system can keep up)

You're kinda spot on when emulating a PII 350MHz in 86box (unlike PCem where u did a PII 450MHz), because your cpu single thread score is 4,052. Maybe you will be just fine with 300 instead of 350.

I still think a Voodoo 2 is enough rather than using a Voodoo 3 3000, which would improve emulation performance a lot, unless you have any reason to be attached to this card (i.e. "I had this card when I was a kid") which is reasonable; I mounted my 86box machines with the same principle. Again, it is up to you and how you conduct your tests. These are just my two cents based on the data I have here.

And I'll assume Battler is 100% correct in his explanation about the speed discrepancy between PCem and 86box there. I mean, it makes sense.

And one thing more 😀 Any shader recommendation to load on 86box?

Oh hi I don't use shaders... at least not yet, but I think CRT Lottes shader is the most popular one.

Bruninho wrote on 2023-11-08, 20:19:

solemgar wrote on 2023-11-08, 18:31:

Bruninho wrote on 2023-11-06, 16:43:

@solemgar: according to this page https://www.cpubenchmark.net/singleThread.html […]
Show full quote

@solemgar: according to this page https://www.cpubenchmark.net/singleThread.html

and a research conducted by one moderator from 86box discord server (Efflixi):

You're kinda spot on when emulating a PII 350MHz in 86box (unlike PCem where u did a PII 450MHz), because your cpu single thread score is 4,052. Maybe you will be just fine with 300 instead of 350.

I still think a Voodoo 2 is enough rather than using a Voodoo 3 3000, which would improve emulation performance a lot, unless you have any reason to be attached to this card (i.e. "I had this card when I was a kid") which is reasonable; I mounted my 86box machines with the same principle. Again, it is up to you and how you conduct your tests. These are just my two cents based on the data I have here.

And I'll assume Battler is 100% correct in his explanation about the speed discrepancy between PCem and 86box there. I mean, it makes sense.

And one thing more 😀 Any shader recommendation to load on 86box?

Oh hi I don't use shaders... at least not yet, but I think CRT Lottes shader is the most popular one.

Will give it a spin, thanks a million Bruninho!

eddman wrote on 2023-11-06, 15:53:

I did mention that guest CPU emulation is single core dependent, however if you don't have enough cores or set the affinity too low (and enable, say, voodoo), the emulation speed would still drop because now multiple threads are processed by those few cores and they can't handle that. You need both high single-core performance and enough cores.

is possible to have a cpu emulation using multi threads in the future for pcem ou x86box or other fork ?

willow wrote on 2023-12-29, 23:27:

is possible to have a cpu emulation using multi threads in the future for pcem ou x86box or other fork ?

Take this into consideration; there is no console emulator out there that multi-threads the emulation of a single core CPU. That should tell you something.

It's not a PCem or 86Box issue to be resolved.

Old PC CPUs are single core and the consumer programs that were written for them were single-threaded, so the emulation would also need to be single-threaded.

You can't split the processing of a single-threaded code between multiple cores, and expect to have better performance. You'll actually have a considerably worse performance.

This goes into more detail: https://superuser.com/questions/293809/can-a- … -multiple-cores

eddman wrote on 2023-12-30, 09:59:

Take this into consideration; there is no console emulator out there that multi-threads the emulation of a single core CPU. That […]
Show full quote

willow wrote on 2023-12-29, 23:27:

is possible to have a cpu emulation using multi threads in the future for pcem ou x86box or other fork ?

Take this into consideration; there is no console emulator out there that multi-threads the emulation of a single core CPU. That should tell you something.

It's not a PCem or 86Box issue to be resolved.

Old PC CPUs are single core and the consumer programs that were written for them were single-threaded, so the emulation would also need to be single-threaded.

You can't split the processing of a single-threaded code between multiple cores, and expect to have better performance. You'll actually have a considerably worse performance.

This goes into more detail: https://superuser.com/questions/293809/can-a- … -multiple-cores

Thanks for the explanation.
I had another beginner question from someone who knows nothing about it. Why does PCem require powerful CPUs to emulate CPUs that are 10 to 100 times less powerful, or perhaps even more, while console emulators can emulate consoles with CPUs much more powerful than a Pentium 2, even at 450MHz? Is it due to something specific? If it's too complicated to explain or not possible, that's okay, it was just out of curiosity

willow wrote on 2023-12-30, 15:11:

I had another beginner question from someone who knows nothing about it. Why does PCem require powerful CPUs to emulate CPUs that are 10 to 100 times less powerful, or perhaps even more, while console emulators can emulate consoles with CPUs much more powerful than a Pentium 2, even at 450MHz? Is it due to something specific? If it's too complicated to explain or not possible, that's okay, it was just out of curiosity

There are certainly improvements that could be made to PCem's recompiler, but an x86 recompiler is a lot more complicated than an ARM one due to the complexity of the x86 ISA, and that a PC emulator needs to support real and protected modes, among other fun stuff.
There are only a limited number of people on the planet with the skills to improve the situation without breaking a bunch of things. Consoles also have the benefit of being mostly fixed platforms. The compatibility list of an average console pales in comparison to the tens of thousands of drivers, peripherals and software titles that are backwards compatible on any given PC architecture. You could wind up making some of them faster and others much slower, inadvertently - a situation that has actually happened before.

There were definitely a number of optimisations I originally had planned for v19+. Copy-on-write register allocation, chaining non-contiguous blocks together, instruction reordering, using host MMU on 64-bit hosts. Should have improved things a bit.

SarahWalker wrote on 2024-01-02, 12:56:

There were definitely a number of optimisations I originally had planned for v19+. Copy-on-write register allocation, chaining non-contiguous blocks together, instruction reordering, using host MMU on 64-bit hosts. Should have improved things a bit.

Thanks chiming in. Taking the chance to say thank you as well for the PCem project in general. The amount of things it accomplishes I could have never believe them until I tried them myself.

GloriousCow wrote on 2023-12-30, 17:18:

There are certainly improvements that could be made to PCem's recompiler, but an x86 recompiler is a lot more complicated than an ARM one due to the complexity of the x86 ISA, and that a PC emulator needs to support real and protected modes, among other fun stuff.
There are only a limited number of people on the planet with the skills to improve the situation without breaking a bunch of things. Consoles also have the benefit of being mostly fixed platforms. The compatibility list of an average console pales in comparison to the tens of thousands of drivers, peripherals and software titles that are backwards compatible on any given PC architecture. You could wind up making some of them faster and others much slower, inadvertently - a situation that has actually happened before.

I apologize for the noob question, but why do you need a recompiler to emulate old PCs on a modern processor with x86-64 architecture?
Don't x86-64 processors have a native, backwards compatible instruction set?
Probably some applications require particularly accurate emulation of older systems, but for mass gaming use, isn’t it possible to create a separate accelerated mode?
The Internet is full of examples of installing Win 98-95 and even MS DOS on modern computers, and for gaming use of old operating systems, the only thing missing is video drivers with support for 3D acceleration for modern video cards and sound drivers.

Dokka wrote on 2024-01-17, 13:52:

I apologize for the noob question, but why do you need a recompiler to emulate old PCs on a modern processor with x86-64 archite […]
Show full quote

I apologize for the noob question, but why do you need a recompiler to emulate old PCs on a modern processor with x86-64 architecture?
Don't x86-64 processors have a native, backwards compatible instruction set?
Probably some applications require particularly accurate emulation of older systems, but for mass gaming use, isn’t it possible to create a separate accelerated mode?
The Internet is full of examples of installing Win 98-95 and even MS DOS on modern computers, and for gaming use of old operating systems, the only thing missing is video drivers with support for 3D acceleration for modern video cards and sound drivers.

The key point of the videos you've seen of running DOS on a modern PC is that every Intel CPU, even to this day, boots up in a mode functionally equivalent to a 40 year old PC, for legacy reasons. You can run old code on it, and your 4080 GPU still knows how to act like a VGA from 1993, but it's mostly a party trick. People don't want to shut down their systems and reboot into DOS, and even then, you're stuck with the hardware you have in your system. This mode is pretty much unavailable once you've booted into a modern 64-bit OS.

So that leaves us with running code while booted into our OS, which can be done either through virtualization, or what is called Native Code Execution (NCE), which is done on ARM by emulators like Yuzu, to make games playable on your ARM-powered smartphone. The biggest drawback is that it limits you to hosts with the same architecture as the emulated machine, with a fairly similar ISA. So no more 86Box on your Macbook.

NCE isn't going to help you run 16-bit DOS programs when you are happily running the host in 64-bit mode, nor is it going to timewarp the circa-2020 Intel ISA back to 1993 for you, or pretend you have a type of bus or specific piece of hardware that you do not. If you have to rewrite a bunch of code to accommodate these differences, you're already basically doing recompilation. I think it works well for Yuzu because the guest device and the devices emulating it are from relatively the same timeframe.

The mentioned emulators are also trying to be fairly accurate in terms of the speed and timings of the machines they emulate for maximum compatibility, which is made difficult when the native code executes at a blistering rate compared to what you're trying to emulate. There's a lot of code out there that never assumed the astonishing single-threaded speed of a modern PC - divisions by 0 or games that run at unplayable speeds are common symptoms. This has been an issue even on games as recent as Skyrim - above a certain FPS the physics engine goes haywire. This is an issue with recompilation as well, but you have more control over the intended timing of translated blocks.

When virtualizing the CPU, emulating specific, era-accurate hardware can be tricky, too. Take for example a hypothetical VGA card - reading and writing to the memory-mapped VRAM has side effects. Reading sets the cards internal latches, and writing memory passes bytes through the card's write mode pipeline. These side effects can't be handled by a simple mapped buffer, so we may have to do an expensive context switch called an 'VM Exit'. Hypervisors typically have special drivers for their video cards and other devices to take advantage of internal optimizations. We start getting into situations where high level emulation is more practical, but PCem and 86box are low-level emulators.

Nothing I've said is insurmountable, I think, it's just a matter if there is enough talent, resources, time and effort available to accomplish it.

GloriousCow wrote on 2024-01-17, 15:20:

The key point of the videos you've seen of running DOS on a modern PC is that every Intel CPU, even to this day, boots up in a m […]
Show full quote

Dokka wrote on 2024-01-17, 13:52:

I apologize for the noob question, but why do you need a recompiler to emulate old PCs on a modern processor with x86-64 archite […]
Show full quote

I apologize for the noob question, but why do you need a recompiler to emulate old PCs on a modern processor with x86-64 architecture?
Don't x86-64 processors have a native, backwards compatible instruction set?
Probably some applications require particularly accurate emulation of older systems, but for mass gaming use, isn’t it possible to create a separate accelerated mode?
The Internet is full of examples of installing Win 98-95 and even MS DOS on modern computers, and for gaming use of old operating systems, the only thing missing is video drivers with support for 3D acceleration for modern video cards and sound drivers.

The key point of the videos you've seen of running DOS on a modern PC is that every Intel CPU, even to this day, boots up in a mode functionally equivalent to a 40 year old PC, for legacy reasons. You can run old code on it, and your 4080 GPU still knows how to act like a VGA from 1993, but it's mostly a party trick. People don't want to shut down their systems and reboot into DOS, and even then, you're stuck with the hardware you have in your system. This mode is pretty much unavailable once you've booted into a modern 64-bit OS.

So that leaves us with running code while booted into our OS, which can be done either through virtualization, or what is called Native Code Execution (NCE), which is done on ARM by emulators like Yuzu, to make games playable on your ARM-powered smartphone. The biggest drawback is that it limits you to hosts with the same architecture as the emulated machine, with a fairly similar ISA. So no more 86Box on your Macbook.

NCE isn't going to help you run 16-bit DOS programs when you are happily running the host in 64-bit mode, nor is it going to timewarp the circa-2020 Intel ISA back to 1993 for you, or pretend you have a type of bus or specific piece of hardware that you do not. If you have to rewrite a bunch of code to accommodate these differences, you're already basically doing recompilation. I think it works well for Yuzu because the guest device and the devices emulating it are from relatively the same timeframe.

The mentioned emulators are also trying to be fairly accurate in terms of the speed and timings of the machines they emulate for maximum compatibility, which is made difficult when the native code executes at a blistering rate compared to what you're trying to emulate. There's a lot of code out there that never assumed the astonishing single-threaded speed of a modern PC - divisions by 0 or games that run at unplayable speeds are common symptoms. This has been an issue even on games as recent as Skyrim - above a certain FPS the physics engine goes haywire. This is an issue with recompilation as well, but you have more control over the intended timing of translated blocks.

When virtualizing the CPU, emulating specific, era-accurate hardware can be tricky, too. Take for example a hypothetical VGA card - reading and writing to the memory-mapped VRAM has side effects. Reading sets the cards internal latches, and writing memory passes bytes through the card's write mode pipeline. These side effects can't be handled by a simple mapped buffer, so we may have to do an expensive context switch called an 'VM Exit'. Hypervisors typically have special drivers for their video cards and other devices to take advantage of internal optimizations. We start getting into situations where high level emulation is more practical, but PCem and 86box are low-level emulators.

Nothing I've said is insurmountable, I think, it's just a matter if there is enough talent, resources, time and effort available to accomplish it.

It’s all clear that software like PCem provides the convenience of using old OS and old 16-bit programs without the need to restart the computer and natively launch the old OS. There is also an obvious advantage in the form of emulating old video cards and ensuring the correct speed of program execution.
But the whole question is in the method of ensuring the correct speed. I read somewhere that emulators like PCem can use up to 200 instructions to emulate one instruction of a virtual processor, as a result, modern computers can barely cope with P2-450 emulation. I'm certainly not an expert, but there is probably a less expensive one a way to slow down old programs.

I followed the topic here because I have the same doubt as the title, but so far no one has talked about UniPCEm. I haven't used it yet, but I think it's somewhere between dosbox and pcm perhaps?

UniPCEm continues to be developed? How fast is he? What requirements?

I guess UniPCEM doesnt get as much attention as 86Box and DOSBox-X has been getting lately, with PCem in a close second (apparently in "maintenance mode").

Why does everyone keep calling it 'UniPCEM'? It's name is UniPCemu. It also isn't related to those other emulators (other than the MPU-401 due to there not being any documentation to implement the full hardware myself and INT 10h video and keyboard support on the internal BIOS if used, all adjusted from old Dosbox code and modified to run inside UniPCemu).

I got to admit that the last release was some time ago (april last year if I remember correctly), mostly because of still ironing out some remaining issues (808x EU timings and recent non-MC6845 display controller issues) and the huge update notes list to make on release.