Marco Pistella wrote on 2026-05-23, 08:01:

First of all, a big thank you to everyone who has been testing NEWAX 0.11 and providing feedback. Your reports are extremely val […]
Show full quote

First of all, a big thank you to everyone who has been testing NEWAX 0.11 and providing feedback. Your reports are extremely valuable and are directly driving the development of the next version.
A specific request: if you have pre-G80 hardware, please test latest NEWAX version (linked above - not GitHub version) and report your results. The current Detect_Supported_Nvidia routine has a known false positive on NV44 discrete (GeForce 6200 confirmed), and improving the detection for pre-G80 hardware requires real-world data from as many cards as possible. PCI_ID, revision and SUBSYS_ID from the /S output are particularly useful.

@Falcosoft

Hi Falcosoft, thank you for sharing the TSR — the approach is interesting and the vsync loop logic is correct in principle. However I found this issues:
1. BL=82h → BL=02h conversion is incorrect and potentially serious
BL=82h (schedule display start, VESA 3.0 asynchronous) has completely different semantics and parameters from BL=02h (set display start during retrace, synchronous). Silently converting one to the other produces incorrect behavior on any VBIOS that implements BL=02h correctly, and the caller has no way to know the conversion happened.
2. Hang on monochrome systems
The vsync loop reads unconditionally from port 3DAh. On monochrome systems the status register is at 3BAh — the loop will wait forever for a transition that will never come on that port.
3. Hang on Intel HD graphics and similar
On many Intel integrated GPUs (SandyBridge, IvyBridge, Haswell and later) port 3DAh does not behave as a standard VGA status register. The vsync loop will hang indefinitely — ironically on exactly the hardware you mentioned as having vsync problems.
4. BL not preserved on return
The caller passes BL=80h. The TSR modifies it to BL=00h before PUSHA, calls the VBIOS, then IRET. The caller receives BL=00h on return instead of the original BL=80h. A TSR must preserve input registers that are not defined as output by the VESA specification.
5. Spurious POP AX at tsrinit entry
JMP does not push anything on the stack. The POP AX at the start of tsrinit consumes the DOS initial return address (0000h) that was pushed by DOS at program load — this is harmless in practice but fragile and unnecessary.

Hi,
1. OK, I thought the 02h/82h variants are only differ in the expected data type (that is 00h/80h expects pixel data while 02h/82h expects byte data).
2. I cannot confirm this hanging problem. It works correctly on my Intel Pentium B940, I7-3632QM and I7-4770K both with X-VESA and FALSSAN3. So some other conditions have to be present on your system(s) that cause infinite loops.
It is not true that 'generally' port 3DAh does not behave as a standard VGA status register (at least it behaves as such on all of my tested Intel GFX systems). More feedback from others with Intel integrated GFX are welcome to investigate this issue further.

@Edit:
Here is my test video from my i7-3632QM Ivy Bridge system (as can be seen at 1st run there is no v-sync in either X-VESA or FALSSAN3 but after running VSYNCFIX v-sync works in both):
https://youtu.be/yolIVmB-ZwE
(BTW, Have you just read about this infinite loop problem somewhere or you actually tested and experienced it?)

3.I do not think monochrome systems are practically relevant in the context of this TSR 😀
4. Yes, but according to VBE specification the content of BL is not defined at output (only BH that is not modified). Also in case of many VBE functions it is explicitly stated that "All other registers are preserved" but Function 07 is NOT one of them. So I do not think and I also do not experience that software would rely on it.
5. Yep, it could be fixed.

I tested NEWAX 0.11 on the Quadro FX540 (GF6), and it still installs without forcing. Here is the status:

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

Also, here is the status for the RTX 4060 Ti:

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

I've tested VSYNCFIX on the FX540 and it does fix the flickering on X-VESA and Quake, but not Duke3D.

System: Asus X556UA
CPU: DualCore Intel Core i5-6200U, 2800 MHz (28 x 100)
Chipset: Intel Skylake-U IMC
GPU: Intel Skylake-U GT2 - Integrated Graphics Controller
PCI_ID: 8086-1916 / 1043-1C7D (Rev 07)

After loading VSYNCFIX.COM FALSSANI.EXE hangs the system.

Marco Pistella wrote on 2026-05-23, 10:32:

System: Asus X556UA CPU: DualCore Intel Core i5-6200U, 2800 MHz (28 x 100) Chipset: Intel Skylake-U IMC GPU: Intel Skylake-U GT2 […]
Show full quote

System: Asus X556UA
CPU: DualCore Intel Core i5-6200U, 2800 MHz (28 x 100)
Chipset: Intel Skylake-U IMC
GPU: Intel Skylake-U GT2 - Integrated Graphics Controller
PCI_ID: 8086-1916 / 1043-1C7D (Rev 07)

After loading VSYNCFIX.COM FALSSANI.EXE hangs the system.

Neither of the above listed systems are Sandy, Ivy Bridge or Haswell 😀
So the problem must be present on Broadwell+ systems.

I explicitly stated that I experienced the v-sync problem
and tested the fix on Sandy, Ivy Bridge, Haswell.
And you said it caused infinite loops on Sandy, Ivy Bridge, Haswell:

On many Intel integrated GPUs (SandyBridge, IvyBridge, Haswell and later) port 3DAh does not behave as a standard VGA status register. The vsync loop will hang indefinitely— ironically on exactly the hardware you mentioned as having vsync problems.

Then I said I could not confirm the problem (on SandyBridge, IvyBridge, Haswell).
And finally you sent the results of Skylake systems. But your tested systems are not related to my original claims since they are later than Haswell.

Overall according to the test results so far the situation is this:
On SandyBridge, IvyBridge, and Haswell port 3DAh does behave as a standard VGA status register and thus the v-sync TSR can work.
On later Broadwell/Skylake+ systems 3DAh does NOT behave as a standard VGA status register and thus the v-sync TSR cannot work (resulting in infinite loops).

BTW, SandyBridge, IvyBridge, and Haswell are the last really relevant systems in terms of native DOS VESA VBE usage since as zyzzle reported on your X-VESA topic on Broadwell/Skylake+ systems LFB write-combining and even some VGA compatibility are seriously broken.

Here is another fix for SandyBridge, IvyBridge, and Haswell integrated GFX systems:

In case of some programs that use VESA VBE modes with 8-bit DAC on returning to text mode you can get a dark/faint screen and seemingly only a restart can help. It's because according to specification returning from VBE mode the DAC should be set to default state but Intel integrated GFX does not do this. So if the program does not reset the DAC to 6-bit on exit you get this dark/faint screen. The above little utility resets the DAC so you can get back the normal/brighter screen.
Here you can see an example about the problem:
https://youtu.be/06F1SNhS0PQ?si=nkYZ61fmalJ8VS7M&t=262

Here is an example benchmark program (PERF.EXE - it needs available dos4gw in order to work) that demonstrates the above described behavior on Intel GFX systems:

NEWAX 0.11.1 - Beta test release
NEWAX 0.11.1 introduces an improved Nvidia card detection routine that better distinguishes supported (G80 and later) from unsupported (pre-G80) hardware.
The previous detection method produced false positives on some pre-G80 cards (GeForce 6200 and Quadro FX 540 confirmed). The new routine uses VESA function 4F06h as an oracle to verify whether writing to CRTC register 3Bh actually affects the scanline length — a behavior that is only possible on G80 and later architectures where the extended CRTC registers are properly implemented.
The executable is attached to this post. Source code will be published on GitHub with the final release.
This release is aimed at all testers, but particularly at owners of pre-G80 Nvidia cards.
Expected behavior:

Pre-G80 cards (GeForce 6 series and earlier): NEWAX should refuse installation with the message "Incompatible Nvidia graphic card"
G80 and later (GeForce 8 series through current): NEWAX should install correctly as before

Please run NEWAX /S and post your results including the full output. PCI_ID, revision and SUBSYS_ID are essential for building the compatibility database.
Thank you to everyone participating in the testing.

Marco Pistella wrote on Yesterday, 09:21:

NEWAX 0.11.1 - Beta test release NEWAX 0.11.1 introduces an improved Nvidia card detection routine that better distinguishes sup […]
Show full quote

NEWAX 0.11.1 - Beta test release
NEWAX 0.11.1 introduces an improved Nvidia card detection routine that better distinguishes supported (G80 and later) from unsupported (pre-G80) hardware.
The previous detection method produced false positives on some pre-G80 cards (GeForce 6200 and Quadro FX 540 confirmed). The new routine uses VESA function 4F06h as an oracle to verify whether writing to CRTC register 3Bh actually affects the scanline length — a behavior that is only possible on G80 and later architectures where the extended CRTC registers are properly implemented.
The executable is attached to this post. Source code will be published on GitHub with the final release.
This release is aimed at all testers, but particularly at owners of pre-G80 Nvidia cards.
Expected behavior:

Pre-G80 cards (GeForce 6 series and earlier): NEWAX should refuse installation with the message "Incompatible Nvidia graphic card"
G80 and later (GeForce 8 series through current): NEWAX should install correctly as before

Please run NEWAX /S and post your results including the full output. PCI_ID, revision and SUBSYS_ID are essential for building the compatibility database.
Thank you to everyone participating in the testing.

The attachment NEWAX0111.ZIP is no longer available

Hello. I tested this on a G70 and it seems to be working:

1Nvidia kEpler/maxWell/pAscal fiX - NEWAX 0.11.1а - NVIDIA mode
2Nvidia kEpler/maxWell/pAscal fiX - NEWAX 0.11.1а - NVIDIA mode
3PCI version: 3.0
4PCI specification: 001
5PCI buses: 006
6Original Logical Scanline Length (4F06h): Supported
7Original Display Start Address/Panning (4F07h): Supported
8Nvidia graphic card: Detected
9NEWAX support: Incompatible Nvidia graphic card detected
10PCI_ID: 10DE_009D - Revision: A1 - SUBSYS_ID: 10DE_0322
11Bus number: 001 - Device: 00 - Function 0
12NEWAX: Not installed

I would also like to ask you something at the same time: in your opinion, is it possible to use TSR to override the monitor's EDID under DOS (The first 128 bytes of the EDID that affect the screen refresh rate under DOS, with DVI connection, on GeForce 6800 cards and later? Where information about the video mode and refresh rate is taken from "EDID - > Detailed Data -> Preferred Timing Block"). It could look something like this: TSR.EXE /EDID=example.(bin\dat) and it would load the first 128 bytes of the EDID file and/or redefine only what the monitor sends to the video card when connected via DVI (i.e., only the data from the "Preferred Timing Block"). To make the new EDID take effect, simply switch the video mode or turn the monitor on and off.

The fact is that currently, in order to change the refresh rate in any DOS program or game, when using DVI connectivity, on nVidia cards based on NV40 (and above), as well as on integrated Intel graphics, regardless of the graphics mode selected in the game (whether it's 320x200 or 800x600), you need to flash a modified EDID to the monitor. For Quake, for example, 72hz is optimal, as the original Quake has a 72FPS limit and always enables vertical sync by default (vid_wait=2 and vid_nopageflip=0), resulting in a very smooth image (but it jitters at 60hz because 60hz and 72FPS cannot be synchronized). For Duke3D, for example, 120hz is well suited, so that the picture looks very smooth and in general, each game has its own specific frequency, depending on the FPS). Instead of flashing the monitor (using PowerStrip, for example), you can also use a hardware EDID emulator that supports different EDID profiles and is connected between the monitor and the video card, but I have a different question: is it possible to override the EDID for DVI connections programmatically using TSR (while the TSR is in memory)? I think this would be a very convenient option. Thank you.

I confirm it now refuses to install on the Quadro FX 540. I don't put the new status information as it's pretty much the same as last time.

Hi DoZator, thank you for testing — G70 confirmed as correctly detected as incompatible, exactly as expected.
Also a thank you to ockiller for confirming the fix on the Quadro FX 540.
Regarding the EDID override question: I have already worked on this exact problem. Here is the project:
https://github.com/Marco-Pistella/IPEREDID
However I have to be honest about the limitations: on DVI connections with G80 and later Nvidia cards the approach is unlikely to work. The key question is whether the VBIOS calls INT 10h 4F15h internally during 4F02h to read the EDID before programming the video timings — if it does, IPEREDID intercepts that call and works. If instead the VBIOS reads the EDID directly via I2C hardware without going through 4F15h, IPEREDID is never involved in the process and has no effect.
On G80+ with DVI my expectation is the latter — the VBIOS reads the EDID directly at hardware level, bypassing any software interception. On analog VGA connections and older hardware the situation may be different.
For your specific use case on GeForce 6800 and later with DVI, a hardware EDID emulator remains the most reliable solution. IPEREDID is worth trying but I would not expect it to work on that configuration.

If you want a detailed analysis of your monitor's EDID data, X-VESA includes a complete EDID inspector accessible via the F9 key

ockiller wrote on 2026-05-23, 09:47:

...
I've tested VSYNCFIX on the FX540 and it does fix the flickering on X-VESA and Quake, but not Duke3D.

Hi,
I have checked Duke3D and it is a special case. It seems it never used the modified VSYNCFIX code path since:
1. If in the ModeAttributes field bit 5 is not set (meaning the video mode is VGA compatible) then Duke3D does not use Function 07h with BL = 80h but uses its own code for handling v-sync.
2. If Function 0Ah is supported then it bypasses int 10h calls and uses the VBE 2.0 Protected Mode Interface.

Here is a version of VSYNCFIX that tries the mitigate the above described 2 problems:

According to my tests it works with Intel SandyBridge, IvyBridge, and Haswell as well as with Geforce 6600.
While v-sync works this way I experienced wild frame rate fluctuations between 60 and 120 FPS that makes movement slower/faster as the frame rate changes. But the exact same problem is also present with NEWAX and Duke3D.

NEWAX 0.11.1 correctly installs on my RTX A4000. No apparent regressions in this part.
Did some more tests with this version and found the following.

1. If /2 is being used (forcing VBE2.0), attempting to detect resolution in X-VESA resulted in a loss of video signal. Without /2 (VBE3.0) no issue happens. This is without using /M.
2. In VBETEST, some resolutions in Banked mode may not clean the video buffer properly, resulting in garbage when it transitions from horizontal scrolling test to vertical scrolling test. The following resolutions are affected: 800x600, 1024x768, both 8-bit and 32-bit.
This issue does not manifest in other resolutions in Banked mode, and all resolutions in Linear mode do not have this issue.
3. FALSSAN3 works, but at higher resolutions, 16MB of usable VRAM is likely not enough to draw the test image, as starting with 1280x1024x32, the image is missing the lower portion, with the missing area completely black (no garbage).
4. Forcing more memory with /M, such as /M:32768, allowed FALSSAN3 to draw everything at 1920x1080x32, and the test works without apparent garbage. However, as soon as the program exits, the monitor signal drops down to 640x480, and I can no longer access higher resolutions anymore.

EDIT: Re-tested 2-4 without /2 and there's no difference. The good part, however, is that VBETEST virtual resolution (scrolling) tests in 32-bit modes now works without /2 (Double Buffering still doesn't work yet).

Hi LSS10999, thank you for the detailed report.
1. This is expected behavior — when X-VESA detects VESA 2.0 it treats it the same as VESA 3.0 retest unlimited, since with VESA 2.0 there is no reliable upper VRAM boundary from 4F00h. This is a known behavior already documented on the A4000.
2. I will investigate.
3. Expected.
4. This is likely caused by the GPU using the VRAM area above 16MB for internal data storage — possibly including a cached copy of the monitor EDID. Forcing /M:32768 overwrites that area, corrupting the internal data. On the next mode change the VBIOS cannot find a valid EDID and falls back to 640×480. — /M should be used with caution on this card.

Here is another experimental version for exclusively Duke3D and older NVIDIA cards that are not supported by NEWAX.
This version uses a code path that is never used by NVIDIA cards with Duke3D by default since NVIDIA VBIOS does not report high resolution VESA modes as VGA compatible.
According to my tests on Geforce 6600 this code path avoids the slower/faster movement due to FPS fluctuations that can be experienced both with NEWAX and VSYNCFIX 0.2.
But to tell you the truth it seems for Duke 3D the best overall solution is the original one used by MSKVBEF7 and NEWAX /1.

BTW, both VSYNCFIX 0.2 and VSYNCFIX 0.2b should be tested up to 1024x768 since it seems Duke3D requires at least 3 pages to produce flicker free results and by default from 1280x1024 only 2 pages are reported as available on NVIDIA.

Falcosoft wrote on Yesterday, 19:21:

BTW, both VSYNCFIX 0.2 and VSYNCFIX 0.2b should be tested up to 1024x768 since it seems Duke3D requires at least 3 pages to produce flicker free results and by default from 1280x1024 only 2 pages are reported as available on NVIDIA.

Interesting! Indeed up to 1024x768 I notice that the flickering is far less pronounced, either without any fix or with VSYNCFIX 1 and 2b (which don't have any visible effect on my Quadro FX 540). VSYNCFIX 2 solves the remaining flickering but as you noticed the game is in a kind of variable slow motion.

Falcosoft wrote on Yesterday, 19:21:

But to tell you the truth it seems for Duke 3D the best overall solution is the original one used by MSKVBEF7 and NEWAX /1.

Agreed. And as I got interested on the subject thanks to all the new discoveries, I looked at your source and was surprised that MSKVBEF7 doesn't do any hacking regarding function 07h anymore, and thus doesn't do anything specific to some problematic nVidia generations. It just seems to be a good fix for any relatively modern machine with fast CPU/RAM and bus transfer speed I guess. Just to say that your tool's name is a bit misleading and doesn't do it justice IMHO 😉