Here are a few subjective, some objective highlights of the Commodore Amiga and why this antiquated retro-machine is still actual.

The Amiga series of computers counts itself amongst the first personal computers that ever existed and had the operating system built-in directly into the hardware; what one would recognize today as the BIOS conflated with the notion of a "kernel" was burned into two chips called the Kickstart that would perform both hardware recognition but would also set up a primitive window-manager generically called Workbench. With that said, the Amiga actually had a built-in operating system, with fully-functioning commands and even a graphical interface without just running games like a console would do.

Actually, the Amiga Workbench is perhaps the first "desktop manager" that ever existed that would be open to the public (of course, like others, inheriting the Xerox interface) as a "personal PC". Note that we're talking here about times when the standard x86 Intel-based or AMD processors did not exist at all so the standard "PC" era did not even commence.

Given the early-days, the Commodore Amiga was not designed with too much enforced consistency, in fact, the way of "modding" the interface, namely Workbench, was done by directly overwriting and injecting code into memory, with memory space truly not being delimited or separated by anything such that any program could write into memory anywhere it liked, which became both a curse and a blessing for the Amiga.

The curse of this freedom was that virii flourished in the Amiga world, and a lot of hacker or cracker groups formed around the platform because there were few protections to defeat in terms of "executable memory space"; definitely no hardware-backed CPU "noNX" flag and no ACL or permission system at all. The blessing was that some of the most elementary concepts of desktop management, software design and other "features" that are now modernly standardized were laid out. One such blessing is the fact that the Windows workbench did not really conceptualize "minimizing windows" but rather assumed that people would be working with one application open at once with the closest matching feature being the ability to cycle between applications as they are all running in full-screen in the background.

Of course, later on, as the Commodore Amiga got more powerful (up to and including the beginning of the 3D era), working with many applications on the same desktop became a necessity such that the concept of "minimizing windows" materialized by adding the ability to have applications minimized to an icon on the desktop. People that lived through that era, still miss the ability to minimize applications to the desktop instead of having them listed in one continuous bar at the bottom, even if for the ability of managing where these "iconifed applications" are placed. Later on, in the very latest iteration of Workbench, namely AmigaOS 4.1 that even requires a PowerPC to run, lots of features were added, for example a desktop dock that is, in fact, a backdraft of borrowing from the MacOS platform because the Amiga never had a desktop dock.

One thing that a user would "feel" when working with Workbench, is that it is very much centered on the concept of icons and windows, like a proper desktop manager. Workbench does not want to act like "software" and refrains from doing much else - perhaps an inherited consequence of actually being built into the hardware itself.

Lastly, much of the Workbench (both BIOS and desktop manager) was designed to be customizable and a complete opposite of modern-day lock-in economic strategies. Given that memory is writable anywhere by anyone, it is clear that any modification is possible but the idea behind the customization of the Amiga is that the developers themselves worked in a modular fashion while creating programmatic hooks that third parties could then leverage in order to create extensions. As a comparison, the buttons on a desktop window on Workbench are in fact separate classes with proper hooks that allow a programmer or a user to add more buttons whilst on Windows the number of buttons next to minimize, maximize or close is rather fixed and changing that would require injecting code to re-write the whole window processing routine.

Another distinctive feature of the Amiga and Workbench is the "RAM Drive", something that conceptually existed probably due to the Xerox filing system and the concept of treating everything, including devices later on with Unix as files. The Amiga by default has an implicit "RAM Drive" that is a virtual drive mounted in RAM and that can be used just like a regular drive. The concept is very useful and, actually, it seems even more useful modernly when RAM is not that expensive and abundant because working in RAM incurs no storage medium wear & tear and it is a very convenient way to very elegantly dispose of single-use files. For instance, "the download folder" on every computer, that ends up with a bunch of files, documents, executables, images, music or whatever else piling up with the user frequently forgetting that they have to throw away the garbage. On the Amiga, the "download folder" is typically set to RAM: for every application, such that any download is first stored in RAM, after which it can be installed, unpacked or moved away as necessary. After a computer restart, the RAM: drive is cleared automatically.

Amiga actually adopts early-stages Unix and Xerox philosophy by having a bunch of "virtual drives" that are materialized to the user as "assigns" to which the user can write and from which the user can read, very similar to the concept of "named pipes" on Linux. The "virtual drives", in turn, are created by devices and, for example, since at the time of writing this is the year of the A.I. tulip fever, even back in the 80s, the Amiga could synthesize text to speech with the command say or by writing to a virtual drive such as SAY:. The virtual devices could be created by users and gave rise to a plethora of inter-connectivity at the operating system level between shell scripts, programming languages and operating system artifacts that made the Amiga an exploration machine.

Perhaps the flashiest and the most technologically advanced feature that does not even exist even today is the architecture created by Commodore and Phase5 that allowed different architecture processors to exist. Whilst the Amiga was an m68k architecture with Motorola creating the CPUs, an expansion card could be added that would add a PowerPC processor to the machine.

The Amiga, in its later iteration managed to clock at whilst the the PPC would be much faster, clocking at up to . Interestingly, the speed of the m68k at was never a problem because every piece of software was written by hand without, say, relying on a graphics card for the extra eye-candy that some people were after.

What the Amiga did was to use clever system-wide context switches and delegate various tasks to different processors depending on what was being executed and it would do so concurrently! That means, you could have a Quake game up on the desktop running on the PPC co-processor whilst working on a document in a word-processor that ran on the m68k processor.

If you will, for a blasphemous comparison, this was like a machine that could both run Windows games whilst running on Linux on bare metal without using an emulation or virtualization shim - it simply ran both binaries by dispatching the bytecode to the processors depending on what sort of code marker it found withing the binary. Given that both CPUs were running different code that was also contextualized by the architecture itself, this was perhaps one of the earliest forms of symmetric multi-processing (SMP), concurrency and parallelism to ever exist that was "lost" for a while until Intel (re-)discovered the feature with the Core2 Duo, the very first Intel two-core processor (that, with industrial multi-processor machines aside, that were not consumer-ready).

In terms of gaming and games the Commodore Amiga was part of the early days catching the inception of the first Nintendo, then the Super-Nintendo, respectively the Sega Genesis and then Sega Megadrive while co-existing in the same timeline.

The early days were marked by a bunch of experimental games that even "indie" game developers do not dare create. These were the days where a game could be anything you liked such that "game categories" were not even possible to create, compared to modern times were games all fall in either this or that category such as first-person shooters, racing games, platformers, etc.

One example is Sentinel (a game created by Geoff Crammond for the BBC Micro), a much cherished game by us, that is... very tough to classify. The perspective of the player is first-person but there is no shooting to be done. The game is very the embodiment of "king of the hill", but that is a "game mode" not a "game category" and it is a single-player game. On top of the hill, there is a creature, a person or enemy that rotates around randomly. The game is turn-based and after every player move, the creature on top of the hill rotates. If the creature sees the player, or rather the square that the player is on, the creature can destroy the player. The purpose of the game is for the player to move around the hills and try to sneak up to the creature to the point that the player can see the square that the creature stands on. When the player can see the square that the creature stands on, the player can destroy the creature and win the game!

Strategy game? Not really because there are no real "units". Puzzle? Close but this is too advanced compared to "Bubble breaker". RPG? Actually that would work better but still it's almost chess in terms of being closer to puzzle. Certainly not a racing game. An FPS? Well, there is nothing to shoot except one single enemy. Maybe a turn-based strategy FPS? That's more like it. A turn-based strategy FPS! A genre that does not even exist today.

Another example is Marble Madness created by Atari where the player is expected to guide a ball with perils, boosters and advantages similar to a racing game or an RPG through a maze using the mouse or the keyboard. The ball itself is programmed with physical properties, including elasticity which makes some of the ordeals difficult, like having to jump ledges by jumping or falling onto something at the right time.

One modern game genre that has been dormant but now fairly re-emergent that we also mentioned as part of game innovation is a "vehicle survival" game named Road Raider. This is a "hybrid" game in terms of gameplay, being a racing, fighting game, survival game where the player can and has to also get out of the car in order to complete missions as top-down RPG similar to Diablo as well as purchase items from stores pertaining to both the player and the vehicle. We categorize this game as vehicle survival which is the dormant but looming genre that has been around for a while and the terminology is spelled out thusly because the purpose of the game is shared both by the vehicle and the player. That is, both the player and the vehicle must survive in order to complete the game and additionally the purpose of the game is to survive. At best, with modern categorization, this would be closest-described as an RPG given all the different elements.

Overall, the idea is that these are the origins of computer games such that studying modern games or analyzing them would greatly benefit from knowing about the origins of the ideas used to create modern games. Of course, given the early days, some of these games were utter disasters and now float on pure notoriety than being a "factually good game", with the puzzle involving spelling out "Rumplestiltskin" in Kings Quest I being perhaps the most memorable example. Many modern games are actually "so good" because they rely on the experience gained from the early days, with catastrophes and calamities being more or less prevented and most claims against games being "bourgeois" by comparison to some of the early disasters. Lots of these games were factually "bad games" yet the melancholy and the fact that they represented the origin kept them being relevant and mentioned. One major success to be mentioned would be Donkey Kong Country that we include amongst our memorable games due to the technological achievement of a 3D game without using a dedicated graphics card.

Going around inserting "Fish Disks" disks into the Amiga became its own purpose. A famous collector named "Fred Fish" went around buletin boards, crackers groups and Usenet collecting Amiga software and games and then placed them onto floppies that were then mass-copied and shared. A game like "Racter" (created in 1984 by Mindscape) is really the equivalent of the more recent ChatGPT which, behind the curtains, is not more than an Eliza chat bot on steroids that has been adorned with a bunch of pre-programmed knowledge - it is the same thing that inspired the SecondLife Racter script.

Interestingly, the Amiga was perhaps one of the first platforms to come up with "hardware expansions" for consumers. As an example there's the A500 that had a trap door underneath the unit that allowed the RAM to be expanded as well as having a special connector to add an external hard-drive (older hardware was bulky, heavy and unreliable).

Aside from expansions that plugged directly into the computer's bus lines, the Amiga had a plethora of connectors at the other edge that could be used to connect a large array of hardware, such as a printer, banana audio jacks were provided, both SCART video and RCA, etc. In fact, the Amiga went as far as to include a reverse TV tuner that would allow the user to use the Amiga directly with their standard TV antenna input.

It took IBM computers and their subsequent knockoffs a lot of time to even agree on PCI standardization, and the Amiga is commonly known as a pre-PCI or pre-ISA era computer yet ulterior developments, for example, by Elbox, allowed a PCI bridge to be attached to the Amiga in order to use 3D graphics cards like the Voodoo, audio cards and even input TV tuners that allowed watching TV channels.

It's clear that development takes place all the time but the Amiga was a leap, even if due to timely trends, that is not really comparable to anything else. There was really nothing that could not be connected or made to work with the Amiga. This is not really a criteria that even is on the table when comparing devices anymore, except for nerds that are happy when their devices include a bunch of ports, the Amiga was a trendsetter for interoperability and extensibility way, way before IBM PCs even started to support color monitors.

Window and icon positions are not saved by default on Workbench. To save the positions you must go to the Workbench menu and select either "Window->Snapshot->All" or "Icons->Snapshot".

On a default install on newer Workbench variants (such as Workbench 3.1) Workbench is contained within a window. In order to have Workbench be the default backdrop window, you can go to the Workbench menu and tick "Backdrop" (or AMIGA+B). Then, to make the setting persist across reboots, go to the Workbench menu, then to "Window->Snapshot->All".

After applying SystemPatch, anti-virus programs will refuse to work. In order to make them work again, edit the S:user-startup file and find the SystemPatch call and append the -LoadSeg argument to it:

;BEGIN SYSTEMPATCH
C:SystemPatch NT Q -LoadSeg
;END SYSTEMPATCH

• One blink: Keyboard ROM check failed.
• Two blinks: Keyboard RAM check failed.
• Three blinks: Watch dog timer failure.
• Four blinks: A short between two lines or the special control keys.

Every Amiga keyboard blinks once when switched on.

• Red: An error was found in the ROM.
• Green: An error was found in Chip ram.
• Blue: An error was found in the custom chips.
• Yellow: The CPU has found an error before the error trapping software (Guru) has been activated.

1. Clears all memory of old data.
2. Disables DMA and interrupts during the selftest.
3. Clears the screen.
4. Checks the processor is working.
5. Changes the screen colour.
6. Do a checksum test in the ROM.
7. Changes the screen colour, again.
8. Begins the system startup.
9. Checks RAM at address $C0000 and moves SYSBASE there.
10. Test all Chip ram.
11. Changes the screen colour, AGAIN.
12. Checks that the software is being executed.
13. Changes the screen colour, for a laugh.
14. Sets the chip RAM to be accessed.
15. Links the libraries.
16. Checks for fast RAM.
17. Turns the DMA and interrupts on.
18. Starts a default task.
19. Checks for an accelerator or a maths coprocessor.
20. Checks the processor again to see if there is an error.
21. If an error is found the system is reset.

To place an icon on the desktop such that it persists across reboots:

• Move the icon to the desktop.
• Select the icon.
• Go to the Workbench or Icon menu and select Leave Out.
• Move the icon to any place and then go to the Workbench or Icon menu and select Snapshot.

To set the current date and time and to save it to the RTC (provided that you have an RTC installed), first issue:

date 19-Nov-04 16:45:0

which sets the system time (in military time).

After that, save the time to the RTC with setclock:

setclock save

You can create a batch script easily with the ed stream editor. After that, copy an application icon (or any other icon with its type set to app - for example, use the seticontype utility) and give it the same name as your script plus the suffix .info. You will thus obtain two items (in this example, the script name is goodday):

goodday
goodday.info

After that select goodday.info and right-click to access the menu and select Icons->Information... (shortcut AMIGA+I).

Set the Default Tool: to C:ICONX and tick the Script and Executable boxes. Finally, save the changes to the icon and double click the icon to run the script.

For drives, we have:

in addition to logical devices that can be assigned.

Common devices:

Usual logical devices:

Copying on the Amiga is usually performed with the hot-key Right AMIGA+C and pasting is performed with Right AMIGA+P

AmigaOS 3.9 boing bags contain a password-protected zip file to store the updates which is annoying in case you want to burn your own ROM and will require you to install AmigaOS 3.9. However, the passwords are listed here:

and you can uncompress the archives using plain unzip.

Under Amiga OS 3.9 SetPatch can be used to turn on disk validation before rebooting. This can be accomplished by adding the WAITFORVALIDATE option to SetPatch in S:Startup-Sequence.

Here is a summary of the various drive capacities that can be used on an Amiga depending on:

• the filesystem used (32bit as in FFS or 64bit as in PFS/SFS)
• the scsi.device in place
• the total capacity of the partitions and the corresponding drive.

In case you are using SystemPatch and using some anti-virus software, the LoadSeg patches from SystemPatch will modify xvs.library. To prevent patching xvs.library, you can install SystemPatch using the -LoadSeg flag:

C:SystemPatch -LoadSeg

Some devices, such as RAM-based devices (ramdisk.device, ramdrive.device), found in the mountlist DEVS:mountlist or DEVS:DOSDrivers/ for Kickstart 2.04 and above can be configured to have a larger size than a floppy disk.

Typically, these devices have the following settings:

LowCyl = 0
HighCyl = 79
BlocksPerTrack = 11

such that the formula:

yields the size in kilobytes of the resulting device. In the default case, where these devices simulate a standard DS/DD diskette, the values above compute to 880KiB.

By changing HighCyl, LowCyl and BlocksPerTrack in the mountlist files you can create a virtual device of any size. Suppose you wanted a drive of, say 64MiB (65536KiB), in that case, with a little bit of maths, one obtains:

Now, the low cylinder LowCyl does not need to be set to a high value, the disk can very well start on cylinder 0, such that the equation can be pushed a little further:

With this equation, all the variables can be substituted in order to obtain the value of HighCyl:

Now the mountlist can be modified (or tooltypes changed in SYS:Devs/DOSDrivers/ and the value of the high cylinder (HighCyl) set to 5957 in order to obtain a 64MiB drive. The device configuration for a 64MiB drive will thus include:

LowCyl = 0
HighCyl = 5957
BlocksPerTrack = 11

In case you get an Intuition requester when Workbench loads, more precisely, whilst executing S:startup-sequence, that says to close all windows then your S:startup-sequence may be printing something to the shell.

All patches and commands in S:startup-sequence are usually ran with a QUIET parameter (or by redirecting output to NIL: via >NIL:) so they do not print out messages or else the Intuition requester will pop-up when Workbench loads before the last EndCli instruction.

Workbench automatically mounts drives on boot if the corresponding mount file icons in DEVS:DOSDrivers/ have an entry in their tool-types set as ACTIVATE=1 (or MOUNT=1 for Workbench 2.0). The drives are mounted sequentially via the startup sequence:

C:Mount DEVS:DOSDrivers/~(#?.info)

such that if mounting one drive fails, then the rest may be skipped. The Amiga can be rebooted without a startup-sequence in order to attempt and mount each drive manually to find out which of the mount files in DEVS:DOSDrivers/ fails to mount.

The aic78xx.device driver from AmiNET contains few instructions on how to set up the Adaptec SCSI cards. Essentially, the device file aic78xx.device has to be copied to DEVS: and then the executable AicSCSI has to be copied over to C:. Following the documentation, AicSCSI has then to be run from either startup-sequence or user-startup. Unfortunately, that is insufficient since startup-sequence will mount any devices found under DEVS:DOSDrivers such that, at best, C:AicSCSI should be ran before C:Mount Devs:DOSDrivers/~(#?.info).

Users have reported that just having a mount list in DEVS:DOSDrivers will not allow the Amiga to boot, getting stuck at the C:Mount Devs:DOSDrivers/~(#?.info) line. Similarly, adding C:AicSCSI before C:Mount Devs:DOSDrivers/~(#?.info) will also prevent the Amiga to boot.

The issue appears to be related to the Mediator not being properly initialized when the aic78xx.device or the AicSCSI binary get loaded - either by the mount line or by directly loading AicSCSI.

The solution is to re-arrange some lines in startup-sequence, placing C:Mount Devs:DOSDrivers/~(#?.info) after C:LoadMonDrvs. In other words, the correct sequence of commands should be:

BindDrivers
 
C:LoadMonDrvs
C:AicSCSI
C:Mount Devs:DOSDrivers/~(#?.info)

and should allow the Amiga to boot and to mount devices when Workbench boots up.

The mixer application provided on the MM CD by Elbox crashes the Amiga right from the startup sequence. Officially, Elbox recommends a third party application such as GhostMix to manage the sound card. Unfortunately, regardless what application is used, the mixer just does not want to remember the settings and restore them on boot.

For instance, GhostMix' documentation mentions the install procedure where GhostMixer should be ran (mind that GhostMixer is a Magic User Interface (MUI) application and needs MUI to be installed) to save the settings, then GMStart is supposed to be copied into C: and called from S:startup-sequence. Regrettably, that does not work and GMStart will just bomb out with GMStart Error and some undecypherable characters hinting to an outright corrupt binary.

To work around all these issues, create the directory ENVARC:Mediator/Mixer:

makedir ENVARC:Mediator/Mixer

and only then load up the mixer application (ex, GhostMixer), make the necessary settings and save. In case you are using GhostMix, you can delete C:GMStart since the settings will be restored on reboot.

Ultimately, if all else fails, TaskiMixer seems to work best:

• taskimixer.lha

Simply unpack the archive, copy the icon into Prefs/ and TsiMixerInit to C:. Then edit S:user-startup and add the line C:TskiMixerInit at the very end.

The following command installs a bootsector:

install DF0:

to a diskette inserted in DF0: and it is sufficient to make the Amiga boot to a CLI.

The following commands create the C: command directory and the S: startup directory necessary to get Workbench running:

makedir DF0:s
makedir DF0:c

The LoadWB command from C: must be copied into C::

copy C:LoadWB to DF0:c/

Finally a startup sequence file is created in DF0:s/startup-sequence containing the following commands:

Loadwb
endcli

The diskette is now bootable and will load Workbench on startup.

Hyperion Quake 2 seems to be incompatible with the "Joystick monitoring" feature of BlitzBlank such that if BlitzBlank is running when Quake 2 is ran, the whole screen / view will spin around as if the turn left or turn right key is being held down. The result is an unplayable mess with a lot of headaches to debug what the culprit may be: clues would indicate some mouse wheel conflicts since "turn left" and "turn right" are by default bound to "mouse wheel up" and "mouse wheel down", after remapping the turn keys further hints are provided by some random error messages shown in-game by Quake stating that some "joy" button is not mapped indicating that some joystick / joypad signal is being generated and picked up by Quake. Diabling FreeWheel, or MultimediaKeyboardMM does not seem to fix the issue and, as it turns out, the joystick monitoring feature of BlitzBlank is somehow generating signals on its own.

The easiest fix is to simply disable the "Joystick-Check" feature of BlitzBlank from BlitzBlankPrefs.

The following file contains a Magic User Interface (MUI) distribution with all the available plugins for MUI bundled in.

• mui38repack.lha

To use this package, simply replace the old MUI folder with the folder from this bundle and make sure that the S:startup-sequence file contains the MUI section:

;BEGIN MUI
if exists "Sys:System/MUI"
   assign MUI: "Sys:System/MUI"
   if exists MUI:Libs
      assign add LIBS: MUI:Libs
   endif
   if exists MUI:Locale
      assign add LOCALE: MUI:Locale
   endif
   version >nil: exec.library 39
   if not warn
      if exists MUI:Docs
         if exists HELP:dummy ; do not remove
         endif                ; this entry!
         assign add HELP: MUI:Docs
      endif
   endif
endif
;END MUI

The top-level directory contains a directory named 020+ wherein lies a patch created by RedSkull @ Digital Corruption that patches muimaster.library for 020 or better processors.

The Libs/ sub-directory contains the libraries:

• date.library
• imagepool.library
• mysticview.library
• vlab.library

that are not part of the standard MUI distribution and are supporting libraries for the various MUI classes that have been bundled. Since the standard MUI assign (from the snippet in the "Installing" section extends the LIBS: directory with MUI:Libs/ then moving these libraries is not necessary and they can be left where they are.

The Libs/ as well as the Libs/mui sub-directories contain duplicated files for various processors. This bundle by default uses the standard 000 files but in case you benefit from a 020 or better processor, feel free to use a file manager and replace the corresponding files by their counterparts. For instance, for a 020 CPU or better, the Libs/mui/ImageDB.mcc file would be replaced by Libs/mui/ImageDB_68020.mcc.

When using RTG graphics with Picasso96, depending on the configuration, the public screens may not work at all such that any program that needs to render onto a separate public screen other than the Workbench screen will be simply inaccessible.

To get public screens working properly on Picasso96 when using RTG graphics, the monitor file has to be edited and the following Picasso96 tooltypes set:

• DisplayChain=YES - this allows the Amiga signal to be passed through,
• FakeNativeModes=YES - this allows software that uses public screens to render properly

Even though certain programs may experience issues with screen promotion, an utility such as ModePro will allow the user to promote public screens without the use of the fake native modes built into Picasso96.

When upgrading to AmigaOS 3.2, the following issues concerning the Elbox FastATA controller are to be observed when the Amiga boots:

• LoadResident is attempting to patch scsi.device but scsi.device might have been already patched and made resident by the Elbox FastATA driver (ATA3.driver) such that LoadResident has to be run with the DOWNGRADE switch or LoadResident will fail patching scsi.device and skip the rest of the patches.
• SetPatch fights over scsi.device with the Elbox FastATA driver (ATA3.driver) because SetPatch wants to apply the LED patch, such that SetPatch must be run with the NODRIVELEDPATCH parameter,
• ATA3.driver can be run after SetPatch and made resident or not

Thus, a working configuration snippet from S:startup-sequence would end up looking like the following (just the sequence and the switches are important):

C:Version exec.library version 47 >NIL:
If Warn
  C:LoadModule L:System-Startup ROMUPDATE DOWNGRADE
EndIf
 
If Exists C:ATA3.driver
  C:ATA3.driver QUIET
EndIf
 
C:SetPatch NODRIVELEDPATCH

For good measure, force delete the DEVS:A1200/scsi.device such that the default OS 3.2 scsi.device file does not exist at all:

delete force SYS:Devs/A1200/scsi.device

In case a revert is desired, the SYS:Devs/A1200/scsi.device file can be found on the modules disk of the OS 3.2 distribution.

The NameFromLock AmigaOS function will obtain a fully qualified path to a directory or file:

lock = Lock(file, ACCESS_READ);
path = NameFromLock(lock, buffer, PATH_MAX);
fprintf(stdout, "%s\n", path);

where file can be the relative (or absolute) path to a file or directory.

Quake uses a pak0.pak inside the ID1 directory that contains some of the more basic models, sounds and maps. Cosmos built an alternate pak0.pak made to speed up Quake considerably by removing, updating or fixing some the more demanding assets.

• pak0.lha

The pak0.pak file just has to be replaced by the new pak0.pak file provided from the archive. In case a version of quake is used that does not use pak0.pak files such as QuakeWOS the PAK file can still be used. The contents of the ID1 folder inside the quake folder must be overwritten with the files from the unpacked pak0.pak file.

The following RAM settings should be made in the BlizzardPPC BIOS (hold ESC on bootup to access the BlizzardPPC BIOS) in order to ensure a stable system:

• Free Config
• 68k No Read Waitstate
• 68k No Write Waitstate
• 68k PreCharge
• PPC Read Waitstate
• PPC Write Waitstate
• PPC PreCharge

The following games manifest various issues ranging from a "white screen", "black screen", unexplained lag to outright crashing from the get-go:

The solution is to use the Warp3D V4.0 library instead of the most recent Warp3D V5.1.

When starting Quake 1, if Quake crashes and the following error is displayed:

I_Error: Hunk_Alloc: failed on 1544814608bytes

attempt to delete the ID1/glquake folder and restart the game.

A feature of Workbench is that, using a button, some application windows will minimize into a Desktop icon. The Amiga Workbench had no concept of "minimizing windows" and there was no way to hide an application unless the application itself provided a way to do so.

Software like IconifyGadget or the more advanced PowerWindows(NG) was created that would patch Workbench to allow any and all desktop windows to be iconified.

Unfortunately, all applications that would have been iconified using the new patched Workbench feature would all display the same default icon, which is extremely confusing. For that purpose, software like appchange appeared that could be combined with the new "minimize to icon" feature that would allow configuring an icon for each minimized application in part.

ImageMagick is able to extract image files from Amiga .info files. For instance:

convert def_disk.info disk.png 

will extract the image icon from def_disk.info to a PNG named disk.png within the same directory.