OSDev.org

It is possible that I do not understand your intentions and if so, I would like to apologize.

It has been said many times that it is not a good idea to play around with the VGA specific things anymore. Of course, it would work if the hardware supports it. With UEFI being concerned, it would be reasonable to look into the future and use a standard interface to control the video hardware.

If you want to do this anyway, there should be some VGA documentations available. I am quite sure that someone can give you a better reply concerning that topic.

If EFI leaves the video card in native mode, you can pretty much assume you will not be getting it into a VGA mode using only VGA code. And since EFI makes absolutely no guarantee about setting a VGA-compatible mode, basically all bets are off.

Which leaves two options: make a wild guess, expect a PC bios available for use, and subsequently alienate all Mac users and then some, or just forget about VGA completely. Sensibility (and pretty much all the previous posters sentiments) expects you to choose the latter.


TL;DR: EFI and VGA are mutually exclusive.

If booted on Mac, RDOS will fail long before getting to the video-BIOS, so that is no problem.

Reason like this about it:

UEFI is not a spec that is usuable for writing video-software. It is a spec that makes it possible for OSes with custom-made graphics drivers to make some minimal user-interaction in case there are problems with boot or similar (I bet that is why Linux runs the UEFI defined mode when booting fail-safe).

As an OS developper without a specific video-driver for every possible video hardware you are out of luck with UEFI. You won't get past the initial boot, and can at best display to the user that you have no video driver, and lock-up. Users will not be very content with this.

Thus, you try the existing standards for setting up a video mode, and getting a LFB address. That standard is called VBE, and UEFI in no way can superseed it as UEFI doesn't contain an interface for setting video resolution and getting the LFB buffer, in addition to its bit organization. Instead, UEFI makes it possible for OSes with a driver for every video hardware (Windows) to drop the VBE interface so less lucky OSes cannot run. That's what UEFI is really about. A way for BIOS developpers to stop supporting anything else than Windows, or their own pet-OS.

No, sensibility makes you use VBE, and if this fails, you are out of luck anyway since no typical hobby-OS developer has a graphics driver for every possible video hardware.

I do not understand. Graphics Output Protocol? I can set the video mode and get the linear framebuffer address. I do not need to develop a specific video driver for that. The backend of that functionality may currently be the VBE but I do not have to care about that.



There might be some truth behind this statement.

I read-up on it, and it is better than I first suspected. GOP might give you a linear frame-buffer, and could setup the mode for you. That is the same as for VBE. For doing this dynamically after OS boot, it might be possible to create a process with unity-mapped page-tables, and let it call the GOP entry-points, which is also possible to do with VBE (using V86-mode). What is unclear is "exit-boot services". Would this be necesary to do, and what exactly does this do? What is the drawback of not doing this? Will some devices be started if this is not done?

I also suppose that if an OS expects to set a 80 x 25 text mode, and none is provided, this could be emulated in graphics mode one way or another. The hard way would be to intercept and emulate accesses to B8000 -BFFFF. The easy way would be to have a API for outputting text that could be built on real text mode or emulated.

ExitBootServices() call is necessary to get full control over the system. Up until that point, (U)EFI firmware is owner of everything; after the call, the full control is passed to the application. By everything, I mean literally everything - you can check for example memory management functions in UEFI specs.

It's simple: if you want UEFI application, don't call it. If you want OS, call it.

The ExitBootServices API is used to disable the boot services, and the requirements of those. Among the requirements are: No paging (most platforms)/Firmware managed identity paging (amd64); firmware managed interrupts; all memory allocation through firwmare; all hardware interaction through firmware enumerated EFI device drivers.

Once you invoke ExitBootServices (Probably after SetVirtualAddressMap, so that you can tell EFI where you're going to map all of its runtime services and it can redo its executable relocations when you invoke ExitBootServices), all boot services become, well, unavailable.


Emulating a text mode isn't hard with a bitmap font. For colour attributes and such, you might decide to go for the traditional option and just interpret ANSI escape sequences.

http://wiki.osdev.org/VGA_Hardware
the last table: List of register settings
you'll have to reprogram via ports

I know this is a thread from 2012 but here's the basics of what it would take to get an Intel-based Mac into legacy VGA modes such as text mode - since its BIOS has been removed, and it only has EFI.

tl;dr: you can use the VGA modes on Intel-based Macs because they use AMD and Intel GPUs.

1. If it is an AMD GPU (such as the Mac Pro) -

The AMD ATOMBIOS is missing.

Grab a copy of the ATOMBIOS from the most closely related card. Example: the 2013 Mac Pro "Trashcan" used dual AMD FirePro D300, D500 or D700s - Pitcairn or Tahiti silicon - and you can't get the exact match on any other hardware. But for ATOMBIOS you would be fine using AMD FirePro W7000 to match the D300, and FirePro W9000 for the D500 and D700.

ATOMBIOS is an emulated instruction set and has the entry point for setting the card in VGA text mode - xorg-x11-drv-amdgpu is where I would start (but it can't be used as-is because it assumes the ATOMBIOS is present and it's missing on Macs). Or it's sometimes called xserver-xorg-video-amdgpu. xf86-video-amdgpu is the proper name. https://gitlab.freedesktop.org/xorg/dri ... deo-amdgpu

2. If it is an Intel iGPU (such as a Macbook pro) -

It's the same thing, only use xorg-x11-drv-intel or xserver-xorg-video-intel - actually xf86-video-intel is the proper name. https://gitlab.freedesktop.org/xorg/dri ... ideo-intel - but check out very old commits to find the last time it included legacy text mode support.

Intel iGPUs started by extending the VGA register spec.

i810 graphics has a VTOTAL register that uses the 10 bits defined by the legacy VGA registers. But CR80 bit 0 enables "extended modes." It enables the 4 high bits in CR30. In other words, search for where CR80 bit 0 is set or cleared, and start reading from there (it's a typo but it's #define IO_CTNL 0x80) Check out the i810 chipset programming reference manual 298026.

Through Iris Xe (and in the driver, Sandybridge New Acceleration, replacing UXA) https://github.com/Igalia/intel-osrc-gfx-prm - the file intel-gfx-prm-osrc-tgl-vol-12-display-engine.pdf starts with a table and discussion of legacy text modes.

The most challenging work would be to program the CRT Controller to send display signals to the panel that the panel supports. Maybe start with a Mac mini since it will be easier to get working with a normal display that can interpret the legacy text mode resolution.

(And to be pedantic, nvidia cards should have an untampered BIOS and therefore you can call the BIOS to set it into legacy text mode. Want to boot your OS on a mac with an nvidia gpu in text mode?)