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.