OSDev.org

Posted: **Mon Apr 06, 2009 5:19 am**

Hello everyone,
I am looking for more information about how to access BIOS features from protected and long modes (especially 64-bit mode). I know that there would be maybe three different solutions: switch to real mode, switch to virtual mode and comunication with hardware manually via ports. But there are so many "ifs", like virtual mode is not available in long mode, I think there is no way (easy way) to switch back to long mode and etc. The question is what is the best way to communicate with hardware? I do not much time to write drivers for each devices and I would need some kind of ports and communications protocols that I find hard to locate. All ideas, references are welcomed.

Posted: **Mon Apr 06, 2009 5:50 am**

Hi,

There is no easy solution. If you wish to be in long mode, you'll have to write your own drivers. Using the BIOS is extremely slow and unweildy, and it comes with the problems you mentioned.

If you don't want to put effort/time in, perhaps this isn't the project for you?

Cheers,

James

Posted: **Mon Apr 06, 2009 6:00 am**

I agree with JamesM.

If you want to fully utilize the BIOS for hardware interfacing, I'd just stick to either Real-Mode and take the traditional 16-bit route, or use P-Mode and use virtual or un-real mode for BIOS work.

Keep in mind though, every time you need to switch back and forth between modes, you will take a performance penalty. Also, as JamesM stated, using the BIOS as a driver interface backend will be very slow.

I'd just write some well-documented hardware drivers for common devices and/or make some sort of driver interface that would allow for easy porting of open-source drivers.

Posted: **Mon Apr 06, 2009 6:08 am**

Hi,

I agree with both the above. Just as another suggestion, though, you could always look at virtualisation for running BIOS code. A couple of caveats: firstly, this will be complex, secondly it will still be slower than native drivers, but you could always use it as a fallback.

Cheers,
Adam

Posted: **Mon Apr 06, 2009 10:23 am**

Hi,

IMHO the BIOS functions have 2 problems. The first problem is that BIOS code is designed for real mode, but there's ways to work around that. The second problem is that the BIOS code is designed for single tasking, and there's no way to work around that.

IMHO the general idea is to write an OS that's impressive enough to encourage other programmers to help, and for these other programmers to write most of the device drivers. In this case you only need to write enough device drivers to make it "impressive enough". If the OS has very bad performance (e.g. because the BIOS is wasting an entire CPU just waiting for data to be transfered to/from disk) would it be impressive? What if the OS has very good performance (for ATA/SATA/ATAPI) but doesn't support SCSI yet? How long would it take to get the BIOS functions working, how long would it take to write a few decent drivers, and where is your time better spent?

Now take a look at the hardware support the BIOS provides:

Keyboard: Usable, but no support for different keyboard mappings or any of the new multimedia keys, no support for "hot plug" keyboards, and you'd need to use polling to see if a key was pressed or not. It's easy to write a keyboard driver for PS/2 keyboards so you're not saving yourself much hassle by using the BIOS for keyboard anyway.
Serial ports: The serial port functions in the BIOS are a huge joke - nobody ever uses these functions (even people writing real mode/DOS code) because they suck so much.
Floppy: The BIOS code could be used here, but the BIOS will consume an entire CPU while it waits for data to be transfered to/from the floppy, which can cause unresponsive or sluggish user interface (e.g. user presses a key and the OS ignores the user for a while because it's busy waiting for the BIOS). It's easy enough to write a floppy disk driver for standard (non-USB) floppy drives that uses DMA, so that it doesn't cost you CPU time to transfer data to/from the floppy.
ATA/SATA/ATAPI: The BIOS code could be used here too, but it has the same performance problems as the floppy. Writing code to handle the ATA/SATA/ATAPI hard disks and CD-ROM isn't as easy; but hard drive performance makes a major difference to the overall performance of a computer - it's important to get it right.
SCSI: Some computers have SCSI disk drives, and SCSI controllers are much less standardized than ATA/SATA/ATAPI. Using the BIOS for SCSI disk support might seem like a good idea (despite the performance problems) because without the BIOS you'd need to write a driver for each SCSI controller. However, SCSI is also rare (mostly older servers), and I doubt it'll matter if your OS supports SCSI or not anyway.
Video: This is the main reason for using the BIOS. The only thing the BIOS functions do properly here is set video modes and bank switching (the "character output" and "plot pixel" functions aren't worth bothering with). If you set a video mode during boot then you won't need to use the BIOS (for video) from protected mode or long mode, but people won't be impressed. If you use the BIOS to change video modes while the OS is running, then it won't make any difference - people still won't be impressed. Let's be honest here - most people won't be impressed with the video support regardless of what you do (unless your OS is using the GPU to do full 3D with special effects in high resolution).
Ethernet, parallel ports, mouse, touch screens, sound cards, joysticks: The BIOS doesn't support any of these things (except if you're booting from network, but you can't boot from disk and then use the BIOS network code). The BIOS can use the PC speaker to beep at you, but that's only about 8 lines of code.

Cheers,

Brendan

Posted: **Mon Apr 06, 2009 12:15 pm**

I would add that if your making a multitasking OS forget the BIOS and just code for common hardware, but if your OS is single-tasking, then there are big advantages to having Bios driver (as in going back and forth), as i have both pmode and bios drivers in my OS.
The slowness depends on what driver your talking about, i defy anyone to have a faster floppy driver, as i have tested it compard to windows and linux and its faster.
The pmode drivers were coder first, than i added the BIOS drivers, with the BIOS driver you can do things like read/write to USB fobs, usb floppy, usb hdd, usb card readers, read the full fdd image from a CD under floppy emulation, i must addmit in usb case its not fast, but it is not much slower than boot any OS using usb and hdd/fdd emulation.

Your can test my OS to see for yourself
Type at the CLI
pmode <enter>
users the pmode drivers for fdd or hdd, and for bios drivers
bios <enter>

Posted: **Mon Apr 06, 2009 7:11 pm**

Dex wrote:The slowness depends on what driver your talking about, i defy anyone to have a faster floppy driver, as i have tested it compard to windows and linux and its faster.

Wait, your driver is fastest or the BIOS driver is or windows and linux is fastest? that really made no sense.. and if your saying your driver is fastest, it's probably due to PIO mode(which isn't supported on all drives)

Posted: **Mon Apr 06, 2009 7:16 pm**

earlz wrote:
Dex wrote:The slowness depends on what driver your talking about, i defy anyone to have a faster floppy driver, as i have tested it compard to windows and linux and its faster.
Wait, your driver is fastest or the BIOS driver is or windows and linux is fastest? that really made no sense.. and if your saying your driver is fastest, it's probably due to PIO mode(which isn't supported on all drives)

He's saying that the BIOS driver is faster, which isn't a fair test as the BIOS driver does not allow for work to be done while waiting (polling) for the drive, whereas the linux/windows ones do.

James

Posted: **Tue Apr 07, 2009 1:14 pm**

JamesM is right, i am saying if you time a full floppy copy in linux or window, and do the same using bios, from my test bios is faster.
If you write your own pmode driver, as per the intel spec, with the required delays etc, it is slower than using the bios.
How this can be so i do not know, but it is.
As for the multitasking part, then why is the pmode ver (run in a single-tasking OS) slower with the rrequired delays, if you use less delays, it does not work.
It really makes me laugh when i use multitasking OS and because you are mounting the floppy the sys is so slow its unusable, so your still waiting around

.

Posted: **Tue Apr 07, 2009 5:05 pm**

Dex wrote:JamesM is right, i am saying if you time a full floppy copy in linux or window, and do the same using bios, from my test bios is faster.
If you write your own pmode driver, as per the intel spec, with the required delays etc, it is slower than using the bios.
How this can be so i do not know, but it is.
As for the multitasking part, then why is the pmode ver (run in a single-tasking OS) slower with the rrequired delays, if you use less delays, it does not work.
It really makes me laugh when i use multitasking OS and because you are mounting the floppy the sys is so slow its unusable, so your still waiting around .

In any operating system - single or multi tasking, waiting on the floppy drive is always going to render the system seemingly unresponsive (because of the long latency for disk accesses). The difference being that in a multitasking OS the network stack can continue to run in the background, the mouse can continue to move, your music can continue to play...

And on the whole of things, why does it matter that the BIOS single-tasking method can do a read in one million milliseconds and a multitasking pmode driver can do it in one million and one milliseconds? the difference is so little as to be negligible.

Cheers,

James

Posted: **Tue Apr 07, 2009 11:26 pm**

Hi,

Dex wrote:If you write your own pmode driver, as per the intel spec, with the required delays etc, it is slower than using the bios.

For transferring data to/from floppy disks there's a difference between PIO and DMA, and PIO is "faster". I'd assume you're comparing a BIOS that uses PIO to a protected mode device driver that uses DMA. If you compared the BIOS to a protected mode device driver that uses PIO then the protected mode device driver should be a tiny little bit faster than the BIOS because there's a little less overhead (you don't need to switch to/from real mode and don't need to copy data to/from a buffer below 1 MiB).

You also think that a single-tasking OS can't do more than one thing at a time and that it doesn't matter if the CPU's time is consumed during transfers to/from floppy. However, nothing prevents a single-tasking OS from supporting asynchronous I/O. For a single tasking OS that supports asynchronous I/O, the CPU can be doing useful work while any devices that use DMA or bus-mastering are also being used (floppy, hard disks, CD-ROM, video, network, sound cards, parallel port, etc). In this case "faster" PIO for floppy disks may mean slower performance in practice. For example, imagine a single task that downloads a compressed file from the internet, stores the compressed file on the hard drive, decompresses the file and stores the decompressed file on a floppy; where the single task does all of this at the same time using asynchronous I/O.

Cheers,

Brendan

Posted: **Wed Apr 08, 2009 1:11 pm**

Brendan you are right, my pmode driver does use DMA, and i agree with you about single-tasking OS's, they should still beable to do other task, if its feasible.

Posted: **Wed Apr 15, 2009 10:52 am**

Hello everyone again and thanks for the help. I must agree with you and decided that I would not be using BIOS. But I need more information that I could implement basic operating to work with computer. I am running my sandbox OS in QEMU. There is a 3 main features:
- Keyboard
- Monitor
- HardDrive (DMA controller?)
(Any other? Free to mention).

I need more information that I could start implementing drivers. I need list of ports, communication protocols, etc. Could I find this kind of information?

I am writing very small operating system that only shows multitastking capabilities.

Posted: **Wed Apr 15, 2009 11:04 am**

The Wiki has almost everything you need this has everything else.

Posted: **Thu Apr 16, 2009 6:56 am**

Hi,

davidlt wrote:I am writing very small operating system that only shows multitastking capabilities.

In this case, it's probably best to (for e.g.) use GRUB to load everything into RAM, write a simple video driver (that uses the default 80*25 text mode via. 0x000B8000), write a keyboard driver, and nothing else.

Note: GRUB will load more than one thing for you. Here's an example ("grub/menu.lst" from one of my test floppies images):

Code: Select all

hiddenmenu
timeout 0

title BCOS
root (fd0)
kernel /boot/bootgrub.bin
module /boot/default.frl
module /boot/commonpc.bin
module /boot/default.bsc
module /boot/install.sbi

This means that using GRUB, you could load a second (/third/next?) stage and/or a kernel, and/or several applications.

To do things properly (if it's not just to demonstrate multitasking capabilities), start with a recursive scan of the PCI bus (while disabling everything you can), then probe for any ISA hardware (e.g. floppy controller, PS/2 controller), then go back to PCI and enable everything again (while assigning resources - I/O port ranges, etc); then, for each USB controller found detect all devices connected to each USB port (not forgetting hubs), and for each PS/2 port and FDC channel detect if any devices are present (and what type). After you've done all of this, you'll know if a keyboard or floppy drive is present (and if they're legacy devices or USB devices, etc)...

Cheers,

Brendan

OSDev.org

BIOS - protected, long modes

BIOS - protected, long modes

Re: BIOS - protected, long modes

Re: BIOS - protected, long modes

Re: BIOS - protected, long modes

Re: BIOS - protected, long modes

Re: BIOS - protected, long modes

Re: BIOS - protected, long modes

Re: BIOS - protected, long modes

Re: BIOS - protected, long modes

Re: BIOS - protected, long modes

Re: BIOS - protected, long modes

Re: BIOS - protected, long modes

Re: BIOS - protected, long modes

Re: BIOS - protected, long modes

Re: BIOS - protected, long modes