Xref: utzoo comp.sys.amiga:21897 comp.sys.amiga.tech:1542
Path: utzoo!attcan!uunet!husc6!uwvax!oddjob!ncar!ames!ucsd!ucsdhub!jack!crash!pnet01!haitex
From: haitex@pnet01.cts.com (Wade Bickel)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: Message from designer of FlickerFixer
Message-ID: <3328@crash.cts.com>
Date: 17 Aug 88 15:56:28 GMT
Sender: news@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 86

u-jmolse%sunset.utah.edu@utah-cs.UUCP (John M. Olsen) writes:
>This came up before, but I think that much of the discussion was in Email
>(for a change :^).  When the machine is modifying the display at 60 Hz,
>like redrawing a moving mouse pointer, there are no two correctly matched
>fields to display that will not cause split images, and hence the Flicker-
>fixer does the absolute best possible thing until the system forces all
>software to update at a maximum of 30 Hz, which would be a Bad Thing.
>Nobody likes having their animation speed cut in half.  The designers 
>worked with what they had, and did the best they could.

        Not so.  What you could do is to buffer a full 2 fields and show them
on both screen updates.  Example:

     Time (60th/secs)    Amiga Displays         Buffered video output
   ------------------- ------------------ ---------------------------------
          0              Shortframe[0]          undefined
          1              Longframe[1]           undefined
          2              Shortrame[2]           Shortframe[0] + LongFrame[1]
          3              Longframe[3]           Shortframe[0] + Longframe[1]
          4              Shortframe[4]          Shortframe[2] + Longframe[3]
          5              Longframe[5]           Shortframe[2] + Longframe[3]
          6              Shortframe[6]          Shortframe[4] + Longframe[5]


                as compared to what the fF generates

          3             Longframe[3]            Shortframe[2] + Longframe[3]
          4             Shortframe[4]           Longframe[3] + Shorframe[4]
          5             Longframe[5]            Shortframe[4] + Longframe[5]

        As you can see, this does not impose any slow down on the actual data
rate of the CRT.  It does however require aprox. twice the ram, and this is
why the fF does things the way it does.  With RAM chips as expensive as they
are cost is a definite design criterium, and a legitimate one at that.

        Still, I cannot see the fF being accurately described as a
de-interlacer.  It is a flickerFixer.  I think there is a difference.


>
>To properly de-interlace an NTSC signal, you need to be able to tell which 
>pair to match, but only if they are meant to be matched, which they
>currently are not on the Amiga.  Under the current system, every pair of 
>adjacent frames is technically mis-matched, but you only notice when things 
>move.

        By definition an interlaced screen has a specifically matched Long
and Short frame.  Admittedly a non-interlaced screen has no such property.
It is interlaced screens we are discussing when talking about the fF? No?

>
>It's a common problem for someone familiar with how TV NTSC works to see
>a computer that sends an NTSC signal, and assume that the formats are 
>similar.  You should know better than to trust a standard. :^)
>

        When examining the Amiga display system it is clear that it was
designed to emulate NTSC video, which has it's positive and negative points.
The formats are almost IDENTICAL.  Clearly the intelaced mode coresponds
directly to normal NTSC video.


        My only point in all this is that one possible solution might be
to speed up the frame rate of the Amiga.  If the A3000 were to have the
ability to be put in a special 76hz mode, it could be used with a Multi-
Sync monitor and would provide a 38hz interlaced mode, whicl would probably
appear flickerless to over 40% of the population in normal viewing conditions
(supposedly at 40hz 50% of the pop notices no flicker, the visual LD50 :^)).
What would be even better would be adjustability.

        Of course, I think refreshed displays are a soon-to-be thing of the
past (a couple of years), so new display issues will probably hit us before
the A3000 does :^).

        In the meantime, imperfect as it is, the flickerFixer is the only game
in town.


                                                                Thanks

                                                                        Wade.

UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COM
Opionions expressed are mine, and not necessarily those of my employer.