Retest of 0.12 on ASUS EN7600GS VGA BIOS Version 5.73.22.61.AS09

Nvidia kEpler/maxWell/pAscal fiX - NEWAX 0.12.á - NVIDIA mode
Nvidia kEpler/maxWell/pAscal fiX - NEWAX 0.12.á - NVIDIA mode
PCI version: 3.0
PCI specification: 017
PCI buses: 005
Original Logical Scanline Length (4F06h): Supported
Original Display Start Address/Panning (4F07h): Supported
Nvidia graphic card: Detected
NEWAX support: Incompatible Nvidia graphic card detected
PCI_ID: 10DE_0392 - Revision: A1 - SUBSYS_ID: 1043_8231
Bus number: 001 - Device: 00 - Function 0
NEWAX: Not installed

/f
Nvidia kEpler/maxWell/pAscal fiX - NEWAX 0.12.á - NVIDIA mode
Nvidia kEpler/maxWell/pAscal fiX - NEWAX 0.12.á - NVIDIA mode
NEWAX installed

I tested NEWAX 0.12 on my GeForce6200 and it did not install, as expected.

By the way, from the PCI specifications:

6.3.3.1.2. INIT Function Extensions
PC-compatible expansion ROMs contain an INIT function that is responsible for
initializing the I/O device and preparing for runtime operation. INIT functions in PCI
expansion ROMs are allowed some extended capabilities because the RAM area where
the code is located is left writable while the INIT function executes.
The INIT function can store static parameters inside its RAM area during the INIT
function. This data can then be used by the runtime BIOS or device drivers. This area of
RAM will not be writable during runtime.

Falcosoft wrote on 2026-05-23, 10:35:

BTW, SandyBridge, IvyBridge, and Haswell are the last really relevant systems in terms of native DOS VESA VBE usage since as zyzzle reported on your X-VESA topic on Broadwell/Skylake+ systems LFB write-combining and even some VGA compatibility are seriously broken.

LFB write-combining still works on Broadwell, but not on Skylake or Kaby Lake (6th and 7th/8th gen). Immediate hard system freeze on trying to enable MTRRs. I do not have anything later than Kaby Lake to test for its Intel onboard graphics, but I suspect problems get even worse on Coffee lake and above. Years ago, I tested a 2020 HP laptop which had a 10th gen Intel i5 (i5-10210u), which still had BIOS and CSM, booted to DOS baremetal, but all sub 640x480 VGA modes were eliminated from its vBIOS (Intel UHD Graphics 630 iGPU), including 320x200x8. Ridiculous, unusable in DOS, so the system was promptly returned.

Marco Pistella wrote on 2026-05-25, 15:45:

the Intel VBIOS reads the EDID during initialization […]
Show full quote

the Intel VBIOS reads the EDID during initialization

it unlocks the shadowed C000h region

it writes the EDID into the ROM shadow

then it locks the region again

This gives the VBIOS a permanent, easily accessible EDID copy in real‑mode memory.

5) Intel can do this because it is an integrated GPU
An integrated GPU knows exactly how the chipset handles shadow RAM, so it can safely:

unlock C0000h–CFFFFh

write the EDID

re‑lock the region

This avoids the need for any RAM allocation during 4F02h.

6) Therefore, when 4F02h needs EDID data, it simply reads it from the ROM shadow
No I²C access is needed during mode‑setting.
No temporary buffer is needed.
Everything is already stored in C000h.

This explains why Intel’s VBE implementation can adapt timings dynamically without touching the caller’s stack.

The above elucidation seems to that indicate an Intel Onboard vBIOS is much easier to modify on the fly than the BIOS of a dedicated video card. If the shadow RAM @ C000h can be directly modified, certainly a similar utility like NEWAX may be coded also which fixes so many of the problems / bugs / busted and eliminated code present on Skylake and above Intel VBIOses). Not sure if such a "fix" utility could be also coded to fix LFB writecombing mode on these later Intel onboard graphics. Probably not, as that is likely a BIOS issue (USB? as you conjectured before, but I tested without USB boot enabled in BIOS and system still froze on enabling LFB MTRRs for write cache combining.)

Hi,
Somewhat off-topic but I think this is still relevant in the context of newer NVIDIA cards and VESA VBE modes.
There is a lesser known utility called NVSC written by RayeR in 2009. It uses undocumented VESA VBE call 4F14h to set NVIDIA flat panel GPU scaling. When he wrote the utility he documented 3 different scaling modes that was true for NVIDIA cards at that time:

;Option "0" - NVidia GPU scaling enabled, (default mode)
; Option "1" - NVidia GPU scaling disabled, display centered
; Option "2" - NVidia GPU scaling disabled, display in uppper left corner

On more modern NVIDIA cards (tested on GTX 960/970) Option 2 is not supported but does the same as Option 1 (that is it gives a pixel perfect centered image). But accidentally I discovered that there is a new option supported by my cards.
That is:
Option "3" - Nvidia GPU scaling enabled - Keep aspect ratio!

This option is equivalent to the option offered by the Windows drivers - it gives a stretched but aspect ratio corrected image.
You should simply call "NVSC.COM 3" to get aspect ratio corrected display for all VESA and VGA graphics modes (it seems it does not work for text modes).

If I remember I also tried more number if have any meaning but I still have 4:3 LCD so didn't find this option... I'll add a note.
Does anybody tried to disassemble the vBIOS code to see what registers this VBE call sets internally?
Do we know what is the last working GPU class that has it implemented?

RayeR wrote on 2026-06-29, 13:51:

If I remember I also tried more number if have any meaning but I still have 4:3 LCD so didn't find this option... I'll add a note.
Does anybody tried to disassemble the vBIOS code to see what registers this VBE call sets internally?
Do we know what is the last working GPU class that has it implemented?

You can try "nvsc 3" and then e.g. FALSSAN3.EXE with 1280x1024 resolution since it has 5:4 aspect ratio so it should have small margin bars on the left and right side even on your 4:3 LCD.
BTW, I have also tested NVSC on my Geforce 6600 and on this GPU Option 1 and Option 2 is fully supported (Option 2 really displays a pixel perfect image in the uppper left corner) but the newly discovered Option 3 is not (it bahaves the same way as Option 0).

Falcosoft wrote on 2026-05-23, 15:07:

Here is another fix for SandyBridge, IvyBridge, and Haswell integrated GFX systems:

In case of some programs that use VESA VBE modes with 8-bit DAC on returning to text mode you can get a dark/faint screen and seemingly only a restart can help. It's because according to specification returning from VBE mode the DAC should be set to default state but Intel integrated GFX does not do this. So if the program does not reset the DAC to 6-bit on exit you get this dark/faint screen. The above little utility resets the DAC so you can get back the normal/brighter screen.

Thanks for coding RESETDAC. Works perfectly and solves an annoying problem.