How to terminate a sprite in automatic mode?

[adrazar]

Hi!

Is it possible to manually turn off automatic data fetching for a sprite channel before it reaches the vertical stop position? I'm missing a control bit for this, does there happen to be one?

[ross]

Writing to SPRxCTL disables the corresponding sprite.
So wait for the desired line, then write.

[adrazar]

Really? That seem to work for me only when the sprite is already in manual mode.

[adrazar]

If I write to SPRxCTL somewhere between the sprite's DMA slots and its horizontal screen position, that line of the sprite is omitted. The next lines of the sprite are still being displayed however. This behaviour lead me to believe that SPRxCTL does not turn off the automatic data fetch.

[ross]

Well, logically it depends on what you write
With proper EVx bits vertical position the fetch stop.

Otherwise a write to SPRxDATA, fetched by DMA on next line, rearm the sprite.

EDIT: this is the reason for a 0,0 when you want to end a sprite list.
These values are loaded by DMA into xPOS and xCTL, after the last defined EVx position, and the fetch end.
Practically the values in SVx and EVx are defining the 'window' where the fetch is active and going to xDAT.

[adrazar]

I take it you suggest that xDAT is loaded if and only if

SV <= beam y < EV,

and that xPOS/xCTL is loaded if and only if

beam y = EV.

I get a different picture:
xDAT is loaded if and only if data fetch is enabled and beam y != EV
xPOS/xCTL is loaded if and only if data fetch is enabled and beam y = EV
and
data fetch is enabled at some point when y beam = SV
data fetch is disabled at some point when y beam = EV

[ross]

No, what I wrote is that (only for y position, not counting the x behaviour):

if (SPREN==1) { //leave out in this context the interaction it has with BPLEN
    on line 25 (PAL, 20 NTSC) DMA always load SPRxPOS and SPRxCTL 
    while (SVx<EVx) {
        if (line==EVx) { fetch new SPRxPOS and SPRxCTL }
        if (line>=SVx)* { fetch SPRxDATA and SPRxDATB }
    }
}

If you manually insert during this condition a right SPRxCTL you can break the DMA fetch (remembering the arm and disarm sprites property).

* see Toni comment some messages later
The condition is even more simple (the DMA simply start at SVx line)


EDIT: sorry if respond a bit at a time but I'm a little busy
But you are right, if you really want to stop the fetch you need also to clear SPREN and re-enable at copper list start
Not that is really a problem, you can position sprites outside of the view or clear xDAT, but maybe your goal is save some DMA cycles

I'll make some test and report

[adrazar]

So there should be no more DMA fetches if I set EVx = 0, because the while condition wouldn't be satisfied? I tried doing that just now by writing 0 to SPRxCTL, but no, it didn't work... :/

[ross]

Originally Posted by ross

if you really want to stop the fetch you need also to clear SPREN and re-enable at copper list start

This is a solution, but it does not satisfy me because it is a global condition and then you have to manage the remaining sprites manually...

[adrazar]

Originally Posted by ross

This is a solution, but it does not satisfy me because it is a global condition and then you have to manage the remaining sprites manually...

Agree!

[Toni Wilen]

Originally Posted by ross

if (SPREN==1) { //leave out in this context the interaction it has with BPLEN
    on line 25 (PAL, 20 NTSC) DMA always load SPRxPOS and SPRxCTL 
    while (SVx<EVx) { 
        if (line==EVx) { fetch new SPRxPOS and SPRxCTL }
        if (line>=SVx) { fetch SPRxDATA and SPRxDATB }
    }
}

There is no larger than (or smaller than) comparison, chipset only does equals comparisons everywhere. If line == EVx: new SPRxPOS/SPRxCTL will be fetched, even when changed mid sprite vertically (=SPRxPOS/SPRxCTL will get sprite data meant for DATx which may appear as sprite getting disabled if new values are "out of range")

Conditions are really simple:

line == SVx: Agnus starts doing sprite SPRxDATx fetches for this sprite.
line == EVx: Agnus does SPRxPOS/SPRxCTL fetches for this sprite, then sprite's DMA channel becomes idle.

Note that Denise does not care or know nothing about sprite vertical position.

[ross]

Ok, i've got the point.

SPRxCTL need to be ==line in value.
And the fetch really stop.

EDIT: ops Toni faster, thanks

[adrazar]

All right, so now we have established that sprite DMA fetches may be disabled by having the sprite reach the vertical stop position. But can it be done before somehow, i.e. without having to go through the "load new xPOS/xCTL"-step?

[ross]

Originally Posted by Toni Wilen

line == SVx: Agnus starts doing sprite SPRxDATx fetches for this sprite.

This is interesing 'cause you can mix DMA/manual without trouble several times in the frame.

Originally Posted by adrazar

All right, so now we have established that sprite DMA fetches may be disabled by having the sprite reach the vertical stop position. But can it be done before somehow, i.e. without having to go through the "load new xPOS/xCTL"-step?

A xCTL write is due before the EV==line position (or this very same line if early on position).

[ross]

Originally Posted by Toni Wilen

Note that Denise does not care or know nothing about sprite vertical position.

Toni, what are the implications of this? You can use some dummy values for y positions?

[Toni Wilen]

Originally Posted by ross

Toni, what are the implications of this? You can use some dummy values for y positions?

All Y-coordinate values are located in registers inside Agnus. They don't matter when sprite is in non-DMA mode. (and vice versa, X-coordinates are only located inside Denise, Agnus does not care)

[ross]

Originally Posted by Toni Wilen

All Y-coordinate values are located in registers inside Agnus. They don't matter when sprite is in non-DMA mode. (and vice versa, X-coordinates are only located inside Denise, Agnus does not care)

Thank you very much for the clarifications

[roondar]

Originally Posted by Toni Wilen

All Y-coordinate values are located in registers inside Agnus. They don't matter when sprite is in non-DMA mode. (and vice versa, X-coordinates are only located inside Denise, Agnus does not care)

I noted this during my sprite layer experiments - my first idea was to update the X & Y position to be correct for the X&Y location of the sprite when repositioning, but due to a bug in the initial code the Y position didn't update (it was stuck at a single value) - however, the sprites still displayed fine so I removed the Y update (only updating X) and that worked fine.

Interesting to know the reason this worked!

[adrazar]

Hello again!

First, thank you all for the replies. It's been a week since I started this thread now, and the time is probably overripe for this, but I hereby confess that still I don't see how the the answers given so far answers my question.

The most conclusive reply I got was this:

Originally Posted by ross

A xCTL write is due before the EV==line position (or this very same line if early on position).

I might have misinterpreted the meaning here, but this is how I read it: write a lower EVx-value into xCTL before line reaches the original EVx; that way the fetching will be disabled earlier.
This solution isn't exactly what I would like, because it still relies on the sprite channel to stop the automatic fetches. I'm aiming at a solution that stops the fetches directly, without having to go through the standard mechanism.

The other main thing that's been brought up is that HPOS- and VPOS-related parameters are stored in separate chips. I must say I currently don't know what difference it makes which chip a piece of data is stored in. Maybe this is where I fail?
More interesting for this problem, the way I see it, is where the automatic fetch status for each sprite channel is stored. I haven't found anything on this in the HWRM yet. :S

[hooverphonique]

The point about y being in agnus means that agnus controls sprite dma fetch (which is only related to y pos), and I'm afraid you can't turn that off manually - since the vertical stop pos is in the second control word, it has to be cached by agnus internally somehow, otherwise it wouldn't know when the next control/end of sprite words are encountered.