This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (July 2009)

AmigaOS is the default native operating system of the Amiga personal computer. It was developed first by Commodore International, and initially introduced in 1985 with the Amiga 1000. Old versions only run on the Motorola 68k series of 16-bit and 32-bit microprocessors, while the newer AmigaOS 4 runs only on PowerPC microprocessors.

On top of a preemptive multitasking kernel called Exec, it includes an abstraction of the Amiga's unique hardware, a disk operating system called AmigaDOS, a windowing system API called Intuition and a graphical user interface called Workbench. A command line interface called AmigaShell is also available and integrated into the system. The GUI and the CLI complement each other and share the same privileges.

The current holder of the Amiga intellectual properties is Amiga Inc. In 2001 they contracted AmigaOS 4 development to Hyperion Entertainment and in 2009 they granted Hyperion an exclusive, perpetual, worldwide right to AmigaOS 3.1 in order to develop and market AmigaOS 4 and subsequent versions.^[1]

Components[link]

AmigaOS can be divided into two parts: the Kickstart (ROM) and Workbench disks. Versions of Kickstart and Workbench used to be released together, for use with each other. Since Workbench 3.5, the first release after Commodore International stopped development, however, new Kickstart revisions stopped being produced, relying instead on a 3.1 ROM that is patched during boot.

Kickstart[link]

Kickstart is the bootstrap ROM. The Kickstart contains the code needed to boot standard Amiga hardware and many of the core components of AmigaOS. The function of Kickstart is comparable to the BIOS plus the main operating system kernel in IBM PC compatibles. However, Kickstart provides more functionality available at boot time than would be typically expected on PC, for example, the full windowing environment.

The Kickstart contained many stock parts of the Amiga's operating system, such as Exec, Intuition, the core of AmigaDOS and functionality to use Autoconfig expansion hardware. This meant that a powered-on Amiga already had a lot of the essential parts of the operating system available. Later versions of the Kickstart contained drivers for IDE and SCSI controllers, PC card ports and various other hardware that came built into Amigas.

Upon start-up or reset the Kickstart performs a number of diagnostic and system checks and then initializes the Amiga chipset and some core OS components. It will then examine connected boot devices and attempt to boot from the one with the highest boot priority. If no boot device is present a screen will be displayed asking the user to insert a boot disk - typically a floppy disk.

Workbench[link]

Workbench is the native graphical desktop environment for the Amiga computer. Workbench is not the operating system, it's just a desktop environment running on top of AmigaOS. The Workbench environment does not have to be loaded for software to run. In fact, to take over the Amiga hardware and keep all memory and resources to themselves, many games boot directly from Kickstart (using a custom bootblock on the floppy disk).

As the name suggests, the metaphor of a workbench is used, rather than a desktop; directories are depicted as drawers, executable files are tools, data files are projects and GUI widgets are gadgets. In many other aspects the interface resembles Mac OS, with the main desktop showing icons of inserted disks and hard drive partitions, and a single menu bar at the top of every screen. Unlike the Macintosh mouse available at the time, the standard Amiga mouse has two buttons – the right mouse button operates the pull-down menus, with a "release to select" mechanism.

A unique feature of AmigaOS is multiple screens. AmigaOS screens do not require the Workbench desktop environment. These screens are conceptually similar to X Window System virtual desktops or workspaces, but are generated dynamically by application programs as necessary. Each screen can have a different resolution and colour depth. A gadget in the top-right corner of the screen allows screens to be cycled — as the OS stores all screens in memory simultaneously, redrawing is instantaneous. Screens can also be dragged up and down by their title bars. On older Amigas this functionality was provided by the custom chipsets specially designed for the platform, but since AmigaOS4 a new technique is adopted and the screens are draggable in any direction. Drag and drop between different screens is possible too.

Underlying the Workbench is the Intuition windowing system. This controls and draws screens, windows and gadgets, and handles input from the keyboard and mouse, passing messages to programs.

AmigaOS 2.x user interface improvements[link]

Until AmigaOS 2.0, there was no unified look and feel design standard — application developers had to write their own widgets (both buttons and menus), with Intuition providing minimal support. With AmigaOS 2.0 came gadtools.library, which provided standard widget sets, and the Amiga User Interface Style Guide, which explained how applications should be laid out for consistency.

AmigaOS 2.0 also added support for public screens. Instead of the Workbench screen being the only shareable screen, applications could create their own named screens to share with other applications.

AmigaOS 2.0 introduced AmigaGuide, a simple hypertext markup scheme and browser, for providing online help inside applications. It also introduced Installer, a standard software installation program, driven by a LISP-like scripting language.

Finally, AmigaOS 2.0 rectified the problem of developers hooking directly into the input-events stream to capture keyboard and mouse movements, often locking up the whole system. AmigaOS 2.0 provided Commodities, a standard interface for modifying or scanning input events. This included a standard method for specifying global "hotkey" key-sequences, and a Commodities Exchange registry for the user to see what commodities were running.

AmigaOS 2.1 introduced locale.library and for the first time AmigaOS was translated to different languages.^[2]

AmigaDOS[link]

AmigaDOS provides the disk operating system portion of the AmigaOS. This includes file systems, file and directory manipulation, the command-line interface, file redirection, console windows, and so on. Its interfaces offer facilities such as command redirection, piping, scripting with structured programming primitives, and a system of global and local variables.

In AmigaOS 1.x, the AmigaDOS portion was based on TRIPOS, which is written in BCPL. Interfacing with it from other languages proved a difficult and error-prone task, and the port of TRIPOS was not very efficient.

From AmigaOS 2.x onwards, AmigaDOS was rewritten in C and Assembler, retaining full 1.x BCPL program compatibility, and it incorporated parts of the third-party AmigaDOS Resource Project,^[3] which had already written replacements for many of the BCPL utilities and interfaces.

ARP also provided one of the first standardized file requesters for the Amiga, and introduced the use of more friendly UNIX-style wildcard (globbing) functions in command line parameters. Other innovations were an improvement in the range of date formats accepted by commands and the facility to make a command resident, so that it only needs to be loaded into memory once and remains in memory to reduce the cost of loading in subsequent uses.

In AmigaOS 4.0, the DOS abandoned the BCPL legacy completely, and starting from AmigaOS 4.1, it has been rewritten with full 64bit support.

File extensions are often used in AmigaOS, but they are not mandatory and they are not handled specially by the DOS, being instead just a conventional part of the file names. Executable programs are recognized using a magic number.

Graphics[link]

Up to version 3, AmigaOS only supported the native Amiga graphics chipset, via graphics.library. This led developers to avoid OS functionality for drawing, and go straight for the underlying hardware. Third-party graphics cards were only supported via unofficial solutions.

The ideal situation, where the AmigaOS could directly support any graphics system, was termed retargetable graphics (RTG).^[4] With AmigaOS 3.5, some RTG systems were bundled with the OS, allowing the use of common hardware cards other than the native Amiga chipsets. The main RTG systems are CyberGraphX, Picasso 96 and EGS.

The Amiga did not have any official 3D graphics capability, so it had no standard 3D graphics interface. Graphics card manufacturers and 3rd party developers provided their own standards, which include MiniGL, Warp3D, StormMesa (agl.library) and CyberGL.

The Amiga was born at a time when there was almost no concept of 3D graphics libraries to enhance desktop GUIs and computer rendering capabilities but, thanks to its graphic capabilities, the Amiga was one of the first widespread 3D development platforms. VideoScape 3D was one of the earliest 3D rendering & animation systems, as well as TrueSpace 3D. Then Amiga led the 3D software market for years with software like Imagine and NewTek's Lightwave (used to render television shows like Babylon 5).

Likewise, while the Amiga is well known for its ability to easily genlock with video, it has no built-in video capture interface. In its golden age, the Amiga supported a vast market of third-party interfaces for video capture from American and European manufacturers. There were internal and external hardware solutions, called frame grabbers, for capturing individual or sequences of video frames, including: Newtronic Videon, Newtek DigiView [1], Graffiti external 24-bit framebuffer, the Digilab, the Videocruncher, Firecracker 24, Vidi Amiga 12, Vidi Amiga 24-bit and 24RT (Real Time), Newtek Video Toaster, GVP Impact Vision IV24, MacroSystem VLab Motion and VLab PAR, DPS PAR (Personal Animation Recorder), VHI (Video Hardware Interface) by IOSPIRIT GmbH, DVE-10, etc. Some solutions were hardware plug-ins for Amiga graphic cards like the Merlin XCalibur module, or the DV module built for the Amiga clone Draco from the German firm Macrosystem. Modern PCI bus TV expansion cards and their capture interfaces are supported through tv.library by Elbox Computer and tvcard.library by Guido Mersmann.

The original Amiga graphic engine and graphic widget library was the intuition.library, which with AmigaOS v2.0 were enhanced with GadTools. Stefan Stuntz created Magic User Interface (MUI) used in all Amiga systems since v2.0 and is now the official widget toolkit in MorphOS while AROS implements MUI clone called Zune, The widget toolkit ClassAct evolved into ReAction GUI which is used in AmigaOS 3.9 and 4.0. In AmigaOS v4,0 ReAction GUI is the standard one. Cygnix provides Amiga with a full Unix/Linux X11 compatible graphic environment. Some vector graphic libraries, like Cairo and Anti-Grain Geometry are also available.

All modern Amiga systems have made large use of cross-platform SDL (simple DirectMedia Layer) engine for games and other multimedia programs.

Following modern trends in evolution of graphical interfaces AmigaOS 4.1 uses 3D hardware accelerated Porter-Duff image composition engine.

Audio[link]

Up to version 3.1, AmigaOS only supported the original Amiga chipset's sound capabilities, via audio.device. Support for third-party audio cards was vendor-dependent, until the creation and adoption of AHI [2] as a de facto standard. AHI can be installed separately on m68k/AmigaOS v2.0 and higher.^[5] AmigaOS itself did not support MIDI until 3.1 when Roger Dannenberg's camd.library was adapted as the standard MIDI API. Commodore's version of camd.library also included a built-in driver for the serial port. The later open source version of camd.library by Kjetil Matheussen did not provide a built in driver for the serial port, but provided an external driver instead.

Speech synthesis[link]

The original Amiga was launched with speech synthesis software, developed by Softvoice, Inc. [3] This could be broken into three main components: narrator.device, which could play and modulate all phonemes used in American English, translator.library, which could translate English text to American English phonemes, and the SPEAK: handler, which command-line users could redirect output to have it spoken.

In the original 1.x releases, a Say program in Utilities and a basic demo was also included with AmigaBASIC programming examples.

The speech synthesiser was occasionally used in third-party programs, often educational software. The word processors Prowrite and Excellence! could read out documents using the synthesiser.

Despite the limitation on the narrator.device's phonemes, Francesco Devitt wrote a new version of translator.library which could translate any language to phonemes, given a set of rules for that language, and thus provided multilingual speech synthesis. [4]

Workbench 2.0 was the last release with speech synthesis support. The speech synthesis software was dropped from the 2.1 release onward.^[2]

ARexx[link]

The AmigaOS has support for the Rexx language, called ARexx (short for "Amiga Rexx"), and is a script language which allows for full OS scripting, similar to AppleScript, intra-application scripting, similar to VBA in Microsoft Office, as well as inter-program communication. Having a single scripting language for any application on the operating system is beneficial to users, instead of having to learn a new language for each application.

Programs can listen on an "ARexx port" for string messages. These messages can then be interpreted by the program in a similar fashion to a user pushing buttons. For example, an ARexx script run in an e-mail program could save the currently displayed email, invoke an external program which could extract and process information, and then invoke a viewer program. This allows applications to control other applications by sending data back and forth directly with memory handles instead of saving files to disk and then reloading.

RAM disk[link]

The AmigaOS has a dynamically-sized RAM disk, which resizes itself automatically to its contents. Starting with AmigaOS 2.x, operating System configuration files were loaded into the RAM disk on boot, greatly speeding operating system usage. Other files could be copied to the RAM disk like any standard device for quick modification and retrieval. Also beginning in AmigaOS 2.x, the RAM disk supported file-change notification, which was mostly used to monitor prefs files for changes.

Later versions of the AmigaOS also has support for a fixed-capacity recoverable RAM disk, which functions as a standard RAM disk, but can maintain its contents on soft restart. It is commonly called the RAD disk, and it can be used as a boot disk (with boot sector). Previously, a recoverable RAM disk, commonly called the ASDG RRD or VD0 was introduced in 1987^[6] at first locked to ASDG expansion memory products. Later the ASDG RRD was added to the Fred Fish series of freeware, shareware and public domain software (disks 58^[7] and 241^[8]).

Bootblock[link]

At start-up Kickstart attempts to boot from a bootable device (typically, a floppy disk or hard disk drive). In the case of a floppy the system reads the first two sectors of the disk (the bootblock), and executes any boot instructions stored there. Normally this code passes control back to the OS (invoking AmigaDOS and the GUI) and using the disk as the system boot volume. Any such disk, no matter what the other contents of the disk, was referred to as a "Boot disk" or "bootable disk". A bootblock could be added to a blank disk by use of the "install" command. Some entertainment software contained custom bootblocks. This allowed an application, game or demo to take control of memory and resources, effectively disabling AmigaOS.

The bootblock became an obvious target for virus writers. Some games or demos that used a custom bootblock would not work if infected with a bootblock virus, as the code of the virus replaced the original. The first such virus was the SCA virus. Anti-virus attempts included custom bootblocks. These amended bootblock advertised the presence of the virus checker while checking the system for tell-tale signs of memory resident viruses and then passed control back to the system. Unfortunately these could not be used on disks that already relied on a custom bootblock, but did alert users of potential trouble. Several of them also replicated themselves across other disks, becoming little more than viruses in their own right.

Technical overview[link]

John C. Dvorak stated in 1996:

The AmigaOS "remains one of the great operating systems of the past 20 years, incorporating a small kernel and tremendous multitasking capabilities the likes of which have only recently been developed in OS/2 and Windows NT. The biggest difference is that the AmigaOS could operate fully and multitask in as little as 250 K of address space. Even today, the OS is only about 1MB in size. And to this day, there is very little a memory-hogging CD-ROM-loading OS can do the Amiga can't. Tight code — there's nothing like it.
I've had an Amiga for maybe a decade. It's the single most reliable piece of equipment I've ever owned. It's amazing! You can easily understand why so many fanatics are out there wondering why they are alone in their love of the thing. The Amiga continues to inspire a vibrant — albeit cultlike — community, not unlike that which you have with Linux, the Unix clone."^[9]

Libraries and devices[link]

The main modularisation technique in AmigaOS is based on dynamically-loaded shared libraries, either stored as a file on disk with a ".library" filename extension, or stored in the Kickstart ROM. All library functions are accessed via an indirect jump table, which is a negative offset to the library base pointer. That way, every library function can be patched or hooked at run-time, even if the library is stored in ROM.

The most important library in AmigaOS is exec.library (Exec), which can be considered a microkernel, as well as a library. It acts as a scheduler for tasks running on the system, providing pre-emptive multitasking with prioritised round-robin scheduling. Exec also provides access to other libraries and high-level inter-process communication via message passing. (Other microkernels have had performance problems because of the need to copy messages between address spaces. Since the Amiga has only one address space, Exec message passing is quite efficient.) The only fixed memory address in the Amiga software (address 4) is a pointer to exec.library, which can then be used to access other libraries. Exec was designed and implemented by Carl Sassenrath.

Unlike traditional operating systems, the exec kernel does not run "privileged". Contemporary operating systems for the 68000 such as Atari TOS and SunOS used trap instructions for invoking kernel functions. This made the kernel functions run in the 68000's supervisor mode, while user software ran in the unprivileged user mode. Mac OS on the 68000 even used supervisor mode for everything, kernel and application code alike. By contrast, exec function calls are made with the library jump table, and the kernel code normally executes in user mode. Whenever supervisor mode is needed, either by the kernel or user programs, the library functions Supervisor() or SuperState() are used.

Device drivers are also libraries, but they implement a standardised interface. Applications do not usually call devices directly as libraries, but use the exec.library I/O functions to indirectly access them. Like libraries, devices are either files on disk (with the ".device" extension), or stored in the Kickstart ROM.

Datatypes[link]

Datatypes are a unique method of dealing with data files born on Amiga. It is a centralized system that handles a series of "datatypes" that could be considered as a series of little programs capable of acting as muxer/demuxer and loading and saving any kind of data file for which the corresponding datatype exists.

Any Amiga productivity software, such as a "paint" program, does not need to embed its own descriptors for dealing with the enormous number of different image files that exist. Amiga software developers just have to embed in their program the code dealing with datatypes, and the software could then open and save any kind of image file types for which a datatype is present on the computer.

Example: existing Amiga jpeg.datatype and tiff.datatype will handle correctly the file types they refer to (JPEG and TIFF image files) and any Amiga program that has the datatype system built into it will then be able to deal automatically with these kind of files by loading the features present into the corresponding datatype.

New datatypes can be written by any Amiga programmer to update the existing datatype system with new features or even build a whole new datatype descriptor that will be capable of dealing with emerging file types that never existed before.

Handlers, AmigaDOS and filesystems[link]

The higher-level part of device and resource management is controlled by handlers, which are not libraries, but tasks, and communicate by passing messages.

One important type of handler is a filesystem handler. The AmigaOS can make use of any filesystem for which a handler has been written, a possibility that has been exploited by programs like CrossDOS and by a few "alternative" file systems to the standard OFS and FFS. These file systems allow one to add new features like journaling or file privileges, which are not found in the standard operating system.

Handlers typically expose a device name to the DOS, which can be used to access the peripheral (if any) associated with the handler.

As an example of these concepts, the SPEAK: handler can have text sent to it. The handler makes use of translator.library, which converts text into phonemes, then it writes the phonemes to narrator.device, which translates the phonemes into intoned speech samples and itself uses audio.device to play them through the Amiga's audio hardware.

Device names are case insensitive (uppercase by convention) strings followed by a colon. After the colon a specifier can be added, which gives the handler additional information about what is being accessed and how. In the case of filesystem, the specifier usually consists of a path to a file in the filesystem; for other handlers, specifiers usually set characteristics of the desired input/output channel (for the SER: serial port driver, for example, the specifier will contain bit rate, start and stop bits, etc.).

Filesystems expose drive names as their device names. For example, DF0: by default refers to the first floppy drive in the system. On many systems DH0: is used to refer to the first hard drive.

Filesystems also expose volume names, following the same syntax as device names: these identify the specific medium in the file system-managed drive. If DF0: contains a disk named "Workbench", then Workbench: will be a volume name that can be used to access files in DF0:.

If one wanted to access a file named "Amp" located in directory "Win" of the disk with name "Work" in drive DF0:, one could write

DF0:Win/Amp

or

Work:Win/Amp

However, these are not completely equivalent, since when the latter form is used, the system knows that the wanted volume is "Work" and not just any volume in DF0:. Therefore, whenever a requested file on "Work" is being accessed without volume "Work" being present in any drive, it will say something to the effect of:

Please insert volume Work in any drive

Programs often need to access files without knowing their physical location (either the drive or the volume): they only know the "logical path" of the file, i.e. whether the file is a library, a documentation file, a translation of the program's messages, etc.

This is solved in AmigaOS by the use of assigns. An assign follows, again, the same syntax as a device name; however, it already points to a directory inside the filesystem. The place an assign points to can be changed at any time by the user (this behaviour is similar to, but nevertheless distinct from the subst command in MS-DOS for example). Assigns were also convenient because one logical assign could point to more than one different physical location at the same time, thereby allowing an assign′s contents to expand logically, while still maintaining a separate physical organization. Standard assigns that are generally present in an AmigaOS system include

• SYS:, which points to the boot drive's root directory.
• C:, which points to a directory containing shell commands. At boot time, this is SYS:C, if it exists, otherwise SYS:. The command path defaults to C: and the current working directory, so putting executables in C: allows them to be executed simply by typing their name.
• DEVS:, which points to a directory containing the system's devices. At boot time, this is SYS:Devs if that directory exists, otherwise SYS:.
• L:, which points to a directory containing AmigaDOS handlers and filesystems. At boot time, this is SYS:L if it exists, otherwise L: is not automatically created.
• LIBS:, which points to a directory containing the system's libraries. At boot time, this is SYS:Libs if that directory exists, otherwise SYS:.
• S:, which points to a directory with scripts, including the startup-sequence which is executed automatically at boot time, if it exists. At boot time, this is SYS:S if it exists, otherwise S: is not automatically created.
• PROGDIR:, a special assign that always points to the directory containing the currently running executable. So, if you run "SYS:Tools/Multiview" and "SYS:System/Format", PROGDIR: points at SYS:Tools for Multiview while simultaneously pointing at SYS:System for the Format command. This feature was introduced in Workbench 2.0.

Paging Memory and Swap Partition[link]

AmigaOS 4 introduced new system for allocating RAM and defragmenting it "on the fly" during system inactivities. It is based on slab allocation method and there is also present a memory pager that arbitrates paging memory and allows the swapping of large portions of physical RAM on mass storage devices as a sort of virtual memory.^[10][11] Co-operative paging was finally implemented in AmigaOS 4.1.

Influence on other operating systems[link]

This section is in a list format that may be better presented using prose. You can help by converting this section to prose, if appropriate. Editing help is available. (December 2011)

AmigaOS and clones

• AROS Research Operating System (AROS) implements the AmigaOS API in a portable open-source operating system. Although not binary compatible with AmigaOS (unless running on 68k), users have reported it to be highly source-code compatible.
• MorphOS is a PowerPC native operating system which also runs on some Amiga hardware. It implements AmigaOS API and provides binary compatibility with "OS-friendly" AmigaOS applications (that is, those applications which do not access any native, legacy Amiga hardware directly).
• pOS was a multiplatform closed-source operating system with source code-level compatibility with existing Amiga software.^[12]
• Although not strictly Amiga-related, a fork of the FreeBSD 4.8 release, called DragonFly BSD, has been created by a former FreeBSD developer and Amiga programmer Matt Dillon. DragonFly BSD aims to make the FreeBSD kernel more like AmigaOS architecturally, featuring message-passing in the kernel and allowing for very efficient and virtually mutex-free SMP support.
• BeOS features also a centralized datatypes structure similar to Mac OS Easy Open after old Amiga developers requested Be to adopt Amiga datatypes service. It allows the entire OS to recognize all kind of files (text, music, videos, documents, etc.) with standard file descriptors. Datatype system provides entire system and any productivity tools with standard loaders and savers for these files, without having the necessity to embed multiple file loading capabilities into any single program.^[13]
• AtheOS was inspired by AmigaOS, and originally intended to be a clone of AmigaOS.^[14] Syllable is a fork of AtheOS, and includes some AmigaOS and BeOS like qualities.
• The operating system of the 3DO Interactive Multiplayer bore a very strong resemblance to AmigaOS, and was developed by RJ Mical,^[15] the creator of the Amiga's Intuition user interface.^[16]

See also[link]

• Comparison of operating systems

References[link]

External links[link]

External videos
	The New Amigas (1988), The Computer Chronicles

• Official website
• Amiga History Guide
• AmigaOS Support homepage
• The Workbench Nostalgia Page – Very detailed information on all known versions of AmigaOS.
• Reference Library
• Amiga Developer Help Site
• Famous Amiga Uses

[[hy: