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 (S:startup-sequence). When 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

The 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 SetPatch.

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:

• use the accelerator features and patch individual modules and override the kickstart modules with the new modules injected by the accelerator, or
• create a custom kickstart using Remus and either burn a physical ROM chip or use the accelerator to kick the resulting file.

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:

• Use a tool such as Remus to dump the contents of a 3.1 kickstart ROM to a folder.
• Use a tool such as Remus to dump the contents of the DEVS:AmigaOS ROM Update file 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:

• Create a new work folder and copy over all the modules from the 3.1 kickstart ROM folder.
• Overwrite the files with the updated modules from the folder containing the modules that have been extracted from the DEVS:AmigaOS ROM Update file.

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 asl.library in 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.

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:

• Any patch by Thomas Richter should be applied because, at the time of writing, those patches are as close to an "official" update to the ROM as it gets.
• Peter Keunecke (PeterK) has an updated icon.library that 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 S:startup-sequence.

Finally, you can rename all the modules (exec.library, audo.device, battclock.resource, etc…) with numbers sequentially: 1, 2, 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:

• TRSaferPatches by Thomas Richter - this patch is a controller for other patches (it makes sure other patches do not tread beyond memory bounds, it maintains a list of patches so they can be potentially removed later, etc…)
• StackAttack2 by Thorsten Schölzel - this patch increases the stack size from startup to make sure that all programs have sufficient stack to run.

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 S:startup-sequence:

C:FBlit
C:FText

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 ENVARC: to 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:

• tlsfmem-1.9.lha

To install, copy TLSFMem and TLSFMemPool to SYS:C/ and then run TLSFMemPool from S:startup-sequence after SetPatch and after SaferPatches.

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 S:startup-sequence:

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 ENVARC:Sys/def_RAM.info to RAM:disk.info such that the RAM icon will not appear ghosted. The relevant line in S:startup-sequence reads:

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 SYS:Tools/IconEdit:

• open up ENVARC:SYS/def_RAM.info with SYS:Tools/IconEdit
• navigate to the Type menu and select project
• save the icon from the File menu and exit

Now, open the ENVARC:SYS/ folder in Workbench and right-click the def_RAM.info icon (if you cannot find def_RAM.info in 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.