List of the Old Skool palettes

[saimo]

Thanks saimo, I fixed that.

You're welcome
Here's some more information... but be warned: when talking about video capabilities of Amigas, it is impossibile not to run into troubles because their chipsets are entirely programmable, so that what they can do is not easily summarized.

Amiga ECS == 16 levels of RGB (16**3 == 4096 colors), 4096 onscreen in HAM mode, 32 or 64 in other modes. [2]

Let's start with the easy stuff.
OCS/ECS Amigas can handle any number of bitplanes from 1 up to 5*, meaning that the number of colors in "normal" modes can be 2, 4, 8, 16 or 32.

*Depending on the resolution: at higher resolutions, because of bandwidth limitations, the maximum number of bitplanes is reduced.
Moreover, As you also mention, a 6th bitplane can be used in EHB mode, for a total of 64 colors.

Amiga AGA == 256 levels of RGB, with > 262144 onscreen in HAM mode, 256 or 128 onscreen in other modes. [4]

The same goes for AGA Amigas, with the difference that they have 2 extra bitplanes - so, also screens with 128 or 256 freely-defineable colors are possible (of course, the 64 colors EHB mode is still available for backwards compatibility).

Moreover, on all Amigas the color registers values can be dinamically changed by the Copper chip (which can write a color value more or less every 4 LORES pixels horizontally), so that the actual number of colors displayed can be much greater than those given by the number of bitplanes.

Finally, there are the dual-playfield modes, which overlap two separate screens (odd bitplanes are used for one playfield and even bitplanes for the other) at the cost of a reduction of the maximum number of colors (on AGA, the limit is a playfield of 16 colors overlapped by a playfield of 15 colors + transparency).

For a better idea of what we are talking about, have a look at this picture:

Here we see an ECS chipset working in dual playfield mode (so, it's 8 colors for the background playfield and 7 colors + transparency for the foreground playfield), with the Copper altering the palette* on a rasterline basis: the end result is that the color count (in this particular screenshot) reaches 171. Edit: I forgot to mention that there are also the colors of the sprites - main character and HUD -, which are given by color registers 16-31 (unused by the playfields).

*For the curious ones: instructed by the CPU, it is also moving the clouds, applying a line-by-line parallax effect on the background planes, applying a sinusoidal wave effect on the bottom of the foreground playfield and scrolling both playfields.

64-color mode was EHB 'extra half-brite' mode, where you could not choose the extra colors, the extra bitplane just specified 'halve the intensity of the color of this pixel' where a bit was set. If you pick a 32-color palette, then copy it and apply Levels 0..128 to the copy, you will have a result that may be right (documentation on this is not clear; it just says 'halve intensity' -- is the resultant intensity quantized to the 16**3 limits of Amiga OCS or not?)

This is hard to say, indeed.
The Amiga Hardware Reference Manual says:

The color register output selected by the first five bitplanes is shifted to half-intensity by the sixth bitplane.

The phrasing (and especially the fact that the word "output" is used instead of "value") suggests that the halving is "real".
However, the Amiga ROM Kernal Manual says:

If you draw using a color number from 32 to 63, then the color displayed will be half the intensity value of the corresponding color register from 0 to 31. For example, if color register 0 is set to 0xFFF (white), then color number 32 would be half this value or 0x777 (grey).

which suggests that halving is limited to the palette generator capabilities as you suspected.

So, which to choose? I personally would go for the option #1, because:
 - when it comes to hardware, the Amiga Hardware Reference Manual is likely to be more reliable than the Amiga ROM Kernal Manual;
 - Amigas' engineers were too clever to go for option #2 when the other solution was so easy
 - emulators (at least the version of UAE I used for testing) use halved intensity (I assume that the programmers did their research/testing).

I must admit that in my life I had never asked myself such question

[4] the actual number of onscreen colors possible is between 262144 and 414720
(see http://en.wikipedia.org/wiki/Amiga_Hold-and-Modify)

Take those figures with a pinch of salt.
As regards the maximum value, it has been calculated assuming 720x576 as maximum resolution, but that is not correct (Edit: f.ex., other more or less standard resolutions possible: 800x600, 1280x256, 1440x512 interlaced, etc.). As said at the beginning, Amigas' video circuitry is entirely programmable, so that countless resolutions/modes/frequencies are possible. For example, there is the DDFSTRT (Display Data Fetch STaRT) register which allowed the programmer to tell the chipset at which position of the raster beam to actually start drawing - and this was also refined in the ECS chipset with the addition of the DIWSTRT (DIsplay Window STaRT) register. And that's just the beginning. Moreover, HAM modes are so tricky that it makes little sense to just give rough numbers.
If I were you, I would just specify figures of "normal" modes.

saimo

[Helm]

saimo, thank you for that informative post! 

[saimo]

saimo, thank you for that informative post! 

My pleasure (really)
(For your curiosity, since I enriched it right after posting, you may want to re-read it not to miss some additional information.)

saimo

[Ai]

Here's some more information... but be warned: when talking about video capabilities of Amigas, it is impossibile not to run into troubles because their chipsets are entirely programmable, so that what they can do is not easily summarized.

Yes, I aimed to summarize just the abilities a pixel artist would use (which IMO doesn't include copper effects*). Another reason for omitting the palette-changing-during-redraw trick is that this is a pretty standard technique, available on at least CPC,  C64, SMS, GameGear, Genesis,
Amiga. Though the Amiga is the only one with an actual processor synced to the monitor so the changes can be very numerous and exact
(kind of overkill -- being able to change palette every 4 pixels, when your total palette may be 8 times that size, heh)

* of course, now that I've said this, I remember a CPC pic of mine that does use midscreen palette changing.

Amiga ECS == 16 levels of RGB (16**3 == 4096 colors), 4096 onscreen in HAM mode, 32 or 64 in other modes. [2]

Let's start with the easy stuff.
OCS/ECS Amigas can handle any number of bitplanes from 1 up to 5*, meaning that the number of colors in "normal" modes can be 2, 4, 8, 16 or 32.

Fixed (or will be by the time you read this)

Finally, there are the dual-playfield modes, which overlap two separate screens (odd bitplanes are used for one playfield and even bitplanes for the other) at the cost of a reduction of the maximum number of colors (on AGA, the limit is a playfield of 16 colors overlapped by a playfield of 15 colors + transparency).

For a better idea of what we are talking about, have a look at this picture:

Here we see an ECS chipset working in dual playfield mode (so, it's 8 colors for the background playfield and 7 colors + transparency for the foreground playfield), with the Copper altering the palette* on a rasterline basis: the end result is that the color count (in this particular screenshot) reaches 171. Edit: I forgot to mention that there are also the colors of the sprites - main character and HUD -, which are given by color registers 16-31 (unused by the playfields).

What I want to know, is, how is this relevant to an artist? Does it amount to any technical limitation or advantage, or is it a thing which is strictly useful only in-game?

64-color mode was EHB 'extra half-brite' mode, where you could not choose the extra colors, the extra bitplane just specified 'halve the intensity of the color of this pixel' where a bit was set. If you pick a 32-color palette, then copy it and apply Levels 0..128 to the copy, you will have a result that may be right (documentation on this is not clear; it just says 'halve intensity' -- is the resultant intensity quantized to the 16**3 limits of Amiga OCS or not?)

This is hard to say, indeed.
The Amiga Hardware Reference Manual says:

The color register output selected by the first five bitplanes is shifted to half-intensity by the sixth bitplane.

The phrasing (and especially the fact that the word "output" is used instead of "value") suggests that the halving is "real".
However, the Amiga ROM Kernal Manual says:

If you draw using a color number from 32 to 63, then the color displayed will be half the intensity value of the corresponding color register from 0 to 31. For example, if color register 0 is set to 0xFFF (white), then color number 32 would be half this value or 0x777 (grey).

which suggests that halving is limited to the palette generator capabilities as you suspected.

Actually, when you quoted 'is shifted' -- that is a real tip off, and IMO indicates that bits set in the 6th bitplane caused the equivalent of a SHL A,1 instruction on the values taken from the palette, since that would have executed very fast.

So, which to choose? I personally would go for the option #1, because:
 - when it comes to hardware, the Amiga Hardware Reference Manual is likely to be more reliable than the Amiga ROM Kernal Manual;
 - Amigas' engineers were too clever to go for option #2 when the other solution was so easy
 - emulators (at least the version of UAE I used for testing) use halved intensity (I assume that the programmers did their research/testing).

The difference is not large, though. in fact, it's nearly invisible in many cases.
Here is the 'exactly-halved' scale

00 08 11 19 22 2a 33 3b 44 4c 55 5d 66 6e 77 7f

and here is the 'shifted-left' scale

00 00 11 11 22 22 33 33 44 44 55 55 66 66 77 77

As you can see, each second 'exactly-halved' value differs from the 'shifted-left' value by exactly 8.

Anyway! It is possible to emulate both effects, whichever is correct.

The first is as I said: Divide sRGB intensities directly by 2. (aka levels with output range set to 0..128)

The second is to first divide by 34 (aka levels with output range set to 0..7),
then to multiply by 17 (aka levels with input == 0..7, output = 0..119)

I'm not sure which is correct, now.

I must admit that in my life I had never asked myself such question

I know, these issues are sooo important )))) I like to get them correct for my Pixlab library, though.

[4] the actual number of onscreen colors possible is between 262144 and 414720
(see http://en.wikipedia.org/wiki/Amiga_Hold-and-Modify)

Take those figures with a pinch of salt.
As regards the maximum value, it has been calculated assuming 720x576 as maximum resolution, but that is not correct (Edit: f.ex., other more or less standard resolutions possible: 800x600, 1280x256, 1440x512 interlaced, etc.).

I understood that those modes were highly subject to flickering, so they were not very practical or useful.

As said at the beginning, Amigas' video circuitry is entirely programmable, so that countless resolutions/modes/frequencies are possible. For example, there is the DDFSTRT (Display Data Fetch STaRT) register which allowed the programmer to tell the chipset at which position of the raster beam to actually start drawing - and this was also refined in the ECS chipset with the addition of the DIWSTRT (DIsplay Window STaRT) register. And that's just the beginning. Moreover, HAM modes are so tricky that it makes little sense to just give rough numbers.
If I were you, I would just specify figures of "normal" modes.

Okay, good idea.

[happymonster]

I understood that those modes were highly subject to flickering, so they were not very practical or useful.

The interlaced screenmodes were prone to flickering, but this could be minimised by reducing the contrast between vertical scan lines (i.e. adding gray between black and white, a form of anti-aliasing). When done this could dramatically improve things while still keeping the higher resolution detail.

There was even a program for Workbench called something like MagicTV which did the same kind of filter in real-time to allow you to have minimally flickering high-resolution desktops on normal TV's or standard monitors (not capable of proper non-interlaced high resolution gfx). I never saw any slowdown with this program, so no idea how it worked so well!

[saimo]

Though the Amiga is the only one with an actual processor synced to the monitor

Just for precision's and completeness' sake, it must be said that the only hardwired synchronization is that the Copper restarts processing its copperlists (sequence of instructions that constitute its programs) when the raster beam restart drawing a frame.
Other than that, there is the WAIT instruction which allows it to wait for the raster beam to reach the wanted position (but it can also be used to wait for other events, like the Blitter being done with data processing) - but how to use that instruction is up to the programmer.

so the changes can be very numerous and exact (kind of overkill -- being able to change palette every 4 pixels, when your total palette may be 8 times that size, heh)

It's not that one *has* to change colors that frequently, you know
Jokes aside, the Copper is not limited to just changing colors (it can write any 16-bit value into the chipset registers, so it is a rather general-purpose processor) and the connection to the raster beam is looser than commonly thought of. The 4 pixel resolution is given by the Copper's speed: it simply cannot write consecutive 16-bit values more quickly than that - in other words, saying "4 pixels" is just a rough way of measuring the Copper's speed*. Had the Copper been quicker, Amigas would have been even more powerful - f.ex., if it had been "just" 4 times as quick, LORES chunky screens would have been trivial to implement at (almost) zero CPU cost.

*Of course there is a connection between the Copper's and the rest of the chipset's clock speed, but at the moment I cannot remember - it is a few years since I last programmed those chips, so my memory got quite rusty

What I want to know, is, how is this relevant to an artist? Does it amount to any technical limitation or advantage, or is it a thing which is strictly useful only in-game?

I don't really understand the meaning of the last part. Anyway, certainly those technical aspects are relevant to an artist: when he draws something, he must know what he can or cannot do and also what the programmer is going to do with the graphics.

Actually, when you quoted 'is shifted' -- that is a real tip off, and IMO indicates that bits set in the 6th bitplane caused the equivalent of a SHL A,1 instruction on the values taken from the palette, since that would have executed very fast.

Agreed.
Still, at the same time, I can harly imagine the engineers - who were perfectly aware that the graphics department was fundamental for the revolutionary machine they were creating - going for such a solution when halving the brightness just before sending the signal to the monitor would have not been very expensive. On the other hand, IIRC, one of Jay Miner's (the Amiga's father) favourite lines was "engineering is the art of compromise", so maybe they just had to resort to the simple shift.

The difference is not large, though. in fact, it's nearly invisible in many cases.
Here is the 'exactly-halved' scale

00 08 11 19 22 2a 33 3b 44 4c 55 5d 66 6e 77 7f

and here is the 'shifted-left' scale

00 00 11 11 22 22 33 33 44 44 55 55 66 66 77 77

As you can see, each second 'exactly-halved' value differs from the 'shifted-left' value by exactly 8.

Anyway! It is possible to emulate both effects, whichever is correct.

The first is as I said: Divide sRGB intensities directly by 2. (aka levels with output range set to 0..128)

The second is to first divide by 34 (aka levels with output range set to 0..7),
then to multiply by 17 (aka levels with input == 0..7, output = 0..119)

I'm not sure which is correct, now.

A reliable way to check it out is:
 1. connecting the video out of a real Amiga to a graphics card;
 2. grabbing the output of an EHB screen;
 3. checking the half-brite pixels.

Take those figures with a pinch of salt.
As regards the maximum value, it has been calculated assuming 720x576 as maximum resolution, but that is not correct (Edit: f.ex., other more or less standard resolutions possible: 800x600, 1280x256, 1440x512 interlaced, etc.).

I understood that those modes were highly subject to flickering, so they were not very practical or useful.

As happymonster said, only the interlaced modes flicker.
Indeed, the 800x600 mode I mentioned is a "productivity" mode: instead of PAL's 15 kHz, the horizontal scan frequency is about 31 kHz* (VGA-like), which makes the picture look very crisp and stable. The only problem is that to enjoy it without losing the PAL modes one must have a bi-sync or multi-sync monitor.

*Again, since the chipset was entirely programmable, this figure is not set in stone: all the video parameters depend on one another.

saimo

[Ai]

interesting and related:
a guide to common game resolutions
This told me for instance that you could get doubleheight pixels as well as doublewidth on the Amiga (apparently this is obvious to someone who's really used an a amiga since Workbench uses this 640x240 mode.)
PS1 also has a 640x240 mode which presumably has doubleheight pixels, and a 320x480 w doublewidth  -- I wonder why? Were these ever used in games??

[saimo]

interesting and related:
a guide to common game resolutions
This told me for instance that you could get doubleheight pixels as well as doublewidth on the Amiga

In PAL/NTSC modes Amigas have basically three horizontal "resolutions": LORES (1:1), HIRES (1:2) and SHRES (1:4). HIRES/SHRES are obtained by simply doubling/quadruplicating the pixel speed. That's where the "standard" PAL screens (320x256 LORES, 640x256 HIRES, 1280x256 SHRES) and the double/quadrupleheight pixels come from.
ECS introduced the "VGA" modes, which double also the number of lines, so that also 1:1 modes with resolutions like 640x512 or 800x600 are possible (these modes, however, are not as common as PAL/NTSC ones for a number of reasons, including non-technical ones).

(apparently this is obvious to someone who's really used an a amiga since Workbench uses this 640x240 mode.)

For PAL, it's 256. Maybe 240 is for NTSC... but it could also be 200... cannot remember, sorry

saimo

[Mathias]

Geeze, I wish I was in the know like you guys. Studying this subject from the outside is intimidating, with all the formlas and whatnot. Math and I declared war on each other years ago and the battle rages on . . . whatever that means.

Ptoing, I'm sorry but in reference to your above posted Commodore 64 color palette image, I am not able to get the same results as you when converting it to greyscale. The pairs of greys present in the palette is ingenious on the part of the C64 developers, but I can't prove it to be true through my own efforts, so that I can be confident in it. I've created an image that should do the talking:





When creating sprites with the C64 pal, each colors' base luminance value is paramount in what colors I pick for what. With only 16 colors, you better pick well. I need to have confidence in which colors are really darker or lighter than others. But I can't come to the correct conclusion.

ptoing, how did you generate that greyscale conversion?

[Ai]

Yes you are doing the conversion wrong. I thought the same. Anyway, you need to convert it to YCbCr colorspace. All of these other things you tried are various measures of intensity, but they aren't luma (==Y).

The luma values for those colors are:

  [  0.000e+00,   2.579e-01,   2.539e-01,    3.301e-01,  3.294e-01, 4.088e-01, 4.041e-01, 5.007e-01, 5.020e-01, 5.400e-01,
     5.419e-01,   6.717e-01,  6.706e-01,  8.008e-01,  8.011e-01,  1.000e+00,]

You can convert rgbp -> ycbcr by applying the following matrix (ie. get the dot product) to the rgb values (which must be normalized to the range 0..1)

[[0.299, 0.587, 0.114],
 [-0.168736, -0.331264, 0.5],
 [0.5, -0.418688, -0.081312]]

Alternatively, some of the more esoteric image conversion software might be able to produce a YCbCr image for you.