Article 3: The Amiga Bus and DMA – How the Custom Chips Access Memory 

In the previous articles, we established two fundamental ideas about the Amiga:
Chip RAM is shared between the CPU and the Custom Chips. Fast RAM can be accessed by the CPU without competing with the Custom Chips for Chip RAM bandwidth.

But this raises an important question: How can the CPU, graphics hardware, audio hardware, Copper, Blitter, and disk controller all access the same Chip RAM without interfering with each other? The answer lies in the Amiga's bus architecture and its use of DMA, or Direct Memory Access. Understanding this mechanism takes us much closer to understanding how the Amiga actually works internally. 

What Is a Bus? 

Inside a computer, the CPU, memory, and other hardware components need a way to communicate. This communication takes place through electrical connections collectively referred to as a bus. In simplified terms, we can divide a bus into three parts: Address Bus The address bus specifies where data should be read from or written to. 

For example, the CPU might request data stored at a particular memory address. Data Bus The data bus transports the actual information between components. Control Signals Control signals specify what kind of operation is taking place. 

For example: 
memory read
memory write
bus ownership
interrupt-related operations

Together, these signals allow the various parts of the computer to exchange information. The Special Situation of Chip RAM Chip RAM creates an unusual situation because the CPU is not its only user. 

A number of hardware components may need access to it: 
CPU
bitplane DMA
sprite DMA
audio DMA
disk DMA
Copper
Blitter

This is very different from a simple system where the processor is responsible for almost every memory operation. Consider audio playback. The CPU could theoretically read each audio sample from memory and repeatedly send it to the audio hardware. But that would require constant CPU involvement. The Amiga provides a much better solution: DMA. 

What Is DMA? 

DMA means: Direct Memory Access It allows hardware to transfer data between Chip RAM and a hardware subsystem without requiring the CPU to perform every individual transfer. The CPU generally sets up the operation first. For example, software can configure an audio channel with information such as where its sample data is located and how it should be played. Once everything is configured, DMA can fetch the sample data. 

So instead of: CPU → RAM → CPU → Audio Hardware the actual data transfer can effectively become: Chip RAM → DMA → Audio Hardware The CPU remains responsible for controlling the overall process, but it does not need to move every individual piece of data itself. DMA Does Not Make Memory Access Free DMA might sound as though data transfers happen without affecting anything else. They don't. DMA still needs access to memory. Every time DMA retrieves or stores data in Chip RAM, it consumes part of the available memory bandwidth. This means that two things can be true at the same time: DMA reduces CPU workload. But: DMA consumes Chip RAM bandwidth. This distinction is extremely important for understanding Amiga performance. Memory Access Is Divided into Slots Chip RAM cannot simply serve every component at exactly the same instant. Access therefore has to be coordinated. The Amiga divides access into small timing opportunities usually described as memory slots or DMA slots. Different hardware units can use particular slots for their transfers. The exact allocation depends on what the Amiga is doing. 

For example, the system may need memory bandwidth for: 
fetching bitplane data
fetching sprite data
playing audio
reading disk data
executing Copper instructions
operating the Blitter
serving CPU memory requests

This means that available Chip RAM bandwidth changes depending on the hardware currently active. 

Agnus: The Traffic Controller 

This is where Agnus becomes particularly important. Agnus is closely involved in managing access to Chip RAM and controlling DMA. A useful mental model is to imagine Chip RAM as a road. 

Several vehicles want to use it: CPU | Display | Sprites | Audio | Disk | Copper | Blitter 

But the road has limited capacity. Agnus acts somewhat like a sophisticated traffic controller, coordinating who gets access to the shared memory system. This analogy is simplified, but it illustrates an essential principle: Chip RAM access is scheduled rather than being freely available to every component at any moment. The Display Needs a Constant Stream of Data One of the most important users of Chip RAM bandwidth is the display hardware. Classic Amiga graphics commonly use bitplanes. Suppose the screen uses several bitplanes. The display hardware must repeatedly retrieve those bitplane words from Chip RAM while the image is being generated. This happens using DMA. So while an Amiga screen is being displayed, the graphics hardware is continuously consuming part of the available Chip RAM bandwidth. More demanding display configurations can require more DMA activity. That leaves fewer free memory cycles for other components. Including the CPU. 

An Example: The CPU Wants Chip RAM Imagine the Motorola 68000 wants to read an instruction or a variable from Chip RAM. 

Conceptually, the process is simple: 
The CPU requests access to an address.
The memory system performs the access.
The data reaches the CPU.
The CPU continues processing.

But suppose the necessary Chip RAM access opportunity is already required by DMA. The CPU cannot simply force every other hardware component out of the way. It may have to wait until a suitable memory slot becomes available. 

So we get: CPU requests memory 
↓ 
Chip RAM bus is needed by DMA 
↓ 
CPU waits 
↓ 
an appropriate slot becomes available 
↓ 
CPU performs its memory access 

This is one of the major reasons why CPU execution from Chip RAM can be affected by Custom Chip activity. 

Why Fast RAM Changes the Situation 

Now imagine that the CPU is executing its program from Fast RAM rather than Chip RAM. The Custom Chips cannot use this Fast RAM for their normal DMA transfers. So while the graphics hardware is accessing Chip RAM, the CPU may be able to continue working with Fast RAM.

Conceptually: Custom Chips → Chip RAM while simultaneously: CPU → Fast RAM 

This is one of the great advantages of adding Fast RAM to an Amiga. It separates part of the CPU's memory traffic from the Custom Chip traffic. The benefit is therefore not simply: "The computer has more memory." It can also mean: "The CPU has memory that does not share the Chip RAM DMA traffic." 

Display DMA 

Let's look more closely at one important DMA user. When the Amiga displays a bitplane-based screen, the graphics hardware needs data representing the image. That data resides in Chip RAM. The required data is fetched automatically by DMA as the display is generated. The CPU does not have to continuously perform operations such as: "Read the next graphics word." "Send it to the display." "Read another graphics word." Instead, the hardware performs these transfers. This is one reason why the Amiga can generate sophisticated graphics while the CPU continues doing other work. But those graphics transfers consume memory slots. 

Sprite DMA 

The Amiga's hardware sprites also use Chip RAM. Sprite information can contain both control information and graphical data. DMA transfers the required sprite information from Chip RAM to the sprite hardware at the appropriate time. 

Again, the fundamental principle is the same: CPU configures the system → hardware fetches the data rather than: CPU manually transfers every piece of sprite data during display generation 

Audio DMA 

Paula's audio system is another excellent example. The classic Amiga provides four PCM audio channels. Sample data resides in Chip RAM. Once an audio channel has been configured, Paula can obtain sample data through DMA. The CPU is therefore free to continue other calculations rather than constantly feeding individual samples to the audio circuitry. For a game this is enormously useful. While Paula handles audio playback, the CPU can calculate game logic. 

Meanwhile, the graphics hardware can be fetching display data. Several parts of the machine are therefore performing useful work during the same overall period. 

Disk DMA 

Floppy disk operations also make use of DMA. Instead of requiring the CPU to transfer every piece of disk data manually, the Amiga hardware can transfer disk data to or from Chip RAM. Again, the design philosophy remains consistent: Let specialized hardware perform repetitive data-transfer tasks rather than wasting CPU time on them. Disk DMA still consumes Chip RAM cycles, however, so it becomes another participant in the shared memory system. 

The Copper Also Needs Memory 

The Copper is essentially a small specialized coprocessor integrated into the Custom Chip architecture. Its program, called a Copper list, resides in Chip RAM. The Copper reads instructions from memory and can synchronize its operation with positions in the video display. Typical Copper operations involve waiting for a particular display position and changing Custom Chip registers. So although the Copper can operate independently of the CPU, it still needs memory access to retrieve its instructions. That access contributes to the overall Chip RAM traffic. 

The Blitter Is a Particularly Interesting Case The Blitter is designed to process blocks of data efficiently. It can read source data, perform logical operations, and write results back to memory. Consider a graphical operation where data from two source areas is combined and written into another area. 

Conceptually: 
Source A
Source B 
↓ 
Blitter operation 
↓ 
Destination 

Multiple memory accesses may be involved. The Blitter can therefore consume a significant amount of Chip RAM bandwidth while operating. This creates an interesting trade-off. The Blitter can save the CPU from performing the actual calculations and copies. But both the CPU and Blitter may want to use Chip RAM. So a Blitter operation is not simply "free extra performance." Its real advantage comes from allowing specialized hardware to perform operations particularly well suited to it. CPU and Blitter: 

Competition or Cooperation? 

Suppose both the Blitter and CPU are working with Chip RAM. They have to share the available memory bandwidth. Now consider a better situation. The Blitter operates on graphics stored in Chip RAM. Meanwhile, the CPU executes program code and processes data located in Fast RAM. 

Now the workload is divided: Blitter works mainly with: Chip RAM CPU works mainly with: Fast RAM This allows the architecture to operate much more efficiently. This is also why the distinction between Chip RAM and Fast RAM from the previous article is so important. Memory architecture and DMA architecture are closely connected. Not All DMA Has the Same Priority The system cannot simply allocate memory slots randomly. Some transfers are time-critical. 

For example, the display hardware has to receive graphics data at the correct moment. If it waited indefinitely for the CPU or Blitter, the video output could not operate correctly. Consequently, the Amiga hardware uses defined priorities and timing rules for access to Chip RAM. Certain DMA operations receive specific opportunities during a video line. Other users can take advantage of remaining memory slots. This means that the amount of bandwidth available to the CPU or Blitter can depend on the active display configuration and enabled DMA channels. This connection between video timing and memory timing is one of the most fascinating aspects of the Amiga architecture. DMA and the Video Display Are Closely Connected Why does video timing matter so much? Because much of the Amiga's DMA scheduling is synchronized with the video system. The generation of a television-compatible video signal follows a precise timing structure. 

A screen is built from: 
individual lines
horizontal positions
vertical positions
visible areas
blanking periods

Agnus keeps track of this timing. This knowledge is also used by other hardware components. The Copper, for example, can wait for particular positions during display generation. Display DMA can retrieve graphics data at precisely defined times. As a result, the Amiga's video architecture, memory architecture, and DMA system are deeply interconnected. 

A Simplified Example Imagine an Amiga running a game. During one short period: Display hardware fetches bitplane data from Chip RAM. Sprite hardware fetches sprite information. Paula fetches audio samples. Copper reads an instruction from its Copper list. Blitter moves graphics data. CPU wants to read or write Chip RAM. All of these components depend on access to the shared memory system. Agnus coordinates these activities according to the Amiga's hardware timing and DMA rules. Now add Fast RAM. The CPU moves some program code and working data there. Suddenly, many CPU memory accesses no longer have to compete for the same Chip RAM bandwidth. The architecture becomes much easier to appreciate when viewed this way. Why DMA Was So Important The Motorola 68000 in early Amigas operates at a modest clock speed by modern standards. 

If it had to perform every: 
graphics transfer
audio transfer
sprite transfer
disk transfer
screen update

it would have much less time available for actual program logic. Instead, the Amiga distributes these tasks across its hardware. The CPU performs general-purpose processing. The Custom Chips perform specialized operations. DMA connects much of this specialized hardware directly to Chip RAM. This explains an essential characteristic of the Amiga: Its performance is not determined solely by the speed of its CPU. What matters is how efficiently the CPU, memory, DMA channels, and Custom Chips work together. 

Thinking in Parallel A useful way to understand traditional computer programming is: Do task A → then task B → then task C. 

The Amiga encourages another way of thinking: CPU performs task A while: audio DMA performs task B while: display DMA performs task C while perhaps: the Blitter performs task D Of course, these components still share hardware resources and cannot all access Chip RAM simultaneously. But they can operate semi-independently and cooperate across multiple cycles. This kind of parallelism is one of the secrets behind the capabilities of the Amiga hardware. 

The Most Important Things to Remember 

1. Chip RAM is a shared resource The CPU and several Custom Chip DMA channels need access to it. 2. DMA means Direct Memory Access It allows hardware subsystems to transfer data without requiring the CPU to perform every individual transfer. 
3. DMA still consumes memory bandwidth Reducing CPU workload does not mean memory transfers are free. 
4. Agnus coordinates Chip RAM access It plays a central role in DMA and shared memory access. 
5. Display DMA is closely connected to video timing Graphics data must be retrieved at the correct time while the display is being generated. 
6. The CPU may have to wait for Chip RAM If the required memory access opportunity is unavailable because of hardware activity, the CPU can be delayed. 
7. Fast RAM helps separate CPU and Custom Chip traffic The CPU can use Fast RAM without competing with the Custom Chips for the same Chip RAM DMA slots. 
8. The Amiga performs several jobs in parallel The system is designed around cooperation between the CPU and specialized hardware. 

The Bigger Picture 

We can now see the architecture discussed in the first three articles coming together. The Motorola 68000 executes the main program. Chip RAM provides shared memory for the CPU and Custom Chips. Fast RAM provides CPU-accessible memory outside the Custom Chips' normal DMA system. Agnus coordinates important aspects of memory access and DMA. Denise participates in transforming graphics data into the video display. Paula handles audio and other I/O-related functions. The Copper performs display-synchronized operations. And the Blitter manipulates blocks of memory without requiring the CPU to perform every operation itself. These components are not isolated pieces of hardware. They form a tightly integrated system. And that leads naturally to two of the most unusual and fascinating components of the Amiga. 

Coming Next: The Blitter and Copper In Article 4: "The Blitter and Copper – The Amiga's Secret Weapons", we can examine these two components in detail. We will look at how the Blitter works with source and destination data, what minterms are, how masks and shifts work, how a Copper list is structured, how WAIT and MOVE instructions work, and how the Copper can change hardware registers while the display is being generated. This is where the Amiga architecture starts to become especially interesting from a programmer's point of view.