A.D.A. Amiga Demoscene Archive

Today, i tried to upgrade from a simple 16 color setup to a 256 color setup by trying to display a picture of 256 colors on screen. This means getting to know the AGA color system. I will write what i have learned here so that other people can 1) correct me 2) give some additional info, hints and tips 3)i don't forget what i have learned 4) other people can learn it faster :).

I discovered everything below from reading in the AGA chipset guide and by experimenting with Piccon. Let's assume that we are talking about a standard 320*256 low-resolution screen (no Ham, no specialities...)... R means Red, G means green, B means Blue.

Before AGA, it was possible to set up a screen of 5 bitplanes, meaning 32 colors (i have read about a sixth bitplane allowing 64 colors, was that ecs?). The color values started at $180 for color 0, $182 for color 1,... ending with color 31. Each color value was 12 bits: 4 bits red, 4 bits green and 4 bits blue, meaning that it was possible to select a color from a palette of 4096 possible color values.

For example, a copperlist could look like this:
dc.w $180,$0000 => color 0 will have color black
dc.w $182,$0F00 => color 1 will have color red
dc.w $184,$00F0 => color 2 will have color green
dc.w $ffff,$fffe (end of copperlist)

The colorvalue is expressed as R(ed)G(reen)B(lue) and each one is 4 bits.
=> $0FBA as color value thus means: $0(not important here) Red:$F Green:$B Blue:$A

Starting from AGA, there are 8 bitplanes possible amounting in 256 colors. For this, a couple of changes had to be done. First of all, as there were only 3 bits to tell the system how many bitplanes it should use (bit 14-13-12 of bplcon0), an extra bit had to be created to be able to tell the system to use 8 bitplanes. This is bit 4 from bplcon0, which is the most significant bit. This means that if bit 4 is set and bit 14-13-12 are not set => number of bitplanes = 1000 = 8. This is the first thing that needs to be changed.

Then there is the color system. In AGA, each color value is 8 bits so 8 bits red, 8 bits green and 8 bits blue => there can be 256 colors on screen, selected from 16777215 possible color values. This also means that the color registers are now 32 bits (or 2 words) wide (24 bits color, 1 bit genlock, other bits unused), instead of one word in the pre-AGA area.

A possible color value would now look like this:
=> $002F2F2F as color value now means: $00(not important here) Red:$2F Green:$2F Blue:$2F
A color value actually looks like this (if we write it in bits):
R7 R6 R5 R4 R3 R2 R1 R0 G7 G6 G5 G4 G3 G2 G1 G0 B7 B6 B5 B4 B3 B2 B1 B0

So far so good. But we still have our 31 color registers: color0 at $180, color1 at $182,... And we need to get those 8 bits RGB values in there and still try to be compatible with the old color system. For that, LOCT was added (bit 9 in bltcon3). When LOCT is 0 (which it is by default), and writing $0FBA to $180, the 4bit values R(=$F) G(=$B) B(=$A) are each copied into the 4 most significant bits of the new 32bit wide color registers (R7-R4 for red, G7-G4 for green, B7-B4 for blue). The 4 least significant bits from RGB (R3-R0 for red, G3-G0 for green, B3-B0 for blue) are filled in by the graphics system itself so that the new 24 bit color value looks actually identical as the old 12 bit value => compatibilty with old color system.

But what if we really want to use the full 8 bits RGB and use a pallette of more than 4096 colors, which is, with the system above, the maximum that one can reach. Well, for that we set the LOCT bit in bplcon3 to 1 and again write values to our color registers ($180, $182,...). By doing this, we also fill in the 4 least significant bits of RGB (R3-R0, G3-G0, B3-B0). In conclusion: LOTC = 0 => we fill in R7-R4,G7-G4,B7-B4, LOTC = 1 => we fill in R3-R0,G3-G0,B3-B0.

For example, let's say that i want a colorvalue $00245678 (R=$24, G=$56, B=$78) in my color 1. I can do this with the following copperlist (106 = bplcon3):
dc.w $0106,$0000 (LOTC = 0)
dc.w $0182,$0257 (=> R7-R4=$2, G7-G4=$5, B7-B4=$7)
dc.w $0106,$0200 (LOTC = 1 by setting bit 9)
dc.w $0182,$0468 (=> R3-R0=$4, G3-G0=$6, B3-B0=$8)
=> my color 1 will have a value of $00245678

There is still one thing to add here. Up to now, we are still talking about 32 colors. Above, we described a way to choose from a far bigger color pallette to define those colors (by going 24 bits). But we still need to find a way to fill in the color values starting from 32 -> 256. For that, 3 bits have been added in BPLCON3: 15-14-13. By writing a value of 000, we say to the system to we are going to fill in the color values of 0->31. When we write 001 to those bits, we tell the system that we are going to fill in the color values 32->63,...

In the end, a copperlist for a 256 color picture would look like this (106 = bplcon3):
dc.w $0106,$0000 (LOTC= 0, color range 0-> 31)
dc.w $0180,$0257 (=> R7-R4=$2, G7-G4=$5, B7-B4=$7 in color 0)
dc.w $0182;$0234 (=> R7-R4=$2, G7-G4=$3; B7-B4=$4 in color 1)
...
dc.w $0106,$0200 (LOTC= 1, color range 0-> 31)
dc.w $0180,$02A7 (=> R3-R0=$2, G3-G0=$A, B3-B0=$7 in color 0)
dc.w $0182;$023B (=> R3-R0=$2, G3-G0=$3; B3-B0=$B in color 1)
...
dc.w $0106,$2000 (LOTC= 0, color range 32-> 63 because bit 15-13 now = 001)
dc.w $0180,$0B57 (=> R7-R4=$B, G7-G4=$5, B7-B4=$7 in color 32)
dc.w $0182;$02C4 (=> R7-R4=$2, G7-G4=$C; B7-B4=$4 in color 33)
...
dc.w $0106,$2200 (LOTC= 1, color range 32-> 63 because bit 15-13 now = 001)
dc.w $0180,$02A7 (=> R3-R0=$2, G3-G0=$A, B3-B0=$7 in color 32)
dc.w $0182;$026C (=> R3-R0=$2, G3-G0=$6; B3-B0=$C in color 33)
...

i have read about a sixth bitplane allowing 64 colors, was that ecs?).

6 bitplanes 64 colors is the Half-Bright mode (already with ocs system)
normal 32 colors, the next 32 colors are half bright of the first 32 colors.
active with bplcon0 $100=$6200, when 6 planes selected for o-ecs and aga.
EDIT: with Aga, using 64 colors mode NOT extra halfbrite require setting the KILLEHB (bit 9) in BPLCON2 ($dff104)

6 bitplanes is also used in Dual Playfield mode : 3 bitplanes by playfield

the sixth bitplane was for a mode called extra halfbright (EHB) and this still wasn't for ECS ;)

ehb worked on plain OCS amigas. you can quickly try it with an old copy of deluxe paint or personal paint. in ehb, colors 32-63 are exact copies of colors 0-31, but with halfed brightness. fading was possible on ehb-screens, as opposed to ham-screens, so ehb was a good choice to present pictures.

Why waste time on generating a copperlist and then loose rastertime each frame on resetting colours that doesn't change? IMHO writing colours directly to the registers is easy and fun!

...and going to last exactly until the next frame. so writing directly to the registers isn't exactly a long lasting decision unless you redo it each frame (which is then doing the same as a copperlist).

...and going to last exactly until the next frame.

not all registers are wasted with the vblank, as far as I know only bpl-pointers are. colours last.

(that is if the os is totally ditched)

Hello!

@z5: this tutorial also is well written. Maybe you could state explicitely, that
in order to use 24 bit colors you have to FIRST fill the most significant bits (LOCT=0) and THEN fill the least significant ones. I know this is implicit in what you wrote, since you correclty said that when you fill the most significant, the least ones are automagically reset to the average value ($888), but to help the inexperinced coder, it could be helpful to state it explicitely.

@dalton,noname: I totally agree with dalton. Writing colors in copperlists is a traditional practice in demo-coding, but it is usually a great waste of time. For ordinary tasks, i.e., if you don't need to change the value of a color many times during the same frame, there is no need to re-load color registers at each frame. Hence its useless and a waste of time to set a copperlist for thi purpose. The same for registers DIWSTxx, DDFSTxx, BPLCONx et others. The ONLY registers that need to be reloaded at each frame are BPLxPT & SPRxPT.
So why there is this traditional practice? I think it all started since, in the glory dawn of Amiga coding (87-88) people used to mimic the AmigaOS copperlists,and also the HRM mimics them. But AmigaOS has a very specific reason to set copperlists which writes colors & BPLCONx &... :
the reason is to support the wonderful and unique feature of dragging multiscreen, which "only copper makes it possible" ;-) . Clearly, even if just one screen is opened, the OS set a copperlist with all the stuff, so that
at any time a new screen can be opened and dragged.
But for a demo, unless you change a color (or some other register) many times in a frame, setting this in the copperlist is just a wast of bus cycles at every frame (in fact any copper instruction uses 2 memory cycles, preventing the blitter and the CPU to access memory). With OCS system, where you usually have to re-load 16 colors, the delay was hardly noticable. But with AGA things changes, since to load a 256 24 bit colors
you have to load 256*2+32*2 registers!!!!! It is a lot of memory accesses,
which is not necessary to repeat at every frame. It is much better to load
colors and other registers in the beginning, with the CPU.
My copperlist for ordinary purposes is just the following:

CopperList
CMOVE xx,BPLCON0L
CMOVE xx, BPLCON0H
.
.
the same fo all bitplanes
.
CSTOP

hope this helps
The Dark Coder

hmm, maybe you guys got a point here. my assumption was based on 10 years old tests of mine that led me to use the copper to write the colors each frame. i was doing fine with this but maybe it is not really necessary for just setting the colors (and just for this case!). still i doubt that you will get significant speed increases. do you have any numbers on saved rastertime?

@noname Well, in this case we arenot balancing pros and against of two solution. There is no advantage at all to load colors with Copperlists when you don't modify them. Demo-coding should be , IMHO, an extremely-optimized form of coding, so when I see that I can improve the speed of a demo very easily and without any disadvantages, as in this case, I just do it without mesuring how much I gained!! :-)
So I never did tests. However:
1) Once, in a small italian party (TIG98), the demo which ranked 2nd (i was 3rd, damn! ;-) had several problems with syncronisations. I don't remember the details now,maybe one of the things was that the copperlist was not executed fast enough to be completed in a frame. Speaking with Phoenix, the coder and big friend of mine, I discovered that he was loading colors with the copperlist. I suggested to avoid this, and this solved the syncronisation problem.
2) You can quickly figure out by yourself: just wait for a visible rasterline and then load a full 256 color palette (24 bits), and then change again color00.
3) In practice, the number of saved time is hard to compute. The copper works in parallel with the CPU and the blitter, but the three compete to access the chip ram. The copper has the highest priority, so every copper instruction you add in the copperlist is a delayed chip ram access for blitter and CPU.
clearly,if your code does not use blitter and the CPU access fast ram, you almost lose nothing. On the other hand, if your code access chip ram the situation is worst. Imagine that you have a 68020 CPU and in parallel to the copper loading colors the CPU start a C2P convertion. I am sure the CPU will be delayed a lot! Anyone wants to try? Since currently my "Amiga" is an Asus laptop equipped with a Pentium Centrino, I douby my speed tests would be significant! ;-)
Note that the experiment I propose is realistic: in many cases, i.e., when you render a 3D scene, the main demo routine and the C2P are executed asyncronously (with respect to the copper), which means that you cannot avoit c2p and the copper working in parallel by simply "scheduling" the c2p to occurr at video beam positions when the copper is idle.

regards!
Darky

@noname:

forget to add: if I remember right, during a scanline the copperlist can execute at most 56 (or 52??) instructions. So to load a full palette copper needs (256*2+32*2)/56= 10,286 rasterlines. If you have a 1280*256 screen, with 256 colors, this means that in that 10+ rasterlines the CPU cannot access the chip ram, if it will to do. So it is locked. Even a 060 gets locked since chip ram accesses are not buffered being not-cachable.

But it would be interesting if someone perform a real test!!
regards
darky

5-600 writes is probably no big difference in cycles, I just think it's easier to write the colour registers directly than to generate a copperlist, and perhaps it should be encouraged?

Rewriting old sources will most likely take more time than it saves though =)

well, it could be 10 rasterlines, which is something. But you are right in pointing out that writing directly the registers with the CPU is also a lot easier and has no disadvantage (and IS more efficient! :-) so it should defenetly be encouraged!! :-)

Of course,no need to rewrite old sources! :)

I don't hear anyone complaining about my little tutorial... Does that mean that i got it right?

Is anybody interested in doing the same thing for other aspects of coding...
for example:
- how to add sound to a demo with P61 player routine
- how to add timing to the sound
...

If each person makes a little mini-tutorial, that could become very interesting. And with tutorial, i don't mean heaps of source code, but some general human talk about how to deal with a certain problem (like i did here).

As a side note: there is a register called BPLCON4 which has something to do with color and copperlists i think. I haven't understood yet what it does but i do have the feeling that this is what noname was hinting at in his mini-tutorial on fading??

yes, Bplcon4 have 8 bits BPLAMx (8-15) for switching colours without change the palette. this allows the copper to exchange colour maps with a single instruction. (256 cols defined by 8 palettes of 32 colors choose with bplcon3 bit "BANKx")
this register is also used for even or odd sprite palette.

@z5:

I don't hear anyone complaining about my little tutorial... Does that mean that i got it right?

Is anybody interested in doing the same thing for other aspects of coding...
for example:
- how to add sound to a demo with P61 player routine
- how to add timing to the sound
...

If each person makes a little mini-tutorial, that could become very interesting. And with tutorial, i don't mean heaps of source code, but some general human talk about how to deal with a certain problem (like i did here).

yes it is right, even though the thread contains good suggestions on how to improve it.
I find this idea of the mini tutorial really interesting, that 's something that it is really needed, otherwise in the future the knowledge about many Amiga tricks may diappear!!
May I propose something? As you said, anyone post a mini-tutorial on a subject that interests him. Then, people discuss about the tutorial and suggest improvements. After a while, when the thread is over, the author should collect all suggestions (if he thinks their' good) , put them in the tutorial and produce a nicely formatted version of the tutorial, maybe in hTML or AmigaGuide. Then the tutorial may be downloaded from web as a unique and coherent document.In this way, one tutorial after the other we could collect a public "library" of Amiga coding!!
What do you think?? ;-)

May I propose something? As you said, anyone post a mini-tutorial on a subject that interests him. Then, people discuss about the tutorial and suggest improvements. After a while, when the thread is over, the author should collect all suggestions (if he thinks their' good) , put them in the tutorial and produce a nicely formatted version of the tutorial, maybe in hTML or AmigaGuide. Then the tutorial may be downloaded from web as a unique and coherent document.In this way, one tutorial after the other we could collect a public "library" of Amiga coding!!
What do you think?? ;-)

This is EXACTLY what i was thinking :) Look at this thread: it began with some very simple tutorial from me (i'm a complete newbie) and turned into an interesting discussion from which i have already learned a lot.

@z5: so, please, collect all the suggestion in one text and put it somewhere on the web!!
I will do the same for the tutorials I will start (I hope soon)!!!

yeah, do it for my old #amycoders :)

a question on fading colors. Suppose i want to fade from black ($00000000) to a value of $00040051 (RGB 8 bit: so R=04, G=00, B=51).
Is it correct to add 1 to each 8 bit value until the needed value is reached, like this:
$00000000
$00010001
$00020002
$00030003
$00040004 (i reach the needed R value here so only blue has to go up)
$00040005
...

I ask because noname said in his mini-tutorial on fading (in topic effects) that the value one step closer to d0=$00ffffff starting from d0=$00000000 was d0=$00111111, which isn't the same as i'm doing...)

z5, you are right and you are doing it the correct way. go on.
there was a small quirk in the fading tutorial that i just corrected.

@noname:

my fade routine worked allready but you had me puzzled there for a moment when i began on it :) It needs a lot of changes though (both directions,...) but it works. I always loved fade effects...

There is one thing i'm missing though. And that is coding tips and tricks from experienced users. Because as a newbie, you just bang something together... it works but i'm sure there are tons of better ways of doing things. Being able to study some code from modern demos would have been great for this. Ofcourse, experience will help me in this aswell but as i said in another thread, i believe in starting the right way instead of starting the wrong way and keep all those wrong habits for a long time/forever (old habits die hard). The point being: i'm sure that my fade routine sucks but i don't know (yet) how to make it better :)

Oh and noname, thanks for the mini-tutorial on fading. It certainly worked for me (i did it exactly in the same order) and it doesn't give everything away. If you have more ideas for mini-tutorials, please post them in the effects topic :)

@noname:
In your tutorial, you talk about writing an array of 256 colors to the copperlist. Does that mean that you have a table of 256 longwords containing the intermediate results of your fade (meaning each color value from the fade) (let's call it fade table)

I worked like that: i set up a fadetable of 256 longwords and when i want to fade from black to a picture for example, i first make all 256 values in my fadetable black, then i fade to the colors of my picture (which is just an incbin of my palette), using the fadetable to store all intermediate values which i write to the copperlist aswell.

But then i ran into problems: at the end of my fade, the fadetable is exactly the same as my picture color file, which is logical. But then, when i want to fade from picture to black again, i have a problem: i thought: easy, i just write black again to all values of my fadetable and start fading from my picture colors and store the intermediate values in my fadetable. But that way i loose my black target colors ofcourse. So that doesn't work.

Now i'm thinking: i could do it like this: use the fadetable only to load the palette that i want to reach (so if i want to fade from black to picture, i copy my picture file into my table, if i want to fade from picture to black, i make all values in my table to black,...). Then i can do something like this:
- take the color value from my copper list (which are the starting colors i want to start ffading from)
- convert them to RRGGBB
- change them (depending on fade in/out) and check if i am already at the color i want to reach (so comparing them with the value in my table)
- convert them to copperformat and store them
- ...

That way i'm using my copper to store the intermediate results (they have to go in there anyway). This also have the benefit that i can stop my fade in the middle, and start fading in the opposite direction.

Any thoughts on my method? Thinking about it myself, i realise that it's going to cost me some extra cpu usage because i need to take the values from the copperlist and convert them to RRGGBB first, which i don't have to do when using an intermediate RRGGBB fadetable. But how do i solve my problem then?

Let's define two terms for the color buffers:
- "current colors", this is the buffer that gets modified by the fade routine and that gets written to the color registers either by copperlist or by direct writes as proposed above

- "destination colors", this is the buffer that holds the destination colors that you want to reach with "current colors". since you would normally feed your subroutine with a pointer to the buffers, there is nothing stopping you from having different "destination colors"-buffer (all black could be one of them). if your subroutine is working properly you can always change the destination colors at any time, e.g. in the middle of the fade.


do not read back colors from slow memory (chipmemory is very slow). treat yourself and be redundant by having an extra 256*4 bytes in fast-ram. this will make your code run a lot faster and save you from unnecessary problems. i usually say "more memory allows faster code".

---

when you got your fade routine working you might think about a brigthness-routine. i always found this very handy.

@noname:
ok, two buffers it is :) What do you normally do: define the tables in the code (dc.l $0000000) or do you have an external table file and how can i generate such a file? I just need 256*4bytes of 0 in a file and incbin it twice, right?

try ds.l 256*4

ok, this isn't funny anymore. I've been trying to make my fade work in both directions but it doesn't work. I've been searching on this for 3 hours now and my logic fails me here.

a0 = buffer (intermediate) color, RRGGBB
a3 = destination color (the one i want to reach), RRGGBB

just showing for blue:
move.b 3(a0),d0 ;get the blue i have reached so far
move.b 2(a3),d1 ;get the blue value i want to reach
cmp.b d1,d0 ;compare the bloody two values
beq.w .blue_done ;equal => reached my destination
cmp.b d1,d0
blt.w .blue_fade_in ;need to fade in because my destination is bigger
sub.b #1,d0 ;well, if i arrive here, it must be that my destination is less => fade out
bra .blue_done
.blue_fade_in:
add.b #1,d0 ;fade in
.blue_done:
move.b d0, 3(a0) ;move our new value or unchanged value in buffer again

Also, some questions:
Am i allowed to do this:
cmp.b d1,d0
beq .jump_routine1
blt .jump_routine2

or do i have to compare them again in between the beq and blt?

this is my little old fade trans routine (not AGA) from source palette to destination palette:
* a3=current palette (ex. copperlist colors)
* a4=destination palette (ex. picture palette or black or white for fadeout/flash)
* d7=nb colors

LoopCol
moveq #0,d0 ; final color
move.w (a3),d3 ; copy source color to d3
move.w (a4)+,d4 ;copy dest color to d4
; extract blue nibble
move.w d3,d5
andi.w #$f,d5 ; source blue
move.w d4,d6
andi.w #$f,d6 ; dest blue

cmp.w d6,d5
beq.s green ; enought blue
blt.s .inc ; need more blue ?
subq.w #1,d5 ; decrement blue nibble
bra.s green ; enought, next nibble
.inc: addq.w #1,d5 ; increment blue nibble

green:
move.w d5,d0 ; put in final color

; extract green nibble
move.w d3,d5
lsr.w #4,d5 ; --> equiv. andi.w #$f0,d5
andi.w #$f,d5
move.w d4,d6
lsr.w #4,d6
andi.w #$f,d6

cmp.w d6,d5
beq.s red ; enought green
blt.s .inc ; need more green ?
subq.w #1,d5
bra.s red ; enought, next nibble
.inc: addq.w #1,d5

red:
lsl.w #4,d5
or.w d5,d0 ; put in final color

; extract red nibble
move.w d3,d5
lsr.w #8,d5 ; --> equ. andi.w #$f00,d5
andi.w #$f,d5 ; red
move.w d4,d6
lsr.w #8,d6
andi.w #$f,d6

cmp.w d6,d5
beq.s final ; enought red
blt.s .inc ; more red ?
subq.w #1,d5
bra.s final ; enought, copy new color
.inc: addq.w #1,d5

final:
lsl.w #8,d5
or.w d5,d0 ; put in final color

move.w d0,(a3) ; put final color in copperlist
addq.l #4,a3 ; next color in copperlist

dbf d7,LoopCol ; loop for each color

; counter of max nibble -> when stop fading
addq.w #1,Count
cmpi.w #16,Count ; 16 nibble values 0->$f
bne.s .return
clr.w Count
seq flag ; for example
.return rts

adapt and optimize for aga 8 bits

----------------------
example 2 :

LoopCol:
moveq #2,d6 ; 3 nibbles : RGB
moveq #$00f,d3 ; mask. start with BLUE
moveq #$001,d4 ; incr/decr. start with BLUE
Loop:
move.w (a1),d0 ; copy coplist colour
move.w (a0),d1 ; copy palette colour
and.w d3,d0 ; -> Blue/Green/Red value
and.w d3,d1
cmp.w d0,d1
bcs.s .dec ; enought r/g/b ?
beq.s .ok
add.w d4,(a1) ; increment Blue/Green/Red nibble
bra.s .next
.dec:
sub.w d4,(a1) ; decrement Blue/Green/Red nibble

.ok:
asl.w #4,d4 ; shift inc/dec -> $001->$010->$100 (BGR)
asl.w #4,d3 ; shift mask -> $00f->$0f0->$f00
dbf d6,Loop ; next nibble
dbf d7,LoopCol ; next color

Am i allowed to do this:
cmp.b d1,d0
beq .jump_routine1
blt .jump_routine2

yes

example for 24 bits palette :
* a0 = source palette
* a1 = dest palette
* a2 = destination buffer
* d6=0 to 128
Loop
moveq #0,d0
moveq #0,d1
moveq #0,d2
; RGB source
move.b 0(a0),d0 ; R
move.b 1(a0),d1 ; G
move.b 2(a0),d2 ; B
; RGB dest
move.b 0(a1),d3 ; R
move.b 1(a1),d4 ; G
move.b 2(a1),d5 ; B
lea 3(a0),a0
lea 3(a1),a1

; delta RGB
sub.l d0,d3
sub.l d1,d4
sub.l d2,d5

muls d6,d3
asr #7,d3
add d0,d3
move.b d3,(a2)+ ; new Red

muls d6,d4
asr #7,d4
add d1,d4
move.b d4,(a2)+ ; new Green

muls d6,d5
asr #7,d5
add d2,d5
move.b d5,(a2)+ ; new Blue

loop each col

Can somebody actually say what is wrong with my logic...please... i can't see where and how it fails.