Now as the months roll by and you get to downloading various things from the BBS's and picking up the odd Fish disk, you're going to end up with programs all over the place, so we need to do two things in preparation. The first is getting our archives together. These disks will be our library. When we download a program off a BBS, it comes compressed, as time is money on the phone line and the smaller the file size, the quicker the download time. This compression is called "arc'ing", and you use a program called, surprisingly, "Arc" to do it with. When you get an arc'd download, you de-arc it with either Arc or a smaller, faster de-arc-only program called Pkax. After that you look at the freshly de-arc'd files, read the docs and try out the program. Then, if it looks like a program you want, or MIGHT want down the road, you copy the original arc'd version to the archives. You'll have drawers on these archive disks and you'll file the programs correctly, as well as have a master text file of what's where, how many arc and program bytes, brief description and where you got it from. Give yourself LOTS of elbow-room on these archives; they fill up quickly and it's a bitch to expand, say, six disks to ten just because of all the copying and trying to keep things in their proper drawers, etc. Update Note: Yes, yes, I know, I know...what about LHArc, Zip, Zoo, Warp, Pak, etc? I'll mention them eventually. LHarc is the compressor of choice now, so use that, and LHunArc96 (renamed "Larc") for decompressing. My archive disks are as follows; you can use them to help plan your own: Ads - BBS ads for hardware/software mail-order companies, etc BBS - captured buffers of file listings Clock - clock/timer stuff Anims - six disks of animations Audio - audio progs Audio Samples - sound and music files BigProgs#1 - progs over 100K compressed BigProgs#2 - CLI - CLI-related progs Docs - two drawers, regular docs and game docs & hints Diskcopiers - misc BBS copiers Fonts - downloaded fonts, font progs GamesA-C - downloaded games GamesD-F - GamesG-M - GamesN-S - GamesT-Z - GraphToolsA-L - all graphics-related programs GraphToolsM-R - GraphToolsS-Z - HacksA-M - misc hacks HacksN-Z - Icons - nothing but IconTools - editors and converters Keyboard - progs directly related to the keyboard Mouse - mouse progs, including menu-makers Misc - whatever doesn't fit somewhere else Pics#1 - pics I'd really mind losing Pics#2 - Pics#3 - Pointer - misc pointers, pointer progs Printer - a few special drivers, controllers Say - a couple of oddball things (could go in Audio) Screens - things concerning screens TextTools - progs dealing with text output ToolsA-E - except diskcopiers and graphtools ToolsF-P - ToolsQ-Z - Windows - window-related progs Yes, it seems silly to have an entire category just for the pointer, but I've got EIGHT files in there, so what'ya want? One point to note is that the number of disks for each category doesn't reflect your interest in that particular area of the computer. It's just that some programs are naturally huge, like the anims, so even if you're just mildly interested in them, you'll still end up with a few disk's worth. If you don't have a modem yet but have picked up a few Fred Fish disks down at the store, the same holds true: Get them stored. Usually you only want a program or two, so my advice is to store what you want and put the Fish disks in a box in the closet to pull out six months from now to see if you've changed your mind about any of the other programs. DON'T use the Fish disks, cleaned and formatted or not, for your Archives, as they're poor quality..and if you're using the Sonys you mustn't stoop so low as to use a generic disk. And BACKUP your archives! Spend half a Sunday every six months or so with your archive disk on one side of the DU and the backup disk on the other side, copying over the latest additions. Yes, it's boring. Yes, it takes forever. Yes, you'll think you're the smartest person since God created kittens when you accidentally wipe out some archive disk three months from now and have a copy safely secreted away in some closet. * The other thing we have to do in preparation for the new programs invading our tidy Amigaworld is to make some specialized CustomBenches. If you like icons, you'll end up with a bunch of different icon utilities, so make a copy of BareBench, rename it IconBench, and go through it as we did before, deleting any file that doesn't relate to icons. I'm just talking about Tools and things, of course. We obviously leave the l, libs, and devs directories mostly alone. But just about everything else you can find besides the CLI and IconEd can go. This is the IconBench, buddy. Move what's left over to the main Workbench window, then "Delete Utilities all". We note that even though we moved everything out of Utilities, the directory's still not empty (there's still the .info file) so "Delete Utilities" without the "all" won't work..directory not empty! Then "Delete Utilities.info" to blast the icon. DiskDoctor might also be in there (without an icon), but it goes too. Remember, I'm capitalizing words simply for clarity; the CLI doesn't care. Good advice right now would be get into the habit of always capitalizing cer- tain words: directory names, program names, c commands, whatever strikes your fancy. There're no strict rules on the subject, as pointed out quite clearly by the stock startup-sequence. In the tutorial I'll just capitalize every- thing in sight. * All right: As you can see, you'll end up with a bunch of different Benches. You'll have a GraphBench where you'll have different graphics tools for showing pics, running slideshows, animations, etc. You'll have a FirstAidBench filled with DiskDoctor-type programs, undeleters, file- zappers, sector editors, whatever, in case of need. You'll have ExperiBench for screwing up, maybe a MusicBench for music programs, NoteBench (with Pro- Write or something on it), DirtyBench, hey, who knows? There is, however, another way to do all this, but it has too many drawbacks..disks are cheap, remember? I'll explain it to you anyways just so you know. Assuming you have a blank, formatted disk in df1, you can, of course, store tools (in drawers, if you wish) on that disk and simply run them by opening df1's window and double-clicking on the icon. Also, because the disk in df1 isn't a boot disk and doesn't need all the accompanying files like Workbench does, it can hold just tons of tools, eliminating the need for almost all of the CustomBenches. For all of that, you REALLY want df1 free to transfer things to and from, and if you start running projects and things from df1 you'll end up being plagued by "Please insert disk so-and- so.." requesters. And that's only the start of some of the hassles that might crop up, another being that paths are much more critical with something running from an external device, be it df1 or Ram. I tried it for a while and gave up. It's more fun and certainly easier to deal with just having custom Benches for different major operations and leave df1 free for file shuffling, holding big programs, collections of pictures, animations, etc. Not to mislead you, you'll still use good ol' Workbench as your standard boot-up disk. The CustomBenches are just that, for custom work. And you can always run a tool or whatever from df1 in a given situation. * So what's next? Why, time to write a scriptfile, you bet! Type in the CLI "Ed s/g" and there's our buddy Ed with a Creating New File for us. The file is in the s directory and is called "g". On the first line type "Ed df0:s/startup-sequence". That's it! Hit Esc, x, Return. In the CLI type "Dir s" and see if little g is there. In the CLI "Type s/g" and see your fine creation right there in blue and white. Now type "Execute s/g" in the CLI and lo and behold, you've executed a scriptfile that told the computer to edit the startup-sequence. Hit Esc, q, Return, to exit the Ed without saving anything. Think that was tricky? Watch this: Type "Copy c/Execute c/f" in the CLI. You've just duplicated the Execute command, renaming it "f". Now in the CLI type "f s/g" and you've got Ed again. Still not slick enough? Hang on. The command Path draws a path into a directory so we can find and use a TOOL easily. We'll use the ol' Clock as our example. Move the Clock into the Utilities drawer. Type "Clock" in the CLI and the little beggar should pop right up there. Close the Clock, then type "Path reset" in the CLI. We have just wiped out (for this CLI) the command "Path Ram: System Utilities" we ran in our st-seq. Now type "Clock" and hey, object not found! Now type "Utilities/Clock" and there it is. Since the Utilities directory was not in the paths (because we reset them), you had to draw a path to the tool with the whole command. Type "Path Utilities". Now type "Clock" again..and since you've directed paths to the directory Utilities, you only need to type the name of the tool and it'll find it. A little clearer? That's why the Path command is in the st-seq; we set things up there so we don't always have to type the long version when we want the tool. And that can BE a real "long version" when you're calling up tools that are within directories within directories within directories, etc. The basic Amiga directories have "built-in" paths, so the Amiga can get going at boot-up. Two are the c and s directories. You notice we didn't put "Path c" in the st-seq Path command, yet if you type "Dir" in the CLI it doesn't come back with "Object not found" as it knows to seek for tools in the c directory automatically. With the s directory it's scriptfiles, like the startup-sequence. The first thing it does at boot-up is seek the s directory for "startup-sequence", even though no paths have been drawn there. So got the point yet? Our little file "g" is also a scriptfile, so to edit the st-seq, we type "f g" as fast as our little fingers can go and bang, there it is. If you've got ol' AddBuffers cranked up, the second time you "f g" it's REALLY there. We keep our scriptfiles in the s directory as the system automatically searches the s directory for scriptfiles; it lays a path for them. The Path command, remember, is only for tools. If you had the scriptfile "g" in the devs directory, say, and typed "f g", nothing would happen. Type "Path devs", then "f g" and still nothing happens. Path is only for tools. S is the directory you keep scriptfiles in unless you plan on spelling out the whole path during the command. In this case, "f devs/g" would work fine, as you specified to the Execute command the directory the file was in. That's "f", by the way, as in "Fire One!" That little file "g" is just the start, of course. We can issue all kinds of commands with just a flip of our fingers with scriptfiles kept in the s directory and our copied Execute command "f". We're not going to delete the original command Execute, by the way, as, like leaving the t directory on the disk even though it's empty, some future programmers might seek out the command Execute by name, never believing in their wildest nightmares that anyone would have the gall to slice up a Workbench like we're doing. The ONLY other command we "shorten" is EndCLI, just because it's hard to type quickly. You "Copy c/EndCLI c/e" and now "e" is your "EndCLI". Got a loose DOS window cluttering up the place? Hit e, Return and bang, it's gone. To be open-minded..at least on this one tiny little point..I'm forced to admit that's it's also common to rename the Delete command to "d", like we did when we cleaned up the c directory. It's just one of those things that you have to weigh out and decide for yourself. As you know, when you delete something in DOS, it doesn't come back with any good-neighborly message asking you if you're just downright sure you want to delete this puppy, it's just gone. It strikes me now, as I'm sure it struck me then, that the LAST thing we all-thumbs Beginners need is a quicker DOS Delete command. In just the time it takes to type out the word, you have enough time to mentally check if you really want this file deleted. And besides, you goof around on this thing long enough and eventually you'll enter some command like "Delte TestMe.file" and the computer will respond "unknown command" and you'll look up and realize with semi-shock that the TestMe.file was the LAST thing you wanted deleted! Saved by the misspell! It is, on the other hand, rather difficult to misspell the word "d". * Here are some of my s scriptfiles: a - Run Type df0:MyFiles/ArchiveList aa - Run Ed df0:MyFiles/ArchiveList g - Run Ed df0:s/startup-sequence gg - Run Ed df1:s/startup-sequence for - FailAt 25 Format drive df1: name Formatted noicons ;lazy Format command b - Run df0:CLI-Buster ;my name for the Directory Utility I use l - SetPrefs Inlace ;switches to Interlace screen/colors Lace ll - Lace ;switches to non-Interlace screen/colors SetPrefs Nolace p - Fac -p 0 -p 1 ;purges FaccII's buffers, both drives dr - Delete Ram:#? all ;deletes everything in Ram m - Delete Ram:#? all ;deletes everything in Ram and quits Fac -q FaccII to get back most of the memory mm - deletes Ram, stops as many sub-routines (like FastFonts) as it can, gets back as much memory as possible. We'll talk more about it later mmm - puts back everything mm took out Now some, like mm, execute a list, or script of commands, and that's why scriptfiles are needed. Others, like "b", just fire up my Directory Utility (if you don't know what a DU is, you've got a real surprise coming). I could just rename the DU "b", then simply type "b" in the CLI window and up it would pop, but frankly, that's a stupid name for a tool. Not to mention how quickly it could get out of hand, renaming commands, scriptfiles AND tools with single letters. We'll leave things just as they are. * The program Lace I included with the tutorial is the best one I can find. There are bunches of them around, half of them called "Lace", so I thought since it's pretty small I'd toss it in. It's not perfect in that it doesn't remember where the windows were when you return to Interlace mode, but hey, so someone sacrificed program quality in order to keep the byteage down. Gee, what a surprise. * If you don't have a modem (what have you been doing, reading??), you'll have to hoof it down to whoever near you has PD/Fred Fish disks, decipher your way through the Index and pick up which of these (or substitutes, if you dare) you can. The disks are only a couple of bucks each, you get a whole bunch of needless crap on each one, and best of all you get the honor of personally throwing away the junk generic disks when you've taken what you want off them. I'm not being a snob here; if you ever loose something valu- able you had stored on a junk disk you'll never forgive yourself. Or me. * If you just happen to HAVE a modem...well THANK GOD!! Can you believe that other guy I was just talking to? Doesn't even have a modem yet and says he has, get this, a "computer"! Har! Har! Har! What that guy has is the "preparation for a computer", as tremendously hip people like ourselves know. So, call up one of the gang (for my Bay Area byte-buddies): HT (408's) 245-4029 Trembler 967-8319 JDR 559-0253 Rancho 683-2534 Homebase 988-4004 (message-base only but superior board) My BBS (415's) 968-8580 FAUG 595-2479 RSVP 659-9169 The Mission 967-2021 Addicts 222-9416 Any good local board CompuServe, GEnie (national boards) When you first get on a BBS, you'll be asked for your name and password, and when you don't have one, it'll assume you're a new user and will proceed with the registration process. Some boards will have you type in something like NEW USER from the beginning. The registration consists of name, maybe address, phone number, type of computer, maybe a few vital details about your computer. If you don't have someone there beside you who's been on a BBS before, don't worry about it. You know you've got a Commodore Amiga, so once you enter that code most everything else should work just fine. If or when it asks you for a "Protocol", pick ZModem if they've got it, other- wise pick XModem. ALWAYS make sure your protocol matches the BBS's. After you register, different things will happen, depending on the SysOps (System Operators) of the BBS, how trusting they are, etc. Most want you to call back a few days later, some will let you on right away. If you're allowed immediate access to the message boards and program files, some will let you download files immediately and some will only let you look around. Either way, when you have access to the files you'll want to use the (S)earch feature to dig up the downloads you want by name. You'll also want to browse through the various sections to see what's cookin'. Most boards have an upload/download ratio, something like 30 to 1, just to make sure you're not a complete leech. Some boards give you more time (starting at, say, thirty minutes) the more you upload, some just give you, say, an hour, period. Uploading is kinda fun. Uploading some righteous new hack or animation to one of your favorite boards gives you a good feeling. The best way to dig up the latest stuff is to look at the (N)ew files when you first get on, and those are the ones most likely to be needed elsewhere. I have uploaded easily more than thirty megs myself. Just call me the old file shuffler. * So slap a blank disk in df1 and download: arc bytes prog bytes Conman 14,277 1,100 - CLI line editor, a must DU-VI 50,220 35,456 - best basic DU I've found, also a must FileType 20,589 25,988 - best file identifier around GShow 17,408 15,712 - shows pics IconLab 55,428 68,768 - excellent icon tool Less1.1 17,384 22,364 - replaces Type, much better LHarc 58,368 36,304 - to arc files, a must LHunArc 15,964 21,724 - to decompress .lzh files, a must Pkax 20,393 18,652 - to decompress .arc files, a must PrefCh 14,034 4,112 - change Prefs while booted-up, a must Mackie 19,361 7,488 - pops up a CLI window at the press of 2 keys Runback 4,877 3,268 - replaces Run in many cases, a must Select 8,413 5,412 - select your st-seq at boot-up, a must PlayBeep 44,068 10,344 - changes error beep and screen flash WhereIs 29,539 12,328 - finds lost files Zip 67,939 89,004 - to decompress .zip files, a must Zoo 70,009 41,428 - to decompress .zoo files, a must I include the arc'd bytes to compare with the file on the BBS, and the prog bytes so you can see if you have the same program or version of the program as me. Not only to avoid confusion in the future, but to make sure you got the right one; the names are sketchy at best (sometimes the name's already been taken on that particular BBS so you HAVE to name it something else) so check to make sure. The arc'd byteage is only a roundabout guideline; shameless people like myself will actually add documentation to some of these programs before uploading to a different board, might even have the temerity to include a Zzenpad.foo file to protect the arc file dur- ing the upload/download procedure, you know, that kind of imprudent action. And we, the hapless victims, can only hope and pray we're downloading a different program this time and not just the same one some wanton Amigalite has added to and renamed. I've now downloaded the same damn 120,000-byte animation THREE times under three different names; two arc'd files with slightly different byteages and a ZOO version! It happens. If I mention a version number, like "Less1.1", try and get that partic- ular one. It's not unusual for an "improved" version to not be as good as the older one. Try to find the Directory Utility DU-VI. Most of the DU's around are single-screen and this one's a double. You'll also notice the occasional file with a .zoo or .zip ending, which is why you need the Zip and Zoo programs. Another thing to note is that you can't tell in the slightest how many bytes a program is by the arc size. There's a good example above. The DU-VI is some 50,000 bytes arc'd, which might lead one the think that by the time it's unarc'd it'd be HUGE..but it's not. As you can see, the actual program is only 35 Kbytes, very modest for all it does. The bulk of the arc file is the "c source" included in the file. And some docs can be pretty hefty. After you've got that gang, the next ones to get are: arc'd bytes Beep 2,967 - a small beep sound for help with scriptfiles DL 11,941 - better List command Edible 14,395 - removes binary from text Filter 3,555 - removes command garbage (^M's) from text IconType 4,648 - changes type (Tool, Project) of icon IFFencode 6,540 - "snapshots" screen, saves as pic JBLS 10,588 - another better List command Melt 13,193 - maybe the greatest screen hack of all NewFlush 1,582 - flushes libs, etc from memory NewFonts 52,001 - neat fonts for paint & processor NewSweep 2,540 - this or NewFlush will do NewZap3.1 31,744 - lets you edit binary things like tools SView 5,248 - slightly different type of pic viewer Zoomlens 6,344 - just a cute Bench tool You'll also want to get anything else that looks intriguing, it obviously depends on where your interests lie. There are, for example, some great nudes on the BBS's. There are some decent games (my favorites at the moment are SnakePit and Cycles), game editors, and lots of tips 'n tricks for commercial games. If you're into audio you'll want to pick up some Play programs and start unraveling the IFF/DMCS/SMUS/SONIX enigma. There are some great graphic demos around, such as Colorful, Dazzle, Multiscope and Nemesis. There are some great animations, such as Froggy, CPUS, BThrows and MarbleFac. The two premiere ones I've seen are StampCol (for StampCollector) and NotAgain, both by the esteemed Dr. Gandalf. If you're going to get NotAgain, dig up Boing first, just so you'll know.. There's also the occasional business program, with some BBS's catering almost exclusively to the business end of the machine, like some boards are devoted exclusively to programmers. * And now, guess what?! It's time for some more of that neat CLI stuff!! Oh please, Mr. BenchMaster, can we have Assign first?? Sorry kids, like dessert, you'll have to finish your plates before we get to the good stuff, and that means every last byte! Okay, I'm just going to skip through the c directory; most of the commands just kind of do one thing so don't need much additional comment. AddBuffers - keep it until you get FaccII Assign - sorry, next section Avail - tells you available memory Break - Will stop some programs that otherwise don't have an off command, but don't count on it. Procedure is to first type Status to see which # task it is, then "Break #". Will also tell Wait when a program is through, like in the 1.3 StartupII file CD - sorry, next section too Copy - makes a copy of a file where you specify, with a different name if you so further specify. Use "all" to copy the directory and all sub- directories and files within Date - use to set date and time Delete - deletes specified file unless "all" is used, then deletes specified directory and all subdirectories/files within. When you use "all", be SURE you want to. The CLI is very unforgiving, compared to the Workbench, so if you're deleting-something-all, be SURE Dir - shows specified directory or device's contents Echo - for printing out text in a CLI window Ed - the "text editor", "screen editor", or "system screen editor", depending on which book's open at the time. A "screen editor" would alter the size of the Workbench screen, maybe make it a triangle, maybe add some little scrolly things at the corners, gosh, just all kinds of great possibilities..therefore I surmise by default (hey, the original meaning of the word) that this is a "text editor". Else, If, EndIf - next section EndCLI - closes CLI window; doesn't close if you've Run certain programs still in operation (that's what Runback is for) Execute - a "Run" for scriptfiles, if I may be so bold FailAt - makes a scriptfile fail (or keep on running) if a program delivers a certain error code. A quick example would be the "for" script- file in my s dir. Format doesn't like to be run from a scriptfile, so it returns an error code and stops the file from executing. Putting a "FailAt 25" in front of it allows the scriptfile to continue and the Format program to run. That's what the error return codes are all about, so you can have a program run some- times and perhaps not at other times. If it wasn't for that one particular usage, I would have had you delete it with the rest of the c commands. FastFonts - speeds up text output and changes default font Fault - translates error message number into semi-English IconX - runs scriptfiles from icons Info - shows current disk space available, which devices mounted Install - to make a blank disk bootable Join - combines textfiles together List - lists blocks in dir or bytes of individual file if specified, also date and time file was last copied or saved. There are Copy programs on the BBS's that copy over a file saving its original date LoadWB - loads up the Workbench screen MakeDir - makes a new directory, but not the icon for it. For the .info file you have to copy over (and rename) another drawer icon, or make up a new one in IconEd. Drawer icons don't have to look like drawers, I remind you. NewCLI - it differs from the CLI command that was in the System drawer in only one way, but you can play with them. Both can have their window sizes changed with NewZap Path - mentioned throughout the tutorial. Paths started up in the st-seq are forever, paths started once you've booted up are only good for the task they're in, or subsequent tasks (NewCLI's) from that task Quit - never found it to do much Rename - renames files as well as moves them. Learn this guy as well as Copy Run - for tools/programs SetClock - for setting the internal and system clocks SetPatch - fixes minor bugs in ROM Sort - alphabetizes columns of words Stack - mainly needed for big graphics things Status - gives you current status of CLI tasks Type - goes into the dumper as soon as you get Less (or rename it Type2) Wait - holds up scriptfile for requested number of secs/mins Why - like Fault, gives you feedback on error. Use right after boo-boo Okay, that's it for those clowns. Assign, Avail, Info, List, Path and Status are the six commands you type into the CLI to check the current condition of the system. Write them down on a small, separate piece of paper and tape it somewhere obvious. These are your direct link to the system, so use them, learn them, figure out what every little scrap of data means, slap 'em in the CLI whenever you have the slightest question as to what's going on. You will eventually feel like you are actually controlling the computer, rather than simply being bewildered by it, and learning, knowing and using these six commands are the shortest and best path to that goal. (To all the DiskMaster fans in the audience who just gasped at that last statement, let me quickly add that you don't control the SYSTEM with a Directory Utility, you only control FUNCTIONS. DU's are really great, but they're just tools, after all) * Well, I fibbed. This is the next section and we're NOT going to go over those other commands just yet. Aw-w, gee Uncle BenchMaster, c'mon, just one little Assign, pretty-please??? Well, okay. Geez, I'm such a sucker for you brats. Now, remember when I said we'd wipe out the fonts dir, get all the space back and still have access to the fonts? Here's how: We made that fonts dir on the disk in df1, so we'll Assign the fonts over to that disk so when Notepad or whatever goes looking for "fonts", there they'll be. Pop a copy of Notepad off the master disk into the Utilities drawer. Slap ol' FontDisk in df1. Think one whole big disk is too much to devote to some punky little fonts? Well, if you're not into them, that's true. If you are, however, you may eventually end up with 754,888 bytes (and counting) worth of the little beggars, like guess-who. To run Notepad with df1's fonts, somewhere before you start up Notepad you need to assign the fonts dir over to the fonts dir on df1, and this you can do a number of ways: - You can just put "Assign fonts: df1:fonts" in your st-seq but then FontDisk always has to be in df1 when you're booting up or it stops. - A variation on the above would be to put an If exists df1:fonts Assign fonts: df1:fonts EndIf in the st-seq so it can see if df1:fonts is there or not. One hitch with this is that unless FontDisk is in df1 during boot-up you'll STILL have to Assign them over before using the Notepad. Also, you could have some ol' game disk with a font dir on it in df1 by mistake and things would really mIxT uP gEt. - You could, of course, just type "Assign fonts: df1:fonts" in a CLI before using the Notepad every time. Personally, I can't even imagine it. - You could write a scriptfile saying "Assign fonts: df1:fonts", call it, say, "fo" (for fonts), and go "f fo" before firing up the Notepad. But then, of course, you still have to remember to do it. - So obviously you'll have to do it the right way. AND you have to be able to run the whole thing from an icon. AND it's due by Part5. Hey, you've heard of mid-terms? This is it. Clue1: (in Official Seventh Grade Typewriter Code): OvpmC Clue2: tim mpy Tim * A few notes on paths: Any paths you enter in the st-seq are there forever. If you enter "Path reset" in a CLI, it only wipes out the paths in that CLI, or any NewCLI's you run from it. If you start up some new paths in a CLI, those paths are only accessible through that CLI or any new CLI's from it, whether you enter the NewCLI c command, or run the CLI tool. Those new CLI processes retain the paths set in the CLI they came from. * Three items about the actual CLI window: You can usually halt the process by imputing a character, like you stop the original Type program. To start it back up again you hit the backspace key. You can usually stop it com- pletely by hitting Ctrl-C. If it's a scriptfile, like the st-seq, you stop it by hitting Ctrl-D. Sometimes Ctrl-X works. On a few rare occasions I've seen Ctrl-\ stop a program, hey, who knows? If you want to enter another command while one's already running, hit Ctrl-J, enter the command, then Return. The CLI will finish up the first task then perform the second. If I'm doing something that takes a while, like compressing some large anima- tion, I enter "LHarc a (newfilename) *", Return, the compressor starts doing its thing, I hit Ctrl-J, enter "Beep", Return, and when the LHarc process is through it plays the little Beep program to let me know. * Perhaps a note on the good Doctor would be in order about now. If you're writing to or reading from a disk, things suddenly grind-grind-grind and up pops a requester saying "Sorry kid, it's Read/Write Error time", the proper procedure is this: If you're writing TO the disk out of Ram, first grab a fresh disk, slap it in df1 and get the Ram file taken care of. If you were writing TO the disk, hopefully you just hit a bad sector and everything already on the disk will copy off it. Pop up the DU if you haven't and copy all the files to a fresh disk. If you were reading FROM, you might have lost a file, but try copying them over to see. When you hit the bad file either the DU or the CLI will let you know. At this point you can "Disk- Doctor df1:" and hope for the best. When the good Doctor's through you can try and salvage the bad file from it. Then you re-format the disk. If the Format command hits a bad sector and stops, the disk is shot. If it's guaranteed, like the Sonys, put it away in an empty disk box and bring the box down to the store when it's full. You won't come across one often, maybe every two or three months, a lot depending upon their treatment. The good Doctor's main role is to restore freshly-deleted files. I say "freshly" because if you've written to the disk since you deleted the file, it might be history. Otherwise just slap the disk in df1 and let the good Doctor do his thing. One other thing: Make sure to try reading a bad file from every drive you have. It's not uncommon for one drive to read a disk and one not. * The Stack command is essential for certain programs to run correctly, usually large animations. If it has an icon with it there'll be a "16000" or something in the STACK box in the Info window. If you're running it from a scriptfile, you'll have to have a "Stack 16000" before the program. It's always better to overestimate how much Stack you need if you're not sure, as it'll usually be Mr. Guru knocking on the door if you don't. If you're into downloading graphic hacks, you'll want to remember ol' Stack, as some definitely need it and the icon might be gone or whatever. One indicator of insufficient stack space is the good ol' CANCEL/DEBUG "requester", so reboot and type in "Stack 16000" in the CLI if you're going that route, or enter the 16000 in the STACK box in the Info window and try it again. You'll also need it if you want to Sort (alphabetize) great big columns of words, like 40K-plus. The original Sort command is really garbage, there's a much better one floating around the BBS's called SuprSort. We saw above that if we entered new paths in a CLI, future CLI's from that same CLI also knew the new paths. The Stack command also works as an example of how CLI tasks work. If you enter "Stack", the computer responds "current stack size is 4000 bytes". Enter "Stack 16000", then "Stack" and the computer will tell you the current stack size is now 16000. Fire up a NewCLI from that CLI, enter "Stack", and it'll respond "16000". Fire up a NewCLI from THAT CLI and the new one will also respond "16000". Enter "f b", which executes a scriptfile that runs DU-VI, punch the COMMAND box on DU-VI to start up a NewCLI, type "Stack" and THAT CLI responds "16000". All OTHER CLI's on the Bench, started from either the CLI icon or the NewCLI command, will be the default 4000 bytes. The 16000 followed the original task it was entered in. Enter "Stack 16000" in the startup-sequence, followed by a "NewCLI". If you "Stack" in that new CLI window after booting up, it responds "16000", but every other CLI, NewCLI, DU's CLI, Mackie's CLI, etc, on the Bench will be at the default 4000, no matter what's in the icon's Stack box, or where you put the Stack command in the st-seq in relation to LoadWb. Let's see..was it LoadWb..or Path? Hmmm....maybe that didn't have anything to do with it. Gosh...I've kinda forgotten now. All I remember is that there's a real easy way to simply click on the CLI icon and automatically have the Stack set to 16000... I guess you'll have to help me out. Also due by Part5. *