OSDev.org

Hi all,

Well I'll go straight with this.

Lately I was looking for protected mode programming of vesa. ie how to make vesa work from protected mode.
I have searched google, but only found the explanation for VESA programming using regs. though they were in 32bit PM mode.
I also referenced to various OS (though they pretend to be open source), but couldn't find any, cause nobody provided any source code.
I have also search this forum wasn't able to find any resource.

To be precise I need to know a way to retrieving VESA info from PM without switching to RM again

So, All i am asking is: can you people please provide me with some reference that i could work with and make a VESA driver for my OS.
Some code snippet would be helpful as it's always easy to understand by reading a code along with the documentation.

Hi,

The best way is to use v86 mode, if you really can't make the switch back to real mode. Also, don't rely on the Protected Mode interface being present - support is poor at best.

Cheers,
Adam

Snake wrote:Hi all,

Well I'll go straight with this.

Lately I was looking for protected mode programming of vesa. ie how to make vesa work from protected mode.
I have searched google, but only found the explanation for VESA programming using regs. though they were in 32bit PM mode.
I also referenced to various OS (though they pretend to be open source), but couldn't find any, cause nobody provided any source code.
I have also search this forum wasn't able to find any resource.

To be precise I need to know a way to retrieving VESA info from PM without switching to RM again

So, All i am asking is: can you people please provide me with some reference that i could work with and make a VESA driver for my OS.
Some code snippet would be helpful as it's always easy to understand by reading a code along with the documentation.

VBE3 has a structure in RAM that you can search for. The signature is ascii "PMID". However, in VBE3 the protected mode interface is optional, and it also requires you to use 16-bit protected mode.

IMO, you're better off just dropping back to real mode, using a VM86 task, or gathering the info before you switch to protected mode in the first place.

What the above have posted is right, If you want a reliable way to get vesa info than you need to
1. get the info and switch mode on bootup (realmode)
2. use V86
3. go back and forth to realmode

That it, the chose is your, there's no other way to do it if your talking vesa, Yes theres a vesa 3 pmode interface, but as it 16-bit pmode and not widely used, its no help.
Maybe that why you can not find any code.

PS: If you put a poll up on this forum, asking what method they use for vesa mode switching, 95% would use one of the 3 above methods.

Dex wrote:What the above have posted is right, If you want a reliable way to get vesa info than you need to
1. get the info and switch mode on bootup (realmode)
2. use V86
3. go back and forth to realmode

That it, the chose is your, there's no other way to do it if your talking vesa, Yes theres a vesa 3 pmode interface, but as it 16-bit pmode and not widely used, its no help.
Maybe that why you can not find any code.

PS: If you put a poll up on this forum, asking what method they use for vesa mode switching, 95% would use one of the 3 above methods.

There is one more option: You could use/implement an x86 realmode emulator.

I'd go for option "switch modes in boot stages" or for the realmode emulator. Counter arguments for the other options include, but are not limited too, the following points:

• The VESA Protected Mode interface isn't available in the most cases.
• Using V86 isn't possible in Long Mode. (Granted, the OP was asking for Protected Mode...)
• Going back and forth to Real Mode isn't very nice from Long Mode. (Granted, the OP was asking for Protected Mode...)
• Going back and forth to Real Mode has issues with interrupt servicing. You have to be sure, that no interrupt occurs, because you may have no 16 bit Real Mode service routines to handle them. Disabling interrupts with CLI isn't an option, because the BIOS code could reenable ints (and many video BIOSes do it...). Effectively you have to reprogram the PICs/APICs so that no interrupt is delivered. Not very nice.

--TS

Hi,

Of course, the problem with an emulator is that it's a lot of code to add if you simply want a basic resolution switcher. If you'll use it for other things as well, then it may be worth it.

I would say that the interrupt servicing argument above is not nearly as severe as it sounds - as long as you save the real mode IVT (0 - 0x400) and re-base the PIC before you go back to real mode, there is no problem. A wrapper can easily be built which will allow your kernel to run any real mode function with little more effort over running a pmode function.

Cheers,
Adam

AJ wrote: I would say that the interrupt servicing argument above is not nearly as severe as it sounds - as long as you save the real mode IVT (0 - 0x400) and re-base the PIC before you go back to real mode, there is no problem. A wrapper can easily be built which will allow your kernel to run any real mode function with little more effort over running a pmode function.

This is what I do in my bootloader. My entire bootloader runs in protected mode with interrupts disabled, and uses a nice little wrapper to go back to real mode and run whatever BIOS function I need. Aside from making sure to save and restore the real mode IVT, I also enable interrupts in real mode just before calling the BIOS function, and disable them again as soon as that function completes. As Hyperdrive pointed out, BIOS code could re-enable interrupts and many do (however the bochs/qemu BIOS code doesn't), so I just make sure to re-disable interrupts after the BIOS functions are complete. Without that, on some machines I would get a double fault exception as soon as I was back in protected mode and had installed my protected mode IDT.

I use the same method as AJ, with no problems.

AJ wrote:I would say that the interrupt servicing argument above is not nearly as severe as it sounds

The other mentioned arguments have a similar level of severity. I just wanted to point out that it isn't done with only switching back to Real Mode as such.

AJ wrote: - as long as you save the real mode IVT (0 - 0x400) and re-base the PIC before you go back to real mode, there is no problem. A wrapper can easily be built which will allow your kernel to run any real mode function with little more effort over running a pmode function.

Hm...

What do you do in case an interrupt fires and you are in real mode? You can't use your pmode ISRs... Do you have 16 bit real mode ISRs? Or do you have an ISR wrapper that goes to pmode, calls the real ISR and drops back to real mode?

I have no problem with that - I'm just wondering how you are handling it.

--TS

the bios' interrupt handlers are also in the IVT - that means if you don't do anything, a decent handler gets called automatically (and sometimes the bios call *needs* that interrupt handler). For VESA, your best bet is to just keep interrupts disabled and hope they don't get enabled again.

It all leads to the conclusion that using v8086 mode is technically better than dropping to real mode.

As far as realmode interrupts goes, its simple as To re-enable realmode interrupts, also with one or two exceptions, you just reverse going to Pmode, to go back to realmode call the function than go back to pmode set up as you did in the first place.
As a example of low over heads, i can go to realmode to read from floppy using bios, go back and forth for each 512bytes read, and still read from floppy faster than you could from windows or linux.

NOTE: I also have a pmode floppy, hdd, driver, so its not a case of be too lazy to write a pmode driver.
There are just big benefits by having both types, eg: you can read/write to usb fob, usb floppy or usb hdd using the goback to realmode method.

mind sharing some of that?

I made a vesa demo that goes to and from pmode to realmode every 10 seconds to switch mode (vesa 640x48032bpp to text mode mode 3)
It may help someone
http://dex4u.com/demos/VesaDemo.zip

Combuster wrote:the bios' interrupt handlers are also in the IVT - that means if you don't do anything, a decent handler gets called automatically (and sometimes the bios call *needs* that interrupt handler).

What if a interrupt from the NIC fires while you are in Real Mode with interrupts enabled? Even if you re-remap your PIC the BIOS can't do anything with it. It has no handler for this. And even if it has a handler for this vector it can't handle the interrupt correctly.

Conclusion: You have to mask the NIC interrupt. And, consequently, you have to for every other interrupt. If you mask everything there is no need to re-remap the PIC. And when you mask everything, take care of spurious interrupts otherwise you shoot yourself in the foot.

Combuster wrote:For VESA, your best bet is to just keep interrupts disabled and hope they don't get enabled again.

Guess what - the first (or one of the first, I don't remember clearly) instructions my ATI cards BIOS does is 'STI'. Sorry, Combuster, for dashing any hopes.

Combuster wrote:It all leads to the conclusion that using v8086 mode is technically better than dropping to real mode.

If you are in Protected Mode, yes. But if you are in Long Mode there is no V86 mode. Well, it may be better to drop to Protected Mode and use V86 there than to drop to Real Mode. Hm, here I have to think more about it (what could go wrong?)...

So, IMO bottom line is: Don't use BIOS calls when you are past the bootup (i.e. you are fully up and running) or use an x86 (Real Mode) emulator.

--TS

Hyperdrive wrote:Sorry, Combuster, for dashing any hopes.

Didn't I already mention that it was a bad method anyway?