Article 2: Chip RAM and Fast RAM – Understanding Amiga Memory 

One of the most important concepts for understanding the Amiga is its memory architecture. At first glance, memory seems simple: a program stores information in RAM and the processor reads or modifies it when necessary. On the Amiga, however, things are more interesting. The reason is that the CPU is not the only component that needs access to memory. The Custom Chips also need memory bandwidth for graphics, sound, disk operations, the Blitter, and the Copper. 

This is why classic Amiga systems distinguish primarily between two important types of RAM:
Chip RAM
Fast RAM

Both are ordinary memory from the CPU's point of view, but they behave very differently within the Amiga architecture. Understanding this difference also explains an interesting phenomenon: Adding Fast RAM to an Amiga can make the computer noticeably faster even when a program does not actually need the additional memory capacity. To understand why, we first have to look at Chip RAM. 

What Is Chip RAM? 

Chip RAM is the memory that can be accessed by both the CPU and the Amiga Custom Chips. This makes it the most important shared memory area in a classic Amiga. Data required directly by the Custom Chips normally has to reside in Chip RAM. 

Examples include: 
screen bitplanes
sprite data
audio samples
Copper lists
data used by the Blitter
certain disk buffers

The CPU can also store normal program code and data in Chip RAM. This means that Chip RAM serves two very different worlds: The CPU needs it for program execution and data. At the same time: The Custom Chips need it for graphics, audio, DMA transfers, and other hardware operations. And this creates competition for memory access. The Chip RAM Bus Memory is connected to the rest of the computer through a bus. A bus can be thought of as a collection of electrical connections used to transfer information. 

For our purposes, three types of information are particularly important: addresses
data
control signals

When the CPU wants to read something from memory, it must essentially specify: "I want the data stored at this address." The memory system then provides the requested data. Writing works in the opposite direction: "Store this data at this address." The important point is that access takes time. Memory therefore cannot serve an unlimited number of components simultaneously. This becomes particularly important with Chip RAM because many Amiga components share access to it. Memory Cycles To coordinate Chip RAM access, the available memory bandwidth is divided into individual access opportunities, commonly described as memory cycles or bus slots. Different hardware components can use these slots. 

Depending on the situation, they may be required by: 
display DMA
disk DMA
audio DMA
sprite DMA
Copper
Blitter
CPU

A simplified representation might look like this: 
Display → CPU → Audio → CPU → Display → Blitter → Display → CPU 

This is not a literal representation of a particular Amiga display mode. The actual allocation depends on configuratin and hardware activity. But it demonstrates the basic idea: The CPU is only one of several components competing for access to Chip RAM. Agnus Controls Chip RAM Access This brings us back to Agnus. Agnus plays a central role in controlling access to Chip RAM and coordinating DMA activities. If the display hardware needs data, it does not ask the CPU to copy every word into a video controller. Instead, DMA hardware can fetch the necessary data directly from Chip RAM. The same basic principle applies to several other Amiga subsystems. This has an important advantage. The CPU does not have to spend its time continuously moving data for these devices. But there is a price: DMA consumes Chip RAM bandwidth. While certain Chip RAM cycles are being used for DMA, those cycles are not simultaneously available to the CPU. What Is DMA? DMA stands for: Direct Memory Access Without DMA, imagine that the CPU had to perform every transfer itself. 

For audio playback, for example, the CPU could theoretically have to repeatedly: 
read an audio sample from memory,
transfer it to the audio hardware,
read the next sample,
transfer that sample,
repeat the process thousands of times.

That would consume valuable CPU time. DMA changes this concept. The CPU configures the hardware and tells it where the relevant data can be found. The DMA hardware can then retrieve that data from Chip RAM. 

In simplified form: 
CPU: "Here is the data. Start processing it." 
DMA hardware: "I'll handle the transfers." 
CPU: "Good. I'll continue executing the program." 

This is one of the fundamental reasons why the Amiga architecture is so interesting. Different hardware components can perform useful work without requiring the CPU to manage every individual transfer. 

But What Happens When the CPU Needs Chip RAM? 

Imagine that the CPU now needs to read a value from Chip RAM. Normally it would initiate a memory access. But suppose the required portion of the memory bus is currently being used by DMA. The CPU cannot simply interrupt an already allocated hardware transfer. It may have to wait until a suitable memory cycle becomes available. This introduces what is generally referred to as wait states or CPU waiting for bus access. 

Conceptually: CPU wants Chip RAM → bus unavailable → CPU waits → bus becomes available → CPU accesses RAM During this waiting period, the CPU cannot complete that particular memory access. This is why CPU performance can be affected by heavy Chip RAM activity. Display DMA Is Particularly Important The Amiga's graphics hardware continuously needs data while generating the display. For a conventional bitplane screen, the hardware reads bitplane data from Chip RAM using DMA. More bitplanes mean that more graphics data has to be retrieved. Other display features and DMA channels can consume additional memory bandwidth as well. Therefore, the amount of Chip RAM bandwidth available to the CPU is not always constant. A simple low-bandwidth screen configuration leaves more opportunities for other bus users than a configuration that causes the graphics hardware to fetch considerably more data. 

This is an important characteristic of the classic Amiga architecture: CPU access to Chip RAM is affected by what the Custom Chips are doing. And now we can understand why Fast RAM is so useful. 

What Is Fast RAM? 

Fast RAM is memory that is available to the CPU but not directly accessible by the classic Amiga Custom Chips through their normal DMA mechanisms. At first this may sound like a disadvantage. After all, wouldn't memory be better if every component could use it? Not necessarily. Because the Custom Chips cannot use Fast RAM in the same way they use Chip RAM, they also do not compete with the CPU for access to that memory. This is the key difference. Chip RAM Shared by: CPU + Custom Chips Fast RAM Used by: CPU This makes Fast RAM particularly useful for CPU-oriented program code and data. 

Why Is It Called "Fast" RAM? 

The name can initially be misleading. "Fast RAM" does not simply mean that the physical memory chips themselves must always be dramatically faster than the chips used for Chip RAM. The major advantage is architectural. When the CPU accesses Chip RAM, it participates in a shared memory system. Other hardware may also need access to that bus. When the CPU accesses appropriate Fast RAM, the Custom Chips are not competing for the same Chip RAM cycles. So rather than thinking: Fast RAM = faster memory chips it is often more useful to think: Fast RAM = memory that the CPU can access without Custom Chip DMA stealing Chip RAM slots. This distinction is extremely important. Program Code in Fast RAM Suppose a game or application consists of two broad types of data. 

CPU-related data 

For example: 
program instructions
calculations
object coordinates
text
tables
internal program structures

Custom Chip data 

For example: 
bitplanes
sprites
audio samples
Copper lists

The Custom Chips do not need direct access to the first group. Therefore, if Fast RAM is available, much of this data may be placed there. The second group has to remain accessible to the Custom Chips and therefore normally needs to stay in Chip RAM. This allows the program to take advantage of both memory systems. A Simple Example Imagine a game in which the CPU is calculating the position of 50 objects. 

For every object it might need to read: 
X position
Y position
speed
direction
animation state

It performs calculations and writes the updated information back to memory. If all of this information resides in Chip RAM, the CPU performs those accesses through the shared Chip RAM system. At the same time, the display hardware may be fetching bitplane data and Paula may be fetching audio samples. The CPU can therefore experience delays. Now move the game's calculation data into Fast RAM. The CPU can access that information independently of Chip RAM DMA activity. The graphics and audio data remain in Chip RAM because the Custom Chips still need them. Conceptually, we now have two traffic routes instead of forcing everything through the same shared route. 

Chip RAM Is Not "Slow RAM" 

It would therefore be incorrect to think of Chip RAM simply as bad or slow memory. Chip RAM has a special purpose. Its great advantage is precisely the feature that creates the contention: The Custom Chips can access it. Graphics hardware needs Chip RAM. Audio DMA needs Chip RAM. The Copper uses instructions stored in Chip RAM. The Blitter operates on data in Chip RAM. So Chip RAM is not something we would want to replace entirely with Fast RAM. Instead, a well-equipped Amiga benefits from having both. Their purposes are different. The Blitter and Memory Competition The Blitter gives us another interesting example. As we saw in the previous article, the Blitter can manipulate blocks of data without requiring the CPU to process every individual word. This saves CPU work. However, the Blitter itself needs memory bandwidth. Imagine the Blitter copying or combining large graphics areas in Chip RAM. It has to read source data and write the resulting data. These operations consume Chip RAM cycles. This creates an interesting trade-off. The Blitter reduces the amount of processing the CPU has to perform, but its operations can also compete with the CPU for Chip RAM bandwidth. This is a good example of why Amiga performance cannot always be understood simply by looking at CPU clock speed. The entire system is working together. CPU and DMA Working in Parallel There is another important consequence of having Fast RAM. Suppose the Blitter is performing an operation in Chip RAM. Meanwhile, the CPU has program code and working data in Fast RAM. The CPU can potentially continue doing useful work without needing the same Chip RAM bus for every instruction and data access. 

Conceptually: Blitter → working with Chip RAM while: CPU → working with Fast RAM 

This is much more efficient than forcing both components to constantly compete for the same shared memory. Good Amiga software can take advantage of this architecture. Why Fast RAM Can Accelerate an Amiga We can now answer an important question: Why can adding Fast RAM make an Amiga faster even when the program does not need more memory? Because additional memory capacity is not the only benefit. Fast RAM can allow CPU-oriented code and data to be stored outside the shared Chip RAM system. This reduces contention between the CPU and Custom Chip DMA. Instead of having: CPU + graphics + audio + Blitter + Copper → Chip RAM we can increasingly have: Custom Chips → Chip RAM and: CPU → Fast RAM The workload is distributed across different memory paths. 

Why Can't the Custom Chips Simply Use Fast RAM? 

This limitation comes from the hardware architecture. The classic Custom Chips are designed to access the memory connected to their own memory system controlled through Agnus. They do not simply have general access to every memory area visible to the CPU. The CPU may therefore be able to address memory that the Custom Chips cannot directly reach. 

This creates an important rule for Amiga programming: Data accessed directly by the Custom Chips must be placed in memory accessible to the Custom Chips. For example, placing an audio sample in ordinary CPU-only Fast RAM would not automatically make it usable by Paula's audio DMA. Similarly, screen bitplanes must reside in memory accessible to the graphics hardware. This becomes especially important when programming the Amiga directly. CPU Address Space vs. Hardware Accessibility This also illustrates the difference between two concepts that can easily be confused: The CPU can address a memory location does not necessarily mean: Every hardware component can access that memory location. From a program's perspective, both Chip RAM and Fast RAM may appear somewhere inside the CPU's address space. But from the Custom Chips' perspective, the situation is different. Their DMA hardware operates within the memory architecture that was designed for them. This distinction between CPU address space and DMA accessibility is fundamental to understanding the Amiga. 

A Useful Mental Model A simple way to visualize Amiga memory is to imagine two work areas. 

Shared Workshop: 
Chip RAM 

Everyone needs access: 
CPU
display hardware
audio hardware
Blitter
Copper
other DMA hardware

Because everyone shares the workshop, sometimes one worker has to wait. Private CPU Workshop: Fast RAM Only the CPU works here. The Custom Chips cannot enter. But that means the CPU does not have to compete with them while working there. The best arrangement is therefore not necessarily to use only one workshop. Instead: Keep hardware-related material in Chip RAM and CPU-related material in Fast RAM whenever appropriate. 

Putting It All Together We can now extend the basic architecture from Article 1. When an Amiga program is running: The CPU Executes program instructions and performs general calculations. Fast RAM Can contain CPU-oriented code and data without competing with Custom Chip DMA for Chip RAM cycles. Chip RAM Contains memory that can be shared between the CPU and the Custom Chips. Agnus Coordinates important aspects of Chip RAM access and DMA. Denise and the display hardware Use graphics data from Chip RAM to generate the display. Paula Can retrieve audio and other data from Chip RAM using DMA. Blitter Processes blocks of data in Chip RAM. Copper Executes its specialized instruction lists from Chip RAM in synchronization with the display. This is not simply a CPU connected to some memory and peripherals. It is a system in which several pieces of hardware continuously cooperate. 

The Most Important Things to Remember 

If you remember only six things from this article, make them these: 
1. Chip RAM is shared memory Both the CPU and the Custom Chips can access it. 
2. The Custom Chips need Chip RAM Graphics, audio, Copper, Blitter, and other DMA-based operations depend on memory that their hardware can access. 
3. Chip RAM has limited bandwidth Several parts of the machine may need access to it. 
4. DMA consumes memory cycles DMA reduces CPU involvement in data transfers, but it still needs access to Chip RAM. 
5. The CPU can sometimes be delayed When required Chip RAM cycles are being used by other hardware, CPU memory accesses may have to wait. 
6. Fast RAM avoids this particular competition 

Fast RAM gives the CPU memory access that is independent of Custom Chip access to Chip RAM. And this leads us to an important conclusion: The difference between Chip RAM and Fast RAM is not simply about memory capacity or raw RAM speed. It is about which components can access the memory and how they share the available bus bandwidth. Understanding this principle gives us the foundation for looking much deeper into the Amiga hardware. 

Coming Next: The Amiga Bus and DMA In Article 3: "The Amiga Bus and DMA – How the Custom Chips Access Memory", the next logical step is to examine what is actually happening on the hardware level. We can look more closely at Chip RAM bus cycles, DMA slots, display DMA, audio DMA, Blitter bus access, CPU access and the role of Agnus. That chapter will connect the memory architecture described here with the actual timing of the Amiga hardware.