On 9/4/07, Patrick McNamara <[EMAIL PROTECTED]> wrote: > > How big a penalty are we going to take for memory reads and writes? > Well, reads anyway? Are we still looking at perhaps a 20 clock delay in > the 200Mhz domain for a read to return data?
Much worse than that. The requests have to cross the bridge from the XP10 to the 3S4000, through some other processing logic, through the memory controller, and back. > > You have to be able to look up the colors as you can change the color > palette for text. Still limited to 16 colors of course, but just like > 16 color graphics modes, you can adjust what those colors map to. Isn't that palette configured through I/O space? That's another thing the nanocontroller is responsible for: storing those registers in scratch space or whereever. > > From a memory access perspective would it be more efficient to draw one > vertical row of each glyph in a row? If writes don't impose a real > penalty or less of a penalty than reads, then probably not. But it is > something to think about. Yes and no. There's so much other overhead, it probably doesn't matter much. Something occurs to me. We have these asynchronous things going on here, where we make requests for reads and then get the data later. The PCI controller causes this to happen when the host accesses graphics memory. If someone were to make a request, through the same set of fifos that the nanocontroller used, there'd be a race condition. I think we don't need interrupts. I think we need to put subroutine calls at appropriate places in the nanocontroller code to a routine that polls for an outstanding PCI transaction and handles it. Is it a problem that we'd impose significant delays (and may retries on the PCI bus)? No more than already happens if you try to read the framebuffer at the same time the video controller is reading a chunk. > I still haven't figured out how to do blinking text without doing this > in a continuous loop yet. *sigh* Do we have any ability for the > nanocontroller to tell time? At least by counting clock cycles or some > such thing. Best would be able to have an time based interrupt, but > that may require more hardware than we want to allocate. I was thinking we could have it actually read a register in the video controller. :) -- 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)
