28 March 2024, 18:09 | #1 |
German Translator
Join Date: Aug 2018
Location: Drübeck / Germany
Age: 49
Posts: 193
|
Spritepointer question
In the first case, the sprite is fully visible.
In the second case, the display of the sprite begins with the second line. The sprite pointer is directly aligned with the sprite data. I would have said that the sprite is started by SPRxPOS and only then should the sprite pointer be automatically incremented with each new line. 1. what counts the SPRxPT and when? 2. why is the second line of the sprite displayed first in the 2nd case? or why is the first line of the sprite skipped? 1) sprite completely visible Code:
00030800: 2c01 fffe ; Wait for vpos >= 0x2c and hpos >= 0x00 ; VP 2c, VE 7f; HP 00, HE fe; BFD 1 00030804: 0120 0003 ; SPR0PTH := 0x0003 00030808: 0122 0830 ; SPR0PTL := 0x0830 0003080c: 0140 2c40 ; SPR0POS := 0x2c40 00030810: 0142 3900 ; SPR0CTL := 0x3900 >m 30830 00030830 0000 8C31 0000 0660 0000 0240 0180 318C ...1...`...@..1. [18 -] [19 -] [1A -] [1B -] [1C -] [1D -] [1E -] [1F -] COPW 08C SPR0 144 SPR0 146 FFFE 0000 8C31 00030816 00030830 00030832 10B 084 118 084 119 084 Code:
00030800: 0120 0003 ; SPR0PTH := 0x0003 00030804: 0122 0fd8 ; SPR0PTL := 0x0fd8 00030808: 2c01 fffe ; Wait for vpos >= 0x2c and hpos >= 0x00 ; VP 2c, VE 7f; HP 00, HE fe; BFD 1 0003080c: 0140 2c40 ; SPR0POS := 0x2c40 00030810: 0142 3900 ; SPR0CTL := 0x3900 >m 30fd8 00030FD8 0000 8C31 0000 0660 0000 0240 0180 318C ...1...`...@..1. [18 -] [19 -] [1A -] [1B -] [1C -] [1D -] [1E -] [1F -] SPR0 144 SPR0 146 0000 0660 00030FDC 00030FDE 1EE 087 1EF 087 |
28 March 2024, 19:17 | #2 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,054
|
If you are using sprites in automatic/DMA mode (sprite DMA enabled), you should set the pointers ($0120-$13e) *before* the end of vertical blank area (before rastertline 25) because that's when they are loaded and the first 2 words (control/position) are read automatically so the hardware knows where to start displaying the sprite.
Since your sprite data only contains bpl lines (normally you start with 2 control/positions words), there are additional complications that make it work or not work properly. In case 1, hardware reads the pointer and control/position words, whatever they are, and then at line $2c you manually update all the registers and overwrite "invalid" data, and the sprite bpl words are all read as they should so it works. In case 2, you set the pointer before the end of VBL and hardware uses that pointer, but your sprite data starts with bpl lines, without control/position words, so the first bpl line is read and interpreted as control/position, and then you update that with proper data at line $2c so it works but the first bpl line is missing. |
28 March 2024, 21:14 | #3 |
German Translator
Join Date: Aug 2018
Location: Drübeck / Germany
Age: 49
Posts: 193
|
The logic behind this is not yet clear to me.
I display sprites in semi-automatic mode by writing to SPRxPOS through the copper. For me it makes no difference whether the sprite pointer is set before or after the wait. Sequence from beginning: - Long before the actual event and therefore during the vbl phase the sprite pointer is set to the first BPL pair of the sprite - the first video line begins at $2c (DIWSTRT $2c81) - a Copper-Wait $2c01,$fffe is placed in front of the sprite DMA slots to write the start position in SPRxPOS - SPR0POS is loaded with $2c40 via Copper (before sprite DMA slots) - the sprite vertical comparators are valid and - Sprite-Datafech SPR0 is done on line $2c at slot $19, $1B and fetches the data from where the sprite pointer is currently pointing - the sprite is displayed at position $2c40, the first BPL pair and not the second |
28 March 2024, 21:37 | #4 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,488
|
I didn't read everything because without a practical example (an executable please ) it's difficult to follow, but have you considered the fact that in any case there is an automatic fetch on line $19 (in PAL) for POS/CTL if the DMA is enabled? (yes, a/b already said it)
|
28 March 2024, 22:03 | #5 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,054
|
Your sprite data doesn't have control/position word at the start, therefore the hardware (since sprite DMA is enabled) will read the first 2 BPL words in rasterline 25, after refreshing sprite pointers, and they will be unavailable for displaying.
If you set sprite pointers before line 25 you will have to rollback those 2 words (reset sprite pointers), or provide a proper sprite structure: - 2 words control/position (or dummy 0s in case you set all that manually via copper), - N*2 words BPL data, - 2 words 0 (control/position) to indicate end (or write 0s via copper). If you set sprite pointers after line 25 then your sprite structure can be 100% BPL words, however the hardware will do what I described above anyway, so you lose some DMA slots and have to make sure display window and bitplane dma activity match (start $2c) or you might get corrupt sprite lines. I mean, it will work (because several things would have to "go wrong" at the same to get corrupt sprites) but it's ugly and not optimal. This is a simplified version of what the hardware does if sprite DMA is enabled: - start of line 25: read sprite pointers from $120-$13f - line 25 sprite dma slots: read 2 words (control/position) to determine where a sprite is to be displayed - note: line 26 is first actually visible line, where the sprites can be displayed, so the hardware has to be 100% ready for that, hence it does what is does in line 25 - wait for the first sprite rasterline - use sprite DMA slots to fetch 2 BPL words - wait horizontal position, display sprite BPL words - etc. You can overwrite pointers/control/position at any point, but you have to understand what is the next thing the hardware/DMA will do and in what state it is, so you don't interfere with it in a way that will result in corruption, missing lines, etc. |
28 March 2024, 22:43 | #6 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,488
|
That's probably what you meant, but a little clarification here.
Pointer registers are in Agnus and are not 'read' but 'used' (by the DMA sprite engine). The hardware simply does nothing but increment their values every time a DMA fetch is performed. The only way to manually modify it is to write in it via CPU or Copper. Different for DATA/B or POS/CTL that are actually read from memory (through DMA) and written into the relevant internal registers of Denise and/or Agnus. Furthermore they can be written at any time via CPU or Copper. |
28 March 2024, 22:56 | #7 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,054
|
Yeah, pointers work the same way as bitplane pointers (and have to be reset each frame). Not the best wording I used...
|
29 March 2024, 12:55 | #8 | |
German Translator
Join Date: Aug 2018
Location: Drübeck / Germany
Age: 49
Posts: 193
|
Quote:
As always thanks a/b and ross! Very good!!! Never looked at that line $19 before, but I see now that this is where the "control words" are fetched and it also explains why the first sprite line is $1a. The program is no longer needed, but I have attached it. right mouse button toggles, left ends. Is there a difference regarding the first sprite DMA position between PAL and NTSC or is it line $19 in both cases? |
|
29 March 2024, 13:03 | #9 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,054
|
For NTSC it's 5 lines earlier.
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
I have a question. | steg2000 | support.Games | 3 | 28 June 2023 06:28 |
Hello and my first question. | Lostdotfish | Member Introductions | 3 | 01 December 2018 18:03 |
Amiga 1200...board revisions question / wire link modification question | voyager_1701e | support.Hardware | 3 | 20 February 2014 12:32 |
Sensible question | mmmfreegoo | support.Games | 5 | 25 November 2006 17:10 |
A Question... | DoaBlade | request.Old Rare Games | 2 | 06 January 2002 05:40 |
|
|