19 December 2021, 01:15 | #1 |
Registered User
Join Date: Jun 2020
Location: Druidia
Posts: 389
|
Copper Wait Masks
Hi
I'm trying to understand as much as possible how the copper wait masks work for some copper loops I'm having trouble with. What I really don't understand is why some h-positions cause different behavior than others. Here is an example copper list that works to change color0 each line for 8 lines. Code:
0x2c01, 0xfffe, 0x0180, 0x0f00, 0x00e1, 0x80fe, 0x0180, 0x0800, 0x00e1, 0x80fe, 0x0180, 0x0ff0, 0x00e1, 0x80fe, 0x0180, 0x0880, 0x00e1, 0x80fe, 0x0180, 0x00f0, 0x00e1, 0x80fe, 0x0180, 0x0080, 0x00e1, 0x80fe, 0x0180, 0x00ff, 0x00e1, 0x80fe, 0x0180, 0x0088, 0x00e1, 0x80fe, 0x0180, 0x000f, 0x00e1, 0x80fe, 0x0180, 0x0008, 0x00e1, 0x80fe, 0xe1 seems to be the last h-position. And so the code mostly does what I'd like but there's a visible step at the right edge. If I change 0xe1 to something later or earlier in h-pos then things stop working. Actually any h-pos from 0xd7...0xe1 is fine. But earlier will cause the waits to be ignored. And later will cause them to never finish. I think later waits are just never finishing because h-pos really never gets that large. But the earlier waits confuse me. Can anyone explain this more for me so I know exactly what I'm dealing with for copper loops? Thanks |
19 December 2021, 03:13 | #2 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,068
|
Yes, $e1 is the last allowed *wait* position (but not the last overall position from the HW's point of view, you could say), and if you change a color at that point the very last part of the current rasterline will still be affected. That is normal behaviour, wait for $01 in the next rasterline to avoid it.
If you use too low horizontal wait position you will still be in the same rasterline after a move to $0180 and the wait condition will be fulfilled again (copper is using >=). |
19 December 2021, 03:37 | #3 |
Registered User
Join Date: Jun 2020
Location: Druidia
Posts: 389
|
I get that. But I’m still confused why it still works when my hpos wait is $d7
What you seem to imply is that I would need a wait for the start and one for the end. What I’d like is just one wait for each line. That works if you wait on $e1 but breaks for the pal split. I’m also trying to use a skip and so that needs to happen before the line end. So I suppose I’m asking if one wait per line for a loop is possible. |
19 December 2021, 04:33 | #4 | |||
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,068
|
Quote:
Quote:
Quote:
Are you trying to do everything with a single skip or with a wait+skip pair (eg. wait to sync a line horizontally, skip to repeat until specific vertical line)? |
|||
19 December 2021, 05:04 | #5 |
Registered User
Join Date: Jun 2020
Location: Druidia
Posts: 389
|
What I'm really trying to do is modify bplxmod each line so it'll cause the same line to be repeated 3 times.
I'm trying to set this up so it'll work across both the 128/0 and 255/0 splits. I'm running into trouble and I'm not entirely sure why, but the parts I don't understand are: - when is the end of the line for a wait or skip. - is there some time inbetween then and the beginning of the next lines. - and also when exactly is bplxmod added, since I need to change it at the correct time. The current setup has a copper list with multiple repeating sections to help with the splits because 3x doesn't sit nicely on the splits. Anyway the copper repeat sections is of this form: Code:
Move cop2lch // set the loop start Move cop2lcl Move copjmp2 // trigger loop (might need to start part way through) Move bpl1mod Move bpl2mod Wait end of line Move bpl1mod Move bpl2mod Wait end of line Move bpl1mod Move bpl2mod Wait end of line Skip end of section line // end the loop at a specified line Move copjmp2 // trigger loop jump I suspect the problem is the interplay between the last wait end of line and the skip. For the splits the vpos has probably already advanced. But I'm just not sure if that's it or what might be a better set up. BTW thanks for the help! |
19 December 2021, 06:03 | #6 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,068
|
I typically don't use a skip for that (just a simple repeat height/pixel_size loop with: wait line, 2x move -mods to repeat, wait line+pixel_size-1, 2x move zero mods to advance; waits can be start of line eg. $2c01 or end of previous line $2bdf) because it's slower and space is generally not a problem, but if you are modifying bplxmod writes then it would make sense so you don't have to update way too many entries.
Yeah, 3x is not very user friendly, I'd shift the whole thing a line up or down to get $ffdf covered for free by with one of the waits. Modifying bplxmod around start/end of a line never caused me any problems, I'd guess mods are added at the end of a dma window. Your setup looks logically ok to me, but yeah, you never know when you plug in actual numbers and especially masks. |
19 December 2021, 06:26 | #7 |
Registered User
Join Date: Jun 2020
Location: Druidia
Posts: 389
|
For the 255-0 split is there something special about waiting for $ffdf versus waiting for $ffe1?
|
19 December 2021, 06:41 | #8 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,068
|
Better compatibility with old chipsets (I used to be in the $e1 camp back in the early days but then read somewhere it's safer to use $df).
|
20 December 2021, 17:20 | #9 |
Registered User
Join Date: Jun 2020
Location: Brno
Posts: 90
|
|
02 May 2024, 12:58 | #10 | |
German Translator
Join Date: Aug 2018
Location: Drübeck / Germany
Age: 49
Posts: 200
|
Quote:
Code:
dc.w $2c01, $fffe dc.w $0180, $0f00, $2ce1, $fffe dc.w $0180, $00f0, $2de1, $fffe >v $2d $d8 [E0 -] [E1 -] [E2 -] W >v $2d $0 Line: 2D 45 HPOS 00 0: [00 -] [01 -] [02 -] [03 -] [04 -] [05 -] [06 -] [07 -] COP 08C RFS0 03C COP 180 RFS1 1FE COP 08C RFS2 1FE C 0180 *= 00F0 *F 00E1 0002BCEC 000256F8 0002BCEE 000256FA 0002BCF0 000256FC 176 05E 17C 02B 177 05E 17D 02B 178 05E 17E 02B Why does the color change not take place in the new line as one would expect, but still on the old line on the right-hand edge? (Agnus/Denise counter?) |
|
02 May 2024, 14:20 | #11 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,501
|
Quote:
The display device knows absolutely nothing about what is happening in the chipset and therefore what it can do is waiting the horizontal blank (which prepares the coverage of the synchronism signals when the composite video is used in output, Denise takes care of this) and the hsync pulse for 'the line is physically finished, go back to the left and draw a new one' (and Agnus takes care of this). These signals are quite close to the start of Agnus'/Denise' counters, but certainly not in cycle 0 [I'm not going to describe where they actually are and how they are managed, the discussion would be very of topic and out of context, in any case there are other threads where it is described, for example the one about undocumented stuff] However, why the counters and the end of line are managed this way is clear: there are many DMA cycles that do not exclusively affect the display and it is logical to perform it during horizontal blank, or better, immediately after the last possible bitplanes DMA cycle (refresh, disk, audio..). And since the actual display of fetched data can also be delayed (see BPLCON1), and therefore displayed in the extreme right part of the line, both the blank and the sync must be carried out 'later' the last cycle of the line. I hope it's a little clearer about the reasons behind the designers' choices |
|
02 May 2024, 18:03 | #12 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,386
|
I found out that with fmode=3 ffdf doesn't work,ffcf does
|
02 May 2024, 18:30 | #13 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,501
|
It depends on the different allocation of the bitplane DMA fetches.
To wake up the Copper requires that the cycle is available (CPU can use it) and if by chance it is used by another DMA channel you must wait for the first free slot. Just try hires with FMODE=0 and 4 bplanes enabled (and large DDFs). You probably have to use a much much smaller value than ffcf |
02 May 2024, 20:27 | #14 |
German Translator
Join Date: Aug 2018
Location: Drübeck / Germany
Age: 49
Posts: 200
|
@ross Thank you very much! It's always a pleasure to read your well-founded answers.
Yes, sometimes I still find it difficult to look at display and DMA control separately or to relate them to each other. But in terms of Copper loops, the masked wait dc.w $00e1, $80feat the end of the line is the most appropriate. And to get rid of the annoying "artefact" at the edge, I can only see one way to mask it somehow E.g. with a sprite over the entire screen height, which is placed exactly here or perhaps also with bitplane data, if we already need bitplane DMA for this strip anyway. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
copper wait glitch | chadderack | Coders. Asm / Hardware | 6 | 15 October 2021 15:18 |
Copper WAIT, copper SKIP and $80/$100 vpos problem | defor | Coders. Asm / Hardware | 2 | 23 July 2021 08:32 |
Copper wait | geldo79 | Coders. Asm / Hardware | 9 | 12 November 2019 09:18 |
Copper Wait Problem | sandruzzo | support.WinUAE | 13 | 18 May 2016 21:54 |
Copper Wait Problem | sandruzzo | Coders. Asm / Hardware | 2 | 17 May 2016 10:30 |
|
|