Question about overscan and sprites

[robinsonb5]

I have a question for the Amiga hardware gurus, if you'd be so kind, please:

I'm currently looking at the MiST/TC64 Minimig core, trying to fix a few glitches and issues, and currently investigating the demo Ray of Hope 2 by Majic12.I have some random sprite garbage in the interference circles effect, which is coming from sprite 7.

Looking at the copperlist, two things stand out immediately:

 00053348: 0092 0018              ;  DDFSTRT := 0x0018
 0005334c: 0094 00e0              ;  DDFSTOP := 0x00e0
 00053350: 008e 1011              ;  DIWSTRT := 0x1011
 00053354: 0090 38ff              ;  DIWSTOP := 0x38ff
 ... bitplane stuff ...
 0005337c: 0120 0005              ;  SPR0PTH := 0x0005
 00053380: 0122 5000              ;  SPR0PTL := 0x5000
 00053384: 0124 0005              ;  SPR1PTH := 0x0005
 00053388: 0126 5000              ;  SPR1PTL := 0x5000
 0005338c: 0128 0005              ;  SPR2PTH := 0x0005
 00053390: 012a 5000              ;  SPR2PTL := 0x5000
 00053394: 012c 0005              ;  SPR3PTH := 0x0005
 00053398: 012e 5000              ;  SPR3PTL := 0x5000
 0005339c: 0130 0005              ;  SPR4PTH := 0x0005
 000533a0: 0132 5000              ;  SPR4PTL := 0x5000
 000533a4: 0134 0005              ;  SPR5PTH := 0x0005
 000533a8: 0136 5000              ;  SPR5PTL := 0x5000
 000533ac: 0138 0005              ;  SPR6PTH := 0x0005
 000533b0: 013a 5000              ;  SPR6PTL := 0x5000

1. The screen is aggressively overscanned
2. Sprite 7's pointers aren't being initialised.

I *think* what's happening is that during the last line of VBLANK the control words are being fetched for all eight sprites and then it's trying to display sprite 7 even though the overscan should prevent it from being used.

My main questions are:
1. During the last line of vblank, should all eight sprites be able to fetch their control words, even though DDFSTART has already been set to 0x18? (bearing in mind bitplane DMA doesn't start until the following row.)

2. The core seems to be using a cycle-by-cycle priority-based allocation for the DMA slots - so the sprite's cycle is only stolen if bitplane DMA actually wants the cycle. But there are two requests in each sprite slot, and when only two bitplanes are active, only one of the two requests is blocked. Should it perhaps instead be blocking all sprite DMA requests after DDFSTART?

3. What happens on real hardware when the display is overscanned to the point where you lose sprites, but those sprites are still enabled? Do they disappear, or just get corrupted?

Any insights would be gratefully received!

[Toni Wilen]

1. During the last line of vblank, should all eight sprites be able to fetch their control words, even though DDFSTART has already been set to 0x18? (bearing in mind bitplane DMA doesn't start until the following row.)

Yes.

2. The core seems to be using a cycle-by-cycle priority-based allocation for the DMA slots - so the sprite's cycle is only stolen if bitplane DMA actually wants the cycle. But there are two requests in each sprite slot, and when only two bitplanes are active, only one of the two requests is blocked. Should it perhaps instead be blocking all sprite DMA requests after DDFSTART?

Sprite slot is always inhibited by bitplane DMA if bitplane sequencer is active (DDFSTRT has matched and BPL DMA is enabled). Bitplane DMA does not need to use sprite's slot, only condition is active BPL sequencer. Which is stupid because in OCS/ECS lores first 2 bitplane slots in normal dma sequence are always free but unfortunately they are not available for sprites. Agnus probably would have needed only few more gates to handle this more sanely.

3. What happens on real hardware when the display is overscanned to the point where you lose sprites, but those sprites are still enabled? Do they disappear, or just get corrupted?

Sprite DMA to SPRxCTL/POS or SPRxDATA/SPRxDATB simply does not happen, register write is skipped (=Denise does not see the write)

Also note that there is OCS/A1000 Agnus extra condition (bug): Sprite slot is also "stolen" (inbihited is probably better word) by bitplane DMA if bitplane DMA starts in following cycle. ECS fixed this off by one bug.

Other DMA channels are not affecteded and can use unused bitplane DMA slots normally.

EDIT: and nasty bug: https://eab.abime.net/showpost.php?p...&postcount=277 (haven't found any programs that triggers this but if it happens, it can be quite mysterious to debug)

[ross]

Originally Posted by robinsonb5

1. During the last line of vblank, should all eight sprites be able to fetch their control words, even though DDFSTART has already been set to 0x18? (bearing in mind bitplane DMA doesn't start until the following row.)

As Toni said, usually yes.

But this is not the case with the demo in question because looking at the copper list something else happens:

DIWSTRT := 0x1011

Bitplane DMA fetches start long before the first sprite fetches (at PAL line $19).
So there is no longer any position control for any of the sprites and many video glitches could theoretically happen if the values present in the registers are previously 'wrong'.

[robinsonb5]

Originally Posted by Toni Wilen

Sprite slot is always inhibited by bitplane DMA if bitplane sequencer is active (DDFSTRT has matched and BPL DMA is enabled). Bitplane DMA does not need to use sprite's slot, only condition is active BPL sequencer.

Many thanks for that - Imitating this behaviour seems to have fixed the glitches I was seeing.

Also note that there is OCS/A1000 Agnus extra condition (bug): Sprite slot is also "stolen" (inbihited is probably better word) by bitplane DMA if bitplane DMA starts in following cycle. ECS fixed this off by one bug.

That's useful to know. Can you think of any games or demos affected by that?

Originally Posted by ross

As Toni said, usually yes.
But this is not the case with the demo in question because looking at the copper list something else happens:

DIWSTRT := 0x1011

Bitplane DMA fetches start long before the first sprite fetches (at PAL line $19).
So there is no longer any position control for any of the sprites and many video glitches could theoretically happen if the values present in the registers are previously 'wrong'.

Interesting - the effect's overscanned even more aggressively than I thought!

Once again, thanks for the input - much appreciated.

[Toni Wilen]

Originally Posted by robinsonb5

That's useful to know. Can you think of any games or demos affected by that?

Batman Vuelve (when batman first appears, part of cape is broken if OCS). This is the only one I remember.

There are many others (listed somewhere in problematic demos thread).

[ross]

Originally Posted by robinsonb5

Can you think of any games or demos affected by that?

First game that came to my mind:
https://eab.abime.net/showpost.php?p...3&postcount=35
(but there are others, mostly demos)

Interesting - the effect's overscanned even more aggressively than I thought!

In any case this aggressive vertical 'overscan' is totally useless, because it is, up to and including line $19, completely in the vertical blank.
So for 10 lines what happens is simply lost DMA fetches..
The same effect would be achieved, thus saving precious bus cycles, by simply setting the DIW to $1axx and the bitplane pointers 10 lines later.

[Rock'n Roll]

1. I like the terminology "aggresive" overscan, but the maximum is:
dc.w $8e,$1a5c,$90,$38d4,$92,$20,$94,$d8 ; Overscan (DiwStrt, DiwStop, DdfStart, DdfStop)
and a datafetch $92,$18 is only necessary for scrolling?

3. vertical blank
goes from line $0 to $19 ?
$1a is first visible displayline and also first possible Y-spriteposition.
earlier bitplane dma fetch is possible but useless, because loosing dma slots
and sprite dma fetch starts always in line $19 if sprite dma is enabled ?

3. topic: loosing sprites if DDFSTRT < $38 if OCS/ECS/AGA (two old posts)
https://eab.abime.net/showthread.php...hlight=DDFSTRT
https://eab.abime.net/showthread.php?t=89276

[ross]

Originally Posted by Rock'n Roll

1. I like the terminology "aggresive" overscan, but the maximum is:
dc.w $8e,$1a5c,$90,$38d4,$92,$20,$94,$d8 ; Overscan (DiwStrt, DiwStop, DdfStart, DdfStop)
and a datafetch $92,$18 is only necessary for scrolling?

Roughly yes, but with small differences between chipsets.

Pixel at $5c is a bit 'ephemeral' in videocomposite PAL (no problem for H&V or CSYNC in RGB).
The colorburst signal can "spill over" at that location and make 'noise' (this at least from field tests, which may or may not be correct and dependent on the devices).
Probably for convenience and simplicity the hardwired values remained the same between NTSC (where the problem doesn't exist, given the slightly higher frequencies) and PAL, and as a solution the workbench drivers start the visible part from $5d (at least, this is the explanation I gave myself, corroborated by a NewTek document where this 'value' is indicated in a document concerning genlock in PAL).
It is however a non-problem given that few use videocomposite and above all with a similar overscan, and very few devices are set to display it (by default none).

From that point there are 376 low resolution pixels visible (377 in ECS and AGA), in standard PAL mode.
EDIT: if I remember correctly in ICS the horizontal blank lasts even longer (STRT=$61 or something?), so even '376' pixels are not always guaranteed..

The end position is only virtually $d4, because the Denise counter do not reach this value (it count from 2 to $(1)c7).
So if you set a value >=$1c8 any pixel to the right is rendered, up to the start of the hblank.

About datafetch from $18: yes, indeed the demo in #1 uses scrolling

2. vertical blank
goes from line $0 to $19 ?
$1a is first visible displayline and also first possible Y-spriteposition.
earlier bitplane dma fetch is possible but useless, because loosing dma slots
and sprite dma fetch starts always in line $19 if sprite dma is enabled ?

Yes to everything (at least under normal conditions).
EDIT: line at '-1' is not blanked but unusable (excluding COLOR00), line0 is also start for Copper and VBI.
This in not true on ICS where line -1 is usable and VBI trigger at line1.