Ultimate VIC-II riser reloaded - (was: Difference in luma-chroma...)

From: silverdr_at_wfmh.org.pl
Date: Sat, 2 Sep 2017 14:42:09 +0200
Message-Id: <96C1F82A-103C-465F-94E7-527A9FA7B2B6@wfmh.org.pl>
> On 2017-09-02, at 11:00, smf <smf@null.net> wrote:
>> Well, as long as you can store about one line you could tweak the clock
>> frequency of the computer so that it produces 624 lines every 1/25
>> second, and then just insert one extra line on every other field.
> Are you saying:
> You would have to change the clock speed so that two VIC frames equals one interlaced frame. But all the lines will be out of sync

The better way would be to mess with the (VIC) clock only on the last line. This way it would not affect anything on the rest/visible parts of the screen.

>  and so would need to be digitised and clocked out at the correct time & the proper syncs generated, to create the extra half line gap in the middle. Buffering data from vic and varying how much to delay it on each line to match legal hsync.

Syncs need to be generated separately because what VIC generates as vsync is not in line with specs anyway.

> My thoughts:
> That should be in tolerance for tape loading, I'm not sure about disk fast loaders.

No, no matter how it is done, this must not break existing software.

> It would cause real bad field seperation artifacts with horizontal movement.

No worse than what a regular video or Amiga (laced) output does. The idea is that it is much better to deal with deinterlacing (we have ways for it) than it is not having anything to deal with. The latter is more and more common these days.

>> - driving only the last line alternately at twice / half the regular clock so that everything but the last line remains unaffected
> If you drive the entire systems clock at double/half the speed for half a line then you'll definitely upset tape or disk loading. If you decouple the vic from the cpu then you're running the risk of software issues.

As long as it is kept stable and in sync with the original, VIC generated clock there shouldn't be any, should there be?

> Spreading out the clock speed difference over two frames is the safest bet. It also avoids the problem of anything going mad if       run at double the speed (vic does memory accesses and refresh cycles).

It might be the simplest/safest but it would affect everything. Things would run differently, look differently, sound differently, etc. That's not something I would be happy with.

SD! - http://e4aws.silverdr.com/

       Message was sent through the cbm-hackers mailing list
Received on 2017-09-02 13:00:03

Archive generated by hypermail 2.2.0.