Latest News

Little Things That Made Amiga Great

A deep dive into a selection of ingenious AmigaOS features.

Autumn 2020

Table of Contents

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
This was never an official name during the Commodore days, but it’s a
handy way of describing all of the components below as a whole.
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.

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:


Screenshot of proportional scroll bars

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


Screenshot of Ed in full screen mode.


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.


Screenshot of an Ed window above an AmigaShell window.


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.


Screenshot of Amiga Workbench displaying a shell window and device driver icons.


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!


An AmigaShell window displaying use of the assign command, and two spawned text editor windows editing files from an assign pointing at two different directories

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.”


An ASL File Requester listing the contents of RAM:

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.


Screenshot of Ed editing an ARexx program, with program output in an AmigaShell window below.


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.


Screenshot of AmigaShell.


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


Screenshot of AmigaGuide, displaying hypertext features such as links.

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.


Screenshot of the Amiga Installer


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


Screenshot of a RequestChoice requester asking the user to choose between Roses and Violets.

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.


Screenshot of Icon information for Deluxe Paint


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!

Read More

Show More

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button

Adblock Detected

Please consider supporting us by disabling your ad blocker