Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!jarthur!nntp-server.caltech.edu!toddpw
From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: More extended graphics on the IIgs
Message-ID: <1991Jan25.022629.25603@nntp-server.caltech.edu>
Date: 25 Jan 91 02:26:29 GMT
References: <1991Jan21.235524.1@gacvx1.gac.edu> <14955@smoke.brl.mil>
Organization: California Institute of Technology, Pasadena
Lines: 31

araftis@polyslo.CalPoly.EDU (Alex Raftis) writes:

>Does it actaully take up _so_ much CPU time.

Yes. SCBs are not the problem, just one byte per line.

Palettes are the problem. 32 bytes per line, every line.

>assembly might be able to rig up some kind of timing to get this to
>work, though I can't see how considering interrupts make software timers
>un-reliable.

Because an interrupt inserts an unknown time delay in between two instructions
whenever one occurs. If you are trying to create a 50 microsecond delay and
you allow interrupts to be serviced, your delay will be a heck of a lot longer
than 50 microseconds if an interrupt occurs in the middle of it.

Example: border color stuff -- suppose I have a program that looks at the
position of the video beam and creates a delay so that a given instruction
will be executed when the video beam reaches a specific position. If an
interrupt comes in and gets control, when it returns the delay subroutine
doesn't know it has happened -- there is no way to correct for the effect
because most interrupts will take longer than the maximum delay you intended
to create -- meaning that you will "miss" your target and the border color
picture will be drawn further down on the screen, and at some random position.

This effect is similar to what happens if you run BGSound with a song and
view something with View3200.

Todd Whitesel
toddpw @ tybalt.caltech.edu