Hold-And-Modify


Hold-And-Modify, usually abbreviated as HAM, is a display mode of the Amiga computer. It uses a highly unusual technique to express the color of pixels, allowing many more colors to appear on screen than would otherwise be possible. HAM mode was commonly used to display digitized photographs or video frames, bitmap art and occasionally animation. At the time of the Amiga's launch in 1985, this near-photorealistic display was unprecedented for a home computer and it was widely used to demonstrate the Amiga's graphical capability. However, HAM has significant technical limitations which prevent it from being used as a general purpose display mode.

Background

The original Amiga chipset uses a planar display with a 12-bit RGB color space that produces 4096 possible colors.
The bitmap of the playfield was held in a section of main memory known as chip RAM, which was shared between the display system and the main CPU. The display system usually used an indexed color system with a color palette.
The hardware contained 32 registers that could be set to any of the 4096 possible colors, and the image could access up to 32 values using 5 bits per pixel. The sixth available bit could be used by a display mode known as Extra Half-Brite which reduced the luminosity of that pixel by half, providing an easy way to produce shadowing effects.

Hold-And-Modify mode

Over-the-air analog color television was designed to solve the problem of sending a color signal over the channel bandwidth assigned for black-and-white signals. It was found that the human visual system is far less sensitive to changes in color than in brightness. Taking advantage of this, the NTSC system slightly reduced the resolution of the black-and-white signal, which became known as the luminance, or luma. The reduction in resolution left a small amount of unused bandwidth which was then used to broadcast a much lower resolution color signal known as chrominance, or chroma. The chroma signal is then further split into two signals, hue and saturation, and the resulting three-part signal is known as HSV, for hue, saturation and value. Just before broadcast, the hue and saturation are further encoded, although the details of these two differ among the different broadcast systems - in NTSC it is known as YIQ, and in PAL it is Y'UV.
In computers and game consoles of the home computer era, which normally used color televisions as computer monitors, the signals inside the computer were normally encoded in HSV. This signal could then be easily turned into YIQ or YUV as needed and then sent to the television using an RF modulator. As the television was receiving a signal that had reduced color resolution, many systems of the era encoded their graphics in a way that also reduced the resolution of the color signal in order to save memory. For instance, the ZX Spectrum stored color only for 8-pixel groups, but this made it difficult to make high-resolution color images due to a problem known as attribute clash.
In the Amiga, the 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. Normally the data would be used to make adjustments to the luma, producing a higher resolution image based on two colors, like the Spectrum, but this system had no fixed-location edges and the encoding could change the base color anywhere along the line. One could, for instance, set the color of a particular section of a line to "sky blue" and then use the rest of the data for that line to encode changes in brightness, only periodically adjusting luma, to display clouds and similar features. This is the same basic technique used in modern image compression techniques like JPEG and MPEG, as well as in other HSV/YUV based video modes such 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. It appeared that this change negated much of the benefit of HAM mode. Amiga project lead Jay Miner relates:

The final form of Hold-And-Modify was, hardware-wise, functionally the same as the original HSV concept, but instead of operating on those three descriptive components, it modifies one of the three RGB color channels, selected by mask bits. Conversion from HAM to RGB output is achieved in realtime by the display hardware, as the data in the graphics buffer is being displayed. In the HAM6 code for instance, two bits are used to indicate which value was being changed, and another four encoded a value. One of the four possible flag values, zero, indicated that the four data bits were selecting a base color from the value in one of 16 previously-set color registers. It would be possible to use only these types of values, producing a 16-color display using 6-bits-per-pixel. The other three possible patterns, 1 through 3, indicated that the value for the blue, red or green value from the original register value should be replaced by the following 4-bit data. The final output values were held in a register in the DAC that produced the final output. Through careful selection of the 16 base colors followed by appropriate modifications, many colors could be displayed in a single image.
HAM can be considered a lossy compression technique, similar in operation and efficiency to JPEG minus the DCT stage; in HAM6 mode, an effective 4096-color playfield is encoded in half the memory that would normally be required - and HAM8 reduces this still further, to roughly 40%. There is, however, a tradeoff for this simplistic compression: a greater overall color fidelity is achieved at the expense of horizontal artifacts, caused by the inability to set any single pixel to an arbitrary 12-bit value. At the extreme, it can take three pixels to change from one color to another, reducing the effective resolution at that point from a "320-pixel" to approximately "106-pixel" mode, and causing smears and shadows to spread along a scanline to the right of a high contrast feature if the 16 available palette registers prove insufficient.

Usage

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 the aforementioned 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. EGA's successor VGA released in 1987 with its flagship games mode, 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 the limitations described above HAM was mainly used for display of static images and developers largely avoided its use with games or applications requiring animation.
HAM mode was only used for gameplay in twelve games, starting with Pioneer Plague in 1988. Other HAM titles include Knights of the Crystallion, Links: The Challenge Of Golf, Overdrive , Kang Fu, AMRVoxel, RTG, Zdzislav: Hero Of The Galaxy 3D, OloFight and Genetic Species.
With the introduction of the Advanced Graphics Architecture, a conventional planar image could have a palette of 256 colors, offering significantly higher color fidelity. The original HAM mode, with its limited color resolution, became far less attractive to users of an AGA machine, though it was still included for backward compatibility. The new HAM8 mode was far less useful to the AGA chipset than the HAM mode was to the original chipset, since the more straightforward indexed 256-color modes greatly increased the options to the artist without suffering from the drawbacks of HAM. A well-programmed "sliced"-palette mode could prove to be more useful than HAM8, with up to 256 unique colors per line - enough to directly define a distinct color for each pixel if a 256-pixel-wide video mode was defined, and in higher resolutions even a single 256-color palette for the entire screen, let alone each line, allowed much more effective and accurate simulation of higher color depths using dithering than could be achieved with only 32.
The original purpose of HAM, which was to allow more color resolution despite limited video buffer size and limited memory bandwidth, had become largely irrelevant thanks to the lifting of those limits. As more modern computers are inherently capable of high resolution truecolor displays without any special tricks, there is no longer any need for display techniques like HAM; as PC-style graphics cards offering modes such as 800x600 SVGA in hi-color were already available for the Amiga in the dying days of the platform, it is unlikely that any further developments of the technique would have been bothered with had it survived to the present day.

Limitations

HAM mode places restrictions on the value of adjacent pixels on each horizontal line of the playfield. In order to render two arbitrary colors adjacently, it may take up to two intermediary pixels to change to the intended color. In the worst case this reduces the horizontal usable chroma resolution in half, from 320~360 pixels to 106~120. Even so, it compares favorably to contemporary video technologies like VHS that has a chroma resolution of around 40 television lines, roughly equivalent to 80 pixels.
Displaying such images over a composite video connection provides some horizontal smoothing that minimizes color artifacts. But if an RGB monitor is used, artifacts become particularly noticeable in areas of sharp contrast, where an undesirable multi-hued artifact or "fringe" may appear. Various rendering techniques were used to minimize the impact of "fringing" and HAM displays were often designed to incorporate subtle horizontal color gradients, avoiding vertical edges and contrasts.
Displaying a full color image in HAM mode requires some careful preprocessing. Because HAM can only modify one of the RGB components at a time, rapid color transitions along a scan line may be best achieved by using one of the preset color registers for these transitions. To render an arbitrary image, a programmer may choose to first examine the original image for the most noticeable of these transitions and then assign those colors to one of the registers, a technique known as adaptive palettes. However, with only 16 available registers in the original HAM mode, some loss in color fidelity is common.
Additionally, HAM mode does not easily permit arbitrary animation of the display. For example, if an arbitrary portion of the playfield is to be moved to another on-screen position, the Hold-and-Modify values may have to be recomputed on all source and target lines in order to display the image correctly. Specifically, if the left-most edge of the animated object contains any 'modify' pixels, or if the image immediately to the right of the object contains any 'modify' pixels, then those Hold-and-Modify values must be recomputed. An attempt to move an object around the screen will create noticeable fringing at the left and right borders of that image, unless the graphics are specially designed to avoid this. In order to avoid recomputing Hold-and-Modify values and circumvent fringing, the programmer would have to ensure the left-most pixel of every blitter object and the left-most pixel of every line of a scrolling playfield is a "set" pixel. The palette would have to be designed so that it incorporates every such left-most pixel. Alternatively, a HAM display can be animated by generating pixel values through procedural generation, though this is generally useful for synthetic images only, for example, the "rainbow" effects used in demos.
Note, however, that Hold-and-Modify only applies to playfield pixels. 128 pixels of sprite data per scanline are still available for placement on top of the HAM playfield.