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

[Rock'n Roll]

brief summary and some additional questions:

In the Agnus chip (not directly in the Copper) there are five (7) Copper registers 2xCOPxLCx, 2xCOPJMPx and 1xCOPINS.
COPxLCx are fixed location (pointer) registers (or COP1LCH $80, COP1LCL $82, COP2LCH $84, COP2LCL $86)
COPJMPx are strobe registers (or COPJMP1 $88, COPJMP2 $8a)
COPINS is a Copper Dummy Fetch Register (COPINS $8c)

- The Copper has its own Copper Program Counter (COPPTR).
- This is loaded with a COPxLCx address by a strobe signal.
- The strobe signal comes either by writing to COPJMP1/2 or automatically after a vertical blank and then with the address from COP1LCx.
- However, the internal COPPTR is only reloaded if Copper DMA is also activated.
- If Copper DMA is deactivated, this is also referred to as Copper Stop or Copper Halt.
- If Copper DMA is deactivated in the middle of a frame, the internal COPPTR remains frozen until the next time Copper DMA is activated.
The COPPTR then continues its process from there.
- After a vertical blank, the COPPTR is only reset to the COP1LCx address value if Copper DMA is activated.
- The address is initially only prepared by a strobe signal and only written to the internal COPPTR when Copper DMA is activated.
- Before starting from the new address, however, a call is made from the old copper address, which is discarded
- the discarded copper instruction is marked with a 'C' in the DMA debugger

e.g. if Copper DMA remains activated, vertical blank, Copper instruction of 10560 is discarded. 'C'
(Sequence at VB+COPEN start: COPINS (old) COPINS (new) DEST (new))

>v 0 0
Line: 00   0 HPOS 00   0:
 [00 1BE -]   [01 1C0 -]   [02 1C2 -]   [03 1C4 -]   [04 1C6 -]   [05 002 -]   [06 004 -]   [07 006 -]
                                        RFS0   03A   COP    08C   RFS1   1FE   COP    08C   RFS2   1FE
                                                *B    C    0002                      00E0
                                          00065910     00010560     00065912     00010520     00065914

                                         188   12C    0B0   082    189   12C    090   082    18A   12C

or if Copper DMA is activated in the middle of the frame, Copper instruction of 10518 is discarded. 'C'

[28 048 -]   [29 04A -] M [2A 04C -]   [2B 04E -]   [2C 050 -]   [2D 052 -]   [2E 054 -]   [2F 056 -]
    CPU-RWI              O COP    08C      CPU-RWI   COP    08C      CPU-RWI   COP    180      CPU-RWI
       0001              V  C    0002         0508         0180         0080         00F0         3D7C	
   0002115E              E   00010518     00021160     00010510     00021162     00010512     00021164

  1AF   008                 08C   082    1B0   008    088   082    1B1   008    089   082    1B2   008

Questions:
1. what is the meaning of the 'C' in the discarded copper call? Cleared?
2. it takes 3 to 5 bus cycles from the activation of Copper DMA to the first valid Copper call? What are the rules here?
3. What are the rules at the end of the scan line? If I remember correctly there are special rules for COPJMPx at the end of the scan line.
4. if a Copper Jump is executed in the middle of the frame with Copper DMA enabled, two Copper DMA fetches are discarded, but only one is marked as 'C'?
Ex. 1A and 1C discarded, but only 1C has 'C' mark.

[10 018 -]   [11 01A -]   [12 01C -]   [13 01E -]   [14 020 -]   [15 022 -]   [16 024 -]   [17 026 -]
 COP    080                COP    08C                COP    082                COP    08C
       0001                      0082                      051C                      008A
   00010512                  00010514                  00010516                  00010518

  089   082                 08A   082                 08B   082                 08C   082

 [18 028 -]   [19 02A -]   [1A 02C -]   [1B 02E -]   [1C 030 -]   [1D 032 -]   [1E 034 -]   [1F 036 -]
 COP    08A                COP    08C                COP    08C                COP    08C
       0000                      00E0                 C    0002                      008E
   0001051A                  0001051C                  0001051E                  0001052C

  08D   082                 08E   082                 08F   082                 096   082

5. can a simple example code showing the blitter wait bug be shared?
It also reminds me of: https://eab.abime.net/showpost.php?p...2&postcount=20

[Toni Wilen]

1: C was originally (I think) meant to show cycle was allocated for copper that does not do any DMA transfers. Now it also marks cycle when COPxLC -> internal pointer copy happens. It does not really mean anything specific.

2: COPJMPx write -> Copper does new DMA request in next available cycle (This still use old address) -> pointer copy happens when DMA is done in next available cycle for the copper, new DMA request is queued -> read from new address (first part of MOVE cycle).

CPU COPJMPx write causing waiting copper to conflict with blitter:

If CPU does write to COPJMPx during odd cycle, copper sequencer still assumes DMA request is done in next copper cycle (2 CCKs) but because COPJMPx write was odd cycle, DMA addressing logic gets copper's DMA pointer copy request still in 2 CCKs which is not the cycle that copper allocated for the DMA transfer (it is next cycle). And if this cycle is used by lower priority DMA channel (=blitter). DMA addressing logic gets two address pointer select signals at the same time.. If this cycle is unused (or used by CPU), COPJMP sequence works correctly.

There is also another COPJMP related bug: if DMA is off and both strobes are written: New pointer will be COP1LC OR COP2LC when DMA is resumed. (OR as in logical OR operation). This happens because DMA addressing logic gets select signal for both COPLC registers and multiple address register selects = OR operation. (Data conflict in internal RGA bus causes AND operation)

3: There are two side-effects, both only happen when last cycle is even (always if PAL)

PAL last cycle is 226 and next cycle is 0. Which means 2 even cycles back to back. If copper does DMA request at cycle 226, cycle 0 gets allocated by the copper and not used for anything and cycle 2 finally does the DMA transfer. Copper sequencer needs even->odd->even cycle sequence to advance fully.

Except if it is COPJMP which is written during cycle 2226, COPJMP sequence allocates cycle 1 (which is not available for the copper normally but still used for address copy, because cycle is allocated, blitter conflict is not possible), cycle 4 is first part of new MOVE cycle. COPJMP DMA request that normally returns word from old address never happens.

This should be enough for now..

[ross]

4: only 1C is discarded
Copper sequencer (pre-)fetches 1A as a normal opcode.
The Strobe at 18 starts the new COPPTR copper jump sequence (old address fetch to COPINS, COPxLC copy, new COPINS start) after 1A.
For all intents and purposes in that case two fetches are ignored. But if you had written the Strobe with the CPU, in the subsequent cycle the Copper could have potentially completed an instruction.

5: it's possible to write some code for this, Toni explained how to make it happen, so it can be a good exercise.
But I think it is better to specify how NOT to make this happen: wait until the blitter has completed its operations or have the Copper inactive before writing COPJMP with the CPU.
Even better don't use COPJMP at all or only when you know what you're doing (I mean with the CPU, with the Copper do it as you like, no restriction here ).

[NorthWay]

Originally Posted by ross

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

If you halt because of a CDANG violation, what happens next?
Is it reset automatically (TOF?), or can be be reset some other way? Do you need a physical reset from the reset pin?

[paraj]

Originally Posted by NorthWay

If you halt because of a CDANG violation, what happens next?
Is it reset automatically (TOF?), or can be be reset some other way? Do you need a physical reset from the reset pin?

It's restarted on next strobe (maybe there are some corner cases), but you definitely do not need a physical reset
KS3.0/3.1 would be in bad shape if you did. In particular the NULL view has a buggy copper list that relies on the copper halting. So don't restore that view's copperlist without clearing CDANG! (Or you will have mysterious crashes when exiting your demo or temporarily revive the system for example).

[ross]

Originally Posted by paraj

..(maybe there are some corner cases)

Not that I know

@NorthWay: Copper (re-)start at vertical blank is to be considered a strobe.

Originally Posted by paraj

KS..

Yep, KSs completely ignore CDANG, so it's always up to the user to restore the situation.
A bit like BLTPRI which can be dangerous...