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.

zyzzle wrote on 2026-07-02, 22:56:

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.

1. FYI, RESETDAC has been integrated into IGVBEFIX and this way the DAC reset is called automatically when such problematic programs return to text mode.
Besides this IGVBEFIX provides the following solutions mainly for Intel HD graphics:

2. It implements an emulated 100h - 640x400 8-bit VESA mode that some app require but Intel HD graphics does not support. It is a fake mode so it's not perfect. Actually it uses mode 101h - 640x480 8-bit instead so the last 80 lines will be missing from the picture. But at least programs that require mode 100h at least can start.

3. Intel HD graphics does not support the integrated VSYNC feature of VESA 2.0 page flipping functions. IGVBEFIX adds VSYNC support for VESA 2.0 video modes.
Marco Pistella reported that the previous VSYNCFIX froze on Skylake+. This version contains a mitigation so it should not freeze. But feedback is welcome since I could not test this on Skylake+.

It can be downloaded from here:
download/file.php?id=247717

Back to Nvidia Maxwell 😀
Since my 1 month trial period with ChatGPT will have been finished in 2 days I thought that after my T430 reverse engineering adventures with ChatGPT it's time to concentrate a little on my Maxwell GPU.
Here is the result: NV43Fix. It is based on the idea of 'NVSC 3', the newly discovered parameter that enables aspect ratio corrected output on digital flat panels (at least) in case of Maxwell.
While Nvidia's aspect ratio correction algorithm is mathematically correct historically it is not. That is it works correctly with classic 4:3 resolutions like 640x480, 800x600, 1024x768 but it does not work correctly with non-square pixel resolutions like 320x200 or 640x400. It treats 320x200 and 640x400 as real 16:10 resolutions. This is also true for 720x400 text modes. So on a 16:9 display you still get a too wide projection even if the 'NVSC 3' command sets aspect ratio corrected projection.

NV43Fix solves this problem a rather simple way: regardless of the source resolution it always projects all video modes to (4/3 * max panel height) x (max panel height) resolution. Examples:
1920x1080 -> 1440x1080
1680x1050 -> 1400x1050
1600x900 -> 1200x900

Important: This is not a TSR but a one shot utility. It patches the aspect ratio correction code in the memory image of the Nvidia BIOS. Unfortunately the BIOS image is read-only by default and there is no universal and vendor independent way that can make it (temporarily) writable. Currently 2 methods are supported: an Intel one and an AMD one. The Intel version should work at least from Sandy Bridge to Broadwell and the AMD version should work from K8 to Bulldozer. As for GPUs it should work where 'NVSC 3' works.
But really only the following configurations were tested by me: Intel i7-4770k + GTX 970 and AMD Phenom II x4 960 + GTX 960.
So user feedback is welcome.

I know that unlike notebook LCDs most desktop monitors have either automatic or manual aspect ratio selection but there can be problems with this:
1. Over digital connection modern NVidia GPUs project all video modes to the native mode of the digital panel. So the automatic aspect ratio correction of the monitor cannot even detect that a video mode change happened.
2. On monitors where manual aspect ratio selection is available the corresponding menu item can be reached with at least 5+ button presses 😀

I do think that NV43FIX as a solution to this problem is more convenient (at least it is for me).