Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!wuarchive!zaphod.mps.ohio-state.edu!ncar!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: More extended graphics on the IIgs
Message-ID: <14955@smoke.brl.mil>
Date: 24 Jan 91 00:08:07 GMT
References: <1991Jan21.235524.1@gacvx1.gac.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 16

In article <1991Jan21.235524.1@gacvx1.gac.edu> youngdahl@gacvx1.gac.edu writes:
>Ok... now I get the idea that everyone agrees that by alternating pallettes and
>partial scan lines we could achieve a very flickering illusion of 32 colors on
>a scan line.  Now, a few questions:
>If the screen refesh rate was 1/30th of a second, how much would this flicker? 
>I've seen an Amiga in interlace mode many a time.  Would this flicker more than
>an Amiga flickers in interlace mode on a cheap monitor?
>How about the number of scanlines that could be completely rewritten before the
>screen catches up to it on a standard IIgs? 

I don't quite understand why you ask this.  The 3200-color demos manage to
keep the SCBs updated (barely) faster than the scanning rate.  "Flicker"
as you call it (usually called "tearing") would occur only if you couldn't
update the SCBs fast enough.  Obviously if you set up a backing array for
the SCB data, it could be rolled into the actual SCBs at a sufficient rate
to keep up with display scanning.