On 7/28/06, Richard Smith <[EMAIL PROTECTED]> wrote:
Now I'm NOT suggesting that any of the current design needs changing or even that anyone needs to think about this ability right now. There is _plenty_ of stuff to accomplish before this matters. I'm just following up on my specific concerns which is that we end up with a card that while flexable is PITA to setup. I think after reading the rest of this thread that most of my concerns are unfounded.
Well, we don't want to leave anyone out or make things too difficult to program. But we're especially now in a situation where every gate counts. If you can remove lots of hardware by writing a little software, it's a winner. Most of the time, things are a PITA because the docs suck. We won't have that problem here. Also, our video compiler should be coded so as to not require any memory buffers. However, we probably want a stack for local variables, which can be a problem. When I did my VGA BIOS, I used parts of the framebuffer as scratch memory, and I've seen other BIOSes that take advantage of the fact that the BIOS image is a copy in RAM and just write to that memory space for scratch buffers. Worst case, we'll have to have a few video moves hardcoded. Hand-coding them may save a little space too. Another common techique would be to generalize the program so that it's a template. Load the program into the video controller, then replace a handful of words with modified values for the appropriate res. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
