Article 5: Inside the Amiga Custom Chips – Agnus, Denise and Paula 

In the previous articles, we looked at the basic Amiga architecture, Chip RAM and Fast RAM, DMA, the memory bus, and two of the Amiga's most fascinating hardware components: the Blitter and Copper.

Now it is time to take a closer look at the three chips that form the heart of the classic Amiga chipset:
Agnus
Denise
Paula

Each has a different role. Agnus is closely connected with memory access, DMA, video timing, the Blitter, and the Copper. Denise turns graphics data into the actual video display. Paula handles audio, floppy disk data, interrupts, serial communication, and other I/O functions. But the real strength of the Amiga comes from the way these chips work together. The Original Amiga Chipset The chipset used in early Amigas is commonly called OCS, the Original Chip Set. It appeared in systems such as the Amiga 1000, Amiga 500, and Amiga 2000, although chipset revisions and configurations differ between individual models and production periods. 

Later generations expanded the architecture: 
OCS – Original Chip Set
ECS – Enhanced Chip Set
AGA – Advanced Graphics Architecture

For now, however, we will concentrate mainly on the basic architecture represented by the classic Agnus, Denise, and Paula combination. Understanding these chips makes many other aspects of the Amiga much easier to understand. Agnus: At the Center of the Chipset If we had to choose one Custom Chip as the central coordinator of the original Amiga architecture, Agnus would be an obvious candidate. 

Agnus is involved in several fundamental functions: 
Chip RAM access
DMA control
video timing
memory refresh
Blitter
Copper

Agnus therefore sits at the intersection between memory, graphics, and several other hardware components. This is why it has appeared repeatedly in the previous articles. 

Agnus and Chip RAM 

Chip RAM must be shared by multiple hardware components. The CPU may need to access it. At the same time, DMA may be needed for: 
bitplanes
sprites
audio
floppy disk operations
the Copper
the Blitter

Agnus is central to the arbitration and timing that make this shared-memory architecture possible. This leads to one of the most important relationships in the Amiga: 
CPU 
↕ 
Agnus 
↕ 
Chip RAM 

while various DMA channels are also using that memory system. Agnus is therefore much more than a simple peripheral controller. It is deeply integrated into the Amiga's memory architecture. 

Agnus and DMA 

As we saw in Article 3, DMA allows hardware components to access Chip RAM without requiring the CPU to perform every individual transfer. Agnus plays a central role in controlling this DMA system. For example, graphics data has to be fetched while the display is being generated. Audio data must reach Paula at the required rate. The Copper needs to fetch instructions. The Blitter needs memory cycles for its operations. These activities have to coexist within the available 

Chip RAM bandwidth. 

This is one reason why the Amiga's memory architecture and Custom Chip architecture cannot really be studied separately. They are parts of the same system. Agnus and Video Timing Another important responsibility of Agnus is video timing. A classic video display is generated line by line. The hardware must therefore keep track of the current horizontal and vertical position during display generation. This timing is important for several parts of the system. Display DMA has to retrieve graphics data at the appropriate time. Sprites must be synchronized with the display. And perhaps most famously, the Copper can wait for specific positions in the video frame. 

So concepts such as: 
DMA timing
raster position
Copper timing
display generation

are closely connected through Agnus. The Blitter Lives Inside Agnus The Blitter discussed in Article 4 is integrated into Agnus. Remember its basic purpose: Process blocks of data in Chip RAM without requiring the CPU to perform every operation itself. 

The Blitter can: 
read several data sources
combine them using Boolean logic
shift data
apply masks
write results back to memory

This makes it particularly useful for bitmap graphics. However, it also means the Blitter requires access to Chip RAM. It therefore participates in the same shared-memory system coordinated through Agnus. 

The Copper Is Also Part of Agnus 

The Copper is another important component located within Agnus. Its role is fundamentally different from that of the Blitter. The Blitter manipulates memory data. The Copper executes simple instructions synchronized with video timing. Its most important operations include: WAIT Wait for a particular video position. MOVE Write a value to an allowed Custom Chip register. This allows hardware parameters to be changed while a video frame is being generated. Agnus therefore combines several important concepts we have already encountered: memory access + DMA + video timing + Blitter + Copper Denise: Creating the Display 

If Agnus organizes the flow of graphics data and display timing, Denise is responsible for major parts of turning that graphics information into the video output. Denise receives graphics-related data and interprets it according to the configured display mode. 

Some of its most important responsibilities include: 
bitplane interpretation
color selection
sprite processing
playfield generation
parts of the final video output process

To understand Denise, we first have to return to one of the most characteristic features of Amiga graphics: bitplanes. Understanding Bitplanes Many modern graphics systems store a pixel as a value directly representing its color. Classic Amiga planar graphics work differently. A picture can be divided into several bitplanes. Each bitplane contributes one bit to the final color number of a pixel. Imagine a screen with three bitplanes. At one particular pixel position, the corresponding bits might be: Bitplane 0: 1
Bitplane 1: 0
Bitplane 2: 1
Together they form a binary value: 101 This value selects one of the available color registers. With three bitplanes, three bits can represent: 2³ = 8 color indices Similarly:

Bitplanes

Special display modes can alter how this basic relationship is used, but the table illustrates the principle of normal planar graphics. Agnus Fetches, Denise Interprets This gives us a useful way of understanding the relationship between Agnus and Denise. 

In simplified form: 
Chip RAM 
↓ 
Bitplane DMA controlled through Agnus 
↓ 
Bitplane data 
↓ 
Denise 
↓ 
Pixel/color interpretation 
↓ 
Video output 

Agnus and Denise therefore work together in the display pipeline. Agnus is heavily involved in getting the required data from memory at the right time. Denise interprets that data to help produce the actual picture. Denise and the Color Registers The bitplane data does not necessarily contain the final RGB value of every pixel. Instead, in normal indexed display modes it produces color indices. Those indices select colors from the Amiga's hardware color registers. This has an interesting consequence. If the color stored in a color register changes, the meaning of that color index changes for subsequent display output. And this brings us directly back to the Copper. The Copper can change color registers while the frame is being generated. 

For example, conceptually: 
Top of screen Color 0 = dark blue Copper WAIT 
↓ 
Color 0 = medium blue Copper WAIT 
↓ 
Color 0 = light blue 

The bitmap itself has not necessarily changed. Instead, the interpretation of a color index has been changed during display generation. This interaction between Agnus, Copper, and Denise is one reason the Amiga can produce impressive raster effects with relatively little CPU involvement. 

Denise and Sprites 

Denise is also closely associated with the Amiga's hardware sprites. Sprites are independent graphical objects handled by dedicated hardware. The classic Amiga provides eight hardware sprite channels. Sprite data is stored in Chip RAM and transferred using DMA. 

Conceptually, the process looks like this: 
Sprite data in Chip RAM 
↓ 
DMA 
↓ 
Sprite hardware 
↓ 
Combined with display 

Sprites can therefore be displayed without first having to draw their graphics directly into the screen's bitplanes. 

This is particularly useful for moving objects such as: 
mouse pointers
game characters
bullets
interface elements

Depending on the desired visual result, multiple sprite channels can also be combined. Dual Playfields Another interesting Amiga graphics feature is Dual Playfield mode. Instead of treating all available bitplanes as one graphics layer, they can be divided into two independent playfields. 

Conceptually: 
Bitplanes A → Playfield 1 
Bitplanes B → Playfield 2 

This is useful for effects involving independently organized foreground and background graphics. The hardware can determine which playfield appears in front. Again, this demonstrates an important characteristic of the Amiga: Many operations that could require significant software processing on another system are supported directly by specialized display hardware. 

Paula: The Sound of the Amiga 

The third major Custom Chip is Paula. Paula is probably best known for audio. The classic Amiga provides four hardware-supported PCM audio channels. Traditionally, they are considered as two channels on the left and two on the right for stereo output. Each audio channel can play sample data stored in Chip RAM. 

Software configures information such as: 
sample location
sample length
playback period
volume

DMA can then transfer sample data from Chip RAM for playback. Sample-Based Audio This was an important feature of the Amiga. Rather than relying only on predefined synthesized tones, the Amiga can reproduce digitized sample data. 

A sample might contain: 
a drum
a voice
a piano note
an explosion
a sound effect
part of a musical instrument

Once digitized, that waveform can be stored in Chip RAM and played by Paula. This gives software enormous flexibility. The same audio hardware can reproduce completely different types of sound simply by using different sample data. Audio Playback and DMA Once an audio channel has been configured, Paula does not require the CPU to manually provide every sample value at precisely the correct moment. DMA handles the memory transfers. 

Conceptually: 
CPU 
↓ 
configures audio channel 
↓ 
Audio sample in Chip RAM 
↓ 
DMA 
↓ 
Paula 
↓ 
audio output 

Meanwhile, the CPU can continue doing other work. This is the same architectural principle we have seen repeatedly. The CPU controls the overall process. Dedicated hardware handles repetitive, timing-sensitive operations. Paula's Four Audio Channels Each of Paula's audio channels has its own control parameters. This allows several sounds to be played simultaneously. 

For example: Channel 0 → music Channel 1 → music Channel 2 → sound effect Channel 3 → another sound effect 

In practice, Amiga music software often uses the four channels in much more sophisticated ways. Tracker software became especially associated with this capability. By rapidly changing samples, notes, periods, and effects, musicians could create impressively complex compositions with only four physical audio channels. Paula Is More Than Audio Calling Paula simply the "sound chip" misses a large part of its functionality. 

Paula is also involved in: 
floppy disk data handling
interrupts
serial communication
controller-port-related I/O

This makes Paula an important general I/O component within the Amiga architecture. Floppy Disk Data The Amiga's floppy subsystem works differently from a simple arrangement in which the CPU is responsible for transferring every individual piece of disk data. Paula participates in handling the floppy disk data stream, while DMA allows disk data to be transferred to or from Chip RAM. 

Conceptually: 
Floppy drive 
↕ 
Paula / disk hardware 
↕ 
DMA ↕ Chip RAM 

Again, the CPU controls the process but does not need to perform every individual data transfer itself. 

Interrupts 

Another important responsibility of Paula is interrupt handling. An interrupt is a hardware mechanism used to notify the CPU that something requires attention. Instead of the CPU constantly asking: "Has something happened?" "Has something happened?" "Has something happened?" hardware can generate an interrupt. 

Conceptually: 
Hardware event 
↓ 
Interrupt 
↓ 
CPU temporarily responds 
↓ 
event is handled 
↓ 
CPU continues its previous work 

Interrupts are essential for coordinating many activities in a multitasking computer system. 

The Three Chips Working Together 

Now we can put the pieces together. Imagine an Amiga running a game. Agnus Coordinates Chip RAM access and DMA timing. The Blitter is moving graphics. The Copper is waiting for specific display positions. Denise Receives graphics data and contributes to generating the video output. Bitplanes and sprites become visible graphics. Paula Plays digital audio samples. At the same time, it participates in other I/O-related functions. 

Motorola 68000 Runs the game logic: 
player movement
enemy behavior
collision detection
scoring
operating system or game routines

This means several hardware systems can be active during the same period. A Frame Inside the Amiga It is useful to imagine a single video frame. 

While that frame is being produced: 
Agnus coordinates DMA.
Bitplane data is fetched from Chip RAM.
Denise interprets the graphics data.
Sprite data is incorporated into the display.
Copper instructions may change registers at specific raster positions.
The Blitter may be manipulating other graphics data in Chip RAM.
Paula continues playing audio samples.
The CPU continues executing the main program whenever its required resources are available.

The Amiga is therefore not carrying out one large operation at a time. It is a coordinated system of specialized processors and state machines operating together. 

Why the Amiga Architecture Was So Effective 

The important question is not simply: How fast is the CPU? Instead, the more interesting question is: How much work can be delegated to specialized hardware? Consider what the CPU does not necessarily have to handle continuously. It does not need to manually fetch every display word. It does not need to feed every audio sample individually. It does not necessarily need to move every block of bitmap data itself. It does not have to perform every raster-synchronized register change. Instead: Agnus handles central DMA and timing functions. The Blitter processes memory blocks. The Copper controls registers in synchronization with the display. Denise handles major parts of graphics generation. Paula handles audio and several I/O functions. The CPU coordinates the overall software environment. CPU + Custom Chips 

We can now summarize the architecture with a useful mental model. Motorola 68000 General-purpose processing Runs applications, games, and operating system code. Agnus Memory, DMA and timing Coordinates many activities around Chip RAM and contains the Blitter and Copper. Denise Graphics Transforms planar graphics and sprite information into the display. Paula Audio and I/O Provides sample-based audio and participates in disk, serial, interrupt, and I/O functionality. Chip RAM Shared workspace Provides memory accessible to the CPU and Custom Chips. 

Fast RAM CPU workspace 

Allows the CPU to work with memory outside the Custom Chips' normal DMA path. 

Together they form the classic Amiga hardware architecture. 

The Most Important Things to Remember 
1. Agnus is central to memory and DMA It coordinates important aspects of Chip RAM access and video timing. 
2. The Blitter and Copper are part of Agnus The Blitter manipulates memory data, while the Copper performs display-synchronized register operations. 
3. Denise is the graphics specialist It interprets bitplane and sprite information as part of the video-generation process. 
4. Classic Amiga graphics are commonly planar Multiple bitplanes provide the bits used to determine a pixel's color index. 
5. Denise supports hardware sprites The classic architecture provides eight sprite channels. 
6. Paula provides four PCM audio channels Samples are stored in Chip RAM and can be transferred using DMA. 
7. Paula is more than an audio chip It also participates in floppy disk data handling, interrupts, serial communication, and I/O. 
8. The Custom Chips work together The real capability of the Amiga comes not from a single chip, but from the cooperation between the CPU, memory, and specialized hardware. 

From Hardware to Software We now have a solid foundation for understanding the classic Amiga hardware. We know how the CPU, Chip RAM, Fast RAM, DMA, Agnus, Denise, Paula, Blitter, and Copper fit together. This gives us a good point to move from hardware toward software. Because when you switch on an Amiga, all of this hardware is initially just waiting to be used. Something has to initialize the machine, configure the hardware, detect available resources, find a boot device, load software, and eventually start the familiar Amiga environment. 

That brings us to the next part of the story: Coming Next: From Power-On to Workbench In Article 6: "How the Amiga Boots – From Kickstart to Workbench", we can follow the machine from the moment the power switch is turned on through Kickstart, Exec, hardware initialization, expansion-device configuration, boot-device selection, the boot block, AmigaDOS, Startup-Sequence, and finally Workbench. That chapter will form the bridge between the Amiga's hardware architecture and the later articles about AmigaOS internals, libraries, devices, handlers, DOS, and the Shell.