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 NTSC display. Because I have a PAL display, the display looks messed up. I can correct that problem by copying the StartInstall script and adding the video=amifb:pal kernel parameter.
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 NTSC which is the default. 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/XFConfig-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. :)
