Copper changing sprite pointers

[Muzza]

Hi,
I'm doing sprite multiplexing for a parallax effect and although I have it working, I'm not confident I'm doing it correctly and there is one bodge in particular I'm confused about that I'm hoping someone can explain.

This is AGA, 32 pixel wide sprites, and 2x Bitplanes Fetch.
The basics are pretty standard. I set sprites0/1 (attached mode) to position X, then sprites 2/3 to position X+32. I then repeatedly modify SPRxPOS to tile them across the screen in 32 pixel blocks. (Sprites 2/3 point to the same data as Sprites 0/1)
When one sprite is complete, a few scanlines further down will be another sprite, that does the same thing, only scrolling at a different speed. This all works fine.

The problem comes from not wanting to use sprite automatic mode. If I did use it, I'd have to triple buffer all the sprite data due to modifying the control words each frame. Also some of the sprite data is animated and so uses up a chunk of CHIP RAM. Triple buffering and/or blitting to the sprites adds RAM/Blitter overhead that I want to avoid.

So here is what I am doing:
I have a single copy of each sprite in CHIP RAM, all control words are set to zero.
My copper list starts by disabling all sprites (actually setting all SPRxPT to a small CHIP RAM alloc of all zeroes)
Scanline 25 (for PAL) is where some kind of DMA Sprite work is performed. I'm not clear on what exactly happens here, but it is important to wait until after it, so the copper will wait for scanline 26 before doing any further sprite work.

Going down the screen, for each sprite the copper:
1. Modifies SPRxPT for sprites 0-3
2. Waits for the scanline BEFORE the sprite is supposed to start.
3. Sets SPR0CTL, SPR1CTL, SPR0POS, SPR1POS, SPR2CTL, SPR2CTL, SPR3POS, SPR3POS in that order.
4. Wait for end of scanline.
5. Sprite is now being displayed, repeatedly modify SPRxPOS to duplicate it horizontally.
6. Repeat step 5 for each row of the sprite.
7. Sprite stops itself, due to the values in SPRxCTL, so I don't need to manually stop it
8. Repeat from step 1 for the next sprite down the screen.

The above all works nicely apart from one thing. The first row of the first sprite is always blank, and the last row missing. I get around it by simply adding 4 words to the address set in SPRxPT for this sprite only. But why does the first one act differently? I presume something is incrementing SPRxPT before it starts being drawn, but what and where?

Anyway, I hope I've clearly explained what I'm doing. I'd appreciate anyone filling in the gaps of my knowledge. Thanks.

[a/b]

Line 25 is the end of PAL vertical blanking, that's where sprite DMA (if enabled) loads sprite pointers from SPRxPT regs, and then the first 2 words of sprite data (SPRCTL/POS) so it knows where the sprites have to be displayed. If you are setting the SPRxPT regs, make sure you do it before line 25 (or 20 for NTSC).

[Muzza]

Thanks a/b. Before line 25, all my sprite pointers point to a dummy allocation of all zeroes.
I assuming that writing SPRxPOS is what triggers SPRxPT to be refreshed with the new values I wrote further down the copper list.

[a/b]

No, they are re-read when sprite DMA has to fetch more data, and incremented afterwards, which happens when you manually modify CTL/POS registers and overwrite the 0/0 pair (otherwise it would never happen because of the initial 0/0 from "empty" sprites).
Do your actual sprites have a pair of control words at the start? If so that's the problem I guess because sprite DMA already read a pair of control words (0/0, and then later you have provided real values manually) and is expecting data.

[Muzza]

My sprites all have zeroed control words at the start, although nothing happens if I write random data in them either. Certainly it appears as though the first sprite is expecting data and this is what causes the blank line. But I'm not sure why this isn't also the case for all the sprites that come later.

From your information, this is the order of things as I understand it:
(the below is what is currently producing correct visual results)

1. On Scanline 25, SPRxPT is used to read POS/CTL for all sprites. They will be all zero.
[sprite dma now expects data? even though the values were all zero?]

2. Copper then changes SPRxPT to point to the bitmap data of the first sprite (missing out the control words).

3. Copper waits for Scanline 0x2B (the line before the display starts).

4. Copper writes POS/CTL.

5. On the next scanline, Sprite DMA is activated and first sprite is drawn.

6. When sprite is complete, the end control words are read into POS/CTL (all zero) so sprite DMA stops.

7. Copper updates SPRxPT to point to the second sprite (this time pointing to zeroed control words just before the data)
[why is it not like the first sprite where it expects data rather than control words? its certainly not using the control words]

8. Copper waits for scanline before the sprite is due to start

9. goto 4

[a/b]

Regarding #1, I think so but I'm not 100% sure. Yeah, start = end (0 = 0, in which case the next fetched pair of words is control again), but I think that check is only performed after you pass the scanline comparator (start = current?), which never happens because start line is 0.

In any case... What I would do is skip zero sprite initialization and use the actual sprite ptr values (before line 25), and set sprite start lines to some high value (higher than what you set manually) so that data fetch never happens automatically before you set the real position manually.

[Muzza]

Thanks, this has worked. I have a better understanding of what is going on now, and can get rid of the special case for the first sprite.

[saimo]

Just to add a little of piece of information that might be useful (also for other stuff)...

In SkillGrid I use all 8 sprites with a variety of graphics. It might happen that 2 or more (also all 8) sprites could display the very same graphics at the same time. In theory, when sprites are DMA-driven, one should have the same graphics replicated for each sprite, thus wasting a lot of memory. To avoid that, I decouple the control words from the bitmap data. This is how I do it:
1. SPRxPTx are loaded to fixed locations containing the initial control words;
2. between DMA cycles $16 and $34 on rasterline 25, Lisa reads the control words for all the sprites and increments SPRxPTx;
3. the Copper waits for cycle $38 (so, shortly after the sprites control words are fetched);
4. the Copper reloads SPRxPTx to point to the desired graphics.

Note: if a position earlier than $38 is waited for, sprites get screwed up.