vanfanel wrote on 2023-05-16, 12:26:

Well, VINFO doesn't report any video modes on HD 500, but there's this "AdvanceCAB" set of utilities, available here: http://mir […]
Show full quote

Well, VINFO doesn't report any video modes on HD 500, but there's this "AdvanceCAB" set of utilities, available here:
http://mirrors.arcadecontrols.com/AdvanceMAME … b-download.html

The inlcuded utility called VGA.EXE can detect these modes on the HD 500:

report7.jpg

However, after loading this "VGA" TSR, Prince of Persia is still unable to find the VGA, and Aladding still works like this:

report7.jpg

..which leads me to think that HD 500 is reeeeaaaally flawed for DOS, way beyond VESA modes availability.

I can't actually get VINFO to work on 3 machines I tried, or in DOSBox, so I found an alternative, PC Player 3D Benchmark, which will report VBE modes with PCPBENCH /MODES. Here's the output from a Vortex86DX2 (shortest list from the 3 machines I tried but still includes the important modes):

1                         VESA VBE Version: 3.0 (RDC)
2
3                Auflősung       8bpp    15bpp   16bpp   32bpp
4                ---------------------------------------------
5                 640x 480        101             111     112    
6                 720x 480        126             127     128    
7                 800x 600        103             114     115    
8                1024x 768        105             117     118    

vanfanel wrote on 2023-05-16, 12:26:

Well, VINFO doesn't report any video modes on HD 500, but there's this "AdvanceCAB" set of utilities, available here: http://mir […]
Show full quote

Well, VINFO doesn't report any video modes on HD 500, but there's this "AdvanceCAB" set of utilities, available here:
http://mirrors.arcadecontrols.com/AdvanceMAME … b-download.html

The inlcuded utility called VGA.EXE can detect these modes on the HD 500:

report7.jpg

However, after loading this "VGA" TSR, Prince of Persia is still unable to find the VGA, and Aladding still works like this:

report7.jpg

..which leads me to think that HD 500 is reeeeaaaally flawed for DOS, way beyond VESA modes availability.

I'm not sure about the TSR but it seems a "supported" function does not necessarily mean "implemented", like how the Kepler issue demonstrates. I think that TSR merely replaces the mode table with one that contains the modes that games expect (so apps/games that actually look at the mode table would be happy), but it's still up to the VGA BIOS itself to actually implement the functionality, so if the VGA BIOS never really implemented it correctly, it won't magically correct it.

So VGA/VESA/VBE is akin to "interfaces" in higher-level programming languages: You must implement every single function/method defined in the interface, but it does not need to have actual code, like in C# you can simply leave the default "throw new NotImplementedException()" as-is if no code within your scope would call it (that the function/method in question is not necessary for you and you alone). You cannot stop others from calling the unimplemented function/method in question, however, but it is up to the caller to handle the exception/failure.

EDIT: OSDev listed some common mistakes when it comes to VESA/VBE. It's possible some issues with some (not all) games may have stemmed from those.

Found this old thread (albeit in the DOS forum) discussing the same issue on 2017 and newer CPUs (including AMD) and basically says there are no VGA or 8-bit VBE modes supported in BIOS. A tool to dump the VBE modes supported, like PCPBENCH, would confirm that.
Given the limitations, I suspect it means the hardware doesn't support graphics modes that use a palette or bit-planes, which is pretty much everything pre-SVGA with high or true colour.

Soon this will become moot, and native booting will no longer be supported, leaving only hardware-assisted virtualization and pure software emulation as the remaining solutions for running DOS and DOS games on x86 systems:

https://www.phoronix.com/news/Intel-X86-S-64-bit-Only

It was only a matter of time before native 16-bit real mode and 32-bit protected mode would be removed from the architecture. It's actually surprising that such native support survived for this long.

digger wrote on 2023-05-21, 14:01:

Soon this will become moot, and native booting will no longer be supported

That is already the case for UEFI-only (no CSM) systems from around 2020.

jtchip wrote on 2023-05-21, 22:52:

digger wrote on 2023-05-21, 14:01:

Soon this will become moot, and native booting will no longer be supported

That is already the case for UEFI-only (no CSM) systems from around 2020.

True, but at least in theory, even non-CSM systems these days could still be switched to 16-bit real mode, 32-bit protected mode or v8086 mode, using something like TK Chia's biefircate tool, once ready. (Yes, I continue to plug this project, since it's a fascinating concept, and I believe it deserves a lot more attention and assistance.)

But once the X86-S architecture finds its way to new Intel and AMD CPUs, the era of booting bare-metal DOS natively on a PC will truly be over.