Split screen with a copper list - changing all the colours in time
 

I want to do a split screen using the copper, changing the 4 bitplane pointers and the colour registers at the split point.

It looks to me like I don't have time to do that, by the time I've set all 16 colours I'm well into the first row of the lower half of the screen.

Is this a limitation I have to work with, or am I doing it wrong?

I can imagine at least two ways to work around it, either a black line built in, or choosing the order that I change the colours smarterly, or maybe even changing less colours, or changing half of them on the second line so my first line can have something other than blackness.

Hints?

You are correct that you'll likely not have time to do this between lines (assuming OCS and a 320 pixel wide display). You can normally fit 16 Copper move instruction during the Horizontal Blank for such a display*. So if you also want to set 4 bitplane pointers and you need both high and low to be set, it won't fit.

That said, you might be able to still do something if you store your bitplanes cleverly in memory and reduce the screen to 304 pixels wide: if the bitplanes you wish to switch between are located at less than 32768 bytes away in memory, you can also do the switch using the modulo registers instead. That way you'd need only 18 moves rather than the 24 you need at the moment.

However, that does mean having a memory setup where this works. Which will be tricky and almost certainly makes interleaved bitplanes impossible.

*) technically 16,5 IIRC, though there might be a difference between PAL and NTSC here

Thanks. I think the best approach for me is to arrange my colour palette and the first line of my lower half so that I can pretend the problem isn't there.

This must have made things interesting for the people doing sliced ham mode stuff back then.

AFAIK sliced HAM gfx didn't update the bitplane pointers between slices, only the colours - so that should still work in the horizontal blanking period.

Oh of course, 16 moves.

Or if you really like crazy stuff, do it with Copper+CPU ;)

Let's not go there.

Wise choice :)

Looking at this with my rational hat near by, I can change 10 colours in time (assuming I don't need to add anything else into the copper list at that point), so there are 6 colours that I either don't change, or design my stuff knowing that they're not ready at the start of that first line. That doesn't sound like much of a hardship.

There is also another trick you can use regarding bitplane pointers and that is to modify only the top of the register(s).
If the splitted bitmap is exactly 64k (or multiple) away from the value present in the ptrs prior to the split then you can modify only 4 registers.

I'm not going there. 'Tis a silly place.

There are several ways to limit the number of copper moves to set bitplane pointers:
- have all bitplanes within a single 64KB bank (e.g. $6xxxx), so that all the upper words are constant and you only have to change 4 lower words, or
- have both bitmaps 64KB aligned (e.g. $60000 and $70000), so that all the lower words are constant and you only have to change 4 uppper words.
You can use AGA colorbank swaping or OCS/ECS 7-bitplanes trick to swap all 16 colors with a single copper move:
- set bplcon0 to $4200 if AGA, $7200 otherwise,
- set bpl6dat to 0 to cancel half-bright mode,
- set bpl5data to $0000 to activate colors 0-15 or $ffff to activate colors 16-31.

So, pretending to be in 6bp mode, but forcing in all zeros or all ones? Am I understanding?

The drawback would be losing control of the colours that you'd use for sprites though, wouldn't it?

Yes, bitplane DMA will fill in bpldat1-4, but all 6 bitplanes will be active so you can then change bpldat5-6 manually with cpu/copper at any time.
If you are using sprites, yeah bad luck then as they are using colors 16-31 ;P.

I think I'd rather work around the limitations of a few colours being unavailable for a few dozen pixels.

The hardest part will be explaining the limitations to the person who draws the graphics for me.

And I forgot one obvious thing when it comes to bitplanes, you can typically achieve the same by only changing the modulos, but since I don't know the details (you seem to have the bitmaps quite apart, more than 16-bit modulos can ever handle) it's hard to tell.

Roondar did mention the modulo option, but, really, "just don't use these 6 colours in the first quarter of the first line" seems like a much easier thing. To me, the muppet writing the code, anyway.

This always made me think about what a huge wasted opportunity in the design phase to use only the BPU bits and not a mask for selective activating the bpl DMA channels :rolleyes

EDIT:
removed my reply to another user in a multi-quote deleted message, perhaps the user prefers it that way

Another solution is to not use all 'new' colors in first line - with careful sorting what colors need to appear as first you may use two slots to alter all 16 CLUT entries.
This apply to last line with 'old' colors - perhaps no all CLUT entries need to be used so you can distribute change across few lines.

Don't even need the copper. There are enough cycles for a pair of movem.l instructions -- one for the bitplane pointers and one for the color registers.

CPU registers must be preloaded of course.