BIOS interrupts in C

Franchie · Post by **Franchie** » Mon Jun 11, 2007 7:46 am

Hello,

Firstly sorry for a stupid question, I just can't seem to find a definitive answer anywhere...

I gather that I am allowed to call a limited subset of BIOS interrupts when in protected mode.
So far, I have set up a basic kernel with an idt, gdt, and isr (not edited much from the 'standard' routines). They appear to work fine, since I am able to access all the physical memory, set up and handle interrupts for the keyboard and PIC, etc...

Now I would like to call a BIOS interrupt (for example to get VBA modes).
So I call the following asm function from my C code:

Code: Select all

call_interrupt:
cli                 ; clear interrupts (so that nothing interferes, who knows)
mov eax, 0x4F00	  ; value of AX...
int 10h             ; actually call the interrupt!
sti                 ; start the interrupts again!
ret

However, instead of whatever data I should be receiving, I receive my own error message set up in isr interrupt callback function (ie: kernel panic [message])...
So the question is mainly: how do I get the interrupt to reach the BIOS, or is that not possible?

Thanks for any help!
Franchie.

Brynet-Inc · Post by **Brynet-Inc** » Mon Jun 11, 2007 8:09 am

You cannot use BIOS interrupts in 32bit protected mode... Without using v8086 mode.

http://www.osdev.org/wiki/Protected_mode
http://www.osdev.org/wiki/Virtual_8086_Mode

inflater · Post by **inflater** » Mon Jun 11, 2007 8:15 am

You can't use BIOS in protected mode. If you need it so much, you can switch back to real mode, do the interrupt, and jump back to pmode (works on 80386 and better; but it *is* possible to do it in 80286), or you can play with the tss and set up a v8086 mode, which is harder (works only on 80386 and above). Or you can download some source of a XT BIOS, "cut" the interrupt routines and put them in your OS's IDT.

I do not recommend v8086 much, I think it is harder to setup.

If you are programming a commerical operating system, your OS should have GUI. And working with disk in your OS GUI the Windows 9x style, alias switching to real mode or doing V86 stuff, is a pretty big pain in the neck. Why? The system will just half-freeze and it will wait until the disk operation is complete. Remember Windows 3.1 or 95?

So you will have to program a new floppy driver by using only OUT, IN, MOV etc. (so no INT 13) and say goodbye to BIOS, which I currently can't

. Or make a GUI and your OS single-tasking.

Regards,
inflater

Franchie · Post by **Franchie** » Mon Jun 11, 2007 8:21 am

Okay great, thanks!
That makes things much clearer!

I don't really need the BIOS that much, since I got most things working (so far) without it... I just thought it would be easier in this particular instance than doing it manually. Obviously no shortcuts allowed

Thanks for the help!
Franchie.

Combuster · Post by **Combuster** » Mon Jun 11, 2007 8:39 am

Or you can download some source of a XT BIOS, "cut" the interrupt routines and put them in your OS's IDT.

Nonsense. Our friend is talking about using the video bios. Everything done in there is video card specific and can't be taken from one version of it. Even parts of the PC bios are motherboard-dependent.

That said, you can not use the PC bios with a protected mode kernel. Most likely you have remapped the PIC, set up the PIT and things like that, which the bios needs in its original state. Using many of the PC bios functions effectively means shutting down your OS and restarting it afterwards. Writing your own drivers is better, and easier since documentation is quite well available.

The video bios is more user-friendly and can be used from protected mode with few problems. Dropping to real mode is the cheapest way of doing so, while v8086 mode is more secure.

@Inflater: Will you try not to post wrong/misleading information.

EDIT: Noticed update:

Why? The system will just half-freeze and it will wait until the disk operation is complete.

Again, nonsense. That is just a case of bad design. Win'95 uses port I/O to read/write sectors to and from floppy. To do this, the floppy signals an interrupt for each byte that needs to be read/written. Essentially its a DoS attack from a poorly-written driver. Modern oses, and the bios, uses DMA which is faster and doesn't cause the overhead as the data is transferred without processor intervention. Also, you can use multitasking over an v8086 task to prevent the lockout problem caused by a long execution time of a bios call.

JJeronimo · Post by **JJeronimo** » Mon Jun 11, 2007 12:48 pm

Franchie wrote:Now I would like to call a BIOS interrupt (for example to get VBA modes).
So I call the following asm function from my C code:
Code: Select all
call_interrupt:
cli                 ; clear interrupts (so that nothing interferes, who knows)
mov eax, 0x4F00	  ; value of AX...
int 10h             ; actually call the interrupt!
sti                 ; start the interrupts again!
ret

You can use VESA BIOS from protected Mode, yes, but:
- You need to ask the BIOS for the protected mode interface support before going to PM (this interface may be absent in your BIOS, and/or in someone's else who will hopefully want to run your OS... it only exists in VESA 3.0, and in a limited form in VESA 2.0)
- Then, the traditional int-style hooks the BIOS provides for you while in real mode are accessed through the Real Mode Interrupt Vector Table. But in PM the IDT you just loaded doesn't have the BIOS hooks, plus the BIOS entry points in the RM IVT are real mode code, so you don't want to simply copy and convert them to your own IDT either...
- So, to use any of the few PM BIOS functionalities, you need to use specific methods... AFAIK, for VESA BIOS you need to scan the BIOS image for an header or ask the Real Mode int 0x10 interface where it is... for more information please read the VBE specs at:

Site: https://vesa.sharedwork.com
User: [email protected]
Password: stds2007

Anyway, I suggest that you plan to implement a VM86 monitor (don't bother with the Secure Virtual Machine, because computers with processors that support that also support VESA 3.0... so it's useless for graphics), and use it to call the BIOS in the case you need something after going to protected mode (not just graphics)...
I also suggest that you implement a standard VGA driver for older computers... but first invest some afternoons studying it because it's a bit hard to understand...

JJ

Franchie · Post by **Franchie** » Mon Jun 11, 2007 1:37 pm

Thanks for the response, thats really interesting, and thanks for the link (and password)! I will definitively spend time reading all of that!

For the moment, I am still designing my driver interface, which is why I wanted to investigate their potential needs.

A small question however. I do not have any real need for the VM86 monitor other than the graphics, so I would be happy to do without it if possible. I currently find the RSDP table via a simple scan in the designated memory location, and that seems to be working well.
I imagine you are suggesting something similar by "scan the BIOS image for a header". I will need to read your documentation to find out exactly what to look for though!

Would this be an acceptable alternative ? Or does the other method have advantages that I have not yet guessed of?

Thanks for your continued support!!
Franchie

JJeronimo · Post by **JJeronimo** » Wed Jun 13, 2007 5:45 am

Franchie wrote:Thanks for the response, thats really interesting, and thanks for the link (and password)! I will definitively spend time reading all of that!

The user name and password are just to skip stages... If you went to the vesa homepage and filled-in a form they would return you the same login and pass....

For the moment, I am still designing my driver interface, which is why I wanted to investigate their potential needs.

Yes... It's essential, because you cannot in the future find that the interface is not sufficiently general...

A small question however. I do not have any real need for the VM86 monitor other than the graphics, so I would be happy to do without it if possible.

It's possible, but then if someone wants to run your OS on a computer with VESA<=2.0 with graphics (like me, who some days ago tried to run menuetOS in such a machine), They won't be able to...
You can of course write a routine the switches back to RM, does the int, and then returns in protected mode... I've done so in a boot loader... If you read the Free Loader (ReactOS boot loader) x86-specific functions you will find another implementation (I've been reading it yesterday!)...
Go to the svn and download the file... the path is http://svn.reactos.org/svn/reactos/trun ... iew=markup ... Please pay attention to the license...

But... It's a bit heavy... And the deeper you setup your Protected Mode environment (PIC, PIT, IDT, BDA, Paging, physical memory under 1MB, etc), the most you will have to un-setup to make sure the BIOS works properly... Imagine the Linux kernel restoring the entire RM execution environment only to execute a VESA function... and then re-setuping PM, Paging, the PIC, the timer, and the interrupt table...

I imagine you are suggesting something similar by "scan the BIOS image for a header". I will need to read your documentation to find out exactly what to look for though!

The header I talked about is explained in page 21 of the vbe3 specification (29th PDF page)...

Would this be an acceptable alternative? Or does the other method have advantages that I have not yet guessed of?

AFAIK, you can either scan the BIOS image (not the EBDA) or ask the int 0x10 interface (while still in real mode) for the protected mode entry point header...

JJ

Brendan · Post by **Brendan** » Wed Jun 13, 2007 8:06 am

Hi,

Franchie wrote:I do not have any real need for the VM86 monitor other than the graphics, so I would be happy to do without it if possible.

The easiest, fastest and most reliable method (and the method I've almost always used) is to setup the video mode during boot before you switch to protected mode, and don't allow the video mode to change after boot (unless a native video driver is used).

It's not for everyone, but it's worth a thought....

Cheers,

Brendan

Franchie · Post by **Franchie** » Wed Jun 13, 2007 8:40 am

Thanks for your helpful comments!
I have located the VBE header in the bios data, and it appears possible to use it (and I will once I reach the stage I can write a proper video driver). The other hints are also very helpful, thanks!

I plan to keep this a hobby OS, in that I will only support standard hardware, or whichever type of hardware I happen to own, something which I think appears reasonable. And all my hardware currently supports VBE! (well, except for a really old one, but its OS is stored on ROM chips so I can't boot my OS onto it anyway!). In any case, I will stay compatible with VGA by simply using another video driver...

The header I talked about is explained in page 21 of the vbe3 specification (29th PDF page)...

Spot on, nice!

Thanks for all your help!
Franchie

JJeronimo · Post by **JJeronimo** » Wed Jun 13, 2007 9:08 am

Franchie wrote:I plan to keep this a hobby OS, in that I will only support standard hardware, or whichever type of hardware I happen to own, something which I think appears reasonable.

In this case, perhaps you don't need a very robust driver interface...

And all my hardware currently supports VBE! (well, except for a really old one, but its OS is stored on ROM chips so I can't boot my OS onto it anyway!).

You can! Get an EEPROM reprogrammer and overwrite the data on the chip!

JJ

Franchie · Post by **Franchie** » Wed Jun 13, 2007 9:39 am

Lol, perhaps not, but its part of the challenge...
As for the eeprom programmer, it is an option, but I would first have to convert the entire project to ARM risc asm

Maybe, but not yet!

F.

JJeronimo · Post by **JJeronimo** » Wed Jun 13, 2007 10:25 am

Franchie wrote:As for the eeprom programmer, it is an option, but I would first have to convert the entire project to ARM risc asm

But of course! And there are compilers for ARM (including GCC, I think)...
What's the device kind?

JJ

Franchie · Post by **Franchie** » Wed Jun 13, 2007 12:39 pm

Lol, its an Acorn Archimedes A310, with 1MB ram, and very little hard disk space. It is currently running RiscOS 4.

[begin propaganda]
Quite frankly it was a great computer for the time, with enviable boot time by todays standards (in mere seconds; thats the advantage of having an OS pre-loaded on ROM). It's also quite interesting, as it used co-operative multitasking. Also, its programs were in fact special directories: these contained the actual program, but also all the related data, etc... in this way, a program could be installed by simply copy&pasting, and completely uninstalled using the 'delete' key. No mess left like the windows registry.
[end propaganda]

Anyway, there's the whole story...

Franchie.

OSDev.org

BIOS interrupts in C

BIOS interrupts in C

Re: BIOS interrupts in C