DOS ain't dead

Hi,
I had a chance to test a nVidia GTX 970 card under DOS. My short tests led me to assumption that the VESA BIOS has the same bugs like on older GTX 670 - e.g. problems with Dark Debugger, crippled fonts in Keen Commander, a bit messy graphics in Partition Magic...
VESA mode list seems to be built dynamically according to attached monitor (it's EDID) trying to utilize a native resolution. I tried 2 LCD panels, my NEC via DVI-D with 1600x1200 - it was the max offered VESA mode, total 31 vmodes. Then I tried with Dell 1900x1200 via DP and the max offered VESA mode was 1900x1200, total 35 vmodes. The xfer speed in vesatest was cca 2,8GB/s same as with GTX 670. So there seems no differences in VBE implementation on this nvidia cards. Maybe it helps someone upgrading his system (GTX 9xx is the last line supported in WinXP-x86).

---
DOS gives me freedom to unlimited HW access.

> Hi,
> I had a chance to test a nVidia GTX 970 card under DOS. My short tests led
> me to assumption that the VESA BIOS has the same bugs like on older GTX 670
> - e.g. problems with Dark Debugger, crippled fonts in Keen Commander, a bit
> messy graphics in Partition Magic...
> VESA mode list seems to be built dynamically according to attached monitor
> (it's EDID) trying to utilize a native resolution. I tried 2 LCD panels, my
> NEC via DVI-D with 1600x1200 - it was the max offered VESA mode, total 31
> vmodes. Then I tried with Dell 1900x1200 via DP and the max offered VESA
> mode was 1900x1200, total 35 vmodes. The xfer speed in vesatest was cca
> 2,8GB/s same as with GTX 670. So there seems no differences in VBE
> implementation on this nvidia cards. Maybe it helps someone upgrading his
> system (GTX 9xx is the last line supported in WinXP-x86).

I saw somewhere (maybe vogons) that the later ATi/AMD GPUs have better DOS compatibility than the nVidia GTX. I have some (Dell OEM) HD5450, HD8490 and others that I'd like to test soon for that.

> The xfer speed in vesatest was cca
> 2,8GB/s same as with GTX 670. So there seems no differences in VBE
> implementation on this nvidia cards. Maybe it helps someone upgrading his
> system (GTX 9xx is the last line supported in WinXP-x86).

So, the GTX 970 does support setting MTRRs write-cache combining with your MTRRLFBE utility? Does the card work well on "modern" DOS systems, i5/i7 8th Gen and above with MTRRs enabled?

Seems like even Intel onboard VGA graphics set the VESA modes dynamically based upon ECID of the monitor, but the last onboard Intel Graphics VGA BIOS which will enable MTRRs without freezing the complete system is the 5th Gen core i3/i5/i7. (Broadwell). 6th Gen-up = very slow, unaccelerated VESA graphics in DOS... no MTRRs are enabled. I've never found a workaround or a hack to prevent this bug / crippling / devolution.

> 5th Gen core i3/i5/i7. (Broadwell). 6th Gen-up = very slow, unaccelerated
> VESA graphics in DOS... no MTRRs are enabled. I've never found a workaround
> or a hack to prevent this bug / crippling / devolution.

AFAIK, enabling the write-combining cache needs to be done with PAT now. This could probably work if managed by an appropriately modified VM86 monitor, but only for real-mode games. Most DOS-extended games run without paging, which would also prevent PAT from being used. At least that’s how I imagine it would work; I’ve never looked at PAE in more detail.

> AFAIK, enabling the write-combining cache needs to be done with PAT now.
> This could probably work if managed by an appropriately modified VM86
> monitor, but only for real-mode games. Most DOS-extended games run without
> paging, which would also prevent PAT from being used. At least that’s how
> I imagine it would work; I’ve never looked at PAE in more detail.

Thank you for this information. I had never imagined that PAT was necessary for write-cache combining on the most modern systems. This is a better answer than I've found elsewhere or in trying to explain the freeze of all > 5th Gen Intel core systems, when using RayeR's utility, or another MTRR-enabler. This appears to be a yet anoth castration / "walled garden" limitation of modern systems. The most modern 12th Gen doesn't even have VESA modes, int13, or DOS text-mode 9x16 fonts, so DOS can't even be booted from USB -- also from lack of CSM legacy BIOS code. Even if non-UEFI code existed in BIOS, DOS games and applications wouldn't be usable due to lack of these fundamental low-resolution VGA modes complete deletion of a legacy 16-bit video BIOS firmware.

> Thank you for this information. I had never imagined that PAT was necessary
> for write-cache combining on the most modern systems. This is a better
> answer than I've found elsewhere or in trying to explain the freeze of all
> > 5th Gen Intel core systems, when using RayeR's utility, or another
> MTRR-enabler. This appears to be a yet anoth castration / "walled garden"
> limitation of modern systems.

My experience is that the freeze happens when the WC region overlapps an UC region. To avoid the overlap is way more difficult to achieve on Intel machines, because they lack the TOP_MEM and TOP2_MEM MSR registers of the AMD machines.

---
MS-DOS forever!

> My experience is that the freeze happens when the WC region overlapps an UC
> region. To avoid the overlap is way more difficult to achieve on Intel
> machines, because they lack the TOP_MEM and TOP2_MEM MSR registers of the
> AMD machines.

Same as my experiences. Very hard to impossible to avoid the overlap! It couldn't be done in my experiences.

As to modern AMD systems, even from the Ryzen 3 released in 2017-18, yes, avoiding WC region overlap is possible, so write-cache combining can be enabled. However all "modern" AMD systems castrate the onboard video BIOS so as to completely eliminate sub-640x480 VGA resolutions (even 320x200 and mode 13, as well as all VESA 8-bit resolutions like 640x480x8bit are excised), so only DOS programs or games utilizing VESA modes in 15-bit (16-bit) or higher work. This is an even worse castration than memory-overlap preventing WC on intel core gen 6-12, since at least the sub-640x480 and 8-bit modes still work! (OOPS, I just checked a 10th gen i5, and all VGA resolutions are cut, *and* wc-catching doesn't work, either, hangs). So, intel gen 6-12 are "worthless" for any bare-metal DOS work at all.

Are you talking about AMD integrated graphics in CPU? I never had a chance to play with a modern AMD machine but I prefer dedicated VGA anyway. About intel, I still have my golded SandyBridge at home that is DOS-friendly enough and then a big leap further a 11th gen. i7 at work but it's 100% UEFI, non-CSM crap so no HW to play with 6th gen+. And as I told, GTX9xx VBIOS seems behave same as GTX6xx, it's enough for playing games in VGA 320x200 or VESA modes but had some fonts issues with CGA.

---
DOS gives me freedom to unlimited HW access.

> Are you talking about AMD integrated graphics in CPU? I never had a chance
> to play with a modern AMD machine but I prefer dedicated VGA anyway. About
> intel, I still have my golded SandyBridge at home that is DOS-friendly
> enough and then a big leap further a 11th gen. i7 at work but it's 100%
> UEFI, non-CSM crap so no HW to play with 6th gen+. And as I told, GTX9xx
> VBIOS seems behave same as GTX6xx, it's enough for playing games in VGA
> 320x200 or VESA modes but had some fonts issues with CGA.

Yes, the AMD integrated graphics on CPU does not even provide sub-640x480 VGA nor even 320x200. So, it's useless for DOS bare metal, although DOS will boot and the 9x16 VGA fonts display correctly (the character ROM font is obviously included in the vbios). And CSM mode is supported in some of the early Ryzen chips / motherboards. But no games play due to no 8-bit support and no low-resolution VGA modes in vbios at all. The integrated sound *is* supported under MPXplay, and it's possible to get full, rich sound under DOS using that program, and Quickview Pro v 2.61, and Mplayer DOS port from your site by Khusraw. Films will also play, as the vbios does support VESA modes upto 1920x1080x32, but only high bitdepth (>= 16-bit colors) and high res modes.

Thanks for the info. It's interesting they discarded VGA stuff but keep VESA. Maybe it has something common to UEFI framebuffer so it was more easy to add some tiny VESA BIOS code to support VESA LFB than emulating legacy VGA ports and other stuff. Working audio is also surprising, some newer HDA on intel MBs doesn't work... BTW does AMD still have some IDE emulation or provide only INT13h in CSM? What xfer speed rougly you get? On my intel (SSD or HDD) I got ~ 100MB/s so quite good...

---
DOS gives me freedom to unlimited HW access.

> BTW does AMD still have some IDE emulation or
> provide only INT13h in CSM? What xfer speed rougly you get? On my intel
> (SSD or HDD) I got ~ 100MB/s so quite good...

Latest AMD system I have is Ryzen 5 3600, and there is no IDE emulation in CSM mode. Int13 only (AHCI mode). I got about max of ~80 mb/s from HDD and 120 mb/s from SSD in DOS. Could not boot SSD directly in legacy / CSM boot mode, I had to use DOS utilities to read the raw sectors via Int 13 access in Testdisk and other utils.

> Could not boot SSD directly in legacy / CSM boot
> mode, I had to use DOS utilities to read the raw sectors via Int 13 access
> in Testdisk and other utils.

I had a Asrock B450 motherboard originally bought with a R5 2600. I upgraded the bios to suit a newer R7 5700X, but then it didn't want to boot non UEFI any more.

So it is possible it is related to newer AGESAs ?