Falcosoft wrote on Today, 04:42:

OK, I have tried once again and X-VESA's virtual resolution test could really use 3840x2160 virtual resolution in 1920x1080x8-bi […]
Show full quote

RayeR wrote on Yesterday, 23:57:

Falcosoft wrote on Yesterday, 22:40:

But on my GTX 970 and 960 cards the around 4MB video memory limit is present in practice even in LFB modes (although reported as 16MB).

ORLY? Once when I got in touch with 4k Dell LCD I tested on my GTX 970 VESA LFB modes 3840 x 2160 / 8 and 16 bpp so it definitely used more than 4MB for LFB:

OK, I have tried once again and X-VESA's virtual resolution test could really use 3840x2160 virtual resolution in 1920x1080x8-bit LFB mode.
But my test program (that actually works perfectly on Intel's integrated GFX) still produces the same problem. That is it can only draw to about 4MB video memory in LFB mode.
The interesting thing is that since I tried my test program after running X-VESA's virtual resolution test I got no garbage at the unreachable memory region but the test image left by X-VESA's virtual resolution test 😀
Here is a demo video about this:

https://youtu.be/QLI8Y-hXHwk

The attachment FALSSANI_1920x1080.zip is no longer available

@Edit:
BTW, my test program's result is somewhat confirmed by VBETEST.EXE that can be found in Scitech's UNIVBE package. That is only a ~4MB buffer can be created even in LFB mode by the program's virtual resolution test:

The attachment Univbe_VBETEST.jpg is no longer available

Maybe the different results are because both my test program and VBETEST.EXE from UNIVBE uses 32-bit protected mode while X-VESA does not.

I have found what the problem is:
VBE Function 06 - Set Logical Scanline Length in DX register returns the number of scanlines possible in the set virtual resolution mode. In case of my cards this call returns the number of scanlines possible in banked mode (about 4 MB) even when it is called after an LFB mode is set. After I modified NEWAX source to return double the amount of scanlinlines in DX both my test program and UNIVBE's VBETEST.EXE started to use the doubled memory region without problems:

1continue_int_10_3:
2	cmp	ax,(VESA_ID SHL 8h) + VESA_FUNC_SET_GET_SCANLINE
3	jne	continue_int_10_4
4	pushf
5	call 	cs: dword ptr [old_int_10_off]
6	cmp	ax,VESA_ID
7	jne	no_set_scanline
8	test	cs: byte ptr [status_flag_0],NEWAX_FLAG_VESA_MODE
9	je	no_set_scanline
10	mov	cs: word ptr [byte_per_scanline],bx
11	[b]add dx, dx[/b]
12no_set_scanline:  

This way actually I can use the doubled ~8 MB of video memory also from banked modes! This means that the ~4 MB limit is not a real hardware limit. 3840 x 2160 x 8-bit virtual resolution works perfectly without artifacts in banked mode.

Maybe an option can be added to NEWAX to report the double amount of available scanlines for the ones like me 😀

BTW, I also changed what value is put to ModeInfoBlock.NumberOfImagePages since according to my tests in this filed the same value is expected by VBETEST.EXE from UNIVBE as in ModeInfoBlock.LinNumberOfImagePages and not as in ModeInfoBlock.BnkNumberOfImagePages. This way VBETEST.EXE from UNIVBE can differentiate between the available image pages in banked vs. LFB modes.
With the current version of NEWAX VBETEST.EXE from UNIVBE only lists the same amount of image pages available for LFB modes as for banked modes.

1continue_number_pages:
2	movzx	eax,cs: word ptr [vesa_memory]
3	shl	eax,10h
4	push	eax
5	xor	edx,edx
6	div	esi
7	dec	ax
8	[b]mov	es: byte ptr [di].ModeInfoBlock.NumberOfImagePages,al[/b]
9	mov	es: byte ptr [di].ModeInfoBlock.LinNumberOfImagePages,al	
10	pop	eax
11	test	cs: byte ptr [status_flag_0],NEWAX_FLAG_LINEAR_MODE
12	jne	nvidia_high_vram
13	cmp	esi,NVIDIA_BANKED_VRAM SHL 10h
14	ja	nvidia_high_vram	
15	mov	eax,NVIDIA_BANKED_VRAM SHL 10h
16 

@Edit:
Modified NEWAX06 3840 x 2160 x 8-bit virtual resolution Banked mode test video (it works perfectly):
https://youtu.be/2PCI_7Oxz8Q

PS:
It seems X-VESA can detect the falsely reported ~4 MB available scanlines in LFB modes and can use more than the reported scanlines in LFB modes (most likely that's why it worked even with the original NEWAX why other programs do not)
but X-VESA actually fails to detect that the reported ~4 MB available video memory is also false in case of banked modes and refuses to use the actually available more than ~4 MB video memory in banked modes.

Several things:

1) The problem with FALSSANI.EXE also occurs on Nvidia GT550Ti and GT210 cards, using the original 4F07h and 4F06h functions and with NEWAX not loaded in memory.

2) There is a bug in the Nvidia function (certainly from the GT210 onward) where DX should return the maximum number of vertical scanlines (calculated based on the video mode and the available video memory).

3) This is how video memory works on Nvidia graphics cards at 8/15/16/32 bits per pixel, certainly from the GT210 up to at least the GT1050:

- in banked mode, 4160 KB are available

- in linear mode, 16384 KB are available (sometimes reduced to 14336 KB)

4) The 4F06h function is bugged: DX should report the maximum number of supported vertical scanlines, but it always performs the calculation using 4096 KB, EVEN if the video mode was opened in linear mode.

5) Point 4 explains why FALSSANI.EXE produces an incomplete image even on the GT550Ti and on cards where NEWAX works correctly.

6) X‑VESA always works because it was designed as software that does not trust the BIOS, and therefore for each video mode it probes how much video memory is actually available.

7) To overcome the problem, it is not necessary to rewrite the 4F06h function; it is enough to set DX to the correct value based on the available video memory:

- 4160 KB / (number of bytes in a horizontal scanline) for banked modes

- 16384 KB (or 14336 KB) / (number of bytes in a horizontal scanline) for linear modes

As soon as possible I will add the fix for 4F06h to correct the Nvidia bug.

Marco Pistella wrote on Today, 10:12:

Several things: […]
Show full quote

Several things:

1) The problem with FALSSANI.EXE also occurs on Nvidia GT550Ti and GT210 cards, using the original 4F07h and 4F06h functions and with NEWAX not loaded in memory.

2) There is a bug in the Nvidia function (certainly from the GT210 onward) where DX should return the maximum number of vertical scanlines (calculated based on the video mode and the available video memory).

3) This is how video memory works on Nvidia graphics cards at 8/15/16/32 bits per pixel, certainly from the GT210 up to at least the GT1050:

- in banked mode, 4160 KB are available

- in linear mode, 16384 KB are available (sometimes reduced to 14336 KB)

4) The 4F06h function is bugged: DX should report the maximum number of supported vertical scanlines, but it always performs the calculation using 4096 KB, EVEN if the video mode was opened in linear mode.

5) Point 4 explains why FALSSANI.EXE produces an incomplete image even on the GT550Ti and on cards where NEWAX works correctly.

6) X‑VESA always works because it was designed as software that does not trust the BIOS, and therefore for each video mode it probes how much video memory is actually available.

7) To overcome the problem, it is not necessary to rewrite the 4F06h function; it is enough to set DX to the correct value based on the available video memory:

- 4160 KB / (number of bytes in a horizontal scanline) for banked modes

- 16384 KB (or 14336 KB) / (number of bytes in a horizontal scanline) for linear modes

As soon as possible I will add the fix for 4F06h to correct the Nvidia bug.

Hi,
Thanks in advance!

- in banked mode, 4160 KB are available […]
Show full quote

- in banked mode, 4160 KB are available

- in linear mode, 16384 KB are available (sometimes reduced to 14336 KB)
....

7) To overcome the problem, it is not necessary to rewrite the 4F06h function; it is enough to set DX to the correct value based on the available video memory:

- 4160 KB / (number of bytes in a horizontal scanline) for banked modes

As I have written above this is definitely not true at least in case of my GTX 960 and GTX 970. Both can use at least ~8 MB video memory in banked modes in my test program as well as in VESATEST.EXE from UNIVBE package.

Here is a screenshot from VESATEST.EXE/UNIVBE. As can be seen with the modified NEWAX version it can use 3872 x 2166 x 8-bit virtual resolution in banked mode without problems (scrolling works perfectly without any artifacts).

Also here is the modified NEWAX source + binary + banked mode FALSSANI program so you can test on your hardware:

Marco Pistella wrote on Today, 10:12:

Several things: […]
Show full quote

Several things:

1) The problem with FALSSANI.EXE also occurs on Nvidia GT550Ti and GT210 cards, using the original 4F07h and 4F06h functions and with NEWAX not loaded in memory.

2) There is a bug in the Nvidia function (certainly from the GT210 onward) where DX should return the maximum number of vertical scanlines (calculated based on the video mode and the available video memory).

3) This is how video memory works on Nvidia graphics cards at 8/15/16/32 bits per pixel, certainly from the GT210 up to at least the GT1050:

- in banked mode, 4160 KB are available

- in linear mode, 16384 KB are available (sometimes reduced to 14336 KB)

4) The 4F06h function is bugged: DX should report the maximum number of supported vertical scanlines, but it always performs the calculation using 4096 KB, EVEN if the video mode was opened in linear mode.

5) Point 4 explains why FALSSANI.EXE produces an incomplete image even on the GT550Ti and on cards where NEWAX works correctly.

6) X‑VESA always works because it was designed as software that does not trust the BIOS, and therefore for each video mode it probes how much video memory is actually available.

7) To overcome the problem, it is not necessary to rewrite the 4F06h function; it is enough to set DX to the correct value based on the available video memory:

- 4160 KB / (number of bytes in a horizontal scanline) for banked modes

- 16384 KB (or 14336 KB) / (number of bytes in a horizontal scanline) for linear modes

As soon as possible I will add the fix for 4F06h to correct the Nvidia bug.

Per Falcosoft's comment... I think a good test would be actually letting the modified NEWAX replace the stock VGA BIOS implementation of these functions in older video cards, and see if it makes a difference.

If so, then NEWAX would be useful on those generations as well.

Test performed on the GT1030 shows the following situation:

1mov ax,4F02h
2mov bx,101h
3int 10h
4mov ax,4F05h
5xor bx,bx
6mov dx,63d
7int 10h

This returns AX = 4Fh

1mov ax,4F02h
2mov bx,101h
3int 10h
4mov ax,4F05h
5xor bx,bx
6mov dx,64d
7int 10h

This returns AX = 14Fh

But the RAM in banked mode, as you have seen, is there!

Unfortunately this is a new Nvidia bug: the 4F05h function fails when exceeding 4 MB of VRAM.

How I understood it: instead of using the 4F05h function to change the bank, I used the far call for the window function, and it works

I need to review NEWAX’s VRAM logic and try to implement a fix for 4F05h.

New version of NEWAX – Version 0.7:

- Added fix for 4F06h function (now FALSSANI.EXE works)
- Added fix for 4F05h function above 4Mb VRAM (Quake 1280x1024 fixed)
- Added the /S command line option to display the status of the flags

Marco Pistella wrote on Today, 12:10:

New version of NEWAX – Version 0.7: […]
Show full quote

New version of NEWAX – Version 0.7:

- Added fix for 4F06h function (now FALSSANI.EXE works)
- Added fix for 4F05h function above 4Mb VRAM (Quake 1280x1024 fixed)
- Added the /S command line option to display the status of the flags

Hi,
I have just tested and the modifications seem to work fine!

@Falcosoft

Thank you for the feedback. VBETEST.EXE still doesn’t work because it does not accept that INT 10h is re‑entrant (it cannot handle a 4F01h call inside a 4F02h call). This can be solved by using the VESA 2.0 interface instead of 3.0 through the command‑line option NEWAX /2.

Marco Pistella wrote on Today, 12:56:

@Falcosoft

Thank you for the feedback. VBETEST.EXE still doesn’t work because it does not accept that INT 10h is re‑entrant (it cannot handle a 4F01h call inside a 4F02h call). This can be solved by using the VESA 2.0 interface instead of 3.0 through the command‑line option NEWAX /2.

Hmm. I have tested and VBETEST.EXE worked for me without problems. AFAIK my verion is from Scitech Display Doctor 5.3 package.

Falco, please could you tell how about quake on your GTX970 in 1280*1024 - if it's known problem or just me? Should i try disable vsync you suggested? (VID_WAIT 0)

@Falcosoft

Confirmed: VBETEST works as expected on GT740. The issue lies with the GT1030 and GT1050Ti; there seems to be a new Nvidia bug in the PMID structure for 32-bit interfacing, which appears to be corrupted or missing some functions.

@RayeR

Try using the latest version (0.7) or using the command line NEWAX /1

Marco Pistella wrote on Today, 12:10:

New version of NEWAX – Version 0.7: […]
Show full quote

New version of NEWAX – Version 0.7:

- Added fix for 4F06h function (now FALSSANI.EXE works)
- Added fix for 4F05h function above 4Mb VRAM (Quake 1280x1024 fixed)
- Added the /S command line option to display the status of the flags

I just tested this on my Ampere system and it still reports 4F06h error, so I wonder if this is not a complete fix for these generations where 4F06h is also absent...

On the other hand, I did a test with Stargunner on my Kepler system (Quadro K6000) and for some reasons its SETUP.EXE could not detect VESA 2.0 (Not Present) regardless of whether NEWAX is loaded (NEWAX /2 doesn't help either).

IIRC on some system configurations Stargunner would permit the toggle of VESA 2.0 option, but so far I haven't found a single setup that worked with it (neither nVidia nor ATi/AMD). With VESA 2.0 turned on the game simply outputs garbage (though cinematics can be played properly). Not sure what exactly Stargunner checks for VESA 2.0 availability or how it actually works in-game...

Anyway, on my Kepler system with NEWAX installed tests that involve 4F07h can work correctly (e.g. VBEVSTST in the OP).

RayeR wrote on Today, 13:22:

Falco, please could you tell how about quake on your GTX970 in 1280*1024 - if it's known problem or just me? Should i try disable vsync you suggested? (VID_WAIT 0)

Hi,
I have just tested it and I have not experienced any 1280x1024 specific problems. I have tried with both VID_WAIT 0 and VID_WAIT 1 and no difference in rendering quality.
The only problem I experienced is with the main/options menu (by pressing ESC). When this menu is active everything is horribly slow (max. 5 fps) but it is true for all double-buffered/page-flipped video modes (even 640x480 is very slow when the menu is active). Most likely this is because the menu is an overlay above the main rendering scene and in case of double-buffered/page-flipped video modes all buffers are in video memory and the overlay requires combining them. And reading from video memory is very slow.

In my case the menu works fine in 1024*768 and lower - normal smooth speed. I think that in 1280*1024 it's not slower but almost unreadable so hard to tell. It's interesting that we have the same GPU and different behavior. I have used MTRRLFBE LFB WC before loading NEWAX. What is your VBIOS version and how output do you use? I use DVI to DVI cable.

RayeR wrote on Today, 14:17:

In my case the menu works fine in 1024*768 and lower - normal smooth speed. I think that in 1280*1024 it's not slower but almost unreadable so hard to tell. It's interesting that we have the same GPU and different behavior. I have used MTRRLFBE LFB WC before loading NEWAX. What is your VBIOS version and how output do you use? I use DVI to DVI cable.

Geforce GTX 970 - BIOS version: 84.04.84.00.29
PCI\VEN_10DE&DEV_13C2&SUBSYS_31611462&REV_A1
DVI to DVI

But if you do not experience the menu slowdown then it is 100% sure that you are not using double-buffered/page-flipping video modes. The menu behaves the same way even on older cards when page-flipping is active.
Be aware that Quake has a setting that explicitly disables double-buffered/page-flipping video modes, namely: vid_nopageflip. It has to be set to 0 in order page-flipping video modes to work.
Unlike vid_wait changing vid_nopageflip requires a restart of the game.

Those options are stored permanently when typed in console? I though they are valid only until exit. I'll have to check my config file (not at the home PC now) how it is set....
My VBIOS is sligtly newer 84.04.84.00.70 but I doubt there would be a significant difference.

RayeR wrote on Today, 15:23:

Those options are stored permanently when typed in console? I though they are valid only until exit. I'll have to check my config file (not at the home PC now) how it is set....
My VBIOS is sligtly newer 84.04.84.00.70 but I doubt there would be a significant difference.

Yes, vid_nopageflip is stored permanently for sure. Otherwise it could not even work since it requires a restart.
CONFIG.CFG:

... bgmvolume "1" volume "0.7" viewsize "100.000000" _vid_default_mode "14.000000" _vid_wait_override "1" vid_nopageflip "0" _co […]
Show full quote

...
bgmvolume "1"
volume "0.7"
viewsize "100.000000"
_vid_default_mode "14.000000"
_vid_wait_override "1"
vid_nopageflip "0"
_config_modem_hangup "AT H"
_config_modem_init ""
_config_modem_clear "ATZ"
_config_modem_dialtype "T"
_config_com_modem "1.000000"
_config_com_baud "57600.000000"
_config_com_irq "4.000000"
_config_com_port "1016.000000"
gamma "1.0"
crosshair "1"