Article 19: Programming the Amiga Custom Chips Copper, Blitter, DMA and Direct Hardware Control 

In the previous article, we looked at programming the Amiga through AmigaOS. 

We saw how applications can use:
Exec
Intuition
Graphics
AmigaDOS
devices
signals
messages

This is the normal way to write system-friendly Amiga applications. But the classic Amiga also offers another fascinating possibility: A program can communicate directly with the custom chipset. 

This approach was particularly important for: 
games
demos
graphics software
multimedia applications
highly optimized software

Direct hardware programming gives the programmer extremely precise control over the machine. But it also comes with risks. To understand why, we first need to look at the hardware registers through which the CPU controls the custom chips. 

1. The Custom Chip Register Area 

The classic Amiga exposes many hardware control registers to the CPU through the processor's address space. The custom register area begins at:
$DFF000
Individual registers occupy locations within this area. 

Conceptually:
68000 Address Space

+------------------------+
| RAM                    |
|                        |
+------------------------+
| Other address regions  |
+------------------------+
| $DFF000                |
| Custom Registers       |
|                        |
| DMA                    |
| Copper                 |
| Blitter                |
| Audio                  |
| Display                |
| Sprites                |
+------------------------+ 

When the CPU accesses these addresses, it is communicating with hardware rather than ordinary RAM. 

2. Memory-Mapped Hardware 

This technique is called: memory-mapped I/O. The processor uses normal address-space operations to access hardware registers. 

Conceptually:
CPU
 |
 | memory access
 v
Address decoder
 |
 +--> RAM address       -> memory
 |
 +--> $DFFxxx address   -> custom hardware 

To the CPU, both operations involve addresses. But the destination behaves very differently. Writing to RAM stores data. Writing to a custom register controls hardware. 

3. Why Hardware Registers Exist 

The custom chips need information telling them what to do. 

For example, the display subsystem needs to know: 
where bitplane data is stored
how many bitplanes are active
display dimensions
display timing
color values

Audio hardware needs information including: 
sample addresses
sample lengths
playback periods
volume levels

The Blitter needs: 
source addresses
destination addresses
modulo values
masks
dimensions
logical operation settings

These parameters are supplied through hardware registers. 

4. A Register Is Not Ordinary Memory 

Suppose software writes a value to a color register. 

Conceptually:
CPU
 |
 | write value
 v
COLOR register
 |
 v
Display hardware
 |
 v
Screen color changes 

The value is not merely being stored like an application variable. It changes hardware behavior. This makes direct register programming extremely powerful. It also makes mistakes potentially serious. 

5. Chip RAM Is Central 

Most custom-chip DMA operations use Chip RAM. 

Therefore direct hardware programming often follows this pattern:
CPU
 |
 +--> prepare data in Chip RAM
 |
 +--> configure custom registers
 |
 +--> enable DMA
 |
 v
Custom hardware
 |
 +--> reads/writes Chip RAM 

Examples of Chip RAM data include: 
bitplanes
sprites
Copper lists
audio samples
Blitter data

This is why understanding Chip RAM is essential before programming the custom chips. 

6. Display Bitplanes 

Classic Amiga graphics are commonly organized using bitplanes. Instead of storing the complete color number for each pixel in one packed value, several separate bitmaps contribute individual bits. 

For example, with three bitplanes:
Plane 2   Plane 1   Plane 0
   0         0         0      -> color 0
   0         0         1      -> color 1
   0         1         0      -> color 2
   0         1         1      -> color 3
   1         0         0      -> color 4 

Three bitplanes provide:
2^3 = 8 colors from the active palette. 

The hardware must repeatedly fetch these bitplane data from Chip RAM while generating the display. 

7. Bitplane Pointers 

The display hardware needs to know where each bitplane begins. Software therefore configures bitplane pointers. 

Conceptually:
Bitplane pointer 1 ---> Chip RAM plane 1
Bitplane pointer 2 ---> Chip RAM plane 2
Bitplane pointer 3 ---> Chip RAM plane 3 

Once display DMA begins, the chipset fetches the data automatically. The CPU does not have to draw every pixel while the screen is being displayed. 

8. DMA Control 

DMA channels are controlled through the chipset. One particularly important register is associated with DMA control:
DMACON Different bits control different DMA-related functions. 

Conceptually:
DMACON
 |
 +-- master DMA
 +-- bitplane DMA
 +-- sprite DMA
 +-- Copper DMA
 +-- Blitter DMA
 +-- audio DMA
 +-- disk DMA 

This gives software fine-grained control over which hardware engines are active. 

9. The Importance of Set and Clear Semantics 

Some Amiga hardware control registers use a special set/clear mechanism. Instead of simply replacing the complete register value, a control bit determines whether selected bits should be set or cleared. 

Conceptually:
control value
     |
     +--> SET selected bits

or

     +--> CLEAR selected bits 

This is very important when programming registers such as DMA and interrupt control registers. A programmer who treats them like ordinary RAM variables can easily enable or disable the wrong facility. 

10. The Copper 

The Copper is one of the most famous components of the Amiga chipset. It is a small coprocessor designed to execute a simple instruction list synchronized with the video display. 

Its fundamental instructions are based around concepts such as:
MOVE
WAIT
SKIP 

The Copper can change certain hardware registers while the display beam moves across the screen. This enables effects that would otherwise require extremely precise CPU timing. 

11. A Simple Copper List 

Conceptually, a Copper list might say:
Set color 0 to blue

Wait until line 100

Set color 0 to red

Wait until line 180

Set color 0 to black 

As the screen is generated:
Top
+-------------------+
| Blue background   |
|                   |
+-------------------+ line 100
| Red background    |
|                   |
+-------------------+ line 180
| Black background  |
+-------------------+
Bottom 

The CPU does not need to execute those color changes at exactly the correct moment. The Copper handles the timing. 

12. Copper MOVE 

A Copper MOVE operation changes an allowed custom-chip register. 

Conceptually:
MOVE value -> hardware register 

For example:
MOVE new_color -> COLOR00 

This allows the Copper to alter display parameters while a frame is being generated. 

13. Copper WAIT 

The WAIT instruction is what makes the Copper particularly interesting. 

Conceptually:
WAIT until beam reaches position Then execution continues. This lets the Copper synchronize precisely with the raster beam. 

The general structure becomes:
MOVE something
WAIT
MOVE something
WAIT
MOVE something else 

This simple mechanism is responsible for many characteristic Amiga graphical effects. 

14. Raster Effects 

Because hardware registers can be changed during the frame, different sections of the screen can use different settings. 

For example:
Scanlines 0-60
      |
      +--> palette A

Scanlines 61-140
      |
      +--> palette B

Scanlines 141-200
      |
      +--> palette C 

Other display parameters can also be modified under suitable conditions. This makes the Copper much more than a simple color-changing processor. 

15. The Copper Frees the CPU 

Without the Copper, the CPU might have to perform carefully timed operations like:
wait for raster
change register
wait for raster
change register
wait for raster
change register 

That wastes CPU time and is sensitive to timing. Instead:
CPU
 |
 | build Copper list
 v
Chip RAM
 |
 | DMA
 v
Copper
 |
 v
Timed register changes 

The CPU prepares the list. The Copper executes it. 

16. Copper Lists Live in Chip RAM 

Because the Copper fetches its instructions using DMA, Copper lists must be accessible to the custom chipset. 

Therefore they normally reside in:
Chip RAM 

This is another direct connection between memory architecture and custom-chip programming.

CPU builds list
      |
      v
   Chip RAM
      |
      v
Copper DMA
      |
      v
Custom registers 

17. The Blitter 

The second major programmable hardware engine is the: Blitter The Blitter performs high-speed block operations on memory. 

Typical uses include: 
copying graphical blocks
filling areas
drawing lines
combining images
masking graphics
scrolling
clearing bitmap areas

Instead of the CPU processing every word individually, it configures the Blitter. 

18. Blitter Channels 

The classic Blitter uses several channels commonly identified as:
A
B
C
D A, B and C can function as input sources. D is the destination. 

Conceptually:
A -----</span>
        </span>
B -------> Logical function ---> D
        /
C -----/ 

This is more sophisticated than a simple memory copier. The Blitter can combine several sources using Boolean logic. 

19. Blitter Minterms 

The Blitter can calculate logical combinations of its input channels. 

Conceptually:
D = function(A, B, C) Possible functions can represent operations related to:
COPY
AND
OR
XOR
masked combinations 

This is extremely useful in 2D graphics. For example, one source may contain image data while another provides a mask. The Blitter can combine them directly. 

20. Why Masks Matter 

Imagine a sprite-like object stored inside a rectangular bitmap. You do not necessarily want the rectangular background copied onto the destination. A mask can determine which pixels should be transferred. 

Conceptually:
Source image
      +
Mask
      +
Background
      |
      v
Blitter
      |
      v
Combined result 

Operations like this were fundamental to many 2D games. 

21. Blitter Pointers 

Like other DMA hardware, the Blitter needs memory addresses. Software configures pointers identifying the source and destination regions. 

Conceptually:
BLT A pointer ---> Source A
BLT B pointer ---> Source B
BLT C pointer ---> Source C
BLT D pointer ---> Destination 

These memory regions need to be accessible to the chipset. Again:
Chip RAM is central. 

22. Modulo Values 

Graphics data is not always copied as one simple contiguous block. Imagine a rectangular area inside a larger bitmap. At the end of each line, the Blitter may need to skip over memory before reaching the next relevant line. This is where modulo values become useful. 

Conceptually:
Process row
xxxxxxxx

skip unused data
..........

Process next row
xxxxxxxx 

The modulo modifies the pointer movement between lines. This allows the Blitter to process rectangular regions inside larger images efficiently. 

23. Blitter Masks 

The first and last words of a Blitter operation may need special masking. Why? Because a graphical object may begin or end at a position that does not align perfectly with a full 16-bit word boundary. Masks allow selected bits at the edges to be preserved or ignored. 

Conceptually:
Word 1       Middle words      Last word

xxxx####     ########          ####xxxx

x = protected/ignored
# = processed 

This is particularly useful for graphics that are not aligned to word boundaries. 

24. Blitter Shifts 

The Blitter can also shift source data. This is extremely important for graphics. Suppose an object is stored at one horizontal position but needs to be drawn several pixels to the right. Without shifting support, the CPU might need to realign the bitmap manually. Instead, the Blitter can shift the data during the operation. 

Conceptually:
Original:

########........

Shifted:

....########.... 

Combined with masks and logical operations, this makes the Blitter a powerful 2D graphics engine. 

25. Starting a Blitter Operation 

A typical conceptual sequence is:
CPU
 |
 +--> configure control registers
 |
 +--> set pointers
 |
 +--> set modulo values
 |
 +--> set masks
 |
 +--> set size
 |
 v
Blitter starts
 |
 v
DMA accesses Chip RAM
 |
 v
Operation completes 

Once started, the CPU does not need to perform every transfer. 

26. CPU and Blitter Can Work in Parallel 

While the Blitter operates, the CPU may perform other tasks. 

Conceptually:
CPU                    Blitter
 |                        |
 | game logic             | copying graphics
 |                        |
 | sound management       | copying graphics
 |                        |
 | input processing       | finished 

This parallelism is one reason the Amiga could achieve impressive graphical performance. However, there is an important limitation. Both may need Chip RAM bandwidth. 

27. Bus Contention 

As discussed in Article 17, Chip RAM is shared.
             Chip RAM
             /      </span>
            /        </span>
          CPU       Blitter
                    Copper
                    Display DMA
                    Audio DMA 

The CPU and chipset therefore cannot all access Chip RAM without coordination. Agnus arbitrates access using the chipset's DMA timing system. Heavy DMA activity can reduce the CPU's opportunities to access Chip RAM. 

28. Blitter Priority 

The chipset allows the Blitter to be given stronger priority relative to CPU access. 

Conceptually:
Normal:

CPU   DMA   CPU   Blitter   CPU ...


Blitter-priority situation:

Blitter  Blitter  DMA  Blitter  CPU ... 

The real timing is more structured than this simplified example, but the principle is what matters. Finishing the Blitter job faster can come at the cost of delaying CPU access to Chip RAM. 

29. The CPU Can Escape to Fast RAM 

This leads to a very important optimization. 

Suppose the CPU's: 
program code
stack
variables
calculations
are in Fast RAM. 

Then while the Blitter works heavily in Chip RAM, the CPU can continue much of its work using Fast RAM.

CPU ----------> Fast RAM

                   Chip RAM
                   /   |   </span>
              Blitter DMA  Copper 

This is one of the best examples of why Fast RAM can dramatically improve real Amiga performance. 

30. Sprites 

The Amiga chipset also supports hardware sprites. Sprites have their own data structures stored in Chip RAM. 

Conceptually:
Sprite data
    |
    v
Chip RAM
    |
   DMA
    |
    v
Sprite hardware
    |
    v
Display 

Because hardware handles much of the sprite display process, the CPU does not need to redraw every sprite into the bitmap for every frame. 

31. Copper and Sprites 

Together The Copper can modify hardware registers during display generation. This means clever programmers can reuse and manipulate hardware resources at different vertical positions. 

Conceptually:
Top of display
     |
Sprite configuration A
     |
     v
Copper waits
     |
     v
Change registers
     |
     v
Sprite configuration B
     |
Bottom of display 

Techniques like this allowed developers to push the hardware beyond what a simple list of specifications might suggest. 32. Audio Hardware Paula provides four DMA-driven audio channels. 

For each channel, software configures values such as: 
sample address
length
period
volume

Conceptually:
CPU
 |
 | configure
 v
Paula
 |
 | DMA
 v
Chip RAM sample
 |
 v
Audio output 

Again the CPU sets up the operation and specialized hardware performs the repetitive real-time work. 

33. Custom Chip Interrupts 

Custom hardware can generate interrupts. 

This enables software to react to events such as: 
vertical blank
Copper events
Blitter completion
audio events
disk events

Conceptually:
Custom chip
     |
 interrupt
     |
     v
68000
     |
     v
Interrupt handler 

This creates two-way communication.
CPU -> registers -> hardware

hardware -> interrupt -> CPU 34. 

Waiting for the Blitter Suppose software needs the result of a Blitter operation before continuing. It cannot simply assume that the operation has completed immediately. 

Possible strategies involve: 
checking Blitter status
synchronizing correctly through system or hardware mechanisms
structuring the program so the CPU performs independent work first

A naive program that starts a Blit and immediately modifies the same memory can create incorrect results. Hardware programming therefore requires careful synchronization. 

35. Double Buffering 

One important graphics technique is double buffering. Instead of modifying the bitmap currently being displayed, software uses two buffers.

Buffer A -> currently displayed
Buffer B -> being drawn When Buffer B is ready:
Buffer B -> display
Buffer A -> being drawn 

Then they swap again. This helps avoid showing partially updated graphics. 

36. Why Double Buffering Works Well on the Amiga 

The custom hardware displays graphics by reading memory through bitplane pointers. Instead of copying an entire finished screen into another special display memory area, software can arrange for the hardware to display another prepared bitmap. 

Conceptually:
Frame 1:

Display DMA ---> Bitmap A
CPU/Blitter ---> Bitmap B


Frame 2:

Display DMA ---> Bitmap B
CPU/Blitter ---> Bitmap 

A Changing the displayed buffer at the correct time can produce smooth animation. 

37. Copper and Double Buffering 

Copper lists can also participate in display configuration. A program may maintain display-related structures for each frame. 

The general idea becomes:
Prepare next frame
      |
      +--> bitmap
      |
      +--> Copper information
      |
      v
Wait for appropriate display timing
      |
      v
Switch 

This combines CPU preparation, Blitter operations, Copper execution and display DMA. 

38. A Simple Game Frame 

Imagine a game running at one frame. 

Conceptually:
1. Read controls
       |
       v
2. Update game logic
       |
       v
3. Blitter draws objects
       |
       v
4. Prepare Copper settings
       |
       v
5. Wait for frame synchronization
       |
       v
6. Switch display buffer
       |
       v
7. Repeat Meanwhile, audio DMA can continue independently. 

That is an excellent example of the Amiga's parallel design. 

39. CPU, Copper and Blitter Divide the Work 

A well-designed program can divide responsibilities:

68000
 |
 +--> game logic
 +--> calculations
 +--> hardware setup


Copper
 |
 +--> raster synchronization
 +--> register changes


Blitter
 |
 +--> graphics copying
 +--> masking
 +--> clearing
 +--> shifting


Paula
 |
 +--> audio DMA


Display hardware
 |
 +--> fetch bitplanes
 +--> generate video 

Instead of one CPU doing everything, the workload is distributed. 

40. Why Demos Became So Important 

The Amiga demo scene became famous for pushing this architecture to extraordinary limits. 

Demo programmers experimented with: 
precise raster timing
Copper tricks
unusual display modes
Blitter effects
sprite reuse
synchronization
audio timing
DMA behavior

The goal was often: Make the machine display or play something that seems impossible from its published specification. Because programmers could access the hardware directly, they could exploit extremely detailed behavior. 

41. The Danger of Direct Hardware Access 

Direct hardware programming has serious disadvantages. 

A program may assume:
specific chipset
specific timing
specific CPU speed
specific memory layout
specific interrupt behavior 

These assumptions can fail on another Amiga model. For example:
A500
A1200
A3000
A4000 

do not all represent identical hardware environments. Code tied too closely to one machine can become incompatible. 

42. AmigaOS Also Uses the Hardware 

There is an even more immediate problem. While your program is running:
AmigaOS may also believe that it controls: interrupts
display hardware
Copper
Blitter
DMA
input
memory

If your program changes hardware state without coordinating with the operating system, both sides can interfere with each other. 

Conceptually:
Application ----</span>
                 > same hardware
AmigaOS --------/ Chaos can result. 

43. Taking Over the Machine 

Games and demos that need exclusive hardware control may deliberately take over important parts of the system. This requires careful handling. 

Conceptually:
Normal:

AmigaOS ---> hardware


Takeover:

Program ---> hardware


Exit:

Restore hardware state
      |
      v
AmigaOS ---> hardware 

The important part is not only taking control. The program must also restore the machine correctly afterwards. 

44. Multitasking and Hardware Control 

An ordinary AmigaOS program should not assume it is the only task running. 

Imagine:
Task A changes display register

Task B changes same register

OS changes same register Without coordination, results become unpredictable. This is why OS-friendly programs normally use system APIs where appropriate. AmigaOS can coordinate resource ownership. 

45. Direct Hardware Programming Is Not Always Faster 

It is tempting to assume:
Direct hardware = fastest
Operating system = slowest 

But that is too simplistic. AmigaOS itself can use the custom hardware efficiently. 

For ordinary applications, system APIs can provide: 
compatibility
resource management
multitasking
tested abstractions
reduced development complexity

Direct hardware programming becomes especially attractive when precise control or highly specialized performance is required. 

46. The Best Approach Depends on the Program 

A Workbench utility should generally behave differently from a full-screen action game. 

Workbench application Prefer:
Exec
Intuition
Graphics
DOS
Devices 

Hardware-intensive game or demo May make greater direct use of:
Copper
Blitter
DMA
Custom registers
Interrupts 

The architecture gives programmers both options. That flexibility is one of the Amiga's great strengths. 

47. Programming the Hardware 

Changes How You Think When using a modern graphics API, a programmer might think: Draw this image here. 

When programming the classic Amiga hardware directly, the thought process can become:
Where is the bitmap in Chip RAM?

Which bitplanes are active?

How much DMA bandwidth is available?

Can the Blitter perform this operation?

Does the data need shifting?

What mask do I need?

When should I modify the display registers?

Could the Copper perform the change?

Will the CPU compete for Chip RAM?

Can CPU work be moved into Fast RAM? 

Hardware constraints become part of the algorithm. 

48. A Complete Graphics Example 

Suppose a game wants to move an object across the screen. CPU Calculates the new position.
x = x + speed Blitter Draws the object into the back buffer.
source graphics
      |
      + mask
      |
      v
Blitter
      |
      v
Back buffer 

Copper Performs any required raster-timed effects. Display DMA Continues displaying the current front buffer. Frame boundary The buffers are exchanged.
Front <--> Back Audio Paula continues playing sound through DMA throughout the process. Multiple parts of the machine work together. 49. The Amiga as a Parallel System This leads to one of the most important conclusions in our entire course. 

The Amiga should not be visualized simply as:
68000
  |
  v
Everything else A better model is:
                      Workload
                         |
       +-----------------+-----------------+
       |                 |                 |
      CPU             Copper           Blitter
       |                 |                 |
       |                 |                 |
       +-----------+-----+--------+--------+
                   |              |
                 Agnus          Paula
                   |              |
                   +------+-------+
                          |
                       Chip RAM
                          |
                       Denise
                          |
                       Display 

This diagram is simplified, but the philosophy is important. The Amiga distributes work among specialized processing units. 

50. Why This Architecture Was Revolutionary 

In the mid-1980s, many home computers relied far more heavily on the main CPU for system operations. 

The Amiga instead provided dedicated hardware for: 
graphics generation
block operations
raster-synchronized control
sprites
multi-channel audio
DMA transfers
The CPU became the coordinator rather than the sole worker. 

This allowed relatively modest CPU hardware to produce sophisticated multimedia output. 

51. Connecting the Previous Articles 

We can now see why all the earlier subjects were necessary. Chip RAM Stores data the custom chips can access. Fast RAM Allows the CPU to work without competing for every Chip RAM cycle. DMA Allows hardware to access Chip RAM independently. Interrupts Allow hardware to notify the CPU. Blitter Performs specialized memory and graphics operations. Copper Changes hardware registers synchronized with the display. Exec Coordinates software tasks and operating-system resources. Libraries Provide higher-level APIs. AmigaDOS Provides files, processes and storage abstractions. They are not isolated topics. They are parts of one architecture. Conclusion Direct custom-chip programming reveals the Amiga at its most distinctive. The CPU can configure hardware through memory-mapped custom registers. Data stored in Chip RAM can then be processed independently by specialized hardware through DMA. The Copper executes simple display-synchronized instructions. The Blitter performs powerful block-memory and graphical operations. The display hardware fetches bitplanes and sprites automatically. Paula can play audio through DMA while the CPU performs completely different work. 

The result is a cooperative architecture:
CPU
 |
 | configure
 v
Custom hardware
 |
 | DMA
 v
Chip RAM
 |
 +--> Graphics
 +--> Audio
 +--> Blitter
 +--> Copper Interrupts provide communication back to the processor:
Hardware
   |
interrupt
   |
   v
CPU 

Together, these mechanisms explain why the classic Amiga was capable of graphical and multimedia performance that seemed remarkable for its CPU speed. The secret was never simply the Motorola 68000. It was the way the 68000, Chip RAM, Agnus, Denise, Paula, Copper, Blitter and DMA system were designed to work together. And this brings us almost to the end of our Amiga course. Article 20 can now serve as the final synthesis: “How the Complete Amiga Works: From Power-On to Applications, Graphics and Sound”, connecting the entire journey from Kickstart and Exec through memory, AmigaOS and the custom chipset into one complete system model.