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
- 6. Downloads
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 installation?
By far the most important one is this extremely simple addition to 'SYS:S/User-Startup':
; ==========================================
If EXISTS ExtSYS:S
Assign S: ExtSYS:S ADD
If EXISTS S:ExtSYS-StartUp
Execute S:ExtSYS-StartUp
EndIf
EndIf
; ==========================================
; === 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_DeferedWhen 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)"
EndIf
EndIfThis 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:
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
EndIf
If EXISTS "ExtSYS:$BootVolume/Libs"
C:Assign LIBS: "ExtSYS:$BootVolume/Libs" ADD
EndIf
If EXISTS "ExtSYS:$BootVolume/L"
C:Assign L: "ExtSYS:$BootVolume/L" ADD
EndIf
If EXISTS "ExtSYS:$BootVolume/Locale"
C:Assign LOCALE: "ExtSYS:$BootVolume/Locale" ADD
EndIf
If EXISTS "ExtSYS:$BootVolume/ARexx"
C:Assign AREXX: "ExtSYS:$BootVolume/ARexx" ADD
EndIf
If EXISTS "ExtSYS:$BootVolume/Fonts"
C:Assign FONTS: "ExtSYS:$BootVolume/Fonts" ADD
EndIf
If EXISTS "ExtSYS:$BootVolume/Env-Archive"
C:Assign ENVARC: "ExtSYS:$BootVolume/Env-Archive" ADD
EndIf
Else
Echo >>RAM:T/Startup $BootVolume" directory NOT found"
EndIfHere 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/LWhenever 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/Land 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:StartupDateA 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?
Afterthought
I thought it a good idea to let you have a peek into all those Startup sequences. They are all listed here below:
- 1. Original Startup-Sequence
- 2. Original User-Startup
- 3. Modified Startup-Sequence
- 4. Modified User-Startup
- 5. ExtSYS:S/ExtSYS-Startup
- 6. ExtSYS:S/ExtSYS-Startup_Defered
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