While the Original Chip Set (OCS) and Enhanced Chip Set (ECS) Amiga computers had the 32 x 2 colour EHB (Extra Half-Brite) and 4096 colour HAM (Hold And Mofify) screen modes, where these ever used outside paint programs, for instance in games?

If so, was there any interactive animation/movement with these screen modes?



For example, a game that uses EHB (Extra HalfBrite) mode during the game action (i. e. ingame) is Pinball Dreams. In my example run of the Beat Box table I can find the following in the copper list:

$00D6EA WAIT $4211FFFE
$00D6EE MOVE #$6200,BPLCON0

I. e. it waits for raster line $42 (66) and uses BPLCON0 to set the number of bitplanes to 6 without the HAM bit set, which means EHB mode.

Cannon Fodder uses EHB for some of its still pictures. I'm not sure if it uses it ingame, but I consider it unlikely.

A newer game, Nemac IV, presents you with a screen mode selection at the beginning, offering EHB mode as an option. It can then render its ingame 3D graphics to an EHB mode display. However, it requires a machine more powerful than a stock Amiga 500.


The way HAM (Hold And Modify) mode works makes it unsuitable for ingame animation in most cases. I used to be unaware of any game that uses it for gameplay. (Update: There were at least 2 games using HAM for their animated action. See robc's answer.)

Fury of the Furries uses HAM for its still images, for example the title image and the images that are displayed before entering a new world (each consisting of a set of levels).

The reason why it is unfeasible to use HAM for animated action is that you will either have to tolerate so-called color bleeding to the right of pixels or you will need to employ sophisticated algorithms to counteract the color bleeding, which timing constraints may forbid or which are just not worth it to come up with.

In HAM mode you usually use 6 bitplanes (you can also use it with 5 bitplanes, but there's not much point to that). That's 64 possible values per pixel. Values 0 to 15 select a full RGB color from the 16 color palette, the same way other normal screen modes would. However, value sets 16 to 31 (modify blue component), 32 to 47 (modify red component) and 48 to 63 (modify green component), respectively, each just change one of the color components relative to the color of the previous pixel. The other two color components remain unchanged from the previous pixel.

Say you set the color to palette entry 8 in column 100. Say also that this palette entry is $0333, i. e. a very dark gray. So the pixel in column 100 will appear gray.

  1. Then, lacking a matching color in the palette, you modify the red component in column 101 to $6 (using a pixel value of $26 = 38). The resulting pixel in column 101 will now have a color equivalent to $0633, which is a dark unsaturated red.

  2. Next, again lacking a matching color in the palette, you modify the green component in column 102 to $7 (using a pixel value of $37 = 55). The resulting pixel in column 102 will now have a color equivalent to $0673, which is a brown-greenish color.

  3. Finally, lacking a matching color in the palette once more, you modify the blue component in column 103 to $6 (using a pixel value of $16 = 22). The resulting pixel in column 103 will now have a color equivalent to $0676, which is a dark gray with a very slight shimmer of green.

    HAM pixels before blitting
    note that each differently colored square represents 1 pixel

So far so good, but say you now want to blit an animated character onto the bitmap. Say the rightmost pixel of that character ends up in column 100 and it is a bright white, palette value $0FFF. What this means is that the white will bleed into the next 2 pixels:

  1. Due to modifying just the red component, the visible color in column 101 will be $06FF, a bright cyan.

  2. Due to modifying just the green component, the visible color in column 102 will be $067F, a bright blue.

  3. Only in column 103 will you have modified all three color components and the apparent pixel color will be the same $0676 as the original one before blitting.

    HAM pixels after blitting
    note that each differently colored square represents 1 pixel

Depending on how many and which color components you consecutively modify, the color bleeding can affect more or less pixels and depending on how different the colors are to the originally intended colors, the artifacts can be more or less visible.

uncorrected HAM color bleeding when naively blitting note that I scaled the image by a factor of 2 to make the artifacts easier to see

To counteract the bleeding, you would have to design a routine that figures out which pixels to the right of a blit to adjust and which pixel values are the optimal ones that let the apparent pixel colors match the original ones as closely as possible. You won't get completely rid of the artifacts, but they might now be unnoticeable unless you take a closer look.

  • 4
    The Settlers uses EHB in-game, obvious from all the shadows. I haven't disassembled it but the screen contains a lot more than 32 colours. Not an action game though.
    – pipe
    May 23 '16 at 15:30
  • @pipe Yes, you are right, The Settlers uses EHB mode in order to produce its shadows. Good find :) Strictly speaking you can achieve the same (not-completely-black) shadow effect without EHB mode, just using darker palette entries, but then you would only have a maximum of 16 usable colors left while the other half is for shadows. With EHB you can have 32 "normal" colors and 32 "shadow" colors. May 23 '16 at 17:38
  • 1
    That's awesome - so the car just needs to go from right to left and it will look like a kind of deliberate motion blur!
    – nsandersen
    Jul 12 '16 at 15:38
  • This is akin to how modern video codecs encode more luma information and less chroma information. Jan 2 '20 at 21:52
  • @Pipe Does feature animation though!
    – nsandersen
    Aug 10 '20 at 7:56

Many OCS/ECS Amiga games use more than 32 colours.

There are some cases of games using Extra Half Bright (EHB) mode like Universe (see this thread for more info on that game: How to obtain 256 arbitrary colors with limitation of 64 per line in Amiga (ECS)?).

However, the most usual way of achieving more than 32 colours in a frame is using Copper tricks. The Copper is a coprocessor which runs in sync with the video beam, and can modify some of the custom chips registers. The programs executed by the Copper are made of 3 different instructions (wait, move, skip). Such programs are called copperlists. You can easily build a copperlist which waits for certain video beam positions and changes some colour palette registers. There are lots of well known games using this technique: Pang, Lionheart, Agony, etc.

Of course, you can animate graphic objects (BOBs or sprites) using any of this techniques.

  • 2
    AFAIK the one top restriction was 64 colors in halfbrite (32 arbitrary + 32 half brightness of them) per scanline of screen. Even to that exceptions could apply by using strategically placed sprites. The restriction caused a slew of colorful side-scrollers and platformers with horizontally-oriented palette bands - sky, backgrounds, foreground, the ground. The copperlist had enough time to switch from sky-blues to moss-greens between rendering the top of the screen and its bottom.
    – SF.
    Apr 21 '16 at 9:30
  • 1
    I might be wrong, but I guess that, in HAM mode, you can have a different colour for every single pixel in the same line. That would mean 320 colours in a line when in 320x200 mode. The Copper can change a colour from the palette every 8 lo-res pixels. In a 320x200 display it can do 40 colour moves (in the visible area of the display) and another 17 in the border: that's a limitation of about 57 colours that can be changed per line in the best circumstances, due to the time needed by the Copper to do every single colour move. Apr 21 '16 at 10:44

Shadow of the Beast uses dual play field mode (of 3 bitplanes each) and some crazy sprite reuse to get its color on the screen. Have a look at this breakdown:


  • 1
    They worked wonders to get a lot of colors to appear visible on the screen without using the screen modes that natively supported more than 32 colors (EHB, HAM). Basically by changing things at certain raster positions, as was often done. The important thing to note is that using Dual Playfield mode, only the first 16 palette entries (one unused due to transparency) are used for the playfield. That means the palette entries 16 - 31(which are shared between sprites and the playfield for 32 color gfx and EHB) can now be independently changed for just the sprites without affecting the playfield. May 4 '16 at 3:19

I've not actually played it to confirm how well it does it, but Pioneer Plague claims to run in HAM mode, but I've not actually given it a whirl to see how well it runs in comparison.

Someone has recorded some gameplay footage and put it up here though, so you can get an idea - though I believe to be emulated, so YMMV :)

  • Yeah, it's ingame HAM. Great find! They make it work by keeping the background within the first 16 paletted colors (first 4 bitplanes). The BOBs they blit onto the screen are indeed HAM. Note the black outlines around the BOBs which keep the background from color bleeding into them. You can see some HAM artifacts when you make the BOBs overlap. It's hardly noticable, tho, if you don't specifically pay attention for it. I'd call it well done! May 3 '16 at 21:09
  • One instance where the HAM artifacts are really obvious is when you make this sphere thingy touch the left screen border. The color changing are the artifacts. However, they made it so that the artifacts reach over the complete width of the BOB, thus it doesn't look bad at all and if you don't know it, you will believe that the color changing is completely intentional ;) May 3 '16 at 21:21
  • 2
    I also found Knights of the Crystallion that uses HAM ingame with similarly clever sidestepping of the HAM artifacts. It's by the same author, Bill Williams. May 3 '16 at 21:44

Given that the present answers are all over the place and seem to completely miss the point here is an attempt to answer your questions properly:

[HAM and EHB] where these ever used outside paint programs, for instance in games?


HAM and EHB modes have been used many times, mostly for static images such as loading and story telling screens.

The Hall Of Light (HOL) site which lists most known Amiga games offers a method to list them by graphic mode: HAM games, and EHB games.

If so, was there any interactive animation/movement with these screen modes?

Yes, definitely. ;)

Some of the games linked to above also used these modes during dynamic screens. HAM games:

EHB games:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.