Article 17: Interrupts, DMA and Hardware Communication 

How the CPU and Custom Chips Work Together One of the defining characteristics of the Amiga is that the CPU does not have to perform every operation itself. 

The custom chips can independently handle important tasks such as:
fetching display data
playing audio
moving graphical data with the Blitter
executing Copper instructions
transferring floppy disk data

This is possible largely because of two fundamental mechanisms: DMA and interrupts. DMA allows hardware to access memory without requiring the CPU to copy every individual piece of data. Interrupts allow hardware to tell the CPU: Something has happened that requires your attention. Together, these mechanisms make the Amiga a highly cooperative system in which the CPU and custom hardware can operate partly in parallel. 

1. The CPU Does Not Do Everything 

Consider a simple computer without specialized hardware. If the processor had to control every operation directly, 

it might need to:
Read display data
Draw pixels
Transfer audio samples
Check the keyboard
Move graphical blocks
Read disk data
Run the application 

The CPU would spend enormous amounts of time performing routine data-transfer operations. 

The Amiga uses a different approach.
                    68000 CPU
                       |
          +------------+------------+
          |            |            |
      Program       AmigaOS      Hardware
                                  control
                                      |
                    +-----------------+----------------+
                    |                 |                |
                  Agnus             Paula            Denise
                    |
             DMA / Blitter /
                 Copper 

The custom chipset takes over many specialized tasks. 

2. Two Important Communication Mechanisms 

The relationship between CPU and hardware involves two especially important mechanisms:
DMA and:
Interrupts 

They solve different problems. DMA DMA answers the question: How can hardware access memory without making the CPU perform every transfer? Interrupts Interrupts answer: How can hardware notify the CPU when something important has happened? These mechanisms complement each other. 

3. What Is DMA? 

DMA stands for: Direct Memory Access It allows hardware components to access memory directly. 

Instead of:
Hardware
   |
   v
 CPU
   |
   v
Memory DMA can allow:
Hardware
   |
   v
Memory 

The CPU configures the operation, but it does not have to perform every individual transfer itself. 

4. DMA on the Amiga 

DMA is particularly important because the Amiga's custom chipset was designed around it. 

DMA is used for tasks such as: 
bitplane display data
sprites
audio
floppy disk transfers
Copper operation
Blitter operations

  The custom chipset can therefore perform substantial work while the CPU executes program code. 

Conceptually:
                 CPU
                  |
                 Agnus
              /    |    </span>
             /     |     </span>
          Video   Audio  Blitter
            |       |       |
            +-------+-------+
                    |
                 Chip RAM 

The exact architecture is more complex, but the important point is that the custom-chip subsystem can access Chip RAM using DMA. 

5. Why Chip RAM Is Special 

This brings us back to the distinction from Article 13. The custom chips need memory they can access. That memory is:
Chip RAM Suppose the display hardware needs bitmap data. 

The data must normally be accessible to the chipset:
Chip RAM
   |
   v
Display DMA
   |
   v
Custom chips
   |
   v
Video output 

If the bitmap were stored in ordinary Fast RAM on a classic Amiga, the custom chipset could not simply perform its normal DMA accesses to it. This is why graphics and audio buffers commonly require Chip RAM. 

6. The CPU and DMA Share Chip RAM 

There is an important consequence. Both the CPU and custom chipset may need access to Chip RAM. 

Conceptually:
              Chip RAM
              /      </span>
             /        </span>
          CPU         DMA
                       |
              +--------+--------+
              |        |        |
           Display   Audio   Blitter They cannot simply perform conflicting bus accesses at exactly the same time. Memory access therefore needs to be coordinated. A key part of this job belongs to Agnus. 7. Agnus as a DMA Controller Agnus is one of the most important chips in the classic Amiga architecture. Among its responsibilities is the coordination of access to Chip RAM. It manages DMA activity for several parts of the custom chipset. Conceptually:
                  Chip RAM
                      |
                    Agnus
          +-----------+-----------+
          |           |           |
       Bitplane     Copper      Blitter
          |
      Display system

Other functions, including audio and disk operations associated strongly with Paula, also depend on DMA access coordinated through the chipset architecture. Agnus therefore plays a central role in deciding how Chip RAM bandwidth is used. 

8. Memory Access Is Divided into Time Slots 

The Amiga organizes Chip RAM access around bus cycles and DMA timing slots. Different hardware functions receive opportunities to access memory. 

A simplified conceptual sequence might look like:
Time --->

+-----+-----+-----+-----+-----+-----+
| DMA | CPU | DMA | DMA | CPU | DMA |
+-----+-----+-----+-----+-----+-----+ 

Real Amiga DMA timing is more sophisticated than this diagram suggests. But the principle is crucial: The CPU and custom chips share available Chip RAM bandwidth. 9. Display DMA Consumes Memory Bandwidth A high-bandwidth display mode requires the chipset to fetch more graphics data. 

For example, increasing: 
the number of bitplanes
horizontal resolution
display activity
can increase demand for Chip RAM access. 

Conceptually:
Low DMA demand

DMA | CPU | CPU | DMA | CPU | CPU


Higher DMA demand

DMA | CPU | DMA | DMA | CPU | DMA The more memory bandwidth consumed by DMA, the fewer opportunities may remain for competing CPU Chip RAM accesses. This is one reason display modes can influence CPU performance when the processor frequently accesses Chip RAM. 10. Why Fast RAM Is Faster for the CPU This provides another explanation for the performance advantage of Fast RAM. CPU access to Chip RAM may compete with custom-chip DMA. Fast RAM does not normally participate in this same classic Chip RAM DMA arbitration. Therefore:
CPU ---> Fast RAM can proceed independently of much of the custom-chip Chip RAM activity. Compare:
CPU
 |
 +----> Fast RAM


CPU ----</span>
         </span>
          > Chip RAM
         /
DMA ----/ The second path involves shared access. The first can provide the CPU with much greater freedom. This is why adding Fast RAM can noticeably accelerate an Amiga even when the CPU itself has not been replaced. 

11. DMA Channels 

The chipset provides DMA functionality for several subsystems. 

Conceptually:
DMA
 |
 +-- Bitplanes
 |
 +-- Sprites
 |
 +-- Audio
 |
 +-- Disk
 |
 +-- Copper
 |
 +-- Blitter 

These DMA channels allow specialized hardware to operate without constant CPU intervention. Amiga programmers can enable or disable relevant DMA facilities through the chipset control system. 

12. The CPU Configures DMA 

DMA does not mean that hardware magically knows what to do. The CPU normally prepares the operation. 

For example, software might: 
allocate suitable Chip RAM,
place graphics or audio data there,
configure hardware pointers,
configure control registers,
enable the required DMA channel.
After that, the hardware can perform much of the repetitive work. 

Conceptually:
CPU
 |
 | configure
 v
Hardware registers
 |
 | start DMA
 v
Custom hardware
 |
 | repeated access
 v
Chip RAM 

This is an extremely efficient division of labour. 

13. Example: Displaying a Bitplane Suppose a program wants to display graphics. 

The CPU can prepare a bitmap in Chip RAM.
CPU
 |
 v
Bitmap in Chip RAM

 The display hardware is then configured with the relevant memory addresses. Once display DMA is active:
Chip RAM
   |
   | DMA fetch
   v
Display hardware
   |
   v
Video signal 

The CPU does not have to manually send every displayed pixel during every screen refresh. The hardware repeatedly fetches the necessary data. This leaves the CPU free for other work. 

14. Example: Playing Audio 

Paula provides four hardware audio channels on the classic Amiga. Software can prepare audio sample data in Chip RAM and configure parameters such as: 
sample address
sample length
period
volume

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

Once configured, Paula can fetch the sample data through DMA. The CPU does not need to write every individual sample to an audio register in real time. 

15. Example: The Blitter 

The Blitter is another excellent example. Suppose the CPU wants to copy or combine graphical data. 

Without dedicated hardware:
CPU:
read data
modify data
write data
repeat
repeat
repeat 

Using the Blitter:
CPU
 |
 | configure operation
 v
Blitter
 |
 | DMA memory operations
 v
Chip RAM 

The Blitter then performs the operation. Meanwhile, the CPU may perform other work, although both can still compete for Chip RAM bandwidth. 

16. DMA Does Not Mean Everything Runs at Full Speed Simultaneously 

This point is important. It is tempting to imagine:
CPU runs
Blitter runs
Audio runs
Copper runs
Display runs all completely independently. 

But many of these components share access to Chip RAM. 

Therefore they compete for a finite resource:
memory bandwidth DMA provides concurrency, but it does not provide unlimited memory bandwidth. The hardware arbitration system determines when each component receives access. 17. Blitter Priority The relationship between CPU and Blitter can be particularly interesting. The chipset provides mechanisms affecting Blitter bus priority. Depending on configuration, intensive Blitter activity can substantially reduce the CPU's opportunities to access Chip RAM. This can be useful when completing a graphical operation quickly is more important than giving the CPU immediate access. Again, this shows that Amiga performance cannot be understood solely by examining the CPU clock speed. 18. Now We Need Interrupts DMA solves the problem of transferring data. But another problem remains. Imagine the hardware finishes an operation. How does the CPU know? 

One possibility would be for the processor to repeatedly ask:
Finished yet?
Finished yet?
Finished yet?
Finished yet? 

This technique is called polling. It can waste CPU time. 

A better solution is often:
Hardware:
"I'll tell you when I'm finished." This is where interrupts become important. 

19. What Is an Interrupt?

 An interrupt is a mechanism allowing an event to temporarily interrupt normal CPU execution. 

Conceptually:
CPU executing program
        |
        |
        | interrupt occurs
        v
Save required state
        |
        v
Run interrupt handler
        |
        v
Handle event
        |
        v
Return
        |
        v
Continue program

 The program does not need to constantly check every hardware component. The hardware can request attention when necessary. 

20. Why Interrupts Matter 

Possible interrupt sources on an Amiga include events associated with: 
vertical blanking
Copper activity
Blitter completion
audio channels
disk operations
serial communication
timers and external hardware

This lets the CPU react efficiently to asynchronous events. 

21. Paula and Interrupt Control 

Paula is heavily involved in the classic Amiga interrupt system. The chipset provides interrupt request and interrupt enable mechanisms. 

At a simplified level:
Hardware event
      |
      v
Interrupt request
      |
      v
Interrupt control
      |
      v
68000 

Software can control which interrupt sources are enabled. This prevents every possible hardware event from automatically disrupting CPU execution. 22. Interrupt Enable and Interrupt Request It is useful to distinguish two related ideas. Interrupt request A hardware event has occurred. Interrupt enable The system allows that particular event to generate CPU interrupt processing. 

Conceptually:
Hardware event
     |
     v
Request bit
     |
     v
Enabled?
 /       </span>
Yes       No
 |         |
 v         |
CPU        |
interrupt  |

This gives software control over which events should receive immediate attention. 

23. Interrupt Levels 

The Motorola 68000 supports multiple interrupt priority levels. The Amiga groups different interrupt sources onto these CPU interrupt levels. 

Conceptually:
Higher priority
      ^
      |
Level 6
Level 5
Level 4
Level 3
Level 2
Level 1
      |
      v
Lower priority

There is also the highest level associated with non-maskable interrupt behavior in the 68000 architecture, although normal Amiga interrupt usage is organized around the relevant hardware levels below it. Higher-priority interrupts can take precedence over lower-priority activity.

24. Multiple Sources Can Share an Interrupt 

Level One CPU interrupt level can correspond to multiple Amiga hardware sources. Therefore receiving a particular interrupt level does not necessarily tell the operating system everything it needs to know. The appropriate interrupt handling code may need to determine which source actually requested service. 

Conceptually:
              CPU interrupt
                    ^
                    |
              Interrupt level
              /     |      </span>
             /      |       </span>
          Audio   Blitter   Copper 

The system examines the relevant interrupt state and dispatches the necessary handling. 

25. Exec and Interrupts Applications should generally not treat the machine as though no operating system exists. Exec provides infrastructure for managing interrupts. This allows operating-system components and drivers to integrate hardware activity within the multitasking environment. 

Conceptually:
Hardware
   |
   v
Interrupt
   |
   v
Exec interrupt system
   |
   v
Interrupt server / handler
   |
   v
Relevant system component 

Direct hardware programming is possible and was common in games and demos, but normal operating-system software should cooperate with the OS. 26. Interrupt Code Must Be Fast Interrupt handling is special because normal execution has been interrupted. An interrupt routine should generally perform only the work necessary at interrupt time. 

A common design philosophy is:
Interrupt occurs
      |
      v
Do urgent work
      |
      v
Signal task
      |
      v
Return quickly 

The task can then perform more complicated processing later. This reduces the amount of time the system spends inside interrupt context. 

27. Signals Connect Interrupts and Tasks 

This brings us back to Exec signals. Suppose hardware finishes an operation. 

A simplified sequence could be:
Hardware
   |
   v
Interrupt
   |
   v
Interrupt handler
   |
   v
Signal()
   |
   v
Waiting task wakes 

The task may have been sleeping while waiting for that event. This is efficient because it does not need to consume CPU time continuously checking the hardware. 28. Waiting Instead of Polling Compare the two approaches. 

Polling
CPU
 |
 +--> check hardware
 |
 +--> check hardware
 |
 +--> check hardware
 |
 +--> check hardware 

Much of the processor's time may be wasted. Interrupt-driven
CPU performs useful work
         |
         |
Hardware event occurs
         |
         v
     interrupt
         |
         v
CPU handles event 

This is one of the fundamental techniques used in efficient operating systems. 

29. Vertical Blank Interrupts 

One particularly important event in graphical systems is the vertical blank. A display is generated repeatedly, frame after frame. There is a period associated with the transition between displayed frames. Software can synchronize operations with this timing. 

Conceptually:
Frame
 |
 v
Display lines
Display lines
Display lines
...
 |
 v
Vertical blank
 |
 v
Next frame 

Vertical blank timing is useful for operations that need to synchronize with the display. 

30. Why Display Synchronization Matters 

Imagine changing display structures at an arbitrary moment. The hardware might already be using them for the current frame. This could create visible artifacts. Synchronizing certain changes with suitable display timing allows software to update graphics more cleanly. Games, demos and the operating system can all benefit from understanding display timing. 

31. Copper Interrupts 

The Copper can also participate in interrupt generation. Remember that the Copper executes a small instruction stream synchronized with the video beam. A Copper list can perform operations at selected positions on the screen. It can also cause an interrupt. 

Conceptually:
Copper waits
     |
     v
Beam reaches position
     |
     v
Copper action
     |
     v
Interrupt request
     |
     v
CPU 

This creates remarkably precise coordination between graphics hardware and processor software. 

32. Blitter Completion 

Another common problem: How does software know when the Blitter has finished? One possibility is polling the Blitter state. Another mechanism involves interrupt-driven notification. 

Conceptually:
CPU starts Blitter
       |
       v
CPU continues
       |
       |        Blitter works
       |             |
       |             v
       |          Finished
       |             |
       +<-- interrupt+ 

The precise strategy depends on what the software is doing. 

33. Audio Interrupts 

Audio channels can also generate interrupts. This allows software to react when audio data reaches particular completion points. For example, software may prepare another audio block or change playback parameters. 

Conceptually:
Paula plays sample
       |
       v
DMA reaches end
       |
       v
Interrupt
       |
       v
Software reacts Again 

DMA and interrupts complement each other. DMA handles repetitive data transfer. Interrupts tell the CPU when intervention is required. 

34. Disk DMA and Interrupts 

Floppy disk operation provides another excellent example. 

Conceptually:
CPU configures disk operation
        |
        v
Disk DMA transfers data
        |
        v
Operation completes
        |
        v
Interrupt
        |
        v
CPU / system handles result 

The processor does not need to manually move every incoming disk word into memory. The hardware assists with the transfer. 35. Interrupts and Multitasking Now we can connect hardware interrupts to the Amiga's multitasking architecture. Imagine a task waiting for I/O.

Task
 |
 | requests I/O
 v
Device
 |
 v
Hardware 

Instead of consuming CPU time while waiting:
Task -> Wait Exec can run another task. 

Later:
Hardware event
      |
      v
Interrupt
      |
      v
Device handling
      |
      v
Signal/message
      |
      v
Waiting task becomes ready 

This is a fundamental reason that asynchronous I/O and multitasking work so well together. 36. A Complete Example: Audio Playback Let's combine everything. 

A program wants to play a sample. 
Step 1: Allocate memory It obtains suitable Chip RAM.
AllocMem(... MEMF_CHIP ...) 
Step 2: Store sample
Audio sample
     |
     v
Chip RAM 
Step 3: Configure Paula The program supplies: sample address
length
period
volume
Step 4: Enable DMA
Paula
 |
 | DMA
 v
Chip RAM 
Step 5: CPU continues The CPU can perform other work. 
Step 6: Audio event occurs At the appropriate point:
Paula
 |
 v
Interrupt request
 |
 v
CPU/system Software can then react if required. This small example combines: memory allocation + Chip RAM + DMA + interrupts + CPU + custom hardware 37. A Complete Example: Displaying Graphics Now consider display output. 

CPU Sets up:
bitmap
bitplanes
display parameters
Copper list Chip RAM Contains:
bitplane data
Copper instructions
possibly sprite data 

DMA Fetches the data as required. Agnus Coordinates DMA and Chip RAM access. Denise Uses graphics data to help generate the video output. Copper Changes display registers at precisely controlled positions. CPU Can meanwhile execute the application. This is the essence of Amiga graphics architecture. 

38. CPU and Custom Chips 

Cooperate It is therefore misleading to think of the custom chipset merely as peripheral hardware attached to the processor. 

A better mental model is:
                  Amiga workload
                        |
           +------------+------------+
           |                         |
          CPU                 Custom Hardware
           |                         |
     Program logic          Repetitive/specialized
     AmigaOS                hardware operations
           |                         |
           +------------+------------+
                        |
                     Memory 

The CPU manages general-purpose work. The custom chips handle specialized operations. DMA and interrupts allow them to cooperate. 

39. Why the Amiga Felt Fast 

Early Amigas typically used CPUs that look modest by later standards. 

Yet the system could perform: 
high-quality graphics
hardware scrolling
multiple audio channels
sprite animation
graphical block operations
floppy transfers
multitasking

The answer is not simply CPU performance. The architecture distributes work.
68000        -> general processing
Agnus        -> DMA coordination and related functions
Blitter      -> block graphics operations
Copper       -> display-synchronized register control
Denise       -> video generation
Paula        -> audio, disk and other I/O-related functions Instead of forcing the CPU to do everything, the machine uses specialized hardware. 

40. Why Direct Hardware Programming Was Popular 

Game and demo programmers often bypassed significant parts of the operating system. Why? 

Because direct control gave them precise access to: 
DMA
Copper
Blitter
display timing
custom registers
interrupts

A demo could exploit the exact timing characteristics of the chipset. 

But there was a trade-off. 
Direct hardware access could make software: more hardware-dependent
less compatible with future machines
less cooperative with multitasking
more sensitive to chipset differences
Operating-system-friendly programming sacrificed some direct control in exchange for better compatibility and resource management. 

41. OS-Friendly Versus Hardware-Hitting Software 

We can roughly compare the approaches: OS-friendly softwareDirect hardware softwareUses AmigaOS APIsUses hardware registersBetter multitasking cooperationMaximum direct controlGenerally more portableHardware-dependentOS manages resourcesProgram manages hardwareBetter suited to applicationsCommon in games/demos Neither approach is automatically "wrong." They serve different purposes. But understanding the distinction is essential when studying Amiga software. 

42. DMA, Interrupts and Exec Together W

e can now build a more complete model:
                    Application
                         |
                         v
                       Exec
                    /        </span>
                   /          </span>
                Tasks       Interrupts
                   |            ^
                   |            |
                   v            |
                  CPU       Hardware events
                   |            ^
                   |            |
                   +----+-------+
                        |
                    Custom Chips
                        |
                       DMA
                        |
                     Chip RAM 

This is still simplified, but it captures the relationship. Exec manages CPU-side software activity. The hardware performs specialized operations. DMA transfers data. Interrupts notify the processor. Signals and messages can then connect hardware events to waiting software. 

43. The Importance of Fast RAM Revisited 

We can now see why Fast RAM is such an important improvement. Without Fast RAM:
CPU --------</span>
             </span>
DMA ----------> Chip RAM
             /
Copper ------/
Blitter ----/ Many components compete for the same memory system. With Fast RAM:
CPU ----------> Fast RAM

CPU ----</span>
         </span>
DMA ------> Chip RAM
Copper --/
Blitter -/ The CPU can perform much of its general processing without competing for every Chip RAM cycle. This is one of the central performance concepts of classic Amiga architecture. 

44. The Big Picture 

Let's put the major components together:
                         68000 CPU
                         /      </span>
                        /        </span>
                  Fast RAM       Exec
                                  |
                        Interrupt handling
                                  ^
                                  |
              +-------------------+-------------------+
              |                   |                   |
            Agnus               Paula               Denise
              |                   |                   |
        DMA arbitration      Audio/Disk           Video
          /       </span>
         /         </span>
     Copper       Blitter
         &nbsp;        /
          &nbsp;      /
           Chip RAM This is deliberately simplified, but it reveals an important concept: The Amiga is a system of cooperating processors, hardware engines, memory regions and operating-system components rather than simply a CPU connected to some peripherals. Conclusion DMA and interrupts are two of the most important mechanisms for understanding how the Amiga achieves so much with comparatively limited CPU power. DMA allows the custom hardware to access Chip RAM without making the CPU perform every individual transfer. 

It is used for important functions including: 
display data
sprites
audio
disk operations
Copper activity
Blitter operations
Interrupts provide communication in the other direction. They allow hardware to notify the processor when an event requires attention. 

Together:
CPU
 |
 | configure
 v
Hardware
 |
 | DMA
 v
Memory

Hardware
 |
 | interrupt
 v
CPU 

This creates an elegant division of labour. The CPU prepares and coordinates operations. The custom chips perform specialized tasks. DMA moves data. Interrupts report important events. Exec integrates many of those events into the operating system's multitasking environment. When combined with Chip RAM and Fast RAM, this architecture also explains one of the most characteristic features of the Amiga: system performance depends not only on processor speed but also on where data is stored and which components are competing for memory bandwidth. This cooperation between CPU, memory, DMA, interrupts and custom hardware lies at the heart of the Amiga's design.