How to terminate a sprite in automatic mode?

[ross]

Originally Posted by adrazar

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

Post #26 sprites behavior is also included in the latest version.
You can notice the sprite 0 (the one on the right) that does not show display discontinuity and goes from DMA to manual to DMA without problems.

Toni phrase "SPRxCTL special trigger condition is a bit unexpected but it probably was needed to handle some special case" probably refers to this.

[adrazar]

Almost good now
Only the last part remain a bit unclear, nice to have it straightened out for the sake of completion

Originally Posted by 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.

I didn't quite follow this argument the last time you presented it, and I'm afraid I still don't :/
It would be of great help if you could make it more explicit somehow (still with respect to the effect seen in post #26).

Originally Posted by Toni Wilen

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

It's not obvious what you have in mind when you say "SPRxCTL special trigger condition"? :S

[Toni Wilen]

Originally Posted by adrazar

It's not obvious what you have in mind when you say "SPRxCTL special trigger condition"? :S

I meant chipset designers must have had some reason to implement this kind of DMA-access-only trigger condition. I am not sure why.

[adrazar]

Originally Posted by Toni Wilen

I meant chipset designers must have had some reason to implement this kind of DMA-access-only trigger condition. I am not sure why.

Ok

About post #26, could you please double check for me that you really did look at the code there?
The funny thing about it was that DMA got disabled without relying on a DMA-access.


EDIT: P.S. I'm well aware you saw the code in post #47, in case you are confusing those.

[adrazar]

Things became a lot clearer to me now
I observed that if (line == EVx) then DMA loads xPOS/xCTL regardless of the channel state.
I used to think xPOS/xCTL reloads would happen only if the sprite was about to go idle, but it turns out they don't depend on such a hairy condition after all (Puh! )

A consequence of this is that xPOS/xCTL can be loaded by DMA also for sprites in manual mode.

The following sums up the fetching rules for sprite DMA channels. (It's an edited version of post #34.)

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

2. if (current vpos == sprite end) set sprite DMA state to idle.

3. if (current vpos == first possible sprite line) sprite DMA slots are used to load SPRxPOS and SPRxCTL. Force disables DMA state.

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

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

Remarks:
- The conditions involving vpos are checked constantly, every horizontal position.
- first possible sprite line in point 3. refers to line 25 for PAL and line 20 for NTSC. (http://eab.abime.net/showthread.php?...95#post1048395)
- (current vpos == sprite end) has higher priority in case multiple conditions are satisfied simultaneously.


Thanks to ross and Toni, both made important contributions towards arriving at this model.

[ross]

I think it can be further simplified.

Cases 2, 3 and 4 can be merged:
3. if (current vpos == sprite end) sprite DMA slots are used to load SPRxPOS and SPRxCTL. Force DMA state to idle. Disable happens even if SPRxCTL write is not possible due to bitplane DMA stealing sprite cycles. Initial sprite end is hard-fixed to the first DMA fetch for the sprite.

"Force DMA state to idle. Disable happens even if SPRxCTL write is not possible due to bitplane DMA stealing sprite cycles.": that made possible the very special case used in my code.
Because is valid in every lines not only on line 25(20).
So my write disarms the sprite and set line=EVx that trigger special case (active in every horizontal position).
You can also add to your table that only a DMA write to SPRxCTL can force DMA in idle mode, a CPU write only disarms the sprite (obviously excluding the indirect and special case indicated, that requires compliance with specific conditions).

[NorthWay]

Erm... am I missing something obvious?
What are the rules for when SPRxPT will be read? All the HRM says is to write once per frame like with the bitplane pointers. So does that mean there is no internal register and you can tweak them at any time, just set SPRxPT(skipping the 2 first control words ofc)+SPRxPOS+SPRxCTL before end of line and you have terminated the previous sprite in mid-flight and started a new one?

(If so, wouldn't using that be helpful for a sprite multiplexer to just cut the previous sprite when the hw gets overloaded?)

[ross]

Hi NorthWay, it's not that easy.
It is true that you can change the pointers at any time but the rules listed are always valid, this to support a sprite list in memory (contrary to BPLxPT that always point to pure video data). So you can easy perform a native vertical multiplexing and define the areas in which there is no sprites, economizing also DMA cycles.

Off course the pointers contain the position in Chipram from which the next data will be taken by sprite's DMA, but destination registers can vary.
Then an auto-increment happen like usual after each fetch, till next CPU/COPPER write, normally in the vertical blank.

So if you change on the fly the pointers you cannot change the destination for the DMA (that can also be xPOS/xCTL, specified through.. xPOS/xCTL).

In fact you could also define the height of the sprite as the whole screen and then change pointers to each row, actually changing sprite shape every line (remember to also define empty spaces ). Only expensive because for every line there is COPPER abuse and also the DMA channels of the sprites are always in use.

Well, actually working with SPRxPT is good, but this DMA/manual technical mixing is intriguing. And can also be mixed with some horizontal multiplex

[adrazar]

Originally Posted by ross

Cases 2, 3 and 4 can be merged:
3. if (current vpos == sprite end) sprite DMA slots are used to load SPRxPOS and SPRxCTL. Force DMA state to idle. Disable happens even if SPRxCTL write is not possible due to bitplane DMA stealing sprite cycles. Initial sprite end is hard-fixed to the first DMA fetch for the sprite.

I didn't proofread 3. properly, and I realise the last sentence doesn't make sense in the surrounding context.
I'll take the liberty of editing it a bit

3. is a special case because it says that xPOS/xCTL are loaded at a particular line regardless of the EVx value found in xCTL. This behaviour doesn't get covered by the other statements.

Originally Posted by ross

So my write disarms the sprite and set line=EVx that trigger special case (active in every horizontal position).
You can also add to your table that only a DMA write to SPRxCTL can force DMA in idle mode, a CPU write only disarms the sprite (obviously excluding the indirect and special case indicated, that requires compliance with specific conditions).

Setting EVx=line triggers condition 2.
Then on the next line nothing is fetched because neither condition 4. or 5. are satisfied.
The outcome of this analysis is in accordance with what your code produced.

Originally Posted by NorthWay

What are the rules for when SPRxPT will be read?

Don't know if this supplement to what ross wrote makes things more or less clear, but SPRxPT are always read and incremented during the sprite DMA time slots if condition 4. or 5. are satisfied.


The model is probably correct because it's almost identical to what Toni first recalled, and moreover because I see it fits with every case we've considered.

[ross]

Originally Posted by adrazar

--

Yes, your five unrolled points also works