MasterOfGizmo wrote:With the new scandoubler my TV basically doesn't work at all ... But sometimes for a fraction of a second i see a correctly colored image, so the YPbPr conversion still works.
The TV then displays the same image two times side by side which means that it doesn't sync to every hsync but to every second hsync. I see that you resync the clock divider of the scan doubler to the incoming hsync. I am afraid this constantly happens on every incoming hsync and thus affects the clock of every second outgoing VGA hsync. Thus the hsync times of two subsequent scandoubled lines vary slightly. And my TV skips every second hsync since it's slightly out of phase.
The issue is somewhat complex (which is why i so far tried to avoid it): The base clock is 54Mhz. This is divided by 7 to get the 7.6 Mhz pixel clock. But for the scandoubler we need 14.2 Mhz which cannot be divided nicely from the 54Mhz. But without stable clock we get these artifacts like a slight jitter on the VGA hsync. I was already thinking about using a PLL to double the 14.2Mhz from the 7.6Mhz ...
I've measured the length of the hsync, they should be the same. Also the same amount of clocks should happen in every line (first I had a slight variation of the line lengths, and that caused zigzagged picture). Is it also not working with the update I've posted here? In that version I aligned the vsync negative edge to hsync's, and added a bit more to the length of the vsync. Or maybe the problem can be the scandoubler halves the time of the original hsync, and this is not enough? Fascinating this scandoubler works in lots of cores, just not here
Btw, the pixel clock is more complex, sometimes it's MCLK/8, sometimes MCLK/10, but until the line lengths are constant (3420 MCLKs in standard modes), I think it shouldn't cause an issue. The scandoubler reads in MCLK/4, writes in MCLK/2, it should fit nicely into the 3420 MCLKs.