How to terminate a sprite in automatic mode?

[ross]

If you zoom in on my last attached jpg (post #36) you can notice that the 'central' line of the 'breaked' sprite is missing.
These values are loaded in xPOS/xCTL by DMA.. (EDIT: see a successive message why this behaviour)

This is an example of code that (partially) works only by chance
(or better, works much similar to what's expected but not for the right reason ).

At the end, yes, a line based change for sprites between DMA/stop/manual modes can be properly 'handled', but you need to be really aware of the 'full picture'.
If you use code similar to what I've done on post #26 you can enjoy a 'mixed' mode perfectly working.

Surely I will soon forget, but at least I know where to look for valid references.
Actually there another detail for a better understand (EDIT: discussed later) but from now thanks to all involved!
As usual especially to the encyclopedic Toni and his patience.

[adrazar]

Originally Posted by Toni Wilen

Sprite Agnus side logic is very simple:

if (current vpos == sprite start) Set sprite DMA state to active.

if (current vpos == first possible sprite line) sprite DMA slots are used to load SPRxPOS and SPRxCTL. Force disable dma state. Disable happens even if SPRxCTL write is not possible due to bitplane DMA stealing sprite cycles.

if (current vpos == sprite end) sprite DMA slots are used to load SPRxPOS and SPRxCTL

if (sprite dma state == active) Sprite DMA slots are used to load SPRxDATA and SPRxDATB

Loading SPRxCTL: dma state -> inactive

This the thing ...but is the last statement true?
It's giving the impression you can stop DMA by writing 0 to SPRxCTL, but that's been shown not to be the case.
I also notice a slight lack of rigour, but I believe this doesn't hide any unexpected surprises (e.g. 3. has priority over 4. if both conditions are satisfied).

[Toni Wilen]

Originally Posted by adrazar

This the thing ...but is the last statement true?
It's giving the impression you can stop DMA by writing 0 to SPRxCTL, but that's been shown not to be the case.

Perhaps SPRxPOS start still matched?

I also notice a slight lack of rigour, but I believe this doesn't hide any unexpected surprises (e.g. 3. has priority over 4. if both conditions are satisfied).

Stop matching always "wins" if there are multiple matching conditions.

[adrazar]

Originally Posted by Toni Wilen

Perhaps SPRxPOS start still matched?

No, I wrote 0 to SPRxCTL about ten pixels down a sprite and did not touch SPRxPOS. Hence the start position can't have matched the line.

I should probably attach a small program to support my claim, but I don't have a proper setup to create projects in assembly. I can make a quick demonstration in AMOS though if that's good enough.

[ross]

Originally Posted by adrazar

No, I wrote 0 to SPRxCTL about ten pixels down a sprite and did not touch SPRxPOS. Hence the start position can't have matched the line.

I should probably attach a small program to support my claim, but I don't have a proper setup to create projects in assembly. I can make a quick demonstration in AMOS though if that's good enough.

Simply guide me on what you do exactly (x/y positions, registers values, etc).
It's sure a one minute job to do.

[adrazar]

Originally Posted by ross

Simply guide me on what you do exactly (x/y positions, registers values, etc).
It's sure a one minute job to do.

Ok, take your previous program and wait for the middle line of sprite 2, with a horizontal position right after the sprite DMA slots (pixel 128?). Write 0 to SPR2CTL.

[ross]

Originally Posted by adrazar

Ok, take your previous program and wait for the middle line of sprite 2, with a horizontal position right after the sprite DMA slots (pixel 128?). Write 0 to SPR2CTL.

Ok.
Only one BPL active to better view DMA activity.

Copper:

        dc.l	$f027fffe		;right after DMA
	dc.l	$01520000		;2CTL=0

[adrazar]

Thank you ross

So the picture shows that writing to xCTL disarmed the sprite because a line is missing.
But DMA is still active because it continues drawing the following lines.

[ross]

Originally Posted by adrazar

Thank you ross

So the picture shows that writing to xCTL disarmed the sprite because a line is missing.
But DMA is still active because it continues drawing the following lines.

Just a comment before Toni intervention.
This is practically the same case that made me comment in post #39.

I've interpreted post #40 as: next line is a normal DMA line so a xDATA/B is done because DMA is still active "and all the comparisons are active all the time".

I've supposed too much?

[Toni Wilen]

Usual answer: example binary (that works without any external dependencies. If it does: adf that includes everything needed) required that does nothing else than the test case. Programming language is irrelevant.

[ross]

Originally Posted by Toni Wilen

Usual answer: example binary (that works without any external dependencies. If it does: adf that includes everything needed) required that does nothing else than the test case. Programming language is irrelevant.

It's attached in my post, no dependencies (pure asm, the usual crap).

[Toni Wilen]

Originally Posted by ross

It's attached in my post, no dependencies (pure asm, the usual crap).

But is it actually exact same case as adrazar reported? I don't like guesses.

[adrazar]

Yes, it displays exactly the behaviour I was referring to.

[ross]

Originally Posted by Toni Wilen

But is it actually exact same case as adrazar reported? I don't like guesses.

Yes.

And practically the same that made me comment #39, where i've not posted a binary (the effect is different but concept is the same).

[Toni Wilen]

I missed one extra condition: SPRxCTL write disables DMA state only if it was DMA access to SPRxCTL. Manual writes do not affect DMA state.

[ross]

Originally Posted by Toni Wilen

I missed one extra condition: SPRxCTL write disables DMA state only if it was DMA access to SPRxCTL. Manual writes do not affect DMA state.

Argh, this explain all the strange cases, everything!

EDIT: in truth not everything, one last detail is missing



Thanks Toni

[adrazar]

Originally Posted by ross

Argh, this explain all the strange cases, everything!

I still fail to see how the current set of rules explains that DMA could be stopped by writing the current line value to SPRxCTL.
It was clear from post #26 that DMA did not load any value into xCTL after you armed the sprite with your own data, because this data was displayed on the next line.
Now, since DMA didn't load xCTL, DMA should still be active. But it isn't (contradiction ).

Maybe Toni should have a look at the code in post #26 as well

[ross]

Originally Posted by adrazar

I still fail to see how the current set of rules explains that DMA could be stopped by writing the current line value to SPRxCTL.
It was clear from post #26 that DMA did not load any value into xCTL after you armed the sprite with your own data, because this data was displayed on the next line.
Now, since DMA didn't load xCTL, DMA should still be active. But it isn't (contradiction ).

Maybe Toni should have a look at the code in post #26 as well

Yes, during dinner I thought the same thing and that I had been too enthusiastic..

I can suppose only that for condition

if (current vpos == sprite end) sprite DMA slots are used to load SPRxPOS and SPRxCTL

system is tricked to think that DMA has done its job..

[Toni Wilen]

Yes, same answer again, y-coordinate comparisons are active all the time so they don't care when or who changed the register.

SPRxCTL special trigger condition is a bit unexpected but it probably was needed to handle some special case.

[ross]

So, the preceding phrase need to be:

if (current vpos == sprite end) sprite DMA slots are used to load SPRxPOS and SPRxCTL, special DMA idle case

Right?

EDIT: word *special* used because we have TRUE condition from two cases:
- a preceding value in SPRxCTL(EVx)==line so a DMA fetch for new SPRxPOS/CTL is done (a DMA write access, condition for sprite DMA idle state);
- a COPPER/CPU poke on SPRxCTL on this very same line that retroactively force a TRUE condition (setting EVx==line), the special case for a DMA idle state.
It's not so different from my post #39