Quote:
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?
Quote:
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.