View Single Post
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  
 
Page generated in 0.04049 seconds with 11 queries