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