Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!amiga!dale
From: dale@amiga.UUCP (Dale Luck)
Newsgroups: net.micro.amiga
Subject: Re: Question on user copper lists
Message-ID: <1567@amiga.amiga.UUCP>
Date: Tue, 23-Sep-86 03:37:06 EDT
Article-I.D.: amiga.1567
Posted: Tue Sep 23 03:37:06 1986
Date-Received: Tue, 23-Sep-86 07:44:58 EDT
References: <1552@curly.ucla-cs.ARPA>
Reply-To: dale@tooter.UUCP (Dale Luck)
Distribution: net
Organization: Commodore-Amiga Inc., 983 University Ave #D, Los Gatos CA 95030
Lines: 43

In article <1552@curly.ucla-cs.ARPA> writes:
>Must user copper lists be sorted when given? I.e. Can I say:
>move to mid screen 
>make these changes
>move to top screen
NOPE. Each user copper list must be internally sorted top to bottom.
However you may have several user copper lists strung together. MrgCop
will sort/merge them all together. But it is only single pass for
speed.

>Also, how long do copper instructions take to execute? Specifically, can I
>reset the position, source, and color of a sprite while another sprite is
>being displayed? And how accurate is the CMOVE (in low res).
Each copper instruction CMOVE/CWAIT takes 4 cycles to complete. Unless of
course the raster DMA is using those cycles as well (>4 lowres planes)
(>2 hires planes).  The Copper
is an every other cycle state machine. It was designed this way so that
it would not swamp the bus with requests. I believe the CMOVE instruction
in low reas can affect every 8 pixels. You can reset positions/colors/data
of sprite while other sprites are being displayed. The dma for the sprite
occurs at the beginning of every scan line. This leaves the rest of the
line for copper toying.

>
>Finally, before I get into trouble trying it, is there a reason (other than
>simplicity) that the anamation routines will not re-use sprites until the
>entire sprite is displayed (limiting to 8 per line, instead of un-limited)
We felt that the generation of coprocessor instructions would be getting
out of hand. Also it could not guarentee that the sprites would actually
be updated correctly in all modes. We chose this as a good compromise,
providing as much flexibility we could without to much overkill.

>that the color changes take 2 lines between v-ports to do? (i.e. Is there
>time?)
The amount of time it takes to change the colors depends on how many colors
you need to change. 32 colors takes over a scan line. Add the other
bitplane control registers/ptrs and you begin to see why it takes a while
to completely change the display state from one screen to the next.


Dale Luck (Duck)

told ya I'd be back.