Fact-checked by Grok 2 weeks ago

Hold-And-Modify

Hold-And-Modify () is a specialized display mode developed for the Commodore computer, enabling the simultaneous presentation of up to 4,096 colors on screen through a unique pixel color encoding technique that leverages six bit planes to achieve 12-bit (4 bits each for , , and ). This mode operates by either selecting one of palette colors using the lower four bit planes or, for modification, retaining the color of the adjacent previous and altering a single color component (, , or ) based on the values in bit planes 5 and 6, which dictate the modification type: '00' for standard selection, '01' for blue adjustment, '10' for red, and '11' for green. Introduced with the original chipset in 1985, HAM was designed to expand the effective color gamut beyond the standard 16-color limitation of earlier modes, making it particularly suited for rendering smooth gradients, detailed images, and photographic content on hardware with constrained memory. To activate HAM, the system sets bit 11 (HOMOD) in the BPLCON0 register, requires single-playfield operation (DBLPF bit cleared), and configures six bit planes (BPU bits set to 110). It supports low-resolution formats such as 320×200 (NTSC non-interlaced) or 320×256 (PAL non-interlaced), and can extend to high-resolution 640×200 or 640×256 when the HIRES bit is enabled, though the modification mechanism inherently propagates horizontally from left to right across scanlines. Programmers often simplify implementation by basing the entire screen on modifications of a single background color from register COLOR00, minimizing the need for full palette across all 32 color registers. While innovative for its era, HAM's dependency on sequential processing introduced artifacts like color bleeding if not carefully managed, influencing its use in applications such as image viewers (e.g., Digi-View) and early software. The mode's legacy persists in , productions, and retro computing recreations, highlighting the Amiga's pioneering role in affordable high-color .

History and Background

Development on the

The Hold-And-Modify (HAM) mode originated from the efforts of and the engineering team at , founded in 1982, and Commodore-Amiga following the acquisition in August 1984. It became a core feature of the (OCS) designed to overcome the limitations of the Amiga's standard 16-color palette by enabling expanded color reproduction in graphics-intensive applications. This innovation stemmed from Miner's exposure to advanced military flight simulators at Singer-Link, where he observed photorealistic visuals and sought to replicate similar capabilities in a cost-effective system. HAM was specifically integrated into the Denise video chip within the OCS, which handled real-time color lookup and pixel processing to support dynamic modifications without requiring external hardware additions. The mode leveraged the Amiga's planar , where bitplanes stored individual color bits across the screen, allowing efficient data fetching by Agnus (the ) and conversion by Denise into display signals. Design constraints played a pivotal role, including a 12-bit limited to 4 bits per RGB channel to balance visual fidelity with the era's chip fabrication capabilities and . Overall, HAM enabled up to 4096 simultaneous colors, marking a significant advancement in affordable hardware.

Introduction and Initial Impact

The Hold-And-Modify (HAM) mode debuted with the Commodore Amiga 1000 on July 23, 1985, introducing a groundbreaking graphics capability that allowed for the simultaneous display of up to 4096 colors in a resolution of 320x200 pixels. This was a significant advancement over contemporary systems, such as the ST, which supported a maximum palette of 512 colors with only 16 displayed on screen at low resolution. By leveraging a specialized encoding technique that held a previous pixel's color and modified components for adjacent ones, enabled richer visual fidelity on the Amiga's original chipset (OCS). Immediately following its launch, found applications in early demos, games, and , where it facilitated photorealistic imagery that captivated users and developers. Similarly, productivity tools like incorporated HAM support for bitmap editing, allowing artists to work with thousands of colors in still images and animations. These uses highlighted HAM's potential for static visuals, such as digitized photographs and artwork, in an era when most systems were limited to dozens of colors. The introduction of HAM received widespread praise in the computing industry for its innovative approach to color display, which elevated the Amiga's reputation as a multimedia powerhouse and influenced subsequent color expansion techniques in competing platforms during the late 1980s. However, it was also criticized for its programming complexity and performance limitations, particularly the mode's slowness for real-time animation due to the need for sequential pixel dependencies. Key milestones included its integration into the AmigaOS Intuition graphics library, which provided developers with API access to HAM screen modes from launch, and detailed documentation in the 1986 Amiga Hardware Reference Manual, which outlined the mode's hardware implementation for broader adoption.

Principles of Operation

Color Encoding Mechanism

The Hold-And-Modify () color encoding mechanism operates by using six bitplanes to generate pixel colors in a 12-bit , allowing up to 4096 distinct colors through sequential modifications rather than direct palette indexing. In this mode, each pixel's color is derived from either a direct selection from a 16-color palette or a modification of the immediately preceding pixel's color, with changes limited to one per pixel to conserve . The process relies on two control bits (from bitplanes 5 and 4) to determine the action, while the remaining four bits (from bitplanes 3-0) provide either a palette index or a 4-bit value for the modified . The encoding begins at the start of each scanline, where the initial "held" color is typically the color from COLOR00. For the first , if the control bits are 00, it selects a base color directly from the 16-color palette using the four bits as an (values 0000 to 1111), loading the corresponding 12-bit RGB value from one of the COLOR00 to COLOR15 registers. Subsequent pixels process their six-bit value as follows: control bits 00 again selects a palette color, resetting the held color; control bits 01 modifies the channel by replacing its 4-bit value while retaining the and green from the held color; control bits 10 modifies the channel similarly; and control bits 11 modifies the green channel. This step-by-step propagation ensures that color changes are incremental and horizontal, with no carryover between scanlines. Mathematically, the color in mode are 12-bit values formatted as 4 bits for (bits 11-8), 4 bits for (bits 7-4), and 4 bits for blue (bits 3-0). For a modify- operation with data bits d (0-15), the new color register value is computed as: \text{new_color} = (d \ll 8) \lor (\text{held_green} \ll 4) \lor \text{held_blue} where \ll denotes left shift and \lor denotes bitwise OR; analogous formulas apply for (( \text{held_red} \ll 8 ) \lor (d \ll 4) \lor \text{held_blue}) and blue (( \text{held_red} \ll 8 ) \lor ( \text{held_green} \ll 4 ) \lor d). Palette selection directly assigns \text{new_color} = \text{COLOR}. The horizontal adjacency requirement means modifications accumulate left-to-right along the scanline, with the held color updating only after each pixel is rendered, which can introduce visual artifacts such as banding in gradients. These artifacts arise because altering a single channel at a time cannot simultaneously adjust all three RGB components, often necessitating dithering techniques to approximate smooth transitions by interleaving modifications across adjacent pixels.

Palette Management and Bit Allocation

The Hold-And-Modify (HAM) mode on the utilizes a 16-entry color palette, where each entry consists of 12-bit RGB values with 4 bits allocated per (red, , and ), allowing for 16 possible base colors in standard operation. This palette is selected through a 4-bit index derived from the lower bitplanes, enabling direct access to one of the 16 predefined colors for non-modifying pixels. HAM extends the effective color range to 4,096 simultaneous colors without increasing the palette size, by dynamically altering components of the previous pixel's color rather than requiring additional palette registers. In HAM's 6-bit pixel representation, the allocation divides the bits across the six bitplanes as follows: the two most significant bits (from bitplanes 5 and 4) serve as control bits to determine the operation—00 for palette selection, or 01, 10, or 11 to select modification of the blue, red, or green channel, respectively. The remaining four least significant bits (from bitplanes 0 through 3) provide either the 4-bit palette index for hold operations or the 4-bit value to apply to the selected channel during modification. This structure leverages the Amiga's existing planar graphics architecture, where data from the blitter or Copper can populate the bitplanes without specialized hardware changes. HAM achieves memory efficiency by adhering to the Amiga's standard planar bitplane format, requiring no extra RAM beyond the six bitplanes needed for the mode—typically around 48 KB for a low-resolution 320x200 display, comparable to the allocation for 64-color standard modes. To prevent unwanted color propagation across scanlines, the mode resets the color state at the beginning of each line to the background color (register 0), ensuring horizontal modifications do not affect vertical continuity. Compared to standard Amiga display modes, HAM trades pixel independence for increased color depth: while a 16-color mode (using four bitplanes) allows each pixel to freely select from the palette without dependency on neighbors, HAM's 6-bit planes enforce sequential color derivation, enabling the full 12-bit color space within the same hardware constraints as higher-indexed modes. This approach maintains compatibility with the Amiga's 512 KB chip RAM limit in early models, prioritizing display quality over fully independent per-pixel coloring.

Original HAM Mode

HAM6 Specifications

The Hold-And-Modify (HAM) mode, known as HAM6 in its original implementation, is supported by the Denise chip within the Original Chip Set (OCS), introduced in 1985 for the and subsequent models. This hardware enables a 6-bit pixel depth configuration using six bitplanes for color encoding data, allowing the system to interpret values in a specialized manner for enhanced color output. HAM6 operates at low-resolution (320 pixels wide) such as 320×200 non-interlaced or 320×400 interlaced for NTSC (60 Hz), with PAL variants supporting 320×256 non-interlaced or 320×512 interlaced at 50 Hz, or in HIRES (640 pixels wide) such as 640×200 non-interlaced or 640×400 interlaced for NTSC, and 640×256 or 640×512 for PAL; these dimensions align with the display capabilities of the OCS Denise, prioritizing . The mode delivers 12-bit RGB color output, supporting a total palette of 4096 colors, though each has 64 possible interpretations (16 palette colors plus 48 modifications), enabling up to 4096 unique colors across a scanline through sequential modifications and palette resets, without requiring palette changes mid-scanline. Activation of HAM6 requires setting bit 11 (HOMOD) in the BPLCON0 register to enable the mode, typically accomplished through Copper list instructions that dynamically manage bitplane pointers and color registers during ; alternatively, software can invoke it via the library's OpenScreen function by specifying a HAM-compatible display mode . This setup ensures compatibility across all OCS-equipped models, including the , , , and 3000 series, as well as ECS variants up to the 4000 with ECS Denise, though true color continuity across different chipsets demands additional software intervention to maintain palette states.

Usage Techniques

To implement Hold-And-Modify (HAM) mode on systems, developers typically use Intuition's OpenScreen function with a NewScreen structure specifying six bitplanes for depth, combined with the SA_DisplayID tag to select a HAM-compatible mode ID from graphics/modeid.h. Once the screen is opened, layers.library routines such as LockLayerInfo and InstallLayerInfoHook manage overlapping drawing areas on the HAM screen, ensuring proper clipping and for multi-layered . For low-level control, custom copper lists are programmed to set the BPLCON0 (at $DFF100) with bit 11 (HAM) enabled and bits 14-12 (BPU) set to 101 for six bitplanes, often synchronized via WAIT instructions to activate the mode at specific scanlines. Optimization in HAM programming relies on strategies that mitigate the mode's horizontal color dependency, where each pixel's hue builds on the prior one. Horizontal dithering, such as ordered or error-diffusion patterns across adjacent pixels, simulates intermediate colors by alternating between base palette entries and modifications, enhancing perceived in gradients without exceeding hardware limits. Palette animation via copper-driven updates to COLOR registers (DFF180-DFF1BE) enables dynamic scenes by the 16 base colors per frame or scanline, creating illusions of motion or brightness shifts, as seen in effects like fading text blocks. To avoid vertical color jumps, developers plan scanline content in advance, resetting the base color at line starts through copper MOVE instructions to BPLCON0 and ensuring adjacency in pixel . HAM mode finds common use in static image rendering, such as converting RGB artwork from tools like III to six-bitplane HAM formats via dedicated utilities that optimize pixel adjacency and palette selection for minimal fringing. Simple animations, including scrollers or fades, leverage operations for fast area fills and copies, where the blitter's line modes draw dense patterns across bitplanes to approximate shapes or transitions in HAM space. Early utilities like custom HAM converters preprocess true-color images by quantizing to 4096 colors and applying dithering, requiring manual adjacency checks to preserve horizontal continuity during import.

Limitations and Visual Artifacts

The original HAM6 mode imposes several key restrictions stemming from its horizontal color propagation mechanism, where each 's color is derived by modifying one RGB component of the preceding unless a base palette color is selected. This dependency prevents fully independent colors, as a modification to one inherently affects all subsequent pixels in the scanline until a via a palette index occurs. Consequently, achieving distinct colors often requires up to three sequential modifications per base palette entry—one for each RGB channel—before necessitating a palette to avoid cumulative errors or unintended hues. These constraints manifest in notable visual artifacts, including Mach banding, where the discrete 4-bit steps for channel modifications create perceptible contours in smooth gradients rather than seamless transitions. Color bleeding is another common issue, particularly in gradients or complex images, as propagated modifications can spill unintended tints across adjacent pixels if resets are infrequent, leading to blurred or inconsistent edges. Additionally, the mode's incompatibility with straightforward exacerbates these problems, requiring full bitplane recalculation for any vertical or dynamic movement to maintain color integrity across scanlines. Performance impacts further limit practical use, with HAM6 confined to low-resolution modes (such as 320×200 or 640×200 pixels) and demanding higher CPU overhead for techniques like dithering to approximate smoother colors. Interlaced displays introduce , as the alternating fields amplify inconsistencies over time. True high-resolution HAM requires bitplane slicing, which compounds these demands without native hardware support. While workarounds such as dithering can mitigate some artifacts by blending modifications across pixels, they do not fully eliminate banding or bleeding and increase computational load, rendering HAM6 unsuitable for fast-motion applications like games where real-time recalculation would overwhelm the 68000 processor.

Advanced Implementations

AGA HAM8 Mode

The Advanced Graphics Architecture (AGA) chipset introduced Hold-And-Modify 8-bit (HAM8) mode in 1992 alongside the Amiga 1200 and Amiga 4000 computers, leveraging the Alice chip for enhanced memory control and blitter operations. This upgrade enabled 8-bit pixel depths to generate up to 262,144 colors from an 18-bit RGB space, supporting resolutions like 640×200 at 60 Hz or 640×256 at 50 Hz, significantly expanding visual fidelity beyond prior modes. HAM8 improves upon the original HAM6 by utilizing two control bits per to select either a hold operation (sampling from the palette) or a modify operation on the , , or of the preceding , with the remaining six bits providing 64 discrete levels per for more precise color transitions and fewer banding artifacts in gradients. This finer allows up to 262,144 colors (18-bit RGB) in high-resolution interlaced or non-interlaced modes, such as × or ×512. Technically, HAM8 operates with 8 bitplanes activated alongside a dedicated mode flag in the registers, drawing from a 64-color base palette selected from the 256-entry 24-bit palette (though HAM8 effectively yields 18-bit output per ). with HAM6 is maintained by limiting palette access to the first 16 or 64 entries and emulating 6-bit behavior, ensuring legacy software rendering without modification. In applications, HAM8 found use in late-period Amiga games and demos, enabling smoother color gradients for complex scenes like textured environments or photographic imports that benefited from the mode's reduced artifacts compared to HAM6.

Other Variants (HAM4, HAM5, HAM7, SHAM)

HAM5 represents an experimental reduction of the standard HAM6 mode, employing only five bitplanes to conserve memory in scenarios with constrained resources, such as early prototypes or applications requiring faster rendering on OCS/ECS hardware. In this variant, the sixth bitplane is fixed to zero, limiting color modifications to the blue component alone, as the mode selection bits are derived from the fifth and fourth bitplanes. This results in lower color fidelity compared to full HAM6 but enables 32 possible colors without the full palette overhead, though visual quality suffers due to restricted RGB adjustments. HAM7, a variant on OCS/ECS systems, leverages a seven-bitplane setup as a hack to achieve functionality with reduced DMA overhead. By requesting seven bitplanes, the hardware activates only four via while using instructions to supply constant data to planes five and six (e.g., alternating RGB patterns like $RGBGRGBGRGBGRGBG for targeted modifications). This enables selective RGB tweaks for effects like ghosting or dithering, demonstrated in demos such as "HAM Eager," where it supports 4096 colors in constrained windows but defaults to 16 indexed colors elsewhere. The mode exploits undocumented OCS/ECS behavior, where planes five and six repeat static values without , facilitating efficient chunky-to-planar conversions or operations. SHAM, or Sliced HAM, emerged in the early as a software-driven technique by third-party developers, including for tools like DigiView 4.0, to mitigate HAM artifacts through per-scanline palette slicing. It interleaves standard HAM encoding with custom copper lists that redefine 15 of the 16 palette registers every line, creating 256 unique palettes across a 320x256 screen for pseudo-high-resolution output. This brute-force optimization tests all 4096 HAM colors per entry to minimize perceptual errors, maintaining computational parity with single-palette HAM while vastly improving gradient smoothness and reducing fringing. Though effective for still images and , SHAM saw limited adoption post-AGA due to its complexity and incompatibility with faster hardware modes, often requiring tuning that underperformed on PAL systems. These variants share core HAM traits—software-managed via for dynamic palette shifts and bitplane control—but emphasize trade-offs in precision, memory, and resolution for specialized uses like demos or legacy tools. Their unofficial nature confined them to enthusiast circles, with implementations relying on quirks rather than standard .

Emulations and Modern Applications

Software Emulations

Software emulations of the Hold-And-Modify () mode enable the recreation of on contemporary non- systems, primarily through cycle-precise simulations of the Original Chip Set (OCS) and Advanced Architecture () chipsets. Emulators like WinUAE and FS-UAE, both derived from the UAE codebase, fully support HAM rendering by accurately modeling the hardware's modification logic and palette operations. These tools achieve high fidelity by emulating the exact timing and behavior of Amiga video hardware, allowing HAM6 and HAM8 modes to produce the characteristic 4,096 and 262,144 color displays, respectively, while adhering to original constraints like the 12-bit . To enhance visual authenticity, these emulators incorporate pixel , typically OpenGL-based, for post-processing effects that mimic period-accurate display characteristics, such as and subtle color artifacts from persistence. FS-UAE's system, for instance, loads custom GLSL files to apply filters that replicate the Amiga's analog output without altering core accuracy. WinUAE similarly supports integration for CRT-like effects, ensuring that HAM's hold-and-modify transitions appear as they would on monitors. Deployed on PCs across Windows, , and macOS, these emulators facilitate seamless HAM playback for legacy software and demos. HAM emulation extends to mobile and web platforms via UAE derivatives. On , ports such as UAE4Droid provide OCS/AGA support, including HAM modes, though performance varies with device capabilities. Browser-based solutions like the Scripted Amiga Emulator () run in and , emulating HAM through rendering for interactive web demos of Amiga content. Image conversion tools complement these emulations by translating modern RGB graphics into HAM-compatible formats. The Java-based ham_convert utility, updated to version 1.12.0 in August 2025, uses to optimize pixel mappings, producing high-quality ILBM IFF files in HAM6, EHB, and other modes while reducing common artifacts like color banding. This cross-platform tool processes inputs from formats like and , enabling creators to generate authentic HAM visuals for emulated environments. Despite these advances, software emulations encounter hurdles in real-time execution on resource-constrained hardware, where cycle-precise OCS/AGA simulation demands significant CPU overhead, often mitigated by just-in-time (JIT) compilation but still lagging on low-end devices. Preserving HAM's inherent visual artifacts—such as edge fringing from sequential color modifications—poses another challenge, requiring precise shader tuning to avoid over-correction while maintaining historical fidelity.

Hardware and Third-Party Implementations

One notable hardware extension for HAM was the Systems HAM-E and HAM-E Plus, released in 1991 as external framebuffers connecting via the Amiga's RGB port. These devices supported an extended HAM mode that achieved 18-bit from 8 bits of data through techniques, building on the original HAM principle but with reduced pixel-level control compared to native modes. The HAM-E offered resolutions up to 384×560 in , while the HAM-E Plus doubled that to 768×560 and added hardware , making it suitable for professional image processing and compatible with tools like NewTek's DigiView buffers. The , a Zorro II expansion card introduced in 1990 for and later models, integrated modes into broadcast video production workflows. Its software interface, including ToasterPaint, utilized standard screens to handle 768×400 virtual canvases while maintaining internal 24-bit data for editing, enabling effects like chroma keying and transitions on digitized footage displayed in . This hardware-software combination powered low-cost TV graphics in the , with the Toaster 4000 variant in 1993 leveraging AGA's for enhanced color fidelity in professional setups. In the , the Apollo-Core boards provided modern hardware extensions for classic systems, incorporating FPGA-based 68080 CPUs that supported full chipset , including HAM8 mode extensions for up to 256,000 colors. These accelerator cards, compatible with and 4000 models, accelerated rendering of HAM-based content through integrated , output, and chipset replication, allowing legacy video tools to run at higher speeds without altering display artifacts. Similarly, FPGA platform's Minimig core, developed from 2017 onward for DE10-Nano boards, delivered cycle-accurate OCS/ECS/ with precise HAM timing to preserve original scanline behaviors and color hold-modify sequences. During the 1990s, found commercial application in Amiga-based video production tools beyond the , such as Black Belt's HAM-E for frame grabbing and effects in broadcast environments. These implementations enabled cost-effective creation of for television, including color-cycled animations and digitized overlays, by exploiting HAM's high color count on limited .

Recent Recreations and Legacy Uses

In 2025, the X65 project implemented a variant of the Amiga's (HAM) mode on an 8-bit 6502-based FPGA system, adapting the technique for retro applications on resource-constrained . This simulates a 6-bit HAM mode using , encoding each with 3 bits for base color selection from an 8-color palette and 3 bits for modification commands (hold base, red delta, green delta, or blue delta), with bitpacking to fit four pixels into three bytes for efficient 24-bit processing. The implementation operates at 320x240 resolution to stay within 64 kB limits, incorporating a blend command for smoother gradients via 50/50 and 1/32 quantum deltas to approximate Amiga's 12-bit on 8-bit hardware, enabling display of high-color images in retro gaming contexts like demoscene-style visuals. Recent software tools for processing saw updates in 2025, with ham_convert version 1.12.0 released in , enhancing image conversion for Amiga-compatible formats through higher-quality resizing algorithms and expanded input format support, including improved brute-force optimization for HAM6 slicing to minimize color errors in modern image processing workflows. This update facilitates cycling palette animations by better handling dynamic color reductions, allowing users to generate ILBM files suitable for or hardware rendering with reduced artifacts in gradient-heavy scenes. HAM principles continue to influence demoscene revivals, as seen in 2024 YouTube-hosted compilations of new demos like those from Revision 2024, where groups such as Darkage and Spreadpoint incorporated HAM-derived color techniques in AGA-compatible productions to evoke aesthetics with modern twists, such as interlaced 4,096-color effects in static or low-motion sequences. Educational recreations have also proliferated, with 2025 forum discussions and video tutorials demonstrating HAM's mechanics using contemporary tools to explain graphics limitations, often converting modern photos to HAM for classroom or about early compression methods. Beyond niche revivals, HAM's hold-and-modify approach inspires compressed in systems, exemplified by the X65's memory-efficient encoding that achieves 4096-color on 8-bit processors without full palette expansion, offering lessons for low-power devices in 2025 IoT applications. Online in 2025 have highlighted HAM's efficiency—requiring only 6 bits per for high-fidelity gradients—contrasting it with modern GPUs' delta color compression () techniques, noting how Amiga's hardware-level modifications prefigured bandwidth-saving methods in and architectures without the overhead of programmable shaders.

References

  1. [1]
    [PDF] COMMODORE -AMIGA, - iKod.se
    Hardware Connection Details ... In hold and modify mode, you use all six bit-planes. Planes Sand 6 are used ...
  2. [2]
    [PDF] User's Manual - Amiga Storage
    Dyna-Show will display. IFF and NewTek's new Dynamic modes. Appendix E: An Explanation of HAM Mode. The Hold-And-Modify (HAM) display mode on the Amiga uses six ...
  3. [3]
    Hold-And-Modify Graphics Mode | X65 - X65
    Jan 23, 2025 · Amiga's HAM (Hold-And-Modify) mode seemed like a great candidate. Implementing HAM on an 8-bit machine looked like a challenge, so I gave it a ...
  4. [4]
    History : Amiga Saga - AmigaNG
    ... Miner begins to consider the use of blitters to improve the graphics capabilities. This is eventually developed into HAM (Hold and Modify) during 1985. This ...
  5. [5]
    The AUI Interview: Jay Miner – the father of the Amiga
    May 31, 2015 · The AUI Interview: Jay Miner – the father of the Amiga. May 31, 2015 ... These improved Amiga chips can use a new type of ram called video ram.
  6. [6]
    [PDF] Hardvvare Reference Manual - iKod.se
    AMIGA TECHNICAL REFERENCE SERIES ... .,..,. Addison-Wesley Publishing ... Hold-and-modify Mode ...<|control11|><|separator|>
  7. [7]
    Commodore Amiga 1000 - The Centre for Computing History
    12-bit color palette (4096 colors). Graphic modes with up to 32, 64 (EHB mode; Early NTSC models do not have the EHB mode) or 4096 (HAM mode) on-screen colors: ...<|control11|><|separator|>
  8. [8]
    Amiga (1988) | IEEE Computer Society
    Jun 8, 2022 · The most popular display mode was HAM. Each 6-bit pixel had two control bits and four data bits. The control bits could modify red, green, or ...
  9. [9]
    Atari 1040ST
    The 1040ST has a pallet of 512 colors to choose from, although on later 'enhanced' versions such as the 1040STe, introduced on November 13, 1989, the color ...
  10. [10]
    The Atari ST and Amiga computing evolution! - RetroShowcase
    Defender of the Crown is a strategy computer game designed by Kellyn Beck. It was Cinemaware's first game, and was originally released for the Commodore Amiga ...
  11. [11]
    include/graphics/modeid.h - Amiga Developer Docs
    * * For example, to specifically open a PAL HAM interlaced ViewPort * (or intuition screen), you would use the modeid of * (PAL_MONITOR_ID | HAMLACE_KEY) ...
  12. [12]
    [PDF] A history of the Amiga - Amigascene.nl
    According to Jay Miner, he sequestered himself in his office for three weeks, only coming out once to ask Carl Sassenrath a question about message ports. The ...
  13. [13]
    Amiga hardware reference manual : Free Download, Borrow, and ...
    Nov 23, 2023 · Amiga hardware reference manual. Publication date: 1986. Topics: Amiga (Computer). Publisher: Reading, Mass. : Addison-Wesley. Collection ...Missing: HAM | Show results with:HAM
  14. [14]
    3 / Advanced Topics / Hold-And-Modify Mode - Amiga Developer Docs
    ... (red, green, or blue) is modified by bits coming from certain preselected bitplanes. After modification, the pixel is written to the screen. The hold-and ...
  15. [15]
    Classic Graphics Primitives - AmigaOS Documentation Wiki
    Jan 26, 2025 · Note that for the first pixel in each line, hold-and-modify begins with the background color. The color choice does not carry over from the ...<|control11|><|separator|>
  16. [16]
    intuition.library/OpenScreen - Amiga Developer Docs
    Opens an Intuition screen according to the specified parameters found in the NewScreen structure. Does all the allocations, sets up the screen structure and ...Missing: HAM copper
  17. [17]
    Layers Library - AmigaOS Documentation Wiki
    Jan 26, 2025 · This article describes the layers library which provides routines that are used to manage overlapping rectangular drawing areas that share a common display.Missing: HAM mode copper
  18. [18]
    HAM Eager - a technical write-up
    HAM is some kind of hardware compression. It uses six bitplanes (64 pens) to display graphics of 12 bit depth (that's all 4096 colours the OCS/ECS Amiga is ...
  19. [19]
    HAMazing - a technical write-up
    The following text explains a little bit about the techniques used and challenges of writing the Amiga OCS Demo “HAMazing”, released at 68k Inside, Finland, ...
  20. [20]
    Amiga Machine Code Letter XII - HAM - Mark Wrobel
    Feb 22, 2020 · HAM stands for Hold And Modify, which is very telling for this color mode. One pixel holds a color, and the next pixels along the scanline is then modified one ...
  21. [21]
    Additional Info / How Amiga HAM mode works
    Amiga HAM (Hold and Modify) mode lets the Amiga display all 4096 RGB values. In HAM mode, the bits in the two last planes describe an R G or B modification ...
  22. [22]
    articles - - Screen Modes - Amiga Graphics Archive
    In reality PAL pixels are a tiny bit wider than they are tall (16:15) and NTSC pixels are a bit taller than they are wide (8:9). OCS (Original Chip Set - ...
  23. [23]
    HAM8 Explained - Tutorials » Hardware » - Articles - Amigans.net
    Oct 18, 2007 · HAM8 mode is based on a 64 color base palette and then an 8 bit per pixel matrix to generate the image. The colors in the 64 color base palette ...Missing: specifications | Show results with:specifications
  24. [24]
    AmigaOS Manual: Workbench Monitors
    Jan 31, 2021 · This chapter describes the options and provides additional information about monitors and video modes that you need to know to take advantage of your Amiga's ...
  25. [25]
    Inside the Machine - Gigabates
    Oct 23, 2024 · Rather than chunky effects, this demo exploits the mode to do some interesting experimental stuff with blitter objects and dithering. I love it!
  26. [26]
    Brute Force Colors!
    Dec 30, 2022 · What if we're able to change the 16 colors palette in each scanline? In the Amiga world this is often referred as “Sliced HAM”, or SHAM. Instead ...Missing: YUV genlock broadcast
  27. [27]
    WinUAE Amiga emulator
    Jul 3, 2025 · WinUAE is an Amiga emulator. Version 6.0.1 includes bug fixes, and 6.0.0 has a major update to custom chipset emulation.Download · Basic features · WinUAE 5.3.1 · WinUAE 5.3.0
  28. [28]
    FS-UAE Features
    FS-UAE is an Amiga emulator for Windows, Linux and Mac OS Xbased on UAE/WinUAE, with a focus on emulating games, though it also emulates high-end Amigas.Missing: HAM | Show results with:HAM
  29. [29]
    shader | FS-UAE
    The shader option in FS-UAE is an OpenGL pixel shader. It can be a bundled shader name or a path to a shader file. Default is 0.
  30. [30]
    Achieving period-correct graphics in personal computer emulators
    Apr 15, 2022 · In this article series we'll be looking at emulating the Commodore Amiga, Commodore 64, and MS-DOS/early Windows era IBM PC compatibles with period-correct ...Missing: HAM | Show results with:HAM
  31. [31]
    Achieving period-correct graphics in WinUAE - AmigaLove
    Apr 24, 2022 · I've recently discovered a method to emulate the C= 1084S quite faithfully in WinUAE via shaders, so I wrote a lengthy blog post about it.Missing: FS- UAE<|separator|>
  32. [32]
    Amiga Emulator for Android | XDA Forums
    Dec 21, 2009 · Hi folks, I spent a good part of my sunday (and friday night, let's be honest) to port UAE4All for Android. So here's UAE4Droid.
  33. [33]
    Scripted Amiga Emulator: SAE
    This site is the home- and demopage of the SAE, an Amiga emulator in pure HTML5 and JavaScript. It is heavily based on WinUAE and does use the AROS-Kickstart ...Missing: HAM | Show results with:HAM
  34. [34]
    gfx/conv/ham_convert.zip - Aminet
    Apr 9, 2025 · Its main use is to produce high-quality hold-and-modify (HAM) images using brute-force search. It can produce ILBM IFF files (Amiga graphic ...
  35. [35]
    Java-Programm: ham_convert 1.12.0 - amiga-news.de
    Aug 24, 2025 · Sebastian Sieczko's Java-based program ham_convert converts modern graphic formats into the HAM format of the Amiga. ... Copyright © 1998-2025 by ...
  36. [36]
    ham_convert | techno kanciapa - bplaced
    Its main use is to produce high-quality hold-and-modify (HAM) images using brute-force search. It can produce ILBM IFF files (Amiga graphic modes: EHB, HAM6, ...
  37. [37]
    Help with Amiga emulation speed, please - Page 1
    Jul 3, 2016 · That slowness is because of emulating without JIT. A quick test on my setup is showing Sysinfo mips drop 80% and mlops drop by 92% without JIT.<|separator|>
  38. [38]
    What makes accurate emulation of old systems a difficult task?
    Apr 25, 2019 · A substantial amount of these emulators are hardly accurate when compared to the original hardware they are trying to emulate.Missing: HAM | Show results with:HAM
  39. [39]
    Black Belt Systems HAM-E & HAM-E Plus - Amiga Hardware Database
    extended HAM mode: similar to the normal Amiga HAM mode; uses compression techniques to achieve 18 bit colour form 8 bits of data; diminishes precise control ...<|control11|><|separator|>
  40. [40]
    NewTek Video Toaster - Amiga Hardware Database
    the interface uses a standard Amiga screen in HAM mode, 768×400 is achieved as a virtual canvas; image information is maintained inetranally as 24 bit data and ...
  41. [41]
    A history of the Amiga, part 9: The Video Toaster - Ars Technica
    Mar 18, 2016 · In 1993 NewTek released the Video Toaster 4000, an updated version that made use of the new AGA graphics hardware available with the Amiga 4000.<|control11|><|separator|>
  42. [42]
    The Big-box Amiga Vampire 68080 Accelerator Guide - Amitopia
    Feb 8, 2021 · You can purchase a Vampire CPU board for Amiga 2000. But as you see in the video, it fits well. ArenaNet also made an Amiga 2000 CPU adapter ...
  43. [43]
    Full text of "Amiga World Special Issue: 1990 Video and Animation"
    ... Amiga as a video- editing tool. In a recent survey, the Amiga had already ... For this reason I tend to think of HAM paint programs primarily as tools ...
  44. [44]
    May | 2025 - techno kanciapa
    May 1, 2025 · ham_convert 1.11.1 ... New in this version: higher quality resizing, more supported input formats, MSX2+ screen 10 yjk+palette conversion.
  45. [45]
    Java program: ham_convert 1.11.1 - amiga-news.de
    May 3, 2025 · Sebastian Sieczko's Java-based programme ham_convert converts modern graphic formats into the Amiga's HAM format. Changes in version 1.11.1 ...Missing: RGB | Show results with:RGB
  46. [46]
  47. [47]
    Depeche's Mode Demo by Spreadpoint - Revision 2024 ... - YouTube
    May 13, 2024 · Depeche's Mode Demo by Spreadpoint - Revision 2024 Amiga Demo Compo. 478 views · 1 year ago ...more. Revision Captures. 1.86K. Subscribe.Missing: HAM | Show results with:HAM
  48. [48]
    Amiga 2025 tech
    May 2, 2025 · Also think of HAM: How todays digital photo and powerful software can convert and tweak HAM pictures to superior quality. Data compression ...
  49. [49]
    HAM/HAM8 limits - Amigaworld.net
    Sep 8, 2025 · Amiga AGA can do pre-baked full motion HAM8 laser disc-style games. The problem is the Commodore's weak game content to drive platform sales for ...