I made a minor mistake, please try the corrected version. (I have also considered a potential workaround for linear modes)

Marco Pistella wrote on 2026-05-20, 14:00:

@LSS10999 […]
Show full quote

@LSS10999

It’s generally not a good idea to force a larger VRAM size unless you are absolutely sure that the memory is actually mapped and accessible. In most cases this will lead to an immediate crash.

If you want to know how much VRAM is really available, the safest method is:

Start X‑VESA

Select the video mode you want to test

Press F10 and choose the Linear mode

Run the last option (“Test video memory”)

Then run Retest unlimited
(Warning: the system may crash during this test — this is expected)

This procedure tells you the actual amount of VRAM that the card exposes in linear mode, regardless of what the BIOS reports.

I got this when testing actual (linear) VRAM size in X-VESA at 1920x1080x32 resolution, without using /M with NEWAX:
- Retest unlimited returns 262144KB (256MB).
- Video card drops down to 640x480 60Hz output and I can no longer perform other tests with this resolution. Originally it outputs at 3840x2160 60Hz over DP connection to my monitor, though maximum available resolution to VESA/VBE is 1920x1080x32.
- Relaunching X-VESA in this state, only 640x480 and 800x600 resolutions are available, and with 800x600 it's actually scaled to 640x480 (per monitor OSD).
- (Insane) Virtual resolution test works fine with 262144KB LFB, though I get occasional flickers during scrolling -- about 2-3 times in total when I scrolled from upper-left to lower-right (testing with 800x600x32).

So while all the 256MB memory is indeed mapped for LFB, there must be something that shouldn't be casually touched get mapped in the region as well.

As such, just as I brought up the question in the SoftGPU thread, perhaps it's not always a good idea to enable as much VRAM as possible with VESA/VBE drivers. However, it seems 32MB is the smallest VRAM size cap for VBEMP 9x, and with SoftGPU VESA driver, the lower limit is also 32MB (when I set "VRAMLimit" in registry to "16", DXDIAG reports 32MB VRAM available). Not sure how VBEMP NT handles this, though, as I don't recall seeing VRAM size related options with that driver (for WinNT family)...

LSS10999 wrote on 2026-05-20, 15:30:

I got this when testing actual (lin...[CUT]

What you’re seeing is completely expected. Using the VRAM size at 262144 KB may appear to work at first, but between the real 16/32 MB window and the forced 256 MB range there is almost certainly some region that should not be touched. Once the test reaches that area, the card will drop to 640×480, lose signal, or behave unpredictably.

This is a behaviour I’ve already seen on several cards when trying to force linear addressing: the program ends up writing into regions that are not part of the actual LFB mapping, and that’s exactly why Retest unlimited can cause crashes or strange output modes.

In short: forcing VRAM sizes is risky unless you know exactly how the hardware maps its memory, and touching unmapped areas almost always leads to instability.

@Falcosoft

New version with support for linear and banked planar video modes (clear VRAM)

Nvidia GPUs use a lot of MMIO registers. They are accessible from DOS (pmode) - I ported NVclock utility [ http://rayer.g6.cz/download/download.htm ] many years ago that manipulates the MMIO. I don't remember the relative offset of MMIO regs to LFB base but I guess it's somewhere inside the range and once x-vesa tries to write some test pattern to this area it probably destroy some MMIO regs vlues that may cause loosing the videosignal or even your GPU may explode 😀
UPDATE: nvclock can display some debug info that show you MMIO base, on my 7900GT it was something like this:
Found VendorID: 0x10DE, DeviceID: 0x0291 @ PCI:1:0:0, MMIO base: 0xF4000000
Then you can compare this address with LFB base to get the offset (unfortunatelly I didn note it here) - this imply the size of LFB you can use for drawing before you overwrite that critical MMIO regs...

>Falco
tried FALSSANI with SSE and NEWAX loaded and seems to run fine and smooth...

According to this, the MMIO registers can be accessed through BAR0 and the VRAM through BAR1 in the PCI configuration space.
https://envytools.readthedocs.io/en/latest/hw … /bars.html#bars
(I guess you all know that already...)

But my question is more towards NVIDIA documentation in general...
Besides https://envytools.readthedocs.io/en/latest/hw/index.html (very incomplete,) https://nouveau.freedesktop.org/NvHardwareDocs.html (also just bits and pieces) and the nouveau driver in the linux kernel, what else is there? Are there any other (good) sources of information about these cards?

Awesome work and discoveries!

I tested NEWAX 0.10 (forcing VBE 2.0) on an RTX 4060 Ti (Ada Lovelace) and a Quadro FX540 (Geforce 6). It's mostly a success on the RTX 4060 Ti, flickering is gone in Duke3D, Quake and page flipping tests of VBETEST. I also have a lot more pages in all graphics modes. As reported for Ampere, banked modes are slow to draw for the virtual resolution tests (30k+ pixels wide then 20k+ pixels tall), linear modes are fine. So it seems that NEWAX works with Ada generation too!

It's quite the opposite with the Quadro FX540. with NEWAX (/2), with VBETEST, screen jumps all over the place when flipping pages, as if each page has incorrect address. Virtual resolution tests are completely garbled. All tests of VBETEST pass with success in stock configuration. Also, the dual page video test of X-VESA flickers between two completely misaligned pages with NEWAX on any refresh mode, whereas it only flickers with the VESA retrace without NEWAX.

As this card is mostly working out of the box, I think the only interesting part is the VESA inverted retrace logic fix. Maybe we could activate only this on Fermi and older as their BIOS are mostly sane?

Marco Pistella wrote on 2026-05-20, 16:01:

@Falcosoft

New version with support for linear and banked planar video modes (clear VRAM)

The attachment NEWAX.ZIP is no longer available

Thanks, this time it seems to be working well!

NEWAX 0.10 — Compatibility report and roadmap for 0.11
Here is a summary of my own test results. Anyone with additional hardware is welcome to contribute by running NEWAX /S and posting the output.
Tested by the author:

1Card                  PCI ID      Rev  SUBSYS ID   Notes
2
3GeForce GTX 1050      10DE_1C81   A1   1458_3766   Original VESA BIOS: 4F07h -> Fail
4GeForce GT 1030       10DE_1D01   A1   1462_8C98   Original VESA BIOS: 4F07h -> Fail
5GeForce GT 740        10DE_0FC8   A1   10DE_0FC8   Original VESA BIOS: 4F07h -> Fail, /M:16384
6GeForce GTX 550 Ti    10DE_1244   A1   0000_0000   /M:16384
7GeForce 210           10DE_0A65   A2   1043_8490   /M:16384
8GeForce 210           10DE_0A65   A2   1043_852D   /M:16384
9GeForce 8400 GS       10DE_0422   A1   1ACC_0851   /M:16384
10GeForce 7025 (IGP)    10DE_03D6   A2   1043_83A4   Integrated GPU - NEWAX not supported

From these results it is clear that NEWAX does not work on GeForce 6. The confirmed lower limit is currently GeForce 8. The GeForce 6 uses CRTC register 1Fh for unlock instead of 3Fh, and the extended registers for that generation are not yet documented.
Roadmap for NEWAX 0.11:

• []Cosmetic improvements suggested by EduBat (function names in /S output)
  []VRAM clear on mode set (4F02h) — fix for a newly identified Nvidia VBIOS bug, as suggested and validated by Falcosoft
  []New /V switch to disable vertical retrace sync globally for all 4F07h sub-functions
  []Implementation of 4F07h sub-functions 02h, 04h and 82h (if feasible)

A sincere thank you to everyone who has contributed to testing and improving NEWAX:
Falcosoft for identifying the VRAM clear bug, validating the fix, and for his continuous technical feedback since the very beginning of this project;
Ockiller for testing on the RTX 4060 Ti and confirming Ada Lovelace compatibility;
LSS10999 for extensive testing on the RTX A4000 and detailed reports on edge cases;
RayeR for technical insights on Nvidia MMIO mapping;
EduBat for the cosmetic suggestions and hardware documentation references;
zyzzle for multi-system testing across different platforms.
Your contributions are making NEWAX better with every release. Thank you all.

Marco Pistella wrote on Yesterday, 06:54:

NEWAX 0.10 — Compatibility report and roadmap for 0.11
Here is a summary of my own test results. Anyone with additional hardware is welcome to contribute by running NEWAX /S and posting the output.
...

Geforce GTX 970:

1Nvidia kEpler/maxWell/pAscal fiX - NEWAX 0.10ŕ - NVIDIA mode
2PCI version: 3.0
3PCI specification: 001
4PCI buses: 007
5Original Logical Scanline Length (4F06h): Supported
6Original Display Start Address/Panning (4F07h): Fail
7Nvidia graphic card: Detected
8PCI_ID: 10DE_13C2 - Revision: A1 - SUBSYS_ID: 1462_3161
9Bus number: 001 - Device: 00 - Function 0
10NEWAX: Installed
11One page mode: Disabled
12VESA 2.0: Disabled
13VBE/PMI: Disabled

NEWAX 0.11 released

Download and source code:
https://github.com/Marco-Pistella/NEWAX

---

NEWAX 0.11 is out. Here is a summary of what changed since 0.10.

---

NEW: VRAM clear on mode set (4F02h)

NEWAX now zeroes the entire VRAM when a VESA mode is opened without the
no-clear flag (BX bit 15 = 0). Both banked and linear modes are supported,
planar modes included.

For linear modes: the mode is temporarily reopened in banked form, the clear
is performed bank by bank via INT 10h 4F05h + REP STOSD, then the mode is
reopened in linear form. For planar modes the bank count is divided by 4.
Bank 0 is restored on exit.

---

NEW: Hardware compatibility detection

The most significant addition is a new routine, Detect_Supported_Nvidia, that
determines whether the card is supported before installation, using a direct
hardware-level test rather than relying solely on broken VESA function behavior.

The test exploits a structural difference between supported and unsupported cards:

- On G80 and later (GeForce 8 through Ampere), the extended CRTC registers for
offset and start address are hardware-protected. After locking CRTC 3Fh with
value 08h, any write to CRTC 3Bh (extended offset) has no effect.

- On pre-G80 cards, no such protection exists. CRTC 3Bh is freely writable
at all times.

NEWAX locks CRTC 3Fh, attempts a non-destructive write (XOR FFh) to CRTC 3Bh,
then reads back the result:

- Readback unchanged -> register protected -> card supported -> install
- Readback changed -> register writable -> card not supported -> abort

On unsupported cards all modified registers are restored before exiting.
In /S mode the detection result is always shown for diagnostic purposes,
even on unsupported cards.

---

NEW: /V flag — force VSync off

A new /V argument toggles forced VSync-off mode. When active, the 4F07h BL=02h
handler (set start address during vertical retrace) skips the retrace wait and
writes immediately. The current VSync status is reported in /S output.
/V can be toggled on an already-installed TSR.

---

BUGFIX: stack imbalance in VGA mode set handler

In the AH=00h handler (Set VGA Mode), the POP DS instruction was misplaced
before the conditional branch:

push BIOS_INTERRUPT_SEGMENT
pop ds
cmp ds:[BIOS_OFFSET_VGA_VIDEO_MODE], VGA_MAX_VIDEO_MODE
pop ds ; <- wrong position: before the branch
ja vesa_mode_on
and cs:[status_flag_0_tsr], NOT NEWAX_FLAG_VESA_MODE_TSR
vesa_mode_on:
call Reset_Nvidia_Start_Address
popa ; <- stack unbalanced by 2 bytes
iret

The PUSHA/POPA pair was unbalanced, corrupting the restored register state
and leaving the stack pointer off by two bytes after every VGA mode set.
Fixed in 0.11 by moving POP DS after the branch.

---

IMPROVED: diagnostic messages in /S output

"Original 4F06h VESA function" -> "Original Logical Scanline Length (4F06h)"
"Original 4F07h VESA function" -> "Original Display Start Address/Panning (4F07h)"

---

Nvidia extended CRTC register map (documented here for reference)

G80 and later (GeForce 8 through Ampere):

Lock: CRTC 3Fh <- 08h
Unlock: CRTC 3Fh <- 57h (key 2469FDB9h, first public documentation)

Start address:
bits 0-7 CRTC 0Dh
bits 8-15 CRTC 0Ch
bits 16-23 CRTC 35h
bits 24-29 CRTC 34h [5:0]

Offset register:
bits 0-7 CRTC 13h
bits 8-15 CRTC 3Bh (first public documentation)

Pre-G80 (RIVA TNT through GeForce 6):

No lock/unlock required.

Start address:
bits 0-7 CRTC 0Dh
bits 8-15 CRTC 0Ch
bits 16-20 CRTC 19h [4:0]
bits 21-24 CRTC 2Dh [3:0]

Offset register:
bits 0-7 CRTC 13h
bits 8-10 CRTC 19h [7:5]

---

Tested hardware (0.11):

GeForce GTX 1050 10DE:1C81 rev A1 SUBSYS 1458:3766 4F07h broken in VBIOS
GeForce GT 1030 10DE:1D01 rev A1 SUBSYS 1462:8C98 4F07h broken in VBIOS
GeForce GTX 970 10DE:13C2 rev A1 SUBSYS 1462:3161 4F07h broken in VBIOS (Falcosoft)
GeForce GT 740 10DE:0FC8 rev A1 SUBSYS 10DE:0FC8 4F07h broken; /M:16384
GeForce GTX 550Ti 10DE:1244 rev A1 SUBSYS 0000:0000 /M:16384
GeForce 210 10DE:0A65 rev A2 SUBSYS 1043:8490 /M:16384
GeForce 210 10DE:0A65 rev A2 SUBSYS 1043:852D /M:16384
GeForce 8400 GS 10DE:0422 rev A1 SUBSYS 1ACC:0851 /M:16384
GeForce 7025 10DE:03D6 rev A2 SUBSYS 1043:83A4 integrated; 4F06h/4F07h not supported

If you have tested NEWAX on any card not listed above, please post your results.
PCI_ID, revision and SUBSYS_ID (available from NEWAX /S output) are appreciated.

I have tested NEWAX 0.11 with both my GTX650 and GeForce 6200

GTX650:
Notes: NEWAX makes Double Buffering and Virtual Resolutions possible on this card. Both failed before. It also increases the amount of memory available in banked mode. (Tests done with X-VESA.)
(I did not use /M)
Nvidia kEpler/maxWell/pAscal fiX - NEWAX 0.11à - NVIDIA mode
PCI version: 3.0
PCI specification: 001
PCI buses: 005
Original Logical Scanline Length (4F06h): Supported
Original Display Start Address/Panning (4F07h): Fail
Nvidia graphic card: Detected
PCI_ID: 10DE_0FC6 - Revision: A1 - SUBSYS_ID: 1458_3553
Bus number: 001 - Device: 00 - Function 0
NEWAX: Installed
One page mode: Disabled
VESA 2.0: Disabled
VBE/PMI: Disabled
Vsync status: Default

GeForce 6200
Notes: NEWAX makes finding the available memory (F6 followed by F5) much slower than without it. The double buffering/retrace test improves as the bar is no longer jumpy like before in VESA mode. With NEWAX, regardless of selecting VESA 2 or VESA 3 the grid shows up garbled in the virtual resolution test. (Tests done with X-VESA.)
(I did not use /M)
Nvidia kEpler/maxWell/pAscal fiX - NEWAX 0.11à - NVIDIA mode
PCI version: 2.1
PCI specification: 017
PCI buses: 004
Original Logical Scanline Length (4F06h): Supported
Original Display Start Address/Panning (4F07h): Supported
Nvidia graphic card: Detected
PCI_ID: 10DE_0221 - Revision: A1 - SUBSYS_ID: 10B0_0403
Bus number: 003 - Device: 00 - Function 0
NEWAX: Installed
One page mode: Disabled
VESA 2.0: Disabled
VBE/PMI: Disabled
Vsync status: Default

EduBat wrote on Yesterday, 22:54:

I have tested NEWAX 0.11 with both my G...[CUT]

Hi EduBat, thank you for the detailed report.
GTX650: confirmed working as expected, added to the compatibility table.
GeForce 6200: this is an interesting and important result. The card installs without /F because Detect_Supported_Nvidia returns a false positive on NV44 — CRTC 3Bh exists on that core but behaves differently from G80+, and the XOR FFh test happens to pass for the wrong reasons. The corrupted grid in virtual resolution is a direct consequence of this: NEWAX writes the extended offset to CRTC 3Bh which on NV44 has different semantics.
The slowdown on F6→F5 is expected and correct — it is the new VRAM clear introduced in 0.11 on 4F02h, which zeroes the entire framebuffer bank by bank. On older hardware with PCI 2.1 bandwidth this has a visible cost.
Fixing the false positive on NV44 without a physical sample to analyze is not straightforward. The VBIOS unlock key 2469FDB9h cannot be used as a discriminant because it is absent on the 8400GS as well, which is correctly supported. If you are able to capture any additional hardware-level data from the 6200 I would be very interested.
For now the recommendation for GeForce 6200 and NV44 discrete cards in general is: do not install NEWAX, the detection will pass but the results will be incorrect.

Attempt to build a new routine for detecting Nvidia graphics cards not compatible with NEWAX

RayeR wrote on 2026-05-20, 16:48:

Nvidia GPUs use a lot of MMIO registers. They are accessible from DOS (pmode) - I ported NVclock utility [ http://rayer.g6.cz/do […]
Show full quote

Nvidia GPUs use a lot of MMIO registers. They are accessible from DOS (pmode) - I ported NVclock utility [ http://rayer.g6.cz/download/download.htm ] many years ago that manipulates the MMIO. I don't remember the relative offset of MMIO regs to LFB base but I guess it's somewhere inside the range and once x-vesa tries to write some test pattern to this area it probably destroy some MMIO regs vlues that may cause loosing the videosignal or even your GPU may explode 😀
UPDATE: nvclock can display some debug info that show you MMIO base, on my 7900GT it was something like this:
Found VendorID: 0x10DE, DeviceID: 0x0291 @ PCI:1:0:0, MMIO base: 0xF4000000
Then you can compare this address with LFB base to get the offset (unfortunatelly I didn note it here) - this imply the size of LFB you can use for drawing before you overwrite that critical MMIO regs...

>Falco
tried FALSSANI with SSE and NEWAX loaded and seems to run fine and smooth...

I did a test of your ported NVCLOCK on my RTX A4000, regarding MMIO base. Here's the result.

Found VendorID: 0x10DE, DeviceID: 0x24B0 @ PCI:12:0:0, MMIO base: 0xED000000

I also did a quick test run of NEWAX 0.11 there (without any additional argument at the moment). Here's the /S output.

Nvidia kEpler/maxWell/pAscal fiX - NEWAX 0.11à - NVIDIA mode PCI version: 3.0 PCI specification: 001 PCI buses: 015 Original Log […]
Show full quote

Nvidia kEpler/maxWell/pAscal fiX - NEWAX 0.11à - NVIDIA mode
PCI version: 3.0
PCI specification: 001
PCI buses: 015
Original Logical Scanline Length (4F06h): Fail
Original Display Start Address/Panning (4F07h): Fail
Nvidia graphic card: Detected
PCI_ID: 10DE_24B0 - Revision: A1 - SUBSYS_ID: 103C_14AD
Bus number: 012 - Device: 00 - Function 0
NEWAX: Installed
One page mode: Disabled
VESA 2.0: Disabled
VBE/PMI: Disabled
Vsync status: Default

Haven't tested much at the moment but noted a few spots probably related to the VGA stack unbalancing issue on 0.10, with X-VESA:
- VRAM Retest Unlimited previously resulted in the video signal dropping to 640x480 60Hz. Now the video signal is completely lost.
- Previously F6->F5 to detect resolutions would result in the video card losing output signal in the middle of the process (default VRAM size, without using /M). Now it completes without issues.

Here's log from my EVGA GTX970, vBIOS 84.04.84.00.70

1Nvidia kEpler/maxWell/pAscal fiX - NEWAX 0.11à - NVIDIA mode
2PCI version: 3.0
3PCI specification: 017
4PCI buses: 007
5Original Logical Scanline Length (4F06h): Supported
6Original Display Start Address/Panning (4F07h): Fail
7Nvidia graphic card: Detected
8PCI_ID: 10DE_13C2 - Revision: A1 - SUBSYS_ID: 3842_2974
9Bus number: 001 - Device: 00 - Function 0
10NEWAX: Installed
11One page mode: Disabled
12VESA 2.0: Disabled
13VBE/PMI: Disabled
14Vsync status: Default

Quake runs fine with default settings. Blood needs set 1 page mode otherwise the screen is black.

Here are base addresses of MMIO and LFB:
LFB address: EF000000 - 4009754624
+A000000 - +167772160 (160MB)
MMIO base: F9000000 - 4177526784

So MMIO is far enough from LFB to not be overwritten (not sure how far xvesa go)...