On 6/1/05, Viktor Pracht <[EMAIL PROTECTED]> wrote: > Am Mittwoch, den 01.06.2005, 10:10 -0400 schrieb Timothy Miller: > > > Anyhow, the bottom line is that we can intercept the VGA palette > > writes, format them appropriately for our LUT, and then we can also > > format the pixels right during translation, and everything works out > > great, where some of the LUT work is done by the video controller. > > Sounds great! The VGA sequencer gets reduced to a shift register for > text mode and to wiring for graphic modes. All we need is a > microcontroller to handle the host access. Since this is not very > performance-critical, we could use some kind of stack machine because it > has 0-operand instructions and therefore less wiring. If the > microcontroller is too slow for memory reads (I assume PIO can take as > long as it wants), we could use 32 LUTs in distributed RAM mode to > implement the VGA write pipeline as a customizable ALU that takes the > rotated CPU data, the latched value from the last read, the previous > content of RAM, and outputs the data which is written back to RAM. The > 4th LUT input could be used to switch between read and write logic. The > microcontroller would only need to fill the LUTs, and even that can be > precomputed on boot and stored in video RAM.
Ok, well, for VGA registers, I'm sure we don't need a special microcontroller, but what I'm wondering is if the logic to implement the VGA framebuffer write pipeline is all that complex either. Unless there is some sort of masking going on (which would be trivial anyhow), VGA framebuffer reads shouldn't be any different from any other graphics memory reads. The writes look like they involve some processing, but I can't imagine that that would be anywhere NEAR the size of a CPU. Filling the LUTs could be easily hardwired as well. > I'd really like to fire up ISE and start modeling it all. What's missing > are the definitions of the the interface to the cache FIFOs and the > interface to the video controller (or whether we should design it all > ourselves). The interface to the PCI controller is already somewhat > defined, but I can't decrypt the names of the control signals. A couple > of comment lines per input/output describing the purpose and the > interaction with other signals would be nice. I'll work on those things. I think I really need to publish the code to the fifos, so you can not only see the interface, but you can see how interacting with it will affect signal delay. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
