HOW TO ACHIEVE LIGHTNING STARTUPS ---------------------------------  - Gotta be Brutal to be Kind -  Scott English   ¿? 35 ¿*? 35 ¿*? 35 ¿*? 35 ¿*? 35 ¿*? 35 ¿*? 35 ¿*? 35 ¿*? 35 ¿*? 35 ¿? There was one major thing that I 'disliked intensely' (my mother said I should never say 'hate' so now I say 'dislike intensely'), about the Macintosh LCs that I worked with at University. Well there was probably more then one thing, but this one comes to mind. Startup-sequences. Or more to the point, the amount of time it takes for the Macs to execute them. You could, literally, get yourself a cup of tea before they were ready for you to use them. I would switch one on, walk to the toilet, answer the call of nature, walk back and be in time to catch the last 30 seconds or so of its startup-sequence. Zzzzzzzzzzz...... The Amiga systems that I have worked on are a dream compared to my experience with Mac startup sequences, but still, sometimes there can be a lot left to desire. Especially if you use your system on and off a lot. For example, I might get a rush of ideas, switch on the Amiga to note them down, and then go off to do something else. When I get these rushes of brilliance, they are, so might say, a rare occurrence, so I don't want to lose them as quickly as they came while I am waiting for my computer to boot. It is possible however, to make your startup-sequences lightning fast, well... maybe not THAT fast, but it will be much better then you are used to. And there are only two things you need to know to achieve this: 1) Pruning and 2) You gotta be brutal to be kind. Don't just trim the edges off your startup-sequences, attack them like you would prune a tree. Because, just like trees, they'll probably grow back after time. Keep the essentials and that which you require regularly enough to justify inclusion in the startup-sequence. Below I have included a copy of the startup-sequence that comes with the WB2 system disks: c:setpatch >NIL: c:version >NIL: addbuffers >NIL: df0: 15 Failat 21 resident >NIL: c:List pure add resident >NIL: c:Copy pure add resident >NIL: c:Assign pure add resident >NIL: c:Execute pure add makedir ram:T ram:Clipboards ram:env ram:env/sys copy >NIL: ENVARC: ram:env all quiet noreq assign ENV: ram:env assign T: ram:t ;set up T: directory for scripts assign CLIPS: ram:clipboards assign REXX: s: if exists sys:Monitors join >NIL: sys:monitors/~(#?.info) as t:mon-start execute t:mon-start delete >NIL: t:mon-start endif BindDrivers setenv Workbench $Workbench setenv Kickstart $Kickstart IPrefs ; echo "Amiga Release 2. Kickstart $Kickstart, Workbench $Workbench" conclip mount speak: mount aux: mount pipe: path ram: c: sys:utilities sys:rexxc sys:system s: sys:prefs sys:wbstartup add if exists sys:tools path sys:tools add if exists sys:tools/commodities path sys:tools/commodities add endif endif ; If this is the initial boot (i.e. keyboard env variable is not set) ; then execute PickMap which will query for a keymap and set the ; keyboard env variable. ; ; if keyboard env variable is set, set the keymap if ${sys/keyboard} NOT EQ "*${sys/keyboard}" setmap ${sys/keyboard} else PickMap.hd sys: endif if exists s:user-startup execute s:user-startup endif rexxmast >NIL: LoadWB endcli >NIL:  ----------------------------------------------------------------------- Pretty long winded, agreed? Right. And there is a lot of it that you don't really need. - If you don't use a floppy very regularly (in this case, df0:), then remove the addbuffer statement. The only time I really use df0: is when I am booting from it, in which case, if I am booting from it I will have the Addbuffer statement. Otherwise I don't, and hardly notice the difference. You will also get a whole chunk of memory back into your system by ditching this one - but disk access should slow. Like I said, I hardly notice the difference. - Resident commands. Again, if you use these AmigaDOS commands, cool. If you don't, they're wasting your time and your memory. Take out the ones you don't use regularly, and only include the ones you do. - Using a standard, none of this multisync mutil-dowhatsit monitor? Just got your old 1081 or TV set? Then you won't need all the monitor stuff, because, getting straight to the point, you don't have the monitor to use it with. Get rid of it, it's just clagging up things. - Take out the echos (who reads them, who needs them?), and take out all the comments. Sure the computer ignores the line once it sees that the line is actually a comment, but it takes time for the computer to actually see that the line is a comment. If you need to look at the comments to see what something does, refer to your original copy. Again, it all adds up and is going to save boot time and memory. - Remember the first time that you booted up under WB2 or installed the WB2 software? You were asked what sort of keymap you wished to use... Well you made your choice and that choice is now contained in your preferences drawer. The startup-sequence still however has code that checks to see if that keymap selection (prefs/env-archive/sys/keyboard) is present on the disk that you are booting from. If it isn't then it activates a program to get you to select one (PickMap). If it is, then it continues on with the startup-sequence. The point is that you know it IS there, so why have a bit of code that checks every time that you boot? Chop it out. - Finally if you don't use Arexx much then you can get rid of that entry. Even if you do use it frequently, you can still get rid of it and simply click on the RexxMast Icon whenever you need it (or set it up in a menu). Again this will give you access to more memory. That's it. Once you have done this, you'll have the smallest, fastest startup-sequence on the block. Below I have included a copy of my latest startup-sequence to show you what the tree should look like after you have pruned it. c:setpatch >NIL: c:version >NIL: failat 21 resident >NIL: c:Assign pure add makedir ram:T ram:Clipboards ram:env ram:env/sys copy >NIL: ENVARC: ram:env all quiet noreq assign ENV: ram:env assign T: ram:t assign CLIPS: ram:clipboards assign REXX: s: bindDrivers setenv Workbench $Workbench setenv Kickstart $Kickstart IPrefs conclip mount speak: mount aux: mount pipe: path ram: c: sys:utilities sys:rexxc sys:system s: sys:prefs sys:wbstartup add if exists sys:tools path sys:tools add if exists sys:tools/commodities path sys:tools/commodities add endif endif if exists s:user-startup execute s:user-startup endif loadWB endcli >NIL:  ---------------------------------------------------------------------- Now isn't that much better? And the most important thing is that it works! And it weighs in at less then half the size of the original file. Of course there is also another file involved in the startup sequence, and that is the user-startup. Basically, with the WBStartup drawer of WB2+ systems you shouldn't really need a user-startup file for most conventional purposes. So what happens if you have software installed that requires assigns? Simple, if you know your way around AmigaDOS. All you have to do is include a small script program somewhere in the running of the program that will do all the assigns for you. This itself is easier then it seems, but does require quite a bit of work on your part. For example, say we wanted to do this for Civilisation which we wish to install on our hard drive. We find the Icon which activates the game - let's say it is actually called Civilisation.info. Then we change the tool type of this icon to Project (this can be done with IconEdit found on your WB2 system disks). When you have done that, save it as something called Civilisation-Start.info. This will now be the way to run the script file to make all the appropriate assignments before the game is run. Then create a text file, called Civilisation-Start and place all the assigns in there and then the command to actually start the game (in this case it is 'Civilisation'). So your file would probably end up looking like this:  Assign CIVA: DH0:Games/Civilisation  Assign CIVB: DH0:Games/Civilisation  Assign CIVC: DH0:Games/Civilisation  Assign CIVD: DH0:Games/Civilisation  Civilisation Finally set the default tool in the Civilisation-Start icon as ':c/Iconx' and make sure it is in your C directory. Now when you run the game by clicking on its icon, the script file is first executed and makes all the necessary assigns for the game, and then the actual game itself is run. This can be done for any type of program, not just games. Also if you are using some sort of Tool Menu Utility then you can achieve the same effect by replacing the command to run the program (eg, DH0:Games/Civilisation/Civilisation) to a command to execute your script (eg, Execute DH0:Games/Civilisation/Civilisation-Start). The end result of all this is that you are no longer blanket assigning everything that you MIGHT use, everytime that you are booting your computer. Instead you are making the assignments on a need-to-use basis, as you go to use it (in a similar fashion to the Shell and Ed-Startup files). This ends up shortening your Startup-sequence, and hence booting time. You also score a little memory as you are no longer asking the Amiga to remember all those assigns. The final suggestion I have is don't include programs in your startup-sequence/WBStartup unless you use them all the time or at least regularly. Good candidates for inclusion are Screen Blankers, Arq, Tool Menu Utilities and such. Hopefully I have given you some ideas about getting your system running faster and more efficiently. These are just a couple of ideas that I have stumbled across trying to push my own system as far as it will go.  Be brutal!   © Scott English 1993  ¿? 35 ¿*? 35 ¿*? 35 ¿*? 35 ¿*? 35 ¿*? 35 ¿*? 35 ¿*? 35 ¿*? 35 ¿*? 35 ¿?