Article 4: The Blitter and Copper – The Amiga’s Secret Weapons 

In the previous chapters, we saw that the Amiga does not rely entirely on its Motorola 68000 CPU. The Custom Chips can perform many tasks independently, and DMA allows them to access Chip RAM without requiring the CPU to move every piece of data itself. 

Two components demonstrate this philosophy particularly well:
the Blitter
the Copper

Both are part of the Agnus chip in the classic Amiga architecture. They serve very different purposes. The Blitter is designed to manipulate blocks of data in Chip RAM. The Copper is a small coprocessor synchronized with the video display that can modify Custom Chip registers while the screen is being generated. Together, they are responsible for many of the graphical techniques that made the Amiga architecture so distinctive. 

What Is the Blitter? 

The name Blitter comes from the expression Bit Block Transfer. Its basic purpose is to process blocks of binary data efficiently. 

This is particularly useful for graphics, because bitmap graphics consist of large amounts of data that often need to be: 
copied
shifted
masked
combined
cleared
moved from one memory area to another

Without a Blitter, the CPU would have to perform many of these operations itself. Instead, the CPU can configure the Blitter and let the hardware carry out the operation. The CPU is therefore effectively saying: "Here are the source areas, here is the destination, and this is the operation I want you to perform." The Blitter then processes the data in Chip RAM. The Four Blitter Channels 

The Blitter works with four logical data channels: 
A
B
C
D

The first three are input sources. 

Channel A Source data 
Channel B Second source data 
Channel C Third source data 
Channel D Destination data 

A simplified operation therefore looks like this: A + B + C → logical operation → D 

The interesting part is the "logical operation." The Blitter does not simply copy the sources to the destination. It can combine them using Boolean logic. Minterms: The Heart of Blitter Logic This is where one of the most important Blitter concepts appears: minterms. The Blitter can perform logical combinations of the A, B, and C input bits to determine the resulting D bit. 

For three binary inputs, there are eight possible combinations. For each combination, the programmer can define whether the destination result should be 0 or 1. This makes the Blitter extraordinarily flexible. 

For example, it can perform operations conceptually equivalent to: 
D = A which simply copies A to D. Or: D = A AND B Or: D = A OR B Or more complex combinations of all three sources. Why Three Sources Are Useful At first, three independent data sources may seem excessive. But imagine drawing an object over a background. 

We have: 
object graphics
a mask defining the object's shape
existing background graphics

The goal is not simply to overwrite the entire rectangular area. Only the pixels belonging to the object should replace the background. Everything outside the object's shape should remain unchanged.

Conceptually, we want something like: Mask + Object + Background → New Background 

This is exactly the kind of operation that can be performed efficiently using the Blitter's multiple sources and Boolean logic. Masks Graphics objects are usually rectangular areas in memory, but the visible object inside that rectangle may have an irregular shape. Imagine a spaceship stored inside a rectangular bitmap. We do not want the entire rectangle to overwrite the background. A mask can determine which parts should be affected. Conceptually: mask = 1 → use object pixel mask = 0 → preserve background pixel The Blitter can combine the mask, graphic data, and background through its logical operations. This means that complex pixel manipulation does not necessarily require the CPU to examine every pixel individually. Shifting Data Another important Blitter capability is shifting. Suppose graphics data is organized into 16-bit words. An object on the screen will not necessarily begin exactly at a 16-pixel boundary. It might need to move horizontally by one pixel. Or five pixels. Or eleven pixels. The Blitter can shift source data while processing it. This allows graphical objects to be positioned at locations that do not align perfectly with word boundaries. For animation and scrolling, this is extremely useful. 

First and Last Word Masks 

When moving rectangular areas, another problem appears. The first and last words of each line may contain pixels outside the area we actually want to modify. The Blitter therefore provides first-word and last-word masks. These masks allow selected bits at the edges of an operation to be protected.

Conceptually: First word → mask unwanted bits Middle words → process normally Last word → mask unwanted bits 

This allows operations to affect precisely defined graphical regions even when their edges do not align perfectly with memory-word boundaries. Blitter Modulos Two-dimensional graphics introduce another problem. Imagine a bitmap that is 320 pixels wide. You want the Blitter to manipulate a rectangle that is only 64 pixels wide. At the end of each processed line, the Blitter must skip the remainder of the bitmap line before continuing with the next line of the rectangular area. This is where modulo values become useful. A modulo tells the Blitter, in effect, how much it needs to adjust an address after processing a line. This enables the hardware to work efficiently with rectangular regions embedded inside larger bitmaps. 

Conceptually: 
process line 
↓ 
adjust address by modulo 
↓ 
process next line 
↓ 
adjust address again 

The CPU does not need to restart the entire Blitter operation for every single line. The Blitter and DMA The Blitter operates directly on Chip RAM. This means it uses DMA. As discussed in Article 3, DMA transfers consume Chip RAM bandwidth. Therefore, a Blitter operation can compete with the CPU and other DMA channels for memory access. This leads to an important observation: The Blitter reduces CPU work, but it does not eliminate the cost of memory access. The Blitter still has to read its source data and write its destination data. Starting a Blitter Operation From the programmer's perspective, a typical Blitter operation can be understood in several stages. First, the CPU configures the relevant Blitter registers. 

These describe things such as: 
source addresses
destination address
logical operation
shifts
masks
modulos
size of the operation

The CPU then starts the Blitter. The hardware performs the requested operation. This demonstrates the basic philosophy we have encountered throughout this series: 
CPU configures the job 
↓ 
specialized hardware performs the job 
↓ 
CPU can perform other work when appropriate 

This principle appears repeatedly throughout the Amiga architecture. 

Enter the Copper 

The Copper is completely different from the Blitter. Instead of manipulating large blocks of graphics data, the Copper controls hardware registers in synchronization with the video display. The name means: Coprocessor You can think of it as a very small processor designed for one unusual job: Perform hardware operations at precisely controlled positions during display generation. This capability gives the Amiga enormous flexibility. The Copper List The Copper executes a program called a Copper list. This list is stored in Chip RAM. 

The list consists of simple instructions that tell the Copper what to do. Its fundamental operations are usually described as: 
MOVE
WAIT
SKIP

For a first understanding, MOVE and WAIT are the most important. MOVE: Change a Hardware Register A MOVE instruction tells the Copper to write a value to an allowed Custom Chip register.

Conceptually: MOVE value → hardware register 

For example, the Copper can modify color registers. Suppose a background color register currently contains blue. The Copper could later change that register to another color. The remarkable part is that this can happen while the video hardware is generating the frame. 

WAIT: Wait for a Screen Position The WAIT instruction makes the Copper wait until the video beam has reached a specified position. In simplified form: WAIT for line 100 ↓ continue executing Copper instructions This allows Copper operations to be synchronized with the display. Combine WAIT and MOVE and something very interesting happens. Conceptually: WAIT for position A MOVE blue → color register WAIT for position B MOVE red → color register WAIT for position C MOVE green → color register The background color can therefore change as the screen is being generated. Raster Effects Changing hardware registers at specific display positions produces what are commonly called raster effects. Color changes are among the simplest examples. Imagine the screen background beginning with dark blue. Further down the screen, the Copper changes the background color to a lighter blue. Further down again, it changes the color once more. The result can be a series of horizontal color bands or, with sufficiently frequent changes, smooth-looking gradients. Importantly, this does not require a large bitmap containing all those colors. Instead, the hardware color register itself is being changed while the image is generated. This is a very different way of thinking about graphics. Changing More Than Colors The Copper is not limited to changing colors. Because it can write to many Custom Chip registers, it can influence several aspects of the display. 

This can be used for effects involving things such as: 
colors
display windows
bitplane parameters
sprite-related registers
scrolling-related values
display configuration

This allows a single video frame to contain regions with different hardware settings. The Copper is therefore not merely an effects generator. It is an important part of the Amiga's display architecture. Copper Lists and the Operating System Copper programming is not restricted to games and demos. The operating system itself uses Copper lists as part of normal screen handling. Software can build display descriptions that ultimately result in Copper instructions controlling the required video registers. This illustrates something important about the Amiga: The Copper is not an exotic add-on. It is part of the normal graphics architecture. Why the Copper Is So Interesting In many traditional systems, changing display parameters would involve the CPU monitoring display timing and writing registers at exactly the correct moment. That would consume CPU time and require extremely accurate timing. The Copper changes this. The CPU prepares a Copper list. The Copper then performs the time-critical register changes itself. So once again we have the familiar pattern: CPU prepares ↓ specialized hardware executes This frees the CPU from continuously managing precise video timing. The Copper and the Video Beam To understand the Copper fully, it helps to remember how a classic CRT display is generated. The picture is constructed line by line. From the hardware's point of view, there is therefore always a current display position.

We can think of this position using: 
horizontal position
vertical position

The Copper's WAIT instruction can synchronize execution with these positions. This means that a Copper list is not simply a sequence of commands. It can be a program whose execution is synchronized with the construction of the picture itself. That is what makes the Copper so unusual. Blitter vs. Copper Although both belong to the Amiga's specialized hardware, their jobs are fundamentally different.

Blitter Copper

Manipulates memory data
Manipulates hardware registers
Designed for block operations
Designed for display synchronization
Copies and combines data
Waits for display positions
Supports masks and shifts
Can modify display parameters
Operates heavily on Chip RAM data
Executes a list stored in Chip RAM
Useful for bitmap operations
Useful for display control and raster effects 

A simple way to remember the difference is: The Blitter changes data. The Copper changes the hardware state at the right moment. Blitter and Copper Working Together The really interesting possibilities appear when the CPU, Blitter, Copper, and display DMA all cooperate. Imagine a game. The CPU calculates the game logic. The Blitter manipulates graphics in Chip RAM. Display DMA fetches bitplane data. The Copper changes color or display registers during screen generation. Paula plays the audio. At the same time, the CPU may be executing program code from Fast RAM. 

So the Amiga is not simply doing: Task 1 → Task 2 → Task 3 → Task 4 Instead, several specialized units are active during the same overall processing period. This is the central idea behind the architecture we have been building up throughout this series. 

Why Demo Programmers Loved the Copper 

The Copper became especially famous through Amiga games and the demoscene. Its synchronization with the display allows effects that appear much more computationally expensive than they actually are. For example, changing a color register does not require the CPU to recalculate an entire bitmap. The display hardware continues generating the picture while the Copper modifies a register at the appropriate moment. This makes the Copper particularly effective when programmers design effects around the capabilities of the hardware rather than simply treating the computer as a CPU attached to a framebuffer. That idea is essential to classic Amiga programming: Instead of asking "How can the CPU draw this?", ask "Which part of the Amiga hardware can help produce this?" A Simplified Frame We can now imagine what happens during a single video frame. CPU Runs the main program. Display DMA Fetches bitplane data. Blitter May manipulate graphical data in Chip RAM. Copper Waits for particular video positions and changes hardware registers. Sprite DMA Fetches sprite data. Paula Continues processing audio. Agnus Coordinates important DMA and Chip RAM activity. Meanwhile, if Fast RAM is available, the CPU can perform many of its own memory accesses without using the same Chip RAM bus. This is why looking only at the Motorola 68000 tells us very little about the true capabilities of an Amiga. The Important Lesson The Blitter and Copper illustrate two different ways of accelerating a computer. The Blitter accelerates data processing by providing specialized logic for memory operations. The Copper accelerates hardware control by performing precisely timed register modifications without requiring continuous CPU intervention. Neither replaces the CPU. Instead, they complement it. That is the important architectural idea: CPU General-purpose processing Blitter Specialized block-data processing Copper Display-synchronized hardware control Each component does the work for which it was designed. 

The Most Important Things to Remember 

1. The Blitter processes blocks of data It is particularly useful for graphical operations in Chip RAM. 
2. The Blitter has three source channels and one destination These are known as A, B, C, and D. 
3. Minterms define logical combinations The Blitter can combine its input sources using flexible Boolean logic. 
4. Masks and shifts make graphical operations flexible They help manipulate objects that do not perfectly align with memory-word boundaries. 
5. Modulos make rectangular operations possible They allow the Blitter to move from one line of an area to the next inside a larger bitmap. 
6. The Copper executes a Copper list The list is stored in Chip RAM and consists of specialized instructions. 
7. WAIT synchronizes the Copper with the display It allows execution to pause until a particular video position is reached. 
8. MOVE changes Custom Chip registers This allows display parameters to be modified while a frame is being generated. 
9. Blitter and Copper complement the CPU Both allow specialized hardware to perform tasks that would otherwise require more CPU involvement. 

The Bigger Picture 

After four articles, we can now see an increasingly complete picture of the classic Amiga. We understand the division between CPU and Custom Chips. We understand why Chip RAM and Fast RAM are fundamentally different. We have seen how DMA and the shared Chip RAM bus allow specialized hardware to access memory. And now we have seen two particularly impressive examples of that philosophy: the Blitter and Copper. But we have so far treated Agnus, Denise, and Paula mainly according to their broad responsibilities. The next step is to look much more closely at the Custom Chipset itself. Coming Next: Agnus, Denise and Paula In Article 5: "Inside the Amiga Custom Chips – Agnus, Denise and Paula", we can examine the three classic Custom Chips individually and then bring them together as a system. This will give us the opportunity to explain Agnus and its DMA/video-timing role, Denise and the bitplane/sprite display pipeline, and Paula's four audio channels, disk interface, interrupts and serial functions before moving on to the Amiga's boot process and operating system.