Reference this: http://lists.duskglow.com/open-graphics/2004-November/000238.html
The one thing that this doesn't handle well is a cursor, so I'm looking for suggestions. One way to do it is for something later in the pipeline to watch the video sync signals and infer counters to compute cursor pixel coordinates for the overlay. Another way I can think of is to make the counters more explicit in the display list code. That is, there would be flag bits in the instruction words to control things like resetting and incrementing counters. Then we use those with an offset to decide where to overlay the cursor. The block rams are 32 bits wide, 512 words deep. We could therefore store two 16x16 cursors. Unfortunately, we have to read them single-ported. That is, we have to read 64 bits at a time, using both RAM read ports (in a Xilinx chip). If you modify the cursor glyph while it's being read, the glyph will glitch for a frame on the screen (no big deal). But more importantly, each head requires its own cursor RAM, because they're running independently. Should we bother to add the logic to have two independent glyphs? Or should we perhaps allow for 32x16 or 16x32 glyphs? Or for that matter, we could go to 16-bit color and do 64x64! _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
