OSDev.org

Hi,
Can one safely assume the availability of int 0x13 extensions in almost all the bios(Real Hardware) nowadays.

Hi,

HardCoder wrote:Can one safely assume the availability of int 0x13 extensions in almost all the bios(Real Hardware) nowadays.

How do you define "nowadays"?

If it includes computers that people still own (that still work), I've got an 80486 (from about 1990) that still doesn't support int 0x13 extensions.

If it only includes computers people buy in 2011, then almost all do/will support int 0x13 extensions (except for emulated or real floppy disks - BIOS manufacturers seem to not bother for floppy).

If it includes computers people will buy further in the future, then I'm predicting a major shift to UEFI when Windows 8 is released, and for the slow death march of the PC BIOS to reach it's eventual conclusion in the next 5 years or so.

Basically, I'd say "int 0x13 extensions" is limited to the computers from about 1995 to 2015 - anything earlier or later, and you're likely to have trouble.

Now... sometimes I like to make wild guesses about what people are thinking. My guess is that you're writing boot code and only want to do one "int 0x13" boot loader. In that case be prepared to make about 8 different boot loaders - some for different devices, some for different partitioning schemes, some for different types of firmware, etc.


Cheers,

Brendan

Brendan wrote:Now... sometimes I like to make wild guesses about what people are thinking. My guess is that you're writing boot code and only want to do one "int 0x13" boot loader. In that case be prepared to make about 8 different boot loaders - some for different devices, some for different partitioning schemes, some for different types of firmware, etc.

I wrote a reasonably good bootloader that can boot from fat32 formated USB sticks (or Hard Disk but I havent tested) that loads by way of int 13 extensions. It will search for a file named SECBOOT (second stage bootloader) and KERNEL and will load it. As the common Boot device of today is either a usb stick or a hard drive I assumed that I will just stick with int13 extensions. All I must have to do then is to boot the USB in HDD emulation. Since it is either USB or HDD with fat32, the count of bootloaders needed is reduced to 2 not counting all those old things. I managed to boot my kernel with this bootloader successfully in 3 real hardware and in the fourth it failed even though it had a chipset with core2duo processor. So I just wanted to check whether it was the int13 extensions not supported in that BIOS. Although the symptoms had me wondering because I made it to boot from usb stick and it waited for 2 seconds and then transferred control to the hard disk in that system as if my bootloader was not loaded by the bios.

Is there any such bios which boots from a device which then executes int 13, Bios then detecting that it is not supported boots from another device. If not then I cannot think of any other reason since it boots from a USB stick with ubuntu.

berkus wrote:What's the point of loading both SECBOOT and KERNEL? If you can load KERNEL, just load it up and go?

The bootloader doesnt have enough space to load every cluster of SECBOOT. so the SECBOOT is actually limited to a CLUSTER unlike KERNEL.
The bootloader just loads SECBOOT which is ORGed to 0x8000. It is the SECBOOT which loads KERNEL. KERNEL is ORGed to 0xC0000000. When it enters SECBOOT it is still in real mode because I intent this to be released to the forum members especially to people like romfox who are struggling to get their kernel to be booted from USB's so they can still be in real-mode unlike GRUB and have a decent FAT32 formated USB stick to boot their kernel.

Brendan wrote:How do you define "nowadays"?

@brendan
I define "nowadays" as the PC/BIOS that majority of the people use for their usual things at their home or at office i.e excluding their usage of systems for experimental tests on older hardware.

HardCoder wrote:Hi,
Can one safely assume the availability of int 0x13 extensions in almost all the bios(Real Hardware) nowadays.

The answer depends on your target audience.
While the chance of unsupported computer is small, if it even occur, will you:
1. Rule out a few exceptions and say, "sorry we don't support your computer, and we can sell you a new machine"?
2. Provide a backup solution (eg. a compatible boot loader)?

IMO, It's more of an operation decision than technical decision.

bluemoon wrote:The answer depends on your target audience.
While the chance of unsupported computer is small, if it even occur, will you:
1. Rule out a few exceptions and say, "sorry we don't support your computer, and we can sell you a new machine"?
2. Provide a backup solution (eg. a compatible boot loader)?

Yes I agree that it is an operation decision. As for the choice I think I might opt for the second one. I will provide a compatible bootloader even though its development will not be any time soon but I guess before my release of DECODE v1.0. The current bootloader is still hooked to my OS at some parts. I will focus on making it general purpose once I finish some of the stuff with my OS.