My question is: do any of you with older Nvidia hardware experience VESA-related issues with DOS applications — for example with VBETEST.EXE or other VESA tools — that might benefit from NEWAX's additional fixes?

Hi,
Yes, I think it's somewhat unfair that currently the more buggy Kepler/Maxwell/Pascal cards with NEWAX loaded have a better VESA VBE implementation than older less buggy cards. 😀
E.g. my Geforce 6600 AGP is definitely affected by the function 4F06h related falsely reported scanlines /4 MB limit problem.

@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 😀

Hi,
I'm getting an error with VBETEST 6.53 when I run this test:
0 - Interactive
5 - 32bits per pixel
0 - 320x200x32
0 - Bios Default
1 - Linear Framebuffer
With NEWAX resident, after the multi buffering test I get an error message saying: "Your Program caused a divide overflow error. If the problem persists, contact your program vendor."
Without NEWAX, VBETEST does not even try to run the virtual resolution test. The problem seems limited to this lower resolution, it works fine in others.

Hello everyone,

I am pleased to announce NEWAX version 0.9, with the following changes:

- Added /F switch (Force installation, bypasses the 4F07h working check — use with caution)
- Improved behavior of 4F07h handler: unknown or unmanaged calls are now transparently passed to the BIOS instead of returning a failure code
- NEWAX now attempts installation even on cards where 4F06h is absent — use with extreme caution, behaviour in this case is currently undocumented

The updated binary is attached to this post.

---

On the performance side, some precise measurements on a GT550Ti / Intel Core i3-4170T:

- 4F07h BL=00h (Set Display Start Address, no retrace wait) via VBIOS: 2197 PIT cycles
- 4F07h BL=00h via NEWAX (direct CRTC register writes): 0 PIT cycles

The VBIOS overhead is entirely eliminated for BL=00h. For BL=80h (set during retrace), both the VBIOS and NEWAX must wait for the retrace signal via port 3DAh/3BAh polling, so the timing difference in that case is negligible.

For applications that call 4F07h BL=00h continuously — scrolling, page flipping, animation without retrace sync — the improvement is a measurable real-world difference.

---

Looking ahead, before NEWAX moves to beta release the following work is planned:

1. A reliable Nvidia-specific detection method, independent of VBIOS signatures, to ensure /F is safe to use without risking interference on non-Nvidia hardware.

2. A systematic compatibility map across Nvidia cards, covering four categories:
- Cards with both 4F06h and 4F07h functional
- Cards with 4F06h functional but 4F07h broken (current primary target)
- Cards with neither 4F06h nor 4F07h functional
- In all cases: card model, tested software, and any issues observed

Once this map is complete and the results are consistent, NEWAX will move to beta.

If you have Nvidia hardware available for testing — especially older cards from the GeForce 6/7 era or earlier — your contribution would be very valuable at this stage.

Thank you as always.

Marco

@Falcosoft

Thank you for the suggestion and the kind words. The CRTCInfoBlock extension would indeed be very useful for CRT users, and restoring it is technically feasible in principle — intercept 4F02h with bit 11, pass the standard mode set to the BIOS, then program the CRTC registers from the block. The real obstacle is the pixel clock: without reprogramming the Nvidia PLL for the correct PixelClock value, the refresh rate cannot actually change. PLL programming on Nvidia is undocumented, generation-specific, and would require days of remote debugging via serial with Turbo Debugger on dedicated AGP hardware. The investment is too high relative to the benefit at this stage. It stays on the long-term list, but I would not want to promise something I cannot deliver in a reasonable timeframe.

P.S. Quick test report: FALSSANI.EXE on GT550Ti — without NEWAX, image corrupted above the 4MB boundary; with NEWAX loaded, image correct across the full VRAM range. The 4F06h fix is confirmed working on this card.

@EduBat

Try new version 0.8 or 0.9 (limit pages)

Marco Pistella wrote on 2026-05-13, 11:24:

Try new version 0.8 or 0.9 (limit pages)

When I limit pages on the GTX650, VBETEST no longer tries to do the double buffering and the virtual resolution tests.
But, there's another interesting fact, on the GeForce 6200 VBETEST crashes on the same 320x200x32 resolution even without NEWAX installed. This is most likely a VBETEST bug, not related to NEWAX at all.

The GeForce 6200 supports function 4F07h in the VBIOS so, strictly speaking NEWAX is not needed.
Without NEWAX, using X-VESA beta5, I get a garbled screen on mode 0130h (320x200x8) virtual resolution test with horizontal resolution 0f 4088.
With NEWAX I get a DIV/INT0 error on the same test.

Falcosoft wrote on 2026-05-13, 06:40:

And you still have not experienced the slowdown in the menu when vid_nopageflip is "0" and NEWMAX is loaded?

Not much visible, without NEWAX it's really slow, a few FPS and with NEWAX seems smooth. I can film a short video. If I test without LFB-WC it looks even worse without NEWAX and still OK with NEWAX..

I used Unirefresh/VBEHz last time on my GF440MX AGP with 17" CRT and also noticed that CRTC refresh settings was removed but as I moved to LCD I didn't care anymore. I think this could be added as optional feature (command line switch) to load some function from older NV BIOS where it was fully implemented but probably need to check first if it would work on newer GPUs (related registers still exist and do what they should).

Did a test with NEWAX 0.9 on my RTX A4000 (Ampere, neither 4F06h nor 4F07h works there).

- Need to use /F argument to force install.
- VBEVSTST (for 4F07h) works after installing NEWAX.
- FALSSANI works with no apparent artifacts. Didn't test it previously, as it apparently can't work when I had JEMMEX/JEMM386 loaded.
- X-VESA dual page test works and reports both VGA and VESA retrace available.
- X-VESA virtual resolution test doesn't work, reporting get/set logical scanline length not supported. So this test needs working 4F06h.

On the other hand, the VESA mode table on Ampere is very limited compared to older generations. Many resolutions were absent according to X-VESA.

It only reported support for 640x480, 800x600, 1024x768, 1280x1024 and 1600x1200 at all bit depths, plus 1360x768 and 1920x1080 at only 24/32 bit depth.

No other resolutions available. With Quadro K6000 (Kepler), however, pretty much all VESA resolutions from as low as 320x200x8 are available.

Thanks to Marco to crunch some VBE bugs that nV cards suffered for many years...
Please could you look at another one that I'm experienced since GTX670 in some DOS utilities in graphics mode like Symantec Partition Editor? Can other users confirm this on another GPUs than 670/970?
Here you can download it for testing: http://rayer.g6.cz/1tmp/ptedit.exe
See that small artifacts in the image, esp. when roll-down the drive menu. It's not affected by NEWAX. I'm not sure what videomode this program use but seems to be something like 800x600/8 or 4bbp.
Also there's some font issues in games like Keen IV:
http://rayer.g6.cz/hardware/gtx670.htm#NVBIOS_BUG

RayeR wrote on 2026-05-13, 16:12:

Thanks to Marco to crunch some VBE bugs that nV cards suffered for many years... Please could you look at another one that I'm e […]
Show full quote

Thanks to Marco to crunch some VBE bugs that nV cards suffered for many years...
Please could you look at another one that I'm experienced since GTX670 in some DOS utilities in graphics mode like Symantec Partition Editor? Can other users confirm this on another GPUs than 670/970?
Here you can download it for testing: http://rayer.g6.cz/1tmp/ptedit.exe
See that small artifacts in the image, esp. when roll-down the drive menu. It's not affected by NEWAX. I'm not sure what videomode this program use but seems to be something like 800x600/8 or 4bbp.
Also there's some font issues in games like Keen IV:
http://rayer.g6.cz/hardware/gtx670.htm#NVBIOS_BUG

You’re absolutely right about this issue — I’ve seen it many times as well, and it’s not related to VESA at all.
This glitch comes from the VGA latch registers and from the fact that many DOS programs rely on a non‑documented VGA CRTC register, specifically CRTC index 22h, which on the original IBM VGA allows reading back the internal latch contents in planar modes.

This register was never part of the official VGA documentation, but a lot of DOS software uses it to read the latch state when working in planar 4bpp modes (like 640×480×16 or 800×600×16).
Unfortunately, modern Nvidia cards no longer implement this undocumented register, and as a result the read‑modify‑write logic breaks, producing exactly the kind of artifacts you’re seeing in PTEDIT and in games like Keen IV.

Since this is a VGA‑level hardware emulation issue, not a VESA BIOS issue, NEWAX cannot fix it — NEWAX only hooks INT 10h VESA functions (4Fxxh), not the VGA sequencer/graphics controller pipeline.

I’ll investigate whether a VGA‑level workaround is feasible, but it would require intercepting and emulating latch behavior in software, which is far more complex than patching VESA functions.

Thanks for explanation. Oh, yes it maybe just standard VGA 640x480/4 or 800x600/4...

So possible solution would be:
1) find a way how to correctly do the drawing without touching CRTC 22h (I'm not familiar with using this modes and what the latch register really do)
2) patch the affected binaries
3) or use JEMM386/QPIEMU/HDPMI for port trapping like in SBEMU/VSBHDA to intercept port 22h access and handle it different way

RayeR wrote on 2026-05-13, 16:12:

Thanks to Marco to crunch some VBE bugs that nV cards suffered for many years... Please could you look at another one that I'm e […]
Show full quote

Thanks to Marco to crunch some VBE bugs that nV cards suffered for many years...
Please could you look at another one that I'm experienced since GTX670 in some DOS utilities in graphics mode like Symantec Partition Editor? Can other users confirm this on another GPUs than 670/970?
Here you can download it for testing: http://rayer.g6.cz/1tmp/ptedit.exe
See that small artifacts in the image, esp. when roll-down the drive menu. It's not affected by NEWAX. I'm not sure what videomode this program use but seems to be something like 800x600/8 or 4bbp.
Also there's some font issues in games like Keen IV:
http://rayer.g6.cz/hardware/gtx670.htm#NVBIOS_BUG

I have the same artifacts in ptedit on my GTX650.
On the GeForce 6200 it's all fine.

EduBat wrote on 2026-05-13, 16:58:

I have the same artifacts in ptedit on my GTX650.
On the GeForce 6200 it's all fine.

Need to test somewhere between GTX2xx - 5xx where it probably breaks. I have GTX240 stored somewhere...

Marco Pistella wrote on 2026-05-13, 16:28:

You’re absolutely right about this issue — I’ve seen it many times as well, and it’s not related to VESA at all. This glitch com […]
Show full quote

RayeR wrote on 2026-05-13, 16:12:

Thanks to Marco to crunch some VBE bugs that nV cards suffered for many years... Please could you look at another one that I'm e […]
Show full quote

Thanks to Marco to crunch some VBE bugs that nV cards suffered for many years...
Please could you look at another one that I'm experienced since GTX670 in some DOS utilities in graphics mode like Symantec Partition Editor? Can other users confirm this on another GPUs than 670/970?
Here you can download it for testing: http://rayer.g6.cz/1tmp/ptedit.exe
See that small artifacts in the image, esp. when roll-down the drive menu. It's not affected by NEWAX. I'm not sure what videomode this program use but seems to be something like 800x600/8 or 4bbp.
Also there's some font issues in games like Keen IV:
http://rayer.g6.cz/hardware/gtx670.htm#NVBIOS_BUG

You’re absolutely right about this issue — I’ve seen it many times as well, and it’s not related to VESA at all.
This glitch comes from the VGA latch registers and from the fact that many DOS programs rely on a non‑documented VGA CRTC register, specifically CRTC index 22h, which on the original IBM VGA allows reading back the internal latch contents in planar modes.

This register was never part of the official VGA documentation, but a lot of DOS software uses it to read the latch state when working in planar 4bpp modes (like 640×480×16 or 800×600×16).
Unfortunately, modern Nvidia cards no longer implement this undocumented register, and as a result the read‑modify‑write logic breaks, producing exactly the kind of artifacts you’re seeing in PTEDIT and in games like Keen IV.

Since this is a VGA‑level hardware emulation issue, not a VESA BIOS issue, NEWAX cannot fix it — NEWAX only hooks INT 10h VESA functions (4Fxxh), not the VGA sequencer/graphics controller pipeline.

I’ll investigate whether a VGA‑level workaround is feasible, but it would require intercepting and emulating latch behavior in software, which is far more complex than patching VESA functions.

On my active Kepler system with Quadro K6000 using BIOS 80.80.35.00.06, that I'm testing NEWAX and X-VESA with, this issue somehow doesn't manifest in EGA games. Fonts in BioMenace and Duke Nukem 1 both work fine there.

I've another spare Quadro K6000 with a different BIOS version and on that one I have this font issue with EGA games, namely fonts in the aforementioned games are not being rendered at all. When I have time I'll inspect the detail of the issue as well as trying to flash that one's BIOS to see if it makes any difference... it can be risky, however.

I recall seeing this font artifact issue with Quadro 2000 (Fermi) as well, but I don't have the environment to test it at the moment.

On the other hand, the same EGA games work fine with Southern Island cards (AMD counterpart of Kepler). However, VESA functionality on AMD SI has some quirks:
- 320x200x8 mode is absent. Only 16/24/32 modes available for that particular resolution.
- No resolutions show up in the list in VBETEST 6.53 for detailed testing.
- When I run VBEVSTST nothing shows up and I can only press ESC to return to DOS.
- With video modes I've tested (only a few), X-VESA reports VESA retrace not available, only VGA retrace.
- Virtual resolution works correctly.
- 8-bit gradient doesn't work. When testing with X-VESA, nothing happens when switching from 6-bit to 8-bit (still showing 4 gradients instead of one).

Though be warned, from my experience, Kepler and SI are the last generations of respective vendors to have mostly proper VGA (not VESA) functionality. Subsequent generations are breaking VGA functionality one by one.

Quick update: NEWAX is now available on GitHub with full source code under MIT license.
https://github.com/Marco-Pistella/NEWAX
Includes NEWAX.ASM, CONST.INC, STRUCT.INC and the compiled NEWAX.COM binary.

LSS10999 wrote on Yesterday, 02:56:

On my active Kepler system with Quadro K6000 using BIOS 80.80.35.00.06, that I'm testing NEWAX and X-VESA with, this issue someh […]
Show full quote

Marco Pistella wrote on 2026-05-13, 16:28:

You’re absolutely right about this issue — I’ve seen it many times as well, and it’s not related to VESA at all. This glitch com […]
Show full quote

RayeR wrote on 2026-05-13, 16:12:

Thanks to Marco to crunch some VBE bugs that nV cards suffered for many years... Please could you look at another one that I'm e […]
Show full quote

Thanks to Marco to crunch some VBE bugs that nV cards suffered for many years...
Please could you look at another one that I'm experienced since GTX670 in some DOS utilities in graphics mode like Symantec Partition Editor? Can other users confirm this on another GPUs than 670/970?
Here you can download it for testing: http://rayer.g6.cz/1tmp/ptedit.exe
See that small artifacts in the image, esp. when roll-down the drive menu. It's not affected by NEWAX. I'm not sure what videomode this program use but seems to be something like 800x600/8 or 4bbp.
Also there's some font issues in games like Keen IV:
http://rayer.g6.cz/hardware/gtx670.htm#NVBIOS_BUG

You’re absolutely right about this issue — I’ve seen it many times as well, and it’s not related to VESA at all.
This glitch comes from the VGA latch registers and from the fact that many DOS programs rely on a non‑documented VGA CRTC register, specifically CRTC index 22h, which on the original IBM VGA allows reading back the internal latch contents in planar modes.

This register was never part of the official VGA documentation, but a lot of DOS software uses it to read the latch state when working in planar 4bpp modes (like 640×480×16 or 800×600×16).
Unfortunately, modern Nvidia cards no longer implement this undocumented register, and as a result the read‑modify‑write logic breaks, producing exactly the kind of artifacts you’re seeing in PTEDIT and in games like Keen IV.

Since this is a VGA‑level hardware emulation issue, not a VESA BIOS issue, NEWAX cannot fix it — NEWAX only hooks INT 10h VESA functions (4Fxxh), not the VGA sequencer/graphics controller pipeline.

I’ll investigate whether a VGA‑level workaround is feasible, but it would require intercepting and emulating latch behavior in software, which is far more complex than patching VESA functions.

On my active Kepler system with Quadro K6000 using BIOS 80.80.35.00.06, that I'm testing NEWAX and X-VESA with, this issue somehow doesn't manifest in EGA games. Fonts in BioMenace and Duke Nukem 1 both work fine there.

I've another spare Quadro K6000 with a different BIOS version and on that one I have this font issue with EGA games, namely fonts in the aforementioned games are not being rendered at all. When I have time I'll inspect the detail of the issue as well as trying to flash that one's BIOS to see if it makes any difference... it can be risky, however.

I recall seeing this font artifact issue with Quadro 2000 (Fermi) as well, but I don't have the environment to test it at the moment.

On the other hand, the same EGA games work fine with Southern Island cards (AMD counterpart of Kepler). However, VESA functionality on AMD SI has some quirks:
- 320x200x8 mode is absent. Only 16/24/32 modes available for that particular resolution.
- No resolutions show up in the list in VBETEST 6.53 for detailed testing.
- When I run VBEVSTST nothing shows up and I can only press ESC to return to DOS.
- With video modes I've tested (only a few), X-VESA reports VESA retrace not available, only VGA retrace.
- Virtual resolution works correctly.
- 8-bit gradient doesn't work. When testing with X-VESA, nothing happens when switching from 6-bit to 8-bit (still showing 4 gradients instead of one).

Though be warned, from my experience, Kepler and SI are the last generations of respective vendors to have mostly proper VGA (not VESA) functionality. Subsequent generations are breaking VGA functionality one by one.

I did a test on the spare K6000. It had 80.80.63.00.01. As I performed tests it seems the issue turned out to be more complicated than I thought.

Fonts in BioMenace and Duke Nukem 1 are okay in this environment, but the game certainly have some glitches like some unexpected (opaque) backgrounds under text as well as ingame tiles (characters).

Downgrading it to an older VBIOS like the one dumped from my active card (80.80.35.00.06) somehow resulted in the monitor I'm using for the test getting a lower resolution (640x480 compared to 1920x1200), and it produced even more glitches in this state. Perhaps the older VBIOS versions have issues with that system's UEFI environment. Eventually I flashed it back to a newer one, 80.80.63.00.08, which restored the usual output resolution for the monitor, though glitches still persist.

I'm using a DVI-to-HDMI connection for that system. In the end I think the issue manifests depending on the connection as well as active resolution (according to the monitor's OSD) used for outputting VGA. The system environment (BIOS or UEFI-CSM behaviors) may also affect this. For these 16-color modes, in some setups things might look good while in other setups things can end up in a mess.

New discovery: Nvidia extended register for offset (CRTC index 3Bh)

After an extensive reverse‑engineering session on the Nvidia VBIOS, I can now confirm the existence of an extended register dedicated to the start‑address offset on Nvidia GPUs:
CRTC index 3Bh.

This register is a full 8‑bit offset field, not masked, not truncated, and completely undocumented in any public Nvidia specification.

This discovery opens the door to a complete rewrite of the VESA function 4F06h, removing the limitations imposed by the Nvidia VBIOS and enabling:

virtual horizontal resolutions far beyond the VESA standard

up to 65528 pixels horizontally for any video mode (limited only by available VRAM (no 4M boundary) and the selected mode

horizontal granularity 2,4,8 pixel

The 3Bh register complements the already known extended registers (34h/35h/3Fh), but it is the missing piece required for full control of the offset mechanism.

A more detailed technical write‑up and experimental implementation will follow.