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 44 minutes ago:

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.