The one system that I own which has a Ryzen 2500 processor with AMD Vega integrated graphics is totally broken in DOS.

No 8-bit display modes are supported at all VESA resolutions in DOS. There are VESA modes present but they only support 32-bit planar modes. No VGA modes are supported at all (320x200x8, 320x240x8, etc), although text mode does display (720x400). Why the AMD Vega Internal graphics would be so castrated to exclude ALL 8-bit display modes is totally baffeling.

MTRRLFBE works on the system, and linear framebuffer write-back cache combining is supported. This yield a super speedup for the supported VESA 32-bit modes.

This graphics on this system in baremetal DOS are so severely defective that simple CGA games like Alley Cat don't even work (320x200 mode is not supported!).

Any tool or utility that might fix these issues would be appreciated indeed. I found a "Fake VGA" TSR which does allow Quickview 2.61 to play .mp4 films with sound. SBEmu is supported wonderfully. The fake VGA utility allows quickview to "see" the advanced 32-bit mode VESA resolutions and therefore play the videos. Previously, it had reported "VGA is required to run Quickview."

However, "Fake VGA" does not magically enable any 8-bit VGA modes for other programs, nor does Vbefast 0.81 work, nor Scitech's UniVBE. Because of the lack of 8-bit VGA modes, the system is basically useless for any DOS games on baremetal. No sub 640x480 video modes work.

Got some vague ideas about CGA and other screenmode emulators for VGA, gonna let that percolate overnight see if the faint wisps of something back in the dusty depths of noggin firm up any.

1st and 2nd gen Ryzen supposed to have some serious deficiencies in 16bit that were corrected in 3rd gen, not sure there were workarounds, full machine emulation might be the only way out.

RetroMaster137 wrote on 2024-09-06, 02:21:

What I do know but couldn't quote at the moment, is that misc display mode(s) and/or lower resolutions such as 320x200 are "emulation" and/or similar, i.e. the system would output 640x400 instead (?)

Weren't 320x200 and such always emulated on VGA by double scanning, such that 320x200 is actually output as 320x400? Maybe it just means the same thing.

RetroMaster137 wrote on 2024-09-06, 02:21:

Hello, I've investigated a bit, but I need yet to learn more and more documents, so I bet I'm very wrong on many things.
My integrated GPU is a Radeon HD 8570d, "northern islands", TeraScale 3, as part of the A8-6600k APU. I've been told that VBE compatibility's cutline (before getting broken or just non-existant) happens at successor, "southern islands" instead, so I guess I'm safe, even though it's a pretty late "northern islands" release.

That document would be AMD Application Note 55145 1.00 "Removal of Default VBE 8-bpp Graphics Mode Support in VBIOS".

Basically:

1. Non-VGA 8bpp graphics modes are no longer provided by the video BIOS, i.e. via VBE (VESA BIOS Extensions), for Radeon HD 7000/7000M
2. Physical support for this mode is also expected to be removed at the hardware level

The first point means the VBE no longer returns 8bpp modes in its list of support modes and hence cannot set it either, regardless of VBE version. Going by model number alone, your HD 8570D would appear to be covered by that restriction. HD 7000 even includes GPUs from Terascale 2 (Evergreen).

Some background: hardware devices, including GPUs, are usually programmed through a register interface, whether over port I/O or MMIO (memory-mapped I/O). Higher-level APIs can provide functions for operations such as getting the list of supported video modes and setting that video mode. On DOS, this is provided by VBE for video modes beyond VGA. VBE is implemented by the video BIOS supplied with the GPU or by TSRs such as UniVBE. UniVBE needs to be able to program each GPU at register level which is why it does not work with GPUs launched after its last version.

If the underlying hardware still supports 8bpp video modes, then a "modern-day UniVBE" TSR could implement support for it. It will need to program each supported GPU at register-level and such modesetting code is available in Linux and the BSDs.

zyzzle wrote on 2024-09-06, 02:38:

The one system that I own which has a Ryzen 2500 processor with AMD Vega integrated graphics is totally broken in DOS.

No 8-bit display modes are supported at all VESA resolutions in DOS. There are VESA modes present but they only support 32-bit planar modes. No VGA modes are supported at all (320x200x8, 320x240x8, etc), although text mode does display (720x400). Why the AMD Vega Internal graphics would be so castrated to exclude ALL 8-bit display modes is totally baffeling.

That would suggest AMD may have physically removed 8bpp modes altogether on newer GPUs. The TSR would then need to set a 24/32bpp video mode instead but expose an 8bpp shadow framebuffer, perhaps in host memory, then at each vsync interval look up the real colour in the pallete and copy that to the 24/32bpp framebuffer in video memory. This is similar to how CGA emulators for HGC worked.

As to why, it's probably a matter of cost. Removing 8bpp paletted modes means saving some silicon and the need for testing what is a little-used feature by modern software.

RetroMaster137 wrote on 2024-09-06, 02:21:

On the other hand, CGA. I have been told "no MC6845 registers", but I gave CGA_COMP a try and it sure looks like it; to put it simple, not a single color change test worked, nor h-sync stuff, but everything else apparently did though. If I'm not mistaken, the main culprit is not being able to freely set H/V timings (resolutions?), instead relying on whatever the system offers from a table (correct?). Alley Cat works fine and manages to change the palette when I enter some rooms, my other CGA games also seem to work fine as well (I don't have many to be honest) so it's all very confusing.

Emulating CGA has a different set of issues. Alley Cat works because it uses BIOS routines (software int 10h) to set video modes and palettes, and later EGA/VGA/SVGA video BIOSes are still backwards compatible with CGA in that respect.

Some CGA titles program the CGA at register level. To emulate that, you'd need to trap the IO to those ports and emulate it (probably using a shadow framebuffer as well), similar to how SBEMU works. EGA and newer graphics adapters are already not fully register-compatible with CGA.

Azarien wrote on 2024-09-06, 14:38:

RetroMaster137 wrote on 2024-09-06, 02:21:

What I do know but couldn't quote at the moment, is that misc display mode(s) and/or lower resolutions such as 320x200 are "emulation" and/or similar, i.e. the system would output 640x400 instead (?)

Weren't 320x200 and such always emulated on VGA by double scanning, such that 320x200 is actually output as 320x400? Maybe it just means the same thing.

Double-scanning is handled at the scanout layer, basically to get the horizontal scanning rate to a range compatible with VGA monitors (31.5kHz). It is essentially transparent to software, which still sees a 320x200/240 framebuffer.

RetroMaster137 wrote on 2024-09-06, 02:21:

For context,
I cannot imagine any other reason why Scitech Display Doctor's VBETEST (for DOS, tested under FreeDOS on USB for now) couldn't set "640x480x256 mode"; there's no other options to test whatsoever (every menu is blank), and much other software faces similar issues, i.e. Kgen98 couldn't set 640x480 16bit. Is it a "if(version >= 2)" vs "if(version != 2)" problem, or are big changes involved? X-VESA can display these just fine though, the lowest resolutions possible there are 640x400 and 640x480, at 8/16/32 bit; some modes do report "Hardware compatible - Yes / Bios compatible - No", I don't know what that means.
UniVBE (DOS) itself doesn't boot and displays an "out of memory" error, but I don't know if that's fault of FreeDOS, or me not setting up EMS yet, or something else (I'll try EMS or other options later when possible).

I think when it comes to mode lists and some other functionalities, ATI/AMD cards behave very differently compared to nVidia ones.

Something I observed with a FirePro V3900 (Northern Islands):
1. VBETEST cannot test it (all modes empty).
2. VBEMP on NT 3.51 only allows basic resolutions like 640x480, 800x600, 1024x768 and 1280x1024. No other resolutions (e.g. 1280x800) can be selected compared to nVidia cards of similar generations.

The first issue seems to affect all new AMD video cards AFAIK, while the second issue may be affected by both the card's generation as well as the connected monitor's capabilities. With newer generations of AMD video cards (e.g. Polaris), legacy VGA capabilities indeed get worse but I can in turn select some more resolutions with VBEMP, including the one native to my current monitor (that would be 3840x2160).

VGA functionality on older generation AMD cards do work okay, though it may behave a bit glitchy in some cases.

There's a horizontal shooting game called Firewind which used some complex VGA functions that did not appear to work with nVidia cards of similar generations -- only menus work, and I only get a black screen when in-game (unplayable).

On the aforementioned AMD card (FirePro V3900) the game is fully playable, but in-game graphics have some flawed palette colors (e.g. white becomes black) that I'd love to know if there's any way to fix it somehow...

EDIT: It seems Southern Islands (GCN1) cards may still be okay for most use cases. After replacing the FirePro V3900 on that system with a W4100 (Cape Verde) I can now set VBEMP resolution to the native ones, and from whatever DOS games I'm running on that system I don't see any noticeable difference -- pretty much the same if not worse. Perhaps the issue with resolution options was simply that my monitor don't appear to work well with cards that do DP 1.1 output, and only those with DP 1.2 and newer work okay with my monitor...