Multiple copper waits beyond 255

[Auscoder]

Hey all,

Bit lost with this one, I have a need to wait multiple times beyond 255 in a copperlist, so I have :

[00]		dc.w $ffdf,$fffe
[01]		dc.w $1c00,$ff00; wait for line 284 ($1c+$100 == $11c)
[02]		dc.w $0180,$00f0
[03]
[04]		dc.w $ffdf,$fffe; Is this needed a second time?
[05]		dc.w $1e00,$ff00; wait for line 286 ($1e+$100 == $11e)
[06]		dc.w $0180,$000f

Thing is with this, only the first wait seems to work as expected. The second wait and following moves do not seem visible.

I tried removing the additional wait on line [04] but still failed to show anything beyond the first wait.



The following seems to work : Not sure why, as I didn't care about x, and thought it was masked out?

[00]		dc.w $ffdf,$fffe
[01]		dc.w $1c01,$fffe; wait for line 284 ($1c+$100 == $11c)
[02]		dc.w $0180,$00f0
[03]
[04]		; -> Removed dc.w $ffdf,$fffe; Is this needed a second time?
[05]		dc.w $1e01,$fffe; wait for line 286 ($1e+$100 == $11e)
[06]		dc.w $0180,$000f

[mcgeezer]

The second wait is not needed.

[Auscoder]

Originally Posted by mcgeezer

The second wait is not needed.

For sure it seems the way. The second wait actually breaks things, makes sense as it would not ever actually occur again in that copper frame.

[ross]

Originally Posted by Auscoder

[01]		dc.w $1c00,$ff00; wait for line 284 ($1c+$100 == $11c)

This is a MOVE and not a WAIT instruction.
WAIT require bit0 in first fetcthed word to be 1.

So a right copper list should be:

[00]		dc.w $ffdf,$fffe
[01]		dc.w $1c07,$fffe; wait for line 284 (x position to prevent COLOR00 from being seen in the previous line)
[02]		dc.w $0180,$00f0
[03]		dc.w $1e07,$fffe; wait for line 286
[04]		dc.w $0180,$000f

Or

dc.w $1c01,$ff00

if you do not change COLOR00 and uninterested in x position.

[Auscoder]

Originally Posted by ross

This is a MOVE and not a WAIT instruction.
WAIT require bit0 in first fetcthed word to be 1.

So a right copper list should be:

[00]		dc.w $ffdf,$fffe
[01]		dc.w $1c07,$fffe; wait for line 284 (x position to prevent COLOR00 from being seen in the previous line)
[02]		dc.w $0180,$00f0
[03]		dc.w $1e07,$fffe; wait for line 286
[04]		dc.w $0180,$000f

Or

dc.w $1c01,$ff00

if you do not change COLOR00 and uninterested in x position.

Thank you, I see that now. Such a newbie mistake, kind of hilarious on such old hardware, but I am just learning all this hardware programming. Copper list was a bit of a fumbling mess, this has helped me clean it up a lot.

I noticed when NOT masking the x, setting $1c01 will show color in left border, but not the line above. and setting $1c07 will not show color change in the border.

Why does it need $07 to not show the color in the line above like you mentioned, I am not seeing that occur (or does it happen in the line above right border area?)

[Antiriad_UK]

Its due to horizontal blanking. Anything lower than 03 (I think) ends up on previous line. I use 07 and df as the min max values as listed here in last paragraph.
http://coppershade.org/articles/AMIG...t_WAIT_Timing/

If you disassemble some demo and game copperlists ( Run winuae debugger and type o1) you’ll see it’s what everyone does.

You’ll also notice that in a lot of old demos you’ll see the exact same colour on previous line errors as it was harder to spot on tv in the 90s and we didn’t realise we’d read the manuals wrong

[Auscoder]

Originally Posted by Antiriad_UK

Its due to horizontal blanking. Anything lower than 03 (I think) ends up on previous line. I use 07 and df as the min max values as listed here in last paragraph.
http://coppershade.org/articles/AMIG...t_WAIT_Timing/

If you disassemble some demo and game copperlists ( Run winuae debugger and type o1) you’ll see it’s what everyone does.

You’ll also notice that in a lot of old demos you’ll see the exact same colour on previous line errors as it was harder to spot on tv in the 90s and we didn’t realise we’d read the manuals wrong

Thanks for that explanation and link. Its gold!

I took a look at your demo after viewing some more of your posts. Wow. Amazing demo, very pro! I love the module as well. Superbly done.

[Antiriad_UK]

Originally Posted by Auscoder

Thanks for that explanation and link. Its gold!

I took a look at your demo after viewing some more of your posts. Wow. Amazing demo, very pro! I love the module as well. Superbly done.

Yeah I have lots of comments from photon’s site scattered in my source code as a reminder as to what I’d been doing wrong in my old demos hehe. I also found his video tutorials useful. I found them a great reminder and learned a few things I should have known before as well.

Thanks for the demo comment, very kind. The module seems to be a love it/hate it one for most. There’s an mp3/synth version in the download

[ross]

I have just read the article indicated and there are some clarifications to make.

To be sure that no color change in right border edge is seen in some monitor, an h position >=$7 should be used ($5 is still visible).
In addition, I've seen references to horizontal positions greater than $e1 (on PAL machines $e1 is the maximum copper h-wait pos, $e3 on NTSC ones).
This may work for vertical lines <$ff because the copper exits the wait for the satisfied condition on the vertical position (and not for the horizontal!).
This could lead to errors, for example when waiting $ffe3, which becomes a CEND in practice, since it's unreachable.

Also be careful to use $ffe1 if you have many bitplanes DMA channels active (and DDFSTOP=$d8) because the slot would be 'stolen' and this would also become an unreachable position.
This is the reason why $xxdf is usually used as the last line position:
it works even with BPL=6 and successive modification operations (pointers, modulos, shifts, ..) are certainly after the last BPL DMA fetch, so no video glitches.

In any case I happened to have some hard sync needs and resort to use $e1 as a wait position when conditions permit