[Coco] Last video I promise... :)

[Mark McDougall]

On 14/11/2014 1:40 AM, Luis Antoniosi (CoCoDemus) wrote:

> 1) I found out what was the major cause of jitter in my code. The PLL was
> not properly set and I was ignoring Quartus II warnings. I deleted it,
> remade, and run the Time Analysis tools to derive and make the uncertainty
> on it. It improved a lot. Also, I change some asynchronous place to make
> all of them very synchronous. The result was an even better image, less
> oscillation on 80 collumn screen, but still I think I can improve it even
> more working on the synchronous part.

Cool. I haven't had a chance to look at the code yet. :(

> 2) I managed to make a version without framebuffer and doubling the GIME
> rates. The results were no good for me. My monitor as I said struggles to
> keep up with GIME timing, although this time the image was way better than
> the previous time. The main problem now is the vsync that seems to be
> irregular, and the VGA oscillates half pixel up/down. This creates a
> flickering effect. Maybe a CRT would be ok, but not my LCD. I need to reset
> the counters together GIME but seems the GIME sync doens't happen on a
> steady pace for the VGA. The GIME scanlines are double the size of the VGA
> lines, any small variation is doubled on the VGA output.

That's odd. Have you verified alternating frame lengths in Quartus SignalTap?

What if you generate the vsync/vblank yourself, sycn'd with the start or end 
(but not both) of the GIME vsync? That way you have a consistent frame length.

The open source C64 FPGA core had a really kludgy video output that was a 
side-effect of the whole system timing; IIRC the last scan line was only 1/2 
width. Was OK on CRT but DVI didn't work at all. I ended up feeding it into 
a triple frame buffer to get a stable output, but then I had a rather large 
FPGA to play with at the time!

> Other inherent problem with this approach is the character shrinking
> effect. I'm displaying now 909 pixels where it was supposed to be 800 in
> the same window time. This makes some pixels to shrink and some columns are
> shrink and I don't like this. However you end up having borders in both
> sides.

You could free-run the VGA pixel clock to show 800 pixels across, and reset 
it on each HBLANK so it's back in sync with the GIME... in some respects 
analogue LCD screens are a PITA with their native resolution issues.

As I mentioned a while back, analogue capture and regeneration of video is 
tricky, which is why they have specialised chips to do it. But you've done a 
good job using just an FPGA, and no doubt more experimentation and 
development will lead to better - and more complicated - results!

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"