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 Yesterday, 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.