Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!harvard!panda!genrad!decvax!mcnc!ncsu!uvacs!edison!dca
From: dca@edison.UUCP (David C. Albrecht)
Newsgroups: net.micro.amiga
Subject: flicker
Message-ID: <829@edison.UUCP>
Date: Fri, 25-Jul-86 13:57:09 EDT
Article-I.D.: edison.829
Posted: Fri Jul 25 13:57:09 1986
Date-Received: Sat, 26-Jul-86 22:00:30 EDT
Organization: General Electric Company, Charlottesville, VA
Lines: 97

I have had my Amiga since May and in general I am pretty happy
with it.  I do find the flicker in high-res annoying about
and I would have been much happier if they had based the OS on
UNIX (a mini version of course) instead of yet another half-assed dos.
I'm also not too impressed that every
piece of software I have bought so far (except Lattice C)
is copy protected so installing them in a RAM disk or
putting them on a hard disk is not an option.

Well, all of this is pretty much water over the bridge.  The
flicker problem is annoying because most software I have
seen ignores the high-res mode.  The ones that don't ignore
it ala. dpaint don't use it to any great degree (they don't
supply and I have yet to see a high-res painting).
I'm interested in doing a feasability study on circuitry
to suppress the flicker.  I am not an electronics
expert by any means but I have enough knowledge to at least
not be too intimidated.

I realise one solution to the problem is a high persistence
phosphor monitor but as they are quite expensive a circuit
approach might be just as cost effective and possibly have
other benefits such as a possibility of reducing the load
on the processor.  Also, prices on monitors have been
dropping relatively slowly compared to prices on semi-conductors
thus a circuit solution can't help but look even better
as time goes by.

As I understand it the flicker is caused by the interlaced
display which updates alternate scan lines at a 1/60 sec rate
with a total update at a 1/30 sec rate.  With high contrast
material this causes noticable flicker.  As the memory is
running flat out during the display period just doing screen
updates processor cycles have to slip through the cracks.
Therefore, a 1/60 non-interlaced display rate would require not
only a faster graphics chip but also faster memory.

It seems that one solution is a scan converter which
will change the interlaced mode to a non-interlaced mode that
updates at the required 1/60 of sec.  As I still have some
warranty left on my machine, I am not prepared to open it up
so have been left to reading the Hardware reference manual
which doesn't get down to the nuts and bolts level.

From my reading, however, I noticed that one of the custom
chips has 3 4-bit (R-G-B) outputs.  My surmise at this point
is that these outputs are the results of the video sweep.
I would expect that these outputs then travel to the
monitor drive circuitry.  It should be possible
to capture this output in video DRAMs ala. the TI dual
port chip and save an entire screen (both scans).
Mind you, we are not talking a small
amount of memory, I figure in the 200K bytes neighborhood
(Horz res * Lines on screen * 12 bits plus some for overscan).
As I understand it the NTSC can't accept a
1/60 sec full screen sweep so the capture (of the interlaced)
and re-insertion point (of the non-interlaced) signal would
have to be in the RGB circuitry.  The $64,000 question is if
I break the link in the RGB circuitry and somehow arrange that
it re-injects a non-interlaced 1/60sec update sweep from the
serial port on the Video rams; does the output network have the
capability to accept what is effectively a doubling in output bandwidth
(especially the RGB D/As)?  If we get a 1/60sec full screen
update does the Amiga monitor have the bandwidth to accept it?

Rather than completely wasting the redundancy of this double
buffering for only flicker filtering it would be very desirable
if it could serve duty to offload the Amiga somewhat.
Given that I could suppress the Amiga's video sweep somehow from
add on circuitry (a feat I don't know is possible or desirable
given that it might upset timing based on the screen sweep),
best would be if I could suppress the Amiga video sweep until
a change was affected in the screen contents.  It is highly
unlikely, however, that I can capture this information.
More likely to be feasible is to suppress the Amiga's sweep
for some time period.  A convenient time period measure is
the number of screen cycles.  A counter on the add on
circuitry could suppress the video update for a variable number
of screen cycles.  In other words, I would delay a display update from
actually reaching the screen by some multiple of 1/60 of a sec and
in return would get less load on the Amiga's memory.
If possible I would want the number of cycles to suppress the
video sweep to be a register just like the ones in the custom
VLSI and accessable as such.  Hopefully, setting the register
would be ignored on a 'stock' Amiga. In this way an application
could vary the amount of cycles available to the
processor versa how fast a feedback response is needed from the screen.
To maintain compatibility with an NTSC output an externally accessable
switch keeping the board from disabling the video sweep despite the
counter register setting would also be handy.

All this is just speculation but I am interested in the input of
those more knowledgeable on electronics, video drivers, and amiga
software/hardware in adding their two cents as to feasability, implementation,
and possible alternate approaches.

David Albrecht