On Fri, Jul 18, 2008 at 1:31 PM, Petter Urkedal <[EMAIL PROTECTED]> wrote: > On 2008-07-16, Timothy Normand Miller wrote: >> [...] That >> pushes the VGA BIOS and the HQ microcode up in priority. > > I believe HQ has not yet been connected to the bridge?
No. Not yet. We're going to get to that once we have debugged it to this point. However, that doesn't mean we can't start on the coding and them merge things later. Would you like to work with me to architect this? > >> The next tasks, things we really need help with, include: >> >> - HQ microcode. > > When we start on the microcode it may be an idea to come up with an > (manually enforced) ABI for utilise the registers as best as we can > without ending up with a web of dependencies to rework if we need to > change something. Is there a register-based ABI/practices we can adapt? > Otherwise, I can write up some ideas. Are you referring to the assignment of "names" to scratch space addresses? We definitely need something like that, but it may be very program-dependent. Unless things turn out to be surprisingly small, we'll have one program for VGA text, one for VGA graphics, and eventually, one for DMA. BIOS or kernel can reload the program as necessary. I'm always in favor of creating good design structures. 512 program words doesn't seem like a lot, but that's part of the challenge -- fitting a program into that space. To keep our sanity, we really need to be organized about it. This is especially important for us and our progeny to be able to maintain it later. Unfortunately, I'm not sure what pre-existing paradigms might apply here, so lets develop something new. -- 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)
