DMA slots on AGA

[mcgeezer]

Hi,

I've been playing around with x4 Fetch mode for bitplanes on AGA and wondered if anyone knows if the same rules that apply on OCS also apply to AGA?

In the HRM the OCS DMA slot allocation is below.

http://amigadev.elowar.com/read/ADCD.../node02D4.html

I was wondering a couple of things?

1) I tried scrolling a 320pixel wide playfield in x4 fetch mode, the only way I could get this to work was by setting DDFSTRT to $18 and losing all sprites.

However as a stop gap I tried also to set DDFSTRT to $28 with DIWSTRT effectively 32 pixels in from the left of the display, this resulted in scrolling stutter probably due to some 64 bit non-alignment - is it possible to use $28 in fetch x4 with working horizontal scrolling, if so under what circumstances?

2) On AGA increasing does increasing the number of bitplanes above 4 have the same effect on performance as it does on AGA? I'm assuming it does but under what circumstances?

I know I should probably learn to use the visual debugger in WinUAE... I think I'll start tonight to see if I can answer these questions myself anyway.

Cheers,
mcgeezer

[roondar]

Originally Posted by mcgeezer

Hi,

I've been playing around with x4 Fetch mode for bitplanes on AGA and wondered if anyone knows if the same rules that apply on OCS also apply to AGA?

Apart from the alignment issues, mostly yes. There are some differences such as needing a total display fetch width that is a multiple of 64 bits in and some trickery with modulos. There was a thread on this recently, but I couldn't find it with a quick check.

In the HRM the OCS DMA slot allocation is below.

http://amigadev.elowar.com/read/ADCD.../node02D4.html

I was wondering a couple of things?

1) I tried scrolling a 320pixel wide playfield in x4 fetch mode, the only way I could get this to work was by setting DDFSTRT to $18 and losing all sprites.

However as a stop gap I tried also to set DDFSTRT to $28 with DIWSTRT effectively 32 pixels in from the left of the display, this resulted in scrolling stutter probably due to some 64 bit non-alignment - is it possible to use $28 in fetch x4 with working horizontal scrolling, if so under what circumstances?

AFAIK you can only do 4x fetch + full screen scrolling by using the $18, but I'm not 100% sure here. Ross made a visual aid once in that thread I can't find anymore that gave a handy overview of where you can place the DDFSTRT values with different fetch modes.

2) On AGA increasing does increasing the number of bitplanes above 4 have the same effect on performance as it does on AGA? I'm assuming it does but under what circumstances?

I'm assuming you mean AGA vs OCS here. So let's go over DMA fetches in AGA real quick. Note: The following is valid for low resolution mode only.

The 4x speed increase is obtained by doing only 1/4th of the normal fetches for the screenmode if it were used under OCS. So, a 320 pixel wide screen in 4 bitplanes would normally require 320/16=20 fetches per scanline (each for 16 bits). Each of these fetches would then deal with 4 bitplanes (=4 slots)*.

For 4x AGA mode, this changes to 5 fetches per scanline (320/16/4=5). Each of these fetches would then get 64 pixels for 4 bitplanes. As you increase number of bitplanes, each of these 5 fetches will deal with more bitplanes.

The upshot is that AGA 4x mode still degrades in performance linearly with number of bitplanes, but that the use of bandwidth is centered around only a few areas of each scanline. This can cause unexpected behaviour, like the Copper skipping a big block of pixels and then returning to 8 pixel intervals. It also means that both the CPU and Blitter are interrupted less often in a scanline.

*) note: I wrote it this way for clarity. Obviously the chip actually does 20*4=80 fetches per scanline in OCS/4BPL lowres and 20 fetches for AGA, but that muddles the explanation somewhat so I grouped them together in the explanation.

I know I should probably learn to use the visual debugger in WinUAE... I think I'll start tonight to see if I can answer these questions myself anyway.

Cheers,
mcgeezer

The debugger is very usefull and shows what I tried to put into words above: in lowres AGA 4x fetch you'll see 5 blue sections in the visual debugger when doing a 320x256x4 display, each with 4 stripes to represent the bitplanes. Do note though that CPU bandwidth to and from memory is not entirely accurate in WinUAE for a basic A1200.

[ross]

Originally Posted by mcgeezer

1) I tried scrolling a 320pixel wide playfield in x4 fetch mode, the only way I could get this to work was by setting DDFSTRT to $18 and losing all sprites.

However as a stop gap I tried also to set DDFSTRT to $28 with DIWSTRT effectively 32 pixels in from the left of the display, this resulted in scrolling stutter probably due to some 64 bit non-alignment - is it possible to use $28 in fetch x4 with working horizontal scrolling, if so under what circumstances?

Yes, you can, losing only sprites 5 to 7. And yes, if you scroll you lose 32 left pixels.
Of course you need a pointer 64bit aligned in memory.
BPLCON1 in no more 'centered' on value 0. This is because the 'zero' value is good only for $18/$38/$58/etc...
Remember also that on AGA there are 256 possible scroll values (4x subpixels).

2) On AGA increasing does increasing the number of bitplanes above 4 have the same effect on performance as it does on AGA? I'm assuming it does but under what circumstances?

Impact on AGA increasing the bitplanes in 4xmode is really moderate.
Imagine having 32 fetch slots in a slice of 64 pixels (which is actually the distance between $18 and $38).
For a bitplane you lose 1 slot, for 2 bitplanes 2 slots, .., for 8 bitplanes 8 slots, therefore even with 8 active bitplanes you have 24 slots available for CPU/Blitter/Copper.
The position of the fetches is different from the 1x (or 2x) modes, they are 'packed', and this can have a light impact on where you synchronize operation with the copper.
The visual DMA debugger will clarify your everything

Cheers!

[roondar]

Originally Posted by ross

Yes, you can, losing only sprites 5 to 7. And yes, if you scroll you lose 32 left pixels.
Of course you need a pointer 64bit aligned in memory.
BPLCON1 in no more 'centered' on value 0. This is because the 'zero' value is good only for $18/$38/$58/etc...
Remember also that on AGA there are 256 possible scroll values (4x subpixels).

So, just for my sanity: in the 4x fetch modes, can you use *any* DDFSTRT position that would be valid for OCS, just with a different 'center point' for BPLCON1?

And would that include OCS style tricks (i.e. one of the "nonvalid" DDFSTRT positions that causes a similar "shift" in BPLCON1 for OCS)?

Impact on AGA increasing the bitplanes in 4xmode is really moderate.
Imagine having 32 fetch slots in a slice of 64 pixels (which is actually the distance between $18 and $38).

Yup, biggest reason for more bitplanes being slower is the extra planes required to blit.

[Toni Wilen]

Originally Posted by roondar

And would that include OCS style tricks (i.e. one of the "nonvalid" DDFSTRT positions that causes a similar "shift" in BPLCON1 for OCS)?

OCS and AGA have exact same reason for this "shift". Denise/Lisa horizontal counter is used for BPLCON1 comparisons, if Agnus BPL1DAT write is not "aligned" to Denise/Lisa horizontal counter, BPLCON1 does not anymore work as documented and has shift/offset that depends on size of misalignment.

[roondar]

Originally Posted by Toni Wilen

OCS and AGA have exact same reason for this "shift". Denise/Lisa horizontal counter is used for BPLCON1 comparisons, if Agnus BPL1DAT write is not "aligned" to Denise/Lisa horizontal counter, BPLCON1 does not anymore work as documented and has shift/offset that depends on size of misalignment.

That's quite interesting to know, thanks.

[chb]

I was wondering - can you overcome the sprite limit at higher fetch modes by fiddling with HSSTRT/HSSTOP and HBSTRT/HBSTOP? Usually you'd need to shift your picture 64 pix to the right to keep the sprites, could you use those registers to bring the picture back in center? Documentation is rather sparse on them, unfortunately.

[ross]

Originally Posted by roondar

So, just for my sanity: in the 4x fetch modes, can you use *any* DDFSTRT position that would be valid for OCS, just with a different 'center point' for BPLCON1?

Yep

If I'm not wrong there is also one bit more usable in DDF (bit 1).
So $36 is a valid value (you 'anticipate' the default first fetch by 2 slots).

The rest as Toni said

[roondar]

Very, very interesting indeed. Learn something new every day!

[ross]

Originally Posted by chb

I was wondering - can you overcome the sprite limit at higher fetch modes by fiddling with HSSTRT/HSSTOP and HBSTRT/HBSTOP? Usually you'd need to shift your picture 64 pix to the right to keep the sprites, could you use those registers to bring the picture back in center? Documentation is rather sparse on them, unfortunately.

This is an old idea of mine, probably I've also wrote of it somewhere on board, related also to DMA bitplanes overrun (possible on AGA at some conditions).

Well, when (if..) I'll re-acquire an A1200 I will surely test it

[NorthWay]

I had a rough idea of using the copper to time the first fetch each line as x2 and switch up to x4 for the rest of the line. My 4000 is still in limbo so I haven't pushed that to its conclusion.

[mcgeezer]

Originally Posted by ross

Yes, you can, losing only sprites 5 to 7. And yes, if you scroll you lose 32 left pixels.
Of course you need a pointer 64bit aligned in memory.
BPLCON1 in no more 'centered' on value 0. This is because the 'zero' value is good only for $18/$38/$58/etc...
Remember also that on AGA there are 256 possible scroll values (4x subpixels).

Cheers!

I have this working now.

If only I had asked the question coding Rygar, the performance would likely be much better as it is in x2 mode.

I live, I learn (from the best).