Piqued*

I think that the perfect baremetal DOS experience should have components from this era and anothers with related features, I don't see the point of using DOS on current CPUs both for being overkill and you're misusing your current hardware. From a modest, retro, full 90s experience you are fun either from a 486 DX4-100 to a Pentium II/III or K6-II. If you plan to use more OSes like Windows 98, NT, 2k and XP I guess both an Athlon XP (socket A) or (Socket 939) Athlon 64 X2 might be the highest-end for pure retro usage.

Not to argue with the above, or what others said in the thread - I am curious, with BIOSes long offering sophisticated features like USB support and legacy device emulation and EFI looking like a miniature OS in itself... is there even guarantee that on a PC which is anywhere modern the CPU is actually in real mode by the time DOS bootloader kicks in? I don't know - hence asking - but could it be that the topic of "pure real mode" is something that is difficult to relate to anything past, say, PII?

ludicrous_peridot wrote on 2025-01-28, 17:57:

Not to argue with the above, or what others said in the thread - I am curious, with BIOSes long offering sophisticated features like USB support and legacy device emulation and EFI looking like a miniature OS in itself... is there even guarantee that on a PC which is anywhere modern the CPU is actually in real mode by the time DOS bootloader kicks in? I don't know - hence asking - but could it be that the topic of "pure real mode" is something that is difficult to relate to anything past, say, PII?

In case BIOS based systems 16-bit real mode as a starting mode is guaranteed. Also in case of UEFI systems in CSM mode. Otherwise no DOS or legacy 32-bit Windows could boot/work at all.
In case of pure UEFI it is guaranteed that the system does NOT start in 16-bit real mode but in 32/64-bit.

Falcosoft wrote on 2025-01-28, 19:40:

ludicrous_peridot wrote on 2025-01-28, 17:57:

Not to argue with the above, or what others said in the thread - I am curious, with BIOSes long offering sophisticated features like USB support and legacy device emulation and EFI looking like a miniature OS in itself... is there even guarantee that on a PC which is anywhere modern the CPU is actually in real mode by the time DOS bootloader kicks in? I don't know - hence asking - but could it be that the topic of "pure real mode" is something that is difficult to relate to anything past, say, PII?

In case BIOS based systems 16-bit real mode as a starting mode is guaranteed. Also in case of UEFI systems in CSM mode. Otherwise no DOS or legacy 32-bit Windows could boot/work at all.
In case of pure UEFI it is guaranteed that the system does NOT start in 16-bit real mode but in 32/64-bit.

I dare not upgrade my TUF B450 BIOS, I need DOS/WIN98/XP on such a hobby.

Falcosoft wrote on 2025-01-28, 19:40:

ludicrous_peridot wrote on 2025-01-28, 17:57:

Not to argue with the above, or what others said in the thread - I am curious, with BIOSes long offering sophisticated features like USB support and legacy device emulation and EFI looking like a miniature OS in itself... is there even guarantee that on a PC which is anywhere modern the CPU is actually in real mode by the time DOS bootloader kicks in? I don't know - hence asking - but could it be that the topic of "pure real mode" is something that is difficult to relate to anything past, say, PII?

In case BIOS based systems 16-bit real mode as a starting mode is guaranteed. Also in case of UEFI systems in CSM mode. Otherwise no DOS or legacy 32-bit Windows could boot/work at all.
In case of pure UEFI it is guaranteed that the system does NOT start in 16-bit real mode but in 32/64-bit.

Pretty sure they start in 16.
Might only be a few instructions to change to 32/64,but I'm pretty sure the CPUs all start in the same mode since the 8088.

I see - I got confused with the above passages about EMM386 and that plain DOS applications were running in V86 mode impacting the test setup, so was suspecting if BIOS-es or other FW could be pulling off similar shenanigans to bootloader/kernel, but as has been explained those would simply not boot unless CPU was back to plain old 16bit mode, so thanks for the explanation.

On the other hand - to think about it - even before fancy stuff like USB BIOSes were supporsed to support HW, and have device FWs loaded and all manner of stuff must have been happenning in the background via interrupts even if only kernel and command.com were loaded... so that would be the reality of any PC regardless of the generation that not only the benchmark code would run at any given time (generally speaking), and architecture overall and particular devices would impact the benchmark performance.

I am just thinking how practical synthetic benchmarks are for when comparing different architectures or machines from different time periods? For a thought experiment take RealDOOM as an example - it's a present day application that has just recently been compiled; sound is already off there and one could also probably add -norender to it (if it's not there yet) and thus take out video memory interaction; and also probably cache in all of the IWAD data preemptively to avoid any disk operations. That would still leave in memory interaction for data (of which there are megabytes). And that's where RealDOOM seems to actually show a difference between real EMS and emulated if I get the readme right. So, would one say that 286 CPU is better for real mode applications than a 486 based on this benchmark?

Ringding wrote on 2024-08-24, 13:45:

Riikcakirds wrote on 2024-08-23, 22:47:

The software/programs don't need to support VME, the CPU just needs it to be enabled, which EMM386 and any version of Win3.x will not, so you will get a slowdown in anything that uses V86 mode.
Loading Emm386 will generally slow down everything in DOS by 25-35% (video, i/o performance, FPU) . NSSI benchmark is just an easy way to show it as a real time bar graph. It is the same with other dos benchmarks/games. The same whether using a 486DX4 or Corei7. The only difference is the slowdown is much more notable on a 386/486 versus a 3GHz core i7 slowed down by 25%.
This was well known back in the early 1990's when using a 386 and 486 as it had such a big impact on performance.

Well yes, but claiming that everything gets slower is very different from saying that it decreases FPU performance.

So if I load EMM386 and then run 32-bit app that uses CWSDPMI, would I be able to notice a slowdown on a, say, Pentium 3 - or is this isolated around FPU assisted calculations?

I suppose you could argue that the 286 is potentially more efficient.

But at some point, raw horsepower more than compensates for efficiency losses.

You wouldn't use a dragster to tow out a plane, because the custom built towing vehicles are better suited to the task, but you certainly could use a dragster, and it would probably be faster if that's the quality you're looking for.

That said, most CPU instructions are a superset of the previous ones.
An integer unit takes the same number of clock cycles to add 2 numbers whether they're 16bit or 64. It is a parallel operation with each unit operating on one bit, and could be scaled infinitely in theory.

A forklift capable of lifting a 40ft container will have no discernible performance difference operating on only 20ft containers.
The weight/volume per time will be half, but the number of containers will be basically the same.

So... Yeah. I dunno, but it should favour newer parts even if they're less efficient.

myne wrote on 2025-01-29, 01:46:

Falcosoft wrote on 2025-01-28, 19:40:

ludicrous_peridot wrote on 2025-01-28, 17:57:

Not to argue with the above, or what others said in the thread - I am curious, with BIOSes long offering sophisticated features like USB support and legacy device emulation and EFI looking like a miniature OS in itself... is there even guarantee that on a PC which is anywhere modern the CPU is actually in real mode by the time DOS bootloader kicks in? I don't know - hence asking - but could it be that the topic of "pure real mode" is something that is difficult to relate to anything past, say, PII?

In case BIOS based systems 16-bit real mode as a starting mode is guaranteed. Also in case of UEFI systems in CSM mode. Otherwise no DOS or legacy 32-bit Windows could boot/work at all.
In case of pure UEFI it is guaranteed that the system does NOT start in 16-bit real mode but in 32/64-bit.

Pretty sure they start in 16.
Might only be a few instructions to change to 32/64,but I'm pretty sure the CPUs all start in the same mode since the 8088.

Yes, the CPU itself is sure to start in 16-bit mode. Only a hypothetical x86S could work differently:
https://www.intel.com/content/www/us/en/devel … chitecture.html

But I was talking about the environment/mode that the firmware (BIOS/UEFI) initializes that software (at 1st step boot loaders/ operating systems) has to interact with since this is what the OP asked about:

... is there even guarantee that on a PC which is anywhere modern the CPU is actually in real mode by the time DOS bootloader kicks in?

BIOS and UEFI with CSM initialize the same 16 bit real mode that even the 8086/8088 used back then. But native UEFI does not. In case of native UEFI even lower level software/OS loader has to be 32/64-bit depending on the UEFI version.
https://wiki.osdev.org/UEFI#Platform_initialization

After having read this discussion I ran a few simplistic (but not synthetic) tests on the machines of different generations with the aim of seeing how performance of various executables scaled with computational power offered to them and documented the results here.

Unfortunately, as much as I wanted to make this comparison to also be relevant to this topic and to make a real experiment out of the though experiment with RealDoom, I have failed to run it on any of the machines in the article. The closest I got was seeing title screen and a few seconds after the game was hanging. I honestly did not expect that getting EMS right would present me such a challenge... 😀

Still looking forward to trying again eventually and filling the gaps. In the meantime got some food for thought with regards to how, say, video card interaction can skew the observed results - well, depending on what one sets out to measure of course.

UP:
I was eventually able to run RealDoom but with a few caveats which prevent me from updating the table in the page linked above (ver 0.22 used, which is not latest and does not support Episode 4; was able to run only on one PC out of 4; it was crashing after completing demo every time, but since subsequent reruns yielded the same values I have actually recorded them). However, despite EMM386 was loaded to provide EMS to the port, I would like to share the findings in this thread; when run on the Core 2 machine (also in sig.) I found that that Vanilla Doom was 0.8~1.6 times faster. Without comparing this to another machine, this may be useless information, but what author claims in the readme is that the version at the moment it was published was ``~5-10% slower than Vanilla DOOM`` on whatever machine he was trying. I am a bit concerned a fairly well performing PC would run an intentionally 16 bit application poorer than whatever test set up it is being developed (somehow I suspect it's not a Ryzen). Was unable to run this with JEMMEX to rule out EMM386 being the culprit.