Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cbmvax!hood From: hood@cbmvax.commodore.com (Scott Hood) Newsgroups: comp.sys.amiga Subject: Re: Commodore De-interlacer Message-ID: <15696@cbmvax.commodore.com> Date: 7 Nov 90 22:03:45 GMT References: <5463@crash.cts.com> <239@mohawk.cs.utexas.edu> <565@cbmger.UUCP> <1990Nov7.181228.3182@uokmax.ecn.uoknor.edu> Reply-To: hood@cbmvax.commodore.com (Scott Hood) Organization: Commodore, West Chester, PA Lines: 64 In article <1990Nov7.181228.3182@uokmax.ecn.uoknor.edu> drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) writes: >>> (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) I guess that I should put this one to rest once and for all. The problem is with the way that the Amber chip did the de-interlacing. It has nothing to do with beam position or sync or any other such infromation, but these are not unreasonable guesses! When the Amber chip was in development I did not think that this was such a bad artifact (I know, I know, how could one be so foolish!) and only a few people said anything about this flickering 1/2 line. By the way, it really is 1/2 of the total 910 (NTSC) or 908 (PAL) line, that is flickering, because of the position of active video in the line it appears to be only 1/3 of the line. It is possible to fix this `artifact' by changing part of the internal circuitry of Amber and work is under way to investage this. I can not say much about this for may reasons but your concerns are not going unheard! When it is appropriate for me to make further comments about this I will do so. Remember that most things are not cast in stone! Scott Hood -- -- Scott Hood, Hardware Design Engineer (A3000 Crew), Commodore-Amiga, Inc. {uunet|pyramid|rutgers}!cbmvax!hood hood@cbmvax.cbm.commodore.com "The views expressed here are not necessarily those of my employer!"