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

[Luis Antoniosi (CoCoDemus)]

Ok I made more tests yesterday and two conclusions:

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.

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.

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.




Luis Felipe Antoniosi



On Wed, Nov 12, 2014 at 8:50 AM, Luis Antoniosi (CoCoDemus) <
retrocanada76 at gmail.com> wrote:

> Yeah I can try making a new version without framebuffer since I matched
> the GIME cock now.
>
> Just one line is enough, in fact I need two lines: one being doubled and
> other being scanned.
>
>
>
>
> Luis Felipe Antoniosi
>
>
>
> On Wed, Nov 12, 2014 at 7:23 AM, Mark McDougall <msmcdoug at iinet.net.au>
> wrote:
>
>> On 12/11/2014 11:02 PM, Luis Antoniosi (CoCoDemus) wrote:
>>
>>  I needed a framebuffer because I couldn't make it to work without it. The
>>> GIME clock gets out of the sync with the VGA timing and I ended up
>>> having a
>>> rolling screen.
>>>
>>> The pixel clocks are not mutiple. While the GIME pixel clock is
>>> 14.318Mhz,
>>> the VGA pixel clock is 25.175Mhz
>>>
>>
>> You can clock the VGA off 2x your GIME pixel clock, you don't have to be
>> absolutely perfect on the 'standard' VGA timing, and even less so on CRT's.
>> The monitor should be able to handle it; I've certainly not had any
>> problems simply doubling the 'composite' clock.
>>
>>  My converter needs a pixel perfect representation of the screen in order
>>> to
>>> reconstruct the artifact modes.
>>>
>>
>> Surely you just need a line buffer to do that? Or do adjacent lines
>> affect one-another for the artifact mode?
>>
>>  Having a framebuffer in the middle gives me freedom to each component to
>>> work at their own speeds. Also, this solves the problem to convert from
>>> 50Hz to VGA 60Hz. I have a french coco2 peritel that does RGB SCART in
>>> 50Hz
>>> and a MSX computer that can operate in 50Hz NTSC.
>>>
>>
>> OK, this I concur. I didn't factor in PAL video modes, despite being
>> Australian! Doh! ;)
>>
>> Regards,
>>
>> --
>> |              Mark McDougall                | "Electrical Engineers do it
>> |  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
>>
>
>