home *** CD-ROM | disk | FTP | other *** search
/ No Fragments Archive 10: Diskmags / nf_archive_10.iso / MAGS / ST_USER / 1990 / USERDC90.MSA / TEXT_ACCSEL.TXT < prev    next >
Text File  |  1990-10-01  |  7KB  |  124 lines
  1. ------------------------------------------------------------------------------
  2.                   Desk Accessory Selector - by Les Kneeling
  3. ------------------------------------------------------------------------------
  4.  
  5. So you want to try it before reading the rest of this file! - OK
  6.      - if you don't already have one, make a new folder, named AUTO, 
  7.        on your boot disk
  8.      - copy ACCSEL.PRG into it
  9.      - reset the computer
  10.      - if it doesn't work carry on reading
  11.  
  12. Why use a selector?
  13. -------------------
  14.      At first sight the amount of memory in an Atari ST appears to be 
  15. enormous. There is, however, a fundamental law of computing which says that 
  16. code will expand to fill the memory available and the last five years have 
  17. confirmed this with the ST. Nowadays programs such as Degas Elite and 
  18. Timeworks use up a megabyte of memory with the addition of a few fonts. Others 
  19. like Calamus and Harlekin need a minimum of a megabyte to get going. Really 
  20. anti-social programs like Signum leave enough space for the accessories but do 
  21. not allow them to be called up.
  22.  
  23.      Until recently desk accessory selectors were written to get around the 
  24. limit of six applied by the desktop. Now the amount of memory available in the 
  25. computer is often the limit. 
  26.    
  27. How does it work?
  28. -----------------
  29.      When the ST is switched on it goes through a number of stages of 
  30. initialisation. It starts up the operating system, checks to see if there is a 
  31. hard disk, runs programs in the AUTO folder, loads the desktop.inf file, runs 
  32. GDOS, and loads desk accessories. The fact that it deals with the programs in 
  33. the AUTO folder before the desk accessories means that an automatically run 
  34. program can be used to control which ones are loaded.
  35.  
  36.      The computer assumes that a file in the root directory of the boot disk 
  37. (or drive C if a hard disk is used) with a '.ACC' extension is an accessory, 
  38. anything else is not. The crude, but effective, method used by every selector 
  39. that I have seen is to rename unwanted accessories with a '.ACX' extension. 
  40. This means that when the AUTO programs have run their course and the operating 
  41. system loads the accessories, the '.ACC' ones will be loaded and the '.ACX' 
  42. ones will not.
  43.  
  44. The AUTO folder
  45. ---------------
  46.      There are a few things to bear in mind when using the AUTO folder. 
  47.      First, the programs must have a '.PRG' extension even though they do not 
  48. use GEM. The normal convention is that programs which do not use GEM have the 
  49. TOS extension.
  50.  
  51.      Second, the order in which the programs execute is the order in which 
  52. they appear in the directory. The desktop always sorts the directory listing 
  53. in some way and cannot be used to predict which AUTO program will be run 
  54. first. There are two ways around this problem. There are a number of programs 
  55. in the Public Domain which will list the directory without sorting (DosAcc, my 
  56. PD accessory has this facility and is available from the ST Club). The 
  57. alternative is to create the AUTO folder from scratch and copy the programs 
  58. into it in the required order of execution. Some experimentation may be needed 
  59. to get things in the right order but most AUTO programs have come with some 
  60. guidance. The exception is the hard disk patch AHDI - which must come first.
  61.  
  62.      Third, there is a little quirk in the operating system which crashes the 
  63. computer after the AUTO programs have run and before the desk accessories 
  64. load. Jeremy Hughes, of Fontkit fame, believes that the number of AUTO 
  65. programs is the cause and recommends that a 'do nothing' program is included 
  66. in the AUTO folder to fix this if it occurs. I think that the system crashes 
  67. in a rather more random way than this but I admit that I have not researched 
  68. it in any way.
  69.  
  70. The Listing
  71. -----------
  72.  
  73.      That is the background to the program, now to the details. The listing is 
  74. very fully commented but there are a couple of points which are worth talking 
  75. about.
  76.  
  77.      AUTO programs run at a stage in the initialisation process where there 
  78. are only two graphics resolutions - low and high. If the desktop.inf says that 
  79. the computer should start in medium resolution this happens after the AUTO 
  80. programs have finished executing. The first thing that the program does is to 
  81. find out whether it is running in colour or mono and sets a flag. According to 
  82. the state of the flag a two or four column display is produced.
  83.  
  84.      The program reads the root directory twice. First to find all of the 
  85. files with a '.ACC' extension, and second to find the files with a '.ACX' 
  86. extension.
  87.  
  88.      The filenames are added to a linked list. Each time a filename is read 
  89. malloc is called to reserve a new chunk of memory big enough to hold a struct 
  90. which consists of a string to hold the filename and pointers to the previous 
  91. and next entries in the list. Using the pointers the program can move back and 
  92. forward through the list as required.
  93.  
  94.      The list is displayed on the screen and a call to Bconin() waits for 
  95. keystrokes which are then fed to a switch-case statement for interpretation. 
  96. This is a little more complex than it appears because Bconin() returns a long 
  97. and the switch will only accept an int. It is possible to ignore this 
  98. difference because the 'normal' keyboard characters are returned in the low 
  99. word. On the other hand the cursor keys and other 'special' keys are returned 
  100. in the high word. I used a union to get around the problem - it is treated as 
  101. a long for the call to Bconin() and is split into key.split.lowword and 
  102. key.split.highword so that it can be fed to the case statements.
  103.  
  104.      The last section of the listing is a group of procedures to make the 
  105. screen handling more readable. Most of them are self explanatory, but perhaps 
  106. auto_overflow_off() needs some explanation.
  107.  
  108.      When the screen is being used as if it was a character device (the VT52 
  109. emulator), writing a character to the last character space on the last line of 
  110. the screen will cause the screen to scroll. I wanted the menus on the bottom 
  111. of the screen to go right into the corner so I called auto_overflow_off() 
  112. before displaying them. This disables the trigger for the scroll and keeps the 
  113. screen tidy. It is important to return the VT52 to normal - just in case.
  114.  
  115. Finally
  116. -------
  117.  
  118.      The program was written to be extendable. In fact the facility to 'Clear 
  119. all accessories' was 'bolted on' after the program was finished. Other 
  120. extensions can be added simply by adding cases to the switch statements. 
  121. Although it was written in Laser C it should work with any other K&R 
  122. specification compiler.
  123.  
  124.