[comp.sys.amiga.tech] Video, and why fF won't ever work

farren@gethen.UUCP (Michael J. Farren) (04/25/88)

In article <2995@leo.UUCP> harald@leo.UUCP ( Harald Milne) writes:
>In article <890@gethen.UUCP>, farren@gethen.UUCP (Michael J. Farren) writes:
>> Let me put this another way:  in interlaced mode, you are trading off
>> the ability to update the display 60 times per second for the ability
>> to put more lines on the screen.
>
>	Agreed. However interlaced displays have twice the number of lines, and
>therefore twice the amount of information.

Finally, we're getting somewhere.  You are defining "information" as
"visible information on the screen" and I am defining it as "video information
sent to the monitor".  No particular problem there, then.

>	A hi-res interlaced display (640X400) versus a hi-res non-interlaced
>display (640X200) also takes twice the amount of memory. So from interlaced
>to non-interlaced, you lose half the information or more specifically
>pixel data.

Again, an "information" gap.  You could, if you wished, have every other
field in a non-interlaced display an entirely different bitmap.  Done
cleverly, this can produce nifty effects.  Done badly, your head will
explode.  Talk about flicker!

>	The number fields are the same, but the amount of information is not.
>Actually, in the context of non-interlaced displays, the term fields doesn't
>make sense any more. It takes 2 60hz odd/even fields to put together a
>30hz NTSC RS170A video frame.

Well, the difference is simply that there are no even fields in a non-
interlaced display - all 60 fields are odd.

>So, in a 30hz time frame, you get the same information twice.

Usually, but not always.  It is possible, as described above, to get
different information, overlaid.

>In an interlaced display, you get two different fields. You also get these
>fields interspersed in such a way, they "fill" in a 30hz time period.

True.

>	Unfortunately, on short persistance monitors, this also creates
>flicker. I even get flicker watching LaserDisks on a high resolution
>monitor. So, it's not just an affliction unique to the Amiga. It's the 
>NTSC standard.

I get flicker on a normal TV, if I look closely.  NTSC sucks, eh?

>> Vertical sync timing differs between the two, and that is the ONLY
>> difference. 
>
>	Vertical sync can't possibly be different. Look at what you said
>previously. 60 fields a second. These fields are separated by a vertical
>sync pulse. It's the only way you can start a new "field".

No.  The way interlace WORKS in a standard monitor is by varying the
vertical sync signal.  The vertical sync has, superimposed over it,
the horizontal sync, resulting in a signal that looks something like
this:

---   ----------------   ----------------   ----------------
  |   |              |   |              |   |              |
  |   |              |   |              |   |              |
  -----              -----              -----              -------------

The horizontal oscillator is locked to the horizontal sync, even during
vertical sync (retrace).  An odd field's vertical sync signal will end
exactly at the horizontal sync time, so the line will start at the extreme
left-hand side of the screen.  An even field's vertical sync, however,
ends 1/2 of the horizontal sync interval later than an odd field's.  The
result is a horizontal line which starts halfway into the screen, but
otherwise synchronized with the vertical rate.  Since the vertical scan
of the screen is a linear function (those lines aren't really straight,
they slant downwards as they scan to the right - you can see an emphasized
version of this if you turn your brightness way up, and are able to see
the retrace lines slanting upwards as the beam moves to the top of the
screen) the result is that the even field's lines are drawn 1/2 line
further down the screen than the odd field's lines were, thus producing
interlace.

This, by the way, is part of the reason that a fixed fF is a harder job
than it first appears - detecting the difference between even and odd
fields is NOT an easy task once you get away from the original circuitry
that generated them.  A monitor doesn't care about even and odd - it's
just displaying the lines as they come in, in a manner dictated by the
timing.  This is why you CANNOT get a monitor to "swap" the lines in
interlaced mode - they will ALWAYS be rendered correctly, with odd 
fields first, then even.  If the video slot does not have a signal to
indicate which field is currently being displayed, you're going to 
have to determine that from the vertical sync differences only, which
is about a 30 microsecond difference.  Not impossible, but hard to
do reliably.  (Come to think of it, how DOES the fF do that?  Either
the signal is on the slot, or I'm impressed.)

But, aside from that, there is one very good reason that a fixed
flickerFixer is impossible. (Yes, he said impossible).  Sprites are
NOT displayed at a 30Hz rate - they are displayed at a 60Hz rate.
Sprite update happens EVERY VERTICAL SYNC, so you are going to get
split images if a sprite is moving no matter what you do.  Read the
hardware manual for details - the block diagram of the sprite circuitry
is very clear, and shows no provision for ignoring alternate fields.
If the mouse pointer IS updated at a 30 Hz rate, it is only because the
software does not update it any faster than that.  Other sprites will still
break up, even if you implement the four-field buffer described earlier.

-- 
Michael J. Farren             | "INVESTIGATE your point of view, don't just 
{ucbvax, uunet, hoptoad}!     | dogmatize it!  Reflect on it and re-evaluate
        unisoft!gethen!farren | it.  You may want to change your mind someday."
gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame