copper execution time

[Rock'n Roll]

I have found following information about execution time here:
https://eab.abime.net/showthread.php?t=66483
some elsewhere.

no bitplane or up to 4 bitplanes:
wait ... ; 3 copper cycles => 6 CCKs = 12 pixel
move ... ; 2 copper cycle => 4 CCKs = 8 pixel
skip ... ; 3 copper cycles => 6 CCKs = 12 pixel ; without jump
skip ... ; 5 copper cycles => 10 CCKs = 20 pixel ; with jump

5 bitplanes:
wait ... ; 4 copper cycles => 8 CCKs = 16 pixel
move ... ; 3 copper cycle => 6 CCKs = 12 pixel

6 bitplanes
wait ... ; 6 copper cycles => 12 CCKs = 24 pixel
move ... ; 4 copper cycle => 8 CCKs = 16 pixel

Now my questions:
1. What means copper cycle?
2. Are the values in my table correct?

If I tested this, I get some what I'm not expected.
Ok, the move dc.w $180,$444 is 4 CCKs ($34 to $37), but why on $34 and not on $30?

The next the wait-command dc.w $3033,$fffe needs 8 CCKs from $38 to $3F.
Also the next from $40 to $47. One wait is with and one wait is without bitplane.
Only one bitplane is activ. I would expected the next wait-command follows after 6 CCKs.


Thats my short piece of copperlist.

dc.w	$3031,$fffe
	dc.w	$180,$444
	dc.w	$3033,$fffe
	dc.w	$3035,$fffe
	dc.w	$ffff,$fffe	; end of copperlist

>v $30 $30
Line: 30  48 HPOS 30  48:
 [30  48]  [31  49]  [32  50]  [33  51]  [34  52]  [35  53]  [36  54]  [37  55]
                                         COP  08C            COP  180
                                             0180                0444
                                         00071808            0007180A
 99E1BC00  99E1BE00  99E1C000  99E1C200  99E1C400  99E1C600  99E1C800  99E1CA00

 [38  56]  [39  57]  [3A  58]  [3B  59]  [3C  60]  [3D  61]  [3E  62]  [3F  63]
 COP  08C            COP  08C
 0   3033                FFFE
 0007180C            0007180C
 99E1CC00  99E1CE00  99E1D000  99E1D200  99E1D400  99E1D600  99E1D800  99E1DA00

 [40  64]  [41  65]  [42  66]  [43  67]  [44  68]  [45  69]  [46  70]  [47  71]
 COP  08C            COP  08C  BPL1 110
     3035                FFFE      8000
 00071810            00071810  0006F020
 99E1DC00  99E1DE00  99E1E000  99E1E200  99E1E400  99E1E600  99E1E800  99E1EA00

 [48  72]  [49  73]  [4A  74]  [4B  75]  [4C  76]  [4D  77]  [4E  78]  [4F  79]
 COP  08C            COP  08C  BPL1 110
     FFFF                FFFE      8000
 00071814            00071814  0006F022
 99E1EC00  99E1EE00  99E1F000  99E1F200  99E1F400  99E1F600  99E1F800  99E1FA00

[paraj]

Hopefully not too wrong info below (I'm sure people will correct me otherwise )

1. What means copper cycle?

Copper cycle: Cycles where copper can use the bus (no higher priority access, i.e. bitplane). Per HRM:

The Copper is a two-cycle processor that requests the bus only during
odd-numbered memory cycles. This prevents collision with audio, disk,
refresh, sprites, and most low resolution display DMA access, all of which
use only the even-numbered memory cycles.

(odd-numbered means 1st, 3rd etc. = $00, $02, ....).

No other bus usage means copper cycles every other CCK.

If more than 4 lo-res bitplanes are enabled you need to look at the DMA cycle allocation diagram to figure out whether the copper operation will take more CCKs. Outside display area you're usually fine (there are some quirks at the very end/beginning of scalines).

2. Are the values in my table correct?

Skip and wait take the same time, jumps are a separate thing. If I'm reading/remembering correctly 5 bpls steal one copper cycles and 6 steals two per 8 CCKs so your numbers look OK for that (in the display area).

If I tested this, I get some what I'm not expected.
Ok, the move dc.w $180,$444 is 4 CCKs ($34 to $37), but why on $34 and not on $30?

I think Toni renumbered the DMA debug output for 4.9.0 (I guess to better match Agnus?), if you check in 4.4.0 they're more in line with what you're expecting (there a 'W' is also displayed to show where the copper wakes up).

The next the wait-command dc.w $3033,$fffe needs 8 CCKs from $38 to $3F.
Also the next from $40 to $47. One wait is with and one wait is without bitplane.
Only one bitplane is activ. I would expected the next wait-command follows after 6 CCKs.

After your first wait the copper is behind and all waits finish ASAP. I can't find it now, but it was probably in the "Undocumented Amiga hardware stuff" thread, basically copper needs a free cycle (available for CPU/blitter) after waking up, so each of the waits end up taking 8 CCKs (3 normal cycles: 2 to read copper instructions, 1 for wait to finish and one "wasted").

[Toni Wilen]

Copper WAIT cycle is:

<IR1> <IR2> <sleep start> (sleeping) <wakeup> (next instruction's IR1 fetch). Real total is 4 copper cycles. Internally wakeup cycle generates request for IR1 (due to pipelining IR1 DMA transfer happens in next copper cycle) so technically you could also say WAIT is 3 cycles even if it isn't the whole truth

Horizontal cycle origin was changed in 4.5+ betas. It was wrong previously. First refresh cycle is cycle 3. It is not cycle "-1". HRM lies. DDFSTRT does not equal first bitplane slot. When DDFSTRT matches horizontal position, it takes 4 cycles more before first bitplane slot is selected (plane 8) because bitplane enable has multiple stages and internal RGA bus is pipelined.

btw, W is back in DMA debugger, it was accidentally moved to wrong place when copper emulation was rewritten few times..

[Rock'n Roll]

Thank's for the answer.
I see the different results between 4.4 and 4.9

First to the wait-command:

The wait-command needs for me now 4 copper-cycles or 8 CCKs.

"so each of the waits end up taking 8 CCKs
(3 normal cycles: 2 to read copper instructions, 1 for wait to finish and one "wasted")."

[38  56]  [39  57]  [3A  58]  [3B  59]  [3C  60]  [3D  61]  [3E  62]  [3F  63]		
 COP  08C            COP  08C
 0   3033                FFFE								  W	
 0007180C            0007180C
 99E1CC00  99E1CE00  99E1D000  99E1D200  99E1D400  99E1D600  99E1D800  99E1DA00

; <IR1> <IR2> <sleep start> (sleeping) <wakeup> (next instruction's IR1 fetch).

$38 - IR1 (fetch) ; copper-cyle 1
$3A - IR2 ; copper-cyle 2
$3C - sleep start ; copper-cyle 3 - wasted - First refresh cycle is cycle 3
$3E - wakeup ; copper-cyle 4
then
$40 - IR1 (fetch) again ; copper-cyle 1


2. bitplane-DDFSTRT:

DDFSTRT does not equal first bitplane slot. When DDFSTRT matches horizontal position,
it takes 4 cycles more before first bitplane slot is selected (plane 8) because
bitplane enable has multiple stages and internal RGA bus is pipelined.

DDFSTRT on $38
 [38  56]  [39  57]  [3A  58]  [3B  59]  [3C  60]  [3D  61]  [3E  62]  [3F  63]	
    1 	       2	 3	   4	     -	    BPL4      BPL6	BPL2
  (free)               (free)		   (free)            (steal)

 99E1CC00  99E1CE00  99E1D000  99E1D200  99E1D400  99E1D600  99E1D800  99E1DA00

 [40  64]  [41  65]  [42  66]  [43  67]  [44  68]  [45  69]  [46  70]  [47  71]
 COP  08C   BPL3      BPL5	BPL1 
  (free)	      (steal)

Is my interpretation correct?


3. move-command:

[30  48]  [31  49]  [32  50]  [33  51]  [34  52]  [35  53]  [36  54]  [37  55]
                                         COP  08C            COP  180
                                             0180                0444
                                         00071808            0007180A
 99E1BC00  99E1BE00  99E1C000  99E1C200  99E1C400  99E1C600  99E1C800  99E1CA00

But why starts the copper-move on $34 and not on $30 by a wait on dc.w $3031,$fffe?
All following copper-moves have two copper cycles. Only the first one not.
(It's also a different between 4.4 and 4.9)

[38  56]  [39  57]  [3A  58]  [3B  59]  [3C  60]  [3D  61]  [3E  62]  [3F  63]
 COP  08C            COP  180            COP  08C            COP  180
 0   0180                0555                0180                0666
 00073F44            00073F46            00073F48            00073F4A
 EEAA2400  EEAA2600  EEAA2800  EEAA2A00  EEAA2C00  EEAA2E00  EEAA3000  EEAA3200

[Toni Wilen]

Originally Posted by Rock'n Roll

Is my interpretation correct?

Yes.

But why starts the copper-move on $34 and not on $30 by a wait on dc.w $3031,$fffe?

Copper comparison matches first, then in next cycle DMA request is generated. Finally following cycle reads next instruction word.

Some copper delays were wrong in 4.4 (and earlier), because it fixed some programs but actual problem was something else..

[paraj]

Great info Toni I didn't mean to imply that 4.4 was better/more correct only mentioned it because it can be easier to match up with the HRM cycle diagram when you're first trying to make sense of everything (should have made that clearer in my initial response)

[Rock'n Roll]

Yes, thanks Toni. This information closed the lack of clarity.