Falcosoft wrote on Yesterday, 08:43:

At that test e.g. 'space' would be a better option.

Confirmed — spacebar will be added as an alternative toggle key in the next build. It maps cleanly to a fixed scancode (39h) regardless of layout, which is exactly what the keyboard handling in X-VESA requires. Minimal change, no side effects.

Is there specific hardware age you are interested in? I have lots of ISA/PCI machines.

mwdmeyer wrote on Yesterday, 12:12:

Is there specific hardware age you are interested in? I have lots of ISA/PCI machines.

Do we have a list, what tested already or all cards are good?

Marco Pistella wrote on Yesterday, 11:32:

Regarding the dump option: it's a reasonable request and I'll keep it in mind for future development. For now, the F2 key saves a screenshot in IFF-PBM format at any point in the program
— PBM2PNG.EXE (included in the archive) converts it to PNG, which is easy to attach to a post.

I'm not sure of your end goal vision on all the data that's collected. But I could see a database of some sort. If the card allows it being able to see the video bios revision versus the test results which might uncover when things were fixed/broken on various hardware.

Just something to think about and plan for the future.

mwdmeyer wrote on Yesterday, 12:12:

Is there specific hardware age you are interested in? I have lots of ISA/PCI machines.

Everything is welcome — ISA, PCI, AGP, no age limit in either direction. If I had to prioritize: ISA cards with real analog oscillators are particularly interesting for the timing analysis (Command 4), as they produce very different jitter signatures compared to modern GPU VGA emulation. But honestly, any real hardware you can throw at it is useful data.

SScorpio wrote on Yesterday, 12:14:

I'm not sure of your end goal v...[CUT]

The hardware bug database is already part of the distribution — X-VESA.TXT includes a documented set of confirmed anomalies with card identification, BIOS version where available, and the specific behavior observed. It will grow with the beta.

A more structured database correlated with BIOS revisions is an interesting long-term idea — it would require a critical mass of data points per card family to be meaningful, which is exactly what a wide beta like this could start to build. Something to think about for the GitHub release phase.

Marco Pistella wrote on Yesterday, 12:40:

SScorpio wrote on Yesterday, 12:14:

I'm not sure of your end goal v...[CUT]

The hardware bug database is already part of the distribution — X-VESA.TXT includes a documented set of confirmed anomalies with card identification, BIOS version where available, and the specific behavior observed. It will grow with the beta.

A more structured database correlated with BIOS revisions is an interesting long-term idea — it would require a critical mass of data points per card family to be meaningful, which is exactly what a wide beta like this could start to build. Something to think about for the GitHub release phase.

Claude code has help me write https://starrts.vogonswiki.com/ which includes Win 9x submit feature (json via HTTP to my server). I'm building in a submit feature for DOS soon too (there will be helper exe file to upload the results, based on mtcp). Planning to add to Git repo in future but happy to help if you think this is of interest to you.

Here is from a Matrox Mill 2 8mb.

mwdmeyer wrote on Yesterday, 13:18:

Here is from a Matrox Mill 2 8mb.

Thank you — clean results on the Millennium II. A few notes:

PMID detected via 4F0Ah but not via BIOS direct detection: this is a known asymmetry on some VESA 2.0 implementations and X-VESA handles it correctly.

σ/μ = 0.0058 at 640×400 — slightly different from my own unit (0.0063 on the same card). Small variation, likely different production batch or thermal conditions at test time. Both values are consistent with healthy analog hardware.

8 MiB VRAM confirmed via direct probe, matching the declared value — no anomalies.

Could you run Command 4 on a higher resolution mode (0103 or 0107) as well? I'm curious whether σ/μ scales with horizontal frequency on this card.

BETA 2 UPDATE — attached to this post.
Changes:
- Spacebar added as alternative toggle key (Command 😎
- Dual-page and virtual resolution tests now distinguish between
"4F07h not supported" and "4F07h supported but failed" (014Fh)

Marco Pistella wrote on Yesterday, 13:37:

... BETA 2 UPDATE — attached to this post. Changes: - Spacebar added as alternative toggle key (Command 8) - Dual-page and virtu […]
Show full quote

...
BETA 2 UPDATE — attached to this post.
Changes:
- Spacebar added as alternative toggle key (Command 😎
- Dual-page and virtual resolution tests now distinguish between
"4F07h not supported" and "4F07h supported but failed" (014Fh)

Thanks, I have just tested it and everything works as expected 😀

This looks absolutely excellent ! I'm not gonna have any time to test it anytime soon unfortunately, but I do have a lot of various hardware to try things on when I finally am able to in a few months.
I appreciate the handwritten assembly aspect, it is something I am doing myself although I have not yet tried to do anything past real-mode yet, but unreal mode is in my todo list ~

I'll test it on the asus x401u anachonistic laptop after work today. It claims vbe3.0, up to 1024x768, with a 32mb framebuffer. It's some integrated radeon derivative baked into an amd E1 cpu.

I've noticed it has strange behavior in jazz jackrabbit. (Jumping, tearing)

I'll do tests with, and without, mtrrlfbe enabling 32bit writes. (Though quake really benefits from 32bit writes being enabled.)

Great news! I was also using V1.0.2, mostly to test for defective video memory after upgrades with questionable chips or changing clocks.
Here's where I learned about it, and the file is still attached.

Wow, this is a heck of a detailed and useful tool. Thanks @Marco Pistella!

I have tested my anachronistic laptop's VESA functions with this.
It looks like the jumpy video problem I see with Jazz Jackrabbit might be related to VESA retrace (in every mode!) listing as failed.
Dual pane tests only seem to work in VGA retrace mode.

wierd_w wrote on Yesterday, 23:00:

I have tested my anachronistic laptop's VESA functions with this.
It looks like the jumpy video problem I see with Jazz Jackrabbit might be related to VESA retrace (in every mode!) listing as failed.
Dual pane tests only seem to work in VGA retrace mode.

Jazz Jackrabbit does not use any VESA modes at all. It uses standard VGA Mode 13h for menus and ModeX for gameplay.
So the jumpy video problem in the game is not likely to be related to VESA retrace problems.

Falcosoft wrote on Today, 01:07:

Jazz Jackrabbit does not use any VESA modes at all. It uses standard VGA Mode 13h for menus and ModeX for gameplay.
So the jumpy video problem in the game is not likely to be related to VESA retrace problems.

Maybe he should try Univbe or another utility capable of remapping VGA modes to VESA ones?

BinaryDemon wrote on Today, 01:48:

Falcosoft wrote on Today, 01:07:

Jazz Jackrabbit does not use any VESA modes at all. It uses standard VGA Mode 13h for menus and ModeX for gameplay.
So the jumpy video problem in the game is not likely to be related to VESA retrace problems.

Maybe he should try Univbe or another utility capable of remapping VGA modes to VESA ones?

Univbe cannot help in this case since it does not do remapping this way. Univbe only exposes hardware specific video modes as standard VESA modes.
So UNIVBE can only help in cases when a game is capable of using VESA modes but the video card's BIOS does not expose any/all supported video modes as standard VESA modes.
For Jazz Jackrabbit you would need a utility that does just the opposite. That is a utility that exposes VESA modes as VGA ModeX/13h modes and redirects calls accordingly.

Marco Pistella wrote on Yesterday, 13:37:

BETA 2 UPDATE — attached to this post. Changes: - Spacebar added as alternative toggle key (Command 8) - Dual-page and virtual r […]
Show full quote

BETA 2 UPDATE — attached to this post.
Changes:
- Spacebar added as alternative toggle key (Command 😎
- Dual-page and virtual resolution tests now distinguish between
"4F07h not supported" and "4F07h supported but failed" (014Fh)

Hi,
I have an interesting case with an HP-Compaq NX6325 notebook. It has a Turion 64 X2 CPU and a chipset integrated ATi Radeon Xpress 1150 IGP. It has a fairly decent VESA 2.0 BIOS with many supported modes (4,8,15,16,24,32-bit modes supported even on low resolution).
Visually the test works perfectly with any modes. But the video memory test shows many errors. Actually it stops at 999 errors. The errors seemingly always show the same specific patterns.
I do not know what can cause these errors but most likely they are data read back related since as I said there are no visual glitches at all in any modes.
I attached the error log file: