Does disabling copper DMA stop the copper?

[Blueberry]

If copper DMA is disabled, and I enable it mid-frame, does the copper continue immediately from where it left off, or does it stay paused until the next vblank (or write to COMJMP)?

Does the behavior perhaps depend on what the copper was doing when DMA was turned off, and/or whether a vblank has happened in the meantime?

[ross]

DMACON bits toggle the DMA channels from 'idle' mode to 'active' mode.
So yes, the Copper simply pause and then continue from where it was.

With one exception, that is, if a new video frame started.
In this case by setting the bit the copper starts from the beginning; or rather, from the address present in COP1LC.

[Blueberry]

I feared as much.

My use case is I want to use all of chip memory for my demo.

If I just disable copper DMA, initialize chip memory, set COP1LC and then enable copper DMA, the copper might execute whatever is now in the place where the system copperlist was. If I wait a frame after setting COP1LC before enabling copper DMA, it might execute my copperlist immediately, rather than waiting for the next vblank as desired.

It seems this requires some dance, like, point COP1LC to an FFFFFFFE longword, wait a frame, point COP1LC to my proper copperlist, then enable copper DMA.

Any ideas for a simpler way to achieve this?

[ross]

Furthermore, since you mentioned COPJMP, it is better to clarify its functioning to avoid unwanted effects (too often in demos its 'abuse' leads to problems, it should be used with caution..).

Copper's Program Counter is internally just one and COP1LC/COP2LC are just buffers that contain values that can be 'pushed' in it.
But in only one case the insertion is automatic (and only for COP1LC), that when a new vblank is happening.

In the remaining cases it can be done manually through COPJMPx, even with active Copper DMA (non in Wait state).
And the latter situation can also lead to video glitches (in the best case scenario) or even a machine crash in particular conditions (there is a description of this case on EAB somewhere, search for Copper Wait/Blitter bug or similar..).

That said, a correct use is to set COP1LC during the frame and let the system automatically insert the value for the next vblank.
In the meantime you can change LCs and stop the Copper as you like

EDIT: I hadn't read your message above yet, but I basically replied to you in this

[ross]

Originally Posted by Blueberry

Any ideas for a simpler way to achieve this?

- stop Copper
- set COP1LC
- fill chip memory
- wait vblank
- enable Copper
- enjoy Blueberry's demo

[Blueberry]

Originally Posted by ross

- stop Copper
- set COP1LC
- fill chip memory
- wait vblank
- enable Copper

As I said, this will start executing my copperlist immediately, i.e. slightly after the vblank (the time from the wait to the enable) rather than at the vblank. I want to avoid this delay.

[ross]

Originally Posted by Blueberry

As I said, this will start executing my copperlist immediately, i.e. slightly after the vblank (the time from the wait to the enable) rather than at the vblank. I want to avoid this delay.

Do you really have a situation where simply waiting for the vblank generates problems for a delayed Copper start?
It's a few cycles at most!
I can't imagine such a case, but I don't know what you want to do with your CPU/Copper code...

EDIT: hmm, maybe you fill the chip memory with Copper Moves? And this need to start exactly at vblank? But why?
I'm curious now

[ross]

I offer you a dirty alternative, but I don't know if you at least have location 0 available.

Usually contains 0*, but you can also put the value $FFFFFFFE and then reset it to 0 at program exit.
Set COP1LC=0 ant COPJMP1 immediately (don't turn off the Copper).
Fill the chip memory as much as you like and then finally set the correct value for Copper PTR.
Then you definitely get what you wanted.

*Copper HALT (it re-start and re-HALT at next vblank)

[Blueberry]

Even if I have no locations available, I can do:

- Put $FFFFFFFE temporarily somewhere and point COP1LC to it.
- Wait for vblank.
- Set correct COP1LC.
- Restore the $FFFFFFFE to what I wanted to have there.

Originally Posted by ross

*Copper HALT (it re-start and re-HALT at next vblank)

Interesting. I thought 0 was a copper no-op (move to dummy address).

[ross]

Originally Posted by Blueberry

Even if I have no locations available, I can do:

- Put $FFFFFFFE temporarily somewhere and point COP1LC to it.
- Wait for vblank.
- Set correct COP1LC.
- Restore the $FFFFFFFE to what I wanted to have there.

Yep, this can work.

Originally Posted by Blueberry

Interesting. I thought 0 was a copper no-op (move to dummy address).

Not only 0, all Copper 'opcodes' that do a Move on 'protected' RGA registers (i.e. the usuals with CDANG=0)