------------------------------------------------------------------------------ Desk Accessory Selector - by Les Kneeling ------------------------------------------------------------------------------ Why use a selector? ------------------- At first sight the amount of memory in an Atari ST appears to be enormous. There is, however, a fundamental law of computing which says that code will expand to fill the memory available and the last five years have confirmed this with the ST. Nowadays programs such as Degas Elite and Timeworks use up a megabyte of memory with the addition of a few fonts. Others like Calamus and Harlekin need a minimum of a megabyte to get going. Really anti-social programs like Signum leave enough space for the accessories but do not allow them to be called up. Until recently desk accessory selectors were written to get around the limit of six applied by the desktop. Now the amount of memory available in the computer is often the limit. How does it work? ----------------- When the ST is switched on it goes through a number of stages of initialisation. It starts up the operating system, checks to see if there is a hard disk, runs programs in the AUTO folder, loads the desktop.inf file, runs GDOS, and loads desk accessories. The fact that it deals with the programs in the AUTO folder before the desk accessories means that an automatically run program can be used to control which ones are loaded. The computer assumes that a file in the root directory of the boot disk (or drive C if a hard disk is used) with a '.ACC' extension is an accessory, anything else is not. The crude, but effective, method used by every selector that I have seen is to rename unwanted accessories with a '.ACX' extension. This means that when the AUTO programs have run their course and the operating system loads the accessories, the '.ACC' ones will be loaded and the '.ACX' ones will not. The AUTO folder --------------- There are a few things to bear in mind when using the AUTO folder. First, the programs must have a '.PRG' extension even though they do not use GEM. The normal convention is that programs which do not use GEM have the TOS extension. Second, the order in which the programs execute is the order in which they appear in the directory. The desktop always sorts the directory listing in some way and cannot be used to predict which AUTO program will be run first. There are two ways around this problem. There are a number of programs in the Public Domain which will list the directory without sorting (DosAcc, my PD accessory has this facility and is available from the ST Club). The alternative is to create the AUTO folder from scratch and copy the programs into it in the required order of execution. Some experimentation may be needed to get things in the right order but most AUTO programs have come with some guidance. The exception is the hard disk patch AHDI - which must come first. Third, there is a little quirk in the operating system which crashes the computer after the AUTO programs have run and before the desk accessories load. Jeremy Hughes, of Fontkit fame, believes that the number of AUTO programs is the cause and recommends that a 'do nothing' program is included in the AUTO folder to fix this if it occurs. I think that the system crashes in a rather more random way than this but I admit that I have not researched it in any way. The Listing ----------- That is the background to the program, now to the details. The listing is very fully commented but there are a couple of points which are worth talking about. AUTO programs run at a stage in the initialisation process where there are only two graphics resolutions - low and high. If the desktop.inf says that the computer should start in medium resolution this happens after the AUTO programs have finished executing. The first thing that the program does is to find out whether it is running in colour or mono and sets a flag. According to the state of the flag a two or four column display is produced. The program reads the root directory twice. First to find all of the files with a '.ACC' extension, and second to find the files with a '.ACX' extension. The filenames are added to a linked list. Each time a filename is read malloc is called to reserve a new chunk of memory big enough to hold a struct which consists of a string to hold the filename and pointers to the previous and next entries in the list. Using the pointers the program can move back and forward through the list as required. The list is displayed on the screen and a call to Bconin() waits for keystrokes which are then fed to a switch-case statement for interpretation. This is a little more complex than it appears because Bconin() returns a long and the switch will only accept an int. It is possible to ignore this difference because the 'normal' keyboard characters are returned in the low word. On the other hand the cursor keys and other 'special' keys are returned in the high word. I used a union to get around the problem - it is treated as a long for the call to Bconin() and is split into key.split.lowword and key.split.highword so that it can be fed to the case statements. The last section of the listing is a group of procedures to make the screen handling more readable. Most of them are self explanatory, but perhaps auto_overflow_off() needs some explanation. When the screen is being used as if it was a character device (the VT52 emulator), writing a character to the last character space on the last line of the screen will cause the screen to scroll. I wanted the menus on the bottom of the screen to go right into the corner so I called auto_overflow_off() before displaying them. This disables the trigger for the scroll and keeps the screen tidy. It is important to return the VT52 to normal - just in case. Finally ------- The program was written to be extendable. In fact the facility to 'Clear all accessories' was 'bolted on' after the program was finished. Other extensions can be added simply by adding cases to the switch statements. Although it was written in Laser C it should work with any other K&R specification compiler. Bolt-on number 2 ---------------- To accomodate programs that allow accessories to be loaded from directories other than the root, I have added a configuration file to ACCSEL. To change the directory type c then enter the full path for the directory, say C:\accs and hit return. The display updates to show the accessory list. To save the configuration file type w. A file called ACCPATH is created in the root directory. This will be read next time the program is used and that directory will be set as the default.