AGA Display Configuration?

[mcgeezer]

Hi All,

I've been reading up on the capabilities of the AGA chip set and I wondered if I could get feedback on how well the config below would work.

Basically I'm looking at Rygar, and the problem of getting all those colours the game has and the parallax play-field working as efficiently as possible.

I've read the 64 pixel wide sprites in AGA has "limitations" but I can't see the devil in the detail of what this is?

Could I setup a scrolling background playfield made up of 8 * 64x224 pixel sprites all aligned next to each other allowing 16 independent colours for background scrolling and 32 colours/5BP or 64 colours/6BP foreground scrolling again with independent colours?

Setting up Dual Playfield mode just won't allow the colours the game needs for it to be done justice, but before I delve into coding are there any show stoppers with the above idea?

Geezer

[roondar]

Hmm, I haven't really looked into AGA capabilities properly, but as I understand it, the limitations of the 64 pixel sprites are as follows:

• Manual mode and copper list insertion of sprite data (but not position) do not work for 64 pixel sprites and will result in garbage pixels
• Can't be mixed with 4x bitplane fetch modes because those push display fetch so early most sprite channels are no longer usable (though this also affects 16 pixel sprites)*
• Need to be aligned on a 64 bit memory location and a NULL sprite is defined slightly differently to an OCS NULL sprite.
• Most importantly: still only 8 channels is fairly limiting (so there is still a maximum of 4 sprites when using 15 colours per sprite)

*) As far as I understand it anyway, this could be very wrong

On the other hand, AGA does support repeating sprites horizontally after 256 pixels automatically (without copper instructions per scanline) by setting a single register and offers selectable sprite colour banks.

[ross]

Originally Posted by roondar

Can't be mixed with 4x bitplane fetch modes because those push display fetch so early most sprite channels are no longer usable (though this also affects 16 pixel sprites)*

Of course you can use together bitplanes and sprites in fetch mode 4x.
Problems arise if you need to scroll the video through BPLCON1.

Take for example a normal screen of 320 pixels with DDFSTRT=0x38 that allows the use of all 8 sprites.
If you want to fine scroll with OCS 1x fetch (then one 16bit word at a time) there are two possibilities to prevent the screen shift from being visible:
- shrunk the screen 16px to the left and usually by symmetry also 16px to the right (for a total of 288 pixels visible);
- set the DMA fetch early by setting DDFSTRT=0x030, but this way subtracts DMA channels available to the sprites (specifically the 7 and a half 6 in OCS, only 7 in ECS and AGA).
[in fact there is a little trick to keep the 6 on OCS intact, but this is another matter]

The exact same applies in AGA, but in this case you can also fetch 32bit or 64bit at a time (2x/4x respectively) using a single DMA slot (good!)
But this involves a shift window of 32 (64 respectively) pixels with BPLCON1 and an anticipated DDFSTRT to compensate for the first visible pixel on screen (that can be even 64px later)..
Retake the standard 320px screen: if you want fine scroll so you need DDFSTRT=0x28 in 2x fetch mode and DDFSTRT=0x18 in 4x fetch, with loss of sprites 5-7 in 2x case and sprites 1-7 in the 4x case!

You can make intermediate choices but you have to compromise

[mcgeezer]

Do i get 8 16 colour 64 pixel sprites or only 4 with the attach bit set?

[ross]

Originally Posted by mcgeezer

Do i get 8 16 colour 64 pixel sprites or only 4 with the attach bit set?

4.
Other goodies and limits from roondar's message.

Yes, using AGA sprites can be frustrating...

[phx]

Originally Posted by ross

- set the DMA fetch early by setting DDFSTRT=0x030, but this way subtracts DMA channels available to the sprites (specifically the 7 and a half 6 in OCS, only 7 in ECS and AGA).
[in fact there is a little trick to keep the 6 on OCS intact, but this is another matter]

Really? More details concerning the OCS-trick, please!

[ross]

Originally Posted by phx

Really? More details concerning the OCS-trick, please!

Use DDFSTRT=$34.
But you should take care of the wrong BPLCON1 shift values that are "aligned" with default DDFSTRT lowres value.
In other word: the shift 0 position is no more the shift 0 value.
So experiment a bit

[phx]

Originally Posted by ross

Use DDFSTRT=$34.

Ah! That's the delay which reactivates the missing Sprite6 DMA slot? And scrolling still works?

I didn't expect that such an odd value does even work in LoRes.

But you should take care of the wrong BPLCON1 shift values that are "aligned" with default DDFSTRT lowres value.
In other word: the shift 0 position is no more the shift 0 value.
So experiment a bit

Hmm. I guess BPLCON1 shift 0 is a shift 8 then? But can you really hide all 16 pixels behind the left border with DDFSTRT=$34?

Very interesting. Never heard of that trick before!

[ross]

Originally Posted by phx

Ah! That's the delay which reactivates the missing Sprite6 DMA slot? And scrolling still works?

Yes and yes

Hmm. I guess BPLCON1 shift 0 is a shift 8 then? But can you really hide all 16 pixels behind the left border with DDFSTRT=$34?

Another yes and yes

Logically you need the right DIW values and you loss 8pixels to the left.
I think the best use for this video mode is a centered 304 pixels wide display.
(a little better than the 288px with DDFSTRT=0x38 for scroll)

[dissident]

Originally Posted by ross

Use DDFSTRT=$34.
But you should take care of the wrong BPLCON1 shift values that are "aligned" with default DDFSTRT lowres value.
In other word: the shift 0 position is no more the shift 0 value.
So experiment a bit

Wow, a trick I've never heard before. If I've got some time, I will experiment a little bit with it. Sounds really interesting. Thanks for sharing your knowledge, ross.