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).
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..
Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough raw HW.
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.
Schwarz Wald-from France to Ukraine, from Denmark to Austria. Celts+German+Slavs melting pot.
RankOldbie
Rank
Oldbie
Posts
1935
Joined
2013-03-07, 04:01
Location
Schwarz Wald-from France to Ukraine, from Denmark to Austria. Celts+German+Slavs melting pot.
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.
Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough raw HW.
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...
Schwarz Wald-from France to Ukraine, from Denmark to Austria. Celts+German+Slavs melting pot.
RankOldbie
Rank
Oldbie
Posts
1935
Joined
2013-03-07, 04:01
Location
Schwarz Wald-from France to Ukraine, from Denmark to Austria. Celts+German+Slavs melting pot.
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.
Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough raw HW.
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 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 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.
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:
…Show last 17 lines
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 Pistellawrote on Today, 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!
Last edited by Falcosoft on 2026-05-04, 11:04. Edited 2 times in total.
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.
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!
Last edited by Falcosoft on 2026-05-04, 11:34. Edited 1 time in total.
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!
