On 8/8/07, Michael Meeuwisse <[EMAIL PROTECTED]> wrote: > Hello all, > > I'm trying to get a better picture of everything that's needed for a > video card, so I can hopefully help out in the near future with well, > something. I'm willing to document a whole lot of things (as soon as > I understand it myself).
You can never have enough documentation. We welcome your help with that! > > Right now I convinced myself I 'get' how PCI works, but right after > that I'm stuck. I'm hoping somebody can answer (some of) the > following questions; > > a) How do plain VGA registers (lots of documentation talks about > things like address 3B4h) get 'mapped' to the correct PCI device? Is > address 3B4h in C/BE#'s 'I/O Space', 'Memory Space', or some added > fields to the configuration space? 3B4h is in I/O space. And it's not in a BAR-mapped space. When our PCI controller sees that address (and we've enabled VGA), it decodes a limited range of "legacy" I/O space addresses. These are the only I/O space addresses we support. All others are memory space. Since these legacy addresses are not allocated to a particular device, there are certainly concerns in a PC system about more than one device attempting to accept them. I think the correct thing to do is have the first VGA device figure out that it was initialized first (there's a certain order in which a PC BIOS initializes devices, with the console gfx card being very early) and be the only one to enable the decode. (Enabling the decode would be device-dependent, I would imagine.) > > b) If I plug in a PCI device which identifies with Base Class 03h, > Sub Class 00h and Interface 00h, will the PCI BIOS and/or 'main' BIOS > use this automagically or is some action from the PCI cards' point of > view required? How tightly is this coupled with question a? Do I (the > PCI card) need to request any mapping? I'm guessing you're referring to a VGA device (I don't have the class listing in front of me). Basically, when the BIOS starts up, it looks for one of these devices very early in the boot processes and sets it up. Then it does other initialization, followed by setup of other PCI devices (network, secondary gfx, etc.). > > c) What's all this talk about VGA BIOS? Where is it located > (motherboard or PCI card) and if this contains code which is executed > by any other BIOS calls and/or interrupts, what does it (as a bare > minimum) need to support? For our purposes, "VGA BIOS" is a bit of x86 code that resides in our EPROM that sets up our card in VGA-compatible modes. There is a header with a certain format. Somehow, we hook into a table of far pointers (this is all done in real mode) so that certain x86 traps (interrupts) are directed to our code. (Look up int10.) We can then provide hooks for changing text/gfx modes, writing characters to the screen, etc. Note that many DOS programs completely bypass some of these system calls; for instance, when in an 80x25 text mode, software often just assumes a standard 2 byte per character arrangement and write to the display memory directly. That's one of the reasons we need special hardware support for VGA. > d) All registers seem to be explained, but I can't figure out how you > switch the graphics mode. Every document seems to say 'just switch to > mode 3', but from a PCI card perspective, how is this done? Is this a > specific register? VGA BIOS instruction? Typically, it's a call to our BIOS code via one of the INT calls. > > That were the more fundamental questions for now, I got a few 'less > tricky' ones as well :) > > d) How is OGD1 doing this whole VGA BIOS thing, and why can't I find > anything of it in the CVS? It hasn't been written yet. Our XP10 FPGA is hooked up to a SPI PROM, and we have all the logic in there to handle THAT part of it. So if someone were to write the VGA BIOS, we could put it in there, and then with all of the supporting logic ultimately in place, we can act as a boot console. > e) Is there a movie available of OGD1 working at OSCON? Really > curious, that's all. :) No. Sorry. I started putting together a video of OGD1 here, but I got pulled away in the middle. Maybe I'll return to it. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
