Page 1 of 1

Should or Shouldn't i use BIOS routines in PMode

Posted: Sat Jan 29, 2005 12:00 am
by kan
hi,
i want my OS to be as Hardware Independent as possible. And for this
should i use BIOS routines for accessing Hardware(eg Floppy,HDD,Graphics Adapter)?? or is there any other technique for same?

According to what i know BIOS routines are 16bit so in Pmode i would have to use V86 mode to call these routines? Right? So would there be a performance hit in switching to V86mode everytime i have to access flpy,hdd or any other BIOS supported Hardware?

I want to avoid writting those very very low level routines(32bit) for accessing hardware devices (flpy,hdd etc) !

So what do u think , should i use BIOS function calls or write my own 32bit drivers to driving various controllers(flpy etc). But don't u think writing 32bit drivers will be very time consuming, and tooo much hardware dependent?????

Re: Should or Shouldn't i use BIOS routines in PMode

Posted: Sat Jan 29, 2005 12:00 am
by Legend
Will there be a performance? As the BIOS in real mode doesn't seem to be fast in all cases - yes!
Is it hardware dependant? Where there are no standards - unfortunately yes!
Will it be easier to implement? From what I have heard, implemeting V86 seems very hard to get right, so it might be just as much work (at least for the basic hardware)

Re: Should or Shouldn't i use BIOS routines in PMode

Posted: Sat Jan 29, 2005 12:00 am
by [AlAdDiN]
@kan : BIOS calls are too slow and will make your OS too dependent to x86 architechture, but if you want to use them i suggest you to use unreal mode instead of pmode

Re: Should or Shouldn't i use BIOS routines in PMode

Posted: Mon Mar 14, 2005 12:00 am
by frizzz
I just published my own assembler OS, which contains drivers for FD and IDE-ATA, written new from scratch using the datasheets of intel and ATA-, T13-commitees. The driver-code works very well an four machines from 1980-2004 (486,pentium.athlon,duron). Look at my homepage:
www.rcfriz.de
If You want to cooperate, contact me at
[email protected]