UserDoc:How AmigaOS Works

As already mentioned, AmigaOS was a pioneer in the early days of personal computing in delivering sophistication that contemporary systems could only have dreamt of and pretended to offer. Today, AmigaOS continues to offer a straightforward elegance that seems to be overlooked in the development of other platforms. Thanks to the concepts behind AmigaOS, the system is easy to understand and to use by everyone.

In this page we will explore all these concepts of AmigaOS. Also you will learn here the naming of all parts of the system.

Introduction

AmigaOS is made of different components which are either mandatory (i.e., AmigaOS will not work without them) or components the user can choose to use or not. All these components can have one or mutiple interfaces a user or a developer can use to operate with the components and through them to control the operating system.

The most important components

Exec, the AmigaOS kernel

Exec is the kernel of AmigaOS. It is the component that pilots all other components. It is responsible for running programs, dealing with computer memory and managing low-level resources that programs may need. In other words, it organises everything to make the operating system run.

It is made of different parts that cannot be moved outside the kernel: the scheduler, the memory pager and the 68k interpretive emulator.

AmigaDOS: the underlying system

The word "DOS" was originally an acronym for "Disk Operating System". Some say it should be "Disk Based Operating System" as it does a lot more than operate a disk and that it was really an operating system based (stored) on disks. Some say it should be "Device Operating System".

The whole AmigaDOS system includes things such as:

• A set of commands that can be used in the Shell window and elsewhere.
• A system for saving data to disk and retrieving it from disk.
• A system for filing data on disks.
• An interface for peripherals such as keyboards, monitors, printers, etc.
• A method of running programs
• A multitasking system for running more than one program at a time.
• etc. etc. etc.

Read the AmigaDOS manual to understand and learn everything about AmigaDOS.

The Graphics library

The Graphics library handles every low level graphic operation like designing pixels on the monitor, creating graphic elements (bobs, sprites) and also writing text output.

Intuition

The Intuition library is responsible for every graphical object: windows, screens, gadgets, mouse pointers... It lies between any graphic program and the graphics library.

The Workbench

The Workbench is the graphical place where you will manage your computer and all your files. The name was chosen because the user will use tools to create and work with the computer.

The Shell

While some people prefer to control the operating system using their mouse, others prefer using the keyboard. The shell is a text based window when you can type commands to execute actions in the operating system. In the shell the commands will display the results of their execution.

ARexx - inter-program communication by scripting

The ARexx scripting language can be used to operate the Workbench and other Amiga applications from a script containing ARexx commands. This is extremely useful in performing repetitive tasks or doing what the controlled application was not even designed to do. After a learning curve, everybody can use ARexx as it is built into the system. The scripts can be executed immediately like any other tool.

How is my data stored?

Files

Executable files

Programs you can start are stored in executable files. They contain binary code directly understandable by the computer. They are files with an executable bit, a flag that shows AmigaOS that such file will do something when started. An example is a music player. When you start this executable, the player opens and you can start playing music files.

AmigaOS can run two different kinds of executable files: the AmigaOS native programs made for the PowerPC processor and programs created for the Motorola 68k processors. The latter are executed inside an emulation that translates them into PowerPC code.

Scripts

Scripts are text files containing a list of commands. They are not strictly executables like binary code files but they can be executed by AmigaOS as if they were. This is the case with AmigaDOS and ARexx scripts. These files need to have the executable and script bits set.

Data files

Files that are not executable are data files. These contain data that will be manipulated by programs. Some examples are a music file, a video file or a text document.

Directories/Drawers

In order to organise things, files are grouped together. We create "directories" which are like drawers of a cabinet to store different files of the same kind, for example. Often the name directory is used when talking about a directory which is stored on a disk. The graphical interface of AmigaOS is called "Workbench," and directories are often called drawers.

Note: directories are often called folders on other systems. The terms "directory," "drawer" and "folder" are synonymous.

Disks, partitions and volumes

Disks

Disks are storage media you can purchase at a computer store. We use them to store our files. They can be internal hard disks, external hard drives, USB interface devices (i.e., SD cards, CF cards, "flash" drives, etc.), and floppy disk drives.

Partitions

A disk is often very big and many users prefer to make it more organised. This is done by virtually splitting the disk into several smaller parts. This operation is known as creating partitions on a disk.

On this screenshot you can see one harddisk with many partitions. Each color corresponds to a different filesystem which defines how data is stored. Also, you can see a greyed area which is a blank area on the disk (i.e., no partition is defined at this position). Several different file systems can be used on the same Amiga drive. It's your choice.

Volumes

A partition is a physical area on a disk. To access it with AmigaOS we must read the physical data off the partition. To make it easier AmigaOS uses the concept of volumes. These are virtual representations of a partition. The volumes have a name so AmigaOS and therefore the user can access all files/directories stored on it in a very practical way: just by using its name.

Volume names can refer to either a physical or virtual named space. See the autodoc section for the ASSIGN command in the C: directory as well as the MOUNT command which provides more information on naming and the concept of volumes.

How to identify files/directories

On the Workbench

The Workbench being graphical, a lot of things are understandable just by looking at them. That's why icons are often enough to understand what kind of object it represents: a file, a directory, a disk...

In case you have a doubt, just look at the information on an icon. The Workbench will tell you the type of the object. It is displayed next to its name.

In a shell

In a shell the list command can be used to see if an object is a file or a directory.

A file will be displayed with its size, whereas a directory will be displayed with the text Dir next to it.

Also, as you can see on the screenshot, the list command displays other characteristics on these 3 items: the protection bits and the date they were updated the last time. The command also sums up what it just listed.

All AmigaOS components

AmigaOS is made of components that are needed as soon as the system starts or later when the user or the system needs them.

Kickstart modules

These components are the heart of AmigaOS. Their duty is to draw graphics, to handle discs or to handle all reads/writes to files. Also one of them is the AmigaOS kernel which is a kind of director handling the work of all other components. These Kickstart modules are loaded at the beginning of the operating system boot process (read here). You can find them all in the Kickstart directory on the system volume. Here is a list:

Mandatory modules

The following modules are required in any AmigaOS system. Without one of these, the system will not start.

• kernel - The kernel works like the conductor of an orchestra. Its job is to make everything work together. It creates processes, handles memory usage, defines the way other components will access peripherals...etc. Note that the AmigaOS kernel is not based on any other kernel. It is a unique kernel that has existed since 1983.
• loader - this component handles the loading of all other kickstart modules
• battclock.resource.kmod - this module handles reading/writing the battery backed up clock which is used on all computers to keep the date and time
• bootimage - this is the boot picture. It is displayed during the start sequence of AmigaOS
• bootmenu.kmod - this component handles the Early Startup Menu the user can employ to define some settings before starting AmigaOS
• con-handler.kmod - it directs read and write requests to the console window, to a serial AUX: device or any other supported interface
• console.device.kmod - it opens a window and reads/writes text to and from that window
• diskboot.kmod - handles the booting of AmigaOS from a supported disk
• diskboot.config - this is a text file experienced users can modify to change the boot behaviour of AmigaOS
• dos.library.kmod - this module is a collection of functions that any program can use to perform actions on disks, files and directories
• elf.library.kmod - handles the loading of executable programs
• env-handler.kmod - handles the reads/writes of environment variables
• FileSystem.resource.kmod - handles access to the different filesystems
• gadtools.library.kmod - a collection of functions used to create all graphic objects like gadgets, sliders, menus...
• gameport.device.kmod - handles the reads/writes of game pads and joysticks
• graphics.library.kmod - a collection of functions used to draw graphic elements on the monitor
• hunk.library.kmod - a set of functions to read a data stream into memory
• input.device.kmod - handles input events like keyboard events or mouse clicks
• intuition.library.kmod - a collection of functions to create and handle all graphic elements (screens, windows, the mouse pointer...)
• layers.library.kmod - set of functions to be used to handle different layers in graphic operations
• keyboard.device.kmod - driver for the keyboard
• keymap.library.kmod - functions to handle different keymaps
• newlib.library.kmod - collection of functions to perform memory operations (allocating memory, copying memory areas... )
• nonvolatile.library.kmod - provides a simple means for an application developer to manage nonvolatile storage
• nvram.resource.kmod - handles the reads/writes to the NVRAM chip present on many AmigaOS computers
• PCIGraphics.card - driver that supports the use of different graphic cards
• ram-handler.kmod - functions that handle the Ram disk:.
• ramdrive.device.kmod - device that allows the usage of the ramdrive device RAD: disk
• ramlib.kmod - loads disk based libraries and devices for exec.library
• rtg.library - library of functions to perform low level graphic operations on graphics cards
• shell.kmod - the AmigaOS command line interface
• strap.kmod - module that handles booting on different disk devices
• timer.device.kmod - driver to give access to timing functions

Filesystem support

These kickstart modules can be loaded optionally. If you want to use a particular filesystem on your disk partitions, you need to load the corresponding filesystem module.

• CDFileSystem - handles the CD-ROM disks with data stored in different formats: ISO9660, HFS...
• SmartFilesystem - allows the usage of partitions in SFS0 and SFS2 layouts
• JXFileSystem - allows the usage of partitions in JXFS layout (now obsolescent)
• FastFileSystem - allows the usage of partitions in FFS and FFS2 layouts
• NGFileSystem - an experimental file system designed to gradually replace the FastFileSystem
• diskcache.library.kmod - component required by the SmartFileSystem and JXFileSystem modules

Hardware drivers

Graphic cards drivers

• 3dfxVoodoo.chip
• 3DLabsPermedia2.chip
• ATIRadeon.chip
• RadeonHD.chip
• siliconmotion502.chip

Disk drivers

Each of these drivers allows the use of disks connected to a disk controller. These files are named after the controller they support. As an example, the sii3114ide.device.kmod allows the use of disks connected to a Silicon Image SiI3114 controller chip.

• it8212ide.device.kmod
• lsi53c8xx.device.kmod
• sam460sata.device.kmod
• sii3112ide.device.kmod
• sii3512ide.device.kmod
• sii3114ide.device.kmod
• sii0680ide.device.kmod
• sii3132ide.device.kmod

USB drivers

• hub.usbfd
• usbsys.device
• usbresource.library
• ehci.usbhcd
• ohci.usbhcd
• uhci.usbhcd
• massstorage.usbfd

Other drivers

• bootkeyboard.usbfd - allows a USB keyboard to be used even before the USB stack is loaded
• bootmouse.usbfd - allows a USB mouse to be used even before the USB stack is loaded
• fpga.resource.kmod - allows to use the FPGA components which are present on some Amiga computers
• i2c.resource.kmod - allows to use the i2c interface present on some Amiga computers
• xena.resource.kmod - provides access to the Xena chip on the AmigaOne X1000

Misc modules

• petunia.library.kmod - this module contains the Just-In-Time emulator that allows AmigaOS to run programs made for the Motorola 68k processor

Control of the Kickstart

The Kickstart/ drawer contains an ASCII file called "Kicklayout". This file lists all the modules that must be loaded from the system volume during the boot process. It is read by the boot loaders "SLB" or "amigaboot".

The Kicklayout file consists of a number of configurations, each of which describes a set of Kickstart modules. Each configuration has a label and the various configurations are listed by label on the boot screen. The user may elect to load the default configuration or to select any one of the other configurations. Often a developer will have several configurations in his/her Kicklayout file, some of which may be experimental, while the default is a "known good" configuration to which (s)he can fall back.

You can edit the Kicklayout file using Notepad or any other ASCII editor. You are strongly advised to leave the original configuration unchanged (as a fall-back) and to add new configurations at the end of the file, each with its own label. That way you can still recover if you make a mistake while editing.

; Configuration name
LABEL MainSystem
; Exec name
EXEC Kickstart/loader.of
;
; PPC native modules
;
MODULE Kickstart/kernel
;
MODULE Kickstart/FastFileSystem
MODULE Kickstart/CDFileSystem
MODULE Kickstart/NGFileSystem
;
(etc)

Note that lines that start with a semicolon (";") are treated as comments and are ignored. Each configuration must start with a "LABEL" keyword and should be separated from the previous configuration by a blank line. The blank line signifies "Stop loading here".

Each module to be loaded is defined by the "MODULE" keyword, followed by the path and file name. You can use any path on the system volume, so you could have two or more drawers containing Kickstart modules and address them independently if you so wished. You can not refer to modules on other volumes, since they have not been mounted by DOS (which does not exist yet) and only the system volume is available at this early stage.

Selecting the Default Configuration

You can specify in the NVRAM the label of the default configuration in the Kicklayout. For instance, if your default configuration is called "MainSystem", the LABEL line will look like this:

LABEL MainSystem

You can define an NVRAM variable called "boot_config" using U-Boot, CFE or the "nvsetvar" tool. Simply type:

nvsetvar boot_config "MainSystem"

[Note that nvsetvar may be inhibited from writing to the NVRAM on some systems, in which case you will have to use U-Boot or CFE to set the variable]

If you do not specify a default configuration with the "boot_config" variable, the boot loader will default to the first configuration in the Kicklayout.

System components

List of directories and files present at the root of any AmigaOS system

Beside the kickstart modules, AmigaOS uses many different components that can be loaded only when needed. These files are stored in different directories in the system volume. A default AmigaOS installation looks like this:

• C

This directory contains AmigaDOS Commands

• Classes

contains different object elements easy to be used in any program: gadgets, requesters, graphic table, windows...

• Devs

contains definitions for Devices

• Emulation

contains files used for the 68k emulation (though E-UAE)

• Fonts

contains various systems fonts

• Internet

contains Internet-related files and configurations

• Kickstart

contains the kickstart modules

• L

contains handlers and filesystems

• Libs

contains dynamic Librairies of functions

• Locale

contains all files used to customise the system for your locality (catalogs, keymaps...)

• MUI

contains the files needed for programs that use the MUI third party graphic interface

• Prefs

contains the preference programs used to customise AmigaOS

• S

contains the system's Scripts

• SObjs

contains .so shared object library files

• Storage

contains other optional files, not currently used

• System

contains some programs used by the system itself (i.e. you don't need to run them yourself) or low-level programs like disk tools

• Utilities

contains several programs you can use to achieve some tasks on AmigaOS

Motorola 680x0 Emulators

For a long time Amigas have had the famous Motorola 680x0 processors as the central unit for execution. Unfortunately the time of the 680x0 series is passing in favor of other architectures. The new era of processors reached the Amiga some time ago, when expansion boards became available for extending the Classic systems with the raw power of a PowerPC processor.

In the old operating system (AmigaOS 3.x) it was not possible to gain the full advantage of the new processors. The system itself and most of the applications required the original Motorola 680x0 processor. There was no 680x0 emulation available for the PowerPCs, so the 680x0 could not be "switched off".

Thus the new processors remained as a powerful, but mostly unused adjunct to the main 680x0 processor. "Native" PowerPC programs were rare, and every time a PowerPC program called the system, a so called "context switch" occurred between the 680x0 and PowerPC code, often causing a large performance penalty.

The new Amiga platform is based on the PowerPC processor family, therefore the new version of the AmigaOS has to smooth the transition from the 680x0 series, which is achieved by emulating the old processor architecture. The operating system itself is written almost 100 percent for the PowerPC processors, but the 680x0 legacy applications require an emulated 680x0 processor.

Two 680x0 Emulators

In version 4.0 of AmigaOS, two different emulators were implemented. One is the successor of BlackBox emulation. It is an interpretive emulator with mediocre emulation speed. On the other hand, it has a very low "reaction time" and is ideal for time critical parts, such as interrupts.

The other is Petunia, the "JIT emulator", a fast but less compatible way of emulation of the legacy Motorola processors. It is intended mainly for emulating applications. When execution of the application leaves the bounds of the application's code segment, emulation falls back to the interpretive method, where it does its job and returns to the JIT emulation again.

Dynamic recompilation (also called just-in-time compilation or simply JIT compilation) is a technique of translating foreign processor machine code to native machine code "on the fly".

This technique is common nowadays in JAVA virtual machines. It is also used with success in several emulators. In dynamic recompilation, there is the possibility of runtime optimization of the emulated code by collecting statistics of the execution process. Therefore (theoretically) the final executed code can be even faster than the original code on its original processor.

Features

Emulated opcodes:

• all user and supervisor level opcodes of the Motorola 68040
• all FPU opcodes of the Motorola 68881/68882

AmigaOS claims only 68020/68881 compatibility to applications because this is the safest compatibility level, but both emulators are compatible with the machine code up to the level of 68040/060 processors.

At compile time, a low level flag and branch control analysis allows on-the-fly optimizations of compiled code.

Removing the JIT Emulator

Using dynamic translation requires a lot more memory than interpretive emulation. The translated code needs to be stored somewhere, not to mention the data collection tables.

If speed is not as important as the memory consumption of the system, the JIT emulator can be removed, leaving the job to the interpretive emulator.

Thanks to the modular design of AmigaOS kickstart, all you need to do is edit the "Sys:Kickstart/Kicklayout" file. Simply put a semicolon (;) at the beginning of the module line "Petunia.library.kmod". After executing a "cold" system reboot, the JIT emulator will not be reloaded. Make sure that you alter the appropriate configuration in the Kicklayout file. There may be several alternative configurations with different names, such as "DefaultJIT" or "DefaultNoJIT".

Configuring the Emulators

Petunia cooperates with a so called "black list". By default, Petunia emulates every 680x0 program or library that is loaded by DOS.library/LoadSeg function, but if an executable or library shows incompatibilities with Petunia, then it can be explicitly inhibited from the dynamic recompilation by specifying it in a list.

If an executable needs to be added to the list, then it can be done by extending the file "DEVS:applications.dos" with the Compatibility preferences program from the Prefs drawer of the system. Adding a program name to the list and checking it will prevent Petunia from emulating that program, and it will be interpreted instead by the built-in interpreter.

Removing a program from the list or unchecking (thus allowing Petunia to emulate it again) can be done with the same preferences program.

Please note: some programs consist of multiple executables (shared libraries, plugins). If you want to fully disable the translation of such programs, then every part must be added to the list.

For example to disable UnArc fully, you would have to add to the list all files from libs:xad and also xadmaster.library.

AmigaOS boot procedure

Classic Amigas with PowerPC accelerators, the original AmigaOne SE/XE and the Sam series of Amigas all use the Second Level Booter (SLB) to read their Kickstart modules from the system volume. The newer A-Eon machines (X1000, X5000, A1222) all use a loader called AmigaBoot. In the X1000, AmigaBoot must be read from an FFS partition, while in the later machines, it is stored in the on-board CF card. The process of loading the kickstart modules is the same in all cases.

Basically a computer with AmigaOS does the following when the power button is pushed:

• 

The BIOS (Uboot or CFE) of the computer initialises the hardware: graphic card, USB ports... At this point, the monitor wakes up and the first information is displayed. This shows if hardware is correctly recognised. As an example you can see if a hard drive is correctly connected into the machine and your BIOS is correctly set up to make this drive useable.

• Depending on the machine type, the BIOS will look on the harddisk to find the Second Level Booter (SLB) or AmigaBoot, or will execute the AmigaBoot program from the on-board NVRAM. Whereas the BIOS does not know about AmigaOS disk structure, the SLB/AmigaBoot can understand the AmigaOS partitions and file systems. In other words, it is the link between the BIOS and the rest of the boot procedure. Its goal is also to give you the ability to start several configurations present on the same drive.
• 

SLB/AmigaBoot analyses all Amiga partitions on the system disk. It reads each system configuration it finds on the partition and displays them all for the user to select one to load. AmigaBoot (not SLB) also displays configurations from Kickstart/Kicklayout files on every "bootable" partition. The user can define many different kickstart configurations to choose from. Also both AmigaOS and Linux can be selected for boot.

• 

SLB/AmigaBoot loads the kickstart files of the selected configuration and executes the Loader module

• Loader executes the kickstart modules (Exec, devices, libraries...)
• AmigaOS becomes alive displaying the AmigaOS boot picture on the monitor
• The AmigaDOS library executes the startup-sequence script found on the system volume
• The Startup-sequence will be executed and all commands it contains are executed. It means that starting from here the boot procedure is easy to follow and understand.
• The Workbench is started

At this point the user can use his/her computer.

How to make a Bootable USB Memory Stick for AmigaOS 4.1

By Julian Margetson ("Spectre660")

Prerequisites:

• USB memory stick of 2 GB or less in size.
• It is best to only have one USB mass storage device connected while you are creating your bootable USB memory stick.
• Plug the USB memory stick into a USB port on your machine.
• Note that the device will be formatted so make sure that you use an empty memory stick or one that does not contain any data that you need or backup the contents before you begin.

Procedure:

1. You use Media Toolbox in the System: drawer to prepare the USB stick. On starting Media Toolbox select usbdisk.device as the device to use.
2. Make certain that you have selected usbdisk.device and not any other device.
3. Click on "Start"
4. You will see the usb mass storage unit connected in a list.
5. Make sure that the Unit type displayed for the USB memory stick is "Removable hard disk"
6. Select that Unit by clicking on it.
7. The first thing that you need to do is to install the RDB onto the USB Memory Stick.
8. Click on the "Install" button.
9. A window Labeled "RDB/disk geometry editing" comes up.
   1. Towards the bottom of the window is the "AmigaOne boot code (SLB)" section.
   2. Select the "Install" button .
   3. A file requester "Select AmigaOne Boot Code" now comes up with the Drawer choice defaulting to "l:"
   4. Select file "slb_v2".
   5. Select Ok.
   6. You are now returned to the "RDB/disk geometry editing window".
   7. Select "Ok-accept changes".
10. You are now returned to the display showing the attached USB unit.
11. Select "Edit partitions and Filesystems". You will now see the Window 'Editing partitions for disk"
12. Select "Add partition"
13. This defaults to using the whole device as a single partition.
14. It is possible to use create more partitions but for this tutorial we will only use one.
15. You now need to give the partition a unique name (e.g. USB0 or something that is different from any of the existing partitions on your hard drive). This is done by changing the default DH0 in the "Name" box.
16. Now make sure that the Boxes "Automount" and "Bootable" are selected and show the "Tick mark".
17. You need to set "Boot priority" to higher than the boot priority of your hard drive boot partition(s). This is done by increasing Boot priority by clicking on the "+" to the right of the "boot priority" box. Normally you can set the boot priority to 2 .
18. Next it is time to select the file system to use.
19. Select "Select filesystem/edit details".
20. The Window "Editing details for partition 'USB0'" ,or whatever partition name you used, comes up.
    1. Select the file system that you are going to use by selecting the pull down menu under "Filesystem chooser".
    2. Only filesystems SFS/00 or SFS/02 will work for a bootable device.
    3. The option that gives the most flexibility at the moment is SFS/00 as a USB stick in this format can be read from and written to using another compatible system in the event that you need to make modifications after it is created without a booting AmigaOS 4.1 machine.
    4. Next select Blocksize from the "Blocksize" pull down menu. 512 is the correct size to use.
    5. Now Select "Ok-accept changes".
    6. Your are now returned to the "Edit partitions for disk" window.
    7. Again select "Ok-accept changes"
21. You are now returned to the window showing the USB mass storage unit list.
22. Select "Save to disk"
23. A requester pops up with the options "Yes, Save." or "No!"
24. Select the "Yes, save." option.
25. You now close Media Toolbox by clicking on the close icon (X) on the left of the Media Toolbox window.
26. This will give you a requester advising that you need to reboot the machine for the changes to take effect. At this point you need to remove the USB memory stick for the machine. If you do not then the Machine will attempt boot from it before it is formatted and the required Kickstart and AmigaOS 4.1 files are copied to it.
27. Select "Yes, reboot NOW!".
28. Once you have rebooted connect your USB Memory Stick to a USB port.
29. A disk icon "USB0:Uninitialized" (or whatever partition name you used) appears on Workbench.
30. You now need to format the device.
31. To format Select this Icon and go to the Workbench "Icons" menu .
32. Select "Format Disk"
33. You can give the USB Memory Stick a unique name and select whether you want a Trashcan or not.
34. You can use either a full Format or a Quick Format. Full Format may take a few minutes.
35. Once formatted the USB Memory Stick is ready for you to copy the required files from you hard drive or AmigaOS Install CD to it in order to boot AmigaOS 4.1 from it.