A vanilla Amiga does not reach its full potential when first being acquired. The classic Dhrystones performance benchmarks using the well-known SysInfo tool will display raw computational speed but it will tell very little about, say, how fast Workbench icons are rendered, how fast the Amiga feels when moving windows around on the Workbench and even how fast programs load up.
In fact, as this guide is progressively written, a A1200 test machine is very noticeably faster by choosing and applying patches but the Dhrystones test remains stuck at the same value. Similarly, the A1200 without the mentioned patches in this guide would be horribly slow and even run out of memory - regardless of the SysInfo performance benchmark.
Updating the kickstart when running Amiga OS 3.9 is performed by the tool
SetPatch that is called at the very beginning of the Amiga startup sequence (
SetPatch runs, it substitutes some ROM modules with updated ROM modules from Amiga OS 3.9.
Commonly, when an accelerator is present that allows mapping the Amiga ROM into fast RAM and loading custom ROM modules using the accelerator built-in features - for instance,
BlizKick for Blizzard accelerators, the
SetPatch command in the startup sequence (
S:startup-sequence) is run with a flag that prevents
SetPatch from overriding any modules loaded by the accelerator:
C:SetPatch NOROMUPDATE QUIET
NOROMUPDATE flag tells
SetPatch to not override modules that are to be found in the ROM and should be used, for instance, if
BlizKick is called before
Fortunately, RAM is, by today's market, rather cheap (even for an Amiga accelerator) such that there is no need to be conservative about updating and substituting ROM modules using your accelerator. Substituting ROM modules, and, more generally, updating the kickstart modules can be performed in two different ways:
Unfortunately, the Amiga has hard-limitations on how large (in size) a ROM can be - for instance, the
workbench.library from OS 3.9 is conventionally left out of a 3.9 kickstart ROM because it would make the ROM too large to boot. Even worse, accelerators cannot kick a ROM file that exceeds these limits either - even if you are kicking just a file and are not burning a physical ROM chip.
From a different perspective, you do not really want a 3.9 kickstart ROM because you want your Amiga to be most compatible with the software that has been optimised to run on previous versions of Amiga OS. In other words, you will at some point want to go back to 3.1 to be able to run a game or a program that may behave differently due to the various "updates" that have been added in the semi-official 3.9 AmigaOS.
To conclude, the best option is to use the accelerator features and make your accelerator patch the ROM on the fly by injecting individually updated ROM modules. The list mentioned in the following table also includes 3.1 ROM modules that have no reason to be there, however, they do no harm by being there and give you a clean overview of what your ROM will be like when the accelerator substitutes the ROM modules.
The procedure of building an OS 3.9 kickstart ROM can be summarised with the following steps:
DEVS:AmigaOS ROM Updatefile to a different folder.
At this point you will have a folder that contains the ROM modules from kickstart 3.1 (the one physically in your computer) and a folder containing the ROM updates from
DEVS:AmigaOS ROM Update - the latter is the very same file that
SetPatch uses to patch the kickstart ROM.
You will now:
DEVS:AmigaOS ROM Updatefile.
Now, you will have obtained a folder that contains a complete 3.9 kickstart of a vanilla Amiga OS 3.9 without any Boing Bags.
The final step is to search your OS 3.9 installation for files matching the files in the resulting kickstart folder. For instance, you will have
asl.library from the 3.1 kickstart because the
DEVS:AmigaOS ROM Update file does not contain an update for
asl.library - however, your full OS 3.9 install will contain an
LIBS:. As such, you will copy
LIBS:asl.library to your working kickstart folder by overwriting the old file.
Once all files have been substituted, you will have a folder that contains an Amiga OS 3.9 kickstart at the latest Boing Bag level with all semi-official but stable patches.
|exec.library|| ||OS 3.9|
|audio.device|| ||OS 3.1|
|battclock.resource|| ||OS 3.1|
|battmem.resource|| ||OS 3.9|
|bootmenu|| ||OS 3.9|
|card.resource|| ||OS 3.9|
|carddisk.resource|| ||OS 3.1|
|cia.resource|| ||OS 3.1|
|con-handler|| || KingCON Handler from OS 3.9 to be found in |
|console.device|| ||OS 3.9|
|disk.resource|| ||OS 3.1|
|dos.library|| ||OS 3.9|
|expansion|| ||OS 3.1|
|FileSystem.resource|| ||OS 3.9|
|filesystem|| ||OS 3.9|
|gameport_keyboard|| ||OS 3.1|
|asl.library|| ||OS 3.9|
|gadtools.library|| ||OS 3.1|
|input.device|| ||OS 3.1|
|graphics.library|| ||OS 3.1|
|icon.library|| ||Peter Keunecke (PeterK)'s IconLib from Aminet||This is vital and in combination with FBlit, it offers a much faster rendering than any Workbench could achieve and can see all the possible Workbench icons ever designed.|
|intuition.library|| ||OS 3.1|
|keymap.library|| ||OS 3.1|
|layers.library|| ||OS 3.9|
|mathffp.library|| ||HSMathLibs||Although no noticeable performance improvement could be observed, they are being worked on, updated and they cost a modest fee - so it is all worth it.|
|misc.resource|| ||OS 3.9|
|potgo.resource|| ||OS 3.9|
|ram-handler|| || OS 3.9 to be found in the |
|ramdrive|| ||OS 3.1|
|romboot|| ||OS 3.1|
|scsi.device|| ||OS 3.9|
|shell|| ||Thomas Richter's shell update.||The shell update by Thomas Richter is a an update that supersedes the OS 3.9 boing bags and provides compliant and backward compatible updates to the shell.|
|timer.device|| ||OS 3.1|
|trackdisk.device|| ||Dan Babcock's HackDisk||HackDisk can be used to fix issues where certain floppy drives are not recognized and utilized properly by the Amiga. Such cases can include the A1200 not being able to properly format 5.25" floppies.|
|utility.library|| ||OS 3.1|
|wbtask|| ||OS 3.1|
|workbench.library|| ||OS 3.9|
|romupdate|| ||OS 3.9|
|C:Execute|| ||Thomas Richter's shell update.|
As you may have observed, there are some updates mentioned in the table that cannot be found in OS 3.9 or any Boing Bag - this is mostly due to the patches being released after the last Boing Bag, namely Boing Bag 3 & 4. It is recommended to keep your patches as close as possible to official sources.
Recommended sources for "updates" are:
icon.librarythat is not only very well-performing but allows your Workbench to see any sort of icon (classic icons, NewIcons, GlowIcons and even PNG icons). It is highly recommended and almost vital since without this patch you may run into issues such as not being able to properly see WHDLoad game icons.
Cosmos patches tend to outperform many other patches, however they perform so well that you will be chasing Gurus a little too much. If you want a stable machine, then avoid Cosmos patches, otherwise, feel free to explore the bleeding edge.
BlizKick contains a few design flaws - one deadly flaw is that if you make the
BlizKick line too long, then
BlizKick will refuse to boot such that having all the modules above listed on a single line in
S:startup-sequence will make the line too long.
One workaround is to first set the path to the folder containing the modules by setting the path to the folder containing all the modules. For instance, supposing you have placed all the above files in
DEVS:kickstarts/3.9, you would issue:
setenv BKMODPATH DEVS:kickstarts/3.9 copy ENV:BKMODPATH ENVARC:
such that you will not have to provide a path to every module in
Finally, you can rename all the modules (
battclock.resource, etc…) with numbers sequentially:
3, and so on such that you will end up with a
BlizKick line in
S:startup-sequnce that will look like:
BlizKick * EXTRESBUF=1000000 HOGWAITBLIT SPEEDROM MODULE 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 BBlank NoClick ColdResetCard patchmath020-ALL romfixes romfixes2 LocalFast MoveVBR NewAlert SpeedyIDE QUIET
where all those numbers are the renamed kickstart files.
There are very few patches that are needed after an OS 3.9 ROM update - the tendency is to accumulate all sorts of patches till your Amiga is so heavily modified that it will… become something else; which means that software will have trouble running and you will end up with Gurus that are very difficult to trace down.
The usual debugging method when you have a pimped Amiga, is to disable all the patches, reboot and check if the issue occurs again - a painstaking experience that will drive you up the wall. As such, only tested and deemed stable patches will be mentioned.
The patches that every machine should include first are the following two essentials:
FBlit can be downloaded from Aminet but it is better to download it as part of Peter Keunecke (PeterK)'s IconLib because the archive contains a configuration file to match.
You can also read a short tutorial presenting a trick that will reduce chip RAM consumption when you combine PeterK's
icon.library with FBlit.
FText makes use of FBlit to render text in fast RAM and should be installed after FBlit in
Also by PeterK, TagLIFE is a rewrite of some functions in
utility.library and can be included in
S:startup-sequence without any harm.
BlazeWCP may be outdated via FBlit, nevertheless, it can be included in
S:startup-sequence without any serious harm and will benefit 32-bit RAM machines the most (A1200, A3000, A4000).
env-handler by Stephan Rupprecht is a tool that treats the
ENV: directory as its own separate disk. It has the advantage that it only loads environment data (such as default icons) only when they are needed and not at system bootup thus preserving memory. Furthermore, the tool has the capacity to offer a Workbench disk that represents the
ENV: directory. The
ENV: disk is flushed upon reboot and
env-handler copies what is needed from
ENV: dynamically on every system start. The tool is highly recommended, it seems to not destabilise the system or lead to strange errors.
An alternative is HappyEnv by Martin Gierich but
env-handler is newer and hence possibly more updated.
If you would like to push the envelope, just a bit, but still keep the Amiga pretty stable, the following patches are recommended and seem to be theoretically sound.
One of the patches worth trying is TLSFMem - this patch is mostly unstable but it is based on a paper on memory allocation optimisations that manages to reduce RAM access time complexity to mostly constant time (except deallocations that are linear, in the worst case). The TLSFMem patch is originally created by Chris Hodges and the original files can be scarcely found. Since the initial release TLSFMem has had two updates: from 1.4 (original) to 1.6 and finally the latest update is by Cosmos to 1.9.
You can download the Cosmos 1.9 patched archive from here:
To install, copy TLSFMem and TLSFMemPool to
SYS:C/ and then run
SetPatch and after
TLSFMem does offer a very noticeable performance increase and does seem stable but it will conflict with MuMove4K - so if you use MuMove4k, then you will need to make a choice. Furthermore, TLSFMem can be set up to work with RAD devices for a performance boost.
Some interesting patches are unfortunately breaking other operating system features and should be best not used or replace by newer system-compliant variants.
AmberRAM by Neil Cafferkey is a RAM disk replacement that unfortunately breaks soft links. The very first
MakeLink command from
SYS:C/MakeLink >NIL: RAM:disk.info ENVARC:SYS/def_RAM.info SOFT
will fail with the error message "feature not supported" and the cause is AmberRAM.
One of the immediate observable consequences is that the RAM disk cannot be snapshotted anymore (or rather, will forget its snapshot position).
Although AmberRAM seems stable, it is best not used because one cannot anticipate what other features are broken due to missing soft link support (for instance, the new OS3.9 Tools menu manager THE references a bunch of AREXX scripts that, in turn, reference C:MakeLink).
With OS3.9, the
MakeLink command is used in
S:startup-sequence to create a link from
RAM:disk.info such that the RAM icon will not appear ghosted. The relevant line in
SYS:C/MakeLink RAM:disk.info ENVARC:SYS/def_RAM.info SOFT
Unfortunately, if you use AmberRAM or similar, the RAM drive will not support soft-links and the command will fail on boot and you will need to comment out the
MakeLink line in
S:startup-sequence by pre-pending a semi-colon.
One of the nice features of PeterK's
icon.library is that tooltypes are supported on icons - unfortunately, due to the Workbench design, you cannot set tooltypes on disk icons and usually
ENVARC:SYS/def_RAM.info is a disk icon. However, due to
icon.library, you can convert
ENVARC:SYS/def_RAM.info to, say, a project icon by using
Typemenu and select
Filemenu and exit
Now, open the
ENVARC:SYS/ folder in Workbench and right-click the
def_RAM.info icon (if you cannot find
ENVARC:SYS/, then the
def_RAM.info icon is still of type disk and it will not show up!) and navigate to the Workbench menu
Icons→Information. Once the pane opens up, go to tooltypes and in the large textbox add
NoGhost - the
NoGhost tooltype will be read on startup by
icon.library and prevent Workbench from showing the icon ghosted.
SystemPatch by Nocciolino Sante is a blanket-patch that replaces a bunch of system functions with alleged optimised versions. All individual patches and be turned off by specifying command-line parameters.
Unfortunately, blanket-patching the operating system leads to deviations from the CBM specification - which is something that some programs might rely on. Quite trivially so, just running SystemPatch with the parameters suggested in the documentation makes the Amiga non-bootable.
Unless you know AmigaOS very well and approve of Sante's "optimizations", there is no way of telling which flags should be specified and which programs may be broken such that it is a good idea to steer clear of SystemPatch.