Article 6: How the Amiga Boots – From Kickstart to Workbench 

In the previous articles, we explored the hardware architecture of the classic Amiga: the Motorola 68000 CPU, Chip RAM and Fast RAM, DMA, the Custom Chips, Blitter, and Copper. But what happens when you actually switch the computer on? How does a machine that initially has no application running eventually present the familiar Workbench screen? The Amiga's boot process provides the bridge between hardware and operating system. 

During startup, several layers come into play:
The CPU begins executing Kickstart
Core operating system components are initialized
Hardware and memory are detected
Expansion hardware can be configured
A bootable device is selected
The operating system environment is loaded
The Startup-Sequence is executed
Workbench or another environment is started

Let's follow this process from the beginning. 

Stage 1: Power On 

When you switch on an Amiga, the Motorola processor cannot immediately start Workbench. It needs executable instructions. The CPU has a defined reset behavior that causes execution to begin using information found at the beginning of its address space. The Amiga hardware therefore has to make startup code available to the processor. This startup environment is provided by Kickstart. What Is Kickstart? Kickstart is a fundamental part of the Amiga operating system. It contains low-level operating system components required to bring the machine to life and provide the basic environment in which other Amiga software can run. 

Depending on the Amiga generation, Kickstart includes important components such as: Exec
core libraries
device drivers
resource management
hardware initialization code
boot-related code

A useful way to think about Kickstart is: Kickstart provides the core operating system environment required before the computer can load its normal disk-based system files. However, there is an important distinction between early and later Amigas. Kickstart Disk vs. Kickstart ROM Most familiar Amiga models contain Kickstart in ROM. For example, machines such as the Amiga 500 can begin executing their Kickstart environment directly from ROM after reset. The original Amiga 1000 is different. It does not simply contain the complete Kickstart environment in ROM in the same way. Instead, the user normally loads Kickstart from disk into a special protected memory area called the Writable Control Store, or WCS. Once Kickstart has been loaded, the machine can continue with the normal boot process. This is why an Amiga 1000 user traditionally encounters a Kickstart disk stage that an Amiga 500 user normally does not. For most of this article, we will concentrate on the ROM-based process familiar from machines such as the Amiga 500. 

Stage 2: Kickstart Takes Control 

Once the CPU begins executing the Kickstart code, the Amiga starts establishing its basic operating environment. At this stage, we are still far below the familiar Workbench desktop. 

The machine needs fundamental services for: 
memory management
task scheduling
interrupts
libraries
devices
hardware resources

At the center of this environment lies one particularly important component: Exec. Exec: The Kernel at the Heart of AmigaOS Exec is the core executive of the classic Amiga operating system. It provides fundamental mechanisms used by the rest of the system. 

Among its most important concepts are: 
tasks
memory allocation
interrupts
message ports
signals
libraries
devices

Exec is therefore present long before Workbench appears. This highlights an important distinction: Workbench is not the Amiga operating system itself. Workbench is the graphical desktop environment running on top of operating system services that already exist underneath it. This distinction becomes extremely important when trying to understand AmigaOS internally. Libraries One characteristic feature of AmigaOS is its heavy use of shared libraries. A library provides functions that programs can use without including all of that functionality themselves. Examples include components such as: exec.library Core operating system services. graphics.library Graphics-related functions. intuition.library User-interface functionality including screens, windows, and gadgets. dos.library File-system and DOS-related functions. Applications can open libraries and use the services they provide. This modular architecture is one of the defining characteristics of AmigaOS. Devices AmigaOS also uses devices. A device is a software component that provides controlled access to particular hardware or system functionality. 

Examples traditionally include names such as: 
trackdisk.device
serial.device
printer.device

For example, instead of an application controlling the floppy hardware entirely by itself, it can communicate through the appropriate operating-system device interface. This introduces an important architectural chain: 

Application 
↓ 
Operating system interface 
↓ 
Device 
↓ 
Hardware 

Not every program must understand every low-level hardware detail itself. 

Stage 3: Hardware and Memory Initialization 

During early startup, the operating system establishes information about the machine it is running on. Memory has to become available to the operating system. Hardware resources have to be initialized. Expansion hardware may also need configuration. This is particularly important because the Amiga was designed to support system expansion. 

A machine may contain additional: 
RAM
storage controllers
processor cards
I/O hardware
other expansion boards

The operating system therefore cannot always assume that every Amiga has exactly the same hardware configuration. 

AutoConfig 

One of the most interesting aspects of the Amiga expansion architecture is AutoConfig. Compatible expansion hardware can identify itself to the system and participate in an automatic configuration process. This greatly reduces the need for the kind of manual hardware configuration associated with many other computers of the same era. The operating system can discover compatible expansion boards and allocate appropriate resources to them. 

Conceptually: 
Expansion board discovered 
↓ 
board identifies its requirements 
↓ 
system allocates resources 
↓ 
board becomes available 

This is an early example of the philosophy later commonly associated with Plug and Play systems. 

Stage 4: Finding Something to Boot 

Once the low-level operating environment exists, the machine needs to find a bootable device. That might be: 
a floppy disk
a hard disk
another supported boot device

On a floppy-based Amiga system, the familiar scenario is simple: Insert a bootable Workbench or application disk and the Amiga boots from it. But behind that simple action is an important distinction. Kickstart and Workbench are not the same thing. Kickstart provides core operating system functionality. The boot medium supplies additional software and configuration required to build the user's working environment. The Boot Block Amiga floppy disks begin with a special area normally referred to as the boot block. A bootable floppy contains information allowing it to participate in the boot process. This is important because the computer does not simply start by looking for a file called Workbench. There is an earlier boot mechanism that allows the operating system to recognize and start from the medium. This capability also explains why some Amiga games can boot directly from floppy without ever showing Workbench. The disk can take control of its own startup path. Booting Does Not Necessarily Mean Starting Workbench This is worth emphasizing. A bootable Amiga disk does not necessarily contain a normal Workbench environment. Games and demos frequently boot directly into their own software. Therefore: Booting AmigaOS components does not automatically mean: Displaying Workbench Workbench is only one possible environment that can be started after boot. 

Stage 5: AmigaDOS 

Enters the Picture As the boot process progresses, the DOS environment becomes important. AmigaDOS provides important higher-level functionality related to: 
files
directories
volumes
file systems
command execution
command-line interaction
processes
handlers

This is the level at which familiar Amiga concepts such as: SYS: C: S: DEVS: L: LIBS: begin to become particularly visible. These names will become important throughout the rest of our series. 

Understanding SYS: 

One of the first concepts to understand is: SYS: On the Amiga, this is not simply the literal name of a particular physical disk. It is a logical system assignment referring to the current system volume. Suppose your Amiga boots from a hard disk partition called: Workbench: During that session, SYS: refers to the system volume used during boot. This makes system-oriented paths more flexible. A script can refer to: SYS:S rather than requiring one specific physical volume name. Important System Directories A typical AmigaOS installation contains several directories with specific purposes. 

C: 

The C: assignment normally refers to a directory containing commands. Examples could include commands such as: Copy Delete Dir Assign Echo When you type a command into the Shell, the system can search appropriate command paths such as C: for the executable. 

S: 

S: contains scripts and system configuration files. One particularly important file traditionally found here is: Startup-Sequence This file plays a major role in the boot process. 

DEVS: 

DEVS: is associated with devices and hardware-related configuration. It may contain device-related files, mount information, system configuration, and other resources required for hardware or filesystem access. 

L: 

L: traditionally contains system components such as handlers and other loadable modules used by DOS-related functionality. Handlers are particularly interesting because they help explain why AmigaDOS can treat different resources through a common naming system. We will explore them in a later article. 

LIBS: 

LIBS: contains loadable libraries. These supplement the library functionality already available from ROM or other parts of the system. Programs can load and use these libraries when required. Stage 6: The Startup-Sequence One of the most important steps in a traditional AmigaOS boot is the execution of: S:Startup-Sequence The Startup-Sequence is essentially a script containing AmigaDOS commands. Rather than hard-coding every part of the user environment into Kickstart, AmigaOS can configure much of its higher-level startup process through this script. This makes the boot process remarkably flexible. 

A simplified conceptual Startup-Sequence might do things such as: 
configure system assignments
start required system components
load preferences or configuration
make additional resources available
prepare the user environment
eventually start the graphical desktop

The exact contents depend on the AmigaOS version and installation. 

Why Startup-Sequence Is So Important 

The Startup-Sequence demonstrates an important division of responsibilities. Kickstart provides the fundamental operating system environment. Disk-based system files provide additional components. Startup-Sequence controls much of the higher-level startup configuration. This separation makes AmigaOS surprisingly flexible. An experienced user can modify the startup configuration without changing Kickstart itself. For example, additional software or system components can be launched automatically by adding appropriate commands to the startup configuration. User-Startup In later and more developed AmigaOS configurations, another file commonly appears: 

S:User-Startup 

This provides a convenient location for additional user or application initialization commands. The general idea is useful: Startup-Sequence primarily establishes the main operating environment. User-Startup can contain additional user-specific or software-specific initialization. This keeps customization separate from more central system startup commands. 

Assigns: 

One of AmigaDOS's Most Useful Ideas We've already seen several names ending in a colon: SYS: C: S: DEVS: LIBS: These are part of a very useful AmigaDOS concept: assigns. An assign provides a logical name for a location. For example: LIBS: might point to the directory containing shared libraries. Software can therefore look for: LIBS:somelibrary.library without needing to know the exact physical disk or directory arrangement. This makes the system highly configurable. It also makes Amiga paths look unusual to users coming from Windows, Linux, or modern macOS. 

Volumes, Devices and Assigns 

When learning AmigaDOS, it helps to recognize that a name followed by a colon does not always represent exactly the same kind of thing. You might encounter: A volume Work: A device DF0: An assign C: From the user's perspective, however, AmigaDOS provides a consistent naming style. This is one of the elegant characteristics of the system. Different types of resources can become accessible through a common path-oriented model. 

Stage 7: Starting Workbench 

Eventually, a conventional graphical boot process starts Workbench. Workbench is the graphical desktop environment most users associate with AmigaOS. 

It provides familiar concepts such as: 
disks
drawers
icons
tools
projects
windows

But by the time Workbench appears, an enormous amount has already happened. The CPU has started Kickstart. Core operating system components have been initialized. Memory has been made available. Expansion hardware may have been configured. A boot device has been selected. AmigaDOS has established the system environment. Startup scripts have been executed. Only then do we reach the familiar graphical desktop. Workbench Is Not AmigaOS This is probably the most important conceptual lesson in this article. Users sometimes use "Workbench" and "AmigaOS" as though they were the same thing. They are not. Workbench is one component of the larger operating system environment. 

Underneath Workbench are layers such as: 
Workbench 
↓ 
Intuition and graphics system 
↓ 
DOS, libraries, devices and handlers 
↓ 
Exec 
↓ 
Kickstart and low-level operating-system components 
↓ 
Amiga hardware 

This is only a conceptual model, not a strict diagram of every dependency, but it demonstrates the important idea: The graphical desktop is only the visible top of a much larger operating system architecture. What Happens When Workbench Is Not Started? One of the easiest ways to understand this distinction is to consider an Amiga that boots directly into another program. 

The machine can have: 
a functioning CPU
Kickstart
Exec
memory management
devices
graphics functionality
audio functionality

without presenting the Workbench desktop. Similarly, an Amiga can operate from the Shell. Workbench is useful, but it is not required for every type of Amiga software environment. Kickstart and Workbench Versions There is another historical source of confusion. 

Amiga users frequently refer to versions such as: 
Kickstart 1.3
Kickstart 2.x
Kickstart 3.x
Workbench 1.3
Workbench 2.x
Workbench 3.x

The ROM-based Kickstart environment and the disk-based system software need to work together appropriately. As AmigaOS evolved, both the ROM components and disk-based components changed. Therefore, understanding an Amiga installation often requires considering both sides of the system rather than looking only at the Workbench disk or only at the Kickstart ROM. A Simplified Amiga Boot Sequence 

Let's put the overall process together. 

1. Power on or reset The Motorola processor begins its reset sequence. 
↓ 
2. Kickstart begins execution The fundamental operating-system environment becomes active. 
↓ 
3. Exec and low-level services initialize Memory, tasks, interrupts, libraries, and other core mechanisms become available. 
↓ 
4. Hardware is configured The system establishes available resources and configures compatible expansion hardware. 
↓ 
5. A bootable device is selected For example, a floppy disk or hard disk. 
↓ 
6. DOS-level boot processing begins The disk-based environment becomes available. 
↓ 
7. System assignments and directories are established Names such as SYS:, C:, S:, DEVS:, L: and LIBS: become important. 
↓ 
8. Startup-Sequence executes Commands build the higher-level operating environment. 
↓ 
9. Additional startup configuration runs Depending on the system configuration, this can include user and application initialization. 
↓ 
10. Workbench starts 

The user reaches the graphical desktop. This sequence is simplified, but it provides a useful mental model for understanding the boot process. What About Booting From a Hard Disk? A hard-disk-equipped Amiga follows the same broad philosophy, although the storage and filesystem configuration is more sophisticated. Kickstart has to reach a point where an appropriate bootable partition and its filesystem can be used. Once the system volume becomes accessible, the familiar AmigaDOS environment can be established. Then the Startup-Sequence continues configuring the machine. 

From the user's perspective the result may simply be: Power on → hard disk activity → Workbench

But underneath, several layers of the operating system have been initialized. What About Games? Many Amiga games do not require the Workbench desktop. A bootable game disk can start its software directly. Some games use operating-system services extensively. Others take much greater control of the hardware themselves. 

This became particularly common because direct hardware programming could give developers precise control over: 
display timing
Copper
Blitter
sprites
audio
memory usage

This distinction between operating-system-friendly software and software that takes over much of the hardware is an important subject in its own right. Why the Boot Process Matters Understanding the boot process makes many seemingly mysterious Amiga concepts much easier to understand. Why does SYS: exist? Why is Startup-Sequence important? What is stored in DEVS:? Why are commands stored in C:? What are libraries doing in LIBS:? Why can a machine boot without displaying Workbench? Why can games boot directly from floppy? All these questions are connected to the layered architecture of AmigaOS. 

The Most Important Things to Remember 

1. Kickstart starts the fundamental operating environment On most familiar classic Amigas, major Kickstart components reside in ROM. 
2. The Amiga 1000 is different Its Kickstart environment is traditionally loaded from disk into special writable memory. 
3. Exec is the operating system core It provides fundamental mechanisms such as tasks, memory management, message passing, libraries, and interrupts. 
4. The Amiga can configure expansion hardware AutoConfig allows compatible expansion boards to participate in automatic resource configuration. 
5. Booting does not mean starting Workbench An Amiga can boot directly into other software. 
6. AmigaDOS creates the higher-level file and command environment This is where concepts such as volumes, directories, assigns, and commands become particularly visible. 
7. Startup-Sequence configures the system S:Startup-Sequence is a central script in the traditional AmigaOS boot process. 
8. Workbench is the desktop, not the entire operating system Many important parts of AmigaOS are already running before Workbench appears. From Booting to Understanding AmigaOS We have now followed the Amiga from its hardware architecture all the way to the Workbench desktop. This is an important turning point in our series. 

So far, the focus has mainly been: CPU → memory → Custom Chips → DMA → booting 

From the next article onward, we can begin looking inside AmigaOS itself. And this is where the architecture becomes particularly interesting. 

Coming Next: AmigaOS Under the Hood In 

Article 7: "AmigaOS Under the Hood – Exec, Libraries, Devices and Handlers", we can examine how the operating system is structured and explain the differences between: 
Exec
tasks and processes
libraries
devices
handlers
message ports
signals
DOS packets

We can also follow a practical example, such as what actually happens inside AmigaOS when a program opens and reads a file, from the application's request through DOS and the filesystem handler down toward the device layer. That will make the internal structure of AmigaOS much easier to visualize.