Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!uokmax!drtiller
From: drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr)
Newsgroups: comp.sys.amiga
Subject: Re: Commodore De-interlacer
Message-ID: <1990Nov7.181228.3182@uokmax.ecn.uoknor.edu>
Date: 7 Nov 90 18:12:28 GMT
References: <5463@crash.cts.com> <239@mohawk.cs.utexas.edu> <565@cbmger.UUCP>
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK
Lines: 40

>> (about the flickering first half line)
>>       Every time this subject comes up, I ask why the C-A deinterlacer can't
>>handle the first scan line in whatever way the flickerFixer does.  I've never
>>seen any answer to this.  I'd just like to know whether the problem is due to
>>a design or manufacturing error, or is the deliberate result of some cost
>>reduction measure.
>>  In either case, is it with us forever?
 
>It has already been answered by one of the chip guys. The reason is the
>definition of an interlaced TV screen where the Amiga sticks to. In this
>norm one half picture starts in the upper left, but the other half picture
>starts with a half line at the top in the middle. And they obviously did
>their best to manage this also on the Amiga.
>So the question arises: What does flickerFixer put in there?
> 
>To get an understanding for this half line, you must imagine that during
>a horizontal scan the vertical scan already and also is running, but
>much slower. So all lines are bent a little downwards (if you don't
>twist the tube). So for the second half picture to match perfectly
>inbetween the lines of the first half, they (TV norm definers) chose to
>start at the very top but offset by half a line horizontally. When you
>draw this on paper you will see, that this way you get a perfect
>interlacing of the two half pictures. And Amiga is dedicated to follow
>TV norms.

Yes, but what does the electron beam scan have to do with the problem?
Whatever happens to the signal at the monitor isn't causing the 1/3
line flicker, the de-interlacer is.  That means that the timing in
the A2320 doesn't sync every frame until about 1/3 of the way into the
first scan line.  The lack of sync causes a variation from frame to
frame that results in oposing information appearing as flicker.
Obviously the FF overcomes this by syncing earlier or (more likely
since I talked to the FF guy and this seems to be his technique for
eliminating problems - i.e. garbage on the right edge) just covering
the offending video with blanking.  A similar solution for the A2320
would be reasonable (BTW, the FF displays "about 719 by 479 hi-res
pixels", I wonder why :-).

Rick Tillery
(drtiller@uokmax.ecn.uoknor.edu)