OCS + DDFSTRT=$30 - Losing spr6?

[Antiriad_UK]

Hi,

Not used sprites that much before, so a sprite noob, but can someone verify this?

I've got an overscan screen with ddfstrt=$30 so I lose spr7 as expected. But I also seem to be getting corruption on spr6 as well. See screenshot.

If I change chipset to to ECS Agnus in WinUAE rather than OCS it works. I found this thread which seems to indicate it's a real bug with OCS http://eab.abime.net/showpost.php?p=995744&postcount=9

I'm using DMA to reuse all the sprites down the screen and from reading that thread I'm pretty much going to have to lose spr6 or change ddfstart if I want this to work on OCS. Do I have it right?

Edit: Just found this as well. http://eab.abime.net/showthread.php?t=89276 - I guess that's that!

[ross]

Yep, is an OCS only bug.
You cannot have sprite DMA and Bpl DMA back to back, you lose latest DMA word for the sprite.
In you case DATB for SPR6 (but DATA works as expected).

But you can even use DDFSTRT=$34 (BPLCON1 work differently, try it) and SPR6 works normally.
I've written in a thread about this possibility.

[DanScott]

you could manually load SPR 6 and 7 with the copper on the right side of the screen

[Antiriad_UK]

Hmm, I can't get this manual loading working. I've initialised spr6pt to a dummy sprite in the vblank. Then just into the display window I set spr6pos and spr6ctl. And on each line I set spr0datb and spr6data to a red/green pattern. It looks like it works fine until it reaches the vertical position where spr0-5 are in use and then it goes crazy.

[ross]

Originally Posted by Antiriad_UK

Hmm, I can't get this manual loading working. I've initialised spr6pt to a dummy sprite in the vblank. Then just into the display window I set spr6pos and spr6ctl. And on each line I set spr0datb and spr6data to a red/green pattern. It looks like it works fine until it reaches the vertical position where spr0-5 are in use and then it goes crazy.

If you define a proper spr6pos and spr6ctl then the DMA fetch(es) are executed: DATA only on OCS and DATA/DATB on >=ECS.
If you write DATB with copper after the DATA fetch and before posx, then it works.
Of course in ECS there are two write in DATB (DMA+Copper).

EDIT: usually is better to use SPR6 as a monochrome sprite (clearing DATB once at the beginning of frame for OCS, and on sprite-list for ECS).

[Antiriad_UK]

Setting DATB at top once to 0 was the first thing I tried to just have a monochrome image but I still see every other line line skipped like in my first post so something else is up.

Edit: Ok I get it. My sprite list was:
SPR_Phys_6:
dc.w 0,0 ;control words
dcb.l SPR_HEIGHT,$fff00000

So $fff0 would be DATA(the red) and my assumption was that it would skip the DATB($0000) due to the dma issues and then start again on the next line. But what is actually happening is that it's using $fff0 for DATA on line x and then $0000 for DATA on line x+1. So the same sprite list is going to act differently on OCS and ECS. I think I'll go with the DDFSTRT=$34 approach