IntuitionBase Banner

A different view about customising the Amiga OS with respect to its functioning

How to organise your Amiga's OS: an alternative way

An odd view about booting an Amiga

The steady flow over the years of OS4.0 and its upgrades upto and including 'OS4.0 Final 1', culminating in the appearence of 'OS4.1' halfway August 2008, combined with an utter lazyness on my part have led me to set up my Amiga a little bit different then usual.

Disclaimer: My Amiga is a bogstandard A1, nothing fancy about it.
It sports a 120Gb HD (Maxtor), a Samsung CD-RW, an iomega ZIP100 drive in SCSI form and therefore the only expansion slot available on the A1 is populated by a Tekram SCSI-controller. On the outward connector of which an Epson Perfection scanner is connected. Printing is achieved through a networked HP LaserJet 4+ using lpr.device.

The partitioning of its 120GB HD reflects some ideas that I already had worked out on my A1200, but never really fully implemented. On the 24th of December 2004, I got hold of a Micro and as it had to have OS4.0 installed I could just as well do it like I had been dreaming of in my A1200 days.
My wish was to have a couple of partitions, each of them for very strict use. What I wanted most was the presence of a number of boot partitions, with at least one emergency boot partitions in case things got nasty. It resulted initially in these partitons:
  • 1. Main boot
  • 2. Spare boot
  • 3. Applications
  • 4. Projects
  • 5. Games
In a later stadium due to various reasons these partitions were augmented with the following:
  • 7. Third boot
  • 8. Webserver (where Apache lives)
  • 9. Extracts
  • 10. UAE
  • 11. Video's
I remember one of the reasons for this massive expansion was the mentioning of a new release of OS4.0.

Coming from an A1200 environment (in my Amiga world), I felt the need for keeping partitions rather small so as not to waste precious disk space. My A1200 sports a 4Gb HD, so all the more reason to be very picky when it comes to choosing a size for a partition.
Being the lazy guy I claim to be, I would like to refrain from duplicating files as much as possible. After a long thought I decided to bite the bullet and add yet another partition:
  • 12. Extended boot (called 'ExtSYS:')

This one partition formed the main reason for my unorthodox setup. Although not bootable, it shows a remarkable resemblence with any of the boot partitions, as it contains a.o. these drawers:
  • Devs
  • MUI
  • Prefs
  • Fonts
  • Libs
  • C
  • S
  • Utilities
In these drawers I put all that stuff that are an extension to the OS, but do not come with the OS. Third party stuff like scanner.device, diskimage.device and lpr.device in ExtSYS:Devs. Or a host of datatype recognition files in ExtSYS:Devs/Datatypes and their respective counterparts in ExtSYS:Classes/Datatypes. These are just some examples. It is far to much to list all of it here, allthough I will make an exception for AISS. Due to it currently taking up more then 2Mb I have it installed onto ExtSys:Classes/ToolbarImages. Without duplication it is now available for all versions of the OS that I keep installed, but we'll come to this later

Dire warning: make sure that for this partition you use a filesystem that is recognised by ALL versions of the OS!

Currently my HD is partitioned this way:
DH0:         255M       143     523.185   0%      0 Read Only  Unused (2)
DH1:         255M    82.996     178.668  32%      0 Read Only  OS_4.0 r3
DH10:      4.000M   328.614   3.767.418   8%      0 Read Only  UAE
DH11:      1.023M    91.813   2.004.379   4%      0 Read Only  Unused (3)
DH12:        128M   223.323      38.821  85%      0 Read Only  OS_4.0 r2
DH13:        127M   250.404      11.292  96%      0 Read Only  OS_4.0 Final
DH14:        164M   320.372      16.076  95%      0 Read Only  OS_4.0 Final 1
DH15:      5.119M 4.189.587   6.295.533  40%      0 Read/Write Video's
DH16:        521M   550.730     518.134  52%      0 Read/Write ExtSYS
DH2:         255M    93.128     168.536  36%      0 Read Only  OS_4.0 r4
DH3:         255M   257.957       3.707  99%      0 Read Only  Unused (1)
DH4:       2.047M   699.626     348.710  67%      0 Read/Write Applicaties
DH5:       2.047M   551.191     497.145  53%      0 Read/Write Projecten
DH6:       3.071M   763.923     808.701  49%      0 Read/Write Games
DH7:         100M    92.703     112.161  45%      0 Read/Write WebServer
DH8:       6.000M 3.271.279   2.872.753  53%      0 Read/Write Extracts
DH9:       4.000M 3.274.983     821.049  80%      0 Read/Write Archives

What modifications did I make to the intallation?

By far the most important one is this extremely simple addition to 'SYS:S/User-Startup':
; ==========================================

  Assign S: ExtSYS:S ADD

  If EXISTS S:ExtSYS-StartUp
    Execute S:ExtSYS-StartUp

; ==========================================
; === End of List ==========================
; ==========================================

In fact, it is also the only one!

The only other modification I've made is in 'SYS:S/Startup-Sequence', where I prefixed the line 'C:AddNetInterface...' with 'Run >>NIL:', as a generally recognized and applied way to reduce the time required to boot the system. These have actually nothing to do with my unorthodoxness.

About the partitions

All partitions contain a drawer called 'S' and some of these drawers contain a startup sequence. These partition related startup sequences are called from ExtSYS:S/ExtSYS-Startup one by one. In these partition related startup sequences you may find all those things that would normally have gone into one wieldy SYS:S/User-Startup. In order to let these startup sequences have as little influence to the boot time as possible, the general lines look like this: C:Run >NIL: C:Execute S:<VolumeName>-StartUp. So for the partition called 'Webserver:' it looks like this: C:Run >NIL: C:Execute S:WebServer-StartUp.
From whichever partition I now boot the system, ExtSYS:S/ExtSYS-Startup is allways executed, thereby ensuring that allways all proper assigns are established as well as all other stuff is handled. Schematically it looks like this:
BootVolume 1: SYS:S/Startup-Sequence --> Execute SYS:S/User-Startup --+
BootVolume 2: SYS:S/Startup-Sequence --> Execute SYS:S/User-Startup --+
.                                                                     .
BootVolume n: SYS:S/Startup-Sequence --> Execute SYS:S/User-Startup --+
             +--> ExtSYS:S/ExtSYS-Startup
             +--> C:Run >NIL: C:Execute Games:S/Games-StartUp
             +--> C:Run >NIL: C:Execute WebServer:S/WebServer-StartUp
             +--> C:Run >NIL: C:Execute ExtSYS:S/ExtSYS-Startup_Defered

When a new version of the OS arrives (OS4.1 being the first candidate), after a clean installation of it on a newly created, bootable partition, the only thing I need to do is to modify the new User-Startup in the way described above and the system is (nearly...) fully customized! Am I lazy or am I not?
Except for a few minor niggles, all bootpartitions contain a clean, uncluttered OS, without any third party enhencements. All those enhencements are put into their respective drawers on ExtSYS:, like fonts, devices and datatypes. Therefore in ExtSYS:S/ExtSYS-Startup you find this snippet of script:
If Exists ExtSYS:Devs
  Run >NIL: C:Mount QUIET ExtSYS:Devs/DOSDrivers/~(#?.info)

  If Exists ExtSYS:Devs/DataTypes
    Run >NIL: C:AddDataTypes FILES "ExtSYS:Devs/DataTypes/~(#?.info)"
This takes care of all 3rd-parties DOSDrivers and DataTypes to be loaded at boottime.

Clean boot partitions

Now that a lot of, mainly 3rd-parties, stuff has been excluded from the boot partitions, the opportunity arrises of locking all of those boot partitions at boot time, as well as any and all other ones that are not served well with any careless modification. This prevents the unauthorized modification or deletion of files (or entire directories) in sensitive partitions. Therefore I've put these lines in 'ExtSYS:S/ExtSYS-Startup':
Lock DH0:  On >NIL:
Lock DH1:  On >NIL:
Lock DH2:  On >NIL:
Lock DH3:  On >NIL:
Lock DH10: On >NIL:
Lock DH11: On >NIL:
Lock DH12: On >NIL:
Lock DH13: On >NIL:
Lock DH14: On >NIL:
These lock about virtually all partitions. (This has been modified in a later stadium, see further on.)

A couple of assigns to accomodate the use of some commonly used volume names are in place here:
Assign Workbench: SYS:
Assign Work:      Applicaties:

Some advanced stuff

An add-on that I have developed myself, is the setting up of an environment variable called 'BootVolume'. A little proggy fills it with the (real) name of SYS:, the name of the volume that is booted from. The value of the variable I have displayed in the screen's title bar, thereby constantly informing me from which volume I booted and, hence, which version of the OS I'm currently using. However, a more advanced use of this variable is possible, as I recently found out:
; === BootVolume-dependent assigns:

If EXISTS "ExtSYS:$BootVolume"
 If EXISTS "ExtSYS:$BootVolume/C"
  C:Assign C: "ExtSYS:$BootVolume/C"                 ADD

 If EXISTS "ExtSYS:$BootVolume/Libs"
  C:Assign LIBS: "ExtSYS:$BootVolume/Libs"           ADD

 If EXISTS "ExtSYS:$BootVolume/L"
  C:Assign L: "ExtSYS:$BootVolume/L"                 ADD

 If EXISTS "ExtSYS:$BootVolume/Locale"
  C:Assign LOCALE: "ExtSYS:$BootVolume/Locale"       ADD

 If EXISTS "ExtSYS:$BootVolume/ARexx"
  C:Assign AREXX: "ExtSYS:$BootVolume/ARexx"         ADD

 If EXISTS "ExtSYS:$BootVolume/Fonts"
  C:Assign FONTS: "ExtSYS:$BootVolume/Fonts"         ADD

 If EXISTS "ExtSYS:$BootVolume/Env-Archive"
  C:Assign ENVARC: "ExtSYS:$BootVolume/Env-Archive"  ADD

 Echo >>RAM:T/Startup $BootVolume" directory NOT found"
Here we see the environment variable being used in an assign. It works!
What might be the usage of this? Well, with the functionallity of the OS gradually increasing, programs may and will change to make use of this new functionallity, thereby rendering them unuseable for earlier versions of the OS. By a): putting that kind of programs, whether they be libraries, handlers, datatypes or whatever, in their respective, but bootvolume dependent drawers, b): establishing an assign to those drawers before the generic (SYS:-related) assign is established, it is ensured that the most recent version of the file that will function with the currently booted version of the OS, is being applied!

An example is given here as to the effect of this mumbo-jumbo after booting from volume 'OS4.0 Final 1' (partial output from 'assign list dirs'-command):
L              OS_4.0 Final 1:L
             + ExtSYS:OS_4.0 Final 1/L
             + ExtSYS:L
             + ExtSYS:Utilities/FTPMountDir/L
Whenever a handler is needed that is supposed to reside in L:, then first it is being looked for in 'OS_4.0 Final 1:L', subsequently in 'ExtSYS:OS_4.0 Final 1/L', then in 'ExtSYS:L' and finally in 'ExtSYS:Utilities/FTPMountDir/L' until it is encountered (or not at all...). Both 'ExtSYS:OS_4.0 Final 1/L' and 'ExtSYS:L' may be holding a copy of the file that is being looked for, each with a different version (of course!). If the one that makes use of OS_4.0 Final 1's functionality resides in 'ExtSYS:OS_4.0 Final 1/L' then that one will be encountered first and hence loaded into memory. If the booting takes place from, say 'OS4.0 #3', then this assign MAY look like this:
L              OS_4.0 Final 1:L
             + ExtSYS:L
             + ExtSYS:Utilities/FTPMountDir/L
and the file residing in 'ExtSYS:L' will be loaded into memory instead. Voila, complete functionality retained.

Finally, as I want to keep track about the date and time the system was started, I've added this line to the Startup-Sequence:
  Date >>ExtSYS:StartupDate
A file will be appended to with an entry every time the system is (re)booted. When the file does not exist yet, it will be created. Has anyone touched my computer while I was on holiday?


I thought it a good idea to let you have a peek into all those Startup sequences. They are all listed here below:
I hope that this may inspire you to experiment with your system. Or, putting it in a modern jargon: to pimp it!

Changes since January 2010

An odd view about booting an Amiga:
new experiences since 2010

By the time this can be read from the internet, things have changed again: an updated version of the OS is released (OS 4.1 upd 1) and a short time later even OS 4.1 upd 2 saw the light of day, the latter being a real update neccessitating OS 4.1 upd 1 to be installed.
It was installing OS 4.1 upd 1 that made me pull my hairs out: whatever I tried it did not install! I had downloaded the update from Hyperion's website and burned it on a CD and that all went well. But whatever I tried from that point onwards, it refused to boot from the CD. Later it appeared to be a matter of booting priorities: my boot partitions had a priority of 7 or 8, while the CD's priority was set to 5 or something. So due to a higher bootpriority it kept booting from an already installed version in stead of from the CD.

Been thinking again and came up with this (utterly weird, I admit, but the Amiga makes it possible...!) solution: I created again a partition, a small one of only some 48Mb (96000 blocks of 512 bytes to be exact) and simply called it 'BootPartition'. It was set to being bootable, with a bootpriority of only 2.
On that partition I created only two drawers, namely 'Kickstart' an 'L'. The latter I filled with only one file: 'slb_v2' of 29,036 bytes. 'Kickstart' received a hefty 3 files: 'KickLayout', 'diskboot.config' and 'loader'. But I did not only give it files: I added some drawers too: 'OS_4.0_F', 'OS_4.0_F1', 'OS_4.1', 'OS_4.1_1' and finally, for the time being, 'OS_4.1_2', although now, halfway december 2010, I'm planning for the upcoming Update 3 to OS4.1!. Chances are that the partition will be called 'OS_4.1_3'
Each of these drawers contain ALL neccessary files to boot the system, like CDFileSystem, rtg.library, dos.library.kmod, etc., etc. augmented with a file called 'BootDevice' containing nothing more then the exec designation of the partition that will turn out to be 'SYS:' when fully booted. This is my current implementation of Amiga OS's multiboot capabillities and I must say it works very well.
My 'Kicklayout' file

In daily use it turned out that the following part of 'ExtSYS:S/ExtSYS-Startup' did not work out that well:
Lock DH0:  On >NIL:
Lock DH1:  On >NIL:
Lock DH2:  On >NIL:
Lock DH3:  On >NIL:
Lock DH10: On >NIL:
Lock DH11: On >NIL:
Lock DH12: On >NIL:
Lock DH13: On >NIL:
Lock DH14: On >NIL:
, so I replaced them with these or omitted them altogether:
Lock "OS_4.0 Final 1:" On >NIL:
Lock "OS_4.0 Final:"   On >NIL:
Lock "OS_4.1:"         On >NIL:
Lock "OS_4.1_1:"       On >NIL:
Lock "OS_4.1_2:"       On >NIL:

In previous setups I had this kicklayoutfile and accompanying kickstartmodules drawer accumulated in every installed release, resulting in a rather messy setup. It worked but was very susceptible for mistakes, hence my reasoning behind this weirdness.
Whenever a new iteration of the OS is released, I create a new partition to store it. When the release is installed, I copy it's Kickstartdrawer (files AND drawer) over to 'BootPartition:Kickstart' and give the drawer there a more proper name like 'OS_4.1_3' for the third update to OS 4.1 to come or 'OS_4.2' when it comes to a an entirely new release. I then add a BootDevice file to that drawer and finally copy and paste the new release's Kicklayout file into 'BootPartition:Kickstart/Kicklayout', provide it with a LABEL line, change all other lines to reflect the proper path to the modules, add a line 'MODULE Kickstart//BootDevice' RIGHT AFTER the line 'EXEC Kickstart/loader' and save it.
Applying multiboot to Amiga OS booting is so easy-peasy.
I've set up a rather large (10 topics) checklist of actions to undertake when it comes to a new iteration. Should work. Fingers X-ed...
Drawbacks of this way of thinking
Yes, unfortunately there are some drawbacks to this method. The most important one is that installscripts are not prepared for this kind of magick and, hence, will not install properly with respect to this setup. Some authors assume their wares being installed in a path relative to SYS:. It is not an omission on their part, but it is a resulting quirk of this setup. Although, installing in 'expert'-mode should make it possible (but often does not...). So you may find yourself either installing 'by hand' or modifying the installscript. I am experimenting with installscripts to take care of this situation.
Written by:
Tjitte 'OldFart' de Wolff

Published: 11th January 2011
2004-2011 IntuitionBase