Does disabling copper DMA stop the copper?

[ross]

The simplest answer might be that cop1lc to internal copy is done only when DMA is active.

But here I venture with my 'alternative' explanation* (which will be refuted when we have more informations ).

I think it has to do with the absolute first DMA fetch word at the VB (or, as in this case, at the DMA reactivation after VB).
It is not as you might expect the first instruction of the 'new' copper list, but the word following the last of the 'old' one.
So I think what happens is that it is simply used as STROBE (and therefore starts as if it were done manually) from the value present in COP1LC.

The problem is that the address of COPJMP is not present on the RGA but that of COPINS...

EDIT: *no, this cannot be for 'prefetch' reasons
The 'old' word act like the second word after a COPJMP strobe, i.e. suppressed to COPINS destination.

So the simplest answer remains the first: the Copper start require both VB and COPEN -> strobe -> 'standard' COP1LC to COPPTR (and 'usual' 'old' word suppressed to COPINS because of prefetch).

Sequence at VB+COPEN start: COPINS (old) COPINS (new) DEST (new)

[Toni Wilen]

COPJMPx (or indirect via VBLANK) strobe only pre-selects which pointer register to copy. Actual COPxLC to internal pointer register copy requires enabled DMA and execution of COPJMP cycle sequence. Which means last written COPxLC is copied when DMA is re-enabled and copper got few free cycles.

Infamous copper wait blitter bug is related to this (happens when blitter is active, copper is waiting and CPU writes to COPJMPx during odd cycle and blitter also wants the cycle), the copper cycle that does the COPxLC to internal copy gets "stolen" by blitter and DMA addressing logic gets confused causing COPxLC getting copied to selected blitter pointer..

[Blueberry]

Originally Posted by ross

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

I did some testing to make sure I understood this correctly.

AFAICT, a MOVE will halt the copper if (and only if) it attempts to write to a register that is prohibited according to the current setting of CDANG.

Specifically, on ECS and above, when CDANG=1, the copper can access all registers, and thus a MOVE will never halt the copper due to this mechanism, even when writing to register 0.

[ross]

Originally Posted by Blueberry

I did some testing to make sure I understood this correctly.
...

Everything correct.
So if you want to use CHALT for some reason, and that it works on any chipset, it is important to set CDANG=0 first (as it usually is, but better to do it because someone might have changed it before you..).