On Mon, Jul 21, 2008 at 6:23 AM, Mark Marshall <[EMAIL PROTECTED]> wrote: > Hi. > > I've been lurking here for some time, and would like to offer to (help) > write the VGA BIOS. > > As far as I can tell no actual work has started on this?
That is correct, and so your offer to help with it is most greatly appreciated. > > I'm not fully sure of the level of compatibility that it is hoped to obtain > for this first version, it looks like we are going for compatibility at the > BIOS and memory access level but are not going to use any of the standard > CGA/EGA/VGA registers? Is this correct? This would seem to limit things to > text mode only, as there is no way you can use a graphics mode without also > using the registers (apart from mode 0x13). We're limiting to text only as a first step. Our PCI controller can decode the VGA I/O register space. > > My plan would probably be to try to setup bochs (or another x86 emulator) > with a simple model of the chip and to program against that. It always > seems to be a good idea to stay away from the real hardware for as long as > possible when developing new code like this else you just get bogged down in > details that will sort themselves out later. Plus, it's easier to debug when something goes wrong. You won't have our hardware to distrust when you're developing, and once your BIOS is working, we won't have to worry about it doing the wrong thing. > I realize that I've come to this project late so I don't want to rock the > boat too much, but I think that we could get a lot further with VGA > compatibility if we were to implement the VGA registers and the memory > access logic in hardware. We would really like to be able to do a variety of VGA and VESA modes, so we have implemented this. Any register that we don't properly support already is a "bug" that needs to be fixed. > For the registers we would have the logic to > implement the indexing schemes in hardware and their values would be > readable by HQ (with possibly some sort of notification that they've > changed, but this might not be needed). The PCI controller and address decode logic drop PCI-related events into queues for HQ. Its job is to check those queues and service them in code. For instance, if someone writes to a VGA color palette register, HQ will be notified of the raw access, and it will have to figure out where in its scratch memory (and possibly our video controller) to store the color value. > For host memory accesses I think > that we should implement the VGA read and write modes. This actually turns > out to be not that much verilog, but it does make the card appear to be much > more like a real VGA card. We would need a way to switch this off for when > we were using VESA modes or our own device drivers. (In my test > implementation of the above they come out at about 250 lines of verilog > each). Our plan is to implement this in microcode. But we want to implement exactly this functionality. We're not going for fast here. Just compatible. > As I said, I know that I am coming to this project late, and would still > like to help even if the first targets are for a more reduced functionality > than this. It would certainly be good to get a simple text console working, > and this should obviously be a first target. I've been getting desperate. Late is better than never. Plus, we're coming up on a time when it'll become a bottleneck. Ideally, someone would be working on this, at least the preliminary stuff, well before the hardware is ready. We need to fill the wiki with all of the information that pertains to what you're doing, so we all have it as reference. > The things that the BIOS needs to do are all relatively simple, but the > documentation is spread thinly all over the place. So, a quick list: > - Contain a magic header at the start (0xAA, 0x55) > - Install a few interrupt handlers (0x10 + 0x1D,0x1F + 0x42 + 0x43) Do there exist some default routines for this in main system BIOSes? So, if the graphics card doesn't implement the interrupt, will the system BIOS assume standard hardware and use it? > - Manage some data in the BIOS data area (addresses 0x40:00xx) > - Load the correct HQ program (contained in the ROM) > - Control the hardware Yes. I think the only other thing that needs to be done is: - Set up video Our video controller is nothing like what's in a VGA card. For one thing, it only knows how to scan out pixels, which is why we need HQ to convert continuously in the background. > > Anyway, any comments or direction before I begin coding would be great. Mostly keep discussion on the list so we have documentation, we should try our best to document things on the wiki, and coordinate with me and Petter and Howard as we go along. I'm excited! Thanks for joining us on this! -- 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)
