From: peter@cbmvax.commodore.com (Peter Cherna)
Newsgroups: comp.sys.amiga.hardware,comp.sys.amiga.programmer
Subject: Re: How does 3.0 do the flickerfixer stuff?
Date: 16 Oct 92 14:24:30 GMT
Reply-To: peter@cbmvax.commodore.com (Peter Cherna)
Organization: Commodore-Amiga, Inc.  West Chester, PA.

In article <dej.01tj@qpoint.ocunix.on.ca> dej@qpoint.ocunix.on.ca (David Jones) writes:
>1. Take over machine and bang hardware directly
>
>   I would not expect the DoubleXXX modes to cut in here.

Exactly right.  Particularly acute is the fact that interlaced screens
would have two copper lists, but if we made a non-interlaced screen
automagically, it would only have one.  Not only that, but in many
cases the take-over-machine program doesn't leave an OS around
to intervene, so promotion here is basically impossible.

>2. Use intuition.library/OpenScreen(), etc.
>
>   Intuition is the easiest way to create a display provided that you
>   are willing to abide by its restrictions.  (Most programs can and
>   do.)  The display mode is determined by at most a single long word.
>   (Parameters such as overscan are secondary and do not affect the
>   basic display mode used.)
>   
>   I would expect Intuition to automatically convert requests for
>   certain screen modes to AGA modes.  This promotion would occur
>   regardless of whether OpenScreenTagList() or just OpenScreen()
>   were used.

This is indeed correct.  If the "Promotion" option is selected, then
_most_ screens opened through Intuition are promoted to flicker-free
equivalents.  This includes ALL 1.3 callers to OpenScreen().  (Some
self-styled experts claimed that no 1.3 callers are promoted, but
they are incorrect).  Under 2.0 and OpenScreenTagList(), you can request
any display ID available.  Graphics library has a place (the graphics
database) where you can find out what's available.  It was possible
to write an application under 2.0 (without knowing about 3.0 and AGA)
that would take advantage of the new modes, including the double-NTSC
ones!  That is because the list of "what's available" has grown to
include the double-NTSC and double-PAL modes.   Any application that asks
for a mode of the "default" monitor (which used to be either PAL or NTSC)
now gets double-PAL or double-NTSC when promotion is turned on.

Using 2.0 methods, an application can also request PAL or NTSC _explicitly_.
We chose not to promote such applications.  There needs to be a way for
an application to say "never ever promote me, because I'm talking to an
NTSC device". Certain video-enhancment products (eg. DCTV) would need
this feature.  DPaint is one significant application which requests PAL
or NTSC explicitly, so it ends up not promoted, even though you might
wish it was.

It would be simple to patch OpenScreenTagList() to promote applications
such as DPaint (which are doing something perfectly legal, by the way).
However, that doesn't make it appropriate to include equivalent code
in the OS, since promoting DPaint would have negative effects on other
titles.  I would expect some programmer to release such a patch in the very
near future, but it would have to be used "with care", which is to say
the user needs to know to remove the patch before running some application
that (for whatever reason) can't function with the patch in place.

>3. Use graphics.library.
>
>   This is partway between 2 and 1.  In effect, you still need to make
>   copper lists.  However, these lists are constructed by the OS.

It would be too much funky voodoo to magically promote folks who go
directly to views and viewports at the graphics level.  Applications
that do so tend to include the group which (necessarily or otherwise)
gets the most intimate with its display.  This is the group that
can't in general be successfully promoted "by magic", because they
are making deep assumptions about the form of their environment.

Fully 2.0-aware applications could use graphics.library to get their
own views and viewports, and have some success with the new modes
automatically.

Now, here's a bit of background on what promotion does.

First, a hardware de-interlacer such as is found in the A3000, A2320,
or other 3rd party products sits on the video output and weaves its
magic there.  As such, it is transparent to software, since the
core of system itself is not involved.  Such hardware is expensive
(it constitutes a significant chunk of the price of an A3000, for example).

De-interlacing through a combination of the OS and the AGA chipset
_does_ affect the system's nature, so compatibility is more tricky.
We've tried to choose the best tradeoff between compatibility and
number of things promoted.  The first thing is there is a whole
category of stuff that _cannot_ be promoted in this manner, no matter
how hard we try (eg take-over the machine games).  Second, we tried
to promote most other programs without breaking (m)any of them.

What the OS does is remap the default monitor (say NTSC) to the
best matching double-scanned (say double-NTSC) modes.  For example,
640x400 interlaced NTSC is mapped to a 640x400 single-field (non-lace)
~60Hz display.  Requesting one magically gives you the other.
What the hardware is doing here is providing the ability to display
640x400 flicker-free in up to 8 planes, which is good enough to cover
all ECS 640x400 modes.

Now there's an additional aspect to be solved for non-interlaced modes.
consider a 320x200 screen.  To promote this to 31 kHz would yield
a 320x200 screen which only filled half the height of the monitor,
because each 31 kHz screen has on the order of 400-480 lines.  It
would be very difficult for software to arrange to double the height,
so AGA has a feature called "scan-doubling", where the chips themselves
can be told to output each scan line twice.  In this case, not only
are the chips providing the deep flicker-free displays, but they're
being used to double each scan-line, to preserve aspect.

>With that out of the way, an explanation from one of the OS engineers
>at C= as to how much of the above is accurate would be greatly appreciated
>and would go far towards dispelling the BS that seems to be accumulating
>around here.

Your analysis is very much on track.  I hope my comments clarify any
additional areas.  Feel free to spread the Truth.

> David Jones, 6730 Tooney Drive, Orleans, Ontario K1C 6R4 CANADA

     Peter
--
Peter Cherna, User Interface Development Group, Commodore-Amiga, Inc.
{uunet|rutgers}!cbmvax!peter    peter@cbmvax.commodore.com
My opinions do not necessarily represent the opinions of my employer.
"I believe it's bad luck to be superstitious."
Newsgroups: comp.sys.amiga.hardware