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

Falcosoft wrote on 2026-05-13, 10:36:

@Marco Pistella: […]
Show full quote

@Marco Pistella:

BTW, if we are talking about more generic Nvidia VESA Bios fixes: there is a long standing problem. According to VBE 3 specification there is the possibility to define the CRTC timings (CRTCInfoBlock struct) and load them together with a mode set with the help of function 4F02h (Set VBE Mode). Up until Geforce 4 (5?) Nvidia supported this extension and it worked perfectly. There was a DOS TSR (Unirefresh) that could be used to define at what refresh rate the different VESA modes should run.
But from (at least) Geforce 6 this function never worked anymore. Maybe it was the 1st sign that Nvidia was not going to add further VESA VBE features anymore but rather remove them.
This extension would be useful on CRT monitors where the high resolution VESA modes on BIOS default 60 Hz can present painful flickering.

I think if someone can restore this functionality, that someone is you 😀

This is not strictly related to the topic but since it was mentioned in some posts like the above quoted:

NVCRTC 1.0

NVCRTC is a pair of DOS utilities that restores VBE 3.0 custom refresh-rate control on NVIDIA NV4x/Curie video cards (Geforce 6/7 series) whose video BIOS reports the feature but does not actually apply the requested CRTC timing.

The package contains two versions:

NVCRTC.COM - for plain real-mode DOS.
NVCRTCD.COM - for V86 environments such as JEMM386/JEMMEX with a resident 32-bit DPMI host such as HDPMI32.

Both versions fix the same standard VBE 3.0 interface. Programs that already use VBE 3.0 custom CRTC mode setting can use the fix directly. Older VBE 1.x/2.x programs can also benefit when a utility such as UniRefresh intercepts their mode changes and issues VBE 3.0 refresh requests for them.

The utilities actually were only tested on a Geforce 6600 AGP so feedback is welcome.

There is also a GitHub repo:
https://github.com/Falcosoft/NVCRTC

Nice, I moved to LCD since ~10 years, but anyway...
Still have one PC with GF 7600GS so I tested it and it worked. I used VBEHz TSR as I had it still installed from old times. It set 1280x1024 from 60 to 72Hz.

NVCRTC 1.0 - NVIDIA NV4x VBE 3.0 custom CRTC fix
Resident status:
NVIDIA BAR0 = FA000000
NV chipset = 4B
Reference crystal = 27000 kHz
Custom CRTC requests = 1
Successfully applied = 1
Failed/skipped = 0
Last BX mode/flags = 491B
Last BIOS AX return = 004F
Last result code = 01
Last analog CRTC = 00
Last H total/start/end = 1728/1352/1504
Last V total/start/end = 1066/1025/1028
Last CRTC flags = 00
Requested pixel clock= 132627456 Hz
Requested VFreq = 72.00 Hz
Calculated VFreq = 72.02 Hz
Programmed clock = 132667 kHz

RayeR wrote on 2026-11-08, 21:19:

Nice, I moved to LCD since ~10 years, but anyway... Still have one PC with GF 7600GS so I tested it and it worked. I used VBEHz […]
Show full quote

Nice, I moved to LCD since ~10 years, but anyway...
Still have one PC with GF 7600GS so I tested it and it worked. I used VBEHz TSR as I had it still installed from old times. It set 1280x1024 from 60 to 72Hz.

NVCRTC 1.0 - NVIDIA NV4x VBE 3.0 custom CRTC fix
Resident status:
NVIDIA BAR0 = FA000000
NV chipset = 4B
Reference crystal = 27000 kHz
Custom CRTC requests = 1
Successfully applied = 1
Failed/skipped = 0
Last BX mode/flags = 491B
Last BIOS AX return = 004F
Last result code = 01
Last analog CRTC = 00
Last H total/start/end = 1728/1352/1504
Last V total/start/end = 1066/1025/1028
Last CRTC flags = 00
Requested pixel clock= 132627456 Hz
Requested VFreq = 72.00 Hz
Calculated VFreq = 72.02 Hz
Programmed clock = 132667 kHz

Thanks for testing, it's great that it really works on a Geforce 7. I would add at least Geforce 5 support as well since I think that was the 1st generation where the VBE 3 CRTC part was broken but unfortunately I have no card anymore to test with...

Bravo! I checked it, and it works great on the G70 (in MS-DOS mode only). With any of these TSRs, the frequency adjustment is restored and works just as well as it did before on the NV30. After Windows starts, the TSR temporarily stops working and resumes only after switching to MS-DOS mode (basically, on the NV30, UniRefresh also works on Windows, together with VESA DOS programs). DVI also effectively works in the same way (although one minor error was found). In any case, thank you very much! This is one of the most challenging puzzles in the world of retro computers, and for a very long time, no one managed to solve it. And yes, you’re right - problems with this were already detected in later FX and PCX series cards. Also, even many FX5600/PCX5300 units already required a vBIOS firmware replacement to restore this function. This was already useless for the FX5950\PCX5900, as no working firmware for these cards was found (I personally checked about 200 of them).

DoZator wrote on Today, 12:08:

Bravo! I checked it, and it works great on the G70 (in MS-DOS mode only). With any of these TSRs, the frequency adjustment is restored and works just as well as it did before on the NV30. After Windows starts, the TSR temporarily stops working and resumes only after switching to MS-DOS mode (basically, on the NV30, UniRefresh also works on Windows, together with VESA DOS programs). DVI also effectively works in the same way (although one minor error was found). In any case, thank you very much! This is one of the most challenging puzzles in the world of retro computers, and for a very long time, no one managed to solve it. And yes, you’re right - problems with this were already detected in later FX and PCX series cards. Also, even many FX5600/PCX5300 units already required a vBIOS firmware replacement to restore this function. This was already useless for the FX5950\PCX5900, as no working firmware for these cards was found (I personally checked about 200 of them).

Hi!
Yep, it cannot work in Windows since the TSR sets the necessary CRTC registers directly that is not allowed under Windows.
To do this NVCRTC has to do its direct CR0/protected-mode transition which is only valid in true real mode.
NVCRTCD works a bit differently (it does not want to switch into protected mode itself) but it also changes the physical CRTC and VPLL directly. This is not a good idea under Windows because the Windows display driver/VDD may have a different saved/virtualized view of the hardware and can overwrite our settings, produce display corruption or simply crash...

Unfortunately this solution is not a BIOS restoration solution since in the buggy BIOSes the CRTC setting part is simply a nop (no operation) but a re-implementation. In the buggy BIOSes there is not enough room to place the new code. That's why it had to be implemented as a TSR together with the limitations..

Falcosoft wrote on Today, 12:41:

Unfortunately this solution is not a BIOS restoration solution since in the buggy BIOSes the CRTC setting part is simply a nop (no operation) but a re-implementation. In the buggy BIOSes there is not enough room to place the new code. That's why it had to be implemented as a TSR together with the limitations..

I was just thinking about this and wanted to suggest trying to create a universal patcher for the vBIOS based on this fix, so that no TSR would be required at all and it would work everywhere and always (just like NV30). But now it’s clear what the catch is. If new ideas emerge on how to free up space or place this code differently, I’m ready to test these experimental firmware on GeForce 7 for as long as needed (By booting from a neighboring PCI card, I can freely flash any test firmware onto the target card without the slightest risk). Even if nothing works out, it’s still incredibly awesome, even just the way it is now! And it’s already quite usable 😀