Copper timings and AGA fetch modes

[earok]

From my understanding, on OCS you can do:

1. Two operations per 16 pixels on 4BP
2. Alternating 1/2 operations per 16 pixels on 5BP
3. One operation per 16 pixels on 6BP

I found that enabling AGA fetch mode seems to have different timings - eg, it appears to be that 6BP with fetch mode 1 is similar to 5BP on OCS. Is there a guide on what timings can be expected on different combinations of fetch mode vs number of bitplanes?

[ross]

Hi earok,
https://eab.abime.net/showpost.php?p...65&postcount=2

EDIT:
Better if I explode the view to make it clear, with some example:

x1: $38     $40      $48      $50      $58
    xxxxxxxx|xxxxxxxx|xxxxxxxx|xxxxxxxx|

4 bplanes:
M4V2M3V1|xxxxxxxx|xxxxxxxx|xxxxxxxx|
-> 2 CMOVE /8cycles
5 bplanes:
M4V2M351|V4M2V351|xxxxxxxx|xxxxxxxx|
-> 3 CMOVE /16cycles
6 bplanes:
M462V351|M462V351|xxxxxxxx|xxxxxxxx|
-> 2 CMOVE /16cycles

For the other fetch widths is the same but only for the parts where the DMA is active:
[usually the copper performs a fetch every other cycle]

x2: $38     $40      $48      $50      $58
    xxxxxxxx|        |xxxxxxxx|        |
x4: $38     $40      $48      $50      $58
    xxxxxxxx|        |        |        |

This means that with 8bpls active you can have areas in which, even with FMODE = 4x, you cannot move values with copper.

[earok]

Thank you!

I don't quite understand it.. I unless I've done something really odd, I seem to be getting an alternating 1/2 moves per 16 pixels on 6BP with fetchmode 1, rather than 2 per 16 pixels?

[ross]

Originally Posted by earok

Thank you!

I don't quite understand it.. I unless I've done something really odd, I seem to be getting an alternating 1/2 moves per 16 pixels on 6BP with fetchmode 1, rather than 2 per 16 pixels?

Not 2 CMOVE every 16 pixels, every 16 (DMA) cycles (32 lo-res pixels).
This mean you can change, for example COLOR00 every 16 pixel (unlike when you have 4 bpl when you can change COLOR00 every 8 pixels).
Alternating seems 5 bpls...

[roondar]

Yeah, for OCS/ECS it is

• <=4 BPL: 1 Copper Move every 8 pixels
• 5 BPL: 1 Copper Move every 12 pixels
• 6 BPL: 1 Copper Move every 16 pixels

Note that this is the same as what Ross is saying, but converted into number of Copper Moves instead. His way of using DMA cycles is more accurate though, as WAITS take 3 Copper cycles rather than the 2 a MOVE do.

[ross]

Perhaps the best thing to do is to post the operations with the copper you do on a video line, then I translate it for you into DMA cycles operations (thinking per pixel could be confusing).

[earok]

Apologies, the image is rough and ugly here, I just wanted to do a quick demonstration of what I'm seeing.

I've just hacked a sprite parallax routine to toggle color00 rather than sprite positions. The only difference between the two screenshots is I toggled the FMODE (via editing the copperlist in the debugger).



Same number of bitplanes (6), with fetchmode 1 it has alternating 8/16 sizes but with fetchmode 0 it's a constant width.

[ross]

Because you move from this situation:

x1: $38     $40      $48      $50      $58
    M462V351|M462V351|M462V351|M462V351|

to this:

x2: $38     $40      $48      $50      $58
    M462V351|M0V0M0V0|M462V351|M0V0M0V0|

Of course it depends on where your initial CWAIT is and you may have the colors 'shifted'.

[earok]

Originally Posted by ross

Because you move from this situation:

x1: $38     $40      $48      $50      $58
    M462V351|M462V351|M462V351|M462V351|

to this:

x2: $38     $40      $48      $50      $58
    M462V351|M0V0M0V0|M462V351|M0V0M0V0|

OH.. ahh.. I'm a dummy, I thought 1x meant fetchmode 1 and 2x meant fetchmode 2 etc.. not multiples of 16x.. whoops..

[ross]

Originally Posted by earok

OH.. ahh.. I'm a dummy, I thought 1x meant fetchmode 1 and 2x meant fetchmode 2 etc.. not multiples of 16x.. whoops..

Yep, x1 -> the base 16 bits DMA width, x2 -> 32 bits, x4 -> 64 bits.
For that I said that it is better to think in DMA cycles (regardless of how many bits fetched) otherwise can be confusing.