sorry to ask this again

[Ronald G. Minnich]

If someone has the *code* example for calling the vga init on a vga card I
could use it.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Massimo Dentico]

"Ronald G. Minnich" wrote:
> If someone has the *code* example for calling the vga init on a vga card I
> could use it.

Sorry for the delay. No distractions this time, only assembly code
for swithing video modes. ;-) This work, at least for me. Obviously,
I'm not writing BIOS usually :o) .. so, I don't know if it lacks
something for functioning as part of firmware.

Included as attachment:

modsrc21.zip  -- 18.402 bytes

P.S.: sorry for my bad English.

[Jeff Garzik]

Massimo Dentico wrote:
> "Ronald G. Minnich" wrote:
> > If someone has the *code* example for calling the vga init on a vga card I
> > could use it.
>
> Sorry for the delay. No distractions this time, only assembly code
> for swithing video modes. ;-) This work, at least for me. Obviously,
> I'm not writing BIOS usually :o) .. so, I don't know if it lacks
> something for functioning as part of firmware.

Thanks for posting code, unfortunately this code does not call the VGA
BIOS to initialize the video card -- this code directly programs the VGA
registers to switch modes, just like vga16fb in the Linux kernel.

BIOS init must have already executed in order for this code to work.

Regards,

Jeff

[Matthew Sullivan]

Hi,

Jeff Garzik wrote:
> Massimo Dentico wrote:
> > "Ronald G. Minnich" wrote:
> > > If someone has the *code* example for calling the vga init on a vga card I
> > > could use it.
> >
> > Sorry for the delay. No distractions this time, only assembly code
> > for swithing video modes. ;-) This work, at least for me. Obviously,
> > I'm not writing BIOS usually :o) .. so, I don't know if it lacks
> > something for functioning as part of firmware.
>
> Thanks for posting code, unfortunately this code does not call the VGA
> BIOS to initialize the video card -- this code directly programs the VGA
> registers to switch modes, just like vga16fb in the Linux kernel.
>
> BIOS init must have already executed in order for this code to work.

From a previous pose by 'James' at Berkeley, on Feb 17th 2000:
> > > > > > http://members.xoom.com/cattaghia/Tuts/biosstrt.txt

The ROM BIOS, on a system startup, executes the POST (power-on self-test) routine which usually checks memory, establishes devices etc.  The POST routine also fills in the BIOS memory area at 0000:0040h and sets up the real mode interrupt handlers (those connected to IRQ lines are set to dummy handlers which simply acknowledge the interrupt with the PIC and return, those assigned to BIOS services are set to the appropriate address, which may vary with the BIOS manufacturer and revision).  The POST then checks for extensions ROMs at this point (for example the video card).  Absolute addresses C0000h through E0000h are searched in 2KB increments for the signature 55h 0AAh.  If the signature is found, the next byte is a length indicator for the ROM (in 512 byte blocks) and the next bytes contain a FAR CALLable address (it should be called as an empirical address, with the lowest possible offset value.  For example, absolute address C0003h is called as C000:0003h).  The extension BIOSes perform initialization and then return. On entry, SS:SP must be set up as a valid stack.

Matthew

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
More Computer Terminology
-=-=-=-=-=-=-=-=-=-=-=-=-
Hardware: The bit that makes the noise when you throw you computer out the window.

[Jeff Garzik]

Matthew Sullivan wrote:
> Jeff Garzik wrote:
> From a previous pose by 'James' at Berkeley, on Feb 17th 2000:
> > > > > > > http://members.xoom.com/cattaghia/Tuts/biosstrt.txt
>
> The ROM BIOS, on a system startup, executes the POST (power-on self-test) routine which usually checks memory, establishes devices etc.  The POST routine also fills in the BIOS memory area at 0000:0040h and sets up the real mode interrupt handlers (those connected to IRQ lines are set to dummy handlers which simply acknowledge the interrupt with the PIC and return, those assigned to BIOS services are set to the appropriate address, which may vary with the BIOS manufacturer and revision).  The POST then che

cks for extensions ROMs at this point (for example the video card).  Absolute addresses C0000h through E0000h are searched in 2KB increments for the signature 55h 0AAh.  If the signature is found, the next byte is a length indicator for the ROM (in 512 byte blocks) and the next bytes contain a FAR CALLable address (it should be called as an empirical address, with the lowest possible offset value.  For example, absolute address C0003h is called as C000:0003h).  The extensio!
!
!
!
n BIOSes
> perform initialization and then return. On entry, SS:SP must be set up as a valid stack.

Thanks, I missed that post.  Yes, this is exactly what FreeBIOS/OpenBIOS
needs to do in order to be able to display video.

Note that many BIOSs do video POST as soon as possible, but initialize
other expansion ROMs much later in the boot cycle.

Jeff

[Matthew Sullivan]

Hi,

Jeff Garzik wrote:
> Matthew Sullivan wrote:
> > From a previous pose by 'James' at Berkeley, on Feb 17th 2000:
>
> Thanks, I missed that post.  Yes, this is exactly what FreeBIOS/OpenBIOS
> needs to do in order to be able to display video.
>
> Note that many BIOSs do video POST as soon as possible, but initialize
> other expansion ROMs much later in the boot cycle.

Actually from my expreience with Award and AM BIOS's they test for 55AA at A000 and then C000 looking for a mono card then then a colour booting the first card found and ignoring any second card.... (ie if a mono and colour cards are both present)....

The only thing I haven't worked out is if you have a card not located in the usual position most BIOS's will still boot it... but none of the BIOS's seem to want to init any second card.... (That includes the second VGA port on a couple of twin TVGA 9000 series cards I had to work on a while ago...)

My conclusion to this is there must be a global identifier to indicate the card is a display card... and the current BIOS's look for this so that they can determine, 1/ There is a display card in the system, and 2/ where it is ... I say this because last time I put 2 PCI VGA cards in a machine (not the same type) no matter what addresses I set them to and which slot they physically located, the same card booted each time...!?! This may be worth investigating further....

Matthew

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
I see you've set aside this special time to humiliate yourself in public.

[Jeff Garzik]

Can you turn on word wrap in your mailer, Matthew?

Matthew Sullivan wrote:
> Actually from my expreience with Award and AM BIOS's they test for 55AA at A000 and then C000 looking for a mono card then then a colour booting the first card found and ignoring any second card.... (ie if a mono and colour cards are both present)....

Yep, sounds like a good plan.
> The only thing I haven't worked out is if you have a card not located in the usual position most BIOS's will still boot it... but none of the BIOS's seem to want to init any second card.... (That includes the second VGA port on a couple of twin TVGA 9000 series cards I had to work on a while ago...)

By virtue of the fact that two cards cannot share a single VGA region,
you can only init a single card.  So that makes perfect sense.  The
standard BIOS reaction to multiple video cards is to -not- execute the
BIOS init sequence for secondary/tertiary cards, but to instead disable
their MMIO and PIO decoding altogether.  This is why XFree86 must map
and execute the video BIOS for a secondary card, before it can be used
as a secondary head.
> My conclusion to this is there must be a global identifier to indicate the card is a display card... and the current BIOS's look for this so that they can determine, 1/ There is a display card in the system, and 2/ where it is ... I say this because last time I put 2 PCI VGA cards in a machine (not the same type) no matter what addresses I set them to and which slot they physically located, the same card booted each time...!?! This may be worth investigating further....

Now -that- is strange.  If there is no video BIOS in the standard
location, it would seem logical to initialize the first
PCI_CLASS_DISPLAY card found...  or maybe PCI_CLASS_DISPLAY_VGA.

Jeff

[Matthew Sullivan]

Hi,

Actually you answered the problem....

Jeff Garzik wrote:
> Can you turn on word wrap in your mailer, Matthew?

I have but it's set to a high figure to stop it screwing with my mails... Doh! :-)
> Matthew Sullivan wrote:
> > The only thing I haven't worked out is if you have a card not located in the usual position most BIOS's will still boot it... but none of the BIOS's seem to want to init any second card.... (That includes the second VGA port on a couple of twin TVGA 9000 series cards I had to work on a while ago...)
>
> By virtue of the fact that two cards cannot share a single VGA region,
> you can only init a single card.  So that makes perfect sense.  The
> standard BIOS reaction to multiple video cards is to -not- execute the
> BIOS init sequence for secondary/tertiary cards, but to instead disable
> their MMIO and PIO decoding altogether.

Which answers it...
> This is why XFree86 must map
> and execute the video BIOS for a secondary card, before it can be used
> as a secondary head.
> > My conclusion to this is there must be a global identifier to indicate the card is a display card... and the current BIOS's look for this so that they can determine, 1/ There is a display card in the system, and 2/ where it is ... I say this because last time I put 2 PCI VGA cards in a machine (not the same type) no matter what addresses I set them to and which slot they physically located, the same card booted each time...!?! This may be worth investigating further....
>
> Now -that- is strange.  If there is no video BIOS in the standard
> location, it would seem logical to initialize the first
> PCI_CLASS_DISPLAY card found...  or maybe PCI_CLASS_DISPLAY_VGA.

However cards/the bus seem to have 'priority' between cards (I do _not_ know PCI bus operation) two different cards would work in different ways and have a different priority as to what memory areas they get....  As the card is not in the 'default video' location it's getting picked up on and by the PCI bus/PCI controller/PCI software and then being initallized...

First one started on the bus reset gets initiallized...? ...The answer...?

Matthew

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
You are validating my inherent mistrust of strangers.

[David Christensen]

Jeff,

The order that video cards get initialized is based on the bus they are
operating on (PCI or ISA), the PCI bus scanning order (lowest to highest
device or highest to lowest device) and BIOS setup options (AGP over PCI or
PCI over AGP).  An ISA video should be initialized first.  If no ISA then
generally the PCI device closest to the host-PCI bridge and with the lowest
device number (swapping two VGA cards between two slots should give an
indication of which PCI slot is the lower device number).  Some BIOS have
settings to allow an AGP device to be initialized first (AGP is usually on
PCI bus 1, many PCI VGA cards will be located on PCI bus 0, though some
systems may also have a PCI-PCI bridge and this wouldn't be true).  Of
course, vendors are free to make exceptions to this and may have other
criteria of making the decision (a VGA card with the OPROM disabled like
some Matrox cards probably won't be initialized as the boot video device).

The VGA card is identified by its class code in PCI configuration space.

Dave

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of
Matthew Sullivan
Sent: Tuesday, April 04, 2000 4:16 PM
To: Jeff Garzik
Cc: OpenBIOS
Subject: Re: [OpenBIOS] sorry to ask this again

Hi,

Actually you answered the problem....

Jeff Garzik wrote:
> Can you turn on word wrap in your mailer, Matthew?

I have but it's set to a high figure to stop it screwing with my mails...
Doh! :-)
> Matthew Sullivan wrote:
> > The only thing I haven't worked out is if you have a card not located in

the usual position most BIOS's will still boot it... but none of the BIOS's
seem to want to init any second card.... (That includes the second VGA port
on a couple of twin TVGA 9000 series cards I had to work on a while ago...)
> By virtue of the fact that two cards cannot share a single VGA region,
> you can only init a single card.  So that makes perfect sense.  The
> standard BIOS reaction to multiple video cards is to -not- execute the
> BIOS init sequence for secondary/tertiary cards, but to instead disable
> their MMIO and PIO decoding altogether.

Which answers it...
> This is why XFree86 must map
> and execute the video BIOS for a secondary card, before it can be used
> as a secondary head.
> > My conclusion to this is there must be a global identifier to indicate

the card is a display card... and the current BIOS's look for this so that
they can determine, 1/ There is a display card in the system, and 2/ where
it is ... I say this because last time I put 2 PCI VGA cards in a machine
(not the same type) no matter what addresses I set them to and which slot
they physically located, the same card booted each time...!?! This may be
worth investigating further....
> Now -that- is strange.  If there is no video BIOS in the standard
> location, it would seem logical to initialize the first
> PCI_CLASS_DISPLAY card found...  or maybe PCI_CLASS_DISPLAY_VGA.

However cards/the bus seem to have 'priority' between cards (I do _not_ know
PCI bus operation) two different cards would work in different ways and have
a different priority as to what memory areas they get....  As the card is
not in the 'default video' location it's getting picked up on and by the PCI
bus/PCI controller/PCI software and then being initallized...

First one started on the bus reset gets initiallized...? ...The answer...?

Matthew

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
You are validating my inherent mistrust of strangers.

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[James]

> By virtue of the fact that two cards cannot share a single VGA region,
> you can only init a single card.  So that makes perfect sense.  The
> standard BIOS reaction to multiple video cards is to -not- execute the
> BIOS init sequence for secondary/tertiary cards, but to instead disable
> their MMIO and PIO decoding altogether.  This is why XFree86 must map
> and execute the video BIOS for a secondary card, before it can be used
> as a secondary head.

I am curious: Does XFree86 drop _back_ into 16-bit mode to initialize
the second video BIOS?

- James

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Massimo Dentico]

Jeff Garzik wrote:
> Massimo Dentico wrote:
> > "Ronald G. Minnich" wrote:
> > > If someone has the *code* example for calling the vga init on a vga card I
> > > could use it.
> >
> > Sorry for the delay. No distractions this time, only assembly code
> > for swithing video modes. ;-) This work, at least for me. Obviously,
> > I'm not writing BIOS usually :o) .. so, I don't know if it lacks
> > something for functioning as part of firmware.
>
> Thanks for posting code, unfortunately this code does not call the VGA
> BIOS to initialize the video card -- this code directly programs the VGA
> registers to switch modes, just like vga16fb in the Linux kernel.
>
> BIOS init must have already executed in order for this code to work.
>
> Regards,
>     Jeff

Ops .. an error due to my scarce knowledge of PC hardware
and this phrase on the Linux BIOS home page: ".. simple VGA
capability up WITHOUT a VGA BIOS ..". So, is there an absolutely
necessary initialization phase that precede the setting of a
video mode? To switch a video mode requires the setting of dozens
of registers .. I hope that the init phase isn't so complicated.

Sorry again, my intention was only to help.

Best regard.

[Jeff Garzik]

Massimo Dentico wrote:
> Jeff Garzik wrote:
> > Massimo Dentico wrote:
> > > Sorry for the delay. No distractions this time, only assembly code
> > > for swithing video modes. ;-) This work, at least for me. Obviously,
> > > I'm not writing BIOS usually :o) .. so, I don't know if it lacks
> > > something for functioning as part of firmware.
> > Thanks for posting code, unfortunately this code does not call the VGA
> > BIOS to initialize the video card -- this code directly programs the VGA
> > registers to switch modes, just like vga16fb in the Linux kernel.
> >
> > BIOS init must have already executed in order for this code to work.
> Ops .. an error due to my scarce knowledge of PC hardware
> and this phrase on the Linux BIOS home page: ".. simple VGA
> capability up WITHOUT a VGA BIOS ..". So, is there an absolutely
> necessary initialization phase that precede the setting of a
> video mode? To switch a video mode requires the setting of dozens
> of registers .. I hope that the init phase isn't so complicated.

The init phase is not complicated at all -- when your computer is
booted, one of the first things it does is run the video BIOS.  The
video BIOS is the only place which contains the information necessary to
set up VGA compatibility.  The video BIOS must, for example, program
chipset-specific registers before it may access framebuffer memory.

Once all that initialization is complete, you can access the video card
in one of two ways -- indirectly, by issuing BIOS calls, or directly, by
programming the VGA and/or extended registers built into the video
chip.  vesafb in the Linux kernel is an example of using BIOS calls. 
vga16fb is an example of directly programming the VGA registers.
> Sorry again, my intention was only to help.

no problem at all... all contributions, especially ones with code
included, are valuable

Jeff

[Massimo Dentico]

Jeff Garzik wrote:
> Massimo Dentico wrote:
> > Jeff Garzik wrote:
> > > Massimo Dentico wrote:
> > > > Sorry for the delay. No distractions this time, only assembly code
> > > > for swithing video modes. ;-) This work, at least for me. Obviously,
> > > > I'm not writing BIOS usually :o) .. so, I don't know if it lacks
> > > > something for functioning as part of firmware.
> > > Thanks for posting code, unfortunately this code does not call the VGA
> > > BIOS to initialize the video card -- this code directly programs the VGA
> > > registers to switch modes, just like vga16fb in the Linux kernel.
> > >
> > > BIOS init must have already executed in order for this code to work.
> > Ops .. an error due to my scarce knowledge of PC hardware
> > and this phrase on the Linux BIOS home page: ".. simple VGA
> > capability up WITHOUT a VGA BIOS ..". So, is there an absolutely
> > necessary initialization phase that precede the setting of a
> > video mode? To switch a video mode requires the setting of dozens
> > of registers .. I hope that the init phase isn't so complicated.
>
> The init phase is not complicated at all ...

You are right, I had sent the e-mail before read the post of
Matthew Sullivan. It doesn't seem so difficult.
> -- when your computer is booted, one of the first things it does is
> run the video BIOS. The video BIOS is the only place which contains
> the information necessary to set up VGA compatibility.  The video BIOS
> must, for example, program chipset-specific registers before it may
> access framebuffer memory.
>
> Once all that initialization is complete, you can access the video card
> in one of two ways -- indirectly, by issuing BIOS calls, or directly, by
> programming the VGA and/or extended registers built into the video
> chip.

I know this; the only thing that I have missed, until now, is that
the video card doesn't start directly in VGA compatible mode.
> vesafb in the Linux kernel is an example of using BIOS calls.
> vga16fb is an example of directly programming the VGA registers.
> > Sorry again, my intention was only to help.
>
> no problem at all... all contributions, especially ones with code
> included, are valuable

Thanks for the patience. :-)