Index
> Main > BIOS functions or not BIOS functions ?Goto page 1, 2 Next |
| Author |
|
|
f0dder 13 Jan 2007, 08:35
Modern operating systems for x86 generally only use the BIOS in the very early boot phase, after that native drivers take over.
And why code works on different BIOS vendor versions? Because there's a standard interface. |
|||
13 Jan 2007, 08:35 |
|
|
fafastrungen 13 Jan 2007, 09:05
Thanks for your answer, I understand now the process.
The standard interface is available for everybody, can I get it ? |
|||
|
13 Jan 2007, 09:05 |
|
|
f0dder 13 Jan 2007, 09:08
Search for Ralph Brown's interrupt list.
|
|||
|
13 Jan 2007, 09:08 |
|
|
fafastrungen 13 Jan 2007, 09:29
Yeah, I've already got it. I thought there is another updated thing becouse Ralph Brown's is not up to date.
Thanks very much for your help. |
|||
|
13 Jan 2007, 09:29 |
|
|
f0dder 14 Jan 2007, 01:33
I think it's relatively up to date - it's limited how much additional stuff has been added to DOS and BIOSes after real operating systems were introduced
 |
|||
|
14 Jan 2007, 01:33 |
|
|
DOS386 14 Jan 2007, 02:31
Quote: Hi everyone, the current OS's use the bios interrupts functions or not ? FreeDOS and Enhanced-DR-DOS do. The problem is that from a 32-bit OS BIOS is NOT accessible or with bad hacks only. Quote: I think it's relatively up to date - it's limited how much Wrong. The amount of "additional stuff" is low, but one could expect that Raplh would add it - but didn't 
The list IS obsolete
And, it seems that BIOS will get killed soon - or already got ? _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
|
14 Jan 2007, 02:31 |
|
|
f0dder 14 Jan 2007, 02:42
Quote:
About time, IMHO. The BIOS was appropriate back in the 8086 days, but has been pretty obsolete for a while. The attempt to introduce pmode BIOS failed miserably, the attempt to introduce a portable driver ABI failed, etc. For modern computers, (roughly speaking) all you really need is chipset initialization and the ability to load a boot image. The idea doing without drivers and having functionality in BIOS instead ends up with lowest-common-denominator code, or a horridly complicated specification. |
|||
|
14 Jan 2007, 02:42 |
|
|
zir_blazer 14 Jan 2007, 03:21
What about EFI? It looks pretty solid.
http://en.wikipedia.org/wiki/Extensible_Firmware_Interface |
|||
|
14 Jan 2007, 03:21 |
|
|
tom tobias 14 Jan 2007, 10:06
In my opinion, this very interesting topic belongs in the Operating System section of the forum, not Main.
zir_blazer wrote: What about EFI? It looks pretty solid. microsoft wrote:
microsoft wrote:
Hmm. sounds a bit like politics and religion (=$$$$) have interfered with engineering practice: microsoft wrote:
some more politics: microsoft wrote:
Who benefits from all this frenzied activity? |
|||
|
14 Jan 2007, 10:06 |
|
|
fafastrungen 14 Jan 2007, 11:57
I'm not interesting in politics and I don't fight against lost causes, the world is what it is.
I just wanted to know the importance of the bios in the current systems, so here a question, if Bios will die soon and EFI will die before it born, how the computers will start up ?. I'm making a simple program to practice and the code is this: Code: format MZ push cs pop ds ; Imprime la cadena de texto lea bx, [msg] mov cl, 14 call print_string ; Regresa al DOS mov ax,4C00h int 21h print_string: mov ah, 0Eh _start: mov al, byte [bx] cmp al, cl je _ret int 10h inc bx jmp _start _ret: ret msg db 'Hello World!', 14 so, is there any option to avoid the use of INT 10h ?, if this is possible no problem if the Bios will dissapear. |
|||
|
14 Jan 2007, 11:57 |
|
|
LocoDelAssembly 14 Jan 2007, 18:33
Yes, you can use INT 21h function 09h (dollar terminated strings), function 02h, 06h, or 40h instead.
The problem fafastrungen is what INTs the OS will call if them are not present anymore. The boot sequence of the OSes needs the services of the BIOS to be able to load it self, later can use its own drivers but that happens after a lot of previous help of the BIOS. |
|||
|
14 Jan 2007, 18:33 |
|
|
tantrikwizard 14 Jan 2007, 19:27
fafastrungen wrote: so, is there any option to avoid the use of INT 10h ?, if this is possible no problem if the Bios will dissapear. You can always write directly to video memory if the intention is print to the screen: Code: proc pstring .strptr mov si, [.strptr] mov ax, 0x0b800 mov es, ax xor di, di cld @@: lodsb or al, al jz @@ret stosb inc di jmp @b @@ret: ret endp You can still do all the other hardware related things without bios by programming the hardware directly, after all, this is all that bios does. BIOS is simply a standard interface for the multitude of different hardware which has hardware specific implementations. Grab the programming reference manual for any hardware you want to work with to figure out how to program it directly without bios. |
|||
|
14 Jan 2007, 19:27 |
|
|
fafastrungen 14 Jan 2007, 23:21
I understand a little more now about how computer works.
So in short, Bios is mandatory becouse system starts with it. I can avoid use it to comunicate with hardware but I have to program my own drivers for any hardware I want to comunicate. If I didn't understand wrong, I need to make my own routines to comunicate with hard drive, video card, sound card and so on, but here is another issue: we suppose I make my own driver to use the hard drive and the hard drive vendor is Maxtor, I suppose the driver only works 100% reliable with this vendor and if I want to use another hard drive vendor, I'd should check if it is fully compatible, am I right ? |
|||
|
14 Jan 2007, 23:21 |
|
|
DOS386 15 Jan 2007, 01:42
Quote: If I didn't understand wrong, I need to make my own routines to comunicate with hard drive, video card, sound card and so on, but here is another issue: we suppose I make my own driver to use the hard drive and the hard drive vendor is Maxtor, I suppose the driver only works 100% reliable with this vendor and if I want to use another hard drive vendor, I'd should check if it is fully compatible, am I right ? This is THE ISSUE. You need a HUGE amount of product-specific code and a HUGE amount of hardware to test ... or a HUGE amount of good testers 
About HD, I think the HD vendor should NOT be a problem, the problem is rather the controller type (IDE/SATA/SCSI) and its vendor  _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
|
15 Jan 2007, 01:42 |
|
|
tantrikwizard 15 Jan 2007, 01:46
fafastrungen wrote: I suppose the driver only works 100% reliable with this vendor and if I want to use another hard drive vendor, I'd should check if it is fully compatible, am I right ? Yes for the most part you are right. There are some programming standards such as VESA for example which is a video standard and any VESA compatible video card will work with your program if you code according to the VESA standard. However, some manufacturers include special features in their hardware which is non-standard. If you want to take advantiage of these non-standard features you will need to write non-standard code to take advantage of it. For example, there are several floppy disk controllers, newer hardware is normally backward-compatible with earlier hardware, yet newer hardware includes additional features not found in earlier hardware. To be safe, code should be written for the earliest possible hardware if you want your program to work on all systems. If you're not concerned about earlier systems then it is okay to have a minimum version/revision requirement and write code for newer hardware. |
|||
|
15 Jan 2007, 01:46 |
|
|
f0dder 15 Jan 2007, 01:53
The problem is you can't come up with a "one big standard" for bios/firmware/whatever - either it will be too clumsy and bulky (I think that's one of the reasons why the intel-backed driver ABI failed?), or it will be too limited
Consider if graphics cards had been limited to OpenGL1 or DX7... |
|||
|
15 Jan 2007, 01:53 |
|
|
DOS386 15 Jan 2007, 02:00
Quote: There are some programming standards such as VESA for example which is a video standard and any VESA compatible video card will work with your program if you code according to the VESA standard. However, some manufacturers include special features in their hardware which is non-standard This would NOT be that bad ... unlike all the BUGS they intrude into their existing VESA implementaion at that occasion ... _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
|
15 Jan 2007, 02:00 |
|
|
fafastrungen 15 Jan 2007, 11:14
I understand now why there's no stable OS in the market. There is too many differences between hardware and nobody try to unify.
And there is another big issue, the processors. If I make a program for example that use the AMD's CPUID instruccion, it won't work on intel's micro, unless intel's micro has this instruction. In one hand I think this is good, becouse stimulate improvment between vendors and low prices, but in the other hands is more complex to developments. Thanks everybody for your help. |
|||
|
15 Jan 2007, 11:14 |
|
|
tantrikwizard 15 Jan 2007, 14:43
Unless things have changed in the past few years, whatever IBM does is normally considered the standard. Last I checked only IBM could declare their PCs as 'IBM Compatible PC' Though IBM is not without their goofy engineering flaws e.g. A20 line and timer interrupt at 18.2 times/second
|
|||
|
15 Jan 2007, 14:43 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|