- I would guess the copperlist also needs to include a WAIT-instruction for each rasterline to ensure a stable timing. Or is it sufficient to just wait for the first line and then just do all the MOVEs?
Do a wait for the start of each line as well.
I would assume it is best to use two copperlists (one is currently executed while the beam is running, the other being filled for the next frame, then swap the two on vsync)?
In some cases you might do with a single-buffered list, but this is mainly the way to do it.
Having an intermediate buffer is a waste of (a lot of) cycles unless you need the buffer for something else.
sometimes I read about 3x2 copper chunky modes or similar - what is meant by this?
Instead of changing the _same_ color register over and over again (which'll give you a minimum horizontal resolution of 8 pix) you draw vertical lines in different colors and then set different color registers per pixel on a line. As long as the color register is written before its corresponding pixels is drawn you're good.
This gives you more control over the horizontal per-pixel resolution but you trade it against the maximum number of chunky pixels per scanline. (Enabling more bitplanes will steal DMA-time).
Depending on your specific case you can of course play around with different trade-offs and variations.
Using multiple bitplanes for your chunky pixels is of course also a nice way of dithering the boundaries between the chunky pixels.
- Using medres/hires to visually reduce the blockiness of the copper "pixels" would be too slow?
It's the copper-write-delay that limits you to 8pix, not the resolution, so this would have no effect there.
Also, the additional DMA traffic would likely slow you down as well.