Falcosoft wrote on Today, 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 Today, 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 Today, 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 Today, 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 Today, 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 Today, 12:40:

SScorpio wrote on Today, 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 Today, 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 Today, 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.)