Matrox & Asus Being Jerks! P4C800-E Dlx + P650/P750 Fails During Boot!

Normally BIOS code by definition IS in host CPU code. Such code is NOT
CPU
independent and therefore most PCI or ISA bus PC cards are NOT CPU
independent! They are x86 CPU dependent.

Ron, the cards are connected to the motherboard using a bus such as ISA,
EIDE, VESA, PCI, PCI-X, AGP.. the host system processor does send commands
to the card using either input/output ports or memory mapping, where writes
to specific address are sent to the card through the bus.

If the host processor wants to execute code from the BIOS, it can do this,
but the results are in CPU local registers and address space. If the CPU
wants something to happen, it must again write back to the memory mapped
region or use output ports.

The device must be able to respond to the command stream from the host
system and do whatever it is this device is supposed to be doing. The host
processor can only send command stream to the device. This code is very
rarely x86 specific in any way or form, it is more often hardware specific
values which change the hardware state.

You seriously don't try to make anyone belive that most PC add-on boards
have x86 compatible processor on them!? If not, what precisely is the factor
that you feel that does make them (all?) x86 CPU dependent? Please come
again, this is going to be very interesting.

Ummm. let's bring some facts to the discission, Ron claims to have written
BIOS'es but fails to materialize the easy-to-understand explanation anyone
who had, would be able to provide.

You see, Ron, things that you know about are trivialized.. you don't need to
act high and mighty to be able to explain what is the essense of things.

Let's talk about IBM PC compatible BIOS.

The interface to this BIOS is mostly interrupt 0x21, which is used to call
code which resides in the read-only ROM memory in the so-called BIOS. This
code is executed on x86 compatible processor by the x86 compatible
processor, which is not a very hard thing to grasp.. what the BIOS contains,
is x86 compatible binary code, obviously.

This code is instructions to the motherboard and other components the BIOS
supports (such as IDE, SATA, etc. controllers, whatever the MB supports that
is within the scope of the IBM PC compatible BIOS...), this allows the
common feature set to be commanded through standard interface.

This was more relevant years ago, novadays Operating Systems such as
Windows, Linux and others do most of the tasks with device drivers
'natively'-- so the BIOS could be a lot simpler novadays, just pass the
control to the OS bootstrap and let it do the rest. This is much more
efficient, because BIOS is implemented using Real Mode and modern x86 OS
runs in Protected Mode.

Calls to the BIOS have to be done using API such as DPMI, which is not very
efficient. It is far more efficient to do the I/O directly from the
Protected Mode. Ofcourse different OS take different approach, Windows just
allows drivers to write into memory where they want with full privileges
which sometimes causes some instability with poorly written drivers. ;-) ;-)

I'm assuming the reader knows what Protection Level and Ring 0 means so I
won't insult anyone with excess babbling about how the privilege levels
work.

Interesting that adults find it more productive to argue who's right and
who's wrong without any mentioning how the BIOS on IBM PC compatibles is
supposed to be working.

Disclaimer: I might have made error or two, tough ****, because haven't done
any "BIOS" level programming for 10 years or so, Windows, BeOS, Linux, BSD
and others kind of made it a Solved Problem. IBM PC compatible BIOS is not
very interesting technically, never were, IMHO.

It was the MS-DOS programmers who had to deal with the BIOS most. Those
times are long past. Maybe someone somewhere is writing this embedded system
controller/application/widget, who knows.. good for you whoever you may be!

FWIW, IBM PC compatible BIOS for a motherboard is example of device which
*does* have a x86 compatible CPU very often. Stating that all add-on boards
do, is naive- why would they need to store driver code in ROM when it can be
loaded off the hard-drive by the OS and thereby even upgraded without
flashing? ;-)

As far as I know of, most cards do have a Windows drivers for instance which
are NOT loaded off ROM. ;-)

As far as I know of, most cards do have a Windows drivers for instance
which
are NOT loaded off ROM. ;-)

... except the VGA/VBE bios which is used through interrupt 0x10 .. which is
required feature only on IBM PC compatible systems.. if you drop such PCI
card to another architechture, you can still command it through the bus..
just more code to write, on the other hand the VBE BIOS is not very commonly
used anymore except for booting, maybe by the motherboard BIOS (int 0x21)
and some archaic "SVGA generic" drivers in Linux and MS-DOS, if you happen
to boot it for some bizarre reason.

Some text-mode tools also propably find it more convenient to use int 0x10
rather than write driver for all possible gfx card.. but again.. this is
just IBM PC compatible proprietary feature for cards which are supposed to
work on one.

But I don't see any technical reason why you couldn't use virtually any PCI
card meant for "IBM PC" in any system which has PCI bus, as long as you have
the software for the feat. Ron seemingly does, what a strange fellow!

"Rapu Rapala" wrote in message
...
Normally BIOS code by definition IS in host CPU code. Such code is NOT
CPU
independent and therefore most PCI or ISA bus PC cards are NOT CPU
independent! They are x86 CPU dependent.

Ron, the cards are connected to the motherboard using a bus such as ISA,
EIDE, VESA, PCI, PCI-X, AGP.. the host system processor does send
commands
to the card using either input/output ports or memory mapping, where
writes
to specific address are sent to the card through the bus.

If the host processor wants to execute code from the BIOS, it can do this,
but the results are in CPU local registers and address space. If the CPU
wants something to happen, it must again write back to the memory mapped
region or use output ports.

The device must be able to respond to the command stream from the host
system and do whatever it is this device is supposed to be doing. The host
processor can only send command stream to the device. This code is very
rarely x86 specific in any way or form, it is more often hardware specific
values which change the hardware state.

You seriously don't try to make anyone belive that most PC add-on boards
have x86 compatible processor on them!? If not, what precisely is the
factor
that you feel that does make them (all?) x86 CPU dependent? Please come
again, this is going to be very interesting.

HUH, reread the thread.

"Rapu Rapala" wrote in message
...
Ummm. let's bring some facts to the discission, Ron claims to have written
BIOS'es but fails to materialize the easy-to-understand explanation anyone
who had, would be able to provide.

You see, Ron, things that you know about are trivialized.. you don't need
to
act high and mighty to be able to explain what is the essense of things.

Let's talk about IBM PC compatible BIOS.

The interface to this BIOS is mostly interrupt 0x21, which is used to call
code which resides in the read-only ROM memory in the so-called BIOS. This
code is executed on x86 compatible processor by the x86 compatible
processor, which is not a very hard thing to grasp.. what the BIOS
contains,
is x86 compatible binary code, obviously.

This code is instructions to the motherboard and other components the BIOS
supports (such as IDE, SATA, etc. controllers, whatever the MB supports
that
is within the scope of the IBM PC compatible BIOS...), this allows the
common feature set to be commanded through standard interface.

This was more relevant years ago, novadays Operating Systems such as
Windows, Linux and others do most of the tasks with device drivers
'natively'-- so the BIOS could be a lot simpler novadays, just pass the
control to the OS bootstrap and let it do the rest. This is much more
efficient, because BIOS is implemented using Real Mode and modern x86 OS
runs in Protected Mode.

Calls to the BIOS have to be done using API such as DPMI, which is not
very
efficient. It is far more efficient to do the I/O directly from the
Protected Mode. Ofcourse different OS take different approach, Windows
just
allows drivers to write into memory where they want with full privileges
which sometimes causes some instability with poorly written drivers. ;-)
;-)

I'm assuming the reader knows what Protection Level and Ring 0 means so I
won't insult anyone with excess babbling about how the privilege levels
work.

Interesting that adults find it more productive to argue who's right and
who's wrong without any mentioning how the BIOS on IBM PC compatibles is
supposed to be working.

Disclaimer: I might have made error or two, tough ****, because haven't
done
any "BIOS" level programming for 10 years or so, Windows, BeOS, Linux, BSD
and others kind of made it a Solved Problem. IBM PC compatible BIOS is not
very interesting technically, never were, IMHO.

It was the MS-DOS programmers who had to deal with the BIOS most. Those
times are long past. Maybe someone somewhere is writing this embedded
system
controller/application/widget, who knows.. good for you whoever you may
be!

HUH, again. This thread is about what happens during boot. This thread is
about BIOSs and about what a display card's BIOS does especially during
boot. Read the whole thread and get a clue.

"Rapu Rapala" wrote in message
...
FWIW, IBM PC compatible BIOS for a motherboard is example of device which
*does* have a x86 compatible CPU very often.

DUH!

Stating that all add-on boards
do,

No one ever stated that especially me. If you read the whole thread you'd
see that. The code on a card/controller is specific to the CPU on that
card, which could even be an 80186, such code is referred to as firmware
and not BIOS.

Some cards also(in addition) may have actual BIOS code(x86 code) that is
registered with the mobo BIOS and essentailly becomes part of that x86 boot
code set.

"Rapu Rapala" wrote in message
...
As far as I know of, most cards do have a Windows drivers for instance
which
are NOT loaded off ROM. ;-)

.. except the VGA/VBE bios which is used through interrupt 0x10 ..

OH, so now you are saying x86 code entry...now you got it.

which is
required feature only on IBM PC compatible systems.. if you drop such PCI
card to another architechture, you can still command it through the bus..
just more code to write, on the other hand the VBE BIOS


That's x86 code

is not very commonly
used anymore except for booting,

Now you got it.

maybe by the motherboard BIOS (int 0x21)
and some archaic "SVGA generic" drivers in Linux and MS-DOS, if you happen
to boot it for some bizarre reason.

Some text-mode tools also propably find it more convenient to use int 0x10
rather than write driver for all possible gfx card.. but again.. this is
just IBM PC compatible proprietary feature for cards which are supposed to
work on one.

But I don't see any technical reason why you couldn't use virtually any
PCI
card meant for "IBM PC" in any system which has PCI bus, as long as you
have
the software for the feat. Ron seemingly does, what a strange fellow!

Get a clue cretin.

"johns" wrote in message
...
You are about to get down a real rat-hole with the
ATI cards. They run well on certain hardware, but not
on others !!!!!!!!!! I'm not kidding at all. I wonder
why there is not a hardware compatibility list somewhere?
Don't put ATIs on the VIA chipset !!!

Don't put anything on VIA chipsetsg.

.. except the VGA/VBE bios which is used through interrupt 0x10 ..
OH, so now you are saying x86 code entry...now you got it.

No... I was covering every contingency, unlike you, loser. With assholes
like you that is mandatory, otherwise little ****-ant loser like you can
point out even tiniest omission.. next you propably are going to point out
how poor grammar I've got, because that's all you are going to be able to
complain about, loser.

Oh, hey, loser, while at it.. the VGA/VBE bios on gfx cards is required only
on IBM PC compatibles.. now you *might* get it.. I think you won't, because
you have shown consistently being stupid, loser.


required feature only on IBM PC compatible systems.. if you drop such
PCI
card to another architechture, you can still command it through the
bus..
just more code to write, on the other hand the VBE BIOS

That's x86 code

Wrong, loser, the PCI specification is not tied to x86 specificly, loser. It
is just so, that IBM PC compatibles expect the gfx card for example to have
VGA/VBE BIOS. Other architechtures are not so much concerned about presense
of VGA/VBE BIOS than IBM PC compatibles, they will accept the cards just
fine, unless they have their own requirements, which are less likely to be
port-level hardware level compatibility. As long as you got driver, you're
all set. No hardware obstacle for anything like you claim, loser.

is not very commonly
used anymore except for booting,

Now you got it.

You little piece of ****, if you knew this all along how come I am the one
who had to write it down for the record? Even if you know this stuff, you
sure suck at putting it down in writing, loser. Should be trivial for you as
it is for me, you little worthless ****.


Get a clue cretin.

So far you have been saying that "now you got it" and so on, as if I were
right. Now you ask me to get a clue.. so which is it going to be, you little
weasel? I'm sorry, did I get your feelings hurt by proving you're wrong? Oh
my..