Hold-And-Modify

Lore & Background

The original Amiga chipset uses a planar display with a 12-bit RGB color space producing 4096 possible colors. The display system usually used an indexed color system with a color palette containing 32 registers. HAM mode was developed as a solution to reducing color resolution memory needs while avoiding attribute clash. In this system, an initial color was set and then the following data was used to modify that value. The technique is similar to modern image compression like JPEG and MPEG, as well as the YJK encoding of the V9958 MSX-Video chip. As the Amiga design migrated from a games console to a more general purpose home computer, the video chipset was itself changed from HSV to the modern RGB color model.

Reader's Guide

When the Amiga was launched in 1985, HAM mode offered a significant advantage over competing systems. HAM allows display of all 4096 colors simultaneously, though with limitations. This pseudo-photorealistic display was unprecedented for a home computer of the time and allowed display of digitized photographs and rendered 3D images. In comparison, the then IBM-PC standard EGA allowed 16 on-screen colors from a palette of 64, and VGA's Mode 13h allowed 256 on-screen colors from 262,144. HAM mode was frequently used to demonstrate the Amiga's ability in store displays and trade presentations, since competing hardware could not match the color depth. Due to its limitations, HAM was mainly used for display of static images and developers largely avoided its use with games or applications requiring animation. Only twelve games used HAM mode, starting with Pioneer Plague in 1988. With the introduction of the Advanced Graphics Architecture (AGA), a conventional planar image could have a palette of 256 colors, making the original HAM mode far less attractive, though it was still included for backward compatibility. The new HAM8 mode was far less useful to the AGA chipset than the original HAM was to the original chipset, since more straightforward indexed 256-color modes increased options without suffering from HAM's drawbacks.

Did You Know?

• HAM mode was originally conceived during a trip to see flight simulators, as a primitive type of virtual reality.
• HAM6 encodes an effective 4096-color playfield in half the memory normally required.
• It can take up to three pixels to change from one color to another, reducing effective resolution to about 106 pixels at that point.

The Core Mechanism: Modifying Color in Real Time

HAM works by establishing a base color and then incrementally altering individual RGB channels as the display scans across the screen. In HAM6 mode each pixel consumes six bits: two serve as a selector flag and four carry the data payload. When the flag reads zero, those four bits simply choose one of sixteen pre-loaded color registers, yielding a straightforward 16-color image. When the flag reads one, two, or three, the corresponding blue, red, or green channel of the currently held color is overwritten by the four-bit value. The blended result is stored in a register inside the DAC that produces the final analog output. Because the hardware performs the conversion from HAM codes to full RGB in real time as the frame is being drawn, the programmer never needs to store complete twelve-bit color values. By carefully choosing sixteen base colors and then layering small channel adjustments on top, a single screen can exhibit a far richer palette than a naive indexed approach would permit.

Origins: A Chip-Layering Accident and a Flight-Simulator Spark

HAM's roots stretch back to the era when home computers drove color televisions using HSV-encoded signals. The original Amiga chipset was designed around that NTSC-compatible architecture, where holding a hue and tweaking only the luminance with four bits made practical sense. Project lead Jay Miner has recalled that the idea crystallized after a trip to watch flight simulators in action, sparking a vision of a primitive virtual-reality display. When the team pivoted the Amiga from a games console toward a general-purpose home computer, the video hardware shifted from HSV to the modern RGB model. Miner initially declared the hold-and-modify circuit unnecessary and asked the chip-layout engineer to remove it. The engineer came back explaining that excising the logic would either leave a large empty gap in the middle of the silicon or demand a three-month redesign the schedule could not absorb. Miner, convinced nobody would ever use the feature, let it stay. He later admitted he was wrong, crediting it as the very thing that gave the Amiga its distinctive color-palette edge.

Solving the Attribute-Clash Problem

Many home-computer systems of the mid-1980s stored color at a coarse granularity to save memory. The ZX Spectrum, for example, assigned a single color to an entire eight-pixel group, which produced the infamous attribute-clash problem: two adjacent pixels that needed different colors but shared the same group could not be rendered independently. The Amiga's planar display already offered a twelve-bit RGB color space yielding 4096 possible colors, with a bitmap held in chip RAM shared between the display hardware and the CPU. The standard indexed mode used thirty-two color registers addressed by five bits per pixel, plus a sixth bit for the Extra Half-Brite dimming effect. HAM was conceived as a way to keep the memory footprint low while eliminating fixed-location color boundaries. Because the base color could be re-set at any point along a scanline, an artist could paint a stretch of sky blue and then use the remaining bits to encode subtle brightness variations for clouds, without being trapped by rigid group edges. The technique is conceptually close to modern lossy compression schemes such as JPEG and MPEG, and to the YJK encoding found in the V9958 MSX-Video chip of the MSX2+.

Practical Use, Memory Savings, and Inherent Tradeoffs

When the Amiga launched in 1985, HAM mode became the go-to showcase for the machine's graphical prowess. Because it could render near-photorealistic imagery on a home computer at a time when that was virtually unprecedented, developers and demo programmers leaned on it to display digitized photographs, video frames, detailed bitmap artwork, and the occasional animation. The memory savings were substantial: HAM6 encoded an effective 4096-color playfield in roughly half the storage a full indexed display would need, and HAM8 pushed that figure down to about forty percent. However, the mode carried a significant tradeoff. As a lossy compression technique—comparable to JPEG minus its discrete-cosine-transform stage—it introduced artifacts and limited the kinds of images that could be reproduced faithfully. These technical constraints meant HAM could not serve as a general-purpose display mode; it excelled at smooth, photographic content but struggled with sharp, high-contrast graphics. Its niche role as a demonstration and photography tool, rather than a universal framebuffer, defined both its fame and its practical ceiling.

Gallery