On 6/29/06, Vesa Solonen <[EMAIL PROTECTED]> wrote:
The problem of losing sync come only then when the change is too fast. Is there any way to implement just variable main clock to the raster generator? Meaning a runtime access to the pixel clock pll registers.
While I'm sure it's possible to feed the video PLL from an external source, I don't think it's the cleanest way to go, nor is it necessary. Like I say, there's going to be some latency between data getting into the framebuffer and it getting scanned out of our chip. Our video output is going to be behind the output. It might be a few scanlines, a frame, or multiple frames, depending on any software overhead. Unless we take some sort of direct video input feed right into our user I/O connector, there simply is no exact synchronization with another video feed. Even then, we're going to at least be some number of pixels behind, simply due to clocking the data into our chip, mixing it with our own video data, and then feeding it back out again. In this case, we do have to be pixel-exact, but I think it may be asking too much for us to provide this feature right now. I think the best we should ask for right now is for the captured video to get written to our video memory. Either via DMA or via a direct connect. No one would ever notice if we were dozens of scanlines behind. Given that, a drift of hundreds of clocks between input and output video (which we compensate for in blanking) is not going to be a problem. Soon, I'll publish the source to my proposed video controller design. Have a look, and you'll see that doing the correction at any other time could be rather painful to add. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
