A.D.A. Amiga Demoscene Archive

Hi everybody,

I am still very new to amiga programming and am trying to understand how to implement a OCS "copper chunky" mode in more detail. So far I could only find rather brief explanations.

From what I grasped, the basic concept is to fill a huge copper list with MOVE-instructions to set the color register value for each "chunky" pixel. Due to bus bandwidth/timing restrictions the copper can change the color only every 8 pixels, resulting in a horizontal resolution of 40 chunky pixels.

My questions:

- 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?

- when filling the "chunky buffer": Do you write the color values directly into the prepared copperlist, i.e. poke the color values directly into the "dc.w $0180,$0xxx" command stream? 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)? Or fill a intermediate WORD-buffer first and then copy values into the copperlist during vblank?

- sometimes I read about 3x2 copper chunky modes or similar - what is meant by this? I thought you can change the pixel color only every 8 pixels? Are these modes using some kind of blitter filling to set additional pixels?

- Using medres/hires to visually reduce the blockiness of the copper "pixels" would be too slow?

Maybe someone of you could give some hints :) Are there some other "best practices" I should be aware of?

Do a wait for the start of each line as well.


Yes. :)
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.


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.



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.

wow, thanks slummy, these are some very detailed answers!
I am very grateful, this clears up a lot of question marks. I guess now it's my turn to experiment a bit in real code :)

There is a good thread about copper chunky here, maybe a little bit to technical to begin with, but you will soon get there...

@jar: Happy to help. :)
One thing I forgot to mention: If you intend for your chunky pixels to be higher than 1 scanline then you should look into doing copper jumps (or "copper subroutine calls" if you will) using the 2 different copperpointers.

cool, thanks.
this article about exact copper timing was also quite useful to me.

I can't seem to change more than 16 colors per scanline. I used to think this was because I was changing AGA colors, but switching to OCS hoping to double the amount didn't give the expected boost.

If it is as you say that one can change 1 color per 8-th pixel I would think I could get 320/8 = 40 changes in one scanline.

Some setup which might be relevant:
- 8 bitplanes in use
- DMACONR is 0x2d0 (dmaenable set. Copper, disk, bitplanes, blitter dma enabled. Sprites, audio dma disabled)
- FMODE is 0xf ( 64-bit sprite fetch mode and 64-bit bitplane fetch mode
- None of the colors I'm changing are shown on the line where the changes are being done. They appear first on the next line.

I read about people changing 50 colors per scanline so I'm wondering what I'm missing? I just turned off sprite DMA, but seems no effect. Disabling bitplanes would make me sad.

Here is a snippet for 1 line of copper attempting 17 color changes.
BPLCON3 is the AGA bank switching since I'm using 256 colors throughout the frame.
Just using OCS colors now so not setting the low bits of the color.



*edit after reading article pointed to by Jar*

"MOVE INSTRUCTION TIMING

During horizontal blanking, MOVEs take 8 cycles (pixels) to execute. During DMA activity, MOVEs will take 12 or 16 (but no more than 16). A typical example is between DDFSTRT and DDFSTOP when bitplane DMA has to be read and output to the screen. Here, 3 bitplanes will increase the timing to 12px and 4 (or more) bitplanes will increase it to 16."

It doesn't say how much 8 biplanes is going to affect the timing, but if using positive thinking, the problem should go away after >7 bitplanes are enabled.

Still 16 seems to be achievable during horizontal blank alone, so this must be absolute minimum.

*double edit.. I'm retarded.. It was a different bug causing the corruption*

8 bitplanes steals more DMA cycles... You can actually avoid using bitplane DMA entirely. Just use a fixed mask of bitplanes written directly to the buffer registers with DMA turned off.