Another card:
Nvidia AGP GeForce 6200
Let me know if you would like any other screenshot.

@Falcosoft

Glad to hear it. Thanks for the follow-up.

Thank you for the detailed log — this is a very clean and
informative failure pattern.

All 999 errors are exclusively MATRIX type, with a systematic
1-bit shift between expected and read value. BITS_TEST and
BURST_TEST pass cleanly. The key difference: BURST_TEST
includes a forced write buffer flush via I/O port 80h before
the readback verification. MATRIX_TEST does not.

On an IGP with shared system memory like the Radeon Xpress
1150, write-combining or caching is almost certainly active.
Without an explicit flush between write and read, MATRIX_TEST
reads stale cached data — the previous bit position, not the
one just written. The systematic shift in the XOR mask
confirms this.

This is not a VRAM defect and not an X-VESA bug — it is
documented hardware behavior caused by the memory subsystem
of integrated graphics with shared memory. Could you repeat
the test in linear mode (F10 before entering the command)
to see if the behavior changes with a different access path?

@Tiido

Thank you! No rush — the thread will still be here in a few
months.

Unreal mode is worth the effort when you get to it. The
transition is straightforward once you have the GDT setup
right; the interesting part is what you can do with 32-bit
addressing from real mode without the overhead of full
protected mode. If you have questions when you get there,
feel free to ask.

@konc

Thank you for tracking down the original reference — that
explains how version 1.x circulated. Good to know the VRAM
reliability test was already finding real use on questionable
hardware. That use case is fully covered in 2.0 as well, with
a more detailed error report and configurable test parameters.

@ajacocks

Thank you, enjoy it!

@EduBat - UMC

Thank you — clean data on all three screenshots.

s/µ = 0.0064 at 640×400 is consistent with other ISA cards
tested so far. The distribution confirms a real analog
oscillator: single spike, N=4, 3 PIT unit spread.

"Emulated VGA CRTC registers!" and the window function
pointer at 1344:00B5 are both expected when running with a
software VESA TSR: the TSR resides in conventional memory
and intercepts the VESA interface entirely, so the bank
switching function pointer lands in the TSR's own segment
rather than in the card's BIOS ROM at C000h, and the CRTC
registers may not be directly accessible in the same way
they would be on a card with native VESA support. X-VESA
falls back to indirect estimation for bandwidth and
interlace detection as a result.

Regarding the VRAM results from the previous screenshot:
Fail[0Eh] on the high-resolution planar and direct color
modes is expected — the card has 512 KiB, insufficient for
those modes. The TSR declares them anyway without setting
bit 0 of byte 0 in the 4F01h mode attributes to indicate
"not supported by hardware configuration", which is a known
class of bug in several 1990s VESA implementations. X-VESA
validates that bit independently and rejects the modes
before any opening attempt.

The "Not supported" entries in the VRAM linear column are
also expected: linear frame buffer requires VESA 2.0 or
higher, and this TSR implements VESA 1.2.

Finally, the 256 KiB vs 512 KiB discrepancy between modes
is normal: the amount of VRAM accessible in banked mode
depends on how the TSR has configured the memory mapping
for each specific mode, not just the total physical memory
installed.

If you have other hardware without a TSR to test on, a
comparison would be interesting.

@EduBat - GeForce 6200

Thank you — GeForce 6200 is a useful data point.

s/µ = 0.0046 at 640×400 is the lowest value seen so far in
this beta, lower than the ISA cards with real analog
oscillators. N=3, 2 PIT unit spread — very stable VGA
emulation at low resolution, quite different from the GT740
which showed extreme jitter and a trimodal distribution.

The garbled characters in the Product revision field are not
an X-VESA bug — that field contains non-ASCII bytes in the
BIOS string and X-VESA displays the raw content as-is.

128 MiB VRAM, LFB at D8000000h, VESA 3.0 — everything looks
clean. Could you run Command 4 on a higher resolution mode
(0107 or 0118) as well? I'm curious whether the jitter
remains this low at higher horizontal frequencies on this
card.

New Beta 3 - Changes from Beta 1

Beta 2

- Command 8 (Test switch DAC 6/8 bit): use spacebar for
compatibility with keyboards without a dedicated numeric
keypad.

- Commands 6 and 7 (Test dual page video mode / Test virtual
resolution): the result of function 4F07h is now reported
with a distinction between "not supported" (AL ? 4Fh) and
"supported but failed" (AL = 4Fh, AH = 01h / return 014Fh).
Previously both conditions were reported identically.

Beta 3

- Command 8 (Test switch DAC 6/8 bit): spacebar added as an
alternative toggle key to numpad +, for compatibility with
keyboards without a dedicated numeric keypad.

- Command 7 (Test virtual resolution): the summary panel
displayed on ESC now includes the horizontal granularity
of the virtual resolution — the interval in pixels at which
function 4F06h generates a new distinct BytesPerScanLine
value, derived from the compatible virtual resolution table
built during the test.

I have 128MB Asus Radeon A9600XT https://www.pcstats.com/articles/1495/2.html
Attached Lavalys Everest 2005 GPU export .txt for more details
Chip ID and memory amount are not detected correctly

vutt wrote on Today, 10:28:

I have 128MB Asus Radeo ... [CUT]
Thank you for the detailed report.

Regarding memory detection: X-VESA reads the TotalMemory
field from the VbeInfoBlock, which on this card declares
16 MiB. However the direct physical probe on mode 0110
finds 32,768 KiB actually accessible — the VESA BIOS
underdeclares the available memory. This is a known
limitation in several ATI VESA implementations and is
not an X-VESA detection error. The full 128 MiB is not
accessible via the VESA interface regardless.

The σ/μ = 3.8587 at 640×480×15 is surprisingly high for
a card of this generation — higher than the GT740 tested
earlier. Could you repeat Command 4 on a packed 8-bit mode
(0101 or 0100) and on a higher resolution mode to see if
the jitter is consistent across modes, or specific to
this one?