Changing 3 registers every 16 horiz. pixels via Copper

[Quagliarulo]

Hello, I'm on OCS and I have 2 bitplanes. DMA for sprites and audio will need to be enabled as well, if I get anywhere with this project.
My screen is made up of 16x16 pixels tiles, 2 bitplanes each.
I need color 0 to always be black and I'd like to set the other 3 colors on a per-tile basis, through a very very long copperlist (I'm trying to use the fewest possible bitplanes to get more freedom for sprite colors).
I tried, but I ran into 2 problems:
- The least significant bit of the horizontal position must be 1
- The Copper's response comes too late, that is, it won't change the colors 16 pixels after the last change.
Is this doable or should I just increase the number of bitplanes?

[DanScott]

With 4 (or less) bitplanes enabled, you can only write to one hardware register every 8 low-res pixels

The trouble is, for what I interpret as what you want to achive, the colour changes will affect the tiles "before" the destination tile.

[Jobbo]

With a 3 bitplane screen you could reserve 2 unique colors for each 16x16 tile and then have the background and three other colors as shared.

You'd then want to have two copies of each tile so you could blit ones that used alternating unique colors each column.

Then your copper list could change 2 colors every 16 pixels ahead of the tiles about to be displayed.

You would probably want to setup a looping copper list so it'll repeat the same color changes for 16 lines.

It'd be like the color attributes on the Speccy.

Horizontal scrolling would be limited to 4 pixel steps since the copper wait for a line can gives you 4 pixel accuracy.

I think it's an interesting quirky idea, not sure anyone has taken advantage of something like that in any meaningful way in the past.

[Thomas Richter]

Originally Posted by Quagliarulo

My screen is made up of 16x16 pixels tiles, 2 bitplanes each.
I need color 0 to always be black and I'd like to set the other 3 colors on a per-tile basis, through a very very long copperlist (I'm trying to use the fewest possible bitplanes to get more freedom for sprite colors).

Is this doable or should I just increase the number of bitplanes?

This wouldn't work. The copper cannot instantaneously change two (or more) colors at once. Reading a command and executing a command takes some time, and hence takes some space on the screen.

[roondar]

Originally Posted by Jobbo

I think it's an interesting quirky idea, not sure anyone has taken advantage of something like that in any meaningful way in the past.

That is indeed a very interesting setup!
Not too sure about the DMA costs vs the benefits but it's certainly a neat trick

[Hypex]

That's a neat idea. I've thought of these tricks myself. I think it could work but you may need an extra plane. Essentially you will need to double buffer or interleave the operations.

So, the first tile, you will need to change the colours before it appears. Say 16 pixels before, depending on how long your changes need. Then wait for first tile left pixel position. Now write the colours for the second tile while the first is displaying. Wait for the next tile. Rinse and repeat, so to speak.

Your tile bitmap will need be set up so the tiles are interleaved. First tile has one palette, second tile other palette. So tile 1 would be colours 0 to 3, tile 2 colours 4 to 7. Then loop across. You would share colour 0 and reuse colour 4 if you don't need it.

Using the top bitplane as a msb should do the switching trick, With a checker pattern. So one palette is lower, then other is higher.

The timing used to be one copper write every four pixels, but I don't know if it can be kept constant at the timing. I note the issue with scrolling, but it should be possible to still scroll if the palettes are set in time before each tile. Or you will get a C16 style soft sprite back block effect. :P