English Amiga Board


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

 
 
Thread Tools
Old 28 October 2018, 09:40   #61
ross
Sum, ergo Cogito

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

 
Join Date: Feb 2017
Location: Oslo
Posts: 40
Almost good now
Only the last part remain a bit unclear, nice to have it straightened out for the sake of completion
Quote:
Originally Posted by Toni Wilen View Post
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).
Quote:
Originally Posted by Toni Wilen View Post
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
adrazar is offline  
Old 29 October 2018, 18:20   #63
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,107
Quote:
Originally Posted by adrazar View Post
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.
Toni Wilen is offline  
Old 29 October 2018, 18:45   #64
adrazar
Registered User

 
Join Date: Feb 2017
Location: Oslo
Posts: 40
Quote:
Originally Posted by Toni Wilen View Post
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.

Last edited by adrazar; 30 October 2018 at 00:08.
adrazar is offline  
Old 01 November 2018, 19:49   #65
adrazar
Registered User

 
Join Date: Feb 2017
Location: Oslo
Posts: 40
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.)
Quote:
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.

Last edited by adrazar; 02 November 2018 at 03:39.
adrazar is offline  
Old 01 November 2018, 22:22   #66
ross
Sum, ergo Cogito

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

Last edited by ross; 01 November 2018 at 23:09. Reason: added case 2 to the 'big merge'
ross is offline  
Old 02 November 2018, 00:38   #67
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 523
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?)
NorthWay is offline  
Old 02 November 2018, 01:50   #68
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,335
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
ross is offline  
Old 02 November 2018, 03:33   #69
adrazar
Registered User

 
Join Date: Feb 2017
Location: Oslo
Posts: 40
Quote:
Originally Posted by ross View Post
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.

Quote:
Originally Posted by ross View Post
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.

Quote:
Originally Posted by NorthWay View Post
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.

Last edited by adrazar; 02 November 2018 at 03:45.
adrazar is offline  
Old 02 November 2018, 10:24   #70
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,335
Quote:
Originally Posted by adrazar View Post
--
Yes, your five unrolled points also works
ross 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 11:12.


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