copper wait glitch

[chadderack]

Hi.


Working on vertical scroller code.

Single playfield (4 bitplanes) scrolling down (starting at y=0) and then back up again. Copper vertical split is calculated based on Y-position such that vertical beam position $2c corresponds to y=0, etc.

Emulated Amiga 500 (ECS)... using WinUAE. Display set to PAL.

Bitplane pointers are updated at the top of the split and leave the bitplane pointers in the second half of the split pointing to the top of the bitmap so that it gets "dragged" upward as the vertical split moves "up" and the screen appears to scroll down.

All of that works fine, except that when scrolling down and the copperlist reaches actual location $2D, something odd happens.

The copperlist waits go from

    dc.w $ffdf,$fffe
    dc.w $0001,$fffe

to

    dc.w $00df,$fffe
    dc.w $ff01,$fffe

... the copper never seems to reach the second wait. The lower part of the screen "disappears" for a single frame.

At the next frame (location y=$2E) the bottom split reappears with the waits

    dc.w $00df,$fffe
    dc.w $fe01,$fffe

...but the split itself appears to be one rasterline too low.

I know it's a bug in the split, not the bitplane pointers... because I change the background color in the bottom split to yellow (for debug purposes)

Y=2C...all is well


Y=2D... wtf?


Y=2E... separated


I can compensate for the problem by checking to see if the scroll is going downward, and then skip past the $00df/$ff01 waits directly to $00df/$fe01... and then the reverse when scrolling up... but I don't like handling those special cases.

Is it possible I'm doing something fundamentally wrong? (I'm going to guess "yes" )

Thanks for any help.

[chadderack]

Maybe horizontal DIWSTART/STOP or DDFSTART/STOP is too wide?

    move.w #DMA_fetch_start,DDFSTRT(a6)                     ;$28 for 22 columns; $38 for 20 columns (etc)
    move.w #$d0,DDFSTOP(a6)

[roondar]

Originally Posted by chadderack

Hi.


Working on vertical scroller code.

Single playfield (4 bitplanes) scrolling down (starting at y=0) and then back up again. Copper vertical split is calculated based on Y-position such that vertical beam position $2c corresponds to y=0, etc.

Emulated Amiga 500 (ECS)... using WinUAE. Display set to PAL.

Bitplane pointers are updated at the top of the split and leave the bitplane pointers in the second half of the split pointing to the top of the bitmap so that it gets "dragged" upward as the vertical split moves "up" and the screen appears to scroll down.

All of that works fine, except that when scrolling down and the copperlist reaches actual location $2D, something odd happens.

The copperlist waits go from

    dc.w $ffdf,$fffe
    dc.w $0001,$fffe

to

    dc.w $00df,$fffe
    dc.w $ff01,$fffe

... the copper never seems to reach the second wait. The lower part of the screen "disappears" for a single frame.

At the next frame (location y=$2E) the bottom split reappears with the waits

Thanks for any help.

I'm guessing the problem is as follows. The $ffdf,$fffe wait is the wait needed to be able to use further Copper wait instructions below line 255 (this wait is needed on PAL Amiga's). It's a very specific wait that can't be altered or it will no longer work.

In this case, changing it to $00df,$fffe will make it fire instantly after whatever instruction happens just prior in the Copperlist as you're now waiting for line 0 and the Copper triggers waits when the raster position is equal to or greater than the requested wait position.

[DanScott]

you could update the wait position as $ffdf,$fffe or as $01fc,$XXXX (copper "nop") depending on whether you need the PAL wait or not for the line at which the screen scroll split happens

[chadderack]

Originally Posted by roondar

I'm guessing the problem is as follows. The $ffdf,$fffe wait is the wait needed to be able to use further Copper wait instructions below line 255 (this wait is needed on PAL Amiga's). It's a very specific wait that can't be altered or it will no longer work.

In this case, changing it to $00df,$fffe will make it fire instantly after whatever instruction happens just prior in the Copperlist as you're now waiting for line 0 and the Copper triggers waits when the raster position is equal to or greater than the requested wait position.

That sounds reasonable roondar. I probably should be more clear; the copperlist isn't fully dynamic. My copperlist never grows or shrinks in size. It has fixed memory positions that I update.

The first wait ($FFDF) waits for y=255 and the second wait ($2c01) adds $2c such that if y=0, the bottom "split" will not show. When y=1, the second wait is decremented... so that it is now $2b01. The bottom split shows one line at the very bottom of the visible area.

When we get to y=$2C, the waits are $FFDF and $0001. At y=$2D, the first wait is modified to $00DF and the second is now $FF01. Maybe by the time the copper finishes the $00DF wait, and the next frame starts, the beam is already past $ff01--so now it would be like waiting for y=$1ff?

Originally Posted by DanScott

you could update the wait position as $ffdf,$fffe or as $01fc,$XXXX (copper "nop") depending on whether you need the PAL wait or not for the line at which the screen scroll split happens

That sound like what is needed... a "nop" so that the first wait is ignored after the y position is > $2C. I'll try that. Thank you, Dan.

[DanScott]

sorry.. should be $01fe NOT $01fc for a copper NOP

[chadderack]

Thank you for the help roondar and Dan.

Changing the wait from $FFDF to $01FE didn't change the behavior. I'm now compensating for the separation glitch by subtracting 1 from the wait value when the vertical position goes past Y=$2C. That way when the bottom split actually shows up in the viewable area, it is aligned properly. It seems to stay aligned when doing this, though the bottom split still "flickers" off for one frame when VIDEOY > $2C.

In a practical sense (because the screen size for the game is 256x224), I won't be showing > 255 vertical scrollable pixels on screen at any one time anyway, and the "separation" and blanking issues only happen when VIDEOY > $2C (only visible below y=255). So the one frame where the bottom split flickers won't be on screen.

ETA: That being the case, maybe I should just re-size the screen buffer to 288x256 instead of 352x288 (as is currently). That way there's no issue.