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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
"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. -- Massimo Dentico
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 -- Jeff Garzik | Tact is the ability to tell a man Building 1024 | he has an open mind when he has a MandrakeSoft, Inc. | hole in his head. (-random fortune) - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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:
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. -- Yours Matthew -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- More Computer Terminology -=-=-=-=-=-=-=-=-=-=-=-=- Hardware: The bit that makes the noise when you throw you computer out the window.
Matthew Sullivan wrote:
Jeff Garzik wrote: From a previous pose by 'James' at Berkeley, on Feb 17th 2000:
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 -- Jeff Garzik | Tact is the ability to tell a man Building 1024 | he has an open mind when he has a MandrakeSoft, Inc. | hole in his head. (-random fortune) - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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.... -- Yours Matthew -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- I see you've set aside this special time to humiliate yourself in public.
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 -- Jeff Garzik | Tact is the ability to tell a man Building 1024 | he has an open mind when he has a MandrakeSoft, Inc. | hole in his head. (-random fortune) - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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...? -- Yours Matthew -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- You are validating my inherent mistrust of strangers.
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: owner-openbios@elvis.informatik.uni-freiburg.de [mailto:owner-openbios@elvis.informatik.uni-freiburg.de]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...? -- Yours Matthew -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- You are validating my inherent mistrust of strangers. - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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. -- Massimo Dentico - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 -- Jeff Garzik | Tact is the ability to tell a man Building 1024 | he has an open mind when he has a MandrakeSoft, Inc. | hole in his head. (-random fortune) - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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. :-) -- Massimo Dentico - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
participants (6)
-
David Christensen -
James -
Jeff Garzik -
Massimo Dentico -
Matthew Sullivan -
Ronald G. Minnich