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 35 minutes ago:

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!