amiga-bootcamp/17_demoscene/pixel_tricks.md

← Home · Demoscene Techniques

Pixel Tricks — Copper Chunky, HAM Art, Scroll Register Abuse, and Modulo Wrapping

Overview

The Amiga's display hardware was designed for planar bitplane graphics — a memory-efficient scheme that matched the DMA streaming pattern perfectly. But the demoscene never accepted "designed for" as a limitation. From 1989 onward, demoscene coders systematically abused every display register to create effects that Commodore's engineers never imagined: copper chunky (no bitplanes at all, just color register writes), HAM art (photorealistic images in 4096 colors), scroll-register distortion (sine-wave text), and modulo wrapping (infinite scrolling surfaces).

These techniques share a common thread: they treat the display registers themselves as the primary rendering surface, not the bitplane memory. The Copper, scroll registers, and modulo values become the "pixels" — a fundamental inversion of the intended programming model.

graph TB
    subgraph "Bitplane Alternatives"
        CC["Copper Chunky<br/>Color register = pixel"]
        HAM["HAM-6/HAM-8 Art<br/>Delta-encoded photorealism"]
    end
    subgraph "Register Abuse"
        SCROLL["Scroll Distortion<br/>BPLCON1 sine waves"]
        MOD["Modulo Wrapping<br/>BPLMOD virtual surfaces"]
        DDF["DDFSTRT/DDFSTOP<br/>Per-line resolution changes"]
    end
    subgraph "Hybrid"
        PLASMA["Plasma Effects<br/>Copper + precalc palette"]
        SHADER["Copper Shader<br/>Per-line pseudo-rendering"]
    end

    CC --> PLASMA
    HAM --> SHADER
    SCROLL --> MOD
    MOD --> DDF
    PLASMA --> SHADER

---

Technique 1: Copper Chunky

The most extreme display hack on the Amiga. Copper chunky creates a pixel display without any bitplanes at all. The Copper writes to a single color register (COLOR01) at every pixel position across each scanline. The result is a "chunky pixel" display where each pixel's color is set directly by the Copper — no bitplane memory, no Blitter, no CPU rendering.

Why It Works

sequenceDiagram
    participant Copper
    participant COLOR01 as COLOR01 $DFF182
    participant Denise as Denise DAC

    Note over Copper: Scanline Y=100, pixel positions:

    Copper->>COLOR01: MOVE #$0F00 (blue) at x=0
    COLOR01->>Denise: Output blue pixel
    Copper->>COLOR01: MOVE #$00F0 (green) at x=2
    COLOR01->>Denise: Output green pixel
    Copper->>COLOR01: MOVE #$0FFF (white) at x=4
    COLOR01->>Denise: Output white pixel
    Copper->>COLOR01: MOVE #$0F00 (blue) at x=6
    COLOR01->>Denise: Output blue pixel
    Note over Copper: ...continues across entire line

Resolution and Bandwidth

Copper chunky resolution is limited by how many MOVE instructions fit per scanline:

Mode	Pixels/Line	Colors	DMA Budget	Notes
LoRes (1×)	~56	Any of 4096	WAIT + MOVE = 4 slots/pixel	Sanity "Arte" style
LoRes (2×)	~112	Any of 4096	MOVE only = 2 slots/pixel	No WAIT, consecutive moves
HiRes (1×)	~28	Any of 4096	More DMA used by bitplanes	Rarely used

Copper Chunky Template

; copper_chunky.asm — Minimal copper chunky (56 pixels wide, 1 line)
; No bitplanes enabled — display comes entirely from COLOR01 writes

COPPER_CHUNKY:
        ; Disable all bitplanes, enable color
        dc.w    $0100,$0200           ; BPLCON0: 0 bitplanes, color on

        ; Wait for display area start
        dc.w    $802C,$FFFE           ; WAIT line 44

        ; Write COLOR01 at each pixel position
        ; Each MOVE takes 2 DMA slots; ~56 pixels per LoRes line
        dc.w    $0182,$0F00           ; COLOR01 = blue (pixel 0)
        dc.w    $0182,$0FF0           ; COLOR01 = cyan (pixel 1)
        dc.w    $0182,$0FFF           ; COLOR01 = white (pixel 2)
        dc.w    $0182,$0F0F           ; COLOR01 = magenta (pixel 3)
        dc.w    $0182,$0FF0           ; COLOR01 = cyan (pixel 4)
        dc.w    $0182,$0F00           ; COLOR01 = blue (pixel 5)
        ; ... repeat for ~56 pixels total ...

        ; End of line — black for rest of frame
        dc.w    $8030,$FFFE           ; WAIT next line
        dc.w    $0182,$0000           ; COLOR01 = black
        dc.w    $FFFF,$FFFE           ; End

Full Copper Chunky Frame

For a full-screen effect, the CPU pre-calculates the copper list each frame, writing color values for every visible pixel:

/* copper_chunky.c — Generate full copper chunky frame */
/* Resolution: ~56 pixels × 200 lines = 11,200 "pixels" */

#define CHUNKY_WIDTH  56
#define CHUNKY_HEIGHT 200
#define FIRST_LINE    44

/* The copper list is an array of UWORDs */
/* Each pixel = 1 MOVE instruction = 2 UWORDs (register, value) */
/* Each line = 1 WAIT (2 UWORDs) + 56 MOVEs (112 UWORDs) = 114 UWORDs */
#define LINE_WORDS  (2 + CHUNKY_WIDTH * 2)
#define TOTAL_WORDS (LINE_WORDS * CHUNKY_HEIGHT + 4)  /* +4 for end marker */

static UWORD copper_list[TOTAL_WORDS];

void generate_chunky_frame(const UBYTE *pixel_data, ULONG frame) {
    int y, x;
    UWORD *cop = copper_list;

    for (y = 0; y < CHUNKY_HEIGHT; y++) {
        /* WAIT for this scanline */
        *cop++ = 0x8001 | (((FIRST_LINE + y) & 0xFF) << 8);
        *cop++ = 0xFFFE;

        /* Write each pixel's color */
        for (x = 0; x < CHUNKY_WIDTH; x++) {
            *cop++ = 0x0182;  /* Register: COLOR01 */
            *cop++ = rgb_palette[pixel_data[y * CHUNKY_WIDTH + x]];
        }
    }

    /* End marker */
    *cop++ = 0xFFFF;
    *cop++ = 0xFFFE;
}

Warning

Copper chunky requires disabling all bitplane DMA — you cannot display bitplane graphics alongside copper chunky pixels. The technique is mutually exclusive with normal display rendering.

---

Technique 2: HAM Art

Hold-And-Modify (HAM) mode gives the Amiga 4,096 on-screen colors from only 6 bitplanes. Instead of direct color lookup, HAM encodes most pixels as deltas — modifications to the previous pixel's color. This makes HAM ideal for photorealistic images but nearly useless for animation.

HAM-6 Encoding (OCS/ECS)

Bit 5	Bit 4	Bits 3-0	Meaning
0	0	color index	Use palette[color index] (64 palette entries)
0	1	blue delta	Modify blue component of previous pixel
1	0	red delta	Modify red component of previous pixel
1	1	green delta	Modify green component of previous pixel

HAM-8 Encoding (AGA)

Bits 7-6	Bits 5-0	Meaning
00	palette index	Use palette[index] (64 entries)
01	blue value	Set blue to 6-bit value, keep R,G
10	red value	Set red to 6-bit value, keep G,B
11	green value	Set green to 6-bit value, keep R,B

HAM Art Technique

HAM art for demos works by pre-rendering images in HAM mode, then displaying them as static or slowly-animated screens. The trick is managing the delta encoding to minimize color fringing:

/* ham_render.c — Render a pre-calculated image to HAM-6 bitmap */

/* OCS HAM: 6 bitplanes, 4 bits per component, 64 palette + 3 modify modes */
/* Total on-screen colors: 4,096 (12-bit RGB space) */

#define HAM_SET_COLOR   0  /* Use palette entry (bits 3-0 = index 0-15) */
#define HAM_MOD_BLUE    1  /* Modify blue (bits 3-0 = new blue 0-15) */
#define HAM_MOD_RED     2  /* Modify red (bits 3-0 = new red 0-15) */
#define HAM_MOD_GREEN   3  /* Modify green (bits 3-0 = new green 0-15) */

/* Convert a 12-bit RGB pixel to the best HAM encoding
   given the previous pixel's color */
UWORD rgb_to_ham(UWORD target_rgb, UWORD prev_rgb) {
    int tr = (target_rgb >> 8) & 0xF;
    int tg = (target_rgb >> 4) & 0xF;
    int tb =  target_rgb       & 0xF;
    int pr = (prev_rgb >> 8) & 0xF;
    int pg = (prev_rgb >> 4) & 0xF;
    int pb =  prev_rgb       & 0xF;

    int err_r = abs(tr - pr);
    int err_g = abs(tg - pg);
    int err_b = abs(tb - pb);

    /* If exact match in palette → use SET mode */
    /* (simplified: check against 16 base colors) */
    if (err_r == 0 && err_g == 0 && err_b == 0) {
        /* Exact match — encode as palette reference */
        return (HAM_SET_COLOR << 4) | 0;  /* Palette entry 0 */
    }

    /* Choose the component with largest error to modify */
    if (err_b >= err_r && err_b >= err_g) {
        return (HAM_MOD_BLUE << 4) | tb;
    } else if (err_r >= err_g) {
        return (HAM_MOD_RED << 4) | tr;
    } else {
        return (HAM_MOD_GREEN << 4) | tg;
    }
}

HAM Limitations

Limitation	Impact	Workaround
Fringing	Color deltas only change 1 component per pixel	Pre-calculate optimal delta sequences
Slow rendering	Each pixel depends on previous pixel state	Use Blitter for fast HAM blits
No random access	Can't set arbitrary pixel without context	Pre-render entire scanlines
Limited animation	Moving objects create fringing artifacts	Reserve palette entries for sprites/objects
Display artifacts	Vertical color bleeding from delta chains	Reset color at start of each scanline

---

Technique 3: Scroll Register Distortion

BPLCON1 ($DFF102) controls horizontal scroll offset for the playfield. By changing it per scanline via the Copper, you create wave distortion effects — the classic "sine scrolling text" that defined the Amiga demo aesthetic.

How Scroll Distortion Works

graph LR
    subgraph "Normal Display"
        N["Line 0: offset=0<br/>Line 1: offset=0<br/>Line 2: offset=0<br/>Line 3: offset=0"]
    end
    subgraph "Sine Distorted"
        S["Line 0: offset=0<br/>Line 1: offset=3<br/>Line 2: offset=7<br/>Line 3: offset=4<br/>Line 4: offset=0"]
    end

    N -->|"Copper writes<br/>BPLCON1 per line"| S

Sine Scroll Implementation

/* sine_scroll.c — Generate copper list for sine wave scroll */

#define DISPLAY_LINES 200
#define FIRST_LINE    44
#define SCROLL_WIDTH  16  /* Max scroll offset (0-15 for LoRes) */

void generate_sine_scroll(UWORD *copper, const UBYTE *sine_table,
                          ULONG phase) {
    int y;

    for (y = 0; y < DISPLAY_LINES; y++) {
        int offset;

        /* Get sine value for this line */
        int sine_idx = (phase + y * 4) & 0xFF;
        offset = sine_table[sine_idx] >> 4;  /* 0-15 */

        /* WAIT for this scanline */
        *copper++ = 0x8001 | (((FIRST_LINE + y) & 0xFF) << 8);
        *copper++ = 0xFFFE;

        /* MOVE scroll offset to BPLCON1 */
        *copper++ = 0x0102;                /* BPLCON1 register */
        *copper++ = (offset << 4) | offset; /* Even/odd playfield same */
    }

    /* End marker */
    *copper++ = 0xFFFF;
    *copper++ = 0xFFFE;
}

---

Technique 4: Modulo Wrapping

BPL1MOD and BPL2MOD ($DFF108/$DFF10A) define the byte offset added to each bitplane's data pointer at the end of a scanline. Normally this compensates for interleaving. By setting the modulo to unusual values, you create wrapping effects — the bitmap appears to fold, repeat, or scroll infinitely.

How Modulo Wrapping Works

Normal display (320px wide, 40 bytes/line):
  Line 0: address 0
  Line 1: address 40    (modulo = 40)
  Line 2: address 80

With modulo = -40 (wraps back 40 bytes per line):
  Line 0: address 0     → displays data[0..39]
  Line 1: address -40   → wraps to end of bitmap!
  Line 2: address -80   → wraps further back!

With modulo = 20 (half-width):
  Line 0: address 0     → displays data[0..39]
  Line 1: address 20    → offset by 20 bytes = half-line shift
  Line 2: address 40

Tunnel Effect via Modulo

/* modulo_tunnel.c — Create a tunnel effect using modulo wrapping */

void setup_modulo_tunnel(ULONG frame) {
    int y;
    UWORD *cop = copper_list;

    for (y = 0; y < 200; y++) {
        /* Distance from center creates tunnel perspective */
        int dist = 100 - abs(y - 100);  /* 0 at top/bottom, 100 at center */
        int modulo = dist * 2;          /* Tighter wrapping at center */

        /* WAIT for line */
        *cop++ = 0x8001 | (((FIRST_LINE + y) & 0xFF) << 8);
        *cop++ = 0xFFFE;

        /* Set modulo per line */
        *cop++ = 0x0108;                    /* BPL1MOD */
        *cop++ = (UWORD)(short)modulo;      /* Signed modulo value */
        *cop++ = 0x010A;                    /* BPL2MOD */
        *cop++ = (UWORD)(short)modulo;
    }
}

Scroll Register + Modulo Combined

The most impressive effects combine scroll offset and modulo changes per scanline:

; combined_distort.asm — Per-line scroll + modulo for wave effect

        ; Line 100: normal
        dc.w    $8064,$FFFE           ; WAIT line 100
        dc.w    $0102,$0000           ; BPLCON1 scroll = 0
        dc.w    $0108,$0028           ; BPL1MOD = 40 (normal)

        ; Line 101: slight wave
        dc.w    $8065,$FFFE           ; WAIT line 101
        dc.w    $0102,$0030           ; BPLCON1 scroll = 3
        dc.w    $0108,$0026           ; BPL1MOD = 38 (slightly tighter)

        ; Line 102: more wave
        dc.w    $8066,$FFFE           ; WAIT line 102
        dc.w    $0102,$0070           ; BPLCON1 scroll = 7
        dc.w    $0108,$0020           ; BPL1MOD = 32 (tighter still)

        ; Line 103: peak wave
        dc.w    $8067,$FFFE           ; WAIT line 103
        dc.w    $0102,$00F0           ; BPLCON1 scroll = 15 (max)
        dc.w    $0108,$0018           ; BPL1MOD = 24

        ; Line 104: coming back
        dc.w    $8068,$FFFE           ; WAIT line 104
        dc.w    $0102,$00A0           ; BPLCON1 scroll = 10
        dc.w    $0108,$0020           ; BPL1MOD = 32

---

Technique 5: Plasma Effects

Plasma is a classic demoscene effect created by overlapping sine waves mapped to a color palette. On the Amiga, plasma is implemented by pre-calculating a color lookup table and using the Copper to write it per scanline (or per block).

Plasma Generation

/* plasma.c — Generate plasma color values */

#define PLASMA_WIDTH  40  /* One color per 8 pixels (320/8) */
#define PLASMA_HEIGHT 25  /* One color per 8 scanlines (200/8) */
#define NUM_COLORS    64  /* Plasma palette size */

static UWORD plasma_palette[NUM_COLORS];

/* Pre-calculate plasma palette (rainbow gradient) */
void init_plasma_palette(void) {
    int i;
    for (i = 0; i < NUM_COLORS; i++) {
        int phase = i * 360 / NUM_COLORS;
        int r = (int)(8.0 + 7.0 * sin(phase * 3.14159 / 180.0));
        int g = (int)(8.0 + 7.0 * sin((phase + 120) * 3.14159 / 180.0));
        int b = (int)(8.0 + 7.0 * sin((phase + 240) * 3.14159 / 180.0));
        plasma_palette[i] = (r << 8) | (g << 4) | b;
    }
}

/* Calculate plasma value at (x,y) with time offset */
UBYTE plasma_value(int x, int y, ULONG t) {
    int v = 0;
    v += sine_table[(x * 4 + t) & 0xFF];
    v += sine_table[(y * 6 + t * 2) & 0xFF];
    v += sine_table[((x + y) * 3 + t) & 0xFF];
    v += sine_table[((x * 2 - y + t * 3) & 0xFF)];
    return (v >> 2) & 0x3F;  /* 0-63 → palette index */
}

---

Antipatterns

1. The Copper Chunky Bandwidth Wall

Attempting copper chunky at too high a resolution. With 5+ bitplanes enabled, there aren't enough DMA slots for per-pixel color writes. The display will flicker, show garbage, or skip pixels.

Broken:

; Trying 112-pixel copper chunky with 4 bitplanes active
; → DMA starvation, half the pixels never get written
dc.w    $0100,$$4200   ; BPLCON0: 4 bitplanes enabled
; ... then try 112 MOVE instructions per line → FAIL

Fixed:

; Disable ALL bitplanes for copper chunky
dc.w    $0100,$0200    ; BPLCON0: 0 bitplanes, color on
; Now full DMA bandwidth available for Copper writes

2. The HAM Fringe

Rendering sharp edges in HAM mode without resetting the color state. Adjacent pixels of very different colors create visible "fringing" as the delta encoding struggles to transition.

Broken:

/* Drawing a red square on a blue background in HAM */
/* Each pixel transition goes: blue→red→blue→red → massive fringing */
for (y = 0; y < height; y++) {
    for (x = 0; x < width; x++) {
        /* Each transition needs 2-3 pixels to change color */
        set_ham_pixel(x, y, is_square ? RED : BLUE);  /* Fringes! */
    }
}

Fixed:

/* Use palette entries for the square colors, and place the
   square on scanline boundaries where HAM state resets */
for (y = 0; y < height; y++) {
    /* At start of each line, set base color from palette */
    set_ham_pixel(0, y, is_square ? RED_PAL_ENTRY : BLUE_PAL_ENTRY);

    /* Now deltas work from a known state */
    for (x = 1; x < width; x++) {
        /* Only use SET mode for sharp transitions */
        if (is_border_pixel(x, y)) {
            set_ham_pixel(x, y, target_palette_entry);
        }
    }
}

3. The Modulo Overflow

Setting a modulo value that causes bitplane addresses to wrap into non-bitplane memory or cross allocation boundaries. The result is visible garbage, DMA conflicts, or even system crashes.

Broken:

/* Modulo too large → bitplane addresses go past allocated memory */
custom.bpl1mod = 0x7FFF;  /* Almost 32KB jump per line! */
/* → Reads from random memory, shows garbage, may crash */

Fixed:

/* Calculate modulo based on actual bitmap dimensions */
int bytes_per_line = (width / 8) * num_bitplanes;  /* Interleaved */
int modulo = bytes_per_line - (display_bytes_per_line);
custom.bpl1mod = (UWORD)(short)modulo;  /* Sign-extend correctly */

4. The Scroll Reset Gap

Forgetting that BPLCON1 scroll applies from the Copper write position to the end of the frame. If you set scroll per-line but forget to reset it, the last value persists for all remaining lines.

Broken:

; Sine scroll lines 50-150, but no reset after line 150
dc.w    $8060,$FFFE           ; WAIT line 96
dc.w    $0102,$0070           ; Scroll = 7
; ... more lines ...
dc.w    $8096,$FFFE           ; WAIT line 150 (last sine line)
dc.w    $0102,$0003           ; Scroll = 3
; BUG: Lines 151+ still have scroll=3!

Fixed:

; After the sine section, reset scroll to 0
dc.w    $8097,$FFFE           ; WAIT line 151
dc.w    $0102,$0000           ; Reset scroll to 0

5. The Palette Stride

Assuming HAM palette entries are contiguous. HAM-6 uses only 16 palette entries (0–15) for SET mode — the upper 48 entries of the 64-entry palette are not directly accessible via HAM SET codes.

Broken:

/* Setting HAM palette entry 32 — NOT accessible via HAM SET! */
ham_palette[32] = 0x0FFF;
/* HAM SET mode only uses bits 3-0 → entries 0-15 */

Fixed:

/* Only entries 0-15 are usable with HAM SET (00xxxx) */
/* Place your most important anchor colors in entries 0-15 */
ham_palette[0] = 0x0000;  /* Black (background) */
ham_palette[1] = 0x0FFF;  /* White (highlights) */
/* ... entries 2-15 for key scene colors */

---

Decision Guide

flowchart TD
    START[Need pixel-level effect] --> Q1{Bitplanes available?}
    Q1 -->|No bitplanes needed| CC[Copper Chunky<br/>~56px wide, any colors]
    Q1 -->|Yes, need bitplanes| Q2{Photorealistic or generated?}

    Q2 -->|Photorealistic| HAM[HAM-6/HAM-8 Art<br/>4096/262,144 colors]
    Q2 -->|Generated/procedural| Q3{Wave distortion or wrapping?}

    Q3 -->|Wave distortion| Q4{Horizontal or vertical?}
    Q3 -->|Surface wrapping| MOD[Modulo Wrapping]

    Q4 -->|Horizontal| SCROLL[BPLCON1 Sine Scroll]
    Q4 -->|Vertical| Q5{Color cycling or structure?}

    Q5 -->|Color only| PLASMA[Plasma / Color Cycling]
    Q5 -->|Structural| SPLIT[Raster Split (see copper_effects.md)]

    CC --> BUDGET{DMA budget<br/>for copper writes?}
    HAM --> BUDGET2{Accept fringing<br/>at sharp edges?}
    SCROLL --> BUDGET
    MOD --> BUDGET

    BUDGET -->|Sufficient| OK[Proceed]
    BUDGET -->|Insufficient| REDUCE[Reduce width or<br/>disable bitplanes]
    BUDGET2 -->|Yes| OK2[Proceed with HAM]
    BUDGET2 -->|No| ALT[Use 6-bitplane normal mode<br/>or copper chunky instead]

---

Historical Timeline

timeline
    title Pixel Tricks Evolution
    1985 : Amiga launch — HAM-6 mode (4096 colors)
         : Planar display standard
    1987 : First HAM art images appear in graphics competitions
    1988 : Red Sector — sine scroll distortion in demos
         : Scroll register abuse becomes standard demo technique
    1989 : First plasma effects using copper color cycling
    1990 : Sanity "Arte" — copper chunky full-screen effect
         : HAM art becomes competition category at parties
    1991 : Combined scroll + modulo distortion effects
         : Copper chunky reaches 56-pixel practical limit
    1992 : AGA HAM-8 mode — 262,144 colors
         : Photorealistic HAM-8 images in demos
    1993 : Advanced plasma with pre-calculated tables
         : Modulo tunnel effects
    1994 : Full copper chunky animations at acceptable framerates
    2000+ : Pixel tricks preserved in demo archives
          : FPGA ensures exact register timing

---

Modern Analogies

Amiga Pixel Trick	Modern Equivalent	Why It Maps
Copper chunky	Fragment shader per-pixel output	Both generate color per pixel programmatically
HAM delta encoding	DXT/Etc2 texture compression	Both store deltas from neighbors, not absolute values
Scroll register distortion	Vertex displacement shader	Both deform the output geometry
Modulo wrapping	UV coordinate wrapping/repeating	Both tile the source data
Plasma effect	GPU procedural texture	Both generate visuals from math functions
Per-line register changes	Per-scanline render state	Both change parameters at Y boundaries
Self-modifying copper list	Dynamic command buffer	Both generate GPU commands per frame
Color register palette	CLUT (Color Lookup Table)	Both map indices to RGB values

---

Use Cases

Use Case	Technique	Notable Examples
Full-screen chunky graphics	Copper chunky	Sanity "Arte", ASD demos
Photorealistic static images	HAM-6/HAM-8	Amiga art competitions, IPF cover art
Sine-wave text scroll	BPLCON1 distortion	Every Amiga demo with scrolling text
Wave distortion effect	Scroll + modulo combined	Red Sector, Kefrens demos
Background plasma	Copper color cycling	Numerous demos, cracktros
Tunnel perspective	Modulo wrapping	"Tunnel" demo effect
Virtual scrolling surface	Modulo repeat	Racing games, side-scrollers
Color gradient animation	Per-line color writes	Copper bar variants

---

FPGA / Emulation Impact

Concern	Impact	Notes
Copper chunky timing	Exact per-cycle color register writes	Denise must latch COLORxx at precise pixel positions
HAM delta decoding	Per-pixel color state machine	Must track running R/G/B across entire scanline
Scroll register latency	BPLCON1 changes take effect next line	Must match hardware pipeline delay
Modulo arithmetic	Signed 16-bit addition to address	Address wrapping must handle 24-bit space correctly
BPLCON0 bitplane disable	0-bitplane mode must suppress all BPL DMA	Copper chunky depends on zero bitplane DMA
HAM-8 AGA extension	8-bitplane HAM mode with 6-bit deltas	AGA Lisa chip HAM decoder must be implemented

---

FAQ

Q: Can copper chunky animate at full frame rate? A: Rarely. A 56×200 copper chunky frame requires generating ~11,200 copper instructions per frame. On a 7 MHz 68000, that takes most of the frame time. Most copper chunky demos animate at reduced resolution or partial updates.

Q: Why not always use HAM for more colors? A: HAM's delta encoding makes it nearly impossible to render sharp-edited graphics or animations. Any pixel transition that requires changing more than one color component creates visible fringing. HAM is excellent for pre-rendered images but terrible for real-time rendering.

Q: What's the difference between plasma and copper bars? A: Copper bars are horizontal bands of uniform color (one color per scanline or per group of scanlines). Plasma varies color both horizontally and vertically using sine-based lookup tables, creating a 2D color field. Plasma typically renders to bitplanes (pre-calculated pixel data) while copper bars use register writes only.

Q: Can I combine copper chunky with normal bitplane graphics? A: Not simultaneously — copper chunky requires disabling all bitplane DMA. However, you can use copper chunky on some scanlines and bitplane graphics on others, switching BPLCON0 mid-frame via the Copper. This is rarely done because the copper list size doubles.

Q: How does modulo wrapping differ from scroll wrapping? A: Scroll (BPLCON1) shifts pixel data horizontally within a scanline by 0–15 pixels. Modulo (BPL1MOD) changes the byte offset between consecutive scanlines in memory — it affects which memory addresses are read for each line, not how the bits are shifted. They produce different visual effects: scroll creates smooth horizontal displacement, modulo creates discontinuous "jumps" in the displayed data.

Q: What is EHB (Extra Half-Brite) and how does it relate? A: EHB is a 6-bitplane mode where the 32nd palette entry is automatically generated as a half-brightness copy of entries 0–31, giving 64 colors. It's not a "pixel trick" per se — it's a hardware feature of ECS+. It can be combined with copper effects for interesting results but is documented separately in HAM & EHB Modes.

---

References

Related Knowledge Base Articles

• Pixel Conversion — C2P algorithms, copper chunky theory
• HAM & EHB Modes — HAM-6/HAM-8 encoding, EHB mode
• Copper Effects — Copper bars, gradients, raster splits
• Display Modes — ModeID, BPLCON0 settings
• Video Timing — Scanline structure, beam position
• Blitter Programming — Blitter fill for HAM rendering

External Resources

• Amiga Hardware Reference Manual — Chapter 3: BPLCON0/1, HAM mode, scroll registers
• Amiga Graphics Archive — https://amiga.lychesis.net/specials/Copper.html — Copper chunky and gradient analysis in commercial games
• Scoopex Amiga Hardware Programming (Photon) — YouTube playlist — Bitplane and copper-based effects walkthroughs; companion site: coppershade.org
• Pouet.net — https://www.pouet.net — Copper chunky and plasma demos
• Demozoo — https://demozoo.org — Demoscene production encyclopedia
• HAM Encoder — Various tools for converting images to HAM format