Marco Pistella wrote on 2026-05-18, 19:07:

NEWAX 0.10 – Nvidia VESA Fix for DOS (major update) […]
Show full quote

NEWAX 0.10 – Nvidia VESA Fix for DOS (major update)

Hi everyone,
I’m releasing NEWAX 0.10, a major update of the TSR that restores proper VESA VBE behavior on modern Nvidia GPUs under DOS.

This version includes a complete rewrite of:

INT 10h 4F06h – Logical Scanline Length

INT 10h 4F07h – Display Start Address / Panning

Both functions are now fully implemented in software and mapped to Nvidia’s extended CRTC registers (34h, 35h, 3Bh), enabling correct panning, pitch calculation and virtual screen support on Kepler, Maxwell and Pascal GPUs whose VBIOS no longer implements these functions.

The project is open‑source and available here:
👉 GitHub repository: https://github.com/Marco-Pistella/NEWAX

Call for beta testers (VERY IMPORTANT)
To properly map compatibility across the entire Nvidia lineup, I need testers for:

pre‑Kepler GPUs (GeForce 7, 8, 9, 200, 400, 500 series)

post‑Pascal GPUs (Turing, Ampere, Ada)

OEM and mobile variants

secondary GPUs or systems with unusual PCI BIOS behavior

Even if NEWAX was originally designed for Kepler/Maxwell/Pascal, testing outside this range is extremely valuable to understand how Nvidia’s extended CRTC registers behave on older and newer architectures.

How to provide diagnostic information
Simply run:

NEWAX.COM /S

and report: GPU model, VBIOS version (if possible), whether NEWAX loads normally or requires /F, panning status, virtual screen status, any anomalies or graphical glitches

Download
Binary and full source code are available here: https://github.com/Marco-Pistella/NEWAX/releases
👉 NEWAX Releases

Notes
/F bypasses Nvidia detection and forces installation (useful for testing).

Works in real mode DOS.

Tested so far on GT210, GT550Ti, GTX650, GTX960, GTX1050, GTX1060, RTX A4000.

More testing is needed across the entire Nvidia family.

Looks good on my RTX A4000 with NEWAX 0.10.
- VBEVSTST and FALSSANI work fine with no noticeable artifacts.
- X-VESA dual page test works as expected (since 0.9)
- Virtual resolution test in X-VESA now works without issues (capped at 16MB VRAM though).
- X-VESA reports 16MB for both Banked and Linear modes.

Some issues with SciTech VBETEST (6.53), however:
- Double Buffering test doesn't seem to work as expected. Flickers and always says Page 1 of xx.
- While virtual scrolling does work, drawing is incredibly slow in Banked mode and some artifacts may be seen. Linear mode works fine.

LSS10999 wrote on 2026-05-19, 11:25:

Looks good on my RTX A4000 with ...[CUT]

Thanks for the detailed feedback on the RTX A4000 — very helpful.

Regarding the issues you observed in SciTech VBETEST: this is expected at the moment. NEWAX 0.10 does not yet implement the 4F07h sub‑functions 02h, 04h, and 82h, which VBETEST relies on for double buffering, page flipping, and advanced virtual scrolling.

When these functions are missing, VBETEST falls back to incomplete logic and may show flickering, incorrect page numbers, or slow scrolling in banked mode.

Could you please run the same tests using the /2 switch?

/2 forces VESA 2.0 compatibility, which makes VBETEST use only the basic 4F07h functions (00h, 01h, 80h) that NEWAX already supports. This should give more consistent results.

If possible, please also report:
• the virtual page size in pixels (width × height)
• the video mode used (resolution + color depth)

VBETEST becomes extremely slow when the virtual page exceeds ~30,000 pixels in either dimension, so this information will help determine whether the slowdown is due to page size or missing 4F07h sub‑functions.

Thanks again for your help — your tests are very valuable for improving NEWAX.

How can I test such big virt. resolution? When I run x-vesa, select e.g. my native 1600x1200 and test virtual resolution, I select the middle option and enter some larger number than physical res. but the verical size I got is capped by my physical res. So I get e.g. 3840x1200 and can scroll over horizontally over full 3840, verically only by 1 pixel. I can't get more verical than 1200 (newax10 loaded on GTX970).

Btw what is FALSSANI and where it came from? Can't see source in this thread...

RayeR wrote on 2026-05-19, 13:37:

How can I test such big virt. resolution? When I run x-vesa, select e.g. my native 1600x1200 and test virtual resolution, I select the middle option and enter some larger number than physical res. but the verical size I got is capped by my physical res. So I get e.g. 3840x1200 and can scroll over horizontally over full 3840, verically only by 1 pixel. I can't get more verical than 1200 (newax10 loaded on GTX970).

Btw what is FALSSANI and where it came from? Can't see source in this thread...

Hi,
Here is a FALSSANI package for you. FALSSANI uses 1920x1080x8-bit mode with 3840x2160 virtual resolution and FALSSAN2 uses 1920x1080x16-bit mode also with 3840x2160 virtual resolution.

Please, do not forget to enable SSE under DOS before running them.
https://falcosoft.hu/sse.zip

LSS10999 wrote on 2026-05-19, 11:25:

... Some issues with SciTech VBETEST (6.53), however: - Double Buffering test doesn't seem to work as expected. Flickers and alw […]
Show full quote

...
Some issues with SciTech VBETEST (6.53), however:
- Double Buffering test doesn't seem to work as expected. Flickers and always says Page 1 of xx.
- While virtual scrolling does work, drawing is incredibly slow in Banked mode and some artifacts may be seen. Linear mode works fine.

I use VBETEST from SciTech Display Doctor 5.3 and there is no such problem for me in the double buffering test (I do not use the /2 parameter for NEWAX).

RayeR wrote on 2026-05-19, 13:37:

How can I test such big virt. resolution? When I run x-vesa, select e.g. my native 1600x1200 and test virtual resolution, I select the middle option and enter some larger number than physical res. but the verical size I got is capped by my physical res. So I get e.g. 3840x1200 and can scroll over horizontally over full 3840, verically only by 1 pixel. I can't get more verical than 1200 (newax10 loaded on GTX970).

Btw what is FALSSANI and where it came from? Can't see source in this thread...

What you are seeing is completely normal: you simply ran out of available VRAM.

You selected: 1600×1200 @ 32‑bit, then set a virtual width of 3000–4000 pixels. At 32‑bit color depth, each scanline consumes: BytesPerScanline = VirtualWidth × 4

Example with 3840 pixels: 3840 × 4 = 15360 bytes per scanline Your GTX 970 exposes only 16 MB of VRAM in LFB mode under DOS. If you compute the maximum possible virtual height:

16384 KB / 15360 ≈ 1090 scanlines But the real mode 1600×1200 already uses 1200 scanlines, so: 1090 – 1200 = VRAM insufficient

Result: horizontal panning works (depends only on virtual width), vertical panning collapses to 1 pixel, because there is no VRAM left to allocate a taller framebuffer. This is not a bug: you simply exhausted the available VRAM. If you want to experiment with very large virtual resolutions, you must use a mode that consumes very little VRAM. The best choice is: 640×480 @ 256 colors (8‑bit) Why?

1 byte per pixel very small scanlines VRAM goes a very long way you can reach extremely large virtual widths and heights

Recommended procedure: Start X‑VESA Select 640×480×256 colors Choose “Insane” Wait for the virtual‑resolution analysis to complete Enter the virtual width you want within the suggested range
– or press F10 and pick a virtual resolution from the list

The only limit will be the available VRAM With this setup you can easily get: virtual widths above 60,000 pixels virtual heights of tens of thousands of pixels smooth panning in both directions

At 1600×1200×32, increasing the virtual width to 3000–4000 pixels immediately consumes all available VRAM, leaving no memory for vertical expansion. If you want to explore huge virtual resolutions, use: 640×480×256 colors, Insane mode, and select a virtual resolution from the proposed range (or via F10).

Marco Pistella wrote on 2026-05-19, 13:35:

VBETEST becomes extremely slow when the virtual page exceeds ~30,000 pixels in either dimension, so this information will help determine whether the slowdown is due to page size or missing 4F07h sub‑functions.

I think that's what's happening. When testing 640x480x8 in VBETEST the horizontal scrolling test can reach about 34.9K pixels in the X axis, which is more than the 30K threshold you mentioned.

With Banked mode it can take a few minutes to finish drawing, though scrolling works fine. With Linear mode the drawing speed is decent.

Vertical scrolling test in Banked mode is much faster as it reached about 26.2K pixels in the Y axis, which is below the threshold.

EDIT: The precise virtual page sizes when testing 640x480x8 in VBETEST are as follows.
Horizontal: 34952 x 480
Vertical: 640 x 26214

So I think VBETEST uses as many pixels as permitted by the available memory size when performing virtual resolution tests.

Marco Pistella wrote on 2026-05-19, 13:35:

Could you please run the same tests using the /2 switch?

/2 forces VESA 2.0 compatibility, which makes VBETEST use only the basic 4F07h functions (00h, 01h, 80h) that NEWAX already supports. This should give more consistent results.

EDIT 2: Just tested the /2 switch. It certainly improved the results with VBETEST.
- Double buffering no longer flickers, with page number correctly changing as expected.
- Virtual resolution scrolling test now works with 32-bit resolutions (e.g. 640x480x32).

Previously without /2 switch, virtual resolution test only works with 8-bit resolutions. With 32-bit resolutions, after finishing drawing for the horizontal test, it immediately returns to menu after pressing a key (without going through the vertical test).

LSS10999 wrote on 2026-05-19, 14:51:

I think that's what's happening. When testing 640x480x8 in VBETEST the horizontal scrolling test can reach about 34.9K pixels in […]
Show full quote

Marco Pistella wrote on 2026-05-19, 13:35:

VBETEST becomes extremely slow when the virtual page exceeds ~30,000 pixels in either dimension, so this information will help determine whether the slowdown is due to page size or missing 4F07h sub‑functions.

I think that's what's happening. When testing 640x480x8 in VBETEST the horizontal scrolling test can reach about 34.9K pixels in the X axis, which is more than the 30K threshold you mentioned.

With Banked mode it can take a few minutes to finish drawing, though scrolling works fine. With Linear mode the drawing speed is decent.

Vertical scrolling test in Banked mode is much faster as it reached about 26.2K pixels in the Y axis, which is below the threshold.

EDIT: The precise virtual page sizes when testing 640x480x8 in VBETEST are as follows.
Horizontal: 34952 x 480
Vertical: 640 x 26214

So I think VBETEST uses as many pixels as permitted by the available memory size when performing virtual resolution tests.

Everything is normal. Please try the /2 switch and let me know the result. Thanks.

Marco Pistella wrote on 2026-05-19, 15:09:

Everything is normal. Please try the /2 switch and let me know the result. Thanks.

The /2 switch worked. Details in the previous post above that I edited.

Though I'm curious why virtual resolution test in VBETEST was broken in 32-bit modes when not using the /2 switch...

LSS10999 wrote on 2026-05-19, 15:24:

Marco Pistella wrote on 2026-05-19, 15:09:

Everything is normal. Please try the /2 switch and let me know the result. Thanks.

The /2 switch worked. Details in the previous post above that I edited.

Though I'm curious why virtual resolution test in VBETEST was broken in 32-bit modes when not using the /2 switch...

That’s normal. In 16/32‑bit modes VBETEST uses VBE function 4F07h with BL=82h (“set display start during retrace”), which is a VESA 3.0 sub‑function. NEWAX does not implement BL=82h, so the call returns 014Fh and VBETEST aborts the virtual‑resolution test immediately.
When you use the /2 switch, NEWAX forces the VESA version down to 2.0, where BL=82h does not exist. This makes VBETEST fall back to BL=80h, which is implemented, so the test works normally. Thanks for testing the /2 switch and confirming the result.

Marco Pistella wrote on 2026-05-19, 15:33:

[
The /2 switch worked. Details in the previous post above that I edited.
...

Hi,
Can you add force v-sync ON/force v-sync OFF options? That is regardless what mode the game/program invokes the TSR always skips or applies v-sync.
Thanks in advance.

Falcosoft wrote on 2026-05-19, 21:04:

Hi,
Can you add force v-sync ON/force v-sync OFF options? That is regardless what mode the game/program invokes the TSR always skips or applies v-sync.
Thanks in advance.

Good idea — force v-sync ON/OFF flags are feasible and would be straightforward to implement. I'll add them to the next version. They would work as global overrides in the 4F07h handler, ignoring whatever BL the application passes.

Marco Pistella wrote on Yesterday, 04:33:

Falcosoft wrote on 2026-05-19, 21:04:

Hi,
Can you add force v-sync ON/force v-sync OFF options? That is regardless what mode the game/program invokes the TSR always skips or applies v-sync.
Thanks in advance.

Good idea — force v-sync ON/OFF flags are feasible and would be straightforward to implement. I'll add them to the next version. They would work as global overrides in the 4F07h handler, ignoring whatever BL the application passes.

Thanks!
One more thing I have noticed: In the VESA VBE 2/3 specification (Function 4F02h - Set VBE Mode) there is a flag defined to clear video memory (or not ) when a new VBE mode is set. If bit 15 is not set in BX register the video memory should be cleared. Yet I have noticed that even if NEWAX is loaded and the bit is cleared the video memory contains the artifacts of previous contents. So without doing an explicit clear by the game/program some artifacts could be seen when a new mode is initialized.
Maybe NEWAX could fix this issue also.

@Falcosoft

The BIOS already handles the visible framebuffer clear correctly when bit 15 of BX is not set — this part of the VBE spec is implemented by the VBIOS and NEWAX does not interfere with it.
If you are seeing artifacts after a mode set, the most likely cause is the application itself not setting bit 15 correctly, or not explicitly clearing the screen before drawing.
Adding an optional flag to clear the full VRAM beyond the visible area would be technically possible, but impractical: on a 256MB card it would require iterating the entire memory via 4F05h and would be extremely slow. The benefit is unclear since that memory is always overwritten by the application before use.
Could you describe a specific case where the artifacts appear? That would help determine whether it is a VBIOS issue, an application issue, or something NEWAX could address.

Marco Pistella wrote on Yesterday, 10:28:

@Falcosoft […]
Show full quote

@Falcosoft

The BIOS already handles the visible framebuffer clear correctly when bit 15 of BX is not set — this part of the VBE spec is implemented by the VBIOS and NEWAX does not interfere with it.
If you are seeing artifacts after a mode set, the most likely cause is the application itself not setting bit 15 correctly, or not explicitly clearing the screen before drawing.
Adding an optional flag to clear the full VRAM beyond the visible area would be technically possible, but impractical: on a 256MB card it would require iterating the entire memory via 4F05h and would be extremely slow. The benefit is unclear since that memory is always overwritten by the application before use.
Could you describe a specific case where the artifacts appear? That would help determine whether it is a VBIOS issue, an application issue, or something NEWAX could address.

Hi,

The BIOS already handles the visible framebuffer clear correctly when bit 15 of BX is not set — this part of the VBE spec is implemented by the VBIOS and NEWAX does not interfere with it.

This is definitely not true in case of my GTX 960 and 970:

I can link the above quick example that works with DosBox, hardware S3 Trio 3D and Intel hardware but fails on Nvidia (together with NEWMAX):
download/file.php?id=140035
The point is in theory the application is not required to clear the memory if the 'do nor clear' flag is NOT set in the mode set command since the mode set should clear the used video memory area instead.
In the attached example the body of the mandelbrot set is not drawn but left as default. It works on non-NVIDIA hardware but not on my NVIDIA cards. The interior of the set reflects the artifacts of previous contents.

After vesaman.com finished drawing you should press any buttons 4 times to look at the 4 memory area displaying the full set.
Most likely you have to run some other programs that use VESA modes (e.g. my FALSSANI) before running the VESAMAN test otherwise there will be no previous content in the frame buffer.

Did a test with NEWAX's /M option on my RTX A4000 (Ampere). Forcing a larger memory size kind of works but doesn't look like a good idea.

Memory available to Banked mode is still 16MB regardless. Only in Linear mode can all the memory be accessed (per X-VESA).
(Q: Does X-VESA support testing virtual resolution using Linear mode instead of Banked mode? VBETEST does have such tests but I can't find how to do it in X-VESA.)
(A: After selecting resolution use F10 to toggle Banked/Linear mode.)

Trying to detect resolutions in this state resulted in some erratic behavior.
- At first with it set to 262144KB (256MB) the card (using DP connection) dropped the output resolution down to 640x480 from the usual 4K during the process. Once it entered this state, all tests with higher resolutions are marked "Fail". If I exit and relaunch X-VESA, all higher resolutions are gone except 800x600.
- Subsequent tests with lower values like 32MB or 20MB all resulted in the card "crashed" during the detection process -- it no longer outputs any signal and I have to reboot via CTRL-ALT-DEL.

With VBETEST (tested using /2):
- Forcing high amount of memory makes all modes have 32 pages available in Linear mode and page switching works as expected.
- The video card loses signal once it entered virtual resolution test (probably "crashed"), and I have to reboot.
- Haven't tested banked mode but I don't think it's going to differ much since it can still only access 16MB that way.

LSS10999 wrote on Yesterday, 12:50:

Q: Does X-VESA support testing virtual resolution using Linear mode instead of Banked mode? VBETEST does have such tests but I can't find how to do it in X-VESA.

Yes, press F10 when the mode is already selected. F10 switches between banked and linear mode for the selected resolution.

@Falcosoft

In theory, it could clear VRAM when bit 15 of BX is not set, but in practice it’s more complicated than it looks.

The main issues are:

If the mode is opened in linear framebuffer mode, calling 4F05h afterwards is unsafe and can even crash the BIOS on some Nvidia cards.

A small TSR of just a bit over 1 KB cannot realistically manage full linear framebuffer access (even with unreal mode) without growing significantly in size and complexity.

Planar modes require a completely different setup to be cleared correctly (plane selection, write mode, etc.), so they cannot be treated the same way as packed/direct color modes.

Because of these constraints, a fully generic “clear all VRAM in all modes” implementation is not feasible within NEWAX’s current design. What is realistically possible is:

clearing VRAM only for banked, non‑planar modes (i.e. packed pixel and direct color),

where bank switching is safe and the memory layout is straightforward.

So yes, I can add a VRAM clear that follows the VBE semantics, but it will necessarily be limited to banked, non‑planar modes. Linear framebuffer and planar modes are out of scope for a tiny TSR like NEWAX without significantly increasing its size and complexity.

I’ve prepared a modified test build of NEWAX for you that should address the VRAM clear behavior (within the practical limits we discussed: banked, non‑planar modes only).
Please try this version when you have time and let me know if it behaves as expected in your tests (especially with VBETEST and your own tools).
Your feedback will be very helpful before I roll this into the next public release.

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

Marco Pistella wrote on Yesterday, 13:55:

@Falcosoft […]
Show full quote

@Falcosoft

....
I’ve prepared a modified test build of NEWAX for you that should address the VRAM clear behavior (within the practical limits we discussed: banked, non‑planar modes only).
Please try this version when you have time and let me know if it behaves as expected in your tests (especially with VBETEST and your own tools).
Your feedback will be very helpful before I roll this into the next public release.

The attachment NEWAX.ZIP is no longer available

Thanks, but unfortunately it did not work. VESAMAN.COM still produced artifacts from previous content where video memory was not explicitly drawn:

BTW, VESAMAN.COM is a real mode program, uses banked 640x480x8-bit VESA mode with 1280x960 virtual resolution and bit 15 is cleared in BX when mode set is called.