Article 20: How the Complete Amiga Works From Power-On to Applications, Graphics and Sound 

During this course, we have examined the Amiga piece by piece. 

We looked at:
the Motorola 68000 CPU
Chip RAM and Fast RAM
Agnus, Denise and Paula
the Copper and Blitter
DMA
interrupts
Exec
tasks and processes
signals and message ports
libraries and devices
AmigaDOS
filesystems and handlers
Intuition and Workbench
direct hardware programming

  
Individually, each of these subjects is interesting. But the real beauty of the Amiga becomes visible when we connect them. The Amiga is not simply a CPU controlling a collection of peripherals. It is a system in which the CPU, operating system, memory and specialized hardware cooperate. This final article brings those pieces together. 

1. The Amiga as a Complete System 

At the highest level, we can imagine the computer as several layers:
Users
  |
  v
Applications / Workbench / Shell
  |
  v
AmigaOS
  |
  +-- Intuition
  +-- Graphics
  +-- AmigaDOS
  +-- Libraries
  +-- Devices
  |
  v
Exec
  |
  +-- Tasks
  +-- Memory
  +-- Signals
  +-- Messages
  +-- Interrupts
  |
  v
Hardware
  |
  +-- CPU
  +-- Chip RAM
  +-- Fast RAM
  +-- Agnus
  +-- Denise
  +-- Paula
  +-- Copper
  +-- Blitter 

This model is simplified, but it provides an excellent framework for understanding the whole machine. 

2. It Begins with Power-On 

When the Amiga is switched on, the processor begins executing code from the system's ROM environment. This brings Kickstart into the picture. Kickstart contains essential parts of AmigaOS needed to bring the system to life. 

Conceptually:
Power on
   |
   v
CPU reset
   |
   v
Kickstart ROM
   |
   v
Core system initialization 

Before Workbench can appear, the machine needs a functioning operating-system foundation. 

3. Exec Comes to Life 

One of the most important components of this foundation is:
exec.library 

Despite the .library name, Exec is effectively the kernel at the heart of classic AmigaOS. 

Exec provides core mechanisms including: 
multitasking
task scheduling
memory management
signals
message ports
libraries
devices
interrupt management

Once Exec is operating, the Amiga has the foundations required for a multitasking operating system. 

4. Exec Discovers Memory 

The system must also determine what memory is available. 

An Amiga may contain several memory regions:
Chip RAM

Fast RAM

Expansion RAM

Exec can manage these as separate memory regions with different attributes. This matters because not all RAM has the same capabilities. 5. Chip RAM Connects CPU and Custom Chips Chip RAM is central to the architecture because both the CPU and the custom chipset can access it.

              Chip RAM
               /    </span>
              /      </span>
            CPU    

Custom Chips Graphics, audio and other DMA data frequently need to reside here. 

Typical examples include:
Bitplanes
Sprites
Audio samples
Copper lists
Blitter data

Chip RAM therefore acts as a shared workspace between software and custom hardware. 

6. Fast RAM 

Gives the CPU Its Own Workspace Fast RAM serves a different role. On a classic Amiga, the custom chipset does not normally use ordinary Fast RAM for its DMA operations. 

Therefore:
CPU ---> Fast RAM does not involve the same competition with chipset DMA traffic that occurs when the CPU accesses Chip RAM. 

A useful simplified model is:
                 CPU
                /   </span>
               /     </span>
         Fast RAM   Chip RAM
                       |
                 Custom Chips 

Program code and CPU-oriented data benefit greatly from Fast RAM. 

7. Why Memory Location Affects Performance 

Suppose the CPU works from Chip RAM while display DMA, audio DMA, Copper and Blitter activity are occurring. They all depend on access to the shared memory system. 

Conceptually:
CPU ------</span>
Display ---</span>
Copper -----> Chip RAM
Blitter ---/
Audio ----/ Available memory bandwidth must be shared. If CPU code and data can instead use Fast RAM:
CPU ----------> Fast RAM


Display ----</span>
Copper ------</span>
Blitter ------> Chip RAM
Audio -------/ the CPU can perform more work independently. 

This is why adding Fast RAM can make such a dramatic difference. 8. Expansion Hardware Joins the System The Amiga was designed to be expandable. 

Additional hardware might provide: 
Fast RAM
hard disks
network interfaces
faster processors
graphics hardware
additional I/O

The operating system can incorporate various additional resources through its modular architecture. This is one reason concepts such as devices, libraries and memory regions are so important. The system does not have to consist only of the hardware present in the original base machine. 

9. The Boot Device Is Found 

Once the low-level system environment is operating, the machine can locate a bootable device. 

This might be:
Floppy disk or:
Hard-disk partition 

The appropriate storage infrastructure allows AmigaDOS to access files. We now move from hardware-oriented startup toward the user environment. 

10. AmigaDOS Builds the File Environment 

AmigaDOS provides high-level concepts such as: 
files
directories
processes
volumes
assigns
command execution

The filesystem hides the physical details of storage from applications. 

Instead of thinking about sectors and disk tracks, software can request something like:
Open "Work:Documents/Letter" The layers underneath resolve the operation.
Application
     |
     v
AmigaDOS
     |
     v
Handler / Filesystem
     |
     v
Device
     |
     v
Storage hardware 

11. Assigns 

Create the Logical System Layout During startup, the Amiga environment establishes important logical names such as:
C:
S:
L:
LIBS:
DEVS:
FONTS:
T:
ENV: These allow software to refer to logical functions rather than fixed disk locations. For example:
LIBS: means, conceptually: the location where the system expects libraries. It does not have to mean:
DH0:Libs This makes the operating-system structure much more flexible. 12. Startup-Sequence Configures the System One of the central files in a traditional Amiga boot is:
S:Startup-Sequence It contains AmigaDOS commands that help construct the working environment. Conceptually:
Kickstart
    |
    v
Boot device
    |
    v
AmigaDOS
    |
    v
S:Startup-Sequence
    |
    +--> assignments
    +--> system commands
    +--> configuration
    +--> additional components
    |
    v
User environment 

A significant part of the visible AmigaOS system is therefore assembled during startup rather than being one enormous fixed program. 

13. Libraries Provide System Services 

Applications do not normally need to perform every operation themselves. They can use operating-system libraries. 

Examples include:
graphics.library
intuition.library
dos.library
utility.library 

An application traditionally opens the library it requires:
OpenLibrary() uses its functions, and later calls:
CloseLibrary() 

This creates a modular environment where system functionality is shared. 

14. Devices Provide I/O Services 

For lower-level input and output, AmigaOS provides devices. 

Examples include:
trackdisk.device
serial.device
parallel.device
timer.device
console.device 

Applications interact with devices using I/O requests. 

A device operation may be synchronous:
DoIO() or asynchronous:
SendIO() Asynchronous operation fits particularly well with Amiga multitasking. 

15. Tasks 

Make Multitasking Possible Exec organizes running software into tasks.

Suppose several programs are active:
Workbench
Editor
Terminal
Clock
Shell 

Exec determines which ready task receives CPU time. 

Conceptually:
              Exec Scheduler
                    |
     +--------------+--------------+
     |              |              |
   Task A         Task B         Task C
     |              |              |
 Workbench        Editor          Shell 

To the user, several programs appear to operate simultaneously. 

16. Waiting Is Just as Important as Running 

Multitasking would be inefficient if every program consumed CPU time while waiting. Imagine a text editor with nothing happening. 

It does not need to perform millions of loops asking:
Keyboard input?
Keyboard input?
Keyboard input? 

Instead it can wait.
Task
 |
 v
Wait()
 |
 | sleeping
 |
Event occurs
 |
 v
Signal
 |
 v
Task becomes ready 

The CPU can meanwhile perform useful work elsewhere. This is one of the fundamental reasons the Amiga's multitasking system is efficient. 

17. Messages Connect the System 

AmigaOS makes extensive use of message passing. 

Messages appear in areas such as: 
Intuition
device I/O
DOS handlers
inter-process communication

The basic idea is:
Task A
   |
   v
Message
   |
   v
Message Port
   |
   v
Task B 

Signals can notify Task B that something has arrived. 

This creates an elegant relationship between:
Tasks
Signals
Messages
Ports 

18. Intuition 

Creates the GUI Environment At the user-interface level we encounter:
intuition.library Intuition manages important GUI concepts including: 
screens
windows
gadgets
menus
user interface events

An application might ask Intuition to open a window. 

Conceptually:
Application
     |
     v
Intuition
     |
     v
Window 

The application then receives user-interface events through the system's message-based mechanisms. 

19. Workbench Is Not the Entire GUI System 

This distinction is important:
Workbench != Intuition Workbench is the familiar graphical desktop environment. Intuition provides underlying GUI mechanisms used by Workbench and other applications. 

Conceptually:
                Intuition
                /       </span>
               /         </span>
        Workbench       

Application A program can use Intuition without being part of the Workbench desktop itself. 

20. The User Opens a Program 

Imagine that the user double-clicks an application icon.

At a simplified level:
User
 |
 v
Workbench
 |
 v
Application startup
 |
 v
DOS Process / Exec Task
 |
 v
Program runs 

The new application now becomes another participant in the multitasking system. 

21. The Program Allocates Memory 

Our application now needs memory. For normal calculations it might request ordinary or Fast RAM. For chipset-accessible graphics it may require Chip RAM. 

Conceptually:
Application
     |
     v
Exec memory request
     |
     +--> Fast RAM
     |
     +--> Chip RAM 

Exec manages which blocks are free and which are currently allocated. 

22. The Program Opens a Window 

The application requests a window through Intuition. Afterward, it may spend much of its time inside an event loop.

Open window
     |
     v
Wait for event
     |
     v
Process event
     |
     v
Wait again 

When nothing happens, the application can sleep. When the user interacts, Intuition delivers the appropriate event information. 

23. Mouse Input Travels 

Through Several Layers Consider something as simple as clicking a gadget. 

Conceptually:
Mouse
  |
  v
Input hardware/system
  |
  v
Intuition
  |
  v
IntuiMessage
  |
  v
Message Port
  |
  v
Signal
  |
  v
Application wakes
  |
  v
Processes click 

What appears to the user as a simple mouse action actually involves several levels of the system. 

24. The Program Loads an Image 

Suppose the application now loads a picture from disk. 

At a high level:
Application
     |
     v
dos.library
     |
     v
Filesystem
     |
     v
Storage device 

The resulting data is placed in memory. Perhaps the image must then be converted into a format suitable for display. CPU-oriented processing may take place in Fast RAM. The final hardware-accessible bitmap may reside in Chip RAM. 

25. Graphics Enter the Custom-Chip World 

Now the operating-system and hardware worlds meet. Suppose the bitmap contains several bitplanes.

Chip RAM
 |
 +-- Bitplane 1
 +-- Bitplane 2
 +-- Bitplane 3 

Display hardware needs repeated access to these planes. The CPU does not have to copy every pixel to the display output. Instead, DMA fetches the bitplane data. 26. Agnus Coordinates DMA Agnus plays a central role in the shared Chip RAM architecture. 

The custom chipset needs memory access for: 
bitplanes
sprites
Copper
Blitter
audio
disk-related operations

Agnus coordinates important DMA activity and Chip RAM access. 

Conceptually:
                  Chip RAM
                      |
                    Agnus
             +--------+--------+
             |        |        |
          Display   Copper   Blitter 

The exact hardware relationships are more detailed, but this gives us the essential idea. 

27. Denise Helps 

Create the Picture The graphics data fetched from memory ultimately contributes to video generation. On OCS/ECS Amigas, Denise has a central role in turning graphics information into the visible display. 

Conceptually:
Chip RAM
   |
Bitplane DMA
   |
   v
Graphics hardware
   |
   v
Denise
   |
   v
Video output
   |
   v
Monitor 

The CPU therefore does not generate the complete video signal in software. Dedicated hardware performs that job.

28. The Copper 

Changes the Display While It Is Being Generated A Copper list resides in Chip RAM.

Chip RAM
   |
   v
Copper 

The Copper can wait for selected raster positions and change hardware registers. 

For example:
WAIT line 80
MOVE color
WAIT line 150
MOVE another color 

The display can therefore change while a frame is being generated without requiring continuous CPU intervention. 

29. The Blitter 

Moves Graphics Suppose the application needs to move or combine graphical blocks. The CPU could process every word manually. But the Blitter can perform many such operations.

CPU
 |
 | configure
 v
Blitter
 |
 | DMA
 v
Chip RAM 

The CPU specifies: 
source addresses
destination address
size
masks
shifts
logical function

The Blitter then performs the operation. 

30. CPU and Blitter Work Together 

While the Blitter performs a graphical operation, the CPU may work on something else. 

For example:
CPU                    Blitter
 |                        |
Game logic             Draw object
 |                        |
AI calculations        Clear area
 |                        |
Input handling         

Finish If the CPU is working largely in Fast RAM, this parallelism becomes particularly effective. 

31. Paula Handles Audio 

Now suppose the program also needs sound. Audio data can be placed in Chip RAM. 

The CPU configures Paula with information including: 
memory address
sample length
period
volume

Then:
Chip RAM
   |
  DMA
   |
   v
Paula
   |
   v
Audio output 

The CPU does not have to feed every sample manually in real time. Paula handles the repetitive playback process. 

32. Four Audio Channels 

The classic Amiga provides four DMA-driven audio channels. 

Conceptually:
             Paula
        +------+------+------+------+
        |      |      |      |
       Ch0    Ch1    Ch2    Ch3
        |      |      |      |
        +------+------+------+
               |
               v
           Audio output 

This was one of the Amiga's most striking multimedia capabilities when the platform appeared. 

33. Interrupts 

Bring Hardware Events Back to the CPU DMA allows the CPU to delegate work. But eventually hardware may need CPU attention. That is where interrupts enter the picture. 

For example:
Hardware operation
        |
        v
Event occurs
        |
        v
Interrupt request
        |
        v
68000 / system
        |
        v
Interrupt handling 

Hardware and software therefore communicate in both directions. 

34. The Complete Communication Cycle 

This gives us a very important pattern:
        CPU
         |
         | configure
         v
      Hardware
         |
         | DMA
         v
      Memory


      Hardware
         |
         | interrupt
         v
        CPU 

The processor controls the operation. The hardware performs repetitive work. The hardware then reports important events. This pattern appears throughout the Amiga. 

35. A Complete Frame of a Game 

We can now imagine what happens during one frame of an Amiga game. 

Step 1: Input The CPU reads or responds to player input. 
Step 2: Game logic 
The CPU calculates:
positions
collisions
game state
AI Ideally much of this processing can happen using Fast RAM. 
Step 3: Graphics The CPU configures the Blitter.
Blitter -> update back buffer 
Step 4: Copper The next Copper list contains display-related changes. 
Step 5: Audio Paula continues playing samples through DMA. 
Step 6: Synchronization The program coordinates with display timing. 
Step 7: Buffer switch The completed buffer becomes visible. Then the cycle begins again. 

36. Many Things Happen at Once 

At one moment we might have:
CPU
 -> calculating game logic

Blitter
 -> drawing graphics

Copper
 -> waiting for raster position

Display DMA
 -> reading bitplanes

Sprite DMA
 -> reading sprite data

Paula
 -> reading audio samples

Exec
 -> managing system activity 

Of course, these components share various hardware constraints and not everything is literally independent. But architecturally, substantial work has been distributed across the machine. This is the central idea behind the Amiga's performance. 

37. The Amiga Is More Than Its CPU 

Looking only at the CPU specification:
Motorola 68000
approximately 7 MHz on early systems does not explain the machine's capabilities. The processor is only one component. 

The real machine is closer to:
               CPU
              /   </span>
             /     </span>
        Fast RAM   Chip RAM
                      |
                   Agnus
             +--------+--------+
             |        |        |
          Copper   Blitter    DMA
             |        |        |
             +--------+--------+
                      |
              Custom chipset
                 /        </span>
                /          </span>
             Video        Audio 

The architecture matters as much as the processor. 

38. Operating System and Hardware 

Were Designed to Cooperate This becomes particularly interesting when we return to AmigaOS. 

Exec understands: 
different memory types
multitasking
interrupts
messages
devices

Graphics and Intuition provide abstractions over the graphical environment. AmigaDOS provides abstractions over files and storage. The operating system therefore reflects important aspects of the hardware architecture rather than completely hiding them. 

39. High-Level and Low-Level Worlds Meet 

An Amiga programmer can work at a high level:
OpenWindow()
Read()
Write()
Wait() or much closer to the machine:
Copper
Blitter
DMA
Interrupts
Custom registers 

This creates an unusually broad programming environment. The programmer can choose the appropriate level. 

40. Applications Prefer Abstraction 

A normal productivity application benefits from using:
Exec
DOS
Intuition
Graphics
Devices because these provide: compatibility
multitasking cooperation
resource management
hardware abstraction
The application does not need to know every hardware detail. 

41. Games and Demos Often Prefer Control 

Games and demos may instead require: 
precise display timing
deterministic graphics behavior
maximum DMA control
direct Copper programming
direct Blitter programming

Therefore they historically often interacted much more directly with the hardware. This explains why some older games work perfectly on one Amiga configuration but encounter problems on another. The more hardware assumptions software makes, the harder compatibility becomes. 

42. The Fundamental Trade-Off 

This gives Amiga programming two broad philosophies. Operating-system approach

Program
   |
AmigaOS
   |
Hardware Advantages: 
compatibility
multitasking
easier development
resource coordination
Direct-hardware approach
Program
   |
Hardware Advantages: precise control
predictable timing
ability to exploit chipset features directly

The correct choice depends on the application. 

43. Why Exec Is So Important 

After studying the entire machine, it becomes clear why Exec is central. 

Exec forms the bridge between many software concepts:
               Exec
        +-------+-------+
        |       |       |
      Tasks   Memory  Messages
        |       |       |
      Signals Devices Interrupts 

Higher-level systems are built on these mechanisms. Without Exec, the Amiga would still have impressive hardware. But it would not have the same elegant multitasking operating-system architecture. 

44. Why Chip RAM Is So Important 

Similarly, Chip RAM is not simply "slow RAM." It is the shared communication space used by the CPU and essential custom hardware.

                 Chip RAM
      +-------------+-------------+
      |             |             |
     CPU          Copper       Blitter
      |             |             |
      +-------------+-------------+
                    |
                 DMA users 

Its special value comes from who can access it. That is why running out of Chip RAM can be a problem even when Fast RAM is still available. 

45. Why Fast RAM Is So Important 

Fast RAM complements Chip RAM. It gives the CPU somewhere to work without sharing every memory cycle with the chipset.

CPU
 |
 +--> Fast RAM
 |
 +--> Chip RAM <--- DMA hardware 

This division creates one of the most important performance optimizations available to classic Amiga systems. Accelerator cards take this principle much further by pairing faster CPUs with fast local memory. 

46. Why the Copper 

Is So Special The Copper represents a remarkable design philosophy. Instead of making the CPU perform precisely timed register changes, the Amiga provides a tiny specialized coprocessor.

CPU prepares instructions
         |
         v
       Copper
         |
         v
Wait for raster
         |
         v
Change register 

It performs a small set of functions extremely efficiently. That is a recurring Amiga principle: Use specialized hardware for specialized jobs. 

47. Why the Blitter 

Is So Special The same applies to the Blitter. The 68000 is a general-purpose CPU. The Blitter is specialized for operations involving blocks of memory. 

Instead of:
CPU does thousands of graphical memory operations the system can often use:
CPU configures Blitter
          |
          v
Blitter performs repetitive operation 

The CPU is then free for other work. 

48. Paula Demonstrates the Same Philosophy 

Paula demonstrates this architecture for audio. 

Rather than having the CPU continuously output individual samples:
CPU
 |
 | setup
 v
Paula
 |
 | DMA
 v
Sample data 

Specialized hardware keeps the sound playing. The CPU can concentrate on the application. 

49. AmigaOS Uses the Same Philosophy in Software Interestingly, the operating system mirrors this modularity. Hardware is divided into specialized components. Software is also divided into specialized components.

Hardware:

Agnus
Denise
Paula
Copper
Blitter


Software:

Exec
DOS
Intuition
Graphics
Libraries
Devices
Handlers 

Both levels favor cooperating components rather than one monolithic controller doing everything. 50. The Entire Amiga in One Model 

We can now create a final conceptual overview:

                         USER
                          |
             +------------+------------+
             |                         |
         Workbench                   Shell
             |                         |
             +------------+------------+
                          |
                     Applications
                          |
          +---------------+---------------+
          |               |               |
      Intuition        AmigaDOS        Graphics
          |               |               |
          +---------------+---------------+
                          |
                         Exec
           +--------------+--------------+
           |              |              |
        Memory          Tasks         Messages
           |              |              |
        Devices        Signals       Interrupts
           |
           v
                    HARDWARE
                       |
         +-------------+-------------+
         |                           |
      68000 CPU                 Custom Chips
         |                       /   |   </span>
         |                  Agnus Denise Paula
         |                    |
      Fast RAM              DMA system
                              |
                         +----+----+
                         |         |
                      Copper    Blitter
                         |
                         v
                      Chip RAM 

No single diagram can capture every architectural detail. But this model demonstrates the central principle: The Amiga is a network of cooperating hardware and software components. 

51. From Power Switch to Running Application 

We can now summarize an entire journey through the machine.

POWER ON
   |
   v
Kickstart
   |
   v
Exec
   |
   +--> memory discovered
   |
   +--> multitasking initialized
   |
   v
AmigaDOS
   |
   v
Startup-Sequence
   |
   v
System assigns and components
   |
   v
Workbench
   |
   v
User starts application
   |
   v
DOS process / Exec task
   |
   +--> opens libraries
   |
   +--> allocates memory
   |
   +--> accesses files
   |
   +--> creates GUI
   |
   v
Application performs work
   |
   +--> CPU
   |
   +--> Fast RAM
   |
   +--> Chip RAM
   |
   +--> Blitter
   |
   +--> Copper
   |
   +--> DMA
   |
   +--> Paula
   |
   v
Graphics + Sound + Interaction 

That is the Amiga as a complete system. 

52. What Makes the Amiga Different? 

The Amiga is not unique because of any one individual feature. 

Other systems had: 
graphical interfaces
sound hardware
DMA
multitasking
coprocessors

What made the Amiga remarkable was the way its components were combined. The architecture was built around cooperation and specialization. The CPU did not need to do everything. The operating system did not need to be monolithic. Applications could communicate through messages. Hardware could transfer data through DMA. Specialized processors could operate concurrently with the CPU. Memory itself could have different roles. The entire machine reflected a consistent philosophy. 

53. Understanding the Amiga 

Changes How You See It At the beginning, an Amiga may appear to be:
Keyboard
Mouse
Workbench
Floppy drive
Games 

After exploring its architecture, we see something very different:
68000
   |
Exec
   |
Tasks / Signals / Messages
   |
Libraries / Devices / DOS
   |
Processes / Handlers
   |
Chip RAM / Fast RAM
   |
DMA / Interrupts
   |
Agnus / Denise / Paula
   |
Copper / Blitter
   |
Graphics / Audio 

The familiar user experience is only the visible surface of a much more interesting architecture. Conclusion The classic Amiga is best understood not as a collection of isolated features, but as a cooperative system. The 68000 performs general-purpose processing. Exec provides multitasking, memory management, signals, messages and core operating-system infrastructure. AmigaDOS provides files, processes, volumes, assigns and filesystem services. Intuition provides the graphical user-interface framework. Chip RAM creates a shared memory area between the CPU and the custom chipset. Fast RAM gives the CPU a more independent workspace. Agnus coordinates important memory and DMA activity. Denise plays a central role in generating the display on classic OCS/ECS machines. Paula provides audio and important I/O functions. The Copper performs display-synchronized hardware control. The Blitter performs specialized graphical and memory operations. DMA allows hardware to transfer data without forcing the CPU to perform every individual operation. Interrupts allow the hardware to request CPU attention when necessary. Together they create a system in which work is distributed intelligently between software and specialized hardware. And that is perhaps the most important lesson from this entire series: The Amiga was not designed around a powerful CPU doing everything. It was designed around many specialized components working together efficiently. That design philosophy is the key to understanding why the Amiga could achieve such impressive graphics, sound, multitasking and responsiveness with hardware that, viewed only by CPU specifications, appears remarkably modest. End of the Amiga Course With Article 20, our planned Amiga course is complete. The 20 articles have taken us from the visible Amiga experience down through Workbench and AmigaOS, deeper into Exec, memory and multitasking, and finally into DMA, interrupts and the custom chipset itself. The natural next series is now your planned AROS course. That will be especially interesting because we can directly connect the new articles to what we have learned here and repeatedly compare AROS with classic AmigaOS, rather than explaining everything again from scratch.