Falcosoft wrote on 2025-02-14, 06:43:

cyclone3d wrote on 2025-02-14, 05:30:

And that is what piqued my curiosity as well. […]
Show full quote

And that is what piqued my curiosity as well.

An ATI x1050 POSTs so that is a good sign.
CSM mode is there as well as legacy USB support (act like PS/2).

Going to try some other video cards now. The first one I tried seems to be bad as the monitor came on but no picture was displayed, but who knows at this point.

Edit - these cards work:
ATI X850XT
ATI X300
Nvidia GeForce 6600
Nvidia GeForce PCX 5900

Now to do some FreeDOS and vesa testing.

You should check this with the help of MTRRLFBE:

impossibility of enabling MTRRs in bare metal DOS.

It seems to have worked. It didn't give me an error when I ran it and 3dbench 1.0c went from 263.1 fps to 478.2 fps.

Edit:
The X850XT is faster than the PCX 5900.
581.3 fps after running MTRRLFBE.

In the DOOM max detail test, the X850XT is extremely faster than the PCX 5900.

Also, FastVid speeds up some other stuff that MTRRLFBE doesn't, as is evident in Landmark System Speed Test 6.00 as the char/ms goes through the stratosphere.

Note: this is also with the CPU and RAM at default speeds (3.1 GHz and 2133Mhz) I very highly doubt the CPU is boosting in DOS.

Systems189 wrote on 2025-02-14, 02:50:

Why did you go with the 2600k ? When 6th gen intel works as well for freedos and is faster?

That system was built back in 2011 when 2nd gen was new. It still is fastest for me in DOS today, because of its outstanding clockspeed. Newer 6th gen and above don't clock as high, especially in bare metal DOS. The 2600k is unlocked.

Can you get beyond 5 Ghz with any 6th gen Haswell chip? Clock-for-clock I agree a 5Ghz Haswell overclock would be faster than a 5Ghz Sandybridge.

Falcosoft wrote on 2025-02-14, 06:43:

cyclone3d wrote on 2025-02-14, 05:30:

And that is what piqued my curiosity as well. […]
Show full quote

And that is what piqued my curiosity as well.

An ATI x1050 POSTs so that is a good sign.
CSM mode is there as well as legacy USB support (act like PS/2).

Going to try some other video cards now. The first one I tried seems to be bad as the monitor came on but no picture was displayed, but who knows at this point.

Edit - these cards work:
ATI X850XT
ATI X300
Nvidia GeForce 6600
Nvidia GeForce PCX 5900

Now to do some FreeDOS and vesa testing.

You should check this with the help of MTRRLFBE:

impossibility of enabling MTRRs in bare metal DOS.

At least with the internal GPU, MTRRs can't be enabled on any post-Haswell system that I have. Result on attempt with MTRRLFBE and other utilities is a hard system freeze and / or no effect.

As to other (dedicated) cards being used on post-Haswell chips with a CSM on a UEFI BIOS to enable MTRRs, I think some might work, but probably still with incomplete and broken VBE 3.0 / VESA modes. Their vBIOSes either don't support 8-bit modes or support only 32 bit VESA modes, or eliminate VESA and LFB pageframe modes completely.

Intel GPUs past 8th Gen, also eliminated 8-bit VGA modes in their vBIOS making them useless for bare metal DOS.

cyclone3d wrote on 2025-02-14, 07:25:

n't give me an error when I ran it and 3dbench 1.0c went from 263.1 fps to 478.2 fps. […]
Show full quote

n't give me an error when I ran it and 3dbench 1.0c went from 263.1 fps to 478.2 fps.

Edit:
The X850XT is faster than the PCX 5900.
581.3 fps after running MTRRLFBE.

In the DOOM max detail test, the X850XT is extremely faster than the PCX 5900.

Also, FastVid speeds up some other stuff that MTRRLFBE doesn't, as is evident in Landmark System Speed Test 6.00 as the char/ms goes through the stratosphere.

Note: this is also with the CPU and RAM at default speeds (3.1 GHz and 2133Mhz) I very highly doubt the CPU is boosting in DOS.

But try some SVGA games or benchmarks as well and see if LFB is enabled and benefits from the MTRR speedup as well. Try Quake 2 DOS or Hexen 2 for DOS at 1024x768 or 1600x1200. That's where your real speedup will occur if MTRRs are enabled and LFB is correct and enabled for these dedicated video cards. Some benchmark that goes beyond 320x200 VGA and into 640x480 and beyond.

Does anyone know the for sure answer to my question?

zyzzle wrote on 2025-02-15, 00:12:

Systems189 wrote on 2025-02-14, 02:50:

Why did you go with the 2600k ? When 6th gen intel works as well for freedos and is faster?

That system was built back in 2011 when 2nd gen was new. It still is fastest for me in DOS today, because of its outstanding clockspeed. Newer 6th gen and above don't clock as high, especially in bare metal DOS. The 2600k is unlocked.

Can you get beyond 5 Ghz with any 6th gen Haswell chip? Clock-for-clock I agree a 5Ghz Haswell overclock would be faster than a 5Ghz Sandybridge.

Wouldnt the IPC be greater though? Clock speed is not everything. You are looking at single threat performance.

zyzzle wrote on 2025-02-15, 00:24:

cyclone3d wrote on 2025-02-14, 07:25:

n't give me an error when I ran it and 3dbench 1.0c went from 263.1 fps to 478.2 fps. […]
Show full quote

n't give me an error when I ran it and 3dbench 1.0c went from 263.1 fps to 478.2 fps.

Edit:
The X850XT is faster than the PCX 5900.
581.3 fps after running MTRRLFBE.

In the DOOM max detail test, the X850XT is extremely faster than the PCX 5900.

Also, FastVid speeds up some other stuff that MTRRLFBE doesn't, as is evident in Landmark System Speed Test 6.00 as the char/ms goes through the stratosphere.

Note: this is also with the CPU and RAM at default speeds (3.1 GHz and 2133Mhz) I very highly doubt the CPU is boosting in DOS.

But try some SVGA games or benchmarks as well and see if LFB is enabled and benefits from the MTRR speedup as well. Try Quake 2 DOS or Hexen 2 for DOS at 1024x768 or 1600x1200. That's where your real speedup will occur if MTRRs are enabled and LFB is correct and enabled for these dedicated video cards. Some benchmark that goes beyond 320x200 VGA and into 640x480 and beyond.

I'll go ahead and try some games as well. There were so VESA test programs I ran and the higher resolution ones did work.

zyzzle wrote on 2025-02-14, 02:25:

Yes, that sounds about right to me. Beyond 6th gen Haswell, VBE 3.0 is borked, MTRRs can't be set. As well, you should enable MT […]
Show full quote

Systems189 wrote on 2025-02-13, 23:51:

Hi, im new here.

Im looking for the highest single threaded performance CPU/motherboard for Freedos baremetal with SVGA programming. Right now, from my research, it's looking like the Intel Core i7-6700K 4.00 GHz and the Matrox G550 is my best bet? Is this accurate or am I missing something?

I will be doing software rendering so I dont care about GPU power, only that it has VBE 3.0. Im still new but this seems like the right idea. My goal is not to play games but to make them. I dont want emulation.

Yes, that sounds about right to me. Beyond 6th gen Haswell, VBE 3.0 is borked, MTRRs can't be set. As well, you should enable MTRRs with RayeR's MTRELFBE utility for an outstanding SVGA (640x480 and beyond) speedup.

Raw CPU power of course gets you max single-core performance as well in bare metal DOS. Dual-Channel DDR4 memory increases throughout a few percentage in DOS for same CPU speed as well. (My 2600k OC to 5.0 Ghz is the king of my raw bare-metal DOS performance still today, because of a lucky, lucky chip and a great overclock, even though it only has DDR3 RAM).

I've found that my Haswell laptops are leaps and bounds faster in raw single-threaded performance than later intel core CPUs (up to 10th Gen, with CSM module). So, the peak of single-threaded performance in DOS bare metal was around the 2016-17 timeframe.

Sadly, anything beyond that is a real demotion in DOS due to intentional castration of A20 line, intentional elimination of VBE 3.0 / VESA resolutions in vBIOSes, and impossibility of enabling MTRRs in bare metal DOS.

What do you mean by "lucky" chip?

Decided to see if my PCIe to PCI adapters would work for older video cards.

Tried a bunch and it just gives me a no video beep, even with cards such as the Nvidia GT610 which should definitely work / be new enough.

Going back to PCIe cards I guess.

Found a post here on vogons that says with a custom BIOS, even an Nvidia 7950GT has pretty good VBE support.

Need to figure out how to lock the CPU speed at above the default of 3.1Ghz base speed as well.

How do we know that these are not already set by default on newer video cards? Is there a way to test?

"MTRRs are enabled and LFB is correct and enabled for these dedicated video cards."

What fps are you getting in Quake at 1280x1024?
What about 1024x768?

cyclone3d wrote on 2025-02-18, 03:53:

How do we know that these are not already set by default on newer video cards? Is there a way to test? […]
Show full quote

How do we know that these are not already set by default on newer video cards? Is there a way to test?

"MTRRs are enabled and LFB is correct and enabled for these dedicated video cards."

What fps are you getting in Quake at 1280x1024?
What about 1024x768?

Write combining is a CPU feature so the video card has nothing to do with its enabled/disabled state. Usually most BIOS did not set the proper WC state on MTRRs even when it mattered for DOS graphics performance. On more modern hardware the chances of MTRRs being set properly are even lower.
But of course you can test this with the help of MTRRLFBE:
1. MTRRLFBE.exe LFB WC command enables write combining for the linear frame buffer.
2. MTRRLFBE.exe LFB UC command disables write combining for the linear frame buffer and sets the default uncached state.
So you can test what result you get after a fresh start. If the result is the same as with command 1. then the WC state is set properly by your BIOS. if it is the same as with command 2. then the WC state is not set properly by your BIOS.

I recommend using PCPBENCH for tesing e.g. with the command PCPBENCH.EXE 105 . This tests 1024x768x8bit in LFB mode (if it is available).
You can use PCPBENCH.EXE /MODES command to list available modes if 105 is not available on your card.

Sweet, thx.

I'll do some more testing.

The PCX 5900 doesn't seem to work with Quake after using MTRRLFBE and other benches also slow down after using it.

Think I am going to pull out another build or builds and do some testing to see if that makes any difference.

Systems189 wrote on 2025-02-17, 02:14:

What do you mean by "lucky" chip?

One that overlocks well with little to no vcore increase. (lower temperature increase and less heat production).

And incidently, I though when we're dealing with single-core performance, as bare metal DOS uniformly is running under, that raw CPU coreclock speed followed by L1/L2 cache amounts, followed memory speed is what matters the most.

Falcosoft wrote on 2025-02-18, 11:55:

Write combining is a CPU feature so the video card has nothing to do with its enabled/disabled state. Usually most BIOS did not […]
Show full quote

Write combining is a CPU feature so the video card has nothing to do with its enabled/disabled state. Usually most BIOS did not set the proper WC state on MTRRs even when it mattered for DOS graphics performance. On more modern hardware the chances of MTRRs being set properly are even lower.
But of course you can test this with the help of MTRRLFBE:
1. MTRRLFBE.exe LFB WC command enables write combining for the linear frame buffer.
2. MTRRLFBE.exe LFB UC command disables write combining for the linear frame buffer and sets the default uncached state.
So you can test what result you get after a fresh start. If the result is the same as with command 1. then the WC state is set properly by your BIOS. if it is the same as with command 2. then the WC state is not set properly by your BIOS.

I'm not sure this is the whole story. For example, I have two systems, one uses an i7-5600 CPU, the other uses a Kabylake i5-8250 CPU.

On the i7-5600, the result of 1 above is an extreme and almost order-of-magnitude greater fps (and something like 3 GB/sec MEM-VRAM transfer as tested by MTRRLFBE's companion benchmark utility included in the package). The system boots bare metal DOS in state (2), uncached... the BIOS does NOT correctly set the MTRRs unless I manually do it with MTRRLFBE.

On the Kabylake system, the state is perpetually in (2), uncached, and nothing I can do will enable the MTRRs in WC mode. They're not set by BIOS, nor can they be set. The system hard-freezes if I attempt to set WC with MTRRLFBE, but with your (Falcosoft's) equivalent program to set MTRRs , it has no effect, does not crash, and does not enable MTRRs into WC mode, even when it says they've "been modified."

So, it's a conundrum, more complicated than just saying a system's BIOS does or does not enable the MTRRs. It hasn't been possible for me to enable MTRRs on any 7th gen Icore CPU or above in write-cache combining mode. I suspect this is because such systems don't properly support LFB somehow. I'm not 100% sure, however.

zyzzle wrote on 2025-02-19, 03:37:

I'm not sure this is the whole story. For example, I have two systems, one uses an i7-5600 CPU, the other uses a Kabylake i5-825 […]
Show full quote

Falcosoft wrote on 2025-02-18, 11:55:

Write combining is a CPU feature so the video card has nothing to do with its enabled/disabled state. Usually most BIOS did not […]
Show full quote

Write combining is a CPU feature so the video card has nothing to do with its enabled/disabled state. Usually most BIOS did not set the proper WC state on MTRRs even when it mattered for DOS graphics performance. On more modern hardware the chances of MTRRs being set properly are even lower.
But of course you can test this with the help of MTRRLFBE:
1. MTRRLFBE.exe LFB WC command enables write combining for the linear frame buffer.
2. MTRRLFBE.exe LFB UC command disables write combining for the linear frame buffer and sets the default uncached state.
So you can test what result you get after a fresh start. If the result is the same as with command 1. then the WC state is set properly by your BIOS. if it is the same as with command 2. then the WC state is not set properly by your BIOS.

I'm not sure this is the whole story. For example, I have two systems, one uses an i7-5600 CPU, the other uses a Kabylake i5-8250 CPU.

On the i7-5600, the result of 1 above is an extreme and almost order-of-magnitude greater fps (and something like 3 GB/sec MEM-VRAM transfer as tested by MTRRLFBE's companion benchmark utility included in the package). The system boots bare metal DOS in state (2), uncached... the BIOS does NOT correctly set the MTRRs unless I manually do it with MTRRLFBE.

On the Kabylake system, the state is perpetually in (2), uncached, and nothing I can do will enable the MTRRs in WC mode. They're not set by BIOS, nor can they be set. The system hard-freezes if I attempt to set WC with MTRRLFBE, but with your (Falcosoft's) equivalent program to set MTRRs , it has no effect, does not crash, and does not enable MTRRs into WC mode, even when it says they've "been modified."

So, it's a conundrum, more complicated than just saying a system's BIOS does or does not enable the MTRRs. It hasn't been possible for me to enable MTRRs on any 7th gen Icore CPU or above in write-cache combining mode. I suspect this is because such systems don't properly support LFB somehow. I'm not 100% sure, however.

Hi,
Of course incompatibility on more modern systems is more likely.
E.g. in case of AMD CPUs even with an Athlon XP/Athlon 64 setting the WC attribute on the classic VGA frame buffer (0xA0000 - 0xAFFFF) has no effect.
You have to write a write-once only AMD specific MSR in order WC on VGA to work. But you can only do this if it is not done by BIOS before...

MTRRLFBE and AGP/PCIe cards in DOS
(You can find the VGAMTRR_AMD.zip tool in the above topic if you would like to test it.)

But of course this does not mean that the VGA frame buffer is not supported on these systems. The video frame buffers themselves and the ability to set these memory regions to write-combining mode with the help of MTRRs are 2 different things.
Similarly just because you cannot set the write-combining attribute on LFB in case of modern Intel systems does not mean that LFB is not supported.
Actually it's very unlikely since the LFB region is used even by Windows/Windows GPU drivers.
In case of Windows the proper caching attributes of GPU memory regions are set differently (Page Table PAT bits) for a long time so compatibility with the MTRR based method is not so important.
https://wiki.osdev.org/Paging#PAT

Until someone offers a "universal VBE" utility (like the old Univbe) for "modern" GPUs, and, especially the modern borked / broken 16-bit code in the Intel video BIOSes of post-5th gen intel core systems, this is probably the best we'll get. Broadwell / Haswell is it for maximum video compatibility support in bare metal DOS in 2025.

Who knows? crazii did for sound what now needs to be done for video in bare metal DOS. Some sort of "shim" driver which fixes broken and hopelessly incomplete video BIOSes on "modern" systems. Then, with such a utility, of course a system with up to a 12th gen core system and its onboard GPU could be used and would just *work* without broken 8 bit support, broken EGA/CGA, no VESA support, etc in baremetal DOS boot with all of its rich 40-year-legacy of software.

One can dream. The Univbe folks back in the day did it and supported over 50 cards. So, "fixing" onboard Intel video should be relatively easier with such a "new" vBIOS in memory and / or patched / overwritten into the system BIOS code.

Ok ok ok ok... MwaHaHaHaHa.

Got an Intel 9900k setup put together with an ASUS MAXIMUS XI HERO (WI-FI) motherboard and it definitely supports MTRRLFBE.

The BIOS is currently version 0506. Will try updating and testing again later.

Have it set to stock boost clocks right now (4.7Ghz) and with an ATI X850XT, Quake went from 9.8 fos to 60.0 fps at 1280x1024 on DEMO1 after I ran MTRRLFBE.

At 640x480 it only went from 29.8 fps to 59.8 fps.

The Nvidia PCX 5900 has much higher stock fps than the stock fps of the X850XT but will not run Quake after running MTRRLFBE.

The X299 setup doesn't act the same and I haven't been able to get it to lock the CPU speed at boost clocks or actually anything higher than stock clocks so not sure if that is a viable platform or if an enthusiast grade board would behave differently than the workstation board.

Done for tonight but am super stoked that this is working well so far.

Encouraging news. So your motherboard BIOS seems to support MTRRs and proper framebuffer, albeit with a standalone ATI card and not the stock Intel GPU.

Quake is probably locking the max fps to your video refresh rate, which appears to be 60 fps. There are DOS programs which may modify refresh rate. I believe Vbehz is one such program, which may support up to 120 hz refresh rate in bare metal DOS. Possibly video card BIOS dependent. There used to be an option in Quake to not lock fps to refresh rate. This disables vsync. I can't remember the command line and / or Quake console command, but I think starting Quake with the option: -vsync off will maximize framerate.

Do some more tests with this system and report back. Please list the VESA reolutions supported in DOS. Does it support 1920x1080 in DOS? Anything higher, like 2560x1792?

Try SBemu and the DOS mplayer port. This system should fly in viewing Blu-rays and / or high-bitrate, high resolution h.264 video in DOS. Even h.265 and h.266 should be very much playable and usable in bare metal DOS. At 4.7 Ghz, there's more than enough raw CPU speed and tons of very fast RAM. I assume DDR4 modules?

Test CpuSpeed v 2.0 / 2.1 by Yang (posted on Vogons) to see max achievable CPU multiplier, and also if it supports underclocking / undervolting since your 9900k CPU is completely unlocked. It should work over a very wide range of multipliers, and also throttle well. Something like 8x-47x multipliers. All of this granularity should be configurable with CPUSpeed in bare metal DOS, including enabling / disabling L1/L2 cache as well.

So on to more testing.
In Quake, via the console, to turn off vsync, the command is:
vid_wait 0

That yields 183.5fps.

-vsync off from the command line doesn't work.

Edit: upped t to 5Ghz and now get 190.4fps

RAM is DDR4 CL16-16-16-37. It is rated for 4000 with the same timings but was not posting at that with the original BIOS. Good news is that this still works with the latest BIOS.

Edit 2: 5.2Ghz yields 194.2fps.

Upping the cache speed from 4300 to 4700 and upping the RAM to 3600 did not seem to have any effect.

Anybody know how to get a .cfg file to set vsync off?

The whole file looks like console commands but vid_wait 0 doesn't work.