Geforce GTX 650 - BIOS version: 80.07.35.00.60
NVIDIA Corporation GK107 [GeForce GTX 650] [10de:0fc6] (rev a1)

UNER - Unlock Nvidia Extended Regs - V0.1 (alpha)
Nvidia Key found at: C000:469B
Nvidia offset bar regs at: C000:0120
Nvidia Bar regs at: DC00
IRET found at: C000:04FB
Nvidia unlock routine found at: C000:48B4
Start Nvidia unlock ... complete

NEWAX v0.3 (alpha) — Full Nvidia virtual resolution support

After completing the reverse engineering of the Nvidia VBIOS unlock sequence (documented in the UNER post), NEWAX v0.3 now implements correct VESA 4F07h support for Nvidia Kepler, Maxwell, and Pascal GPUs.

Minimal unlock — no full UNER mechanism required

The extended CRTC registers on these cards require only two port writes to unlock before programming:

CRTC index 3Fh ← 57h

This is the minimal form of the unlock discovered during UNER development. No key, no trampoline, no VBIOS routine call — just those two bytes written to the CRTC before touching the extended registers.

Extended start address registers

The reverse engineering revealed two previously undocumented Nvidia extended CRTC registers for the display start address:

CRTC 34h — high byte of extended start address (bits 5:0 used)
CRTC 35h — low byte of extended start address

These are programmed alongside the standard VGA start address registers (0Ch/0Dh) to provide the full address range required for virtual resolution panning. The retrace wait logic (BL=80h) is also orrected: Nvidia's own BIOS inverts the vertical retrace polarity, waiting for end-of-retrace instead of start-of-retrace. NEWAX fixes this.

Tested hardware and software

Verified on Nvidia GT740 and GT1030 with:
- X-VESA (virtual resolution panning across all tested modes)
- Quake (VESA mode, full panning)
- Duke Nukem 3D (VESA mode, full panning)

All tests ran without issues up to 1280x1024 virtual resolution.

Known limitation

On the tested GPUs, the horizontal start address must be a multiple of 2 pixels. If an odd value is requested (e.g. 103 pixels), NEWAX rounds it down to the nearest even value (102 pixels). This appears
to be a hardware constraint specific to Nvidia on the tested cards — behavior on other GPUs may differ and is one of the things beta testing will clarify.

Call for beta testers

NEWAX needs testing on as many Nvidia cards as possible to build a complete compatibility map. Cards of particular interest:

- Pre-Kepler Nvidia (Fermi and older)
- Quadro and professional series
- High-end Maxwell and Pascal (GTX 900/1000 series)
- Turing and Ampere

If you have Nvidia hardware and a DOS boot environment, please test and report: card model, whether virtual resolution panning works correctly, and whether the horizontal alignment behavior matches or
differs from the description above.

Beta testers from other forums are equally welcome — the more hardware covered, the more complete the compatibility picture.

Source code is included in the archive.

Marco Pistella wrote on Yesterday, 11:14:

NEWAX v0.3 (alpha) — Full Nvidia virtual resolution support […]
Show full quote

NEWAX v0.3 (alpha) — Full Nvidia virtual resolution support

After completing the reverse engineering of the Nvidia VBIOS unlock sequence (documented in the UNER post), NEWAX v0.3 now implements correct VESA 4F07h support for Nvidia Kepler, Maxwell, and Pascal GPUs.

Minimal unlock — no full UNER mechanism required

The extended CRTC registers on these cards require only two port writes to unlock before programming:

CRTC index 3Fh ← 57h

This is the minimal form of the unlock discovered during UNER development. No key, no trampoline, no VBIOS routine call — just those two bytes written to the CRTC before touching the extended registers.

Extended start address registers

The reverse engineering revealed two previously undocumented Nvidia extended CRTC registers for the display start address:

CRTC 34h — high byte of extended start address (bits 5:0 used)
CRTC 35h — low byte of extended start address

These are programmed alongside the standard VGA start address registers (0Ch/0Dh) to provide the full address range required for virtual resolution panning. The retrace wait logic (BL=80h) is also orrected: Nvidia's own BIOS inverts the vertical retrace polarity, waiting for end-of-retrace instead of start-of-retrace. NEWAX fixes this.

Tested hardware and software

Verified on Nvidia GT740 and GT1030 with:
- X-VESA (virtual resolution panning across all tested modes)
- Quake (VESA mode, full panning)
- Duke Nukem 3D (VESA mode, full panning)

All tests ran without issues up to 1280x1024 virtual resolution.

Known limitation

On the tested GPUs, the horizontal start address must be a multiple of 2 pixels. If an odd value is requested (e.g. 103 pixels), NEWAX rounds it down to the nearest even value (102 pixels). This appears
to be a hardware constraint specific to Nvidia on the tested cards — behavior on other GPUs may differ and is one of the things beta testing will clarify.

Call for beta testers

NEWAX needs testing on as many Nvidia cards as possible to build a complete compatibility map. Cards of particular interest:

- Pre-Kepler Nvidia (Fermi and older)
- Quadro and professional series
- High-end Maxwell and Pascal (GTX 900/1000 series)
- Turing and Ampere

If you have Nvidia hardware and a DOS boot environment, please test and report: card model, whether virtual resolution panning works correctly, and whether the horizontal alignment behavior matches or
differs from the description above.

Beta testers from other forums are equally welcome — the more hardware covered, the more complete the compatibility picture.

Source code is included in the archive.

The attachment NEWAX03.ZIP is no longer available

Thank you and congratulations!
I think this is a huge breakthrough. It works almost perfectly on my GTX 970 and GTX 960.
The only (minor) problem is that virtual resolutions at and above (1280 * 2) x (1024 * 2) have unreachable memory region both in banked and LFB modes. The problem manifests itself as garbage after writing/drawing.
Here is a demo program and a screenshot about the problem.

@Edit:
Here is a demonstration video about the problem:
https://youtu.be/LywuiRP7PXs

Falcosoft wrote on Yesterday, 11:56:

Thank you and congratulations!
I think this is a huge brea ... [CUT]

Hi Falcosoft,

thank you very much for the quick test and for the detailed feedback — it’s extremely helpful.

About the issue you observed with virtual resolutions at and above 1280 × 1024:
this behaviour is actually normal on Nvidia cards and not caused by a bug in NEWAX.

Although VESA function 4F00h reports 14336 (or more) KB of available video memory, Nvidia Kepler+ cards expose only a much smaller contiguous framebuffer region when running under DOS.
On the Kepler/Maxwell/Pascal cards I tested, the maximum reliably accessible area is about 4160 KB.

Anything beyond that range is not mapped as visible framebuffer memory.
So when the virtual start address grows large enough to point past this limit, writes go into a non‑framebuffer region, and the result is the “garbage” pattern you observed.

X‑VESA includes a built‑in VRAM visibility test for exactly this reason.
If you start X‑VESA and press F6, then F5, (wait for the test) you can see the actual amount of video memory that is accessible physically for each video mode, separately for banked and LFB modes.
This confirms the real hardware limit and explains why very large virtual resolutions cannot be fully mapped.

So the good news is:
NEWAX is working correctly — the limitation comes from how Nvidia maps VRAM under DOS.

Thanks again for testing on GTX 960 and 970. Your reports are invaluable for building a complete compatibility map.

EDIT: Resut on a Nvidia GT1050:

It drives me thinking if it would be possible to reprogram some MMIO reg. to expose more VRAM for LFB. Probably vbios initialize some minimal space exposed by VBE and graphics driver then reprograms it to larger window according to available vram and memory space. nV up to 7xxx exposed full VRAM, not sure about 8xxx/9xxx

Marco Pistella wrote on Yesterday, 12:43:

Hi Falcosoft, […]
Show full quote

Falcosoft wrote on Yesterday, 11:56:

Thank you and congratulations!
I think this is a huge brea ... [CUT]

Hi Falcosoft,

thank you very much for the quick test and for the detailed feedback — it’s extremely helpful.

About the issue you observed with virtual resolutions at and above 1280 × 1024:
this behaviour is actually normal on Nvidia cards and not caused by a bug in NEWAX.

Although VESA function 4F00h reports 14336 (or more) KB of available video memory, Nvidia Kepler+ cards expose only a much smaller contiguous framebuffer region when running under DOS.
On the Kepler/Maxwell/Pascal cards I tested, the maximum reliably accessible area is about 4160 KB.

Anything beyond that range is not mapped as visible framebuffer memory.
So when the virtual start address grows large enough to point past this limit, writes go into a non‑framebuffer region, and the result is the “garbage” pattern you observed.

X‑VESA includes a built‑in VRAM visibility test for exactly this reason.
If you start X‑VESA and press F6, then F5, (wait for the test) you can see the actual amount of video memory that is accessible physically for each video mode, separately for banked and LFB modes.
This confirms the real hardware limit and explains why very large virtual resolutions cannot be fully mapped.

So the good news is:
NEWAX is working correctly — the limitation comes from how Nvidia maps VRAM under DOS.

Thanks again for testing on GTX 960 and 970. Your reports are invaluable for building a complete compatibility map.

EDIT: Resut on a Nvidia GT1050:

The attachment FILE0000.PNG is no longer available

Hi,
OK, it's understood.
So far I have only tested 8-bit modes since these are the really relevant modes in DOS. Now I also tested 16/32-bit modes and the situation is much worse. Actually none of the 16/32-bit modes works in X-VESA's dual pages/double buffering test. Even 640x480x16 and 640x480x32 gives flickering screen with artifacts:

Hi everyone,
I’ve released NEWAX 0.4, this update introduces an important improvement to the handling of VESA function 4F01h (Get Video Mode Info): NEWAX now recalculates the NumberOfImagePages field dynamically based on the actual amount of VRAM available for the current video mode.

VRAM is calculated as follows: in banked mode it is fixed to 4160 KB unless the video mode requires more. In that case — and also when the video mode is opened in linear mode — NEWAX uses the TotalMemory field from the VbeInfoBlock structure.

Fixed:
- Duke Nukem3D (1280x1024)
- Reset nvidia extended regsters on new open video mode
- Video Mode 15/16/32 bpp

Just tested this on my Ampere system, and it seems NEWAX is not going to work yet.

It exits with message "VESA function 4F06h (Set/Get scanline) not supported".

So I think for that system I'll have to wait until a fix for 4F06h gets implemented.

Marco Pistella wrote on Yesterday, 15:11:

Hi everyone, I’ve released NEWAX 0.4, this update introduces an important improvement to the handling of VESA function 4F01h (Ge […]
Show full quote

Hi everyone,
I’ve released NEWAX 0.4, this update introduces an important improvement to the handling of VESA function 4F01h (Get Video Mode Info): NEWAX now recalculates the NumberOfImagePages field dynamically based on the actual amount of VRAM available for the current video mode.

VRAM is calculated as follows: in banked mode it is fixed to 4160 KB unless the video mode requires more. In that case — and also when the video mode is opened in linear mode — NEWAX uses the TotalMemory field from the VbeInfoBlock structure.

Fixed:
- Duke Nukem3D (1280x1024)
- Reset nvidia extended regsters on new open video mode
- Video Mode 15/16/32 bpp

The attachment NEWAX04.ZIP is no longer available

Thanks!
It seems 16/32-bit modes work properly now.
Once again, this is a huge success.
These cards have been almost useless so far considering high resolution DOS gaming/VESA programming. But now, thanks to you, they have one of the best performing VESA implementations! 😀

New version NEWAX 0.5

Fixed:

- 16/32 video mode (again)

New:

- 1 Pixel horizontal scrolling for 8/16/32 bpp (unusual 3C0h/13h)

@RayeR

The idea of trying to map all the VRAM reported in VbeInfoBlock.TotalMemory is interesting, but it’s important to clearly distinguish between banked and linear modes.

In linear mode, the problem doesn’t actually exist:
the LFB is always mapped to the maximum size reported by VBE, i.e. 14336 KB or 16384 KB, depending on the card.
So the BIOS already exposes all the VRAM that VBE considers usable for that mode.

The limitation applies only to banked mode, where the classic window is about 4160 KB.
When a video mode requires more memory than that window (for example 1280×1024×32), the BIOS uses the larger amount indicated in TotalMemory (16384 KB in my case).
If the mode fits within the ~4 MB window (like 1280×1024×16), it stays within the standard banked window.

To understand exactly how the BIOS decides what to map and when, one would need to compare—via debugger—two video modes that are almost identical but have different memory requirements (in my case 1280×1024×16 vs 1280×1024×32) and see what changes the BIOS introduces during initialization.
From what little I’ve seen, it looks much more complex than just writing to a few I/O ports. I’d set this aside for now.

@LSS10999

Yes, on Ampere NEWAX cannot work yet — and the reason is technical, precise, and already known: on Nvidia Ampere GPUs the VESA function 4F06h simply no longer exists.

I would like to add a reimplementation of 4F06h as well, but to be honest: implementing 4F07h on Kepler/Maxwell/Pascal took me over 15 hours of continuous work, so I can’t promise anything.

I will still take another look at the GT 1030 BIOS (where 4F06h is still present and functional); if the logic is straightforward enough to replicate in a TSR, I will add it. Otherwise, Ampere will unfortunately remain unsupported.

@Falcosoft

I'm really glad to hear that 16/32-bit modes are now working correctly. In version 0.5 I fixed a bug in the horizontal scanline size for 16/32 bpp video modes, and horizontal scrolling is now accurate to 1 pixel in all video modes.

I will try to implement the 4F06h function on cards where it has been removed, but I cannot promise anything. I’ll take a look and see if it’s feasible.

P.S. I also tested the Mandelbrot animation (FALSSANI.zip), and it now works correctly

Marco Pistella wrote on Yesterday, 16:22:

New version NEWAX 0.5

The attachment NEWAX05.ZIP is no longer available

I know my GTX650 may not be a very interesting datapoint, given that it's bang in the middle of the range of cards under test but here goes: NEWAX works well and makes the double buffering and virtual resolutions work perfectly.

I'm running my tests with a Windows 98 boot diskette and noticed that, if I run NEWAX and then NEWAX /U to remove it from memory, followed by the MEM /C /P command it leaves behind a 96 bytes "memory hole" (for lack of a better term).

NEWAX v0.6 — What's New

New runtime switches (no reinstall required)

NEWAX.COM /1 Toggle one-page mode
When enabled, forces NumberOfImagePages,
LinNumberOfImagePages and BnkNumberOfImagePages to 0
in all 4F01h responses. Use this as a last resort for
games that ignore the correct page count and display
garbage from non-existent video pages.

NEWAX.COM /2 Toggle VESA 2.0 / 3.0
When enabled, downgrades the VbeVersion field returned
by 4F00h from 3.0 to 2.0. Useful for software that
misbehaves specifically with VESA 3.0 BIOSes.

NEWAX.COM /P Toggle VBE/PMI passthrough
Controls whether function 4F0Ah (VBE Protected Mode
Interface) is passed to the original BIOS handler or
blocked. Disabled by default.

Improved 4F01h (Return VBE Mode Information)

LinearNumberOfImagePages and BankedNumberOfImagePages are now
calculated independently. Linear modes use the full available VRAM;
banked modes are capped at the hardware banked window limit.
Linear vs. banked state is now tracked correctly across mode switches.

Uninstall fix

NEWAX.COM /U now correctly frees both the PSP environment segment
and the main code block. Previously the environment block was left
allocated after uninstall.

Internal fixes

- NEWAX_FLAG_LINEAR_MODE is now cleared correctly on every VGA and
VESA mode switch, preventing state carried over from a previous mode
from affecting the new one.
- VESA planar memory model removed from the 4F01h page count
calculation — NEWAX does not intercept planar modes.

Outstanding work, Marco. And so quickly. I don't currently have any Nvidia card to test. However, this is making me want to buy an NVidia card now to put into one of my older DOS systems. I think I should still be able to find one for a reasonable cost at one of my local Goodwill thrift shops. Recommendations on a "middle of the road" Nividia card for good-performance DOS 2D gaming at high VESA resolutions? Hopefully I'll find one at non-Ebay prices...

Congratulations on unlocking these cards. A great day for DOS systems.

Marco Pistella wrote on Yesterday, 22:03:

NEWAX v0.6 — What's New ... LinearNumberOfImagePages and BankedNumberOfImagePages are now calculated independently. Linear m […]
Show full quote

NEWAX v0.6 — What's New
...
LinearNumberOfImagePages and BankedNumberOfImagePages are now
calculated independently. Linear modes use the full available VRAM;
banked modes are capped at the hardware banked window limit.
Linear vs. banked state is now tracked correctly across mode switches.
...

Hi,
If I understand you correctly you say that in LFB modes the whole reported memory should be available.
But on my GTX 970 and 960 cards the around 4MB video memory limit is present in practice even in LFB modes (although reported as 16MB). That is even with your newest NEWAX 0.6 version my test program (FALSSANI) that uses (1280 *2) x (1024 *2) virtual resolution in 1280x1024x8-bit LFB mode still produces the same artifacts as I posted before. That is:
download/file.php?id=241941&mode=view
https://youtu.be/LywuiRP7PXs

Falcosoft wrote on Yesterday, 22:40:

But on my GTX 970 and 960 cards the around 4MB video memory limit is present in practice even in LFB modes (although reported as 16MB).

ORLY? Once when I got in touch with 4k Dell LCD I tested on my GTX 970 VESA LFB modes 3840 x 2160 / 8 and 16 bpp so it definitely used more than 4MB for LFB:

weird thing was that such VESA modes was listed only when I connected LCD via DP 1.2 but when switched to HDMI 2.0 those 4k modes disappeared. I never realize how nvidiots build the dynamic VESA mode list but it's full of bugs (depending what kind of LCD connection you use and on various GPU family)...

RayeR wrote on Yesterday, 23:57:

VESA modes was listed only when I connected LCD via DP 1.2 ... dynamic VESA mode list ... depending what kind of LCD connection you use...

Maybe because DP is a VESA standard and HDMI was (is?) mainly intended for non-PC devices.

RayeR wrote on Yesterday, 23:57:

ORLY? Once when I got in touch with 4k Dell LCD I tested on my GTX 970 VESA LFB modes 3840 x 2160 / 8 and 16 bpp so it definitel […]
Show full quote

Falcosoft wrote on Yesterday, 22:40:

But on my GTX 970 and 960 cards the around 4MB video memory limit is present in practice even in LFB modes (although reported as 16MB).

ORLY? Once when I got in touch with 4k Dell LCD I tested on my GTX 970 VESA LFB modes 3840 x 2160 / 8 and 16 bpp so it definitely used more than 4MB for LFB:

weird thing was that such VESA modes was listed only when I connected LCD via DP 1.2 but when switched to HDMI 2.0 those 4k modes disappeared. I never realize how nvidiots build the dynamic VESA mode list but it's full of bugs (depending what kind of LCD connection you use and on various GPU family)...

I think one set of the modes in the table are meant for whatever native mode supported by your monitor and connection (read through EDID). And yes, if 4K is supported then it outputs using 4K for everything below that (as shown in the monitor OSD).

Sadly on my 4K monitor I can't make 1080p work out-of-box through VESA, as my monitor's EDID doesn't have any detailed config for that -- only 4K and a 1440p fallback. With HDMI I have to use an EDID dongle containing a modded EDID to enable that resolution in VESA, as well as enabling higher refresh rates (e.g. 120Hz/144Hz).

Anyway, 4K does work in VESA if supported and listed, though with old OSes on which VESA driver is relevant, such high resolution doesn't look very well so I had to use something in between. Fortunately nVidia cards seem to allow use of 1280x800 which looks okay with a widescreen monitor.

PS: My monitor, ASUS XG27UQR, supports 4K output on both HDMI and DP ports, though HDMI is only at 2.0 spec so no higher refresh rates than 60Hz. Not sure about your monitor, but the connection detail might affect what resolution might be available, such as the cable used (if HDMI-HDMI), or the specs of the DP-HDMI converter. IIRC most passive DP-HDMI converters don't support 4K very well, and active converters may or may not add quirks.

RayeR wrote on Yesterday, 23:57:

Falcosoft wrote on Yesterday, 22:40:

But on my GTX 970 and 960 cards the around 4MB video memory limit is present in practice even in LFB modes (although reported as 16MB).

ORLY? Once when I got in touch with 4k Dell LCD I tested on my GTX 970 VESA LFB modes 3840 x 2160 / 8 and 16 bpp so it definitely used more than 4MB for LFB:

OK, I have tried once again and X-VESA's virtual resolution test could really use 3840x2160 virtual resolution in 1920x1080x8-bit LFB mode.
But my test program (that actually works perfectly on Intel's integrated GFX) still produces the same problem. That is it can only draw to about 4MB video memory in LFB mode.
The interesting thing is that since I tried my test program after running X-VESA's virtual resolution test I got no garbage at the unreachable memory region but the test image left by X-VESA's virtual resolution test 😀
Here is a demo video about this:

https://youtu.be/QLI8Y-hXHwk

@Edit:
BTW, my test program's result is somewhat confirmed by VBETEST.EXE that can be found in Scitech's UNIVBE package. That is only a ~4MB buffer can be created even in LFB mode by the program's virtual resolution test:

Maybe the different results are because both my test program and VBETEST.EXE from UNIVBE uses 32-bit protected mode while X-VESA does not.

I finally tested NEWAX 0.6 on my EVGA GTX970 VBIOS 84.04.84.00.70 in Quake and compared with old Falco's MSKVBEF7.

In 1024*768 mode both runs fine (timedemo demo1.dem, MTRRLFBE LFB WC):
MSKVBEF7.COM - 255 FPS
NEWAX.COM - 60 FPS, capped by vsync

But in 1280*1024 I got heavy artefacts, mostly in game menu, 60 FPS
(with MSKVBEF7 still OK as it disable this)

I also tried with option "NEWAX.COM /1" but got error "not installed".

for completness output of UNER.COM:
UNER - Unlock Nvidia Extended Regs - V0.1 (alpha)
Nvidia Key found at: C000:4016
Nvidia offset bar regs at: C000:0129
Nvidia Bar regs at: EF00
IRET found at: C000:054D
Nvidia unlock routine found at: C000:43E2
Start Nvidia unlock ... complete

>LSS10999 for my 4k test I used DP-DP cable at DP output and HDMI-HDMI cable at HDMI output of VGA (card and monitor had both interfaces).