Sprites mutliplexing AGA

[mcgeezer]

I've had a read of other threads and ream the HRM but I can't quite work out the full detail to the answer to my question.

If I want to multiplex sprites using the 8 channels the HRM says I can reuse the channels at a later Y position. But the sprite data seems that is must be pre-loaded so I would have to blit new sprites into the data.

Using the copper can I wait for a specific scan line, point the sprite SPRxPTH/SPRxPTL registers at some sprite data in memory and update the SPRxPOS registers to position them on display, then later down the display do the same thing but point to a completely different sprite data - so in essence I get two completely different sprites on screen at different and non-overlapping Y positions (without having to blit the sprite data)?

I should point out this is on AGA on 2x mode in case there are any differences from OCS.

I hope that makes sense, any help or advice is appreciated.

Geezer

[ross]

Originally Posted by mcgeezer

Using the copper can I wait for a specific scan line, point the sprite SPRxPTH/SPRxPTL registers at some sprite data in memory and update the SPRxPOS registers to position them on display, then later down the display do the same thing but point to a completely different sprite data - so in essence I get two completely different sprites on screen at different and non-overlapping Y positions (without having to blit the sprite data)?

Yes, but remember that SPRxCTL defines when the data fetch stops and new SPRxPOS/CTL need to be loaded by DMA.
So set SVx/EVx bits for a full screen cover then with copper change PTR and values for x position.
In this way you do not even have the gaps you would have using a normal sprites multiplex (y position) chain.
But a more complex, and that use precious DMA time, copper job..

(remember also to manually point to a void position with copper when you want to display nothing..)

I should point out this is on AGA on 2x mode in case there are any differences from OCS.

The only difference in the large fetch

[mcgeezer]

Originally Posted by ross

Yes, but remember that SPRxCTL defines when the data fetch stops and new SPRxPOS/CTL need to be loaded by DMA.
So set SVx/EVx bits for a full screen cover then with copper change PTR and values for x position.
In this way you do not even have the gaps you would have using a normal sprites multiplex (y position) chain.
But a more complex, and that use precious DMA time, copper job..

(remember also to manually point to a void position with copper when you want to display nothing..)


The only difference in the large fetch

Great, i’ll give it a shot.

I take i just set the inital control words fed by dma to something off screen and then immediately set the SPRxPOS and SPRxCTL to the desired x/y values with the copper.

[ross]

Originally Posted by mcgeezer

Great, i’ll give it a shot.

I take i just set the inital control words fed by dma to something off screen and then immediately set the SPRxPOS and SPRxCTL to the desired x/y values with the copper.

Just some other hints to avoid you a bit of a headache (maybe you know all this but..).
Writing to SPRxCTL disable sprite x comparator so you need to set it with copper before DMA slot that fetch SPRxDATx.
[SPRxDATx write re-enable x comparator]

You can use this property to avoid the fetch of the null (void) part of the sprites during DMA time [logically using a previous beam y position]
(you gain DMA time at the cost of greater complexity of code, evaluate if it suits you, depends on how many sprite you have visible on screen).

To rearm a sprite a write to SPRxPOS suffice [x comparator is continuously checked] and this is the trick for x multiplexing

[roondar]

One note here, I've found that if you set sprite V start to be too high up the screen, DMA seems to just not fetch any sprite data at all. Even if sprite V end is set so it should fetch data down the screen.

I don't remember the exact value, but if you check using the WinUAE visual debugger, you can see that sprite DMA (when active) always does it's first fetch at a specific 'height'. As long as V start is below that, it should just work. In my tests, as soon as it is either at or above that 'height', sprite data isn't actually fetched for that channel.

No idea why it works like that though.

--
On a side note: I'm not so sure why you wouldn't be able to use the CPU to set the sprite control words/pointers in a frame (both starting ones and later ones).

I do agree it's not the best of ideas for updates later down the frame, since you'd likely need a bunch of interrupts to make it happen (which automatically make the Copper a more optimal choice), but still - the HRM suggests that sprite control words and pointers can be update by both CPU and Copper.

[ross]

Originally Posted by roondar

One note here, I've found that if you set sprite V start to be too high up the screen, DMA seems to just not fetch any sprite data at all. Even if sprite V end is set so it should fetch data down the screen.

The first fetched values (SPRxPOS/CTL pair) by sprites DMA are on line 20 for NTSC and 25 for PAL.
So on the first visible video line (21 or 26 respectively) you can have the first DATx usable.

[mcgeezer]

Hi all,

I'm struggling to get *any* AGA sprites to work here never mind a multiplexer!

I have configured a 32x32 sprite, set its control words as long words to what I'm interpreting from the documentation I have. I have FMODE set to 5 which enables 4 mode, also have the first sprite at least 32 bit aligned. It is supposed to be an attached sprite.

Can anyone shed any light as to what else to check?

Very frustrating.... gonna sleep on it but any help appreciated.

[ Show youtube player ]

[ross]

KS1.3 on AGA?
Maybe it's a stupid question, but have you activated the AGA chipset in WinUAE?

[mcgeezer]

Originally Posted by ross

KS1.3 on AGA?
Maybe it's a stupid question, but have you activated the AGA chipset in WinUAE?

Yeah, trust me its in aga mode. The display is 8 planes.

[ross]

Just written a simple test program and all works as it should.
Without your code it's hard to understand what's wrong ..

[Galahad/FLT]

Originally Posted by mcgeezer

Hi all,

I'm struggling to get *any* AGA sprites to work here never mind a multiplexer!

I have configured a 32x32 sprite, set its control words as long words to what I'm interpreting from the documentation I have. I have FMODE set to 5 which enables 4 mode, also have the first sprite at least 32 bit aligned. It is supposed to be an attached sprite.

Can anyone shed any light as to what else to check?

Very frustrating.... gonna sleep on it but any help appreciated.

[ Show youtube player ]

Isnt it supposed to be Fmode=3 for AGA?

[mcgeezer]

Originally Posted by Galahad/FLT

Isnt it supposed to be Fmode=3 for AGA?

That would set bitplanes to 4x.

Bits 1 & 2 control bitplane fetch of 2x or 4x respecively. Bits 3 and 4 control the sprite fetch. So 5 is what i beleive it should be for 32 wide bitplanes and sprites.

[ross]

Yes. Made my tests with bit3=1 and bit3/4=1.

But noticed from you video that x=0x32(*2) that is a position covered by border in your config.
Have you tried with other values?

[mcgeezer]

Originally Posted by ross

Yes. Made my tests with bit3=1 and bit3/4=1.

But noticed from you video that x=0x32(*2) that is a position covered by border in your config.
Have you tried with other values?

That’s weird, the x value i’m sure should be $64 as i set it to 100 pixels in.

That’s still in the border though??? I’ll try different values and see what i get.

Really appreciate your help with this - i’m learning all the time.

[ross]

It depends on your DIWSTRT.

For a standard DIWSTRT=xx$81 and a full sprite view the minimum sprite x coordinate is $80 (yes there is an offset..),
so a value of $40 in SPRPOS(low bits) and 0 on low bit of SPRCTL.

[mcgeezer]

Originally Posted by ross

It depends on your DIWSTRT.

For a standard DIWSTRT=xx$81 and a full sprite view the minimum sprite x coordinate is $80 (yes there is an offset..),
so a value of $40 in SPRPOS(low bits) and 0 on low bit of SPRCTL.

You da man Ross. I have a sprite showing now, its a bit messed up because the attached sprite is broke but the basics are there now.

Really appreciate it!

[ross]

My pleasure

[mcgeezer]

@Ross - Would you mind having a quick look at the video below for me please? Despite experimenting for a couple of hours now I can't get this sprite to display properly.

As you'll see it is kind of there.. but has like a weird HAM flicker.

At the start of the video you'll see what it should look like.

Have you seen anything like that before? Do you have any pointers for me to check? Really really weird. I'm starting to look at other AGA games to see how they've set stuff up but if you can shed some light I would really appreciate it.

Thanks,
Geezer

[ Show youtube player ]

[ross]

Originally Posted by mcgeezer

@Ross - Would you mind having a quick look at the video below for me please? Despite experimenting for a couple of hours now I can't get this sprite to display properly.

As you'll see it is kind of there.. but has like a weird HAM flicker.

At the start of the video you'll see what it should look like.

Have you seen anything like that before? Do you have any pointers for me to check? Really really weird. I'm starting to look at other AGA games to see how they've set stuff up but if you can shed some light I would really appreciate it.

Thanks,
Geezer

[ Show youtube player ]

Hi Geezer, it seems a wrong SPRxPTR init time.
First visible row is the POS/CTL from TEST_SPRITEx (used as DATA).
On PAL line 25 (see one of my previous message) the DMA (auto)loader seems that fetch bad values for POS/CTL, making the flickering.
That can result from some erroneus preceding values: SPRxPTR are auto-incrementing like BPLxPT!
This is the reason why they must be properly initialized by the copper, or the CPU, in precise moments.

To fix: setup SPRxPTR in copper list, on first video lines

Cheers!

[mcgeezer]

I've managed to remove the flickering now by putting the sprites at the top of the copper list so something in there is screwing it up, so getting there.

However it looks like the colour palette on the sprite is wrong. Do the AGA sprites still occupy the last 16 colours in the 32 bank of colours?

All help appreciated.

Geezer