Copper lists are hard

[deimos]

I'm trying to build a copper list that changes colour 0 at the start and end of each line, complicated by also changing bit depth part way through. It's nearly there, but in trying to fix one bit (circled in orange in the first picture, I end up with everything falling apart in a way that I just don't understand.

Could someone please fill this gap in my knowledge?

In the "before" picture things look like they're working, with colour changes before and after the rollover being taken care of, but with some stuff going wrong within the orange circle.

When trying to fix the orange circle by adding an extra wait:

        // I thought this would fix it
        //
        COP_INSTR(0x80db, 0x80fe)
        COP_INSTR(COLOR00, 0xccf)
        //
        // but it made it worse

All the stuff after the rollover stops happening, even though the bit I fixed was way before that.

I don't understand, and I don't know where to look apart from the HRM.

I've attached the code I use to generate the copper list and a hex dump of the results.

[ross]

Sure the change from y=80 to y=00 is at roll-over?

Can you post an exe?

[deimos]

Originally Posted by ross

Sure the change from y=80 to y=00 is at roll-over?

Can you post an exe?

I can post an exe tomorrow, everyone's in bed here now.

I'm not getting this rollover thing. I get that there's only 8 bits and it starts counting over when it gets past 255, but I thought that happened when the I start showing red in the before picture, long after the code I added.

[ross]

Originally Posted by deimos

I can post an exe tomorrow, everyone's in bed here now.

I'm not getting this rollover thing. I get that there's only 8 bits and it starts counting over when it gets past 255, but I thought that happened when the I start showing red in the before picture, long after the code I added.

I'm sure that with the exe I can tell you what happens

At tomorrow.

[a/b]

Based on generator code, it looks like your split screen starts at line $dc.
And based on copper list dump, you are changing a bunch of bitplane stuff right at the very end of line $db leading into line $dc (bplcon0, modulos, bitplane pointers), all while display DMA is still enabled. I'd try setting $0100 (bplcon0) to $0200 first, then change stuff, and finally set $0100 to $3200.
Plus there's also a $008a trigger, so maybe check if you can squeeze all that stuff within horizontal blanking, otherwise you'll need an empty line.

[ross]

hmm, I downloaded the image and zoomed in because I didn't see it well

And I realized that you change too many registers with the copper and therefore the color is changed to a point far from the edge.
Change all others first and then COLOR00 when the time is right.

EDIT: OK, a/b before me

[ross]

But I think the problem is at first 0x8037 0x80FE after bplcon0, modulos, bitplane ptrs changes.

[deimos]

Here is the executable for the "before" image.

[deimos]

Originally Posted by a/b

Based on generator code, it looks like your split screen starts at line $dc.
And based on copper list dump, you are changing a bunch of bitplane stuff right at the very end of line $db leading into line $dc (bplcon0, modulos, bitplane pointers), all while display DMA is still enabled. I'd try setting $0100 (bplcon0) to $0200 first, then change stuff, and finally set $0100 to $3200.

This made almost no difference. There is now a tiny black dot near the start of the first line after the split. But it sounds like you don't like me changing bitplane stuff while display DMA is running, so I should leave it in?

        ...
        COP_INSTR(COPJMP2, 0x0000)

        COP_INSTR(BPLCON0, COLORON)

        COP_INSTR(BPL1MOD, INSTRUMENTS_DISPLAY_MODULO - 2)
        COP_INSTR(BPL2MOD, INSTRUMENTS_DISPLAY_MODULO - 2)

        COP_INSTR(BPL1PTH, HIGH_WORD(secondaryBuffer))
        COP_INSTR(BPL1PTL, LOW_WORD(secondaryBuffer))
        COP_INSTR(BPL2PTH, HIGH_WORD(secondaryBuffer + DISPLAY_WIDTH_IN_BYTES))
        COP_INSTR(BPL2PTL, LOW_WORD(secondaryBuffer + DISPLAY_WIDTH_IN_BYTES))
        COP_INSTR(BPL3PTH, HIGH_WORD(secondaryBuffer + 2 * DISPLAY_WIDTH_IN_BYTES))
        COP_INSTR(BPL3PTL, LOW_WORD(secondaryBuffer + 2 * DISPLAY_WIDTH_IN_BYTES))

        COP_INSTR(BPLCON0, INSTRUMENTS_DISPLAY_DEPTH << PLNCNTSHFT | COLORON)

        COP_INSTR(0x8037, 0x80fe)
        ...

[deimos]

Originally Posted by ross

But I think the problem is at first 0x8037 0x80FE after bplcon0, modulos, bitplane ptrs changes.

So, currently, with a/b's changes, I get black until the edge of the display window, 3 pixels of 999 light grey, 1 pixel of black, a bunch of 777 grey, then 8? pixels of 070 green before 977 pink.

So that big chunk of 777 grey is from line 4 to end - 2 below:

        COP_INSTR(BPLCON0, INSTRUMENTS_DISPLAY_DEPTH << PLNCNTSHFT | COLORON)

        COP_INSTR(0x8037, 0x80fe)
        COP_INSTR(COLOR01, BLACK_RGB) // deliberate ordering
        COP_INSTR(COLOR00, 0x777)

        COP_INSTR(COLOR02, 0xccc)
        COP_INSTR(COLOR03, 0x999)

        COP_INSTR(COLOR04, 0x444)
        COP_INSTR(COLOR05, 0xfff)
        COP_INSTR(COLOR06, 0x0f0)
        COP_INSTR(COLOR07, 0x00f)

        UWORD row = 0;

        for (UWORD i = 0xdc; i <= 0xff; i++) {
            COP_INSTR(0x8037, 0x80fe)
            COP_INSTR(COLOR00, 0x070) // replace with something useful
            COP_INSTR(COLOR00, 0x977) //// pink grey

So, basically the first 0x8037 0x80fe in the loop is triggering. I need to finish the line I'm on before entering the loop. Which must have been what I was trying to do with 0x80db 0x80fe, COLOR00 0xccf, but that broke everything.

Attached is an executable with those extra lines added.

[deimos]

Originally Posted by ross

Sure the change from y=80 to y=00 is at roll-over?

No, if I fiddle with the number of iterations the first loop does so that the change to y=00 occurs one row earlier, things look like they work. But now I'm not sure my maths adds up.

        COP_INSTR(COLOR05, 0xfff)
        COP_INSTR(COLOR06, 0x0f0)
        COP_INSTR(COLOR07, 0x00f)

        // this does fix it
        
        COP_INSTR(0x80db, 0x80fe)
        COP_INSTR(COLOR00, 0xccf)
        
        // if I start the loop below from dd instead of dc

        UWORD row = 0;

        for (UWORD i = 0xdd; i <= 0xff; i++) {
            COP_INSTR(0x8037, 0x80fe)
            COP_INSTR(COLOR00, 0x070) // replace with something useful
            COP_INSTR(COLOR00, 0x977) //// pink grey

[ross]

Your code is working now?

[deimos]

Originally Posted by ross

Your code is working now?

Yes, I think so. I've even managed to fix the black dot that disabling the bitplanes during the split introduced.

I'm going to work on it a bit more before calling it done though.

[deimos]

So, everything works until I actually try to use it.

My current problem is bad screen glitches when I swap in a new copper list for my triple buffering. This glitch only lasts for a screen refresh before it corrects itself. I know the copper list isn't changed between when it's glitched and when it's back to working. It doesn't happen all the time, or consistently either.

I change my copper lists during a copper interrupt at the bottom of the screen, before the vertical blank happens, and I just update cop1lc, I don't touch copjmp1.

I do do some timing sensitive stuff in the copper lists, like changing colours at exactly the right place, and I've fiddled with bplcon1 to get the colour changes to line up just so, but I don't why that would affect anything, or if it did, why it would only be for a millisecond.

[deimos]

Originally Posted by deimos

So, everything works until I actually try to use it.

Nevermind, it works now.