[net.micro.amiga] Question on user copper lists

cc1@locus.ucla.edu (UCLA Computer Club) (09/17/86)

Must user copper lists be sorted when given? I.e. Can I say:
move to mid screen 
make these changes
move to top screen
make more changes
move to bottom
make changes
move to middle
make changes

end

and expect the system to sort this into 'move top, move middle, move bottom'
for me? 

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).

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)
or that the color changes take 2 lines between v-ports to do? (i.e. Is there
time?)
      Views expressed here may not be those of the Computer Club, UCLA, or
  anyone in their left OR right mind.  And that's the name o' that tune.

dale@amiga.UUCP (Dale Luck) (09/23/86)

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.