A long time ago, computers didn't have bootstrap ROM. One had a direct interface to modifying RAM, and could halt the CPU, change RAM, and then restart the CPU. So, when you restarted the system, you had to make sure the CPU was halted, enter your bootstrap code that would load a second stage bootloader (2bl) off of paper tape or whatnot, and then "unhalt" your CPU.
ROM saves the day here, obviously. When you power on an x86 CPU-based system, it begins executing at address FFFF:FFF0. That's a hardwired feature of the x86 CPU. ROM has to reside at that address, and indeed the very upper part of the BIOS does (usually starting at E000:0000).
The term BIOS is a holdover from the old CP/M operating system. The structure of CP/M was the ROM BIOS at the lowest layer, the BDOS (Basic Disk Operating System) in the middle, and the CCP (Console Command Processor) in front of the user. The BIOS had routines to perform low-level functions such as reading/writing a specific disk sector, reading a key from the keyboard, writing a character to the screen, etc. The BDOS would use BIOS functions to implement a file system, and the CCP would be the command shell using BDOS and BIOS functions. The idea was the BIOS would contain the hardware specific interface, and the BDOS and CCP could be the same on any CP/M system.
The BIOS would also hold the initial code executed by the processor, which initialize required hardware, display a splash screen, load the 2bl off the first sector off of the first disk drive and run it.
MS-DOS 1.0, pretty much being a x86 implementation of CP/M, with kludgy Unix-like features added on starting at version 2.0, was structured the same way. The IBM PC BIOS at that time also included enhancements such as video mode switching, graphics functions, and hard drive support in the original AT BIOS.
However, most DOS programs did not use BIOS functions once they started; they directly accessed hardware for performance reasons. This was especially important after 32-bit CPU's became commonplace; the BIOS only worked from the older 16-bit mode, so calling it from 32-bit mode incurred a further performance penalty.
Around the 1990 the PC architecture was beginning to be extended, and starting to include new stuff like APM, PnP, and PCI. So the BIOS was starting to take on additional functions and get bigger. PCs also were starting to use chipsets instead of discrete components. Initializing the chipset is something that needs to happen to get RAM and other components such as the PCI bus usable, so that has to be handled by the BIOS bootstrap code. For some reason many chipset vendors do not like to document how their setup processes work.
APM was handled by BIOS functions; i.e. to power the system off the operating system had to call an APM function. ACPI, APM's successor, is the big thing BIOSes do today. The ACPI BIOS is responsible for creating a bunch of tables in memory that describes many non-plug and play hardware components. A booting operating system uses this to determine how many CPUs there are, how many RAM slots the system has, whether the system is a desktop or laptop, how many batteries are installed, etc. The ACPI BIOS also must be called to power off the system, or place it into sleep, etc. There's no reason that operating system code couldn't handle ACPI calls, though.
Most of the time BIOS updates are to fix ACPI errors, since ACPI is complicated and difficult, or to introduce enhanced microcode. All modern CPU's allow microcode updates, and if a new microcode update is released the BIOS must then be updated to install that new microcode. It's possible for a normal program to update a CPU's microcode.
SMI's are also handled by the BIOS. I'm pretty sure most of the thermal and power related hardware in a PC triggers SMI's, whose routines then adjust fan/CPU speed and/or other things. Other things can trigger SMI's; check out the Wikipedia article on System Management Mode. But there's also no reason that this code couldn't be replaced with operating system code if hardware interfaces were documented.
Modern operating systems do not use the BIOS at all for hardware access, except for power events. Some bootloaders do use the BIOS character I/O to display text and disk I/O load the OS boot code.
So I hope this sheds some light on the BIOS's role, and for the most part you are absolutely right about how it works.
Thanks, but, if BIOS is there to supply some standardised interface for OS, why not to design HW to have the same level of interface? For example Intel and AMD, both have different chipsets, both both could offer same functionality on HW level. You know, to provide same interface. And, am I right when I say BIOS cant do anything OS yould do? You know, BIOS is just a SW which loads to RAM from external storage? – user32569 – 2010-11-06T00:33:27.607
"..why not to design HW to have the same level of interface?" That would be an ideal situation but it just doesn't happen like that - chip manufacturers are always producing different designs that have different signal and timing requirements, or integrating multiple I/O functionality into single blocks of silicon that need coaxing to work with a few additional calls and twists and it's up to the system board designers and BIOS developers to always ensure that function X of INT Y always delivers what's expected. (cont..) – Linker3000 – 2010-11-06T09:19:08.443
...There would be nothing worse for a software company to discover that, say, Acer's new laptop has used a different brand of USB chipset and your app doesn't know how to drive it so your data logging software won't work on that platform because your direct USB calls somehow lock up the hardware. I appreciate where you are coming from with your original question but IBM set the standard of apps and the OS interfacing with the hardware using s/w drivers and BIOS calls and that part of the overall 'IBM PC' spec has been with us pretty much ever since. – Linker3000 – 2010-11-06T09:19:42.437
...The final issue is one of convenience: imagine a software company having to sit down with every piece of hardware to ensure their apps have drivers that supported it all and then writing some code that says..Case (USB_CHIPSET) when Intel01 load DRV_Intel01 when Intel02 load DRV_Intel02 when SIS01 load... and then have the next routines that do the same for all other IO devices - your app is going to take a lot of time to fire up! Admittedly, this kind of thing does happen, but using BIOS calls takes away a lot of the need to do this – Linker3000 – 2010-11-06T09:25:24.830