Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!necntc!ames!ucbcad!zen!hoser.berkeley.edu!bryce
From: bryce@hoser.berkeley.edu.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: Sprites
Message-ID: <4085@zen.berkeley.edu>
Date: Thu, 1-Oct-87 07:33:45 EDT
Article-I.D.: zen.4085
Posted: Thu Oct  1 07:33:45 1987
Date-Received: Sat, 3-Oct-87 03:53:02 EDT
Sender: news@zen.berkeley.edu
Distribution: world
Organization: You want it, we sell it, Inc.
Lines: 70
Keywords: Agnus design, Sprites, DIWSTRT, incoherent ramblings
Summary: Agnus DMA tromps spr0 with DIWSTRT=$1C.  And "DMASTRT"

In article <4094@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>In article <1686@gryphon.CTS.COM> jdow@gryphon.CTS.COM (Joanne Dow) writes:
>>In article <4034@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>>>In article <1659@gryphon.CTS.COM> jdow@gryphon.CTS.COM (Joanne Dow) writes:
>>>
>>>	More egg, Joanne....			:-) :-)
>>>	There is a hardware stop for display DMA at data fetch cycle $18.
>>
>>Your turn for something akin to egg. There may be such a stop; but, I have a
>>program that stomps the mouse cursor. The latest Showanim (4.0) is the guilty
>>party. [ ... ]
>
>	Sigh.  My information came from the mystic DMA timing chart that
>everyone says isn't in the A/W Hardware manual but really is.  There's a
>notation saying that a hardware stop is at cycle $18.

The DMA timing chart came to me as a separate ~40 page stapled addendum.
It is also in the A500/A2000 technical reference manual.

It clearly implies that DMA can't overrun Sprite zero:

"Hardware stop installed here.  Default cannot begin any sooner than cycle
$18.  This allows the user to wipe out most of the sprites if desired...."

The problem is that sprite zero gets nuked when DIWSTRT is $1c!!  This
may be partially due to other effects, but the $18 is not hard and fast.
In fact, it does not seem to be a stop at all.  Just as well.  It would
be circutry that has no actual system value.  (Unlike CDANG which has
a possible use in a protected mode Operating System so the custom chips
don't need to run though the MMU 1/2 :-)  [The Copper ought to be able
to write to the lower $40 registers when dangerous, though])

It seems a bit strange that the positioning is locked to Agnus DMA
offsets, rather than starting the entire DMA locking "DMASTRT" cycles
after one of the syncs.  That would allow arbitary screen positioning
with no undue sprite loss, since the bitpane DMA would always be backed
up against the last cycle before the next line (and memory refresh).

Even without that mythical register, you can get lots of sprites
even with lots of overscan.  (Register sure would help for high
overscan applications that must be centered, however.)

Working backwards on the "kill list":
Sprite 7
Sprite 6
Sprite 5
Sprite 4
Sprite 3
Sprite 2
Sprite 1
Sprite 0	;Manual implies this is preserved.  Test says no.
Audio 3-0	;Could this be killed also?
Disk 2-0	; "
Refresh 3-0	;Or how about these!!! :-)

GetSprite() ought to be able look DIWSTRT up on a table to determine
what sprites are unusable.  But what about an already allocated sprite?
YankBackSprite() ?? :-) :-) :-)

With 704*464 overscan I still can get all 8 sprites as long as the screen
is shifted a bit too far to the right.

Now the burning question is::  Is it possible to set up a screen such
that not enough refresh DMA happens?  Probably not.

 
|\ /|  . Ack! (NAK, ENQ, SYN)
{o O} . 
 (") 	bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce
  U	How can you go back if you have not yet gone forth?