7th sprite corrupt with DDFSTRT of 0x30

[FSizzle]

I'm having a weird problem with my 7th sprite being corrupt when I start my DDSTRT earlier (0x30 instead of 0x38) in order to have HW scrolling.

I fully expect to lose the 8th sprite, but I'm puzzled why the 7th sprite appears, but doesn't display properly.

Here is my full window setup:
DIWSTRT = 0x2C80
DIWSTOP = 0xF4BC
DDFSTRT = 0x0030
DDFSTOP = 0x00D0

Am I missing something really obvious here? Have i misunderstood the DMA timing diagram?

[ReadOnlyCat]

Originally Posted by FSizzle

DDFSTRT = 0x0030
DDFSTOP = 0x00D0

Am I missing something really obvious here? Have i misunderstood the DMA timing diagram?

DDFSTRT

is the only one which matters and with 0x30 you should indeed only lose the 8th Sprite (Sprite 7).

Are you sure that you are feeding Sprite 6 with proper data? It could be as simple as your Sprite data being corrupted by another bug in your code.

Toni has discovered a number of weird behaviors regarding data fetches but I do not recall anything which matches your case.

[FSizzle]

Thanks for confirming that at least what I'm trying to do should work I do suspect it's something wrong with my code, but I'm a little stumped as to what it might be.

If I change the DDFSTRT to 0x38, the 7th sprite displays correctly. Similarly, if I change the sprite to use any of the first 6 slots it also displays correctly, so if the bug is somehow in the sprite setup, it's very subtle.

I've noticed that the way the sprite is corrupted is very specific - it's almost as if the second word fetch for each line is being inhibited, including the sprite data ptr not being advanced. For example, with the sprite data for each row as follows:

1111000000000000 0000000000000000
0000111100000000 0000000000000000
0000000011110000 0000000000000000
0000000000001111 0000000000000000

it actually ends up displaying as alternating lines:

1111000000000000
0000000000000000
0000111100000000
0000000000000000
0000000011110000
0000000000000000
0000000000001111
0000000000000000

It appears the same in Win-UAE and FS-UAE - I guess i can try the real HW next. I'm open to other ideas about what else I should check if you have any

[Toni Wilen]

All OCS Agnus variants (fixed in ECS/AGA) have sprite DMA bug/feature: single cycle just before bitplane DMA starts is not available for sprites, it kills dma transfer to sprite's second control word/data word (if bitplane DMA start is early enough) causing sprite to become damaged, for example previously loaded DATB is visible.

In other words, if OCS Agnus, when documentation says only sprite 7 gets killed due to bitplane DMA, sprite 6 second word DMA slot also gets stolen by bitplane DMA and so on.

[Photon]

Correct, basically left side overscan steals sprite channel DMA slots one bitplane per 8px. (See the moon sprite in the DYSP part of Uncle Tom Sonix, and surely any game with horizontal scrolling would use the 7th sprite.)

For DDFSTRTs of $2c and $34 you can still use 1 bitplane sprites!

[FSizzle]

Thanks for the great info everyone. Looks like I'll need to shrink the window by 16 pixels on the left if I want that 7th sprite to work reliably on all hw (on the plus side I'll get the 8th one back also).

[borchen]

Looks like I'll need to shrink the window by 16 pixels on the left if I want that 7th sprite to work reliably on all hw

If you want full use of all sprites AND make use of HW scrolling, isn't it possible to extend the right margin of the visible windows by 16 pixels? Ofcourse the whole screen will be offset by 16 pixels to the right...
Or is this a noob-answer?

[FSizzle]

It's possible to have the screen finish 16px later, thus keeping the full width, all the sprites and scrolling, as far as I can tell, but it introduces some new potential problems.

Firstly, I think this would be considered to be entering the overscan area, so you are now risking the image being cut off on people's screens. If someone has a monitor like the 1084s they can adjust the position, but someone on a TV is not able to do that usually. Even the defaults of something like WinUAE would at best put this to the very edge of the window and maybe even cut off some pixels. It also think it looks bad to be so off-center like this.

Secondly, I am relying on some precise copper timing to align palette switching at the left and right edges of the window. For reasons I don't fully understand, pushing the window further to the right starts to exhibit some odd timing problems that make it not possible to reliably line up the right window edge and copper palette switches (timing seems to not be consistent).

[phx]

Originally Posted by FSizzle

For reasons I don't fully understand, pushing the window further to the right starts to exhibit some odd timing problems that make it not possible to reliably line up the right window edge and copper palette switches

I guess you lost some Copper DMA slots to Bitplane DMA by moving DDFSTOP to the right. So the Copper can no longer execute your WAIT instructions in time?

BTW, sprites 6 and 7 still work, you only lost their DMA slots. Which means you could also load SPRxDATA/SPRxDATB with the copper, at the beginning of the line and still use those sprites.

[FSizzle]

I guess you lost some Copper DMA slots to Bitplane DMA by moving DDFSTOP to the right.

I decided to investigate this a bit, so I created a small test (with sprites and bitplanes disabled), which changes the color at the right edge of the screen, setting the wait at each pixel position around 0xDC (+/- 16 pixels):

for ( uint16_t i=0; i<32; ++i )
{
    // Left
    CopperList_WaitH( cl, 100 + i, 0x40 );
    CopperList_Move( cl, 0x180, ( i & 0x1 ) ? 0xF00 : 0x0F0 ); // Red/Green
    // Right
    CopperList_WaitH( cl, 100 + i, 0xDC - 16 + i ); 
    CopperList_Move( cl, 0x180, 0x000 );
}

This creates a stable stepping pattern on the right side of the screen until it goes past 0xDC, at which point the color change no longer happens at the expected time. It also alternates between odd and even frames as shown in WinUAE below. My assumption is that this is another quirk of the HW.

BTW, sprites 6 and 7 still work, you only lost their DMA slots. Which means you could also load SPRxDATA/SPRxDATB

You're absolutely right. The trouble is that it makes them impractical for fast moving objects when combined with an already complicated copper list that is full of delicate per-frame timing for multiplexing and various other tricks.