help me fix this copper "effect"

[jotd]

What I'm trying to do is to change one color, taking advantage of the fact that there are 8-pixel blocks that hide it.


I know that there's a delay when you change a color but I can't seem to tune it properly. The changing color (line which is red/blue/green/yellow...) starts too late/ends too soon at places, and sometimes it's perfect.






Here's the code (copperlist) I found by a lot of trial and error but it's still not okay. Can you help me fix it? or what I'm asking is not possible? (using AGA + fmode=3)

    .word    0x4441,0xFFFE
    .word    color,0xF0
    .word    0x4453,0xFFFE
    .word    color,0xF00
    .word    0x4461,0xFFFE
    .word    color,0xF0
    .word    0x4469,0xFFFE
    .word    color,0xF4F
    .word    0x4477,0xFFFE
    .word    color,0xF
    .word    0x4495,0xFFFE
    .word    color,0xFF0
    .word    0x449B,0xFFFE
    .word    color,0xF0F
    .word    0x44B1,0xFFFE
    .word    color,0x0

[a/b]

1. How many bitplanes, more than 4? Even with fetch=1/2/3 the copper can be slowed down.
2. Copper's horizontal resolution is lower than lores (320), writes to color registers can't be pixel perfect. You can select every fourth pixel: 50% lower resolution, waits can only select every other position, bit0=0 means it's a move, so that's another 50% reduction.

[chb]

AFAIR, in higher fetch modes the display DMA is not uniformly distributed; e.g in eight planes lores with fmode=3 for eight consecutive memory cycles (16pix) bitplane data will be fetched, leaving no free cycles for copper or CPU, then afterwards bitplane DMA is inactive for 24 mem cycles. Does that explain the observed behavior?

[ross]

To add to what a/b and chb rightly said.

This may or may not be possible, it depends on several factors, the data you provided is not enough for a precise or definitive answer.
We also need the values of BPLCON0, BPLCON1, DDFSTRT and possibly also the bitmap (basically a test executable..).

However from your Copper list it is very clear that the bitplane DMA fetches are interfering, the wait positions values are too erratic.

[jotd]

right, it's best with a test exe.

Find "elevator_action_aga.zip" in the zone. It has a whdload starter too, and crashes when click on LMB

[ross]

Fix:

    .word    0x4435,0xFFFE
    .word    color,0xF0
    .word    0x4455,0xFFFE
    .word    color,0xF00
    .word    0x01fe,0xFFFE
    .word    color,0xF0
    .word    0x4475,0xFFFE
    .word    color,0xF4F
    .word    0x01fe,0xFFFE
    .word    color,0xF
    .word    0x4495,0xFFFE
    .word    color,0xFF0
    .word    0x01fe,0xFFFE
    .word    color,0xF0F
    .word    0x44B5,0xFFFE
    .word    color,0x0

Uses the fact that a simple CNOP is sufficient for waiting (due to bitplane fetches in certain areas) and evenly distributes the CWAITs.

[jotd]

I don't think I could have found that! thanks. Works a treat.