Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!bryan
From: bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End)
Newsgroups: comp.sys.amiga
Subject: Re: Commodore De-interlacer
Message-ID: <237@mohawk.cs.utexas.edu>
Date: 31 Oct 90 17:40:05 GMT
References: <15436@cbmvax.commodore.com> <235@mohawk.cs.utexas.edu> <15450@cbmvax.commodore.com>
Reply-To: bryan@cs.utexas.edu
Organization: Spam Detection & Removal Squad, Austin, TX
Lines: 24
Spam-Content: Negligible

In article <15450@cbmvax.commodore.com> hood@cbmvax.commodore.com (Scott Hood) writes:
=-
=-Yes, the A2320 does exhibit the same top 1/3 scan line flicker as the
=-A3000, but with the Commodore 1950 multiscan monitor (and some others)
=-you can adjust the vertical and horizontal sizing controls to put the
=-black boarder behind the monitor's faceplate and not see the top line
=-flicker.  This may not be the best solution, but it works!  I am looking
=-into this further...
=-

	Sure, it works, but if one uses full vertical overscan, then the top
corners of the display disappear behind the rounded corners of the bezel.  The
1950 doesn't, as far as I could tell, have a proportional horizontal size
control that would allow the picture to be narrowed just enough to make up for
this.  The horizontal size switch is much too coarse an adjustment.  In any
case one shouldn't have to fiddle with knobs to make up for an inadequate
deinterlacing algorithm.

	If, as has been suggested, this top scan line flicker is an artifact of
NTSC, there must still be a way to overcome the problem, since the flickerFixer
does not behave in the same way.  Perhaps it throws away the first scan line in
every odd field.  This would seem to be a reasonable solution, and I wouldn't
expect the marginal cost of the extra logic to do this to be large, though I'll
certainly defer to the opinions of people who actually design these things.