trashthing
11-28-2003, 10:22 PM
hi. i'm learning ASM and having alot of fun. do you have a tutorial on the BIOS calls for x86 ASM? i know they are not used any longer.
Click to See Complete Forum and Search --> : tutorial on BIOS calls in ASM
bwkaz
11-29-2003, 02:59 PM
Actually they are used, by the kernel. Without the BIOS, the kernel would not be able to do stuff like disk access, setting the video mode, and other I/O type stuff.
However, I'm pretty sure that normal users don't have permission to use the BIOS interrupts directly. If they did, then they could use the BIOS "write disk sector" interrupt function to cause all kinds of havoc. Root may not even have the required permissions; you might have to be running your code in kernel mode.
As for what interrupts do what, I've got a copy of a book named "IBM ROM BIOS" that details all the known interrupts (and the values that certain registers had to have when those interrupts got called) at the time, but it's pretty old. It wouldn't surprise me if the Int 0x13h (disk access interrupt) information was pretty out of date by now. It's also a print book, and I don't think it's available online (though it wouldn't hurt to look).
Maybe Ralf Brown's interrupt list?
However, I'm pretty sure that normal users don't have permission to use the BIOS interrupts directly. If they did, then they could use the BIOS "write disk sector" interrupt function to cause all kinds of havoc. Root may not even have the required permissions; you might have to be running your code in kernel mode.
As for what interrupts do what, I've got a copy of a book named "IBM ROM BIOS" that details all the known interrupts (and the values that certain registers had to have when those interrupts got called) at the time, but it's pretty old. It wouldn't surprise me if the Int 0x13h (disk access interrupt) information was pretty out of date by now. It's also a print book, and I don't think it's available online (though it wouldn't hurt to look).
Maybe Ralf Brown's interrupt list?
infidel
12-02-2003, 08:17 AM
Greetings,
Programming Tutorials (http://www.geocities.com/SiliconValley/Lab/1928/tutorials.html) ;
Paul Hsieh's x86 Assembly Page (http://www.azillionmonkeys.com/qed/asm.html) .
Actually they are used, by the kernel. Without the BIOS, the kernel would not be able to do stuff like disk access, setting the video mode, and other I/O type stuff.
Actually, this is not true. The Kernel does use some BIOS calls, mainly APM, ACPI stuff and to get info about the system at startup, but apart from that the Kernel talks directly to the hardware, hence the drivers for everything. Oh, and of course, while booting and still in Real Mode (16 bit).
Programming Tutorials (http://www.geocities.com/SiliconValley/Lab/1928/tutorials.html) ;
Paul Hsieh's x86 Assembly Page (http://www.azillionmonkeys.com/qed/asm.html) .
Actually they are used, by the kernel. Without the BIOS, the kernel would not be able to do stuff like disk access, setting the video mode, and other I/O type stuff.
Actually, this is not true. The Kernel does use some BIOS calls, mainly APM, ACPI stuff and to get info about the system at startup, but apart from that the Kernel talks directly to the hardware, hence the drivers for everything. Oh, and of course, while booting and still in Real Mode (16 bit).
bwkaz
12-02-2003, 10:59 PM
And everything in drivers/video/vesafb.c. Which is used just about all the time while the kernel's running...
X's vesa driver uses the same video BIOS calls.
Most other devices, yeah, it talks to them directly. After checking through drivers/ide, I see that most of them use the PCI bus functions (which are merely writes to memory-mapped PCI registers) to do their work, not BIOS interrupts as I originally thought. Oops. ;)
X's vesa driver uses the same video BIOS calls.
Most other devices, yeah, it talks to them directly. After checking through drivers/ide, I see that most of them use the PCI bus functions (which are merely writes to memory-mapped PCI registers) to do their work, not BIOS interrupts as I originally thought. Oops. ;)
infidel
12-03-2003, 07:01 AM
And everything in drivers/video/vesafb.c. Which is used just about all the time while the kernel's running...
X's vesa driver uses the same video BIOS calls.
Yeah, I had forgotten about the VESA thing. But is it still widely used? Even so, with VESA BIOS >= 2.0 (and if the card supports linear framebuffer) only one call to set the video mode (actually there more than one just for that), another one to get a pointer to the linear frame buffer and you're set, no more stinkin' BIOS calls. :)
Now, if the card does not support linear framebuffers, the VESA BIOS >= 2.0 provides a bank switching mechanism wich can be used in Protected Mode (32 Bit) environments, so although the Kernel is forced to use the BIOS, its not as costly as switching the CPU to Real Mode (16 Bit - where the BIOS code runs), make the BIOS call and switch the CPU back to PM (Kernel), wich is what the problem with BIOS calls is, in terms of performance.
This info is mainly from memory (mine :)) so it may be a bit off, it's been a long time since I did any VESA programming, back in the DOS days.
And since this is clearly getting way off topic I'll just shut up! :D
X's vesa driver uses the same video BIOS calls.
Yeah, I had forgotten about the VESA thing. But is it still widely used? Even so, with VESA BIOS >= 2.0 (and if the card supports linear framebuffer) only one call to set the video mode (actually there more than one just for that), another one to get a pointer to the linear frame buffer and you're set, no more stinkin' BIOS calls. :)
Now, if the card does not support linear framebuffers, the VESA BIOS >= 2.0 provides a bank switching mechanism wich can be used in Protected Mode (32 Bit) environments, so although the Kernel is forced to use the BIOS, its not as costly as switching the CPU to Real Mode (16 Bit - where the BIOS code runs), make the BIOS call and switch the CPU back to PM (Kernel), wich is what the problem with BIOS calls is, in terms of performance.
This info is mainly from memory (mine :)) so it may be a bit off, it's been a long time since I did any VESA programming, back in the DOS days.
And since this is clearly getting way off topic I'll just shut up! :D
bwkaz
12-03-2003, 08:04 PM
Originally posted by infidel
But is it still widely used? It's used on any system with an nVidia card that wants a high-res console plus 3D drivers in X. The "nvidia" X driver is incompatible with the "rivafb" console driver.
only one call to set the video mode, another one to get a pointer to the linear frame buffer and you're set, no more stinkin' BIOS calls. Except for stuff like scrolling the screen and setting the palette entries (when there is a palette); for those it uses the protected-mode interface function pointer returned when initializing the VBE.
And since this is clearly getting way off topic I'll just shut up! :D We probably had better both do that... :D
But is it still widely used? It's used on any system with an nVidia card that wants a high-res console plus 3D drivers in X. The "nvidia" X driver is incompatible with the "rivafb" console driver.
only one call to set the video mode, another one to get a pointer to the linear frame buffer and you're set, no more stinkin' BIOS calls. Except for stuff like scrolling the screen and setting the palette entries (when there is a palette); for those it uses the protected-mode interface function pointer returned when initializing the VBE.
And since this is clearly getting way off topic I'll just shut up! :D We probably had better both do that... :D
justlinux.com
Copyright Internet.com Inc. All Rights Reserved.
Copyright Internet.com Inc. All Rights Reserved.