Bios
-
Does bios function like an operating system? It captures keyboard input, has the ability to display characters on screen, on my laptop it even displays animations. All this is done without using drivers. What does the battery on the motherboard do? Does it help keep the bios always loaded in memory or is the bios booted from permanent memory when you turn on the PC? Bios uses the processor to function hence it must be written in assembly, is that how it works?
-
Does bios function like an operating system? It captures keyboard input, has the ability to display characters on screen, on my laptop it even displays animations. All this is done without using drivers. What does the battery on the motherboard do? Does it help keep the bios always loaded in memory or is the bios booted from permanent memory when you turn on the PC? Bios uses the processor to function hence it must be written in assembly, is that how it works?
You can consider it a very simple OS, lacking a lot of the functions you expect today. Some primitive drivers are part of this "OS". These are mainly for getting the 'real' OS loaded into memory and give it control - often referred to as 'bootstrapping'. In principle, you could have the BIOS load your program rather than the real OS, but most likely, your program would request services that the BIOS doesn't provide. In the old days (DOS), applications relied on the drivers that are part of the BIOS to handle the few devices that the BIOS have drivers for, such as keyboard and character based output to a screen or printer. Executing driver code out of the BIOS ROM was slow. PCs started to copy the BIOS code to RAM at startup, to run it faster. Often, the BIOS code was limited and couldn't utilize all the functions of the peripheral, so OSes started providing their own code to replace the BIOS drivers. Today, the OS has its own drivers for 'everything', so those provided by the BIOS are used only for the bootstrapping process. Even though execution out of the BIOS ROM is slow, those drivers are used for such a brief time that it doesn't really matter much. I doubt that any modern motherboard would care to copy the BIOS drivers from ROM to RAM for speedup, the way they did in the old days. Note that in the old days, those drivers were used all the time; the OS didn't have a better replacement driver. So then it made much more sense to copy to RAM than it does today. When you boot up, the OS isn't there yet, so you need something to read the disk, floppy, USB stick or whatever medium you keep you OS on. If your OS is on a medium for which your BIOS doesn't have a driver (say, a tape cassette), you may be lost - unless your BIOS has a driver for, say, a floppy drive, and you can load the tape station driver from the floppy, and use that driver (loaded to RAM) to load the real OS from the tape. (This is not very common, though.) We had USB for years before we got BIOSes with drivers for the USB interface. During those years, you could not boot your OS from a USB stick the way you can today. Even before that, we had the same issue with CD/DVD drivers: The BIOS didn't have CD drivers, so the CD/DVD drive was useless until the OS had been loaded with its CD drivers. The mainboard battery: Flash is a more recent invention than the PC. In the old days, the data area used by the BIOS, holding e.g. the order in which to try the various boot devices, was held in what is called CMOS, an extremely
-
You can consider it a very simple OS, lacking a lot of the functions you expect today. Some primitive drivers are part of this "OS". These are mainly for getting the 'real' OS loaded into memory and give it control - often referred to as 'bootstrapping'. In principle, you could have the BIOS load your program rather than the real OS, but most likely, your program would request services that the BIOS doesn't provide. In the old days (DOS), applications relied on the drivers that are part of the BIOS to handle the few devices that the BIOS have drivers for, such as keyboard and character based output to a screen or printer. Executing driver code out of the BIOS ROM was slow. PCs started to copy the BIOS code to RAM at startup, to run it faster. Often, the BIOS code was limited and couldn't utilize all the functions of the peripheral, so OSes started providing their own code to replace the BIOS drivers. Today, the OS has its own drivers for 'everything', so those provided by the BIOS are used only for the bootstrapping process. Even though execution out of the BIOS ROM is slow, those drivers are used for such a brief time that it doesn't really matter much. I doubt that any modern motherboard would care to copy the BIOS drivers from ROM to RAM for speedup, the way they did in the old days. Note that in the old days, those drivers were used all the time; the OS didn't have a better replacement driver. So then it made much more sense to copy to RAM than it does today. When you boot up, the OS isn't there yet, so you need something to read the disk, floppy, USB stick or whatever medium you keep you OS on. If your OS is on a medium for which your BIOS doesn't have a driver (say, a tape cassette), you may be lost - unless your BIOS has a driver for, say, a floppy drive, and you can load the tape station driver from the floppy, and use that driver (loaded to RAM) to load the real OS from the tape. (This is not very common, though.) We had USB for years before we got BIOSes with drivers for the USB interface. During those years, you could not boot your OS from a USB stick the way you can today. Even before that, we had the same issue with CD/DVD drivers: The BIOS didn't have CD drivers, so the CD/DVD drive was useless until the OS had been loaded with its CD drivers. The mainboard battery: Flash is a more recent invention than the PC. In the old days, the data area used by the BIOS, holding e.g. the order in which to try the various boot devices, was held in what is called CMOS, an extremely
Thank you for taking the time to reply tronderen, that’s an interesting post.
-
You can consider it a very simple OS, lacking a lot of the functions you expect today. Some primitive drivers are part of this "OS". These are mainly for getting the 'real' OS loaded into memory and give it control - often referred to as 'bootstrapping'. In principle, you could have the BIOS load your program rather than the real OS, but most likely, your program would request services that the BIOS doesn't provide. In the old days (DOS), applications relied on the drivers that are part of the BIOS to handle the few devices that the BIOS have drivers for, such as keyboard and character based output to a screen or printer. Executing driver code out of the BIOS ROM was slow. PCs started to copy the BIOS code to RAM at startup, to run it faster. Often, the BIOS code was limited and couldn't utilize all the functions of the peripheral, so OSes started providing their own code to replace the BIOS drivers. Today, the OS has its own drivers for 'everything', so those provided by the BIOS are used only for the bootstrapping process. Even though execution out of the BIOS ROM is slow, those drivers are used for such a brief time that it doesn't really matter much. I doubt that any modern motherboard would care to copy the BIOS drivers from ROM to RAM for speedup, the way they did in the old days. Note that in the old days, those drivers were used all the time; the OS didn't have a better replacement driver. So then it made much more sense to copy to RAM than it does today. When you boot up, the OS isn't there yet, so you need something to read the disk, floppy, USB stick or whatever medium you keep you OS on. If your OS is on a medium for which your BIOS doesn't have a driver (say, a tape cassette), you may be lost - unless your BIOS has a driver for, say, a floppy drive, and you can load the tape station driver from the floppy, and use that driver (loaded to RAM) to load the real OS from the tape. (This is not very common, though.) We had USB for years before we got BIOSes with drivers for the USB interface. During those years, you could not boot your OS from a USB stick the way you can today. Even before that, we had the same issue with CD/DVD drivers: The BIOS didn't have CD drivers, so the CD/DVD drive was useless until the OS had been loaded with its CD drivers. The mainboard battery: Flash is a more recent invention than the PC. In the old days, the data area used by the BIOS, holding e.g. the order in which to try the various boot devices, was held in what is called CMOS, an extremely
Quote:
In the old days (DOS), applications relied on the drivers that are part of the BIOS
How did that function? I don't understand much about hardware or driver programming and I'm looking to broaden my horizons. Without a driver the CPU doesn't know the 'love language' of the equipment that sits in a slot. But only the equipment producer knows how to address the piece of hardware it has produced. Is there a universal language that works for all video cards, sound boards etc.? Back in the old days (and even today I think, I'm not sure I've only had laptops in recent years) a slot like PCI matched hardware from different categories how did that work?
-
Quote:
In the old days (DOS), applications relied on the drivers that are part of the BIOS
How did that function? I don't understand much about hardware or driver programming and I'm looking to broaden my horizons. Without a driver the CPU doesn't know the 'love language' of the equipment that sits in a slot. But only the equipment producer knows how to address the piece of hardware it has produced. Is there a universal language that works for all video cards, sound boards etc.? Back in the old days (and even today I think, I'm not sure I've only had laptops in recent years) a slot like PCI matched hardware from different categories how did that work?
Back in the DOS days, video cards sat at a certain address. The BIOS didn't need any special drivers. It just wrote directly to the addresses the video RAM was at. Back then, the bus and cards couldn't assign addresses, ports, DMA channels, and IRQs. You had to manually manage the separation of the hardware yourself. Then you told the drivers where the hardware sat in memory and/or how it was configured to listen on.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
-
Quote:
In the old days (DOS), applications relied on the drivers that are part of the BIOS
How did that function? I don't understand much about hardware or driver programming and I'm looking to broaden my horizons. Without a driver the CPU doesn't know the 'love language' of the equipment that sits in a slot. But only the equipment producer knows how to address the piece of hardware it has produced. Is there a universal language that works for all video cards, sound boards etc.? Back in the old days (and even today I think, I'm not sure I've only had laptops in recent years) a slot like PCI matched hardware from different categories how did that work?
Calin Negru wrote:
How did that function?
The BIOS is really nothing but a function library. In the DOS days, you could in principle call, say, the driver for outputting a character on the serial line by calling the function directly, by its BIOS address. Well, not quite - the return mechanism wouldn't match you call, but we are close. Rather than a direct function call, you used the interrupt system to call the driver function. You may think of physical interrupts, coming in on the INT or NMI (Non-Maskable Interrupt) line, as a hardware mechanism for calling a driver function when something, like an input, arrives from a device. Hardware will put the input value into a temporary register in the interface electronics (not a CPU register) and the driver function will move the value from that register into memory. Each interrupt source (device), or group of devices, provide an ID to the interrupt system so that a different function is called for each device (group), each knowing that specific device type and how to transfer the value from the interface electronics to the CPU. The interrupt system has a function address table with as many entries as there are possible interrupt IDs, so the ID is used to index the table. This table is commonly called an 'interrupt vector'. All computers have at least one extra location in the interrupt vector that is not selected by a hardware device ID, but your software can use a specific instruction to make a function call to the BIOS, OS, Supervisor, Monitor, ... Whatever you call it. Intel calls it an INT(errupt) instructions, on other machines it may be called an SVC (SuperVisory Call), MON(itor) call, or similar. On some machines, the instruction may indicate the interrupt number (i.e. the index to be used in the vector), so that different service functions have different interrupt numbers. Others have a single 'software interrupt' number and vector entry, with a single handler that reads the desired service number from a register. Many machines started with giving each service a separate ID, but the number of services outgrew the interrupt vector, so they had to switch to the second method. DOS is a mix: A number of services have their own interrupt ID, but the majority of BIOS driver functions use INT 21, with a service selector in the AH register. (Other DOS multipurpose software interrupts are 0x10 for video functions, INT 13 for low-level disk functions, INT 16 for keyboard functions and INT 17 for pri
-
Calin Negru wrote:
How did that function?
The BIOS is really nothing but a function library. In the DOS days, you could in principle call, say, the driver for outputting a character on the serial line by calling the function directly, by its BIOS address. Well, not quite - the return mechanism wouldn't match you call, but we are close. Rather than a direct function call, you used the interrupt system to call the driver function. You may think of physical interrupts, coming in on the INT or NMI (Non-Maskable Interrupt) line, as a hardware mechanism for calling a driver function when something, like an input, arrives from a device. Hardware will put the input value into a temporary register in the interface electronics (not a CPU register) and the driver function will move the value from that register into memory. Each interrupt source (device), or group of devices, provide an ID to the interrupt system so that a different function is called for each device (group), each knowing that specific device type and how to transfer the value from the interface electronics to the CPU. The interrupt system has a function address table with as many entries as there are possible interrupt IDs, so the ID is used to index the table. This table is commonly called an 'interrupt vector'. All computers have at least one extra location in the interrupt vector that is not selected by a hardware device ID, but your software can use a specific instruction to make a function call to the BIOS, OS, Supervisor, Monitor, ... Whatever you call it. Intel calls it an INT(errupt) instructions, on other machines it may be called an SVC (SuperVisory Call), MON(itor) call, or similar. On some machines, the instruction may indicate the interrupt number (i.e. the index to be used in the vector), so that different service functions have different interrupt numbers. Others have a single 'software interrupt' number and vector entry, with a single handler that reads the desired service number from a register. Many machines started with giving each service a separate ID, but the number of services outgrew the interrupt vector, so they had to switch to the second method. DOS is a mix: A number of services have their own interrupt ID, but the majority of BIOS driver functions use INT 21, with a service selector in the AH register. (Other DOS multipurpose software interrupts are 0x10 for video functions, INT 13 for low-level disk functions, INT 16 for keyboard functions and INT 17 for pri