Sunday, January 26, 2025

Running Linux on my Amiga 4000


In a recent blog post, I have described how I have been using my Amiga 4000 in 2024, including how to install the 3.1 and 3.9 AmigaOS versions from scratch and showing a few interesting use cases.

After completing this project, my Amiga 4000 experiments have continued. Recently, I have managed to run Linux on my Amiga 4000.

It turns out that making Linux work on such an old vintage machine (and somewhat uncommon hardware architecture) is challenging. There is quite a bit of information available on the Internet explaining how to do this, but not all of it is of good quality, some of it is heavily outdated and useful information is scattered.

As a result, I have decided to write a blog post about my collected knowledge and experiences.

My motivation


Some readers may probably wonder why I want to run Linux on such an old vintage machine? Aside for nostalgic reasons and fun-oriented programming projects, I have an interesting connection with both Amiga machines and Linux. Actually, my Amiga experiences eventually brought me to Linux.

IMO this is an interesting story, but feel free to skip to the next section. :-)

Commodore's demise


After Commodore's demise in 1994, the Amiga remained my main working machine for several years, but I could strongly feel the decline in the years after 1994.

Foremost, no newer Amiga models appeared. In 1995, a major Dutch Amiga magazine (Amiga X) was canceled. I was no longer receiving any software updates and I was still mostly using the same applications and games.

When the Internet and the World Wide Web became a mainstream service (in mid-1996) I realized that the PC had surpassed the Amiga in all thinkable areas. It was clear to me that the Amiga has become an obsolete platform and it was time to move on.

My transition to the PC was not abrupt. In the years before Commodore's demise I already slowly grew accustomed to using PCs -- I already knew how to use MS-DOS, because I had access to friends' PCs and PCs on my elementary school. Moreover, I also had plenty of hands on experience thanks to the KCS PowerPC board in my Amiga 500, capable of emulating an XT-based PC.

Transition to the PC as a main machine


Although I never hated MS-DOS, I always considered it a primitive working environment compared to AmigaOS. It was mainly text-oriented: a black screen with gray text. It only had a simple filesystem capable of using file names that consist of a maximum of eight characters (optionally with a three character extension). There was no multi-tasking support.

(As a sidenote: If you want a graphical desktop environment, then you can start a graphical shell, such as Windows 3.1. Windows 3.1 was a DOS application, not a full operating system. Although it was nice to use it, for playing games you generally did not need it.)

In late 1996, my parents bought a brand new PC with Windows 95 -- the successor to Windows 3.1. I was happy and a bit disappointed at the same time.

Foremost, I was very happy with all new abilities that this new PC provided me: better graphics, better sound, blockbuster games that were not available for the Amiga (most notably Wolfenstein 3D and Doom), newer productivity applications that offered more features than comparable Amiga applications and access to the Internet and the World Wide Web.

Moreover, Windows 95 overcame a number of limitations that MS-DOS (and Windows 3.1 as a shell) used to have, such as pre-emptive multi-tasking, long filenames and better graphics. From a visual perspective, a Windows 95 working environment did not feel primitive compared to AmigaOS and a hybrid MS-DOS / Windows 3.1 environment.

I was not very fond of Windows 95's stability. It used to crash quite frequently with a blue-screen of death.

Also, I considered Windows 95 a big and bloated operating system. AmigaOS only used a couple of megabytes on a hard drive installation, but for Windows 95 I needed several hundred of megabytes. From a disk space perspective, Windows 95 was a huge sacrifice. Back then our hard drive was only 2 GiB. The Windows 95 boot process was also considerably longer than the Amiga Workbench.

AmigaOS is more modular -- it can easily be stripped down in such a way that you can boot it from a single double density floppy disk. Although it is possible to create a bootable/customizable MS-DOS floppy disk, it is not possible to boot into a customized, stripped down version of Windows by conventional means.

Windows 95 was still a hybrid MS-DOS / Windows based operating system, even though it did a number of things to conceal its MS-DOS heritage. For example, it did not boot into a DOS prompt, but at startup you could still see that it was loading DOS drivers. For conventional Windows productivity application usage, you typically did not need to know about Windows 95's DOS heritage.

However, most of the games I used to play in late 1996/early 1997 were still MS-DOS based. It was quite a challenge to make some these MS-DOS games work thanks of the legacy of the segmented memory model of the Intel CPU.

For example, some games still rely on enough available conventional memory. In the default Windows 95 installation, the amount of free conventional memory was sometimes not enough. I have played quite a lot with MEMMAKER to optimize my system to have more conventional memory available. Using MEMMAKER sometimes bricked the boot process of Windows 95.

There were also quite a few annoying bugs that could brick my system. I still remember that a Windows-bundled application called Active Movie once reported that it lost its file associations. When it asked me to restore them it connected all file types to Active Movie including .EXE files rendering my system impossible to use.

In several occasions, I also learned in a painful way that certain application installers could brick the Windows registry rendering my system unusable.

Because of these issues I ended up reinstalling Windows 95 so many times that I can still remember its serial key.

First exposure to Linux: reading a magazine


At some point, my dad subscribed himself to a PC magazine: c't magazine. Because Windows 95 had an interesting stability reputation, magazines sometimes reported about alternatives. Thanks to these magazines, I learned about Linux the first time in early 1997.

When I first read about it, I could not believe that a single student named, named Linus Torvalds (at that time he was still a student at Helsinki university), could create an operating system that could measure up with Windows (developed by a multi-billion dollar company) and do certain things better.

I was not convinced that Linux was a realistic alternative to Windows at that time. Moreover, there were also many things that I did not understood about Linux. More about this later :)

Second exposure: DOS UAE


Still in early 1997, I discovered the Ultimate/Unusable/UNIX Amiga Emulator (UAE) that makes it possible to emulate an Amiga on different kinds of computer systems.

UAE is portable emulator -- it came in several variants for various operating systems. The first UAE variant that I used was DOS UAE. Because I was still fond of the Amiga, I decided to give it a try.

Getting DOS UAE to run was not an easy job. I needed to study the manual and I found out that the DOS UAE distribution also included the documentation of the core UAE distribution.

By reading the documentation of the core UAE distribution, I learned a couple of interesting things. For example, what I found interesting is that it was possible to get access to the UAE source code. The core UAE distribution was primarily developed for UNIX-like systems (at that time UNIX was a completely new word to me that I did not understand), most notably: Linux.

For non-UNIX like operating systems, UAE was forked into a number of variants, such as: DOS UAE for MS-DOS, WinUAE for Windows and MacUAE for the classic Apple Macintosh. Changes of these forks were regularly merged back into the core UAE distribution.

The core UAE manual also provides configuration instructions for all the other operating systems that it supports. Studying the UAE manual gave me my second exposure to Linux. From the documentation, I learned that there is a command-line interface, and quite a few command-line utilities, such as: cat, ls, cp, gzip and bzip2.

The manual also regularly mixed the words "Linux" and "UNIX" which gave me quite a bit of confusion -- are they the same, or different? What is their relation?

Third exposure: real hands on experience


After managing to make DOS UAE run, it took a while before I got exposed to Linux again.

My third exposure to Linux was late 1999. A cousin started to study Computer Science and he was to first to show me what working with Linux was actually like in practice. I also got the opportunity to try it out several times myself. I still remember using old versions of Red Hat Linux and Corel Linux.

Using Linux for the first time was not a scary experience to me at all, including the command-line -- I was already familiar with the AmigaOS and MS-DOS command-line interfaces, and I already knew several Linux commands from studying the DOS UAE manual.

I was quite impressed by a number of things:

  • It was quite powerful in multi-tasking -- I could easily run many programs at the same time.
  • There was a command-line interface that felt decent and was more powerful (e.g. TAB-completion) compared to the MS-DOS command-line interface in Windows 95 that was somewhat treated as a second class citizen.
  • Native Linux filesystems (e.g. Ext2) have more abilities than the FAT32 file system in Windows 95: native long filenames and a notion of ownership and permissions.
  • As a result of a more powerful filesystem and its notion of ownership, everything was more secure. In particular, the fact that the root file system is owned by the root user and an unprivileged user only has write access to files in its own home directory was a huge improvement over Windows 95, 98, Me in which the user has full access to all files, including the operating system parts.
  • Many Linux distributions are quite modular. They provide package managers allowing you to easily install, upgrade and remove additional packages. You can also relatively easily deploy a stripped down system if you want. Windows 95 also had the option to enable/disable certain pieces, but even in its most basic form it was still bloated to me.
  • Graphical desktop environments looked decent. I tried both KDE and GNOME, and although they were not perfect, their look and feel was OK to me.
  • I could easily set up a server and provide services such as email, a web server and FTP.
  • Some well known commercial applications and games became available for Linux, such as Netscape, Real Player, Word Perfect, Quake 3 arena and Unreal Tournament. I remember that Quake 3 and Unreal Tournament ran pretty well in combination with my NVIDIA Riva TNT2 card.

I also gradually learned more about how Linux was developed -- Linus Torvalds started the Linux project while he was still a student at Helsinki university, but the software packages of a Linux distribution are developed by a larger movement:

  • The component that bears the name Linux is an operating system kernel -- not a full operating system. Typically most Linux systems are augmented with packages from the GNU project, such as GNU Bash, GNU Coreutils, GNU Texinfo etc. For this reason, the GNU project's opinion is that GNU/Linux is a more accurate name for Linux distributions.
  • Linus Torvalds leads the Linux project, but he is not doing all the development by himself -- in fact, there are many developers participating in the development of the kernel and other projects.
  • The goal of Linux and the GNU projects is to provide a free version of UNIX. The ideas that these packages implement have already been implemented in non-free/commercial UNIX operating systems.
  • Other pieces of a Linux distribution are developed by other communities. For example, both the KDE and GNOME desktops are developed by their own communities.
  • Most of the software packages that Linux distributions provide are free and open source software. The source code of these packages are available, you are free to study them, modify them and distribute your own (modified) copies.

    Back in the 90s and early 00s this was considered to be quite unconventional -- most well known software packages were proprietary software products for which the source code was kept private.

Fourth exposure: installing Linux myself


Somewhere in 2000 I took the decision to install Linux on my home computer, because I was convinced that it was relevant to regularly use. It was a challenge to get started -- I tried two Linux distributions: SuSE and Red Hat. With both distributions, I ran into a driver problem -- the Ultra ATA/66 controller to which my hard drive was attached was not supported yet.

After some time, I gave up and eventually attached my hard drive to the Ultra ATA/33 controller. Later on, I managed to find a kernel patch that adds a Ultra ATA/66 driver. I had to compile a patched kernel myself from source code.

While visiting kernel.org to obtain the Linux kernel source code, I discovered another interesting property of Linux: Linux is a portable operating system that runs on many hardware architectures in addition to the PC (with an Intel x86-compatible CPU).

I even noticed that it possible to run Linux on an Amiga if you have model with a Motorola 68000-based CPU variant with an MMU: the 68020, 68030 and 68040 (non EC-variants). These CPUs were only included with the high-end Amiga models: the Amiga 2500, 3000 or 4000.

Back in the 90s, I only had an Amiga 500 that with the first generation 68000 CPU (lacking an MMU and FPU), so I knew it would not be possible to run Linux on it.

How to get started with Linux on Amiga?


Now that I finally have a Linux-capable Amiga 4000 in my possession (with a 68040 CPU with an MMU), I have decided to revisit that old idea to run Linux on the Amiga.

Getting started is a challenge. For PCs, there are plenty of Linux distributions available with plenty of advertising, but for the m68k there barely is.

I still remember from visiting old versions of the kernel homepage that there is a Linux/m68k homepage. It turns out that this website has not been updated in a very long time. Some links are broken and some functionality no longer works properly -- for example, I tried to register myself as a m68k Linux user but the registration form does not seem to work anymore.

The distributions page explains that there have been only three Linux distributions: an old unofficial port of Red Hat, Whiteline Linux/68k: an old Linux distribution for Atari STs in German and Debian. It turns out that Debian is the only actively developed distribution that still maintains an m68k port.

I know that the current versions of the Linux kernel still support m68k and that there are still people maintaining it. I have decided to a search on the Internet to discover more about using modern versions of Linux on the Amiga.

The most recent discussion I could find was in this forum post on the English Amiga Board. Apparently, the same questions that I had were raised. The forum post links to an old post from 2013 that contains basic installation instructions from a Debian developer explaining how to install a test version of Debian (pre-Wheezy) on an Amiga hard drive (e.g. compact flash card) from a PC-based Linux host.

I tried the installation instructions, and they worked. However, I also found out that this test build of Debian did not work well on my Amiga 4000. Apparently, the instructions state that 64 MiB of fast RAM is the minimum (32 MiB may work, but it was not tested).

It turns out that the instructions were right -- my Amiga 4000 only has 48 MiB fast RAM. As a consequence, the Linux kernel boots and the initialization process starts, but once udev is called (a tool that loads device drivers), the kernel gives me all kinds of memory related errors. Half way, the boot process got completely stuck.

Selecting an appropriate Debian version


After running into the kernel out of memory issues, I realized that I had to make a choice -- either obtain all the required hardware upgrades or find an older Debian version that still works within the limits of the machine that I currently have.

I have been looking at various kinds of Debian versions. What I learned by diving into the history of Debian is that an m68k port was introduced with version 2.0. It remained one of the Debian ports until version 3.1 -- its successor: Debian 4.0 dropped m68k support (or at least: I could not find any disk images in the archive). The test version in the forum post was a pre-Wheezy (7.0) release. In Debian 9.x and later versions, the m68k port returned.

First, I tried the newest Debian port that I could find (12.0). The installation disc seems to provide an installer for the Amiga, but once the boot loader has loaded the kernel, my system freezes -- I got stuck with a gray colored screen. The same thing happened to me with versions 11.x, 10.x and 9.x.

I am not sure what the reason behind this stuck gray colored screen is. Maybe the Amiga version is broken and the other m68k platforms (e.g. Atari ST, classic Apple Macintosh) still work. It could also have something to do with increasing system resource demands, but I have no idea.

Then I tried older Debian distributions. The Debian 3.0 kernel seems to have problems detecting my hard drive -- it appears to have trouble with the fact that it is bigger than 4 GiB.

Debian 3.1 actually seems to boot up fine and it did not run out of memory. As a result, I have decided to pick that version.

Creating Debian 3.1 Sarge m68k ISO images


My Amiga 4000 does not have a network card. By default, Debian prefers to download packages from the Debian package repository over the Internet.

The only means I have to connect my Amiga to another machine is a null-modem cable, which is too slow to transfer large quantities of data, such as the packages for an entire Linux installation.

As result, I need to use old fashioned CD-ROM/DVD-ROMs. I learned that Debian 3.0 is the last version that offers downloadable ISO files for the entire distribution.

Although its successor: Debian 3.1 does not offer downloadable distribution ISOs (it does offer a NETBOOT image with a minimal system), you can still generate distribution ISOs with a tool called: Jigdo. I followed the instructions described in the Debian Jigdo HOWTO by downloading the required Jigdo files and running the following commands:

$ jigdo-lite debian-31r8-m68k-binary-1.jigdo
$ jigdo-lite debian-31r8-m68k-binary-2.jigdo
$ jigdo-lite debian-31r8-i386-binary-1.jigdo
$ jigdo-lite debian-31r8-i386-binary-2.jigdo

The above commands automatically download all required packages from the appropriate Debian mirrors and generate self-contained ISO images from them.

When jigdo asks me for a Debian mirror I provided:

http://archive.kernel.org/debian-archive/debian/

For legacy Debian distributions, it turns out that the packages are no longer available anymore from their original locations.

For DVD 2, there is one package that has a different checksum: zope-quotafolder_0.1.1-1_all.deb. I ignored the error -- it is a package I do not care about and I simply removed the .tmp suffix from the generated ISO file. The resulting ISO seems to work just fine.

After generating the two DVD ISO images, I have burned them on writable DVD-ROMs. Fortunately, I still have a blu-ray drive in my desktop PC that is capable of writing DVD discs.

Installing Debian 3.1 on the Amiga


I can install Debian on my Amiga by inserting the first DVD-ROM into the DVD-ROM drive of my Amiga and booting up the installer.

By opening the following directory in the Amiga Workbench: CD0:install/tools/amiga, we can find multiple executables:


Only two of the above executables are useful to me. The StartInstall icon boots up a Linux kernel using the framebuffer driver for the Amiga's OCS/ECS/AGA video chipset. The drawback of this installer is that driver's default setting is to use a "double NTSC" mode display (this mode is similar to ordinary NTSC, but it runs at twice the refresh rate). Because I have a PAL display that does not like double NTSC mode, the display looks messed up.

I can correct that problem by copying the StartInstall script and adding the video=amifb:pal kernel parameter to instruct the kernel to use an ordinary PAL mode at boot time.

There is another installer icon named: StartInstall_CV3D. This script instructs the kernel to use the Cybervision 64/3D frame buffer driver. I have decided to pick this installer for my installation, since I have that RTG card installed in my machine.

Installing Debian is relatively straight forward. I left some free space (+/- 5 GiB of the 32 GiB) at the end of my Amiga hard drive that already contains a Workbench 3.1 installation. I can use that free space for my Linux installation and store it next to my AmigaOS installation.

When the installer reaches the partitioning step, I have picked the "manual partitioning" option and added the following two partitions:

  • A swap partition of 128 MiB
  • The root file system partition (/) using the remaining available disk space. The root partition uses the Ext2 file system.

Installing packages takes a quite an amount of time on my Amiga -- uncompressing and installing packages is nowhere as fast as a modern machine. I did not exactly measure the full installation time, but it took several hours before the installation of the base system was completed.

Moreover, the installer works but it is quite slow and unresponsive. It seems that it is written in Perl and interpreting Perl scripts on my Amiga is significantly slower than running compiled executables that have been implemented in C. Sometimes it feels that the process is completely stuck, but by running ps in a second terminal, I discovered that the machine is actually doing a lot of hard work.

Configuring the boot process


The installer does not take care of configuring the Linux boot process on the Amiga. You need to set that up yourself.

Booting a Linux kernel is an interesting process. Although the kernel is the operating system component that interacts with the hardware and controls the system, the Linux kernel is not magically there in memory yet when you power up a computer -- it first needs to be loaded from external media into memory and then it needs to be started so that it can take control of the machine. A boot loader is an application that is typically responsible for this process.

There are various ways to load and start the Linux kernel. As a result, there are also various flavours of boot loaders.

(As a sidenote: I know that older versions of the Linux kernel (2.6.x and lower) on the x86 architecture can boot without a boot loader, as described in the Bootdisk HOWTO. Instead of using a boot loader, you can also write a kernel image to the Master Boot Record (MBR) of a disk drive.

The kernel image contains some bootstrap code to put the CPU in protected mode and starting the kernel. This feature is not used very frequently because it makes updating the kernel hard.)

Nowadays on PCs, it is common to load the Linux kernel as quickly as possible after booting up the machine (a process which I will call cold booting). LILO used to be amongst the first boot loaders to accommodate that -- it could load a selection of kernels from the hard drive with pre-configured parameters.

LILO was eventually succeeded by GRUB (one of its improvements is that it does not require an update when a new kernel image becomes available) and systemd-boot (meant for UEFI-based systems).

In the MS-DOS era, it was also possible to start a Linux kernel after having already booted into MS-DOS. Since MS-DOS is a relatively primitive operating system with no memory protection, this was easily possible -- LOADLIN is a DOS program that can load a kernel from an MS-DOS partition into memory and then start the kernel so that it can take over the system. Booting a kernel from a running existing operating system is a process that I will call warm booting.

On the Amiga, it turns out that warm booting Linux from AmigaOS is the preferred practice -- amiboot is an Amiga program that can load a Linux kernel into memory from AmigaOS and then start the Linux kernel so that it can take control of the system.

(As a sidenote: I also found traces of a package named: amiga-lilo. I guess the purpose of this package is to facilitate cold booting on the Amiga.

In theory, it should also be possible to mostly bypass the Amiga operating system by creating a custom boot block on a partition. This custom boot block starts a boot loader program. I guess the cold boot approach on the Amiga was never popular enough).

To set up the boot process for the Debian installation on my Amiga, I executed the following steps:

  • I have created a directory on my first AmigaOS partition: DH0:boot-debian and added a Workbench icon for the directory.
  • I have copied the amiboot program and supporting documentation files from the following folder of the first Debian installation DVD: CD0:install/tools/amiga to DH0:boot-debian.
  • I have copied the Linux kernel for the Amiga from the following location: CD0:install/kernels/vmlinuz-2.4.27-amiga to DH0:boot-debian
  • I have renamed the StartInstall_#? files to Start_#? because these scripts are no longer about starting the installer, but starting my Linux system.
  • I have modified the amiboot instruction of the Start script with the following parameters:
    amiboot-5.6 -d -k vmlinuz-2.4.27-amiga root=/dev/hda7 video=amifb:pal video=virge:off
        

    The above command invokes amiboot to load the Linux kernel from an image in the same directory with the following parameters:

    • The root partition points to the seventh partition of the hard-drive: /dev/hda7.
    • I have configured the Amiga framebuffer to start in PAL mode, rather than "double NTSC" which is the default. Double NTSC mode messes up my display.
    • I have disabled the S3 Virge driver (the video chipset on my Cybergraphics 64/3D card), because it gives a division by zero exception in the kernel when I boot it.
  • I have modified the amiboot instruction of the Start_CV3D script with mostly the same adjustments:
    amiboot-5.6 -d -k vmlinuz-2.4.27-amiga root=/dev/hda7 video=virge:640x480-8
      

    The only difference is that the above command instructs the kernel to use my Cybervision 64/3D card using the 640x480 resolution and an 8-bit color depth.
  • I did a backdrop of the Start and Start_CV3D icons (by selecting the icons, and then picking 'Icon -> Leave out' in the menu) so that I can boot up Linux conveniently from the desktop:


Clicking on the Start icon gives me the following boot up screen:


Completing the Debian installation


After booting up my Linux installation, the Debian installer resumes the installation process. It asks me to configure my timezone, hostname, the package manager (by scanning the two installation DVDs), an unprivileged user account and so on. This is generally a straight forward, but slow process (due to the fact that the installer is a Perl script).

Some use cases


After completing the installation process described earlier, my Amiga-based Linux system is ready to be used. I tried a number of use cases.

Controlling the frame buffer


Previously, I have shown that it is possible to change the settings of the framebuffer at boot time with the video= kernel parameter (such as PAL/NTSC mode, color depth and resolutions). It is also possible to switch these settings at run-time by using the fbset utility.

fbset can be installed as follows:

$ apt-get install fbset

To be able to properly use fbset you need video configurations in the /etc/fb.modes configuration file. It turns out that the default installation does not provide the settings that you need to work with the Amiga's OCS/ECS/AGA video chipsets.

Fortunately, by looking up the corresponding source code, I could find a modes file that provides the settings that I need: fb.modes.PAL. I have replaced the default fb.modes file with this file.

By installing this configuration file, I can switch to interlaced mode by running:

$ fbset pal-lace


As shown in the picture above, running the above command doubles the amount of scanlines on my screen (at the expense of a flickering screen).

I can switch back to normal PAL mode by running:

$ fbset pal

When using my Cybervision 64/3D card, I also want to have the ability to switch resolutions and color modes at runtime. I could not find a preconfigured fb.modes file for my RTG card to do that.

To obtain the required framebuffer configuration settings, I followed a silly procedure. I ended up booting the kernel in a specific video mode, and then saving the framebuffer settings by running:

$ fbset >> /etc/fb.modes

and then rebooting and switching screen modes until all available modes have been covered. I repeated the procedure for the following kernel video parameters:

virge:640x480-8
virge:800x600-8
virge:1024x768-8
virge:1280x1024-8
virge:1600x1200-8
virge:640x480-16
virge:800x600-16
virge:1024x768-16

When capturing the configuration the configuration name does not take the color depth into account. For example, when capturing the 640x480-8 configuration, fbset generates a mode that is named 640x480-50 in which the -50 component refers to the refresh rate.

I ended up changing the configuration names to use a naming convention that consists of <width>x<height>x<colorDepth> which is similar to the kernel video parameters shown earlier.

After capturing all screen modes, I can switch between them at runtime. For example, the following command switches to a 1024x768 using an 8-bit color depth:

$ fbset 1024x768-8


As can be seen in the picture above, the resolution has changed from 640x480 to 1024x768.

The X Window System


After playing around with the framebuffer. I have also decided to give the X Window System a try.

Since X11 applications are quite resource demanding, I have decided to do a very minimal X Window System installation. Based on instructions from the following page (they were outdated, so I looked for the equivalent set of packages in Debian 3.1), I installed the following set of packages to produce a very small X11 installation:

$ apt-get install xfonts-base xfree86-common xlibs xserver-common \
    xserver-xfree86 xbase-clients

While installing the above packages, the xserver-xfree86 maintainer script asks me to provide a number of configuration settings. I used the following values:

  • Select desired X server driver: fbdev
  • Use kernel framebuffer device interface? yes
  • XKB rule to use: xfree86
  • Select keyboard model: amiga
  • Keyboard layout: us
  • Mouse device: /dev/amigamouse
  • Is your monitor an LCD device? No
  • Method for selecting your monitor characteristics? simple
  • Monitor size: 17 inch
  • Video mode to use: 640x480
  • Default color depth in bits: 8

After trying to start the X Window System, I have noticed that it crashes on startup while loading certain modules. I fixed the startup procedure by opening the /etc/X11/XF86Config-4 file in a text editor and disabling the problematic modules.

OpenGL is not required, and probably will not work on the Amiga, because of the lack of system resources. As a result, I can disable the following modules by commenting them out:

# Load "GLcore"
# Load "dri"
# Load "glx"

The following module can also be disabled. It is not needed because it is used to make a BIOS interrupt call on 80x86 systems:

# Load "int10"

I also figured out that the keyboard does not work properly with XKB and needs to be disabled. I can disable XKB altogether by commenting out the following options:

# Option "XkbRules" ...
# Option "XkbModel" ...
# Option "XkbLayout" ...

And adding the following property:

Option "XkbDisable"

I have also installed TWM as window manager and xterm as a terminal application:

$ apt-get install twm xterm

I can start the X Window System from the terminal by running:

$ startx

Resulting in the following graphical environment:


The X Window System works fine in combination with my Cybervision 64/3D card. The only thing that remains a mystery to me is whether it is possible to use the X Window System in combination with the AGA chipset -- it always results in a segmentation fault in the startup procedure.

Using the GoTek floppy emulator


Similar to Linux on PCs, Linux on the Amiga can also work with floppy disks and a variety of file systems. For example, it knows how to read and write to floppy disks using Amiga's Fast File System and MS-DOS' FAT file system.

As I already explained in previous blog posts, I have a GoTek floppy emulator as an additional floppy drive. The GoTek floppy emulator uses disk images from a USB memory stick rather than real floppy disks. The GoTek drive can be attached to the external floppy port and is mapped to the DF2: drive.

To use the DF2: drive in Linux, I need to create additional device files (/dev/fd2 etc.). This can be done by running the following commands:

$ cd /dev
$ ./MAKEDEV fd2

I am using the following entries in the /etc/fstab file to mount floppy drives:

/dev/fd0    /media/floppy0  auto    rw,user,noauto    0 0
/dev/fd1    /media/floppy1  auto    rw,user,noauto    0 0
/dev/fd2    /media/floppy2  auto    rw,user,noauto    0 0

Of course, I must also make sure that the mount point directories exist. I can create them by running:

$ mkdir /media/floppy0
$ mkdir /media/floppy1
$ mkdir /media/floppy2

For example, I can mount a virtual Amiga floppy "inserted" into the GoTek drive, such as the Workbench disk, by running the following command:

$ mount /media/flopppy2

Then I can get access to the floppy disk's contents by opening the /media/floppy2 directory.

Setting up a terminal connection between the Amiga and PC with a null-modem cable


Similar to connecting my Amiga 4000 (running AmigaOS) to my Linux PC, I can also set up a terminal connection between my Linux PC and Amiga Linux installation with a null-modem cable.

For example, I can turn my desktop PC (running NixOS) into a terminal server by running the following command as root user:

$ agetty --flow-control ttyUSB0 19200

The above command exposes a terminal session over the USB to RS232 port, using hardware (RTS/CTS) flow control and a baud rate of 19200 bits per second.

I can connect with minicom from my Amiga 4000 to remotely administer my desktop PC and exchange files using the ZMODEM protocol.

I can also do the opposite. With the following command (as root user) on my Amiga 4000 Linux installation, I can turn it into a terminal server:

$ getty -h 19200 /dev/ttyS0

Then I can use minicom from my desktop PC to connect to the Amiga:

$ minicom -b 19200 -D /dev/ttyUSB0

The result of this linking up process can be seen in this picture:


As may be observed, my laptop on the right uses minicom to open up a shell session on my Amiga 4000 machine.

Connecting to the Internet


Another nice property of Linux is that has builtin support for the Internet protocol stack. (As a sidenote: Internet connectivity is also possible on AmigaOS, but you need to install separate software for that).

In addition to a terminal connection, I can also set up a PPP link between my Amiga and desktop PC over the null-modem cable so that I can use the Internet protocols to connect between them. My desktop PC is supposed to have 192.168.1.1 as an IP address and my Amiga 4000 192.168.1.2. I took inspiration from the PPP HOWTO, which is a bit outdated.

First, I need to set up a link end point on my Amiga 4000, with the following command:

$ pppd -detach crtscts lock noauth defaultroute 192.168.1.2:192.168.1.1 /dev/ttyS0 19200

Then I can configure my desktop PC (which has a connection to the Internet by using an ethernet card):

$ pppd -detach crtscts lock noauth proxyarp 192.168.1.1:192.168.1.2 /dev/ttyUSB0 19200

Then I should be able to ping my desktop PC from the Amiga by running:

$ ping 192.168.1.1

With some additional steps, I can also connect my Amiga 4000 to the Internet by using my desktop PC as a gateway.

First, I need to enable IP forwarding on my desktop PC:

echo 1 > /proc/sys/net/ipv4/ip_forward

Then, on my desktop PC, I can enable network address translation (NAT) as follows:

INTERNAL_INTERFACE_ID="ppp0"
EXTERNAL_INTERFACE_ID="enp6s0"

iptables -t nat -A POSTROUTING -o $EXTERNAL_INTERFACE_ID -j MASQUERADE
iptables -A FORWARD -i $EXTERNAL_INTERFACE_ID -o $INTERNAL_INTERFACE_ID -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $INTERNAL_INTERFACE_ID -o $EXTERNAL_INTERFACE_ID -j ACCEPT

In the above example: ppp0 refers to the PPP link interface and enp6s0 to the ethernet interface that is connected to the Internet.

In order to resolve domain names on the Amiga 4000, I need to copy the nameserver settings from the /etc/resolv.conf file of the desktop PC to the Amiga 4000.

Then I can, for example, use Lynx to visit my homepage:


Visiting Internet sites is not particularly fast over a null-modem cable (with a baud rate of 19200 bits per second) but it is possible. :)

Exchanging files


Sometimes it is also required to exchange files from and to my Linux installation on the Amiga 4000, such as software packages from the Internet. There are various ways to accomplish that.

Exchanging files with the memory card on my Linux PC


In addition to using a null-modem cable, which is slow because it has a baud rate of 19200 bits per second, I can also simply just take the Compact Flash card from the CF2IDE device and put it in the card reader of my PC.

An Ext2 partition on the Amiga is no different than an Ext2 partition on the PC. The only challenge is that we need to address it somehow -- Linux on my PC is not able to understand an RDB (Rigid Disk Block) partition table (the partitioning format that the Amiga uses) -- PCs use a different partitioning format.

There is a way to cope with this. If in a file (e.g. a hard disk image or device file referring to a hard drive) we know the offset and length of a partition, then we can use a loopback device to mount it.

GNU Parted is capable of reading an RDB partition table:

parted /dev/sdb
unit B
print
Model: Generic- USB3.0 CRW-CF/MD (scsi)
Disk /dev/sdb: 32019111936B
Sector size (logical/physical): 512B/512B
Partition Table: amiga
Disk Flags: 

Number  Start         End           Size          File system     Name  Flags
 1      1806336B      2149539839B   2147733504B   asfs            DH0   boot
 2      2149539840B   4297273343B   2147733504B   asfs            DH1
 3      4297273344B   6445006847B   2147733504B   asfs            DH2
 4      6445006848B   15090130943B  8645124096B   asfs            DH3
 5      15090130944B  25891117055B  10800986112B  asfs            DH4
 6      25891117056B  26019366911B  128249856B    linux-swap(v1)  DH5
 7      26019366912B  32019111935B  5999745024B   ext2            DH6
quit

In the above code fragment, I started GNU parted to read the partition table of my Amiga drive (/dev/sdb), switched the units to bytes, and then I printed the partition table. The last partition entry (Number: 7) refers to the Linux Ext2 partition on my Amiga 4000.

I can use the start offset and size fields in the above table to configure a loopback device (/dev/loop0) referring to my Amiga drive's Linux partition from my Amiga drive's compact flash card:

$ losetup --offset 26019366912 --sizelimit 5999745024 /dev/loop0 /dev/sdb

Then I can mount the partition (through the loopback device file) to a directory:

$ mount /dev/loop0 /mnt/amiga-linux-partition

And then I can exchange files to the Amiga's Linux partition by visiting /mnt/amiga-linux-partition.

When the work is done, I must unmount the partition and detach the loopback device:

$ umount /mnt/amiga-linux-partition
$ losetup -d /dev/loop0

Exchanging files between the AmigaOS and Linux operating systems


I have two operating systems running on my Amiga 4000. Another relevant use case is the ability to exchange files between the AmigaOS and Linux operating systems on the Amiga 4000.

As I already explained, the Linux kernel supports reading and writing Amiga Fast File system partitions. For example, if one of my hard-drive partitions would have been formatted using Amiga's Fast File system, then I can simply mount it at boot time by adding the following entry to /etc/fstab:

/dev/hda1    /mnt/harddisk    affs    defaults    0 0

Unfortunately, because of my hard-drive size (which is much bigger than 4 GiB) I have picked Smart Filesystem (SFS) over Amiga's Fast Filesystem for my Amiga partitions. It seems that a Linux kernel module for SFS has been developed, but it was never accepted into the upstream Linux kernel and its development seems to have stopped a long time ago. As a result, there is no means for me to read my AmigaOS partitions from Linux.

Fortunately, I can do the opposite -- it is possible to read and write to a Linux Ext2 partition from AmigaOS: there is an ext2fs filesystem handler for AmigaOS.

Installing it consists of three steps:

  • We must extract the contents of the lha file into a temp directory
  • Copy the AmigaOS/Ext2FileSystem handler to L:
  • Create a DEVS:DOSDrivers entry specifying mount settings of our Linux Ext2 partition.

Writing the DOSDriver file for the Ext2 partition is tricky -- the ext2fs package suggests to use a tool: GiggleDisk to automatically generate a mount list. This tool can be used to mostly derive the configuration properties from the RDB partition table.

I ran into an annoying problem with GiggleDisk -- when I run it, it stops with an "Invalid RDB header" error. Some experimentation revealed that it is the Ext2 and swap partitions that it does not like. If I remove the Linux partitions, then GiggleDisk is able to generate a mount list for all the Amiga partitions.

As a consequence, my recommendation is to run GiggleDisk before you generate the Linux partitions and keep the corresponding mount list stored for future use. Before installing Linux you need to install GiggleDisk and run the following command:

GiggleDisk DEVICE scsi.device UNIT 0 TO DH0:T

The above command examines the first drive on the SCSI bus and writes the mount list entries to following directory: DH0:T.

For example, for my first hard drive partition, GiggleDisk generated the following DOSDriver file (DH0:T/DH0):

/*
** DosDriver automatically created by GiggleDisk
**
** GiggleDisk (c)2005 Guido Mersmann
**
*/

FileSystem       = df2:l/SmartFilesystem
Device           = scsi.device
Unit             = 0
BlockSize        = 512
Surfaces         = 7
SectorsPerBlock  = 2
BlocksPerTrack   = 252
Reserved         = 2
PreAlloc         = 0
Interleave       = 0
MaxTransfer      = 0x0001FE00
Mask             = 0x7FFFFFFE
LowCyl           = 2
HighCyl          = 2412
Buffers          = 80
BufMemType       = 0
StackSize        = 16384
Priority         = 0
GlobVec          = -1
DosType          = 0x43465300
Activate         = 1
Mount            = 1
/* Bootable      = TRUE */

Fortunately, most of the properties of the mount list entries are the same for all partitions. The only differences we have between the partitions are:

  • The FileSystem and DosType fields.
  • The location of the partition on the hard drive, defined by the LowCyl and HighCyl properties.

By studying the documentation of the ext2fs package, using the information of GNU Parted (shown in the previous section) and some math, I can derive the configuration settings for the Ext2 partition from the existing partitions' configurations.

First, I need to make a copy of the DH0 file, naming it EXT6 -- EXT6: means the Ext2 filesystem device equivalent for the partition DH6:. Then I change the following two fields so that the operating system knows that it needs to be treated as an Ext2 file system partition:

FileSystem = DH0:L/Ext2FileSystem
DosType = 0x45585432

Then we must compute the LowCyl and HighCyl values. In the previous section, we have already requested the offsets (in bytes) of all partitions by running GNU Parted. We can use these offsets to derive the LowCyl and HighCyl properties by doing some math.

First, I must compute the amount of blocks per cylinder. This value can be computed with the following formula:

blocksPerCylinder = heads * sectors

We can map the variables in the above formula to properties shown in the previous mount entry:

  • heads corresponds to Surfaces
  • sectors corresponds to BlocksPerTrack

In our situation this results in:

blocksPerCylinder = 7 * 252 = 1764

From the number of blocks per cylinder I can derive the amount of bytes per cylinder with the following formula:

bytesPerCylinder = blocksPerCylinder * BlockSize

By filling in the BlockSize value in the config file this results in:

bytesPerCylinder = 1764 * 512 = 903168

With the above value I can derive the low cylinder with the following formula:

LowCyl = Start / bytesPerCylinder

By filling in the start offset (in bytes) of the Linux partition from the GNU Parted output, this results in:

LowCyl = 26019366912 / 903168 = 28809

I can apply the same value to also compute the size in cylinders:

sizeInCylinders = Size / bytesPerCylinder 
  = 5999745024 / 903168
  = 6643

The high cylinder value can be computed as follows:

HighCyl = LowCyl + sizeInCylinders - 1
  = 28809 + 6643 - 1
  = 35451

(As a sidenote: we need to subtract 1 because the start cylinder is taken into account with the size)

By updating the mount file with the above LowCyl and HighCyl values, I have filled in all required configuration properties.

Unfortunately, I learned that providing the correct settings is not enough. There is another small problem -- it turns out that the Ext2 file system driver is also constrained by the SCSI driver's 4 GiB limitation. I learned from the ext2fs README that it is possible to escape that limit by installing a program called: td64patch. td64patch is a program that needs to run in the background.

Although this program does the job, I do not like to start it as part of the Startup-Sequence because I do not permanently need it. As an alternative solution, I created a mount script (MountEXT6):

Run C:td64patch DEVICE scsi.device
C:Mount DH0:Storage/DOSDrivers/EXT6

The above script does two things:

  • It starts the td64patch program in the background for bypassing the limits of AmigaOS' scsi.device driver
  • Then it mounts the EXT6: drive using the mount configuration that we have created earlier.

I also created an icon for the above script, using C:IconX as a default tool and did a backdrop so that I can conveniently start it from the desktop when I need it:


The screenshot above shows the result of clicking on the MountEXT6 icon. The EXT6: drive gets mounted and I can explore its contents in the Amiga Workbench.

Running Linux on Amiga in FS-UAE


Another thing I was curious about is whether I could run Linux for Amiga in FS-UAE, an Amiga emulator.

Having the ability to use an emulator is useful for experimentation. Moreover, UAE does not use cycle exact emulation for 68020 processors and later models. Instead, it emulates as fast as possible. As a result, on my modern desktop PC an emulated Amiga 4000 runs much faster than my real Amiga 4000. For experimentation with Linux, e.g. building packages from source code, this greater speed is quite convenient.

It turns out that running Linux in FS-UAE is actually possible, but we need to enable certain settings for that.

The biggest impediment to run Linux in a UAE is how UAE normally "emulates" hard-drives and CD-ROM drives. In fact, FS-UAE does not really emulate them, but it provides its own AmigaOS replacement drivers: uaehf.device and uaescsi.device that interface with the host filesystem/device drivers. Linux does not work with AmigaOS device drivers -- once the kernel is started, it wants to take control of the hardware itself.

As an alternative, it is also possible to emulate IDE controllers. When IDE emulation is enabled, AmigaOS uses its own scsi.device driver to interact with the storage devices. Linux can control the IDE controllers by itself.

For a hard drive, we must create a hard file (mounting a directory from host file system relies on using uaehf.device) and specify an IDE controller. We can do that by adding the following properties to an FS-UAE configuration file:

hard_drive_0 = mydrive.hdf
hard_drive_0_controller = ide
hard_drive_0_type = rdb

In the above code fragment, hard drive 0 uses mydrive.hdf as a hardfile, use an IDE controller named: ide and the type property states that the hard file contains an RDB partition table, not a single partition.

The last property is only needed when the hard file is still empty. After the partitioning is done, FS-UAE is able to detect the hard file type automatically.

For the CD-ROM drive, we also need to enable an IDE controller:

cdrom_drive_0_controller = ide1

After configuring the IDE controllers, we should be able to install Debian in FS-UAE on the hard-drive image.

I have noticed that emulating an IDE controller in combination with an emulated CD-ROM is not perfect. Sometimes I/O access becomes very slow in AmigaOS.

While installing Debian from the DVD-ROMs, I have noticed that during the package installation process I sometimes run into read errors.

Fortunately, I can cope with that by executing a shell session from the Debian installer and remounting the CD-ROM drive:

umount /cdrom
# Eject the CD-ROM and reinsert it again with FS-UAE (F12)
mount /dev/cdroms/cdrom0 /cdrom
exit

And then resuming the installation where I left off. After a couple of tries, the installation should succeed.

The result is that I can run Linux conveniently in FS-UAE:


The above screenshot shows my NixOS Linux system (running on an x64 CPU) running FS-UAE that runs Debian Linux for m68k. Isn't it cool?

Similar to the memory card of my Amiga 500's SCSI2SD device, I can also put the Compact Flash card of my Amiga 4000 in the card reader of my PC and then run its Linux installation in FS-UAE.

To do that I need to change the hard drive setting to use the device file that corresponds to my card reader:

hard_drive_0 = /dev/sdb

In the above code fragment: /dev/sdb corresponds to the device file representing the card reader. I also need to make sure that the device file is accessible by an unprivileged user by giving it public permissions. I need to run the following command as a root user to do that:

$ chmod 666 /dev/sdb

Conclusion


In this blog post, I have described how I have been using Linux on my Amiga 4000. I hope this information can be of use to anyone who is planning to run Linux on their Amigas. Furthermore, I hope that the existing documentation on the Linux/m68k homepage gets updated at some point. May be the information in this blog post can help with that.

Debian 3.1 works decently for me, but everything is much slower compared to a PC. This is not really surprising if you run an operating system (last updated in 2008) on a CPU from the early 90s that still runs at a 25 MHz clock speed :).

Most command-line utilities (that have been written in C) work at an acceptable speed, but applications such as Perl scripts or the X Window System is generally quite slow.

I have also noticed that the amount of system resources that the Linux kernel needs grows with each newer version. Even for the Amiga, an obsolete hardware platform, it is possible to address these higher system demands by, for example, buying an accelerator card with a substantially faster CPU (e.g. a 68060 @ 100 MHz) and substantially more RAM (e.g. 512 MiB of fast RAM).

Although an accelerator card may give my Amiga a huge performance boost, I do not want to implement such big upgrades -- the reason why I like to tinker with my Amiga is because it is a limited machine. I use it for nostalgic and creative reasons, such as developing software that fit within the boundaries of the machine.

I did buy a modest upgrade to my Amiga 4000 machine though -- my Fastlane Z3 expansion card still has room for an additional 32 MiB of fast RAM. I have decided to buy an extra 16 MiB increasing the amount of my Amiga's fast RAM from 48 MiB to 64 MiB.

I highly appreciate Debian's efforts to maintain uncommon ports of Linux and the GNU system. From a commercial point of view, I believe there is little motivation to keep the m68k port alive, but it is still good to see that a community-driven project, such as Debian, still does the effort.

I also got motivated to see if I can run some of my own software under Linux on the Amiga 4000. An obvious candidate would be the packages from my IFF file format experiments project. I need to find more spare time to see if I can actually do it. :)

Another thing that I expect people (who know me a bit better from my Linux background) to ask me is when I will deliver a port of the Nix package manager and the Linux distribution that is built around it: NixOS to m68k-linux. I have not made any plans yet, but you will never know -- these tools are instrumental in my personal software construction process and I have already done an interesting Amiga crossover with these tools in the past. :)

Monday, December 30, 2024

Blog reflection over 2024

Not much to report this year. I have only written one article: Using a Commodore Amiga 4000 in 2024.

Next year, I hope to find back my usual cadence. I am not out of ideas and there is definitely going to be more to report about.

The last thing I would like to say is:

HAPPY NEW YEAR!!!!

Sunday, December 29, 2024

Using a Commodore Amiga 4000 in 2024


Some time ago, I have written a couple of blog posts about using my old Commodore computers that I grew up with: the Commodore 64, 128, and Amiga 500 in modern times.

At the time these machines were bought by my parents (in the late 80s and early 90s), Commodore still used to be a respected and mainstream computer brand. Times were quite exciting back then -- I had many relatives that used to own a Commodore computer. We also used to regularly visit local computer clubs in which we used to exchange ideas and software.

An uncle of mine was always very progressive with new computer models -- he was always the first in the family to make the switch to a new computer model. For example, when we all still used Commodore 64 and 128s, he was the first to make the switch to the Amiga 500 when it came out. He was also the only relative to buy an Amiga 4000 -- the most powerful Amiga model. After Commodore's demise, he was the first to switch to the PC.

I still remember that I was always excited to visit him in the Amiga days. The Amiga 4000 was much more advanced than the Amiga 500 (that we used to own at that time) and I was very impressed by its improved graphics and speed capabilities.

Contrary to the 64, 128 and Amiga 500, I have never worked with the Amiga 4000 much, aside from a couple of visits to my uncle and the Home Computer museum in Helmond.

Almost three years I ago, I ran into the opportunity of buying a second hand Amiga 4000.

Although I am quite happy to have a good working Amiga 4000 in my possession, there were a couple of subtle annoyances:

  • The machine has quite a few hardware and software modifications. As a result, when I boot up the machine, it loads a heavily modified AmigaOS 3.9 Workbench with many additions and customizations, such as a high resolution screen with large high color icons.

    Although the installation works fine and provides useful features, this Workbench installation barely resembles the desktop environment I was used to in the 90s.
  • I want control over the machine's hard-drive's software configuration -- I want to exactly know how to reproduce a machine's configuration from scratch, in case all data gets lost.

    As a consequence, I must exactly know which applications and dependencies I need to install, where these software packages came from, and what kind of configuration changes I want to make. I have such procedures documented for myself.

    Doing this for my Amiga 4000, turned out to be somewhat a challenge -- some floppy disks, such as driver disks, and instruction manuals were lost by the previous owner.
  • I only want to install the software packages that I know. As a consequence, I want to get rid of the software that I do not use or care about.

In the last few weeks, I have managed to perform clean AmigaOS 3.1 and AmigaOS 3.9 installations on my Amiga 4000 -- I have identified all my required software packages, found the ones that were missing, and documented the installation procedures.

In this blog post, I will explain the properties of my Amiga 4000 and report about my findings.

Some interesting properties of the Amiga 4000


As I have already explained, the Amiga 4000 was the most advanced Amiga model produced by Commodore. It was released in mid-1992, but it took a little while longer before they became available on the market in my home country, the Netherlands.

Similar to the earlier Amiga models, such as the Amiga 500, it contains custom chips that give the Amiga all kinds of nice multimedia capabilities, such as a good working sound chip (Paula), a video beam-aligned co-processor: the copper, capable of generating all kinds of interesting visual effects, and the blitter, a co-processor capable of quickly copying data chunks (such as graphics surfaces).

The Amiga 4000 has the following improvements over its predecessor models:

  • A more advanced and much faster CPU: a 68040 clocked at 25 MHz with an FPU (floating point unit) and a MMU (memory management unit). In contrast, the Amiga 500 has a 68000 CPU clocked at 7 MHz, without an FPU and MMU.

    (As a sidenote: Some time later, Commodore also introduced a lower priced Amiga 4000 model containing the 68EC030 CPU. Its capabilities are similar to the 68030 CPU that can also be found in the Amiga 3000, but the EC variant is cheaper, because it removes the MMU and FPU.)
  • More RAM. By default, the Amiga 4000 came with 2 MiB chip RAM and 4 MiB fast RAM. The amount of fast RAM can be upgraded to 16 MiB. With a Zorro III expansion card, fast RAM can be extended even further to, for example, 64, 128, 256 MiB and even larger quantities.
  • AGA graphics chipset. The AGA chipset is the successor to the previous Amigas' OCS and ECS graphics chipsets -- it expands the amount of color registers from 32 to 256, and increases the size of the red, green and blue color components from 4 bits (providing a set of 4096 possible colors) to 8 bits (providing a set of approximately 16.8 million possible colors).

    The OCS and ECS graphics chipsets also offer HAM-6 screen modes, that make it possible to use view photo realistic images using all 4096 colors by using only 6 bits per pixel (albeit with some compression limitations). The AGA chipset offers an additional 8-bits HAM mode capable of displaying 262144 colors on one screen, with some compression limitations.
  • A high-density floppy drive. High density floppies have twice the amount of storage capacity of double density disks (1.72 MiB rather than 880 KiB).
  • A new operating system Kickstart and Workbench (version 3.0), with all kinds of new features. Its successor version (version 3.1) also became available on the earlier Amiga models as an upgrade, such as the Amiga 500.

Contrary to the Amiga 500, but similar to the Amiga 2000 and 3000, the Amiga 4000 is a high-end computer model, not a budget model -- the computer is in a separate case (not integrated into the keyboard), and has much more extension capabilities. The Amiga 4000 has four Zorro III expansion slots, rather than one. You can use these slots to extend the machine with multiple hardware peripherals at the same time, such as external graphics, sound and network cards.

The Amiga 1200 and Amiga CD32 are the Amiga 4000's budget counterparts. The Amiga 1200 also contains the AGA chipset, but only has one expansion slot, less memory and a cheaper and less powerful CPU (the 68EC020). The CD32 is basically an Amiga 1200 that lacks a keyboard, but includes a CD-ROM drive.

Although the Amiga 4000 has quite a few nice improvements over its predecessor models, the competitive situation of Commodore was quite bad in 1992. Contrary to the introduction of the Amiga 1000 and 500 (in 1985-1987) Commodore no longer had the competitive edge in 1992.

In the late 80s, due to mismanagement and cuts in research budgets, the Amiga failed to innovate. With the introduction of the Amiga 4000 and 1200, Commodore was basically just "catching up". The competition, such as the IBM PC and compatibles, were ahead in many areas:

  • VGA graphics (introduced in 1987) have become more common in PCs in the 90s. VGA provides a 320x200 screen mode with 256 colors (albeit out of a palette of 262144 possible colors) and has an easier method to address pixels -- chunky graphics, that address every pixel as a byte, rather than 8 separate bitplanes.

    Although for 2D games, the Amiga's AGA chipset did fine in comparison to VGA, it had no "good answer" to 3D games, such as Wolfenstein 3D and Doom, because it lacks the chunky graphics modes that these games heavily rely on.

    (As a sidenote: many years later, after Id software released the source code of Wolfenstein 3D and Doom, these games were ported to the classic Amiga models, but that is a different story).
  • After VGA, even better graphics standards were developed for the PC in the late 80s and early 90s, such as Super VGA and XGA, that were much more powerful than Amiga's AGA chipset. These graphics standards support even higher resolutions and more colors (16-bit high color, and 24/32 bits true color screen modes).

    Aside from using an external RTG card, the Amiga did not provide any built-in solution to match these graphical features.
  • From an audio perspective, the Amiga was also no longer leading. Although Paula was still a fine sound chip in 1992, cheaper and more powerful sound cards were developed for the PC that can provide an even better experience.

The only area that I believe the Amiga still had a competitive edge in 1992 was on operating system level. In 1992, Microsoft had no consumer operating system yet that was capable of doing pre-emptive multi-tasking. Windows NT 3.1 (release mid 1993) was the first version of Windows supporting pre-emptive multi-tasking, but it was an expensive operating system meant for business use. Windows 95 brought pre-emptive multi-tasking to consumers, but it became available in the middle of 1995. It took Apple even longer -- they brought pre-emptive multi-tasking to consumers with Mac OS X, introduced in 2001.

The Amiga 4000 also has a number of drawbacks over its predecessor models -- it used cheaper hardware components of lesser quality, such as IDE rather than SCSI for hard-drives (SCSI at that time provided better performance) and low quality capacitors and batteries, that will typically start to leak after years of inactivity, damaging the motherboard. Fortunately, my Amiga 4000 was revised in time to not suffer from any damage.

My Amiga 4000 specs



My Amiga 4000 has the following specs:

  • It is the Amiga 4000/040 model, which means that it has a 68040 CPU (with an MMU and FPU), rather than the cheaper, slower and less powerful 68EC030 CPU (that lacks an MMU and FPU).
  • The amount of fast RAM on the board was upgraded to 16 MiB.
  • It also contains an expansion card: a Phase 5 Fastlane Z3 providing a SCSI controller (no devices are connected to it) and another 32 MiB of fast RAM, providing me a total of 48 MiB of fast RAM.
  • Similar to my Amiga 500, the hard-drive was broken due to old age. It was replaced by a CF2IDE device, making it possible to use a Compact Flash card as a replacement hard drive. Compared to old hard drives, a Compact Flash card provides much more storage capability and higher I/O speeds.
  • A DVD-ROM player was added
  • An external RTG graphics card was added: the Cybervision 64/3D. This card provides chunky graphics at much higher resolutions and higher color modes than the AGA chipset (in addition to 8-bit colors, it provides 16-bit high color and 24/32-bit true color).
  • The original 3.1 kickstart ROM was replaced by an AmigaOS 3.9 kickstart ROM. This requires some explanation.

I have also been using some of the replacement peripherals of my Amiga 500 in combination with the Amiga 4000:

  • I can attach my GoTek floppy emulator to the external floppy disk connector and use it as the DF2: drive. Although the internal disk drive still works fine, using disk images from a USB memory stick is much more convenient than using real floppies.
  • I can use the null modem cable to hook up the Amiga 4000 to my PC and conveniently exchange files.
  • I can use the RGB2SCART cable to connect the RGB output to my LED TV, because I no longer have a working Amiga monitor.

AmigaOS 3.9


As I have already mentioned earlier, the original Kickstart 3.1 ROM chip in my Amiga was replaced by an "AmigaOS 3.9 Kickstart ROM". This kickstart ROM was a big mystery to me when I first saw it.


According to Wikipedia, AmigaOS 3.5 and 3.9 were developed by Haage & Partner after Commodore's demise. They were released in 1999 and 2002 as software-only updates to Kickstart 3.1 systems, that ran at least on a 68(EC)020 processor.

AmigaOS 3.9 has a variety of changes and additions over AmigaOS 3.1, such as:

  • An updated SCSI driver that is not restricted to a maximum of 4 GiB of storage
  • A TCP/IP stack and web browser
  • An MP3 player
  • Various look and feel updates
  • NewIcons, providing 256 color, high resolution icons, rather than 4 color icons in the classic Workbench
  • AmiDock (a menu application that can be used to conveniently launch applications)

After learning more about AmigaOS 3.5 and AmigaOS 3.9, I still did not understand where this ROM chip came from or why it was needed, because the official AmigaOS 3.9 documentation does not mention the kickstart part at all.

After some additional searching, I learned that this 3.9 ROM chip is a scene/homebrew ROM. Basically its value is that it provides a faster and more convenient AmigaOS 3.9 bootup.

Normally, AmigaOS 3.9 patches various aspects of the Kickstart 3.1 ROM on first startup with various kinds of modifications, such as a better SCSI driver and Workbench modifications. After the patching is complete, the machine reboots and then the system boots into Workbench 3.9, making the first startup process slow. With the AmigaOS 3.9 ROM chip these modifications are already present on powerup, making the boot process faster.

Moreover, because the Kickstart 3.1 ROM's internal SCSI driver is not able to escape the 4 GiB limit, the first partition of a hard drive needs to be smaller than 4 GiB. When using the AmigaOS 3.9 ROM, there is no such limitation because the patched SCSI driver is already present in memory.

Installing an AmigaOS 3.9 system from scratch


Another thing that I learned is that Amiga Workbench 3.1 does not boot on Kickstart 3.9. After some deeper inspection, I discovered that the LoadWB command in the Startup-Sequence fails with an "invalid resident library" error.

My guess is that AmigaOS 3.9's modified workbench.library is not compatible with the LoadWB command from Amiga Workbench 3.1. This incompatibility is a bit disappointing, because previous kickstart releases (provided by Commodore) were always backwards compatible with older Workbench releases. For example, you can still boot Workbench 1.3 on a system with a Kickstart 3.1 ROM.

Because of this incompatibility and because I learned the value of using AmigaOS 3.9, I have decided to first do a clean AmigaOS 3.9 installation on a new Compact Flash card.

Creating an AmigaOS 3.9 boot disk


Contrary to the Amiga Workbench versions provided by Commodore, AmigaOS 3.9 is distributed on a CD-ROM, rather than a set of floppy disks.

On my Amiga 4000, it is not possible to boot from a CD-ROM. To do a fresh AmigaOS 3.9 installation, I must first create an emergency boot disk that has access to the CD-ROM drive.

Creating an emergency disk is straight forward. I must first boot from an existing Workbench installation, insert the AmigaOS 3.9 CD-ROM and start the installer: CD0:OS-Version3.9/OS3.9-Installation. In the installer I need to pick the option: "Create emergency disk". The rest of the steps are self explanatory:


The size of my Compact Flash card is 32 GiB. As I already explained, Commodore never took drives of such large sizes into account because they simply did not exist yet in 1992. As a result, the SCSI driver and Amiga Fast File System were never designed to (efficiently) deal with them.

The previous owner decided to use Smart Filesystem (SFS) as the default filesystem for the harddisk partitions rather than Amiga's Fast File System, because it is much better suited for large partitions. I have decided to do the same.

To be able to create SFS partitions and format them, I have downloaded and unpacked the SFS distribution from Aminet and copied the following files to the emergency boot disk:

  • The file system handler from: AmigaOS3.x/L/SmartFilesystem to DF2:L/.
  • The SFSformat command from the base directory to DF2:C/.

Partitioning the hard drive


After finishing the emergency boot disk, I can switch off the machine, insert my blank Compact Flash card, and boot from the emergency disk to partition the hard drive.

As a sidenote: similar to my Amiga 500, I recommend to clear a memory card first before partitioning it. Traces of previous partitions may confuse tools, such as HDToolBox and DiskSalv. On Linux, I can clear a memory card by running the following command:

$ dd if=/dev/zero of=/dev/sdb bs=1M

I have used the HDToolBox tool included with the AmigaOS 3.9 installation CD (CD0:Emergency-Boot/Tools/HDToolBox) to do the partitioning:


  • First, I need to select the drive that I want to partition. I have picked: SDCFXS-032G and clicked on the button: 'Install drive'
  • Then I need to configure HDToolBox to recognize Smart Filesystem partitions. I can configure HDToolBox to use the SmartFileSystem handler, by selecting the first partition, and then clicking on: 'Add/Update...' button below the 'Filesystem / International (FFS)' text box.
  • Then I must click on the button: 'Add New Filesystem...' and open DF2:L/SmartFileSystem handler
  • Finally, when creating a partition, I must change the partition's file system to: CFS\00

Although with the custom kickstart 3.9 ROM it is possible to escape a partition's 4 GiB limit, I have still decided to keep the first two partitions below 2 GiB -- the operating system and Workbench may be able to work fine with larger partitions, but certain applications may still have problems. For example, AMOS BASIC internally uses signed 32-bit integers to indicate the amount of free disk space. As a consequence, it will overflow and report weird values if a partition is bigger than 2 GiB.

Formatting the hard drive partitions


After creating the partitions, I have to reboot the system once more and boot from the emergency disk so that these new partitions are recognized. Then I can format the partitions by running the following kinds of commands on the command-line interface (CLI):

DF2:C/SFSformat DEVICE DH0: NAME HARDDISK0 SHOWRECYCLED

The above command formats the device DH0:, gives it the name: HARDDISK0 and adds a recycle bin to it.

Installing Workbench 3.9


Finally, I can install AmigaOS 3.9 on the hard drive from the CD-ROM, by opening the installer: CD0:OS-Version3.9/OS3.9-Installation and selecting the option: "OS3.9 full installation over OS3.0 or empty HD". The procedure is straight forward and self explanatory.

After completing the installation, I can reboot the machine and boot into AmigaOS 3.9 installed on the hard disk. Then I can install the applications that I want.

Making the RTG graphics card work


Installing the applications that I want is generally a straight forward process. The only challenge was making the Cybervision 64/3D graphics work.

As I already explained in the beginning of this blog post, the driver disks and the manual were lost. Fortunately, this Amiga hardware database page can still offer me the missing copies.

In my search process, I also learned a thing or two about retargetable graphics (RTG) on the Amiga. It seems that Commodore never developed a standardized API for AmigaOS to facilitate retargetable graphics. It was on the planning, but they went out of business before it got realized.

Other parties eventually stepped up to fill the gap. The two most popular RTG APIs are CyberGraphX (launched in 1995) and Picasso96 (launched in 1996). Initially, CyberGraphX was the most popular, but the slowly Picasso96 overtook its popularity, because it provides much better integration with the Amiga Workbench. The two APIs have a high-degree of compatibility with each other.

First, I tried to install CyberGraphX that came with the missing driver disks. Although I was able to see the 'CyberGraphX' logo on my VGA monitor, RTG graphics were not usable. The system basically just hangs. I guess this problem may be caused by an incompatibility with AmigaOS 3.9 or the CyberGraphX libraries that were already stored in the Kickstart 3.9 ROM.

Then I tried Picasso96. A copy was included on my AmigaOS 3.9 CD-ROM. It includes a driver for my Cybergraphics 64/3D card.

Unfortunately, with Picasso96 I also ran into problems. Using the test feature in the Picasso96Mode Prefs program always showed me a black screen, no matter how much I change the display parameters.

After an extensive search on the web and comparing the content of my AmigaOS 3.9 installation with the installation of the previous owner I eventually discovered the root cause -- there was no 68040.libary installed on my system. I fixed the issue by copying the missing library from the directory: CD0:OS-Version3.9/Extras/Libs on the AmigaOS 3.9 CD-ROM to DH0:Libs.

After fixing the library issue, Picasso96 works fine. I can, for example, display the Workbench (and many Intuition/Workbench-based applications) at a much higher resolution on my VGA screen:


The above pictures show the effect of enabling RTG graphics. On the left, the Workbench screen is rendered by the AGA chipset (using a 640x256 resolution). The RGB output is attached with an RGB2SCART cable to the right screen. On the right, we have enabled the RTG card using a much higher resolution: 800x600. The RTG card is connected with a VGA cable to the left screen.

Installing an AmigaOS 3.1 system from scratch


After producing a working AmigaOS 3.9 configuration from scratch, I also wanted to have a working AmigaOS 3.1 installation so that I can enjoy the original user experience that I was used to in the 90s.

Because Compact Flash cards are cheap, and we can conveniently switch them at the back of the machine, we can easily make a second hard drive image with an AmigaOS 3.1 installation.

Getting a working AmigaOS 3.1 installation turned out to be quite an interesting puzzle :). As I have already explained, Workbench 3.1 is not compatible with Kickstart 3.9. Contrary to my Amiga 500, it seems that it is not possible to have multiple kickstart ROM chips in my Amiga 4000 -- my Amiga 500 has two kickstart ROM chips (1.3 and 2.0) and a kickstart switcher, but as far as I know, such a device does not exist for the Amiga 4000.

Moreover, I am hesitant to replace the Kickstart 3.9 ROM chip by the original Kickstart 3.1 ROM chip. Aside from the fact that I find replacing chips scary, it also feels as a step backwards to deliberately degrade a working system's functionality -- Kickstart 3.9 has useful features, such as an updated SCSI driver.

Soft kicking Kickstart 3.1


After recollecting my memories of earlier Amiga models, I realized that there is a different way to tackle my problem. The first Amiga model: the Amiga 1000, did not have a kickstart ROM at all. Instead, on initial power up, it showed a white screen requesting the user to load the kickstart from a floppy disk into a restricted area of the RAM. After the kickstart is loaded, it shows the well-known floppy disk splash screen and permanently stays in RAM, even after reboots.

After some searching, I learned that loading a Kickstart into RAM is possible on all Amiga models, by using a program called a "soft kicker". There are a variety of such programs available.

For example, SKick is a soft kicker that works well on my Amiga 500 -- it can patch a variety of Amiga 500 compatible kickstart ROM images, load them into a different area in memory, namely: RAM, and then reboot the machine to use that Kickstart version. The Kickstart stays in memory, even after a reboot.

The only price you need to pay is 256 KiB (for Kickstarts 1.x) or 512 KiB (for Kickstarts 2.x or newer) of RAM. If you have a memory expansion, such as an additional 8 MiB of fast RAM, this is typically not a big issue.

SKick does not seem to work well on my Amiga 4000. From what I have read, the problem is that the 68040 CPU has an MMU and puts things in memory differently than SKick is used to.

After some more searching on Aminet, I found BlizKick. This soft kicker is originally designed for phase5/DCE turbo boards, but it also supports the MAPROM feature of the Commodore A3640 CPU card that contains the 68040 CPU.

I discovered that the MAPROM feature was disabled on my CPU card. I had to open the Amiga 4000 case and change the jumper configuration to enable it:


After enabling the MAPROM feature, I can easily soft kick my machine from my existing AmigaOS 3.9 installation to load the original Kickstart 3.1, by running the following command-line instruction:

BlizKick CPUCARD KICKFILE DEVS:Kickstarts/kick40068.A4000

The above command-line instruction states that we need to load the 3.1 Kickstart ROM for the Amiga 4000 file into RAM: DEVS:Kickstarts/kick40068.A4000 and soft kick it by using the MAPROM feature of my A3640 CPU card.

"Bootstrapping" AmigaOS 3.1


The next step turned out to be a challenging one. I need to somehow partition the hard drive, format the partitions and install Workbench 3.1. My idea was to create a bootable floppy disk to soft kick my Amiga 4000 into Kickstart 3.1, and then boot from the Workbench 3.1 install disk.

Unfortunately, it turns out that calling BlizKick from a bootable floppy disk's Startup-Sequence, does not work. For reasons unknown to me, the Kickstart always seems to enter a crash loop after the reboot.

Eventually, I gave up the boot floppy approach and took a very unorthodox route. First, I used AmigaOS 3.9 to partition the hard-drive and format the SFS partitions, the same way described in the previous section.

I did not install AmigaOS 3.9 on the hard drive. Directly after formatting the partitions, I copied BlizKick and the 3.1 Kickstart ROM to the first hard-drive partition. I created a very basic Startup-Sequence that only does the following:

BlizKick CPUCARD KICKFILE DEVS:Kickstarts/kick40068.A4000

After rebooting the machine from the hard-drive I noticed that it had successfully soft kicked into Kickstart 3.1.

Then I booted from the Workbench 3.1 install disk to install the Workbench on the hard drive. The Workbench installation procedure is straight forward and self explanatory.

After completing the Workbench installation, the old Startup-Sequence gets overridden. To allow the machine to soft kick into Kickstart 3.1 on the next reboots/power ups, I have added the following code fragment to the beginning of the hard drive's Startup-Sequence:

C:Version >NIL:

If NOT $Kickstart EQ "40.68"
    SYS:Programs/BlizKick/BlizKick CPUCARD KICKFILE DEVS:Kickstarts/kick40068.A4000 QUIET
EndIf

The above code fragment extends the previous example with a Kickstart version check: it checks whether the current kickstart version is 40.68 (the internal version number for the 3.1 kickstart release that we want to use) and only invokes BlizKick when this is not the case.

On a real Amiga 4000, this check is redundant -- BlizKick also checks whether the desired Kickstart version was soft kicked already. However, I also want to have the ability to put the Compact Flash card in my PC's card reader so that I can use it with FS-UAE. In FS-UAE, BlizKick is unable to determine that it had soft kicked already, causing the emulated machine to run in an infinite loop without this check.

Patching the Kickstart to use an updated SCSI driver


As I have already explained, one of the benefits of the 3.9 Kickstart ROM is that it includes an updated SCSI driver that is not limited by a maximum hard drive size of 4 GiB.

When booting my Workbench 3.1 configuration (that also soft kicks Kickstart 3.1), I have noticed that I was constrained by the 4 GiB limit again -- aside from the first partition, the remainder of the partitions were no longer visible.

To escape this 4 GiB limitation, I have installed the Install-SCSI package from Aminet. This package extracts the SCSI driver from the Kickstart, patches it with new features (such as the ability to use partitions larger than 4 GiB), and modifies the Startup-Sequence to patch the Kickstart to use the updated driver on startup. As long as the boot partition is below the 4 GiB limit, this approach works.

Result


Although I had to take a very unorthodox route, I am happy about the result. The following pictures demonstrate my Workbench 3.1 (on Kickstart 3.1) experience:


Similar to my AmigaOS 3.9, I can use both the AGA chipset (shown on the left) and the RTG card (shown on the right) to render the Workbench screen.

Using the Amiga 4000


After producing clean AmigaOS 3.1 and 3.9 configurations, I have been playing around with quite a few applications and games.

For example, when using Brilliance, a painting program, I can instantly see that AGA graphics are an improvement over ECS/OCS graphics:


The above picture shows an 256 color example picture that is included with Brilliance. Apart from using 256 colors, it can also use a high-resolution, interlaced screen mode (providing a resolution of 640x512). In comparison, an Amiga 500 can only use 32 colors (or the extra-half brite and HAM modes) in low resolution modes. In high resolution mode, it can only display 16 colors.

AGA games are also typically much more colorful, such as Pinball Fantasies (AGA version), Soccer Kid (AGA version) and Slamtilt:


Earlier in this blog post, I have mentioned that when Wolfenstein 3D and Doom were launched for the IBM PC and compatibles, the Commodore Amiga had no good answer. Not being able to catch up partially contributed to its demise.

After the source code of these games were released, these games were eventually ported to the Amiga (AmiWolf was released in 2013 and ADoom in 1997):


On my Amiga 4000, these games do not render extremely fast, but they are playable. I believe that the Doom gaming experience on early 80386 PCs was not particularly fast either.

I also tried a demo (Closer by CNCD) that was designed specifically for the Amiga 4000 showing me 3D animations:

The Cybervision 64/3D RTG card opens up even more possibilities. A higher resolution screen makes it possible for me to more conveniently use productivity software, such as FinalWriter and Deluxe Music:


Painting can also be done in high resolution, true-color modes with TVPaint:


One particular program I am still quite impressed with is LightWave. Although LightWave even works on an Amiga 500 (albeit with many limitations), having a much faster machine with an FPU at my disposal makes it much more usable:


In combination with my RTG card I can also render a scene at a much higher resolution, with more colors:


I must admit that the above rendered picture still looks nice today.

How does the Amiga 4000 experience compare to the Amiga 500?


As I have explained earlier, I have intensively used my Amiga 500 for years, but I have not used an Amiga 4000 much, so it is still (sort of) a new experience to me.

I have to say that the experience in the last couple of weeks was nice -- it was nice to explore the enhanced capabilities of the Amiga 4000 and the applications that use it:

  • A faster CPU makes many applications much more responsive, which makes you as a user more productive. For example, FinalWriter and DeluxeMusic also work fine on my Amiga 500, but it sometimes takes a couple of seconds to render a page of a document or sheet music. On an Amiga 4000 these pages render almost instantly.
  • Some applications are much more usable, such as LightWave. More abilities open up because of the machine's speed and the presence of an FPU. Although the non-floating point aspects of LightWave even work on an Amiga 500, it is too slow and limited to do anything useful.
  • There are AGA games that look nice.
  • There are some really nice demos using the enhanced capabilities of the Amiga 4000.
  • With an RTG card you can do advanced, high resolution, true-color graphics. I am particularly impressed by the images that I can produce with LightWave in combination with a RTG card. With an RTG card, I have the feeling that the Amiga 4000 is still on par with PCs in the early 90s.

Although it is nice to have more power and new abilities, I do not want to claim that my Amiga 4000 experience is significantly better than my Amiga 500 experience.

For quite a few of my use cases an Amiga 4000 is "overkill" -- most of the software that I am interested in were developed for the Amiga 500, because that was the most popular Amiga model, despite being a lesser capable machine.

On my Amiga 4000, I still mostly use the same applications that also work fine on an Amiga 500, such as DirectoryOpus, Cygnus Editor, AMOS Professional, and ProTracker. Moreover, most of my favourite games were OCS/ECS-compatible games.

Furthermore, there are some aspects of my Amiga 4000 that I consider worse compared to my Amiga 500:

  • I do not have the ability to (conveniently) switch the primary floppy disk drive (the DF0: drive) with an external drive. On my Amiga 500, there is a DF0 selector switch that I can use to make the secondary disk drive the primary disk drive and vice-versa. This feature makes it possible to conveniently boot disk images from my GoTek floppy drive.

    As far as I know, it is not possible to have such a facility on an Amiga 4000. Some applications and games can boot from any disk drive (if you select the boot device from the Kickstart by pressing both mouse buttons on startup), but many of them will only work if you boot from DF0:.

    I do not want to replace the internal floppy drive from my Amiga 4000 with a GoTek. Fortunately an alternative solution exists -- I can also find WHDLoad replacements of these games so that they can be played from the hard drive.
  • To my knowledge, there is also no method to use multiple ROM chips. Although soft kicking is also possible, it is still a bit disappointing to require such a complex solution.
  • The Amiga 4000 is not perfectly backwards compatible with software designed for older Amiga models. There are quite a few games that crash because of an incompatibility, such as one of my favourite Amiga 500 games: Turrican.

    There are a variety of reasons that older applications may not work: the AGA chipset, the CPU, and the Kickstart/Workbench version are components that could introduce incompatibilities.

    Fortunately, the WHDLoad project has addressed many compatibility issues. WHDLoad is somewhat comparable to Virtual Machines on modern computers -- aside from the fact that it loads disk images from an hard disk and prevents the user from switching disks, it can also soft-kick more compatible kickstart versions, disable CPU caches and perform other kinds of tweaks to make a game more compatible on a certain system.

    For example, the WHDLoad-version of Turrican is compatible with my Amiga 4000, because it provides all kinds of facilities/fixes to deal with incompatibilities.
  • The Cybervision 64/3D is a nice graphics card for mid-90s standards, but not all software can effectively use it.

Conclusion


In this blog post, I have described the properties of my Amiga 4000, how I have installed the operating systems from scratch and my experiences using the machine.