---------- Forwarded Message ----------
Subject: Re: [Open-graphics] VGA register documentation Date: Friday 06 May 2005 16:21 From: Patrick McNamara <[EMAIL PROTECTED]> To: Daniel Phillips <[EMAIL PROTECTED]> --- Daniel Phillips <phphillipseredhatom> wrote: > On Friday 06 May 2005 09:16, Timothy Miller wrote: > > On 5/6/05, Daniel Phillips <phphillipseredhatom> wrote: > > > Was it decided whether to implement (a few) text modes only, vs > > > vgvga> > > > graphics modes as well? It would seem sensible to implement only > > > > text modes for the time being, in order to leave more room on the > > > FPFPGAor our own (non-vgvgagraphics mode(s). > > > > > > If it is going to be text mode only, does that reduce the number > > > of registers that need to be fully documented? Or do we want to > > > fully document the vgvgaraphics-related registers anyway, and > > > just mark the ones that are not involved in text modes? > > > > My opinion is that if we want to boot Windows, and we want to > > support safe mode, we need to support some graphics modes. > > How important is it that the very first FPFPGAelease boot Windows? > How about just booting Linux for the first release, and spend some > saved gates on more multipliers and memory control logic? > > Maybe this is something we need to add to the survey: > > a) Would you buy this card _only_ if it boots Windows (where nobody > really needs an open graphics card anyway) > > b) Would you want this card even more if it _doesn't_ boot Windows > :-) > > c) Do you dual boot? Don't you have a working video card already, > that already has Windows drivers? Why not keep using that one > to boot Windows? > > We can always follow up a few weeks later with a logic upgrade to > boot Windows. But I for one would not want to delay the Linux > release by even a week to accommodate that. > > And: will Windows drivers even be ready by then? Is anybody really > passionate enough to write those drivers, particularly given the > extra level of pain they can expect for low-level Windows code? > > /me listens for a thundering herd of volunteers... > > Regards, > > Daniel Something to consider in all this: It is actually way easier to support basic graphics modes than it is text. Even the screwy VGA legacy graphics modes are basically paged and possibly packed bit maps. In text modes, you have to handle attributes, font bit maps, cursors, etc. Another thing to consider: They are x86 motherboards that have graphical BIBIOS'sn them. While you can get to a text version on some, others you can't. Here is my two cents. Once the prototype is made, the goal should be to get it to display an image on a machine. Doesn't matter how. We don't even have to have the VGA section working as long as it is capable of being initialized as a secondary card. A rudimentary driver cacapablef display a GLGLears type program would be sufficient. The aim being to have something we could show investors to show that we actually have a product. Once the prototype is made, developers can start buying their own. I'll be purchasing one as soon as I can. As various parts of the card begin to fall into place, the development boards get reloaded and new functionality comes ononline I don't believe that the ASASIChould be taped out till we have a chip that will work reasonably in "Joe BlBlow'ssystem out of the box. This means a reasonable set of features people expect in a video card, including the basic VGA graphics and text modes. While we are not targeting the "AOAOL'ers(my apologies to any AOL users on the list) of the world, we want to make sure that if someone who isn't in our target market buys our card, they have a good experience. One of the big differences in hardware and software is you can't patch hardware (in general). We can release the development boards when they are ready as at that point, all the functionality is still software. Plus, Timothy and others have pointed out, they are now building a general purpose FPFPGAevelopment board that we are then going to use to build a video card. OkOkthat was a long two cents... Patrick M ------------------------------------------------------- _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
