(Redirected from Amiga OS)
'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. It ran on the
Motorola 68k series of
32-bit microprocessors, except for AmigaOS 4 which runs 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 called
''Intuition'' and a
graphical user interface called
''Workbench''. A
command line interface is also available.
Components of AmigaOS
AmigaOS can be divided into two parts: the ''Kickstart'' (
ROM) and ''Workbench'' disks. It used to be the case that versions of Kickstart and Workbench were released together, for use with each other. From Workbench 3.5 onwards, the first release after
Commodore International stopped development, AmigaOS has become software-only, standardising on Kickstart version 3.1 in ROM.
Kickstart
The image shown by 'Amiga OS 1.x' on start-up, asking the user to insert the kickstart
disk.
'Kickstart' is the name given to the
bootstrap ROM. On the first
Amiga model, the
A1000, this was loaded from disk into a special section of memory called the writable control store (WCS), although eventually the Kickstart was embedded in a ROM chip inside the computer. The Amiga 1000 could be modified to take these chips, and subsequent Amiga models all used ROM chips.
Kickstart contains the code needed to boot the standard Amiga hardware and any
Autoconfig expansion hardware. The Kickstart also contained many stock parts of the Amiga's operating system, such as ''Exec'', ''
Intuition'' and the core of ''AmigaDOS''. 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. It can be compared to the
BIOS plus the main
Windows kernel in
IBM PCs, however it has far more functionality available at boot time — the full windowing environment, for example.
With third party
software, it is possible to have a different Kickstart loaded in RAM and to use it instead of the ROM one — for example Kickstart 1.3 may be loaded in order to run old games incompatible with Kickstart 2.0 and higher. These programs are called ''softkickers''. There are also hardware ''Kickstart switchers'' which allow you to have more than one set of Kickstart chips inside the computer, which are selectable either by a switch or a keyboard shortcut when you first turn the machine on.
MMU-enabled Amigas typically loaded a copy of kickstart from a file on disk and passed control to it at cold-boot time. Subsequent warm-boots would reuse the already-loaded copy of kickstart, reducing boot time. An Amiga 3000 could fully warm-boot in 7 seconds; cold-boot in 11 seconds.
Workbench
Main articles: Workbench (AmigaOS)
'Workbench' is the name given to both the core operating system software that is not stored in the Kickstart ROM (the "Workbench disk"), and also the native graphical
shell for the
Amiga computer. 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, the standard Amiga mouse has two buttons – the right mouse button operates the pull-down menus, with a Macintosh-style "release to select" mechanism.
A unique feature of Workbench is ''multiple screens''. These 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.
Workbench 2.0 user interface improvements
Until Workbench 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 Workbench 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.
Workbench 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.
Workbench 2.0 introduced ''
AmigaGuide'', a simple text-only
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, Workbench 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. Workbench 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.
AmigaDOS
Main articles: AmigaDOS
'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.
In AmigaOS 1.x, the AmigaDOS portion was based on a
TRIPOS port by
MetaComCo, written in
BCPL. Considerable amounts of functionality was only available to programs written in BCPL and not to developers using other languages. The third-party ''AmigaDOS Resource Project''
[1] (arp.library, formerly the ''AmigaDOS Replacement Project''
[2]) provided equivalent functionality to C programmers. ARP also provided one of the first standardized
file requesters for the Amiga.
From AmigaOS 2.x onwards, AmigaDOS was rewritten in
C and
Assembler, retaining full 1.x BCPL program compatibility, and incorporated most of ARP into the OS.
Partitions and physical drives are typically referred to as DF0: (floppy drive 0), DH0: (hard drive 0), etc. However, unlike many operating systems, outside of built-in devices like DF0: these names are totally arbitrary; for example a hard disk partition could be named HARDDISK: or A: or HD0: when it was partitioned. Volume names have the same format as device names, so a disk partition on device DH0: might have the volume name Boot:. In addition, virtual volume names could be set with the "assign" command to any directory or device; for example programs often assigned a virtual volume name to their installation directory; an example might be FooBarWriter assigning FooBar: to DH0:Productivity/FooBarWriter. This allows for easy relocation of installed programs.
Graphics
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)
[1]. Release 3.1 included some support for third party graphics cards, such as the Picasso. 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 provided their own standards, which include
MiniGL,
Warp3D, Storm
Mesa (''agl.library'') and
CyberGL.
VideoScape 3D was one of the earliest 3D rendering & animation systems, as well as
TrueSpace 3D.
Likewise, while the Amiga is well known for its ability to easily
genlock with video, it had no built in
video capture interface. Third party interfaces included
Digiview,
VHI (Video Hardware Interface) by IOSPIRIT GmbH, ''tv.library'' by Elbox Computer and ''tvcard.library'' by Guido Mersmann.
Audio
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. 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
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, 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 it had a set of rules for that language, and thus provided multilingual speech synthesis.
[4]
ARexx
Main articles: ARexx
The Amiga OS had support for the
Rexx language. It was called ARexx (short for "Amiga Rexx") and was a script language which allowed 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 was beneficial to users, instead of having to learn a new language for each application.
Programs could listen on an "ARexx port" for string messages. These messages could then be interpreted by the program in a similar fashion to a user pushing buttons. For example, an ARexx script when run in an e-mail program, could save the currently displayed email and invoke an external program which could extract and process information and then invoke a viewer program. This allowed applications to control other applications by sending data back and forth directly with memory handles instead of saving files to disk then reloading.
RAM disk
The Amiga OS 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.
The Amiga OS also has support for a fixed-capacity recoverable RAM disk, which functions as a standard RAM disk, but can maintain its contents on restart. It was commonly called RAD disk and it can function as a boot disk (with boot sector).
Technical overview
John C. Dvorak stated:
Libraries and devices
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 libraries are accessed via an indirect
jump table, which is always stored in RAM. 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'', which can be considered a
microkernel, as well as a library. It acts 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''. 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.
Handlers, AmigaDOS and filesystems
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 aren't 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. Standard assigns that are generally present in an AmigaOS system include
★ ''SYS:'', which points to the boot drive's root directory; this is the only assign created automatically by the kickstart
★ ''LIBS:'', pointing to a directory containing the system's libraries, usually SYS:Libs/
★ ''DEVS:'', pointing to a directory containing the system's devices, usually SYS:Devs/
★ ''C:'', pointing to a directory containing shell commands, usually SYS:C/
★ ''PROGDIR:'', this is not normally accessible to a user but all programs have this assigned to them behind the scenes so that they do not need to know where they have been stored on disk.
thumb
AmigaOS influence on other Operating Systems
AmigaOS has spawned at least two "clone" operating systems over time.
★ '
AROS', or ''AROS Research Operating System'' is an attempt to clone 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, originally created when the future of the Amiga looked uncertain. It provides binary compatibility with "OS-friendly" AmigaOS applications (that is, those applications which do not access any native, legacy Amiga hardware directly). A version which runs on Classic Amigas with PPC accelerator cards has been released.
★ 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.
★ '
AtheOS' was inspired by AmigaOS, and originally intended to be a clone of AmigaOS.
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.
Easter eggs
Some versions of AmigaOS included
copyright messages as
Easter eggs that required some trickery to access.
★ In version 1.x, by holding down both Shift keys and both
Alt keys and pressing the function keys F1 through F10, you could see copyright messages in the title bar. As an example, pressing F10 resulted in the message "Moral support:
Joe Pillow and the Dancing Fools". "Joe Pillow" was the name used to book a seat on a flight which was used to transport a prototype Amiga computer to a computer trade show
[3].
★ In versions 2.x and 3.0, the secret message was accessed by repeatedly selecting the "About..." option from the Workbench menu, and leaving the resulting
dialog box open. When there were enough (approximately 20) dialog boxes open at the same time, the next one had a secret message instead of the normal one. In version 3.1 the secret message was openly integrated into the "About..." dialog box.
★ The Amiga 1000 Kickstart floppy diskette master for AmigaDOS 1.0 was not erased prior to duplication, and contains the remnants of various source code and header text files on the disk.
References
1. http://uk.aminet.net/misc/antiq/ARP_13.readme
2. ARP is referred to as the AmigaDOS Replacement Project in ARP version 1.1's arpbase.h, available from ftp://ftp.funet.fi/pub/amiga/ancient/ex-amiga-s/archive/
3. Article about Joe Pillow on AmigaU http://www.amigau.com/aig/pillow.html
See also
★
AmigaOS versions
★
AROS
★
Comparison of operating systems
External links
★
Official AmigaOS 4 homepage
★
AmigaOS homepage
★
AmigaOS4 PreRelease Update 1 review
★
AmigaOS4 PreRelease Update 4 first impressions
★
AmigaOS Support homepage
★
The Workbench Nostalgia Page – Very detailed information on all known versions of AmigaOS.
★
Amiga History Guide
★
Online Emulated AmigaOS
★
AmigaScene.nl - Information about Workbench GUI concepts and other Amiga / AmigaOne related material (Dutch)
★
Reference Library
★
Development site dedicated to Amiga systems
★
On the Edge: The Spectacular Rise and Fall of Commodore (2005) Variant Press, ISBN 0-9738649-0-7. – A book describing the creation of the AmigaOS.
★
Amiga user community portal
★
Amiga Developer Help Site
★
AmigaOS4 Free Files Archive
★
Aminet – Amiga OS all versions/MorphOS Free Files Archive
★
Amiga Disassemblies including a commented disassembly of the Amiga Exec multitasker
العربية
中国
Français
Deutsch
Ελληνική
हिन्दी
Italiano
日本語
Português
Русский
Español
