VOGONS


PCEM vs 86Box vs UniPCEM vs DosBox-X

Topic actions

Reply 20 of 58, by eddman

User metadata
Rank Member
Rank
Member

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.

Reply 21 of 58, by Battler

User metadata
Rank Member
Rank
Member

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

Reply 22 of 58, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie

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

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.
READ: Right to Repair sucks and is illegal!

Reply 23 of 58, by solemgar

User metadata
Rank Newbie
Rank
Newbie
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".

Reply 24 of 58, by solemgar

User metadata
Rank Newbie
Rank
Newbie
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

Reply 25 of 58, by solemgar

User metadata
Rank Newbie
Rank
Newbie
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?

Reply 26 of 58, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie
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.

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.
READ: Right to Repair sucks and is illegal!

Reply 27 of 58, by solemgar

User metadata
Rank Newbie
Rank
Newbie
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!

Reply 28 of 58, by willow

User metadata
Rank Member
Rank
Member
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 ?

Reply 29 of 58, by eddman

User metadata
Rank Member
Rank
Member
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

Reply 30 of 58, by willow

User metadata
Rank Member
Rank
Member
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

Reply 31 of 58, by GloriousCow

User metadata
Rank Member
Rank
Member
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.

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc

Reply 32 of 58, by SarahWalker

User metadata
Rank Member
Rank
Member

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.

Reply 33 of 58, by solemgar

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 34 of 58, by Dokka

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 35 of 58, by GloriousCow

User metadata
Rank Member
Rank
Member
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.

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc

Reply 36 of 58, by Dokka

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 37 of 58, by Rikintosh

User metadata
Rank Member
Rank
Member

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?

Take a look at my blog: http://rikintosh.blogspot.com
My Youtube channel: https://www.youtube.com/channel/UCfRUbxkBmEihBEkIK32Hilg

Reply 38 of 58, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie

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

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.
READ: Right to Repair sucks and is illegal!

Reply 39 of 58, by superfury

User metadata
Rank l33t++
Rank
l33t++

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.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io