Copper Wait Masks

[Jobbo]

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.

	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,

It's fairly simple stuff. It waits for start of line 0x2c, then repeatedly changes color0 and waits for 0xe1 h-pos.

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

[a/b]

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 >=).

[Jobbo]

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.

[a/b]

Originally Posted by Jobbo

I get that. But I’m still confused why it still works when my hpos wait is $d7

Because after all the work is done (1 move, load next wait) the copper has already switched to the next line and the same wait condition >=$d7 is not automatically fulfilled.

Originally Posted by Jobbo

What you seem to imply is that I would need a wait for the start and one for the end.

If you wait for a too early position then a single wait won't do. I'm sure you understand that but I don't know what exactly are you trying to accomplish (with skip etc.) so I can only restate that..

Originally Posted by Jobbo

What I’d like is just one wait for each line. That works if you wait on $e1 but breaks for the pal split.

Do you mean vertical wrap $ff to $00? That should work just fine, I typically use $(ff)df in such cases to get it for free while waiting for something else.

Originally Posted by Jobbo

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.

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)?

[Jobbo]

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:

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

Don't know if that makes it clear.

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!

[a/b]

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.

[Jobbo]

For the 255-0 split is there something special about waiting for $ffdf versus waiting for $ffe1?

[a/b]

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).

[defor]

When is the modulo added to the bitplane pointers?
Copper - waiting for the end of a line

[Rock'n Roll]

Originally Posted by Jobbo

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.

	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

I wait for the end of the line and the copper move for the color change takes place in the next line.
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?)

[ross]

Originally Posted by Rock'n Roll

I wait for the end of the line and the copper move for the color change takes place in the next line.
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?)

What you call "end of the line" is actually just the Agnus horizontal counter reaching its maximum hardwired value before incrementing the vertical counter (actually it's not exactly the cycle in which the increment occurs, but that's another question...).

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

[jotd]

I found out that with fmode=3 ffdf doesn't work,ffcf does

[ross]

Originally Posted by jotd

I found out that with fmode=3 ffdf doesn't work,ffcf does

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

[Rock'n Roll]

@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, $80fe

at 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.