I tried running X-VESA Beta 5 on ZimaBoard (CPU: Intel Celeron N3350 [Apollo Lake], GPU: Intel HD Graphics 500) and the result was:
No VGA adapter detected
@M-HT
X‑VESA requires a real IBM‑compatible VGA core (sequencer, graphics controller, CRTC, planar modes, latch logic, etc.).
Intel Apollo Lake (HD Graphics 500) no longer includes a legacy VGA hardware block — only a VESA framebuffer interface provided by the firmware.
Because INT 10h function 1A00h does not return a valid VGA Display Combination Code (07h/08h), X‑VESA correctly reports “No VGA adapter detected”.
This is expected behavior on modern Intel SoCs where the VGA subsystem has been removed from the silicon.
M-HT wrote on 2026-05-14, 11:16:I tried running X-VESA Beta 5 on ZimaBoard (CPU: Intel Celeron N3350 [Apollo Lake], GPU: Intel HD Graphics 500) and the result was:
No VGA adapter detected
That happened on my netbook with Intel N4020 CPU. There are various "fakevga" programs out there. The one I used to supplant this message, and get X-VESA and quickview pro, and others to run is called FAKEVGA.COM a small .com file which fools the system into thinking VGA is in the system by modifying INT 10 function.
@zyzzle
Thank you for the information about FAKEVGA.COM.
Using FAKEVGA will indeed allow X-VESA to pass the initial VGA detection check, but this is strongly discouraged. X-VESA relies heavily on direct VGA hardware access throughout its execution — sequencer registers, CRTC, graphics controller, planar modes, latch logic — not just at startup. These are not optional code paths but core to almost every function X-VESA performs.
On systems without real VGA hardware, any of these accesses may produce unpredictable results or cause X-VESA to crash at any point during execution. This would not be a bug in X-VESA — it would be the expected consequence of running software that requires real VGA hardware on a system that does not have it.
In short: FAKEVGA + X-VESA on nonVGA/partialVGA or similar platforms = use at your own risk, crashes are expected and will not be investigated as bugs.
Marco Pistella wrote on 2026-05-15, 04:12:@zyzzle Thank you for the information about FAKEVGA.COM. […]
@zyzzle
Thank you for the information about FAKEVGA.COM.Using FAKEVGA will indeed allow X-VESA to pass the initial VGA detection check, but this is strongly discouraged. X-VESA relies heavily on direct VGA hardware access throughout its execution — sequencer registers, CRTC, graphics controller, planar modes, latch logic — not just at startup. These are not optional code paths but core to almost every function X-VESA performs.
On systems without real VGA hardware, any of these accesses may produce unpredictable results or cause X-VESA to crash at any point during execution. This would not be a bug in X-VESA — it would be the expected consequence of running software that requires real VGA hardware on a system that does not have it.
In short: FAKEVGA + X-VESA on nonVGA/partialVGA or similar platforms = use at your own risk, crashes are expected and will not be investigated as bugs.
Of course. This is evident and understood.
I've only had to invoke fakevga.com on one system:
Lenovo 100e 11.5"(64GB eMMC, Intel Celeron N3350) with a SOC.
netbook which reports "VGA card required" on many programs, but supports VESA3.0, has many VESA modes, supports MTRRs writecombining caching for VGA and LFB with the Broxton onboard Intel Graphics. Never noted any other glitches on this one system after executing fakevga. Everything just works as it should from then on, from Quickview Pro 2.61 to X-VESA to older Apogee games. So, something about its vBIOS is crippled in VGA mode INT 10h function 0x1A00h which doesn't affect VESA and seems to be an artificial software, vbios limitation.
Intel seems to have intentionally cripped its post Broadwell onboard graphics BIOSes, the later Apollo / Broxton chipsets are the most denuded of all. For no good reason. Some of these intentional disablements can be fixed in software, like you've so expertly done with Nvidia GeForce cards and NEWAX.
AMD Ryzen did the same thing. Ryzen 1700 and above onboard graphics don't seem to support any VGA at all (even 320x200x8) or 8-bit modes in DOS. 16 and 32-bit VESA modes @ 640x480 and up are enabled. All programs using low VGA resolutions fail on such a vBIOS. Come to think of it, I should try running fakevga on that system. Such systems are basically unuseable in baremetal DOS because of that castration of the onboard vBIOS.
I'd never try running fakevga on a system with only an EGA / CGA card installed, or other such nonsense.
X-VESA RC1 (Update)
RC1
- minor fix update and optimization
Hey!
I want first to thank you Marco for such a remarkable tool, the level of engineering and polish put into this is quite mind blowing. I wish I had your skill!
I tested a Quadro FX540 in my main system (Ryzen 5700X3D), which is very close to a Geforce 6600 LE PCIe, I have enabled write combining with Reyer's MTRRLFBE (VGA & LFB). Here are some results. I would say that everything looks normal, I don't know what else would be interesting to you, let me know if you want more tests.
Except that for the dual page video move test I have "VESA retrace status" reported as FAIL, and I indeed see the line flicker. VGA version works as intended. I guess it's related to what you mentioned about the nVidia logic of triggering the refresh signal at the end of the blank period? I have to notice that this card suffers from flickering on some Duke Nukem 3D or Quake graphics modes, which is solved by Falco's MSKVBEF7 for example (must be a positive side effect of this tool as it was not intended to fix anything on a generation this old).
ockiller wrote on Yesterday, 17:06:Hey!
I want first to thank you Marco f...[CUT]
Thanks a lot for the detailed test and for the kind words — much appreciated!
About the VESA retrace status = FAIL in the dual‑page video move test:
yes, what you’re seeing is completely normal for Nvidia cards of that generation. Their VBE implementation triggers the “retrace” signal at the end of the blanking period, not at the beginning like standard VGA hardware. Because of this timing difference, the VESA 4F07h “set display start during retrace” call cannot reliably synchronize page flips, and the result is exactly what you observed: occasional flicker and a FAIL status.
The VGA version works correctly because it uses the classic 3DAh/3BAh vertical‑retrace bit, which is still generated in the expected way.
If your FX540 shows flicker in VESA page‑flipping tests (and in games like Duke3D or Quake), that’s completely normal for this generation of Nvidia cards. Their VBE BIOS handles the retrace signal in a non‑standard way, so 4F07h “set display start during retrace” cannot reliably synchronize page flips.
If you want to fix this behaviour, you may want to try NEWAX, which was specifically designed to correct Nvidia’s VBE timing issues on GeForce/Quadro cards:
NVIDIA Kepler/Maxwell/Pascal VESA Bios Bug (workaround found) (last pages)
It replaces the broken 4F07h logic with a proper handler and restores stable page‑flipping on many Nvidia cards.
If you test it on your FX540, I’d be very interested in your results.
NEWAX on GitHub: https://github.com/Marco-Pistella/NEWAX
Great tool! I don't know how to use it as I'm too stupid to understand it but it's really great. Thanks for sharing.
eM-!3 wrote on Yesterday, 17:57:Great tool! I don't know how to use it as I'm too stupid to understand it but it's really great. Thanks for sharing.
Thanks! Glad you like it.
No worries — you don’t need to understand everything to use it. Just have fun experimenting with it at your own pace.
Marco Pistella wrote on Today, 07:00:Thanks! Glad you like it.
No worries — you don’t need to understand everything to use it. Just have fun experimenting with it at your own pace.
Few years ago in my very first post to the forums I described my problems with Scorched Earth in high resolution. I think that your tool might be helpful to find the real reason behind it. I just need to learn more about huge amounts of information that you give to the user.
