Little Things That Made Amiga Great

A deep dive into a selection of ingenious AmigaOS features.

Autumn 2020

Introduction
Jargon buster
The Little Things
Closing words

Introduction

To most people, the Amiga is probably synonymous with the Amiga 500 and that machine was, above all, a video game: something into which you plonked 3.5" floppy disks that transported you to strange, wonderful worlds and hours of fun. To this group, the gamers, the operating system wasn't important. They probably booted Workbench 1.3 only once, took a good look at the garish blue and orange interface, and decided that enough was enough, before going back to blasting enemies in Silkworm.

And why not? The machine was great for games. There are tons of great texts about the groundbreaking audio and video capabilities of the Amiga.

This text is not one of those.

This text is about the later versions of AmigaOS produced by Commodore, from 2.0 to 3.1. While these newer versions (with majors released in 1990 and 1992, respectively) certainly carried the Amiga heritage with pride and were - mostly - backwards compatible, the advent of AmigaOS 2.0 marked a paradigm shift. The shift is best symbolized by the fact that AmigaBASIC - the ubiquitous and mandatory language of any self-respecting eighties home computer - was ditched and replaced by ARexx, a professional scripting language without any kind of graphics or sound features whatsoever.

This paradigm shift is also why so many of us who had the good fortune to come across those versions clung to the Amiga so desperately. A lot of us stuck with it well into the late nineties, years after Commodore's demise. And we were fierce: if you think Apple fanboys are annoying today, be very happy you didn't meet an Amiga zealot in 1995. Things got personal quickly. It was downright ugly.

I still think there were some grounds for our fanaticism, though.

In a time when home PC:s were single tasking DOS boxes with 8 character file names and Ataris and Macs were single tasking GUI boxes, hampering any hacker with their glaring lack of a CLI, the Amiga was a champion of both worlds: It combined the CLI and GUI, leveraging both their strengths. But there was more to it than that, something that's hard to convey in so many words.

Many a time have I come across exasperated Amiga users who, on some online forum, tries to explain the greatness of the Amiga's operating system in a few short sentences. It often, quite understandably, boils down to something akin to "It's like UNIX", which I always think is unfair to both of the systems.

Sure, it was an early multitasking system with a capable command line. At the same time, it was also a mature and coherent desktop environment with levels of user friendliness much more like today's MacOS X than any traditional UNIX. But, contrary to today's MacOS, it never mollycoddled the end user. It opened the machine up, rather than closing certain parts off.

Unlike UNIX, AmigaOS is a system designed for home computer use, lacking a lot of what makes UNIX so popular: memory protection, multi user support, source code portability and built in networking support.

They're very much alike in one aspect, though. Like UNIX, the Amiga's operating system is a collection of a lot of little strokes of genius that come together to make it bigger than the sum of its parts.

I invite you to explore this ingenuity with me. But first, let's get the terminology sorted.

Jargon buster

The Amiga's operating system has been called a lot of things by a lot of people, because it consists of many components that different types of users interacted more or less with. Let me try to clear things up a bit:

AmigaOS: Commodore didn't call the operating system as a whole "AmigaOS" until the release of version 3.1 in 1994, the year they went defunct. And even then, it was mostly printed on the box it came in - nothing in the OS calls itself AmigaOS. It's still a useful umbrella term for all of the components below.
Kickstart: This is basically the firmware of the Amiga, residing in the ROM chip. On version 2.0 and up, the ROM chip was 512 kB large and contained not only code for self tests and bootstrapping but also quite sizable portions of the other parts of AmigaOS.
AmigaDOS: This is, roughly speaking, the command line interface, device drivers, file system management and so on. It was originally based on TRIPOS, a heritage that still shows to this day. (There are newer versions of AmigaOS than 3.1, but this text will only cover the ones released by Commodore.)
Intuition: Best likened to a modern desktop compositor, Intuition handles screen updates and manages windows. The custom sound and video chips in the Amiga had mostly female names (Paula, Denise and later Alice), so I suppose Intuition is a fitting name for an abstraction layer that lets the OS interface with them.
Workbench: This is often used interchangeably with "AmigaOS" but it's really the name of just the desktop environment - which is a workbench, not a desktop: Programs are called tools, folders a called drawers and data files are called projects.

Other terminology

Requesters: Not really a major part of the OS per se, a requester is the Amiga's name for a dialog box. A "file requester" is a file selection dialog, for example. I still often use this term to describe any dialog on any platform, much to the confusion of friends and colleagues. Old habits die hard.
Devices: Devices, much like in UNIX, usually represent peripherals attached to the computer, such as storage media, printers, etc. The Amiga has a number of built-in devices that are automatically mounted, for example the internal floppy drive, DF0: and the serial and parallel ports, SER: and PAR: respectively. Other common devices are DF1:, the first external floppy drive, DH0:, the common device name given to the bootable hard drive partition, and CON:, the text console. There are also devices that can't be mounted but only be accessed using programming languages, such as timer.device which is used to interface with hardware clocks.
Volumes: Mounted devices (such as DF0, DF1, DH0) can contain a volume. In the case of DH0:, a bootable hard drive partition, the volume is fixed and is represented by the name of the partition, such as System: or Boot:. If you insert the Deluxe Paint program disk into the internal floppy drive, the current volume in device DF0: will be DPaint:.

The Little Things

The Amiga Workbench after a clean boot. To the left are device icons, for the RAM disk and hard drive partitions. The other icons represent various applications, placed on the desktop for easy access. Click the image for full resolution.

The RAM Disk

The Amiga always has a RAM disk ready for use and the device name is always RAM:. No mounting, no third party software - it just sits there, waiting. That's clever in its own right, but the really ingenious part about it is that it's dynamically allocated. That means the size of the RAM disk corresponds to the amount of free memory currently available on the system, and that it never takes up more memory than is needed to accommodate the files currently stored on it.

A RAM disk might sound esoteric today, but in the days of slow mechanical hard drives and floppy disks, it was a godsend for unpacking archives, running test compiles and storing temporary working documents.

The downside is that every time you reboot your computer, all the contents of the RAM disk are lost. Which brings us to...

The RAD Disk

RAD, which (somehow) stands for Recoverable Ram Disk, is another testament to the flexibility and ingenuity of AmigaOS. The RAD disk is a fixed size RAM disk that can not only survive reboots but also itself be booted from. It can be used as a small but extremely fast mini hard drive, or for extracting disk images to, for checking out their contents.

Proportional scroll bars

A proportional scroll bar is a scroll bar that grows and shrinks to reflect the size of the scrollable content it represents:

Click the image for full resolution.

Highlighting a feature like this might seem like a silly point to make, because today all scroll bars are proportional. Not so in the bad old days: Microsoft didn't implement them until Windows 95 and Apple, as far as I know, didn't make the move until MacOS 9 in 1999. In a time when computer mice had no scroll wheels, this was a nifty feature indeed.

The Text Editors

Above, Ed is used to edit S:Shell-Startup, the equivalent of .bashrc for AmigaShell. The editor is currently in command mode, getting ready to delete a line of text. Click the image for full resolution.

AmigaOS shipped with three different text editors: Ed, Edit and MEmacs. The latter is a port of, you guessed it, Micro Emacs, and will of course appeal to Emacs fans. The other two are sort of curiously named: Edit is a line editor mostly resembling ed on UNIX. The Amiga's Ed, on the other hand, is a full screen editor with both mouse support and an extensive command language. Amiga Ed is probably best likened with vi.

All three of them are capable and powerful editors. Both MEmacs and Ed make use of the Amiga's drop down GUI menus and feature support for macros and extensive configuration.

Ed's command mode is, as mentioned earlier, somewhat reminiscent of vi. Consider the following examples:

Change the next three occurrences of "data" to "gubbe":
3 E/data/gubbe/

Move to top of file, repeat (RP) replace of "data" with "gubbe" until end of file:
T; RP E/data/gubbe/

Move to top of file, find all occurrences of "gubbe" and insert three blank lines after every occurrence, repeat until end of file:
T; RP (F /gubbe/; 3A//)

Ed also has something called an ARexx port, which completely intentionally leads us to...

ARexx

ARexx is an improved and Amiga-ized version of IBM's REXX language. It's a capable (albeit somewhat dated, these days) general purpose scripting language with excellent functions for easy string parsing.

Through an interprocess communication interface, it can also act as "glue" between various programs with so called ARexx ports. For example, if both your text editor and Desktop Publishing package have ARexx ports, you can write a script for automatically inserting the text you've just written in the editor into the desktop publishing program by interfacing with them both using ARexx.

Ed, the editor described above, exposes its command language through its ARexx port, allowing users to create highly advanced text processing scripts.

Above, we can see Ed editing an ARexx script. Below is an AmigaShell window using Ed's own ARexx port to send instructions to Ed. I have just sent the command T; RP E /g./global./, renaming the compound variable g to the more descriptive global. Click the image for full resolution.

No CD

While AmigaDOS does have a CD command, it's usually not needed. Any command that evaluates to a valid path will automatically change the current working directory to that path:

1.System:> Work:Code/ARexx/WebServer 1.Work:Code/ARexx/WebServer> _

File Systems

OFS (Old File System) and FFS (Fast File System) are the Amiga's native file systems. Thanks to the modular and ingenious nature of the OS, the Amiga can, much like UNIX, handle an arbitrary amount of file systems. Version 3.0 of the OS shipped with CrossDOS, a utility to mount MS-DOS FAT volumes - but a lot of others have popped up as well, from third-party native replacements for FFS to ports of for example EXT2.

In the above screenshot, I've used AmigaShell to mount CF0:, a compact flash card reader. I could also have double-clicked on the device driver icon (marked in the screenshot) to mount it. I'm using the info command in AmigaShell to inspect the device. It currently contains a card formatted with the FAT32 file system. Click the image for full resolution.

Assigns

An assign is a kind of fake logical volume that can point to any path. It's great for deep directory structures. Say you've got a current programming project going in Work:Code/ARexx/WebServer. That's quite a handful to type often. By creating an assign, ASSIGN wserv: Work:Code/ARexx/WebServer, you can now access files and CD to your project directory by referring to wserv: instead.

An assign can also span several physical volumes. The Amiga's standard assign where it looks for dynamic libraries is LIBS:, pointing at the Libraries directory of the current boot volume. But what if you're writing a new such library and don't want to litter your system directory with your development versions of it while testing?

Not to worry, you can ADD to any assign:

1.System:> Assign LIBS: Work:Code/C/HTMLParseLibrary ADD

AmigaOS will now look for dynamic library files in both paths!

Above we can see examples of directory creation, output redirection and assigns in AmigaDOS. Notice how the SomeFiles: assign points at two different directories, letting Ed load files seamlessly from both of them using a single assign. Click the image for full resolution.

Libraries

Much like libraries in UNIX, this is a way of sharing common functions between different programs. Amiga libraries are always dynamically linked and yet, for some reason, there never seems to be any problems with backwards compatibility. For an end user, things just generally work.

Commodore shipped AmigaOS with libraries for everything from mathematical functions to something called ASL, used for creating file and font requesters.

ASL

The simplest way for a programmer to ask the user to pick a file or a font is through the ASL library. Using a standardized API, a requester (dialog) for saving or loading a document can be presented to the user. The dialogs have functions for pattern matching and keyboard navigation.

Sadly, it doesn't stand for "Age, Sex, Location" but rather "Amiga Standard Library."

Editing a path, adding pattern matching ("globbing") for its contents. The tilde (~) is used to exclude matches. Click the image for full resolution.

Datatypes

Datatypes are, in a sense, a bit like dynamic libraries for file formats. Instead of relying solely on the capabilities of, say, a graphics program to implement loaders for every conceivable file format, if it supports Datatypes, it can load images of any format for which a Datatype is installed in the system.

This is a great way of future proofing software, ensuring that even older programs can load and display newer image formats. When the PNG format was created in 1996, many Amiga programs made years earlier could load those images through the use of a third party PNG datatype released as freeware.

In the above screenshot, Ed is used to edit an ARexx script that utilizes the shared library for interfacing with datatypes to identify file formats. The script is used to load an appropriate file viewer for an arbitrary file given as an argument to the script - a sort of primitive plumbing, if you will. Click the image for full resolution.

ReadArgs

While AmigaOS doesn't have online documentation like UNIX man pages, it does have a standardized way for CLI programs to read arguments. This is facilitated by the ReadArgs function, designed to help programmers implement this way of reading arguments.

The ? (question mark) argument always produces a list of a command's arguments and their kind, and then awaits user input of said arguments:

1.System:> Delete ? FILE/M/A,ALL/S,QUIET/S,FORCE/S: _

So what does this mean? It means that FILE can be multiple strings (/M) and that it's a required argument (/A); ALL, QUIET and FORCE, meanwhile, are boolean flags, or switches (/S).

There are also patterns for keywords (/K), numbers (/N), and a handful more. Once you get the hang of it, it's a very helpful reference system for refreshing your memory, and the argument names tend to have curiously sensible names.

ReadArgs is refreshingly easy to implement in shell scripts, ensuring conformity to standards even for the simplest of tasks.

In the above screenshot, we can see how easy it is to add ReadArgs-style arguments to a shell script, using .key FNAME/A. Also note how easy it is to add version information to a file using $VER. Finally, we can see the script running with the ? argument, triggering AmigaDOS to list the argument for the script. Click the image for full resolution.

AmigaGuide

Click the image for full resolution.

AmigaGuide is an early hypertext format, originally used by Commodore for their official developer documentation, but delivered as a standard component of AmigaOS 3.0 and up. It's simple compared to modern HTML: it can't display inline images or play background sounds, but you can create links to arbitrary files that are then displayed separately.

It quickly became popular and before long, most freeware, shareware and public domain programs came with AmigaGuide documentation.

Installer

In the beginning, hard drive installation of programs was made using shell scripts. Seeing the havoc wreaked by such scripts, Commodore eventually created a standardized software installer. It's a brilliant little tool for selecting installation paths, creating directories, comparing file versions, copying files and modifying startup scripts.

The mighty installer. Notice the options for doing a dry run ("pretend to install") and logging the install procedure. Click the image for full resolution.

Pretty much all developers adopted this right away, including PD/Freeware authors, much to the enjoyment of end users. To this day, installers for my crappy Amiga software remains the only really meaningful things I've coded in a purely functional language: Installer scripts are written entirely in LISP.

Because of the powerful nature of having a LISP dialect and easy access to a subset of the Amiga's GUI widgets, the Installer has also been used to create simple adventure games.

Standardized File Structure

Every Amiga installation looks basically the same, especially where it really matters. We've already covered shared libraries and their residence in LIBS:. The same pattern is used for the rest of the system files: Device drivers are always in DEVS:, file system drivers and other low-level stuff in L:, AmigaDOS commands belong in C:, shell scripts (including the bootup scripts, Startup-Sequence and User-Startup) live in S:, typefaces are always in FONTS:, and so on.

Resident programs

Some programs, most of them AmigaDOS commands, can be made resident - that is, stored in memory for future use. This is useful to avoid excess disk access when performing certain tasks.

RequestChoice

Click the image for full resolution.

AmigaDOS has a simple command for asking the user a Yes/No question, called Ask. In version 3.0, Commodore introduced the commands RequestChoice, for making a multiple-choice GUI requester and RequestFile, for opening a file requester. A nice example of how integrated the GUI and CLI environments are on AmigaOS.

.info Files

A bit like with MacOS X, if you give a disk to an enthusiastic Amiga novice and ask to have a few files copied onto it, you'll probably find it littered with strange files that serve no apparent purpose. They always have the same name as another file, but end with ".info".

These are the Amiga's icon files, containing not only the actual icon image, but also a bit of metadata. For a data file, that can be what program to open the file with, which means that if you double click a picture created with, say, Deluxe Paint, then Deluxe Paint will be started and then load the picture in question. This is called the file's "default tool".

The .info files also contained positional information: the desired coordinates of the icon within its parent window. For drawer (directory) icons, it also stored the size and position of the window opened to display their contents.

Other noteworthy metadata is represented by the Tool Types, which can be described as settings or arguments for a program. For example, such a tool type can be used to control if Deluxe Paint should display the coordinates for the mouse pointer's current position.

File and icon information for Deluxe Paint. Apart from the icon image and Tool Types, there is other file metadata presented that's not stored in the icon: the file system handles the protection flags (mode bits) Script, Archived, Readable, etc. and the ability to write a comment about the file. We can also see the file size, a datestamp and the stack size (in bytes) used when running the program. Click the image for full resolution.

A system with stand-alone icon files might seem odd today, but instead of having a centralized icon storage or embedding the icons into the binaries, this method meant that tooltypes, default programs and positional information could easily be transferred between systems. It also gave the users freedom to modify or even draw new program icons, or delete them completely if they wanted to save disk space.

Several beautiful icon sets were released as third party shareware, most notably Magic Workbench.

Closing words

While certainly not a UNIX clone, the Amiga was still a great preparatory platform for tackling other operating systems further on. When I first stumbled across Linux (and other *nixes) in 1995, a lot of stuff instinctively made sense to me. I easily drew parallels to AmigaOS and was already familiar with a lot of the concepts: devices, mounting, task priorities, shell scripts and scripting languages, Emacs and much more. And as much as I enjoy UNIX today, it's when I sit down in front of an Amiga that I truly feel at home and in control.

I hope this text has given you some insight into what made the Amiga great. There are of course many more things, but these are a few that have stayed with me. Some concepts, like Datatypes, are still unique to the Amiga and would be an interesting and useful addition to an operating system even today.

And remember - Only Amiga makes it possible!

{ datagubbe }