26 June 2014, 14:42 | #1 |
Registered User
Join Date: Aug 2008
Location: Salisbury
Posts: 746
|
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 |
26 June 2014, 15:49 | #2 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,545
|
$e2 is last cycle of line, not $e3. Try $e1 or $df.
|
26 June 2014, 18:03 | #3 |
Registered User
Join Date: Aug 2008
Location: Salisbury
Posts: 746
|
tried that, didnt seem to make a difference.
|
26 June 2014, 18:10 | #4 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,545
|
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)
|
05 July 2014, 23:37 | #5 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,647
|
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. |
06 July 2014, 01:57 | #6 | |
AMOS Extensions Developer
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 44
Posts: 1,924
|
Quote:
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 |
|
08 July 2014, 14:38 | #7 |
Registered User
Join Date: Aug 2008
Location: Salisbury
Posts: 746
|
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 |
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 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,545
|
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:01 | #10 |
Registered User
Join Date: Jun 2008
Location: outer space
Posts: 60
|
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 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 |
11 July 2014, 17:26 | #11 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,545
|
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 |
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? |
12 July 2014, 09:51 | #13 | ||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,545
|
Quote:
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:
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. |
||
12 July 2014, 16:06 | #14 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,647
|
My article did explain these positions past $xxdf make a following move execute on the next line.
Code:
... $fedf,$fffe $ffdf,$fffe $00df,$fffe ... 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 ... Last edited by Photon; 08 January 2016 at 01:26. |
12 March 2017, 10:52 | #15 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,172
|
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 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 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 ... 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 |
13 March 2017, 00:17 | #16 |
Registered User
Join Date: Oct 2013
Location: Hamburg
Posts: 70
|
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 Last edited by losso; 13 March 2017 at 12:40. Reason: did not read, sry |
13 March 2017, 16:40 | #17 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,545
|
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:05 | #18 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,172
|
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.
|
13 March 2017, 19:53 | #19 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,545
|
You can save one move if both copperlists are located in same 64k block, only need to update COP2LCL.
|
13 March 2017, 20:14 | #20 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,172
|
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
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
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 |
|
|