Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!bbn!rochester!udel!burdvax!sdcrdcf!ism780c!ico!hao!hull From: hull@hao.UCAR.EDU (Howard Hull) Newsgroups: comp.sys.amiga Subject: Re: Disk fragmentation???? Message-ID: <932@hao.UCAR.EDU> Date: Tue, 27-Oct-87 01:50:08 EST Article-I.D.: hao.932 Posted: Tue Oct 27 01:50:08 1987 Date-Received: Thu, 29-Oct-87 21:53:08 EST References: <6121@sunybcs.UUCP> Organization: High Altitude Obs./NCAR, Boulder CO Lines: 201 Keywords: loading many programs at once... Summary: CA Workbench can be optimized to your environment In article <6121@sunybcs.UUCP>, ugmiker@cs.buffalo.EDU (Michael Reilley) writes: > Now, my question is: could my boot up time be shortened if > I waited for each process to be loaded and running before I try > to load the next one?? The disk drive makes ALOT of > brrrrrt...brrrrrt noises (good description huh?? :-), like it is > jumping back and forth between the programs it is simultaneously > trying to load. > Could it also be that one of the programs I am trying to > load are just fragmented throught the disk (which is 90% full), > and if it is, how could I better "order that program, would I > have to copy the disk, file by file to keep the programs whole??? Actually, this one was brilliantly deciphered by Matt Dillon a year ago. The Workbench, as it comes from Commodore, has not been particularly well groomed, even for it's own bootup - let alone yours. Of course, there is no way that the CA programmers could have known what you were going to do on your own particular Workbench disk. However, the order in which files are written to the Workbench disk is critical to rapid boot-up. Following is Matt's article, and after that is the front end of a sample script that I use with the Drew Shell. (Heck, it even copies the file dates over as they were on the source!) I put the write-protected Workbench in df0:, an initialized, installed, and versioned target disk in df1:, the mkbench file in ram: and cd to df1: to issue the command "ram:mkbench" from the Drew Shell. If the resulting Workbench grinds on bootup, try moving the Execute or Run file load position around a little. Methinks that either Execute or some of the things Execute calls are invoked by whatever is in AmigaDOS that reads the Startup-Sequence. After a little fussing with the order of things written to the new Workbench, you can have a quicker, quieter booting system! >From hplabs!decwrl!ucbvax!CORY.BERKELEY.EDU!dillon Wed Nov 12 22:09:06 1986 >Path: hao!hplabs!decwrl!ucbvax!CORY.BERKELEY.EDU!dillon >From: dillon@CORY.BERKELEY.EDU (Matt Dillon) >Newsgroups: comp.sys.amiga >Subject: Streamlining WorkBench >Message-ID: <8611130509.AA23119@cory.Berkeley.EDU> >Date: 13 Nov 86 05:09:06 GMT >Sender: daemon@ucbvax.BERKELEY.EDU >Organization: University of California at Berkeley >Lines: 104 [Insert yer own >'s for the next 105 lines!] I've gotten tired of hearing all the seeks my floppy is making to bring boot from workbench disk, so I did some experimenting and came up with an easy solution. All it involves is a lot of dilligent work. The idea is to start with a blank disk, create the directory structure and files in the same order that the workbench accesses them on boot and while it is executing your startup-sequence. For me, there is also a set of commands I execute from my shell login, so take the following as an example. WORKBENCH BOOT PROCEDURE: (1) Make a blank disk bootable by using the Dos INSTALL program. You now have a workbench diskette which, even though it's blank, will boot and give you a default cli with the default preference settings. You don't even need a startup-sequence (2) Create directories and files in the same order that workbench accesses them. Note that if any of the files doesn't exist, some default will be used: DEVS/SYSTEM-CONFIGURATION -contains preference settings S/STARTUP-SEQUENCE -contains execute script so far, the sequence of commands to setup the boot disk is (using SHELL commands): 'x:' is your old workbench diskette mkdir devs s c l copy x:devs/system-configuration devs copy x:s/startup-sequence s You now want to copy commands executed by the startup-sequence. Assume the following startup sequence (mine): ----------- shell c:.rootlogin endcli > nil: ----------- copy x:c/shell c copy x:c/.rootlogin c My Shell login looks like: ----------- date echo -n "date/time? " addbuffers df0: 30 addbuffers df1: 30 binddrivers echo ram:* >nil: source c:.login #contains aliases etc... input x;if $x;date $x;endif;unset x ----------- Note that I echo ram:* to nil:. This is only to force workbench to load the RAM disk driver. Note that I ask the question to set the date and time, and do the rest of the initialization while the user is typing his responce (none of the commands inbetween output anything), Then I get the user line and set the date. So, we continue copying stuff as follows: copy x:c/date c copy x:c/addbuffers c copy x:c/binddrivers c copy x:l l Note the last copy creates the entire 'l' directory and files. This is mainly to get the Ram-Handler which handles the RAM: device, but all three files are needed to have a properly working workbench. Now BRING OVER THE REST OF THE FILES. This involves creating other directories (such as LIBS), and copying files by hand. Don't trust AmigaDos to overwrite files in the same place on disk, so only copy stuff which isn't already on your new workbench. NOTE that none of my startup commands required any disk libraries. If you have any startup commands that do require disk libraries, you should create the libs directory and copy the libraries in question. The whole idea is to reduce the number of seeks required to bring up the system. For those of you who use the icon-based system, you would have also copied LOADWB and a few of the disk libraries (I'm not sure which ones) over. Don't get the idea that I'm excluding anything... I'm just talking about what you initially put on your workbench diskette. After your through copying that, you copy everything else over (I reiterate to, hopefully, avoid confusion). Now, when I bring up my system, I hear only a few clicks from my drive, and it comes up considerably faster. And if you don't like manually doing this stuff everytime a new version of the OS comes out, write a script to do it. Happy Hacking -Matt Dillon P.S. By only copying what I use, I have 382K free on my workbench diskette. >END of >'s [And here is the front end of my Drew Shell script (HH):] mkdir Trashcan copy df0:Trashcan.info Trashcan.info mkdir devs s c l libs System copy df0:devs/System-Configuration devs copy df0:s/Startup-Sequence s copy df0:c/Execute c copy df0:c/Run c copy df0:c/Echo c copy df0:c/RTClock c copy df0:c/Wait c copy df0:c/If c copy df0:c/Path c copy df0:c/EndIf c copy df0:c/BindDrivers c copy df0:c/LoadWb c copy df0:Setlace Setlace copy df0:c/RunBackground c copy df0:l l copy df0:libs libs copy df0:c/Shell c copy df0:c/.login c copy df0:Disk.info Disk.info copy df0:.info .info copy df0:Setlace.info Setlace.info copy df0:Clock Clock copy df0:Clock.info Clock.info copy df0:Preferences Preferences copy df0:Preferences.info Preferences.info copy df0:CLI CLI copy df0:CLI.info CLI.info copy df0:System.info System.info copy df0:System/.info System/.info copy df0:System/DiskCopy System/DiskCopy copy df0:System/DiskCopy.info System/DiskCopy.info copy df0:System/Format System/Format copy df0:System/Format.info System/Format.info copy df0:System/IconEd System/IconEd copy df0:System/IconEd.info System/IconEd.info copy df0:c/Assign c copy df0:c/Break c copy df0:c/CD c copy df0:c/ChangeTaskPri c copy df0:c/Copy c copy df0:c/Date c copy df0:c/Delete c ... etc, etc, you get the idea, I'm sure... Best Regards, Howard Hull [If yet unproven concepts are outlawed in the range of discussion... ...Then only the deranged will discuss yet unproven concepts] {ucbvax!hplabs | decvax!noao | mcvax!seismo | ihnp4!seismo} !hao!hull for domain mailers: hull@hao.ucar.edu