A.D.A. Amiga Demoscene Archive

  Welcome guest! Please register a new account or log in

  

  

  

Demos Amiga Demoscene Archive Forum / Coding / OCS copper chunky newbie questions

 

Author Message
jar
Member
#1 - Posted: 20 Mar 2017 12:27
Reply Quote
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?

Angry Retired Bastard
Member
#2 - Posted: 20 Mar 2017 13:02
Reply Quote
jar:
- 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.

jar:
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)?

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.

jar:
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.


jar:
- 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.
jar
Member
#3 - Posted: 20 Mar 2017 13:26
Reply Quote
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 :)
todi
Member
#4 - Posted: 20 Mar 2017 13:28 - Edited
Reply Quote
There is a good thread about copper chunky here, maybe a little bit to technical to begin with, but you will soon get there...
Angry Retired Bastard
Member
#5 - Posted: 20 Mar 2017 14:49
Reply Quote
@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.
jar
Member
#6 - Posted: 20 Mar 2017 15:48
Reply Quote
cool, thanks.
this article about exact copper timing was also quite useful to me.

 

  Please register a new account or log in to comment

  

  

  

 

A.D.A. Amiga Demoscene Archive, Version 3.0