OSDev.org

Everyone is talking about setting the video mode using VBE, but do you really need that? You're using GRUB, you could have GRUB set the video mode for you. Specify the mode you want in your multiboot header, and then read the multiboot structure to determine the layout of the frame buffer.

hi,
benlunt, thanks for your reply.now i can to the screen and draw to the screen, without setting colors.octocontrabass, i can set it in grub, but then i wont be able to switch again(?).

You're welcome.


Octocontrabass has a good point that Grub will set the screen mode for you, but as you state, only once. You cannot change it again via GRUB. To do so, you either have to call your v86 code to call the BIOS or you have to write your own video driver.

Usually, you allow the loader -- in your case, GRUB, in my case, my loader -- to set to a screen mode the initial OS would like to use. Then later, when you load a video driver, if you find that the video supports a better mode/display, you can then use that driver to switch to that mode.

However, video drivers are very specific to the video card and there are many, many cards. This is not part of the hobby OS Dev I suggest. Stick with whatever the loader can do and go from there.

Ben

Hi,



Assuming that during boot you set the video mode to the best video mode that is supported (by the monitor, by VBE and by your OS); the only reasons to switch video mode a second time are:

• Your code is bad and doesn't support resolution independence, so people have to change video modes because (e.g.) fonts are too small to work around the fact that your code is bad.
• The user unplugs the monitor and plugs a different monitor in (where a different video mode would be best and the current video mode may not be supported). In this case VBE is completely useless - you can't even figure out that the monitor was unplugged and the user may not be able to see anything at all (and won't be able to tell the OS that the video mode needs changing because they can't see anything).
• The user is doing something where they need to reduce resolution for performance reasons (e.g. 3D games with expensive shader effects where the user wants to improve frame rate). In this case it costs almost nothing to do the graphics at a lower resolution and then scale it up; and most of these cases simply won't exist until/unless you start having games that desperately need support for GPU that you won't have while you're using VBE.

Essentially; the disadvantage of not setting a video mode once during boot (e.g. using GRUB) is that you can't do something that's almost entirely irrelevant anyway; and the advantages are that you don't need horrible/complex virtual8086 mode (that prevents you from porting your OS to 64-bit) and your OS won't become an obsolete piece of junk in less than 18 months (when Intel stops supporting BIOS in 2020 and no computers support VBE ever again).


Cheers,

Brendan

if i set the video mode during the boot, i wont be able to switch again.if i quit VM8086 due the intel no support for bios in 2020, then i'll can't do many other things that(for me)is necesary the bios, almost a just bios interrupt.if i quit vm8086 i'll need another way to do what i do with the bios.how i can do that??.as far as i know these interrupts arent in uefi

That's right, they are not in UEFI.

The point is, contrary to many opinions here, is that you should write your own boot loader, doing everything you need to do while still having access to the firmware, whether that be the Legacy BIOS, the UEFI, or whatever firmware there is, including setting the screen mode, then move to protected/long mode and forget about the firmware. At that point, if you ever need to do something that a call to the firmware could handle (which should be rare), you will need to do it via direct hardware programming.

As for the 2020 deadline, or whatever this may be, in my humble opinion, don't worry about it. The Legacy BIOS is going to be around for a long time. Look how long support for a v86 mode was supported. How about real-mode? Look how long the A20 line was supported. How about PS/2 ports (keyboard/mouse) or at least legacy support for them. The legacy BIOS will be around for a long time to come, if not simply emulated by the modern firmware.

Anyway, my suggestion is, and again, against many opinions, skip Grub and write your own boot loader. There are many reasons for this. First and foremost, you learn how to do it. Second, you get to have full control of the machine, doing what you need to do before the kernel takes over. There are many other reasons as well.

Just my opinion,
Ben

ok then. i'll write my own bootloader. i think some links will help but i think i know how to do it

EDIT:i'm wrong.totally wrong

A simple video driver for QEMU, bochs and virtualbox is the BGA, which is relatively simple to program.

Hi,



I'd take this very seriously. About 6 to 12 months ago, Intel announced official plans to phase out BIOS by 2020 and that's not something Intel are likely to do if they aren't sure. This was always inevitable (the "hybrid UEFI and BIOS for backward compatibility" transition period that began in 2005 had to end at some point, and 15 years is longer than average) and I've been predicting this since at least 2013.

Of course BIOS will still exist in emulators like VirtualBox, and it'll take a while before people upgrade existing/old computers, but at this point in time it's (still) obvious that failing to at least make it possible to support UEFI in future is a guaranteed death sentence.



Yes, all of this awful old junk had to stay because BIOS requires it; and making it possible to get rid of all the legacy hardware is the reason Intel wants to get rid of BIOS. I'm thinking it'll probably take less than 6 months between "old chipset without BIOS" and "new chipset without BIOS, A20, PS/2, PIC chips, PIT, legacy ROM areas, legacy VGA area, ..."); and by 2021 we'll finally end up with lean and mean PCs without the unnecessary baggage that no major operating system (Windows, OSX, Linux) has required for at least a decade.


Cheers,

Brendan

thomtl, thanks, but the idea for the OS is also run in real hardware.brendan, benlunt and many other people have said to me for writing my own bootloader, 'cause with it i'll can call interrupts.but if the problem is the protected mode of grub, isn't the solution leave from protected mode??

Hi,



Why? There is (almost) no sane reason to want to use VBE after boot.



The simplest way is to set the best video mode during boot and then emulate worse video modes that nobody wants to use by writing a little software that reads pixel data from a fake/emulated frame buffer in RAM, scales the pixel data up and/or convert pixel formats, and then writes the resulting pixel data to the real frame buffer. This same emulation trick (with a few additions - font data lookup) can even be used to make the fake/emulated video mode so crippled and ugly that it's effectively identical to ancient monochrome text modes from before VGA existed (still without actually changing the real video mode).


Cheers,

Brendan

well, i think thats very complicated. leave from protected mode lets me use interrupts, for things that i consider that can't be done in C. also my plans are not only vbe, also vga

More than likely, they will simply eliminate real mode entirely at the 2020 mark, making the A20 line and the BIOS routines moot and making UEFI booting the only option.

Several of the other things you've mentioned are ones which that were imposed on Intel by IBM's designs for the PC, PC/AT, and PS/2 product lines, and are, for the most part, only emulated even now, IIUC. For example, the Local APIC, inside of x86 CPUs as far back as the Pentium 'refresh' of 1994, bears little if any actual resemblance to the 8253 PIT even though the former was made by Intel originally - and IIUC, the legacy behavior is in the CPU's internal firmware, not hardware.

I wouldn't be surprised if they eliminated booting into 32-bit p-mode, for that matter, and made 32-bit code a legacy support feature to be phased out over a few years, as well. Even supporting just two different operating modes is getting burdensome, and they have already stopped making CPUs without 64-bit modes for mainstream use, so this would simplify a lot.

This would be a lot less painful than the shift away from real mode has been, simply because (unlike with real mode software) most of the programs were written in high-level languages, and with less direct operations on the hardware, and most of the source code is still around and can be re-compiled with some tweaks. For that matter, the ubiquity of code compiled to .NET and JVM, or written for interpreted languages such as Python or Ruby, means most won't even need recompiling.

I'd finish by adding that recent developments - in particular, the problems Intel is having with implementing their CPUs on a 10nm process - raise the hope that we will finally be able to put that horrible x86 garbage out of our misery for good soon. I'm not sure, as we've thought that revenant was down for the count before, but maybe.

Which things?

int 33h?for example

EDIT:with int 33h i mean by set a cursor specifically a graphic cursor