OSDev.org

Switching to v86 mode just to set up VESA VBE is quite unreliable since the 'driver' has to be loaded at address under 1MB (which requires extra bookkeeping work).
Setting VBE before switching to protected mode is a better solution, but I want to keep my bootloader minimal. I might also have to call VBE in the kernel proper (unless no? I'm not too familiar with VBE..)

What would you recommend?

Thanks

You could also just emulate x86. For me, I have a long mode OS. So emulation is the only way I would ever be able to use VBE. However, for now, my OS just wants a framebuffer, to be provided by the bootloader. And then I don't have to care if it is a VBE or GOP or native framebuffer. This does mean that there is currently no resolution changing. The only way I see to change that is to attempt to get a native driver for my hardware working (I highly doubt my OS will ever be used by anyone but myself, and as far as I know, even nVidia has pledged to release enough documentation to get a frame buffer going). It also means no 2D acceleration, no 3D acceleration, so neither videos nor games will work without burning up the CPU, but all that can follow after I make it to userspace. Build the house from the bottom, not the top.

As nullplan said, emulation is your best route. Emulating isn't the easiest, especially since some VESA BIOSes are known for entering into protected mode. Also, I would bet that some VESA BIOSes make use of CPU extensions, meaning that you should emulate a Pentium Pro or something newert. Also, VBE is very simple, so doing it in your bootloader would be an easier route then all out emulation. In UEFI, you must do it in your bootloader (since GOP can only be called from UEFI boot services).

nullplan wrote:You could also just emulate x86. For me, I have a long mode OS. So emulation is the only way I would ever be able to use VBE. However, for now, my OS just wants a framebuffer, to be provided by the bootloader. And then I don't have to care if it is a VBE or GOP or native framebuffer. This does mean that there is currently no resolution changing. The only way I see to change that is to attempt to get a native driver for my hardware working (I highly doubt my OS will ever be used by anyone but myself, and as far as I know, even nVidia has pledged to release enough documentation to get a frame buffer going). It also means no 2D acceleration, no 3D acceleration, so neither videos nor games will work without burning up the CPU, but all that can follow after I make it to userspace. Build the house from the bottom, not the top.

Isn't emulation very troublesome to implement? Parsing and executing x86 instructions sounds like a lot of pain..

If I'll never have to call any VBE functions, having a linear framebuffer set up by the bootloader is fine

Can you send the NVidia documentation link, please?

I know 3D games won't work, but CPUs really aren't so slow... with enough knowledge you can implement a very efficient software renderer, which can render not-very-complex 3D scenes at a reasonable framerate. And AMD & Intel release documentation for their graphics cards

nexos wrote:As nullplan said, emulation is your best route. Emulating isn't the easiest, especially since some VESA BIOSes are known for entering into protected mode. Also, I would bet that some VESA BIOSes make use of CPU extensions, meaning that you should emulate a Pentium Pro or something newert. Also, VBE is very simple, so doing it in your bootloader would be an easier route then all out emulation. In UEFI, you must do it in your bootloader (since GOP can only be called from UEFI boot services).

I will do that then

Isn't emulation very troublesome to implement? Parsing and executing x86 instructions sounds like a lot of pain..

x86 is a big pain because of its variable sized instructions, real mode, segmentation, etc. Emulation can be a pretty fun project, but if you don't want to do it, then you should implement in the bootloader

And AMD & Intel release documentation for their graphics card

Yes, but at least Intel's documentation is rather horrible from what I understand

angods wrote:Isn't emulation very troublesome to implement? Parsing and executing x86 instructions sounds like a lot of pain..

There are already finished libraries for it, but of course you are welcome to tackle it yourself. Doesn't seem like that big of an issue. For VBE you probably won't even need protected mode to work correctly (if BIOS does switch, then usually only to go to flat address space), and mostly it will only be in, out, and a few calculation instructions.

angods wrote:If I'll never have to call any VBE functions, having a linear framebuffer set up by the bootloader is fine

Yeah, that's what I do, and it has served me well so far.

angods wrote:Can you send the NVidia documentation link, please?

I can't, actually. I had only heard that they wanted to, and a cursory search revealed the nVidia documentation hub. Sadly it seems to want to bury me in inconsequential documents until I give up. A search for "framebuffer" turned up 84 pages of results, but most of them for some Linux driver. If someone ever does find out how to make a framebuffer on an nVidia card, it would be a good thing to tutorialize.

In any case, my laptop has an Intel graphics card and my PC has an AMD one, and unless AMD really starts to put their foot in it, I don't see much of a need to switch.

angods wrote:What would you recommend?

Set the video mode in the bootloader. That way, the kernel doesn't need separate code to handle BIOS/VBE and UEFI/GOP.

If you still want to write an emulator, go for it. You can use it to do fun things like set up a framebuffer on secondary adapters (with help from PCI) or support VBE on non-x86 platforms.

I have support for dynamic mode switching using VBE (using the real mode interface), which is handled through V86 mode. I also have my own emulator (in x86 assembly), so I can run part of the code using emulation. Since long mode no longer supports V86 mode, you either need to switch the CPU temporarily to protected mode or use full emulation.

Still, I no longer use dynamic mode switching, rather I set up the native resolution either with GOP or VBE before starting applications. For VBE, I have a setting that indicates the display width, and when this is set, the VBE mode switch is done at initialization time. For UEFI, I let the bootloader set up the optimal resolution with GOP. Thus, I can still use dynamic mode setting when doing BIOS boots, but not when booting with UEFI.

The downside of setting up a fixed mode is that you can no longer use text mode, which is a very fast interface for displaying text. Instead, text mode needs to be emulated with a fixed font, which is much less efficient.

rdos wrote:The downside of setting up a fixed mode is that you can no longer use text mode, which is a very fast interface for displaying text. Instead, text mode needs to be emulated with a fixed font, which is much less efficient.

This... Is a very debatable point. Especially considering the fact that every OS uses embedded font rendering in one way or another. I'd say the slowdown isn't even remotely significant, maybe a few hundred ns extra latency, maybe 1-2 us.

Ethin wrote:Especially considering the fact that every OS uses embedded font rendering in one way or another.

I don't think that's correct. Linux for example will happily run text mode still (as long as you compile the kernel with appropriate support) and that means it's not rendering fonts itself. The whole point of text mode is that you don't have to do font rendering in software.

Ethin wrote: I'd say the slowdown isn't even remotely significant, maybe a few hundred ns extra latency, maybe 1-2 us.

Latency is not the issue, throughput is. Writing a text mode character requires writing 2 bytes. Writing a character in graphics mode will typically be more than 256 bytes (and a generally more complex operation). In any circumstance where text output is your bottleneck, that's a huge difference.

There are other trade-offs, and I don't think optimising text output is necessarily worth worrying too hard over, but I completely disagree with your assessment that text mode is not more efficient (for displaying text).

davmac314 wrote:

Ethin wrote:Especially considering the fact that every OS uses embedded font rendering in one way or another.

I don't think that's correct. Linux for example will happily run text mode still (as long as you compile the kernel with appropriate support) and that means it's not rendering fonts itself. The whole point of text mode is that you don't have to do font rendering in software.

Ethin wrote: I'd say the slowdown isn't even remotely significant, maybe a few hundred ns extra latency, maybe 1-2 us.

Latency is not the issue, throughput is. Writing a text mode character requires writing 2 bytes. Writing a character in graphics mode will typically be more than 256 bytes (and a generally more complex operation). In any circumstance where text output is your bottleneck, that's a huge difference.

There are other trade-offs, and I don't think optimising text output is necessarily worth worrying too hard over, but I completely disagree with your assessment that text mode is not more efficient (for displaying text).

I wasn't saying that text mode is (not) more efficient, just that saying that its faster than an LFB is a pretty hard claim to prove. As for Linux still using text mode, sure it will, but only if your not on UEFI (or maybe it reconfigures the GPU). The point I was getting at regarding practically all OSes not using text mode is that in the end, when your in userland and running GUI apps, your doing font rendering all the time. It may be slightly slower than text mode but most likely not remotely significantly enough to be anything to worry about or even notice. Your not using text mode if you've got Wayland running a desktop, for example, and Windows most likely doesn't use it anymore either (though it probably does retain support). UEFI outright ditched it, and you're going to have to do font rendering in-kernel because of that unless you write a GPU driver that's capable of reconfiguring the GPU to operate in text mode.

Ethin wrote:I wasn't saying that text mode is (not) more efficient, just that saying that its faster than an LFB is a pretty hard claim to prove.

Writing 2 bytes per character is going to be significantly faster than writing 256 bytes. Unless you are disputing that claim, what more proof do you need?

(and incidentally if you agree that it is "more efficient" but not that it is "faster", what do you mean precisely?)

Ethin wrote:It may be slightly slower than text mode but most likely not remotely significantly enough to be anything to worry about

I agree with you on this part, not because it won't be a lot slower, but because text output isn't usually a bottleneck (and if it is, you probably can avoid it).

This is probably the crux. I think what you mean is: LFB versus text mode doesn't matter, overall - which is probably right. But what you are saying is that text mode isn't more efficient (edit: sorry, isn't faster) than an LFB, which is clearly not right when considering text output.

Ethin wrote:UEFI outright ditched it, and you're going to have to do font rendering in-kernel because of that unless you write a GPU driver that's capable of reconfiguring the GPU to operate in text mode.

Not wrong, but also does not mean that text mode, if you can use it, is not more efficient and faster.

rdos wrote:The downside of setting up a fixed mode is that you can no longer use text mode, which is a very fast interface for displaying text. Instead, text mode needs to be emulated with a fixed font, which is much less efficient.

You could just have text mode be one of the available preset options. Obviously if you're writing your own bootloader, you can present that as a config file option, keyboard shortcut, menu entry... Even Grub has a way to do this, which is useful for Multiboot payloads that request a graphics mode - you can "set gfxpayload=text" and it'll start you up in text mode instead.

Since I'm still very focused on building live CDs, my loader presents a menu that has "VGA Text Mode" as one of the options. It also has a keyboard shortcut to switch between graphics and text mode within the loader and will keep whichever mode it is in as it boots into the OS (though most of my video drivers will kick in and put things in graphics mode unless asked not to, so the dedicated menu option is still a bit of a necessity).

I consider EGA/VGA text mode as a novelty. You absolutely should not rely on its availability - it's a rather unique feature of PCs you won't find on other platforms, EFI gets rid of it as has already been discussed, and it's terribly limited in its functionality even when it is available. So, yes, you're absolutely going to want to or even need to write your own debug text output targeting a framebuffer if you want that. But, it's pretty simple to add support for as an optional feature, so by all means support if it you can. My kernel debug output can use it, and I provide a backend for my userspace terminal emulator that can output to it.

davmac314 wrote:

Ethin wrote:I wasn't saying that text mode is (not) more efficient, just that saying that its faster than an LFB is a pretty hard claim to prove.

Writing 2 bytes per character is going to be significantly faster than writing 256 bytes. Unless you are disputing that claim, what more proof do you need?

(and incidentally if you agree that it is "more efficient" but not that it is "faster", what do you mean precisely?)

It can be a lot more than that. In a command window, you will typically scroll the text too, which is the major bottleneck with font rendering. In text mode, you can scroll the screen by copying 2 bytes per character, while with font rendering it might be 256. If you want to scroll a 80x24 screen once, that becomes 3840 bytes vs 491520, something that is VERY noticable. I will typically implement the graphical "text mode" by regularly rendering the complete screen instead of doing it in real time. This avoids getting into "scroll loops", but also looks "slow". With text-mode, the characters will be printed directly and scrolling will be done in real-time.