Yes, it is possible to trap only specific VBE subfunctions and emulate them some way. But one need to know GPU in detailed to reimplement it or if there'se no HW equivalent functionality in GPU it would needed to be SW emulated - very slow. Then it's better to tell the application that function is not supported to don't use it if possible (this is how simply Falcosoft did it).

About using Linux source code, Intel and AMD moved to fully open source drivers long time about.

There were some changes in the last 2 years.
I read that previous trash Nouvea driver for Geforce 9xx and 10xx is now good overall performance in 3D which is still great, average FPS are good, but is stuttering, its 10 month old report, but nowest, which i found:
https://www.reddit.com/r/linux_gaming/comment … ver_perfomance/
Im usually looking for Phoronix tests, found only old test:
https://www.phoronix.com/review/nouveau-kepler-2021/2 - Kepler test, finally patches to get not boot, but 3D clocks when its needed - performance is like 30% to 80% ~60% on average what is quite too. Im not sure what real clock has card in Windows 9x, if 3D clocks are activated, or it runs in boot slimmer mode.
i have found is from the 2019, where performance is abysmal: https://www.phoronix.com/review/nvidia-nouveau-2019/2
I searched more and only found out that Nouvea project leader resigned in 2024 due classic Linux toxic environmental issues.
same for new Vulkan implementation: https://www.phoronix.com/review/nvk-vulkan-performance/2
Also Nvidia released their own open source drivers for Linux, its better than be better, kernel part is open source and user space part its using there closed source firmware blob, some overview is here:
https://arstechnica.com/gadgets/2024/07/nvidi … kernel-modules/
https://developer.nvidia.com/blog/nvidia-tran … kernel-modules/

Well its not simple like other devices drivers, because if on wrong gpu these drivers have like million lines of code and they are a lot of per game basis adjustment..

ruthan wrote on 2025-05-12, 17:37:

About using Linux source code, Intel and AMD moved to fully open source drivers long time about. […]
Show full quote

About using Linux source code, Intel and AMD moved to fully open source drivers long time about.

There were some changes in the last 2 years.
I read that previous trash Nouvea driver for Geforce 9xx and 10xx is now good overall performance in 3D which is still great, average FPS are good, but is stuttering, its 10 month old report, but nowest, which i found:
https://www.reddit.com/r/linux_gaming/comment … ver_perfomance/
Im usually looking for Phoronix tests, found only old test:
https://www.phoronix.com/review/nouveau-kepler-2021/2 - Kepler test, finally patches to get not boot, but 3D clocks when its needed - performance is like 30% to 80% ~60% on average what is quite too. Im not sure what real clock has card in Windows 9x, if 3D clocks are activated, or it runs in boot slimmer mode.
i have found is from the 2019, where performance is abysmal: https://www.phoronix.com/review/nvidia-nouveau-2019/2
I searched more and only found out that Nouvea project leader resigned in 2024 due classic Linux toxic environmental issues.
same for new Vulkan implementation: https://www.phoronix.com/review/nvk-vulkan-performance/2
Also Nvidia released their own open source drivers for Linux, its better than be better, kernel part is open source and user space part its using there closed source firmware blob, some overview is here:
https://arstechnica.com/gadgets/2024/07/nvidi … kernel-modules/
https://developer.nvidia.com/blog/nvidia-tran … kernel-modules/

Well its not simple like other devices drivers, because if on wrong gpu these drivers have like million lines of code and they are a lot of per game basis adjustment..

I heard about the new, open nVidia kernel drivers before. It's not useful for older cards.

I think at least Turing is required for those drivers, and the VGA BIOS on Turing has become too broken to be of any good use. Games like Titus the Fox would simply give a garbled text-mode screen (can exit with ESC however), suggesting a failure in some crucial VGA BIOS calls.

Nouveau's usefulness is limited. From my experience on newer cards (e.g. Fermi), resolutions with higher refresh rates (e.g. 120Hz) can only be attained with the proprietary driver. It may be useful for some older, pre-CUDA video cards, however.

It seems that olders card supported by Nvidia Open drivers is Geforce 1650 source https://github.com/NVIDIA/open-gpu-kernel-modules, but could argue that its very similar to 10xx cards, which are not far from 9xx. You dont need drivers for exact card to reuse a lot of source code to help you with development.

Nouveau driver are not great, but are still much better than start from the scratch and they seems to have much smaller code base, to start.

I hope that sooner or later will someone to 9x driver for modern cards, i could happen this year, or it could take 10 years we will see.

I think that even 2D drivers are too complex (compated to oss/alsa linux sound drivers) and it would take so many mandays to port it to win9x. Scitech did own drivers in the past but it didn't bring them profit for that effort so stopped it...

In theory there is maybe one other way how to it - use Nvidia HW driver only for putpixels in 2D GDIplus and settings videomodes and use PCem/86Box code doing all graphics magic in software by CPU, but it would still need putpixel with decent speed, there is even some proof of concent how to use multicore cpus from Rloew, so it could run on not used cpu cores.
Or maybe use Swiftshader for the same, but it would still need a lot of work.

Hi,

I own a Nvidia GT740 affected by this bug and I can confirm the issue on that card. Tracing the INT 10h execution through the BIOS in real mode reveals that function 4F07h is imply absent from the ROM — the function does not exist at all, likely cut due to the limited ROM space available for VGA legacy emulation on modern Nvidia GPUs. This is probably also one of the reasons why support for this function was dropped in the first place.

My proposed solution is a real-mode TSR that intercepts INT 10h function 4F07h and reimplements the missing functionality. The main technical challenges are:

1) On these GPUs, CRTC registers above index 19h are not accessible with a single key — they require a 32-bit unlock sequence via port 3CAh. Using this unlock causes the VGA emulation subsystem to enter an inconsistent state, which adds complexity to the implementation.

2) The first 16 bits of the display start address follow the standard VGA registers, but the upper bits require direct MMIO access via BAR0 in the card's PCI address space. This requires Unreal Mode for 32-bit addressing. The procedure, implemented via the GS register:
- Save the current GDT for GS
- Load a minimal Unreal Mode GDT for GS
- Locate BAR0 in PCI config space
- Write the display start address via MMIO registers
- Restore the original GDT for GS

3) The TSR will also disable PM/32 support via function 4F0Ah to force any caller to fall back to 4F07h.

4) BL=00h (Set Display Start), BL=01h (Get Display Start) and BL=80h (Set Display Start during retrace) will all be handled. On these cards 3DAh bit 3 works correctly, so retrace synchronization via BL=80h should be feasible.

I have identified the unlock key and the BAR0 access procedure on my GT740, but full technical feasibility is not yet confirmed across the Kepler/Maxwell/Pascal families
— this is precisely why I am looking for betatester with affected cards before committing to the full implementation.

This is not a trivial undertaking and I am not making any promises. If the implementation proves feasible, source code will be published on this forum.

Is anyone available with a Kepler, Maxwell or Pascal card willing to test?

Marco Pistella wrote on 2026-05-02, 12:12:

Hi, […]
Show full quote

Hi,

I own a Nvidia GT740 affected by this bug and I can confirm the issue on that card. Tracing the INT 10h execution through the BIOS in real mode reveals that function 4F07h is imply absent from the ROM — the function does not exist at all, likely cut due to the limited ROM space available for VGA legacy emulation on modern Nvidia GPUs. This is probably also one of the reasons why support for this function was dropped in the first place.

My proposed solution is a real-mode TSR that intercepts INT 10h function 4F07h and reimplements the missing functionality. The main technical challenges are:

1) On these GPUs, CRTC registers above index 19h are not accessible with a single key — they require a 32-bit unlock sequence via port 3CAh. Using this unlock causes the VGA emulation subsystem to enter an inconsistent state, which adds complexity to the implementation.

2) The first 16 bits of the display start address follow the standard VGA registers, but the upper bits require direct MMIO access via BAR0 in the card's PCI address space. This requires Unreal Mode for 32-bit addressing. The procedure, implemented via the GS register:
- Save the current GDT for GS
- Load a minimal Unreal Mode GDT for GS
- Locate BAR0 in PCI config space
- Write the display start address via MMIO registers
- Restore the original GDT for GS

3) The TSR will also disable PM/32 support via function 4F0Ah to force any caller to fall back to 4F07h.

4) BL=00h (Set Display Start), BL=01h (Get Display Start) and BL=80h (Set Display Start during retrace) will all be handled. On these cards 3DAh bit 3 works correctly, so retrace synchronization via BL=80h should be feasible.

I have identified the unlock key and the BAR0 access procedure on my GT740, but full technical feasibility is not yet confirmed across the Kepler/Maxwell/Pascal families
— this is precisely why I am looking for betatester with affected cards before committing to the full implementation.

This is not a trivial undertaking and I am not making any promises. If the implementation proves feasible, source code will be published on this forum.

Is anyone available with a Kepler, Maxwell or Pascal card willing to test?

I still have 2 Maxwell cards in active use: GTX 960 and GTX 970 so beta testing is not a problem.

Falcosoft wrote on 2026-05-02, 13:01:

Marco Pistella wrote on 2026-05-02, 12:12:

Hi, […]
Show full quote

Hi,

I own a Nvidia GT740 affected by this bug and I can confirm the issue on that card. Tracing the INT 10h execution through the BIOS in real mode reveals that function 4F07h is imply absent from the ROM — the function does not exist at all, likely cut due to the limited ROM space available for VGA legacy emulation on modern Nvidia GPUs. This is probably also one of the reasons why support for this function was dropped in the first place.

My proposed solution is a real-mode TSR that intercepts INT 10h function 4F07h and reimplements the missing functionality. The main technical challenges are:

1) On these GPUs, CRTC registers above index 19h are not accessible with a single key — they require a 32-bit unlock sequence via port 3CAh. Using this unlock causes the VGA emulation subsystem to enter an inconsistent state, which adds complexity to the implementation.

2) The first 16 bits of the display start address follow the standard VGA registers, but the upper bits require direct MMIO access via BAR0 in the card's PCI address space. This requires Unreal Mode for 32-bit addressing. The procedure, implemented via the GS register:
- Save the current GDT for GS
- Load a minimal Unreal Mode GDT for GS
- Locate BAR0 in PCI config space
- Write the display start address via MMIO registers
- Restore the original GDT for GS

3) The TSR will also disable PM/32 support via function 4F0Ah to force any caller to fall back to 4F07h.

4) BL=00h (Set Display Start), BL=01h (Get Display Start) and BL=80h (Set Display Start during retrace) will all be handled. On these cards 3DAh bit 3 works correctly, so retrace synchronization via BL=80h should be feasible.

I have identified the unlock key and the BAR0 access procedure on my GT740, but full technical feasibility is not yet confirmed across the Kepler/Maxwell/Pascal families
— this is precisely why I am looking for betatester with affected cards before committing to the full implementation.

This is not a trivial undertaking and I am not making any promises. If the implementation proves feasible, source code will be published on this forum.

Is anyone available with a Kepler, Maxwell or Pascal card willing to test?

I still have 2 Maxwell cards in active use: GTX 960 and GTX 970 so beta testing is not a problem.

I will get back to you when I have something concrete to test.
Thank you for the availability.

Marco Pistella wrote on 2026-05-02, 12:12:

Is anyone available with a Kepler, Maxwell or Pascal card willing to test?

I have a GTX 950 if you want another sample.

Marco Pistella wrote on 2026-05-02, 12:12:

Is anyone available with a Kepler, Maxwell or Pascal card willing to test?

I have a GTX650, BIOS version 80.07.35.00.60, from 2012, which is affected by the bug. Will be happy to test.

Still have GTX 970 and 670 and some 730 or 745 for testing.

Preliminary test for a possible VESA 4F07h implementation
on Nvidia Kepler/Maxwell/Pascal

As a first step toward a TSR that implements the missing
4F07h function on affected Nvidia cards, I have written
a small test program that checks whether the standard VGA
CRTC registers 0Ch/0Dh are functional and produce an
actual hardware scroll.

Test sequence:

1) Opens video mode 640×480×8 via function 4F02h/101h
(error if the mode cannot be opened)
2) Reads the horizontal scanline via function 4F06h/BL=01h
(error if not supported)
3) Draws two white pixels in the top-left and top-right
corners of the screen
4) Waits for a keypress
5) On keypress, writes a 1-pixel vertical offset to CRTC
registers 0Ch and 0Dh
6) Verifies that the registers actually accepted the new
values (error if not)
7) Betatester verification: the two white pixels MUST
disappear from the screen. If they do not, the VGA
registers are present but the display hardware is not
reading them — which means the CRTC approach is not
viable for that card.
😎 Whether the pixels disappear or not, please report
the PCI_ID of the card and the legacy BIOS ROM version
if available.

Note on step 7: a card can accept the register values
(step 6 passes) while the display hardware ignores them
completely. This is the critical distinction. If the dots
do not disappear, the VGA registers are present but
disconnected from the actual display controller, and the
entire TSR approach via CRTC 0Ch/0Dh is not viable for
that card. The viable fallback in that case would be
direct MMIO access via BAR0 — a more complex path that
will be explored if necessary.

My result:

Card: Nvidia GeForce GT740
PCI_ID: PCI\VEN_10DE&DEV_0FC8&SUBSYS_0FC810DE&REV_A1
Legacy BIOS: 80.07.DF.00.03
Func 4F02h: OK
Func 4F06h: OK
CRTC registers 0Ch/0Dh: accepted and verified
Hardware vertical scroll of 1 pixel: working

The GT740 passes all steps including the visual
verification. Looking forward to results on GTX 960,
GTX 970, and any other Kepler/Maxwell/Pascal card
available.

Source code:

1	.386
2	CODE SEGMENT PARA PUBLIC USE16 'CODE'
3	ASSUME	CS:CODE,DS:CODE,ES:CODE,SS:CODE
4	ORG 	100h
5
6start_code:
7	mov	ds: word ptr [fail_msg_pointer],OFFSET fail_message_01
8	mov	ax,4F02h
9	mov	bx,101h
10	int	10h
11	cmp	ax,4Fh
12	jne	exit_fail
13	mov	ds: word ptr [fail_msg_pointer],OFFSET fail_message_02
14	mov	ax,4F06h
15	mov	bx,1h
16	int	10h
17	cmp	ax,4Fh
18	jne	exit_fail
19	dec	bx
20	push	0A000h
21	pop	es
22	mov	es: byte ptr [0h],0Fh
23	mov	es: byte ptr [bx],0Fh
24	xor	ah,ah
25	int	16h
26	mov	ds: word ptr [fail_msg_pointer],OFFSET fail_message_03
27	mov	dx,3D4h
28	mov	al,0Dh
29	out	dx,al
30	inc	dx
31	mov	al,bl
32	out	dx,al
33	dec	dx
34	mov	al,0Ch
35	out	dx,al
36	inc	dx
37	mov	al,bh
38	out	dx,al
39	dec	dx
40	mov	al,0Dh
41	out	dx,al
42	inc	dx
43	in	al,dx
44	cmp	al,bl
45	jne	exit_fail
46	dec	dx
47	mov	al,0Ch
48	out	dx,al
49	inc	dx
50	in	al,dx
51	cmp	al,bh
52	jne	exit_test	
53	xor	ah,ah
54	int	16h
55exit_test:
56	mov	ax,3h
57	int	10h
58	mov	ax,4C00h
59	int	21h
60exit_fail:

61	mov	ah,9h
62	mov	dx,ds: word ptr [fail_msg_pointer]
63	int	21h
64	jmp	exit_test
65
66fail_message_01:
67	DB	'Fail 4F02h',0Dh,0Ah,'$'
68fail_message_02:
69	DB	'Fail 4F06h',0Dh,0Ah,'$'
70fail_message_03:
71	DB	'Fail set/get VGA regs',0Dh,0Ah,'$'
72fail_msg_pointer:
73	DW	?
74
75	CODE ENDS
76	END	start_code

Marco Pistella wrote on 2026-05-04, 08:29:

Preliminary test for a possible VESA 4F07h implementation on Nvidia Kepler/Maxwell/Pascal […]
Show full quote

Preliminary test for a possible VESA 4F07h implementation
on Nvidia Kepler/Maxwell/Pascal

As a first step toward a TSR that implements the missing
4F07h function on affected Nvidia cards, I have written
a small test program that checks whether the standard VGA
CRTC registers 0Ch/0Dh are functional and produce an
actual hardware scroll.

Test sequence:

1) Opens video mode 640×480×8 via function 4F02h/101h
(error if the mode cannot be opened)
2) Reads the horizontal scanline via function 4F06h/BL=01h
(error if not supported)
3) Draws two white pixels in the top-left and top-right
corners of the screen
4) Waits for a keypress
5) On keypress, writes a 1-pixel vertical offset to CRTC
registers 0Ch and 0Dh
6) Verifies that the registers actually accepted the new
values (error if not)
7) Betatester verification: the two white pixels MUST
disappear from the screen. If they do not, the VGA
registers are present but the display hardware is not
reading them — which means the CRTC approach is not
viable for that card.
😎 Whether the pixels disappear or not, please report
the PCI_ID of the card and the legacy BIOS ROM version
if available.

Note on step 7: a card can accept the register values
(step 6 passes) while the display hardware ignores them
completely. This is the critical distinction. If the dots
do not disappear, the VGA registers are present but
disconnected from the actual display controller, and the
entire TSR approach via CRTC 0Ch/0Dh is not viable for
that card. The viable fallback in that case would be
direct MMIO access via BAR0 — a more complex path that
will be explored if necessary.

Hi,
Geforce GTX 970 - BIOS version: 84.04.84.00.29
PCI\VEN_10DE&DEV_13C2&SUBSYS_31611462&REV_A1
1. After running the test 2 pixels appear in the top left/right corners of the screen.
2. After a key press both pixels disappear.
3. After another key press the program quits nicely.
So it seems the test was successful on this card!

@Edit:
Geforce GTX 960 - BIOS version: 84.06.0D.00.6E
1. After running the test 2 pixels appear in the top left/right corners of the screen.
2. After a key press both pixels disappear.
3. After another key press the program quits nicely.
So it seems the test was successful also on this card!

Falcosoft wrote on 2026-05-04, 10:41:

Hi,
Geforce GTX 970 - BIOS version: 84 ...[CUT]

Thank you — this is exactly the result I was hoping for.

GTX 970 (Maxwell 2.0), BIOS 84.04.84.00.291: CRTC
registers 0Ch/0Dh confirmed functional, hardware scroll
working.

Combined with the GT740 result, this confirms that the
CRTC approach is viable on at least two different Nvidia
cards across different generations. The TSR implementation
via registers 0Ch/0Dh is now the primary path to pursue.

Could you also run the test on the GTX 960 when you have
a chance? Having both Maxwell cards confirmed would be
very useful before starting the full implementation.

Marco Pistella wrote on 2026-05-04, 10:47:

Thank you — this is exactly the result I was hoping for. […]
Show full quote

Falcosoft wrote on 2026-05-04, 10:41:

Hi,
Geforce GTX 970 - BIOS version: 84 ...[CUT]

Thank you — this is exactly the result I was hoping for.

GTX 970 (Maxwell 2.0), BIOS 84.04.84.00.291: CRTC
registers 0Ch/0Dh confirmed functional, hardware scroll
working.

Combined with the GT740 result, this confirms that the
CRTC approach is viable on at least two different Nvidia
cards across different generations. The TSR implementation
via registers 0Ch/0Dh is now the primary path to pursue.

Could you also run the test on the GTX 960 when you have
a chance? Having both Maxwell cards confirmed would be
very useful before starting the full implementation.

Meanwhile I edited my previous post but here is the result:

Geforce GTX 960 - BIOS version: 84.06.0D.00.6E
PCI\VEN_10DE&DEV_1401&SUBSYS_36901458&REV_A1
1. After running the test 2 pixels appear in the top left/right corners of the screen.
2. After a key press both pixels disappear.
3. After another key press the program quits nicely.
So it seems the test was successful also on this card!

Gigabyte Geforce GTX 1070 Ti - BIOS version: 86.04.85.00.A0
PCI\VEN_10DE&DEV_1B82&SUBSYS_37941458&REV_A1
1. After running the test 2 pixels appear in the top left/right corners of the screen.
2. After a key press both pixels disappear.
3. After another key press the program quits nicely.
So it seems the test was successful on this card!

Hi,
Geforce GTX 650 - BIOS version: 80.07.35.00.60
NVIDIA Corporation GK107 [GeForce GTX 650] [10de:0fc6] (rev a1)
1. After running the test 2 pixels appear in the top left/right corners of the screen.
2. After a key press both pixels disappear.
3. After another key press the program quits nicely.
So it seems the test was successful on this card!

Just did this test on some of my systems that have nVidia video cards in active use.
All the systems are using DisplayPort connection.

1. Quadro K6000 (Success) […]
Show full quote

1. Quadro K6000 (Success)

GK110-B1 (Kepler)
10DE:103A - 10DE:1036
BIOS: 80.80.35.00.06

1. After running the test 2 pixels appear in the top left/right corners of the screen.
2. After a key press both pixels disappear.
3. After another key press the program quits nicely.

2. Quadro P5000 (Success) […]
Show full quote

2. Quadro P5000 (Success)

GP104-A1 (Pascal)
10DE:1BB0 - 1028:11B2
BIOS: 86.04.40.00.09

1. After running the test 2 pixels appear in the top left/right corners of the screen.
2. After a key press both pixels disappear.
3. After another key press the program quits nicely.

3. RTX A4000 (Failed) […]
Show full quote

3. RTX A4000 (Failed)

GA104-A1 (Ampere)
10DE:24B0 - 103C:14AD
BIOS: 94.04.57.00.0B

After running the test, the screen clears, then immediately returns to DOS prompt (no error messages).
With updated version, it reports "Fail 4F06h".

From the already submitted results I think most cards from Kepler to Pascal can pass this test.

I'm afraid more stuffs have been broken since Turing. I do have a T600 but it's not in active use right now.

From what I remembered when I used the T600 back then, some games, namely Titus the Fox, failed to change mode and left in a garbled text mode that I can at best press ESC to safely return to DOS prompt.

And Ampere behaves just like Turing if not worse.

EDIT: Looks like the code should print error messages if it encounters failure, but on my Ampere system, the screen simply cleared, then immediately returned to the DOS prompt, without any (visible) error message.

EDIT 2: Post updated to reflect the updated test code which can properly report the error message in my case.

Update — BIOS trace results on GT740 and GT210

Some significant findings from today's debugging session
with TurboDebugger on the GT740 and GT210 BIOS ROMs.

GT740 — 4F07h confirmed deliberately removed

The 4F07h handler on the GT740 consists of exactly two
instructions:

mov ax, 014Fh
ret

The function is not broken — it was intentionally
stripped. This confirms that the absence is a deliberate
design decision, not a bug or an oversight.

GT210 — 4F07h fully implemented

The GT210 BIOS contains a complete and functional 4F07h
implementation using CRTC indices 37h and 80h for
extended address mapping, with an unlock sequence via
port 3CAh. The function is alive and working on this
architecture.

Two possible paths forward

1) Port the GT210 routine to a TSR and test whether it
works on Kepler/Maxwell/Pascal. The CRTC indices and
unlock sequence may or may not be compatible with
the newer architecture — this needs to be verified
on a GTX 960/970.

2) CRTC indices 37h and 80h also appear to allow mapping
BAR0 as a PC I/O port: two OUT dx,eax instructions
at the BAR0 base address are sufficient to reach the
MMIO registers without requiring Unreal Mode or 32-bit
addressing. This simplifies the TSR significantly.

Unlock key

The firmware unlock key used in the GT210 BIOS routine
is 2469FDB9h. This value does not appear in any publicly
available documentation, to my knowledge.

More details and test results to follow.