I made a minor mistake, please try the corrected version. (I have also considered a potential workaround for linear modes)

Marco Pistella wrote on Today, 14:00:

@LSS10999 […]
Show full quote

@LSS10999

It’s generally not a good idea to force a larger VRAM size unless you are absolutely sure that the memory is actually mapped and accessible. In most cases this will lead to an immediate crash.

If you want to know how much VRAM is really available, the safest method is:

Start X‑VESA

Select the video mode you want to test

Press F10 and choose the Linear mode

Run the last option (“Test video memory”)

Then run Retest unlimited
(Warning: the system may crash during this test — this is expected)

This procedure tells you the actual amount of VRAM that the card exposes in linear mode, regardless of what the BIOS reports.

I got this when testing actual (linear) VRAM size in X-VESA at 1920x1080x32 resolution, without using /M with NEWAX:
- Retest unlimited returns 262144KB (256MB).
- Video card drops down to 640x480 60Hz output and I can no longer perform other tests with this resolution. Originally it outputs at 3840x2160 60Hz over DP connection to my monitor, though maximum available resolution to VESA/VBE is 1920x1080x32.
- Relaunching X-VESA in this state, only 640x480 and 800x600 resolutions are available, and with 800x600 it's actually scaled to 640x480 (per monitor OSD).
- (Insane) Virtual resolution test works fine with 262144KB LFB, though I get occasional flickers during scrolling -- about 2-3 times in total when I scrolled from upper-left to lower-right (testing with 800x600x32).

So while all the 256MB memory is indeed mapped for LFB, there must be something that shouldn't be casually touched get mapped in the region as well.

As such, just as I brought up the question in the SoftGPU thread, perhaps it's not always a good idea to enable as much VRAM as possible with VESA/VBE drivers. However, it seems 32MB is the smallest VRAM size cap for VBEMP 9x, and with SoftGPU VESA driver, the lower limit is also 32MB (when I set "VRAMLimit" in registry to "16", DXDIAG reports 32MB VRAM available). Not sure how VBEMP NT handles this, though, as I don't recall seeing VRAM size related options with that driver (for WinNT family)...

LSS10999 wrote on Today, 15:30:

I got this when testing actual (lin...[CUT]

What you’re seeing is completely expected. Using the VRAM size at 262144 KB may appear to work at first, but between the real 16/32 MB window and the forced 256 MB range there is almost certainly some region that should not be touched. Once the test reaches that area, the card will drop to 640×480, lose signal, or behave unpredictably.

This is a behaviour I’ve already seen on several cards when trying to force linear addressing: the program ends up writing into regions that are not part of the actual LFB mapping, and that’s exactly why Retest unlimited can cause crashes or strange output modes.

In short: forcing VRAM sizes is risky unless you know exactly how the hardware maps its memory, and touching unmapped areas almost always leads to instability.

@Falcosoft

New version with support for linear and banked planar video modes (clear VRAM)

Nvidia GPUs use a lot of MMIO registers. They are accessible from DOS (pmode) - I ported NVclock utility [ http://rayer.g6.cz/download/download.htm ] many years ago that manipulates the MMIO. I don't remember the relative offset of MMIO regs to LFB base but I guess it's somewhere inside the range and once x-vesa tries to write some test pattern to this area it probably destroy some MMIO regs vlues that may cause loosing the videosignal or even your GPU may explode 😀
UPDATE: nvclock can display some debug info that show you MMIO base, on my 7900GT it was something like this:
Found VendorID: 0x10DE, DeviceID: 0x0291 @ PCI:1:0:0, MMIO base: 0xF4000000
Then you can compare this address with LFB base to get the offset (unfortunatelly I didn note it here) - this imply the size of LFB you can use for drawing before you overwrite that critical MMIO regs...

>Falco
tried FALSSANI with SSE and NEWAX loaded and seems to run fine and smooth...

According to this, the MMIO registers can be accessed through BAR0 and the VRAM through BAR1 in the PCI configuration space.
https://envytools.readthedocs.io/en/latest/hw … /bars.html#bars
(I guess you all know that already...)

But my question is more towards NVIDIA documentation in general...
Besides https://envytools.readthedocs.io/en/latest/hw/index.html (very incomplete,) https://nouveau.freedesktop.org/NvHardwareDocs.html (also just bits and pieces) and the nouveau driver in the linux kernel, what else is there? Are there any other (good) sources of information about these cards?

Awesome work and discoveries!

I tested NEWAX 0.10 (forcing VBE 2.0) on an RTX 4060 Ti (Ada Lovelace) and a Quadro FX540 (Geforce 6). It's mostly a success on the RTX 4060 Ti, flickering is gone in Duke3D, Quake and page flipping tests of VBETEST. I also have a lot more pages in all graphics modes. As reported for Ampere, banked modes are slow to draw for the virtual resolution tests (30k+ pixels wide then 20k+ pixels tall), linear modes are fine. So it seems that NEWAX works with Ada generation too!

It's quite the opposite with the Quadro FX540. with NEWAX (/2), with VBETEST, screen jumps all over the place when flipping pages, as if each page has incorrect address. Virtual resolution tests are completely garbled. All tests of VBETEST pass with success in stock configuration. Also, the dual page video test of X-VESA flickers between two completely misaligned pages with NEWAX on any refresh mode, whereas it only flickers with the VESA retrace without NEWAX.

As this card is mostly working out of the box, I think the only interesting part is the VESA inverted retrace logic fix. Maybe we could activate only this on Fermi and older as their BIOS are mostly sane?

Marco Pistella wrote on Today, 16:01:

@Falcosoft

New version with support for linear and banked planar video modes (clear VRAM)

The attachment NEWAX.ZIP is no longer available

Thanks, this time it seems to be working well!