Log on
Main page Graphics Photography Audio Video Tools Web Design Documents Amiga Funny Surreal Gallery Links & Contact

The (more or less) forgotten Amiga technologies


The Amiga is the cat of computing. The bird Phoenix. The zombie that refuses to stay in the grave. It seems to have lived multiple lives and died multiple deaths. And each time, it has been taking a lot of unique design ideas and technologies with it into the grave.

On this page I shall attempt to describe some of the things I miss, hoping that some day, someone will pick it up and carry on where the Amiga left. I may also describe things that did survive, but are now so rare that I think they need to be exposed further.

Rexx



Many applications have some sort of scripting engine. This scripting engine usually resides within the host application. On the Amiga it was the other way around: The scripting language is the host, calling whatever applications it needs from the same script. This has numerous benefits:
  1. The user only has to learn one scripting language.
  2. One script can easily access multiple applications, drawing on functionality from all these.
  3. Application developers do not need to waste time implementing a scripting language. All they have to do is allowing Rexx to control their application. Thus, on the Amiga it was standard for large applications to be scriptable, because the extra development overhead was much smaller.
  4. Because the scripting language and syntax is the same no matter what program you're addressing, it becomes easier to learn to script everything.
  5. Rexx resembles english more than most other programming languages, making it easier for non-programmers to learn.
  6. Scripting a program you already know makes it easier to understand what is going on, when you already know the functionality of the program you wish to control.
I have been informed that AppleScript serves the same purpose, but I would like to confirm this by 1st hand experience before elaborating on any similiarities.

Datatypes

Every single application should not need to have an import/export filter (loader/saver) for every single fileformat on earth. This should simply be a part of the operating system, as it was on the Amiga. This way new file formats will be accessible to all applications - even old ones - as soon as the proper Datatypes module is installed.

Wide use of the IFF format

A vast majority of Amiga software reads and writes IFF files. IFF resembles XML files, but is binary and thus less prone to encoding and spelling mistakes. It also uses much less space. IFF files are typically both forwards and backwards compatible, that is, new software can read old files and vice versa. To identify any IFF file, you only need to read the first 12 bytes of the file.

Before the PC had noticeable graphics abilities, all graphics software on the Amiga used the IFF ILBM format. This way you never had to deal with conversions, as all software used the same format. More.

File type detection

The Amiga looks at the file header when deciding what filetype something is. So even if you loose the file extension, or don't even have file extensions, everything still works perfectly.

Focusing a window does not bring it on top

That's right, you had to do this yourself on the Amiga. Now this might sound like you'll have to spend a lot of extra time clicking the right windows in front of each other, but having used this GUI for over 10 years, I sincerely beleive that dealing with this yourself is actually faster than not being in control of window placement.

My favorite example is this: Imagine using a text editor in fullscreen. You need to calculate several values for the document at hand, so you bring up a little calculator. Upon clicking the document to type in the first value, the calculator now dissappears behind the text editor. This goes on everytime you need the calculator.

On Windows, you're sometimes presented with an option "Always on top", which is obviously a feature designed to overcome the above problem. I do find this approach somewhat suboptimal compared to never having these issues to begin with.

On some Unix window managers, there is a feature called "focus follows mouse" which also addresses and solves this problem, but you suddenly have to pay too much attention to the placement of the mouse, which I find equally troublesome to use. I still to this day prefer the Amiga solution, even though I've had over 10 years to get used to Windows' way of doing this.

Now I'm well aware this is also a matter of taste, but because no current operating system / window manager (except KDE) currently offers this, I find that many people are missing a chance to try something I find very efficient. And at least this yet another example of the Amiga not just copying other companies, but rather boldly rethinking fundamental usability concepts.

No modal dialogs

If you have a Windows machine, try this: Open notepad. Press Ctrl-O to bring up the file dialog. Notice that while it is open, the main notepad window is completely frozen. You cannot move or resize it.

This is called a "modal dialog", and is a design limitation that occurs because resizing and moving a window requires the attention of the application itself. On the amiga, resizing and moving a window is handled by the operating system. This is why you are never troubled by these "frozen windows" on the amiga.

Multiple assigns

This feature originates from VMS. Even though all aspects of this was never entirely well implemented on the Amiga, it allowed you to assign (create) a virtual device name (something that resembles a drive letter on a PC) that points to several destination folders. The somewhat similar feature called "Linked Folders" in Windows is less elegant, as it just shows the list of destination folders. In Unix you can achieve something similar using softlinks, but it can be troublesome administrating this, and it's less dynamic than Multiple Assigns.

HAM - Hold And Modify

Perhaps not entirely as usable today, this technology still is somewhat fascinating as it allowed 4096 colors using only 6 bits per pixel, 262144 colors using 8 bits per pixel and, in theory, full truecolor 16777216 colors using only 10 bits per pixel. Decoding this format is extremely fast if you scan the file from left to right, top down.

original
Original image, typical JPEG compression

HAM8
HAM-8 (8 bits per pixel) as seen on an Amiga 1200 or 4000

HAM6
HAM-6 (6 bits per pixel) as seen on an Amiga 500, 600, 2000 or 3000

The last image shows the maximum possible graphical quality that could be displayed on an Amiga in 1985. Maximum resolution back then was appx. 720 x 576 (PAL). This was only a year after EGA and just two years before the introduction of VGA (which was still only 256 colors at 640x480.)

This section needs to be written

Screens

The concept "virtual desktops" is attempting to mimic parts of what "screens" on the Amiga did. Unfortunately it oversees many interesting usability concepts covered by the Amiga's screens.

This still needs to be written:
  • Explain how screens were completely isolated, creating an experience of working on multiple computers rather than one machine.
  • Screens could have different resolutions and numbers of colors. Explain why this is partially relevant today.
  • Conjure up a demonstration video of screens in action, in order to demonstrate. Windows and Mac users are not used to this concept, and need a good visual presentation of this rather alien phenomena.
Found an error or a mistake?   Let me know so that I can fix it:   joachip at gmail dot com