OSDev.org

Hey guys,

I was wondering what registers the BIOS preserves when you call one of its functions?

I.e. What registers can I rely on being the same value as they were before the intN call?

~K

It depends on each call to each device.

BIOS is out of date so it's not worth using but it's idea to control a device with a simple set mode, read sector & get key type functions is useful. Amiga and DOS did a similar thing and C worked with them fairly well.

Have a look at the RBIL: http://www.cs.cmu.edu/~ralf/files.html

For any interrupt in that list, if it does not specifically say that the register is preserved, you SHOULD assume it gets trashed.

- Monk

b.zaar, that's not useful in the least. Many machines still present the BIOS interface rather than EFI's, even if the BIOS itself is implemented as EFI.

tjmask15, if what you've said is true then I cannot trust that any register will be preserved in pretty much any BIOS call. This includes important registers such as the stack pointer...

elderK wrote:tjmask15, if what you've said is true then I cannot trust that any register will be preserved in pretty much any BIOS call. This includes important registers such as the stack pointer...

tjmonk15*

But, yes pretty much. The easiest solution is to use as few registers as possible while you still need to call the BIOS. Then switch to pmode (or long mode) ASAP so you don't have to worry about a horribly buggy BIOS.

- Monk

P.S. In reality, the BIOS SHOULD be saving any register that is not an output, and you can rely on this in DEBUG/TEST code. In Production code, you have to assume worst case

tjmonk15 wrote:But, yes pretty much. The easiest solution is to use as few registers as possible while you still need to call the BIOS. Then switch to pmode (or long mode) ASAP so you don't have to worry about a horribly buggy BIOS.

P.S. In reality, the BIOS SHOULD be saving any register that is not an output, and you can rely on this in DEBUG/TEST code. In Production code, you have to assume worst case

Not quite so. BIOS does not exist in outer space or vacuum. There's quite a lot of software, mostly DOS itself, programs for DOS, DOS compilers and DOS programs compiled with these compilers, which de facto serve as test code for the BIOS. There must be vendor's BIOS test code in the first place, but it can't be the only BIOS test code. If a commonly used BIOS function is screwed up, many such programs will fail to operate and render this particular BIOS useless. If you didn't know, some PC manufacturers use DOS utilities to update the BIOS and those come on a bootable DOS floppy. The BIOS can't be screwed up too badly because there will be no way to update it.

alexfru wrote:

tjmonk15 wrote:...

Not quite so. BIOS does not exist in outer space or vacuum. There's quite a lot of software, mostly DOS itself, programs for DOS, DOS compilers and DOS programs compiled with these compilers, which de facto serve as test code for the BIOS. There must be vendor's BIOS test code in the first place, but it can't be the only BIOS test code. If a commonly used BIOS function is screwed up, many such programs will fail to operate and render this particular BIOS useless. If you didn't know, some PC manufacturers use DOS utilities to update the BIOS and those come on a bootable DOS floppy. The BIOS can't be screwed up too badly because there will be no way to update it.

How many modern BIOS versions do you think include any kind of tests for DOS compatibility? How about EFI hosted BIOS stubs?

- Monk

P.S. Not meant to be sarcastic or rude (hope it doesn't come across that way)

tjmonk15 wrote: How many modern BIOS versions do you think include any kind of tests for DOS compatibility?

They're testing it against something or what is the point of doing a BIOS fix?

The thing about the BIOS idea is that any OS can use it from the simplest boot loader to a 64 bit OS (with a nasty @$$ hack). Something like CDI, EDI and UDI requires an OS to already be an almost complete system which rules out all basic systems that want to test something higher than how to write a USB device driver.

What if something existed that was protected mode aware but as simple as BIOS to operate? Even if that meant running it in compatibility mode? Maybe there could be 2 entry points, 1 for 32 bit and 1 for 64 bit and the firmware handles the difficult part.

The advantage would be a GRUB multiboot kernel tutorial could say load this module before your kernel, and it will load your kernel and initrd and you can access the HDD, Framebuffer (not vesa) and USB!

Obviously it wouldn't apply to any advanced kernels, they already use CDI/EDI/UDI and share all their common drivers...

b.zaar wrote:

tjmonk15 wrote:...

They're testing it against something or what is the point of doing a BIOS fix?

I think you missed the point. Pretty much, you can not prove that all BIOS behave correctly, (and there is quite a bit of evidence that many do not behave "correctly") therefore you must (SHOULD) assume there will be problems. *rolls eyes*

For hobby projects, testing/debugging, etc. this is not an issue, just use what works with your machines. But if you are aiming at production code, you have to assume someone will install your OS with a bad BIOS.

Beyond that, modern BIOS are tested against Windows (XP+ probably) and MAYBE linux (doubtful). Just look at ACPI (and the almost 100% necessity to use ACPIA) to see how well this works out for OSs in general.

- Monk

tjmonk15 wrote: I think you missed the point.

Yeah I can do that...

tjmonk15 wrote:Beyond that, modern BIOS are tested against Windows (XP+ probably) and MAYBE linux (doubtful).

DOS is still in use, or this wouldn't exist.
http://www.freedos.org/wiki/index.php/M ... et_FreeDOS

b.zaar wrote:

tjmonk15 wrote: I think you missed the point.

Yeah I can do that...

tjmonk15 wrote:Beyond that, modern BIOS are tested against Windows (XP+ probably) and MAYBE linux (doubtful).

DOS is still in use, or this wouldn't exist.
http://www.freedos.org/wiki/index.php/M ... et_FreeDOS

As much as FreeDOS is like DOS it is not *truly* DOS. There are some differences, specifically at the code level (Not sure if FreeDOS is based off of the old open-source versions of DOS or from-scratch) And out of curiosity, does FreeDOS boot from the BIOS on your current PC? (I don't have a floppy drive to try this with :\)

- Monk

tjmonk15 wrote:And out of curiosity, does FreeDOS boot from the BIOS on your current PC? (I don't have a floppy drive to try this with :\)

I didn't read about booting from floppy in that link

Looks like they don't have a floppy boot download for their "current" version (looks like its from Feb. 2012) but they do have a CD Version which I will have to try out of curiosity. Link is http://www.freedos.org/download/ if you are curious.

- Monk

tjmonk15 wrote:they don't have a floppy boot download for their "current" version

That is why I do not like the whole project. What is the point of having a DOS system if it is not floppy-installable? I would try it on old hardware if it supported floppy installation.

You might need to dd to a floppy then install from a CD.

http://www.linfo.org/freedos_floppy.html