Copper - waiting for the end of a line

h0ffman · 26 June 2014, 14:42

Currently doing some demo coding experiments where I want to change the bitplane registers every line (yep, I'm sure you can guess the type of effect).

Anyway, I started out simple with just a single plane. What I wanted to do this time was put a wait in for the end each line rather than specifying the vertical position. However the result looks like its not waiting on every line?

This is an attempt to make copper programming a bit easier for me so I don't have to have massive lists specifying every vertical position!

I'm pretty sure I have the wait instruction correct?

Code:

_c_CRL		rept	256
		dc.w	$00e3,$80fe
		dc.w	bplpt,$0
		dc.w	bplpt+2,$0
		endr

Any ideas?

Toni Wilen · 26 June 2014, 15:49

$e2 is last cycle of line, not $e3. Try $e1 or $df.

h0ffman · 26 June 2014, 18:03

tried that, didnt seem to make a difference.

Toni Wilen · 26 June 2014, 18:10

If you mean lines >=128 does not appear to work correctly, check HRM copper loop example for explanation. (E3 should work, I forgot that bit 0 is not part of hpos)

Photon · 05 July 2014, 23:37

This article should answer all questions regarding timing across the horizontal blanking.

Edit: OK, so the question isn't about waiting for end of line.

Looks to me you're specifically matching the top bit of VPOS to be 1. If the moves inside the loop are the same, you can also make a proper loop instead of a rept.

An unmasked wait will match every line shown, i.e. absolutely full overscan from something like $1b to $139. Probably it might still miss line $100 on some Amigas. You'd want a start wait for the top line to know where you are unless it's a blanket ("don't care") move.

Probably bplpt1 (? unspecified, bplpt is a non-standard symbol) would not travel that far in memory between lines so that you would only have to reset the low word.

You could also use a variable to make the code more readable and use normal waits:

Code:

y_pos:	set $2c
	REPT $100
	dc.b y_pos&$ff,$df,$ff,$fe
	dc.w $1e2,0
y_pos:	set y_pos+1
	ENDR

Lonewolf10 · 06 July 2014, 01:57

Quote:

Originally Posted by Photon

You could also use a variable to make the code more readable and use normal waits:

Code:

y_pos:    set $2c
    REPT $100
    dc.b y_pos&$ff,$df,$ff,$fe
    dc.w $1e2,0
y_pos:    set y_pos+1
    ENDR

err... wouldn't it complain about duplicate labels (y_pos:) when you assemble the code??

So set can be used to set aswell as change variables within code?
I learnt something new (and useful) today

h0ffman · 08 July 2014, 14:38

I scrapped it in the end and made it wait for the end of each line but also specified the vpos too.

Alexco · 11 July 2014, 09:49

I have a somewhat similar question. While playing around with old sources of mine I found an issue with waiting for raster lines >$ff I do not understand. I wait for the end of a raster line with $xxe5 fffe to switch color00. This works for all lines <=$ff. For lines after that it seems that copper interprets $ffe5 as end of copper list. If I change only the $ffe5 to $ffe1 or $ffdf the other lines (>$ff) are executed normally. But this creates a small step in the color effect in this line since $e1 is in the visible area of the screen.
So why is line $ff different?

Tested that on WinUAE 2.8 only. Is this the same on real hardware?

Toni Wilen · 11 July 2014, 11:11

Include part of the copper list with copper debugger enabled.

shift+f12, od <return>, g <return>, shift+f12 again, o1 or o2 to dump the copper list, o to continue dumping.

There are some side-effects if WAIT instruction is executed near the end of scanline, hpos can wrap around just before copper does first vpos&hpos comparisons. (For example Superfrog's copper list's normal looking ffdf fffe wait at address 73a0 won't wake up)

Alexco · 11 July 2014, 17:01

Hmm. I see.
Here is what happens:

Code:

 0002d8e8: 0180 0b5d [0fd 004]	;  COLOR00 := 0x0b5d
 0002d8ec: fde5 fffe [0fe 000]	;  Wait for vpos >= 0xfd and hpos >= 0xe4
                        	;  VP fd, VE 7f; HP e4, HE fe; BFD 1
 0002d8f0: 0180 0b5e [0fe 004]	;  COLOR00 := 0x0b5e
 0002d8f4: fee5 fffe [0ff 000]	;  Wait for vpos >= 0xfe and hpos >= 0xe4
                        	;  VP fe, VE 7f; HP e4, HE fe; BFD 1
 0002d8f8: 0180 0b5f [0ff 004]	;  COLOR00 := 0x0b5f
 0002d8fc: ffe5 fffe          	;  Wait for vpos >= 0xff and hpos >= 0xe4
                        	;  VP ff, VE 7f; HP e4, HE fe; BFD 1
 0002d900: 0180 0b60          	;  COLOR00 := 0x0b60
 0002d904: 00e5 fffe          	;  Wait for  hpos >= 0xe4
                        	;  VP 00, VE 7f; HP e4, HE fe; BFD 1
 0002d908: 0180 0b61          	;  COLOR00 := 0x0b61
 0002d90c: 01e5 fffe          	;  Wait for vpos >= 0x01 and hpos >= 0xe4
                        	;  VP 01, VE 7f; HP e4, HE fe; BFD 1

And here when it is working correctly:

Code:

 0002d8f0: 0180 0b5e [0fe 000]	;  COLOR00 := 0x0b5e
 0002d8f4: fee1 fffe [0fe 0de]	;  Wait for vpos >= 0xfe and hpos >= 0xe0
                        	;  VP fe, VE 7f; HP e0, HE fe; BFD 1
 0002d8f8: 0180 0b5f [0ff 000]	;  COLOR00 := 0x0b5f
 0002d8fc: ffe1 fffe [0ff 0de]	;  Wait for vpos >= 0xff and hpos >= 0xe0
                        	;  VP ff, VE 7f; HP e0, HE fe; BFD 1
 0002d900: 0180 0b60 [100 000]	;  COLOR00 := 0x0b60
 0002d904: 00e1 fffe [100 0de]	;  Wait for  hpos >= 0xe0
                        	;  VP 00, VE 7f; HP e0, HE fe; BFD 1
 0002d908: 0180 0b61 [101 000]	;  COLOR00 := 0x0b61
 0002d90c: 01e1 fffe [101 0de]	;  Wait for vpos >= 0x01 and hpos >= 0xe0

Toni Wilen · 11 July 2014, 17:26

It is correct behavior.

Waiting for non-existing hpos (0xe4) will still exit wait state if current vpos is larger than waiting vpos.

FEE5 wait will exit at beginning of next line because vpos FF > FE but waiting for FFE5 keeps waiting (until end of field) because next line will be zero and smaller than FF.

xxE1 hpos >= 0xe0 check will exit the wait normally. (unless bitplane DMA steals all cycles from copper, delaying the wait)

Copper wait exit condition has two parts: if current vpos > waiting vpos: exit, ignore hpos. Only if current_vpos == waiting_vpos hpos is also checked.

Alexco · 11 July 2014, 22:49

Ahh. Thanks.
So in fact, my copper list from around 1990 just worked "by accident" and stopped working now because I extended it to lines >$ff :-).
Can you also please explain what the debug output means?

Toni Wilen · 12 July 2014, 09:51

Quote:

Originally Posted by Alexco

Ahh. Thanks.
So in fact, my copper list from around 1990 just worked "by accident" and stopped working now because I extended it to lines >$ff :-).

"Buggy" copper lists are quite common, for example I have seen lots of copper lists that only "work" because bitplane DMA stole exactly "correct" amount of cycles from copper.

Also another common bug is to wait for positions that have already passed but still worked, for example something like this:

Wait for beginning of line 100, many copper moves, wait for line 100, hpos $40. But because "many copper moves" took long enough, current hpos was already over $40 (for example $50). The best part: wait for hpos $40 was actually wrong and there would have been graphics glitches if wait had ended at hpos $40

Quote:

Can you also please explain what the debug output means?

Extra values are cycle position [vpos hpos] when copper instruction was executed. (This allows to see if wait really exited when expected or if there was some side-effects, like above)

If you want really detailed cycle output, type "v -1" to enable dma debugger and when you enter debugger next time, you can use "v vpos [hpos]" to see all cycle activity for selected scan line.

Photon · 12 July 2014, 16:06

My article did explain these positions past $xxdf make a following move execute on the next line.

Code:

...
$fedf,$fffe
$ffdf,$fffe
$00df,$fffe
...

is a cross-chipset compatible way of extending f.ex. a coppershade across line $100.

Edit: found this again from a question. Sorry if I sounded obtuse here, but the HRM example is wrong (at least on PAL) and WinUAE reflects this correctly. $df as EOL works, so does $e1 but $e3 will not. I wanted to perhaps a little too harshly promote what I think is the correct EOL wait:

Code:

...
$00df,$80fe
...

and that it will survive the $ff vpos wrap hm feature of the chipset.

paraj · 12 March 2017, 10:52

So what's the recommended way of dealing with this? It seems like the best way is to structure the copperlist such that all waiting is done at the end of scanlines:

Code:

dc.w ...., $fedf, $fffe ; Wait for end of line $0fe
dc.w ...., $ffdf, $fffe ; Wait for end of line $0ff
dc.w ...., $00df, $fffe ; Wait for end of line $100

But sometimes you want to do stuff triggered on the left side of the playfield:

Code:

dc.w $fe05, $fffe, ... ; Wait for start of line $0fe
dc.w $ff05, $fffe, ... ; Wait for start of line $0ff
dc.w $ffdf, $fffe ; Wait for end of line $0ff - special case!
dc.w $0005, $fffe, .. ; Wait for start of line $100

Which is fine if the copperlist is static (one extra copper move isn't a big deal), but when building the copperlist on the fly / modifying it as part of the effect all routines end up having to deal with the extra wait, which is pretty annoying and error prone.

In particular I'm mucking about with a copper chunky routine and the copper instructions for each line looks like:

Code:

dc.w $XY09, $fffe ; wait for line XY hpos>=8
dc.w bplcon1, .... ; set scroll for current line
dc.w color+1*2, ... ; set color 1
dc.w color+2*2, ... ; set color 2
...
dc.w color+15*2, ... ; set color 15
dc.w color+1*2, ... ; set color 1
...

Now of course I could avoid the special case by always waiting for end of line, but that would waste precious cycles. I could also make sure the effect never crosses line $ff i.e. give up

. So I was wondering whether I'm missing a neat trick or I'll just have to live with all routines having to deal with the special case.

BTW Photon, your site is an excellent resource, but you write "[...]3 bitplanes will increase the timing [of copper moves] to 12px and 4 (or more) bitplanes will increase it to 16." [0]. Is this for hires modes? For lores <= 4-bitplane modes (no disk/sprites/audio) won't moves keep completing in 8 cycles (this seems to be the case in WinUAE at least and matches my reading of the HRM)?

[0]: http://coppershade.org/articles/AMIG...t_WAIT_Timing/ MOVE INSTRUCTION TIMING

losso · 13 March 2017, 00:17

EDIT: oh, that was already mentioned before… never mind, then

Well, you could try to always wait for a horizontal position right enough to the right that the $ff rollover will occur during your writes and see if you get away with it.

For example, always waiting for $yyDF in each line and changing the background yields (copper debug output):

Code:

 0002d8bc: fddf fffe [0fd 0dc]  ;  Wait for vpos >= 0xfd and hpos >= 0xde
                                ;  VP fd, VE 7f; HP de, HE fe; BFD 1
 0002d8c0: 0180 06eb [0fd 0e1]  ;  COLOR00 := 0x06eb
 0002d8c4: fedf fffe [0fe 0dc]  ;  Wait for vpos >= 0xfe and hpos >= 0xde
                                ;  VP fe, VE 7f; HP de, HE fe; BFD 1
 0002d8c8: 0180 06f2 [0fe 0e1]  ;  COLOR00 := 0x06f2
 0002d8cc: ffdf fffe [0ff 0dc]  ;  Wait for vpos >= 0xff and hpos >= 0xde
                                ;  VP ff, VE 7f; HP de, HE fe; BFD 1
 0002d8d0: 0180 06f9 [0ff 0e1]  ;  COLOR00 := 0x06f9
 0002d8d4: 00df fffe [100 0dc]  ;  Wait for  hpos >= 0xde
                                ;  VP 00, VE 7f; HP de, HE fe; BFD 1
 0002d8d8: 0180 0700 [100 0e1]  ;  COLOR00 := 0x0700
 0002d8dc: 01df fffe [101 0dc]  ;  Wait for vpos >= 0x01 and hpos >= 0xde
                                ;  VP 01, VE 7f; HP de, HE fe; BFD 1
 0002d8e0: 0180 0707 [101 0e1]  ;  COLOR00 := 0x0707
 0002d8e4: 02df fffe [102 0dc]  ;  Wait for vpos >= 0x02 and hpos >= 0xde
                                ;  VP 02, VE 7f; HP de, HE fe; BFD 1

Toni Wilen · 13 March 2017, 16:40

What about using COP2JMP? Replace 00xx wait with COP2JMP which does the extra wait, resets COP2LC and COP2JMPs back to original copper list?

paraj · 13 March 2017, 19:05

Quote:

Originally Posted by Toni Wilen

What about using COP2JMP? Replace 00xx wait with COP2JMP which does the extra wait, resets COP2LC and COP2JMPs back to original copper list?

Neat idea, thanks! And it only costs a handful of extra copper instructions (2 extra jumps, 4 loads to set and restore COP2LC), which I think in most circumstances is a win. Especially if e.g. screen height times "cmp.w $ff, dN ; bne.s .normalcase" can be avoided.

Toni Wilen · 13 March 2017, 19:53

You can save one move if both copperlists are located in same 64k block, only need to update COP2LCL.

paraj · 13 March 2017, 20:14

Quote:

Originally Posted by Toni Wilen

You can save one move if both copperlists are located in same 64k block, only need to update COP2LCL.

Great optimization tip in general (avoiding unnecessary moves to LCH/PTH), but I think in this case the number of saved instructions (2 if the move to cop2lch is done before the copperlist starts and this is the only use of COP2

) probably don't outweigh the risks of messing up. I can just imagine myself debugging random debugging random crashes when later down the line I forget about the optimization and one of the jump targetss suddenly move... But it's always nice to have a few spare cycles ready to cut

26 June 2014, 14:42	#1
h0ffman Registered User Join Date: Aug 2008 Location: Salisbury Posts: 744	Copper - waiting for the end of a line Currently doing some demo coding experiments where I want to change the bitplane registers every line (yep, I'm sure you can guess the type of effect). Anyway, I started out simple with just a single plane. What I wanted to do this time was put a wait in for the end each line rather than specifying the vertical position. However the result looks like its not waiting on every line? This is an attempt to make copper programming a bit easier for me so I don't have to have massive lists specifying every vertical position! I'm pretty sure I have the wait instruction correct? Code: _c_CRL rept 256 dc.w $00e3,$80fe dc.w bplpt,$0 dc.w bplpt+2,$0 endr Any ideas?

05 July 2014, 23:37	#5
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,615	This article should answer all questions regarding timing across the horizontal blanking. Edit: OK, so the question isn't about waiting for end of line. Looks to me you're specifically matching the top bit of VPOS to be 1. If the moves inside the loop are the same, you can also make a proper loop instead of a rept. An unmasked wait will match every line shown, i.e. absolutely full overscan from something like $1b to $139. Probably it might still miss line $100 on some Amigas. You'd want a start wait for the top line to know where you are unless it's a blanket ("don't care") move. Probably bplpt1 (? unspecified, bplpt is a non-standard symbol) would not travel that far in memory between lines so that you would only have to reset the low word. You could also use a variable to make the code more readable and use normal waits: Code: y_pos: set $2c REPT $100 dc.b y_pos&$ff,$df,$ff,$fe dc.w $1e2,0 y_pos: set y_pos+1 ENDR Last edited by Photon; 05 July 2014 at 23:49.

12 July 2014, 16:06	#14
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,615	My article did explain these positions past $xxdf make a following move execute on the next line. Code: ... $fedf,$fffe $ffdf,$fffe $00df,$fffe ... is a cross-chipset compatible way of extending f.ex. a coppershade across line $100. Edit: found this again from a question. Sorry if I sounded obtuse here, but the HRM example is wrong (at least on PAL) and WinUAE reflects this correctly. $df as EOL works, so does $e1 but $e3 will not. I wanted to perhaps a little too harshly promote what I think is the correct EOL wait: Code: ... $00df,$80fe ... and that it will survive the $ff vpos wrap hm feature of the chipset. Last edited by Photon; 08 January 2016 at 01:26.

12 March 2017, 10:52	#15
paraj Registered User Join Date: Feb 2017 Location: Denmark Posts: 1,115	So what's the recommended way of dealing with this? It seems like the best way is to structure the copperlist such that all waiting is done at the end of scanlines: Code: dc.w ...., $fedf, $fffe ; Wait for end of line $0fe dc.w ...., $ffdf, $fffe ; Wait for end of line $0ff dc.w ...., $00df, $fffe ; Wait for end of line $100 But sometimes you want to do stuff triggered on the left side of the playfield: Code: dc.w $fe05, $fffe, ... ; Wait for start of line $0fe dc.w $ff05, $fffe, ... ; Wait for start of line $0ff dc.w $ffdf, $fffe ; Wait for end of line $0ff - special case! dc.w $0005, $fffe, .. ; Wait for start of line $100 Which is fine if the copperlist is static (one extra copper move isn't a big deal), but when building the copperlist on the fly / modifying it as part of the effect all routines end up having to deal with the extra wait, which is pretty annoying and error prone. In particular I'm mucking about with a copper chunky routine and the copper instructions for each line looks like: Code: dc.w $XY09, $fffe ; wait for line XY hpos>=8 dc.w bplcon1, .... ; set scroll for current line dc.w color+12, ... ; set color 1 dc.w color+22, ... ; set color 2 ... dc.w color+152, ... ; set color 15 dc.w color+12, ... ; set color 1 ... Now of course I could avoid the special case by always waiting for end of line, but that would waste precious cycles. I could also make sure the effect never crosses line $ff i.e. give up . So I was wondering whether I'm missing a neat trick or I'll just have to live with all routines having to deal with the special case. BTW Photon, your site is an excellent resource, but you write "[...]3 bitplanes will increase the timing [of copper moves] to 12px and 4 (or more) bitplanes will increase it to 16." [0]. Is this for hires modes? For lores <= 4-bitplane modes (no disk/sprites/audio) won't moves keep completing in 8 cycles (this seems to be the case in WinUAE at least and matches my reading of the HRM)? [0]: http://coppershade.org/articles/AMIG...t_WAIT_Timing/ MOVE INSTRUCTION TIMING

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Combining copper scrolling with copper background	phx	Coders. Asm / Hardware	16	13 February 2021 12:41
Have you played Banshee? If not what are you waiting for?	vroom6sri	Amiga scene	14	18 June 2013 01:01
Resource - end-of-line comments	demolition	support.Apps	2	15 January 2013 14:56
Waiting for disk activity to finish	Dreedo	project.WHDLoad	11	07 December 2010 16:07
Which game would you prefer to play while waiting for XCopy to copy Project-X Disk 1?	killergorilla	Nostalgia & memories	29	11 January 2007 15:59

26 June 2014, 15:49	#2
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,528	$e2 is last cycle of line, not $e3. Try $e1 or $df.

26 June 2014, 18:03	#3
h0ffman Registered User Join Date: Aug 2008 Location: Salisbury Posts: 744	tried that, didnt seem to make a difference.

26 June 2014, 18:10	#4
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,528	If you mean lines >=128 does not appear to work correctly, check HRM copper loop example for explanation. (E3 should work, I forgot that bit 0 is not part of hpos)

08 July 2014, 14:38	#7
h0ffman Registered User Join Date: Aug 2008 Location: Salisbury Posts: 744	I scrapped it in the end and made it wait for the end of each line but also specified the vpos too.

11 July 2014, 09:49	#8
Alexco Registered User Join Date: Jun 2008 Location: outer space Posts: 60	I have a somewhat similar question. While playing around with old sources of mine I found an issue with waiting for raster lines >$ff I do not understand. I wait for the end of a raster line with $xxe5 fffe to switch color00. This works for all lines <=$ff. For lines after that it seems that copper interprets $ffe5 as end of copper list. If I change only the $ffe5 to $ffe1 or $ffdf the other lines (>$ff) are executed normally. But this creates a small step in the color effect in this line since $e1 is in the visible area of the screen. So why is line $ff different? Tested that on WinUAE 2.8 only. Is this the same on real hardware?

11 July 2014, 11:11	#9
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,528	Include part of the copper list with copper debugger enabled. shift+f12, od <return>, g <return>, shift+f12 again, o1 or o2 to dump the copper list, o to continue dumping. There are some side-effects if WAIT instruction is executed near the end of scanline, hpos can wrap around just before copper does first vpos&hpos comparisons. (For example Superfrog's copper list's normal looking ffdf fffe wait at address 73a0 won't wake up)

11 July 2014, 17:26	#11
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,528	It is correct behavior. Waiting for non-existing hpos (0xe4) will still exit wait state if current vpos is larger than waiting vpos. FEE5 wait will exit at beginning of next line because vpos FF > FE but waiting for FFE5 keeps waiting (until end of field) because next line will be zero and smaller than FF. xxE1 hpos >= 0xe0 check will exit the wait normally. (unless bitplane DMA steals all cycles from copper, delaying the wait) Copper wait exit condition has two parts: if current vpos > waiting vpos: exit, ignore hpos. Only if current_vpos == waiting_vpos hpos is also checked.

11 July 2014, 22:49	#12
Alexco Registered User Join Date: Jun 2008 Location: outer space Posts: 60	Ahh. Thanks. So in fact, my copper list from around 1990 just worked "by accident" and stopped working now because I extended it to lines >$ff :-). Can you also please explain what the debug output means?

13 March 2017, 16:40	#17
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,528	What about using COP2JMP? Replace 00xx wait with COP2JMP which does the extra wait, resets COP2LC and COP2JMPs back to original copper list?

13 March 2017, 19:53	#19
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,528	You can save one move if both copperlists are located in same 64k block, only need to update COP2LCL.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)