Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!oliveb!amiga!jimm
From: jimm@amiga.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga
Subject: Re: Screen goes black
Message-ID: <1971@amiga.amiga.UUCP>
Date: 10 Dec 87 19:27:11 GMT
Reply-To: jimm@amiga.UUCP (Jim Mackraz)
Organization: Commodore-Amiga Inc., 16795 Lark Ave. Suite 106, Los Gatos CA 95030
Lines: 76

[forgive that this is not a true rn followup]

Wade asks what LoadView does ...
Leo says: "It updates GfxBase, then stuffs some registers in the chips."

This isn't too educational.

The main content of a view is/are ready-to-go Copper List(s), which
result from MgrCop.  LoadView() primarily puts the address of these
Copper Lists into the  fields in GfxBase from which GfxBase will
initialize the Copper during vertical blank.  That's right, even though
the hardware seems to have the capability to restart the coppers itself,
it is in fact done through software--the graphics Vblank interrupt handler.

LoadView() was augmented in 1.2 to set the top margin color to the
background color of the TOP screen, instead of leaving it the background
color of the bottommost visible screen (remember that ugly?).

This latter is done by looking down the View's viewport list, but isn't a
big performance hit.

SO: you cannot get away with stuffing the hardware copper registers without
also inhibiting gfx vblank from putting back the copper lists stored in
GfxBase.  Better way to go, however is to use LoadView to install your new
copper lists.  The effect of displaying the new view will then occur 
after the very next vertical blank.  This is a cleaner change than 
when one tries ScrollVPort() (which is a copper list Poke).

You do not need the copper generated interrupt to do the voodoo, but such
an interrupt is invaluable in notifying your program (send a signal to your-
self from the copper interrupt handler) that BOTTOM of frame has occured, so
it is now safe to render in the buffer which you have just set up to be
"offscreen".

I think the optimal way to behave is this ....
	...
	Draw in offscreen view's raster
		(call it rasterA, so rasterB is now onscreen)
	LoadView
		(rasterA will be displayed onscreen after next vblank)
	Tell your copper int handler to send you a signal next Bottom of Frame.
		(set a global, perhaps)
	Perform any calculations needed for the next view
		(while the beam finishes tracing rasterB)
	Wait for the signal
		(if BOF has occured already, your signal will be pending,
		 and your task won't even be switched out)
	Draw in rasterB ....
	repeat 

Note that this wastes minimal time in a couple ways.
1) You perform calculations in the "dead time" while the beam finishes
scanning rasterB.  If you have minimal calculation (such as with an ANIM
playback), you might want to bag this, and try a beam synchronization 
scheme.

2) You don't wait for Top of Frame before rendering in rasterB, so you
get to use that most valuable vblank period when the processor and blitter
don't get compromised by the display dma.

plus 3) You don't spin wait for the bottom of frame (which WaitBOF() does
in 1.2) which really only effects multi-tasking, I think.  This way,
all you need to do to go wild is crank your priority up, not take over
the machine or Forbid().

Since I've been posting this scheme for several months, but never actually
coded it up, maybe someone can send me an example or tell me how wonderful
it really is in practice.

	jimm

-- 
	Jim Mackraz, I and I Computing	  
	amiga!jimm	BIX:jmackraz
Opinions are my own.  Comments regarding the Amiga operating system, and
all others, are NOT to be taken as Commodore official policy.