OSDev.org

Hi,

Is it possible to switch to a VESA resolution once you are in protected mode?
I am aware of the way to switch with bios interrupts, and know of bankswitching without the bios.
But I would like to see a windows like system where you can change the resolution on the fly, but don't know if that is only possible with drivers.

In the category "answered ways to change mode questions":
1) Write a VGA driver.
2) Go (back to) real mode and call the bios from there.
3) Use v8086 mode.
4) Write drivers for each card.
5) Write your own real mode emulator.

6) (the easiest way) The function for changing videomode is in VESA 3.0 available in protected mode.

Caveat with option 6: The Protected mode interface will not be supported in VESA 1.x and 2.x implementations and is also an optional part of the VESA 3.0 specification. This means that your OS still has to handle the case where the PM entry point is not supported.

If you rely on VBE3 with the PM interface, expect that your OS may not be able to run on a large number of machines.

Cheers,
Adam

Plus the biggest draw back of using (6), is you need to go back to 16bit Pmode to use it, so its not much differant than going to realmode and back.

...not to mention that looking at the VBE3 spec, setting up for PMode looks anything but simple.

My suggestion: If doing this directly from a 32 bit kernel, use Combuster's option 3. If doing it once at startup from your boot loader, use Combusters options 2 or 3.

Once your kernel progresses, try options 1, 4 or 5. On each occasion, attempt to set the mode with an LFB - you will later have to add support for systems that do not support this, but in my experience most do.

Cheers,
Adam

But when you ask the bios to switch to a vesa mode the bios isn't performing magic (I hope)
So it should be possible to write a 32 bit version of what the bios does,
Or am I missing something

Jacobbus wrote:But when you ask the bios to switch to a vesa mode the bios isn't performing magic (I hope)
So it should be possible to write a 32 bit version of what the bios does,
Or am I missing something

But the bios is generally closed-source and proprietary. It would be difficult if not impossible to replicate, and may not be the same for all cards.

AJ wrote:...not to mention that looking at the VBE3 spec, setting up for PMode looks anything but simple.

My suggestion: If doing this directly from a 32 bit kernel, use Combuster's option 3. If doing it once at startup from your boot loader, use Combusters options 2 or 3.

Cheers,
Adam

Wat's better: Switching to realmode or use vm86?

But when you ask the bios to switch to a vesa mode the bios isn't performing magic (I hope)
So it should be possible to write a 32 bit version of what the bios does,
Or am I missing something

yes, your missing the fact that the 'BIOS' calls which switch video modes, are on the video card -- not the MB, which means that code which actually does the switching is different for each video controller

svdmeer wrote:Wat's better: Switching to realmode or use vm86?

It really depends on your environment. If you already have task switching with ring 3 support and are happy writing a Virtual Mode Monitor (or are just using CPU's which suport VM extensions) and just want video mode switching, go for v86 every time.

I am writing a boot loader where I have none of this environment and I want to use BIOS disk access functions (which can't be used in v86 - they want control over interrupts). Real mode is more appropriate for this situation.

Cheers,
Adam

AJ wrote:

svdmeer wrote:Wat's better: Switching to realmode or use vm86?

I am writing a boot loader where I have none of this environment and I want to use BIOS disk access functions (which can't be used in v86 - they want control over interrupts). Real mode is more appropriate for this situation.

Cheers,
Adam

A few years ago, I wrote a function to call BIOS-interrupts from protectedmode. The function switches to vm86 mode, calls interrupt functions and returns. It happened from a single-tasking environment, meant for a bootloader. I even used interrupts: From every interrupt routine, I switched to vm86 mode and called the vector in the realmode vector-table. It worked ok. Without using any features newer than 386. From protectedmode, realmode interrupts are used. For example the BIOS-keyboard buffer worked from protectedmode when I pressed a key.
Sadly, there is a major bug. All int 10h functions work, but int 13h gives an exception, a bug I could never solve. Maybe I will reuse this code soon. But I think it's possible to use BIOS interrupt handling & BIOS routines from a single tasking protectedmode environment without own drivers.

Hi,

IIRC, the Intel Manuals themselves suggest not using v86 for disk I/O (such as int 0x13) - or was it on RBIL? Either way, I would not suggest using int 0x13 in v86 - even if you get it going on one machine, I think there are far less guarantees than with using BIOS int 0x10.

Cheers,
Adam

AJ wrote:Hi,

IIRC, the Intel Manuals themselves suggest not using v86 for disk I/O (such as int 0x13) - or was it on RBIL? Either way, I would not suggest using int 0x13 in v86 - even if you get it going on one machine, I think there are far less guarantees than with using BIOS int 0x10.

Cheers,
Adam

Microsoft Windows '95 does use int 13h @ vm86 (16-bit disk access) doesn't it?

the bios don't contain all the drivers for all video cards.

if you buy a PC with a "X videocard X" onto, then, at boot (using bios), you will set vesa modes.

if you change the video card, you don't have to change your bios to set the video mode, because VGA bios is not PC bios.

by evidence, there is a STANDARD layer somewhere between BIOS and VESA that permits to change all video modes with the simple int 10h ( in fact, a function inside the bios that wil call some functions into the VGA bios????