Yes, you are right. When your test program was run under DOS, the functions were shown as supported, but failed. Also flickering was observed when UniVBE's vbetest was run.

I'm not familiar with the virtual scolling test aspect. Also when I initially tried the programs on XP's cmd prompt, just got a blank full screen with a blinking cursor on running VBETEST. Your test program made the nvidia display driver to crash and the system had to be restarted. Probably I missed something. Since I don't have a native Win9x system, directly skipped to DOS on a floppy.

My Video Bios Version is 84.06.0D.00.F1 dtd. 24.12.2014.

<placeholder> hoping that edit will be re-enabled

What happened?

I will share the results this weekend for a GTX 960

Thanks

Falcosoft wrote:

<placeholder> hoping that edit will be re-enabled

What happened?

Suddenly can't edit posts anymore?

Falcosoft wrote:

<placeholder> hoping that edit will be re-enabled

What happened?

Two tantrum boys had a tantrum.

gandhig wrote:

Yes, you are right. When your test program was run under DOS, the functions were shown as supported, but failed. Also flickering was observed when UniVBE's vbetest was run.
....
My Video Bios Version is 84.06.0D.00.F1 dtd. 24.12.2014.

Thanks for your test. The conclusion so far can be that not only one GTX 960 BIOS is affected since mine is Version 84.06.0D.00.6E.

I'm not familiar with the virtual scolling test aspect. Also when I initially tried the programs on XP's cmd prompt, just got a blank full screen with a blinking cursor on running VBETEST. Your test program made the nvidia display driver to crash and the system had to be restarted. Probably I missed something. Since I don't have a native Win9x system, directly skipped to DOS on a floppy.

I forgot to mention that GTX 960 under WinXP is totally unable to display any DOS VESA/VGA modes by default with available drivers (any attempt results in a blue screen in my case) . You need to patch videoprt.sys to get it working.
I have attached the package that worked for me.

I confirmed the bug on EVGA GTX 670 so probably whole Kepler family is affected. Problem persist with the latest BIOS 80.04.5C.

I please other users of nvidia GTX 4xx and 5xx series to run the test so we could find the point where the nVidiots introduced this bug.
I can only confirm that GT230 is not affected (and probably whole 2xx serie).
Does this bug still persist in latest nvidia models?

It's been a year since this thread was started; has anyone informed nVidia about the bug?

dr_st wrote:

It's been a year since this thread was started; has anyone informed nVidia about the bug?

Do you think they would care about something such obsolete as VBE? They will phase out VBE and replace it by UEFI...
I reported some older BIOS bugs to nvidia but never got a reply. We need to help ourself. Probably most painless way would be to write a TSR that hooks INT10h...

Thanks for reviving this thread.
1. Maybe the thread's title was not clear enough so it cannot attract enough attention. Now that we know that this problem is more widespread than I originally thought I renamed the title to be a little more attractive. I hope soon we will have more data to identify the point where/when things have gone wrong in Nvidia' BIOS cooking laboratory 😀
2. The problem is this function is not an optional one (it's mandatory since version 1.2 of VBE) so even if there is an option to get the supported status of this function it's likely that games when detect the presence of VBE 1.2/2 rightfully try to use it without first checking the supported status. So I do not think games implemented an alternative fallback code path. Or as in the case of Quake1 and alternative code path exists (activated by vid_nopageflip 1), but you can only choose it manually.
Nevertheless we could try to write a patch. INT 10h should be intercepted and when function 07 is called we should give back the status of not supported.
I have a template for this so I can write the patch/TSR and then we could test if it makes any difference with problematic games.
Stay tuned 😀

OK, I have made a TSR that masks INT 10h 4F07h calls and reports function status as not supported.
It should be tested if it makes any difference in case of problematic games (I do not think so, but a try cannot hurt)

Thanks, I just have the same idea according to VBE spec:
VBE RETURN STATUS
AL == 4Fh: Function is supported
AL != 4Fh: Function is not supported
AH == 00h: Function call successful
AH == 01h: Function call failed
AH == 02h: Software supports this function, but the hardware
does not
AH == 03h: Function call invalid in current video mode
So it should be enough to set AL=0, AH=1 for function 7. I'll try your patch this night.

Intel will EOL'ed legacy BIOS support in year 2020. INT10h, INT13h and rest of the original IBM BIOS INTxx software interface will be gone.

kjliew wrote:

Intel will EOL'ed legacy BIOS support in year 2020. INT10h, INT13h and rest of the original IBM BIOS INTxx software interface will be gone.

Sure, I know but it will probably take longer. Intel was already a pioneer in deprecating legacy stuff (ISA, PCI, etc.) but other manufacturers like Gigabyte may be more conservative and they could support CSM longer. Also it is possible to compile opensource SeaBIOS project as an UEFI module and insert into CSM-less UEFI image. I hope so, never tried deal with UEFI modding. Anyway PC-compatible era is going to dead end, after intel will remove realmode and v86 mode from CPU no DOS will be able to run on it. So we have to stick with latest reasonably compatible HW...

Falcosoft wrote:

OK, I have made a TSR that masks INT 10h 4F07h calls and reports function status as not supported.
It should be tested if it makes any difference in case of problematic games (I do not think so, but a try cannot hurt)

MSKVBEF7.zip

As expected it didn't help (any change in Blood). Maybe because there is still page flipping support reported somewhere in VESA info - UniVBETest reports it regardless TSR loaded and line trest is flickering in all resolution - see below. It's strange that Quake doesn't flicker in some modes (in my case afected modes are: 320 x 240, 320 x 400, 640 x 400, 640 x 480, 800 x 600, 1024 x 768 - about a half of total available modes.

I found a workaround for Blood & Duke - load NOLFBLIM TSR to disable LFB. Then it's not flickering but less performance. It is still playable up to 1024 x 768 so better than nothing. But I'd rather find some better fix. Maybe comparing of good and bad VBIOS disassembly could point the problem. Here's DASM of my runtime VBIOS image, entry point of INT10h handler is at 19D4h
http://rayer.g6.cz/1tmp/GTX670DA.TXT

Beside in Ruthan's thread Old+Modern videocards pure DOS benchmarking- which one is fastest?, need your numbers + analysis, 320x200 to 1600x1200! I found he stated:

Geforce 730 difference, i have two G730 cards, one with GDRR3 and one with GDRR5 - i though than difference would be only in memory, but card with GDRR3 has not blinking problem and working with VIA 880 chipset, GDRR5 card has blinking problem (again Q1 only Q2 same resolution is not affected) and not working with VIA no picture at all + broken Text modes in FileWizzard. It could be manufacturer or bios difference, slower if Gigabyte, faster is Zotac, its i also has 4 GB of VRAM what is of course useless on such card..

So this prove that not ALL modern nvidia cards are afected by this bug and there may be a chance to find also some 6XX BIOS that is not affected and could be flashed to GTX 670 after some mods. Or if I get a dump of good video BIOS from GTX 730 I can disassemble it and try to look for code of VBE func. 07h and compare it with bad version. Good function then may be used as a TSR or direct BIOS insertion patch...

Thanks to Ruthan providing me runtime video BIOS dumps of both GT 730 cards. The 1st visible difference is that card without his issue use older BIOS version 70.08.D5.00.04 while newer affected card use BIOS version 80.28.92.00.8D. So this can imply that all BIOSes with major version 80.x are bad and older 70.x are OK - this inludes GTX 5xx and 4xx families that should be OK...

I dunno if it matters, but that slower 730 is PCI-E 2.0 card, faster is PCI-E 3.0

ruthan wrote:

I dunno if it matters, but that slower 730 is PCI-E 2.0 card, faster is PCI-E 3.0

This doesn't matters. But it is interesting that the same GPU is presented with various PCIE spec. This makes stronger my assumption that older Gigabyte card use some older re-labeled GPU (probably GT 630? it's a PCIE 2.0 chip: https://www.geforce.com/hardware/desktop-gpus … /specifications) as they needed to sold out old stocks. So they used also older video BIOS with major version 70 that is not crippled yet.

The GT730 has a massively split personality as there are rebadges:
1. True GT730 - Kepler core with 64 bit GDDR5
2. Rebadged GT630 V2 - Kepler core with 64 bit DDR3
3. Rebadged GT430 - Fermi core with 128 bit DDR3
Though in my resource, they are all down as PCI-E 2.0, though the two Keplers only implement X8