The ST Guide Part 7: The Auto Folder

Overview

Every Atari user will at some point have to delve into the Auto folder. The Auto Folder is a folder located on the boot drive, usually either the floppy disk (Drive A on the desktop) or the first partition of the hard disk (usually Drive C on the desktop). So what does the auto folder do? Well the ST's OS will try and load any programs (with a file name along the lines of *.prg) placed in the autofolder automatically. This all occurs before the OS fully initialises, i.e. before GEM and the desktop fully load. The presence of an active folder will usually be given away by text being printed on the screen.

What is it used for?

Typically the auto folder was used to provide patches and system enhancements to GEM. Patches like Pinhead, foldrxxx or poolfix can be placed in the auto folder and can patch GEM bugs that would cause problems. Other typical programs used in the auto folder are screen accelerators like NVDI or Turbo ST, graphic/ font/ printing system programs like SpeedoGDOS, GDOS, NVDI (again) or replacement file selectors such as UIS III or Selectric. In fact the range of programs that can use the auto folder is quite diverse. Screen savers and complete operating systems like Magic also use the auto folder to initialise. Programs which need GEM, such as Atari Works or Papyrus, which need GEM cannot autoboot from the auto folder. They can be persuaded to run automatically using the GEM desktop install application menu option (with this option when using TOS 1.02 or below, then you also need a program called startgem.prg in the auto folder to achieve this).

Auto folder conflict!

Auto folder programs don't necessarily get on with each other. Some programs do strange things to achieve their objectives, others don't take into account changes that may have been made by other auto programs. Some programs are so ubiquitous that you should have no problems with them as they would have been on most developer systems as well. Pinhead and Foldrxxx are examples of this type, although you shouldn't completely rule them out completely. GDOS, SpeedoGDOS and NVDI should be of this type as well, but they can cause problems. The results of auto conflict usually result in the ST stopping during the boot process (while the programs are writing to the screen before the GEM desktop arrives), or perhaps even a reset. This can result in a continous loop on floppy and hard drive systems where the OS starts loading the operating system, encounters the problem, crashes and then starts the process again. The way to get round this is to hold down alternate on the keyboard to skip the auto load sequence on hard disks, or perhaps boot from a floppy with no problems. Alter the auto folder as below and then try again. It can lead to a lot of frustration until you solve the problem. You should also be aware that Auto folder programs can also clash with Accessory programs, causing similar results.

Auto folder conflict solutions

First thing to check is that there are two programs in the auto folder essentially doing the same thing. Turbo ST and NVDI aren't going to get on as they essentially do the same thing, i.e. accelerate the screen output. If this isn't the problem look at the order of the programs in the auto folder. You can do this reasonably easily on versions of TOS 2.06 or higher by going to the 'view' menu on the desktop and selecting 'no sort' (while viewing the auto directory in a window). The running order is determined by the order in which files were copied onto the disk. You can manually alter this by copying everything out of the folder and then copying them back in, in the order you want them to run. This is feasible on a fast large hard drive but a nightmare solution on a floppy based ST. However a good alternative is to use a program called Autosort, or the similar Dirsort, which can re-order the programs for you, the latter having the added benefit of being able to sort the running order of any directory, which can also help with problem accessories. You can use this program to choose in what order programs will run, an example of which might be say the Magic operating system, which likes to be one of the first programs to run, or NVDI, which prefers to be one of the last. Playing about with the order will usually allow a lot of auto programs to run. It is better to try and run only the minumum you need however, if nothing but to limit the amount of memory lost to these programs. Typically a standard ST hard disk system for word processing with Papyrus would need only a few programs for stability. Foldrxxx.prg is essential for any hard disk, and some sort of disk cache can speed up operations considerably, but if you are using HD-Driver, you won't need to use even these. Therefore you could just get away with a font/ printing system like NVDI or SpeedoGDOS. So how do you go about disabling auto programs?

Disabling Auto programs

The convention is rename the extender on the program label from *.prg to *.prx, which effectively renders them inactive. You can get programs to do this for you, some of which can be themselves autobooted. X-boot or Superboot are examples of these sort of programs. They will allow you to choose which programs run before they actually get the chance to, so are ideal for reducing conflict. Some of them, or indeed most of them can also do other clever things like choosing GDOS set-ups or which desk accessories get run. They are not to everyones taste however.

Multiple Auto folders

If you don't like boot managers you might want to use several auto folders with different setups that you can re-name and then just reset to get the right set-up. This works well if you have enough disk space, and have a TOS version greater than or equal to TOS 1.04. Older versions of TOS have difficulty renaming folders, although they can be coaxed into doing so with a program like Kobold or UIS III.

Do games use the auto-folder?

Yes and no. Most commercial games bypass the OS completely, using a small section of code in the floppy disk boot sector to initialise the system and then run the game. They do this to avoid dealing with the overheads of GEM and TOS (the operating system) and this allows them to pack more punch. This was particularly important on 512k systems where loading GEM would swallow a substantial chunk of this memory. Some games do however use the autofolder to load, these are usually games that don't have a copy protection based on weird floppy disk formats, but not necessarily. Equally some games use neither either method and can be run from the desktop. These are few and far between however.