Spritepointer question

[Rock'n Roll]

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

 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

2) sprite first line skipped

 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

[a/b]

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.

[Rock'n Roll]

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

[ross]

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)

[a/b]

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.

[ross]

Originally Posted by a/b

- start of line 25: read sprite pointers from $120-$13f

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.

[a/b]

Yeah, pointers work the same way as bitplane pointers (and have to be reset each frame). Not the best wording I used...

[Rock'n Roll]

Originally Posted by ross

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)

That's "really nasty", but that's the answer. I'm always happy when there's an explanation for mystical things!
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?

[a/b]

For NTSC it's 5 lines earlier.