OSDev.org

On qemu, you can quite easily add '-vga std' and use the BochsGA emulation (see the wiki). On real hardware, either drop to real mode very early in your code, or use a VM8086 hypervisor to run the bios (or write a native driver, but those are quite fun)

I tried all qemu's vga emulations but it just gives me that error.
For VM86 I need to have a working user space. changing back to real mode to set some flags and call interrupts and change back to pmode is something trickey and I cant use it because I use GRUB as bootloader.
So I try to arrive to user mode as soon as I can to use a VM86 to enable graphics

I didn't mean that it will make qemu support mutliboot's graphics fields, but it will allow you to write a very simple modesetting graphics driver.
Bochs_VBE_Extensions

VM8086 isn't that complex, but it does almost require a stable multitasking system.

Is this method usable on real hardware? I mean the bochs VBE
Yet I'm working on a physical memory manager. few (But time consuming) steps are remaining to get the user mode
WoW then I can use VM86

Hi,



What if one user has a tiny ("14 inch") monitor and needs large characters, and another user has a huge ("46 inch") monitor and needs small characters? What if one user has a "4:3" monitor and needs tall thin characters, and another user has a "16:10" monitor and needs wider/shorter characters?

The right way to do this is to set the video mode to "anything" (preferably the best resolution the monitor and video card support and/or the monitor's native resolution if possible); and then scale the font to suit both the size of the monitor and the resolution of the video mode to get the ideal width and height for characters in all cases. Note that the monitor can give you "EDID" information that says the physical width and height of the screen, which video modes the monitor supports and (e.g. for LCD monitors) the monitor's native resolution.

It also isn't too hard to "pre-scale" a bitmap font once during boot (and then use the already scaled font data after that with little/no impact on performance). For example, the last time I did it I started with "256*64, one bit per pixel" data (with run length encoding and some other tricks to reduce font data size) and scaled it to "x * y, 256-bit alpha per pixel" format that was actually used. This gave relatively good results (e.g. with recognisable small 5*6 characters and nice/smooth large characters).



Normally, the firmware starts a boot loader (e.g. GRUB) and the boot loader starts your code (e.g. using multi-boot). Qemu has built-in support for starting multi-boot kernels directly with no boot loader, no file systems and no disk devices - the kernel just magically appears in RAM. Qemu's built in multi-boot support is nothing like how real computers work; and can be "differently compatible" with the multi-boot specification.


Cheers,

Brendan

At this early stage I just want to use a small resolution and my own font instead of default text mode fonts and its small resolution. But later, When everything is ready to use VM86, I will add support for more resolutions


I think VBE gives me the EDID?


I want to use raw binary font (Of course if I get the graphics working )


Thats so cool. But doesnt that font format slow down the print performance? Making a x*y 32 bytes character may reduce the performance :O


You mean qemu can even load the kernel binary itself? Even without that small assembly kernel loader?
But in this early stages I cant risk and run my OS on a real hardware. It may crash the system :O

Hi,



I tend to not bother with VM86 - it doesn't work reliably for UEFI systems; and means the OS has to care what sort of firmware/environment the boot loader booted from. Most people don't change resolutions unless they're playing 3D games, and most people won't be playing 3D games (due to performance problems) unless there's a native video driver, so there isn't really any need to switch video modes after boot (unless there's a native video driver). It's enough to set the best video mode you can during boot.



Yes - getting the EDID is very easy. It's just "blocks of data" though, so you'll have to parse it to extract the information you need.



It depends on how good your code is. For a basic 2D GUI (text, windows, menus, icons, etc) your code would/should still be fast enough to get acceptable performance when running on Bochs (which is much slower than real computers). It also depends on how much other stuff your code does. For example; if you add something like dithering (which can be expensive) then the cost of drawing text is going to be unnoticeable in comparison.



As long as you don't write to hard drives or modify CMOS it's extremely difficult to do any harm (even if your code does crash).

It's always a very good idea to test on as many different (real and emulated) computers as possible; because different computers are different. It's too easy to have bugs in your code that don't cause symptoms and don't get noticed on some systems (and cause massive problems on other systems), and also too easy to end up effected by hardware and firmware bugs that your code failed to work around.

You'll also find that none of the emulators support EDID (it's hard to give information about the monitor when there isn't a real monitor and it's just a window running in some OS's GUI).


Cheers,

Brendan

So as you said, VM86 is not supported in UEFI systems. So the only ways for me to get graphics is swiching back to real mode or ask grub to give me the vbe information and enable it. But I cant use the real mode to get the vbe working cuz im using grub. so the only way is to ask grub and as one of the friends said, grub may give me wrong information.
So what should I do to get exactly the thing I want?

Hi,



Not quite. VM86 is supported in protected mode (and not supported in long mode) regardless of what the firmware is (BIOS or UEFI). VBE functions don't exist if the firmware is UEFI though, so for the "32-bit UEFI" case VM86 can be used but there's nothing to use it for.

For UEFI, there are a set of functions (called "boot services") provided by UEFI that can only be used during boot, that includes functions to get EDID and setup video modes (similar to VBE but different), where these functions are run in protected mode or long mode (depending on whether the firmware uses 32-bit or 64-bit UEFI). After the "exit boot services" UEFI function is called none of these UEFI functions can be used. GRUB calls the "exit boot services" UEFI function for you; so after your code is started by GRUB the UEFI functions for setting up video modes can't be used.



There's only really 2 choices:

• You learn to live with the problems/limitations of GRUB and forget about ever getting exactly what you want. This can include supporting "plain text" as a fall-back option, supporting all possible video modes, and still having "no working video" (because GRUB chose a video mode that the monitor doesn't support)
• You write your own code that does exactly what you want. This can include not using GRUB at all (especially on UEFI systems).

Cheers,

Brendan

So I should start writing my own bootloader This is going to take a long time

Thank you so much Brendan for your help

Hi,



In that case, I'd recommend planning for at least 5 different boot loaders:

• One for BIOS hard disk (partitions, etc)
• One for BIOS floppy disk (no partitions, BPB)
• One for BIOS network boot/PXE
• One for BIOS "no emulation El Torito CD-ROM"
• One for 64-bit UEFI

Note: "planning for" doesn't necessarily mean "implementing now". For example, you could start with one boot loader and worry about the others much much later on.

I'd also recommend designing some sort of specification that describes the way the boot loader/s hand control to the next piece (the kernel?); so that the kernel knows what state the computer is in (which CPU mode, if A20 is enabled/disabled, if it can assume anything about any devices, etc) and how/where to get information from the boot loader (memory map, video mode details for one or more monitors, boot log, etc); so that the kernel does not need to care what the boot loader (or the firmware) actually was; and so that anyone (including you later on) can look at your OS's "boot loader specification" and implement more boot loaders for your kernel.


Cheers,

Brendan

Wow so that would be so great. Btw should I write a separate bootloader for each kind of cpu or BIOS?
And one more question, is there a way to use 16 bit C in bootloader? Assembly is something hard to read and understand so it would be great if i could write the stage 2 of bootloader in C

Hi,



You will need to write a separate bootloader for each different kind of CPU (e.g. 80x86, ARM, PowerPC, etc); but you won't need a separate bootloader for each different "sub-kind" (e.g. Intel 80x86, AMD 80x86, VIA 80x86, etc).

You will need a separate bootloader for each different kind of firmware (e.g. BIOS, UEFI, OpenFirmware, etc). In some cases (e.g. BIOS) you will also need a separate bootloader for each category of boot device, but in other cases (UEFI) a single bootloader covers all types of boot device.



You probably can find a C compiler that is able to generate 16-bit code. None of the BIOS functions use C calling conventions though, so at a minimum you'd need assembly wrappers for them. Those wrappers could also switch from 32-bit to 16-bit and back (so that you can use 32-bit C); and those wrappers could be implemented in "stage 1" (allowing you to have a stage 2 that only contains 32-bit code, which uses an API provided by stage 1 to do the dirty work).


Cheers,

Brendan

So is there a way to write a portable bootloader that these frimwares can support? Or they have different interrupts and this is not possible?


Aw switching from 32bit to 16bit and reverse is a dirty work to call a BIOS interrupt from C. Its better to write all of the bootloader in assembly

IMHO, it's even better to use ready bootloaders and concentrate on things that are more interesting.
Are you sure that you want your own set of bootloaders?
Why don't you want to use, for example, GRUB or OS Boot Tools?