DblPAL vs changing the screen bitmap using Copper

[BSzili]

To implement the EGA split screen mode in Catacomb 3D, I'm using a custom copper list that changes the bitplane pointers at the correct line. This work well with the good old PAL monitor, but for some reason the 4th bitplane is missing with DblPAL. This is how the custom copper list looks like:

#define BPLPTH(p) (*((UWORD *)&custom.bplpt[0] + (2 * (p))))
#define BPLPTL(p) (*((UWORD *)&custom.bplpt[0] + (2 * (p)) + 1))
#define HIWORD(x) ((ULONG)(x)>>16 & 0xffff)
#define LOWORD(x) ((ULONG)(x) & 0xffff)

static void BEL_ST_AddSplitlineCopList(uint16_t splitline)
{
    struct TagItem uCopTags[] =
    {
        {VTAG_USERCLIP_SET, NULL},
        {VTAG_END_CM, NULL}
    };
    int i;

    if ((ucl = AllocMem(sizeof(struct UCopList), MEMF_PUBLIC|MEMF_CLEAR)))
    {
        CINIT(ucl, 16);
        CWAIT(ucl, splitline, 0);
        for (i = 0; i < 4; i++)
        {
            CMOVE(ucl, BPLPTH(i), HIWORD(&g_sdlVidMem->egaGfx[i][0]));
            CMOVE(ucl, BPLPTL(i), LOWORD(&g_sdlVidMem->egaGfx[i][0]));
        }
        CEND(ucl);

        Forbid();
        g_amigaScreen->ViewPort.UCopIns = ucl;
        Permit();

        VideoControl(g_amigaScreen->ViewPort.ColorMap, uCopTags);
        RethinkDisplay();
    }
}

Is there anything obviously wrong with this? How can I change the 4th bitplane on the DblPAL monitor?

PS: I tried opening a second child-screen, but that way I lose about 3 scanlines between the two screens, and it introduces a few other quirks I'd have to work around. I'm mainly interested in what's wrong with my copper list.

[Toni Wilen]

Perhaps your copper list triggers chipset "feature" that causes DMA pointer register write to do nothing (written value goes nowhere) if exactly following cycle is DMA fetch that uses same pointer register. Does anything change if you modify order of bitplane register writes?

(Emulation copper and dma debugger are nice tools to debug these kinds of copper list problems)

[BSzili]

You are onto something, reversing the order of the for loop appears to have fixed the problem! Thanks for the help!
I'll check out the debugger too. It will come in handy the next time I run into something like this.