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.)