English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 17 October 2018, 17:32   #1
adrazar
Registered User

 
Join Date: Feb 2017
Location: Oslo
Posts: 38
How to terminate a sprite in automatic mode?

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?
adrazar is offline  
Old 17 October 2018, 18:11   #2
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,237
Writing to SPRxCTL disables the corresponding sprite.
So wait for the desired line, then write.
ross is offline  
Old 17 October 2018, 23:26   #3
adrazar
Registered User

 
Join Date: Feb 2017
Location: Oslo
Posts: 38
Really? That seem to work for me only when the sprite is already in manual mode.
adrazar is offline  
Old 18 October 2018, 01:42   #4
adrazar
Registered User

 
Join Date: Feb 2017
Location: Oslo
Posts: 38
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.
adrazar is offline  
Old 18 October 2018, 10:24   #5
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,237
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.

Last edited by ross; 18 October 2018 at 11:07.
ross is offline  
Old 18 October 2018, 13:00   #6
adrazar
Registered User

 
Join Date: Feb 2017
Location: Oslo
Posts: 38
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
adrazar is offline  
Old 18 October 2018, 13:53   #7
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,237
No, what I wrote is that (only for y position, not counting the x behaviour):

Code:
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

Last edited by ross; 18 October 2018 at 16:04.
ross is offline  
Old 18 October 2018, 14:27   #8
adrazar
Registered User

 
Join Date: Feb 2017
Location: Oslo
Posts: 38
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... :/
adrazar is offline  
Old 18 October 2018, 14:33   #9
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,237
Quote:
Originally Posted by ross View Post
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...
ross is offline  
Old 18 October 2018, 14:39   #10
adrazar
Registered User

 
Join Date: Feb 2017
Location: Oslo
Posts: 38
Quote:
Originally Posted by ross View Post
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!
adrazar is offline  
Old 18 October 2018, 14:49   #11
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,022
Quote:
Originally Posted by ross View Post
Code:
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.
Toni Wilen is offline  
Old 18 October 2018, 14:51   #12
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,237
Ok, i've got the point.

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

EDIT: ops Toni faster, thanks
ross is offline  
Old 18 October 2018, 15:33   #13
adrazar
Registered User

 
Join Date: Feb 2017
Location: Oslo
Posts: 38
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?
adrazar is offline  
Old 18 October 2018, 15:57   #14
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,237
Quote:
Originally Posted by Toni Wilen View Post
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.

Quote:
Originally Posted by adrazar View Post
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 is offline  
Old 18 October 2018, 16:27   #15
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,237
Quote:
Originally Posted by Toni Wilen View Post
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?
ross is offline  
Old 18 October 2018, 16:35   #16
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,022
Quote:
Originally Posted by ross View Post
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)
Toni Wilen is offline  
Old 18 October 2018, 16:45   #17
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,237
Quote:
Originally Posted by Toni Wilen View Post
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
ross is offline  
Old 18 October 2018, 16:47   #18
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 562
Quote:
Originally Posted by Toni Wilen View Post
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!
roondar is offline  
Old 26 October 2018, 02:32   #19
adrazar
Registered User

 
Join Date: Feb 2017
Location: Oslo
Posts: 38
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:
Quote:
Originally Posted by ross View Post
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
adrazar is offline  
Old 26 October 2018, 11:28   #20
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 810
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.
hooverphonique is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Mani Pulite sprite problems (A500 mode) andreas support.WinUAE 17 22 January 2015 15:41
Start automatic.. Nightmare4k support.FS-UAE 8 08 November 2014 17:53
Automatic Savestates Another World request.UAE Wishlist 12 17 January 2009 20:55
'Warp Mode' broken in 'windowed mode' NoX1911 support.WinUAE 3 26 May 2007 02:05
REQ: Automatic resolution change ; automatic resolution detection Borg_Number_One request.UAE Wishlist 3 21 August 2004 15:16

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 06:24.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.09827 seconds with 16 queries