Hi Marco,
Your X-VESA program seems to work pretty good on all my VESA systems. If you want I can make a list of each of them.

Since it shows you went on a deep dive on VESA, I believe there is a lot of room for going beyond its current state: it would be ideal to have a tweak section which would for example, help spoof the VESA version, fake the video memory size, let users adjust brightness, contrast, etc. This would make it ideal as an all-in-one tool which we currently don't have (we have a collection of patches in the best of cases for some of these purposes).

Impressive! Used an old version (1.0.3) of your tool before. Will definitely test this version in the future.

igully wrote on Yesterday, 22:30:

Hi Marco,
Your X-VESA progra ... [CUT]

Hi, thank you! A list of your systems would be very welcome — that's exactly the kind of data I'm looking for during the beta phase.

Regarding the tweak section: it's an interesting direction and I understand the appeal of an all-in-one tool. For now X-VESA is designed as a pure diagnostic instrument, but I'm keeping all suggestions noted for future development. Let's see what comes out of the beta first.

Yoghoo wrote on Yesterday, 22:32:

Impressive! Used an ol ...[CUT]

Thank you! I'm curious — where did you find version 1.x, and on what hardware did you test it? I wasn't aware it had reached anyone outside my immediate circle. Any feedback from that experience, even old impressions, would be useful context for the current beta.

Marco Pistella wrote on Today, 03:57:

Yoghoo wrote on Yesterday, 22:32:

Impressive! Used an ol ...[CUT]

Thank you! I'm curious — where did you find version 1.x, and on what hardware did you test it? I wasn't aware it had reached anyone outside my immediate circle. Any feedback from that experience, even old impressions, would be useful context for the current beta.

I found it on Vogons in some topic (which I can't find anymore). I used it on a couple of retro videocards (ET4000, S3). It worked correctly and was informative. But as it was some time ago I forgot why I even ran it so don't have any feedback on that version. 😀

Yoghoo wrote on Today, 06:49:

I found it on Vogons in some topic (w ...[CUT]

Thanks for tracking it down! ET4000 and S3 are well-represented
in the 2.0 hardware database — if you get a chance to run this
version on the same cards, the comparison might be interesting.
No pressure though.

Marco Pistella wrote on Today, 07:04:

Thanks for tracking it down! ET4000 and S3 are well-represented in the 2.0 hardware database — if you get a chance to run this […]
Show full quote

Yoghoo wrote on Today, 06:49:

I found it on Vogons in some topic (w ...[CUT]

Thanks for tracking it down! ET4000 and S3 are well-represented
in the 2.0 hardware database — if you get a chance to run this
version on the same cards, the comparison might be interesting.
No pressure though.

I tested it on a Tseng ET4000AX 2theMax 4000S (ISA) just now and it works okay. Was a bit confused at first about all the Fails in attached screenshot. It's not clear what Fail[11] means. It's clearly not supported of course on a ET4000AX. So maybe change the wording or show an explanation? I have dozens of video cards so can do a couple of more tests if needed but let me know what option in the program you like to be tested etc. I am not an expert on VESA things so I can use some guidance what you like me to test.

Yoghoo wrote on Today, 08:16:

I tested it on a Tseng ET4000AX 2theMa ... [CUT]

Thank you for testing on the ET4000AX — that's exactly the kind of hardware I need covered.

Fail[11] means "linear frame buffer not supported": the card declares no LFB address in the VESA mode information, so linear access is not available. On a card like the ET4000AX this is
completely expected — it's not a malfunction, just a hardware limitation of the era. I'll add an inline explanation in the next build to make this clearer without having to look it up.
For the next tests, the most useful commands on that card would be:

- Command 4 (Detect video scan timings) on a few modes — I'm curious about the jitter signature of a real ISA card
- Command 1 (Detailed video mode information) on mode 0101 or 0103 to verify the banked window parameters
- Command 9 (Detect available video memory) to confirm the 1.024 KiB figure via direct probe

No pressure — even what you've already provided is useful data.

Hi,
1. Just a quick remark:
At the 8-bit wide palette the 6/8-bit switch is associated to the numeric pad '+' button. Unfortunately on some notebooks (e.g. Thinkpad T430) such button is not available.
At that test e.g. 'space' would be a better option.

2. It is known that at least from Nvidia Maxwell the Function 07h - Set/Get Display Start does not work correctly:
NVIDIA Kepler/Maxwell/Pascal VESA Bios Bug (workaround found)
Your double buffering and virtual screen tests say the function is not available and refuse to run. The truth is the function is available and supported but it fails.
Maybe instead of simply refusing to run the test could show how the function fails ( that is scrolling does not work, the page flip flickers etc.).
This way the test would be more expressive about the nature of the problem.

Thanks in advance.

Here is the output of the requested tests. Hope that covers it.

Falcosoft wrote on Today, 08:43:

Hi, 1. Just a quick remark: At the 8-bit wide palette the 6/8-bit switch is associated to the numeric pad '+' button. Unfortuna […]
Show full quote

Hi,
1. Just a quick remark:
At the 8-bit wide palette the 6/8-bit switch is associated to the numeric pad '+' button. Unfortunately on some notebooks (e.g. Thinkpad T430) such button is not available.
At that test e.g. 'space' would be a better option.

2. It is known that at least from Nvidia Maxwell the Function 07h - Set/Get Display Start does not work correctly:
NVIDIA Kepler/Maxwell/Pascal VESA Bios Bug (workaround found)
Your double buffering and virtual screen tests say the function is not available and refuse to run. The truth is the function is available and supported but it fails.
Maybe instead of simply refusing to run the test could show how the function fails ( that is scrolling does not work, the page flip flickers etc.).
This way the test would be more expressive about the nature of the problem.

Thanks in advance.

Good news: the regular + key (not just the numpad one) works
for the toggle as well. Let me know if that's not the case
on your T430.

Thank you for the link — I'm familiar with that bug.

On the GT740 I traced the INT 10h execution step by step through
the BIOS: function 4F07h returns 014Fh (failure) immediately,
with no hardware register activity whatsoever. It's not a case
of "the function is available but misbehaves" — the BIOS
explicitly reports failure and does nothing.

In that situation there is nothing meaningful to show: forcing
the test to run anyway would produce a static screen with no
scrolling and no page flip, which is indistinguishable from a
hang from the user's perspective.

The current behavior — detecting the failure via the 014Fh return
code and the GET verification, reporting it clearly, and refusing
to proceed — is intentional and I think more honest than
pretending the function is operational when the BIOS itself
disagrees.

That said, I'll consider whether the failure report could be
more descriptive about the nature of the problem (014Fh + no
hardware activity) rather than just "not available".

Falcosoft wrote on Today, 08:43:

Hi,
1. Just a quick r ... [CUT]

It's also worth noting that my analysis is based on a specific
GT740 BIOS. Other Nvidia generations or firmware revisions may
behave differently — if anyone has a Maxwell/Pascal/Kepler card
and wants to test, that data would be very useful.

Yoghoo wrote on Today, 09:10:

Here is the output of the requested tests. Hope that covers it.

Thank you — this is excellent data.

The timing distribution on the ET4000AX is exactly what a real
analog oscillator looks like: single spike, N=4 distinct values,
MINX/MAXX spread of 3 PIT units. Compare this with the GT740
trimodal distribution from the screenshots in the first post —
the difference between a physical crystal and GPU VGA emulation
quantization could not be more visible.

One note: the σ/μ of 0.0069 at 640×480 is slightly above the
expected range for that resolution (typically 0.0052–0.0057 on
healthy hardware). Not a malfunction, but a measurable indicator
of component aging — likely the crystal or capacitors showing
their years. X-VESA picks it up.

This kind of data is precisely what the tool was designed to
produce. Much appreciated.

Marco Pistella wrote on Today, 09:24:

Thank you — this is excellent data. […]
Show full quote

Yoghoo wrote on Today, 09:10:

Here is the output of the requested tests. Hope that covers it.

Thank you — this is excellent data.

The timing distribution on the ET4000AX is exactly what a real
analog oscillator looks like: single spike, N=4 distinct values,
MINX/MAXX spread of 3 PIT units. Compare this with the GT740
trimodal distribution from the screenshots in the first post —
the difference between a physical crystal and GPU VGA emulation
quantization could not be more visible.

One note: the σ/μ of 0.0069 at 640×480 is slightly above the
expected range for that resolution (typically 0.0052–0.0057 on
healthy hardware). Not a malfunction, but a measurable indicator
of component aging — likely the crystal or capacitors showing
their years. X-VESA picks it up.

This kind of data is precisely what the tool was designed to
produce. Much appreciated.

You're welcome. It would be nice to make that note visible somewhere in the program as I think the σ/μ values (as well as some other values) will probably not be understandable for a regular user. Thanks for the program.

Yoghoo wrote on Today, 09:38:

You're welcome. It would be nice to ... [CUT]

Thank you for the suggestion. Adding inline explanations for
σ/μ and related values is something I'll evaluate — the
challenge as always is balancing information density with
interface readability.

Regarding the values themselves: collecting this kind of data
from a wide range of hardware is exactly one of the reasons
I'm running this beta on Vogons. My own lab is reasonably
large but nowhere near the collective hardware pool here.
The σ/μ ranges I mentioned are based on my own observations
and should be treated as preliminary — a real correlation
would need a much larger dataset than I can build alone.

One thing I have observed consistently on my machines: σ/μ
tends to increase with temperature over a measurement session,
which suggests a thermal component in the jitter. Again,
preliminary — but repeatable on my end.

Thanks again for the data and the feedback, both are valuable.

Can you add a option to dump all data to a txt file so we can attach more easily? Just a command line switch? I don't really understand this information but I have lots of hardware I can test on!

Marco Pistella wrote on Today, 09:11:

Good news: the regular + key (not just the numpad one) works
for the toggle as well. Let me know if that's not the case n your T430.

Hi,
Bad news:
I have just tested and none of the expected key combinations work. It's a keyboard with a Hungarian layout so 'Shift + 3' should be the right combination (that otherwise work in other DOS programs) but in the palette test it does nothing.
I have also tried 'Shift+=' that is the English layout equivalent but this combination does not work either.
Then I have tried with an external English keyboard and only the numpad + key worked, 'Shift + =' did not. So actually this can be a more generic problem that is not Hungarian T430 specific ( during the tests always the proper code pages were used).

Marco Pistella wrote on Today, 09:11:

On the GT740 I traced the INT 10h execution step by step through the BIOS: function 4F07h returns 014Fh (failure) immediately, […]
Show full quote

On the GT740 I traced the INT 10h execution step by step through
the BIOS: function 4F07h returns 014Fh (failure) immediately,
with no hardware register activity whatsoever. It's not a case
of "the function is available but misbehaves" — the BIOS
explicitly reports failure and does nothing.

2. Maybe I'm too pedantic but I partly disagree. According to VBE 3 specification there is a clear distinction between a function call is not supported and a function call is failed:

VBE RETURN STATUS
AL == 4Fh: Function is supported
AL != 4Fh: Function is not supported
AH == 00h: Function call successful
AH == 01h: Function call failed

As you say the function 4F07h returns 014Fh that means the function is supported but it failed. I think this is clearly different from a situation when the function is simply not available (as the test program currently suggests).

mwdmeyer wrote on Today, 10:17:

Can you add a option to dump all data to a txt file so we can attach more easily? Just a command line switch? I don't really understand this information but I have lots of hardware I can test on!

Thank you — having access to a wide range of hardware is exactly what this beta needs.

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.

If you want to start testing, the most useful sequence on any card is:
- Main screen: note the VBE version, OEM name, and total video modes reported
- F10: extended interface information
- Command 4 (Detect video scan timings) on a couple of modes
- Command 9 (Detect available video memory) on a packed or direct color mode

Screenshots of those screens give me most of what I need. No VESA expertise required — just run it and share what you see.

Falcosoft wrote on Today, 10:43:

Hi,
Bad news:
I have just ... [CUT]

Thank you for the detailed testing — this is a real bug, not a layout issue.

X-VESA reads hardware scancodes directly, not ASCII characters. It currently only recognizes the numpad + scancode (4Eh). The main keyboard + (Shift+= in English, Shift+3 in Hungarian) produces a different scancode that X-VESA doesn't catch. This will be fixed in the next build by adding the main keyboard equivalent alongside the numpad key.

Sorry for the inconvenience, and thank you for isolating the problem across two different keyboards — that made the cause unambiguous.

Falcosoft wrote on Today, 10:43:

2. Maybe I'm too pedantic but I pa ...[CUT]

You are correct and I was imprecise. 014Fh is unambiguous per the VBE specification: AL=4Fh means the function is supported, AH=01h means the call failed. These are two distinct conditions and X-VESA should report them as such.

The current behavior conflates "function not supported" (AL != 4Fh) with "function supported but failed" (014Fh), which is technically wrong. I'll correct the reporting in the next build to distinguish the two cases explicitly.

Thank you for pushing back on this — it's a legitimate correction.