and/or data storage space.  When that space is limited, you cut
     something.  What should get cut?

     A very appealing aspect of OS9 is the ability to snap from one program
     to another with the push of a button.  But with space and CPU speed
     limited, how many programs of what size, power and function can you
     squeeze into a little CoCo?  Working Delphi is nice.  You run a
     terminal program.  Maybe you have an editor to generate messages which
     are stored.  You download a file to disk or ramdisk.  Maybe you print
     out documentation in the background.  Fun!

     But what are you downloading?  A spreadsheet that will hold all your
     small business bookkeeping for a year?  Will you run that at the same
     time you have a memory gobbling graphics program in place?  And the
     graphics user interface you use?  And the big game you didn't finish
     last time you played?

     Then, perhaps more importantly, there is the 6809 CPU a terrific
     little chip that could blow the doors off everything when it first
     came out (and later).  DECB users who've been around a while remember
     when everyone was scrambling to get things running at double speed -
     (still less than 2 mhz).  If one program can need that, what about
     several, running at once?  Some programs take little CPU time.  Some
     take a lot more, like when there is much disk I\O.  Special disk
     controllers can help a lot, but that is only one of the angles.

     How successful multi-tasking will be for you will depend on what
     you'll be running.  Don't plan on having three action games running on
     three different terminals.

     With applications growing to accomodate users demands for computing
     power, more memory and speed is needed.  If you're a purist of the
     68xx genre, the new 68xxx computers may be interesting.  They have
     many times more memory and speed than CoCo.  You'll find programmers
     right on Delphi who are working day and night to develop applications
     for these computers.

     Take a look at things.  If you're a budding programmer, learning OS9
     can be very educational.  If you're a hobbiest you can do a lot of
     experimenting with OS9 software and utilities.  You can even run some
     of those very good applications programs.  Or power a rock concert via
     Ultimuse and MIDI!


                     A little Body For the Attitude

     So far, I've given you just a peek at how life can be in the OS9
     world.  Some things I've described may be very unlike what you
     ultimately find to be your specific experience.  But I have been more
     interested in the general idea of things.  Now I'll touch on a few
     points that will probably effect everyday computing more.  Still, this
     isn't an OS9 "how to", just a whiff of its perfume.

     Why is it so important to have so many levels of directories?

                                      -6-











     Firstly, as I mentioned, there is a lot of stuff to organize.  With
     people writing constantly there are new "tools" coming out almost
     every week!  (I have 16 clocks on file and that isn't all of them.)
     By "tools" I mean utilities to do jobs, etc.  Earlier I used "del" in
     an illustration.  That is a very simple tool.  "List" is a fairly
     simple tool.  "Free" is like free in DECB.  "Mfree" is like "MEM".
     (There ARE differences between such similar DECB and OS9 commands but
     the general idea is the same).  Improved versions of various commands
     are written, often somewhat larger.  Most veteran OS9 users have an
     entirely new shell - SHELL +.

     Other commands are replaced if the user prefers something different
     (and if an alternative is available).  But you really can't just toss
     out the original commands.  There WILL be a time when you need at
     least some of them if you stick with OS9 long!  So you keep copies of
     them.  Probably on a separate disk.  But if you happen to want to use
     both versions you might want them on one disk.  You can't do that with
     DECB if you use the same name, but it is easy with OS9, because you
     can put them in different directories.

     You might want to put them on the same level in differently named
     directories.  You could have, for example, CMDS1 and CMDS2.  Then it
     would be possible to have one version of (perhaps) ATTR in one and
     another version in the other - (/d0/cmds1/attr or /d0/cmds2/attr).
     How much of this you can do might depend on your own memory.

     Or you might want to put them on different levels.  You could actually
     have a CMDS directory listed under the regular CMDS directory
     (/d0/cmds/cmds/attr), although it would probably not be a very good
     idea.  A "dir" could confuse you if you didn't remember which level
     you were looking at.

     Another reason for various directories is the wide variety of data you
     can (sometimes must) have on disk.  Frequently you will see
     directories named SYS, DOC, MODULES or ARC.  SYS might have data
     essential to the function of an assembler.  It might have "help" or
     "error" messages.  "DOC" would probably have documentation for
     programs or commands.  "MODULES" would likely have descriptions of the
     parameters of your various I/O devices such as your printer or RS-232
     pak (40 isn't unusual).  ARC would probably have archived (compressed)
     copies of programs, data, or other files.

     As mentioned, directories CAN be "stacked" many levels deep.  One
     communications program stores dialing information like this:
     /d0/sys/dial/filename.  A MultiVue screen icon might be named like
     this: /d0/cmds/icon/icon.app.  I saw an example in which Basic09
     commands were on the same disk with others.  Under the regular CMDS
     directory was BASIC09, and under that was another CMDS.  To copy it
     you could end up with this line:

      copy /d0/cmds/basic09/cmds/filename /d1/cmds/basic09/cmds/filename.

     (Note, above, that I have put directory names in capital letters but

                                      -7-










     the command lines in lowercase.  If you have many things on the same
     level, caps make a directory stand out on the screen.  When you set up
     a directory (using MAKDIR) you can just enter the name in caps.  After
     that you need not use caps to call it.  In most cases, OS9 accepts
     lowercase keyboard input for the system.  Programs run under OS9 make
     their own decision on that).

     If you see the reason for multiple directories, we can go on.

     At some point you will probably come across the phrase "Unified I/O
     System".  So far I've referred to pathlists only as long paths through
     the maze of directories to files on your disks.  But paths can access
     other things.  Via pathlists you can list a text file to the screen or
     you can list it to your printer or to a screen in another window to be
     seen later!  Via a pathlist you can read input from your RS-232 pak
     (and therefore whatever it is connected to).  You can run a program in
     a window you don't see.  These things can happen because of this
     "unified" system.

     In section one I mentioned that most commands are usually kept on
     disk.  When you need, for example, the command "format" it will
     probably be on disk.  When you enter "format" the computer loads it
     into memory and executes it (but not by firing squad) then unloads it
     when it is done with it.  But you can also load commands into memory
     manually, then unload them when you wish.

     (Computereze for "unload" is "unlink".)

     In section one I mentioned that mis-spelling something in a command
     line could cause an error such as 216 (pathname not found).  Something
     that you can do in OS9 does make life easier when this and other
     things happen - the command line buffer.  What you enter as a command
     line is saved in memory.  You can then repeat it with the appropriate
     keypresses.  As it comes, OS9 has an command repeat that is activated
     by CTRL-A.  Before you press <ENTER> you can do some overstrike type
     editing.

     With one very popular new version of this you use right arrow or
     shifted right arrow instead of CTRL-A.  You can easily key over to the
     offending characters, change, insert or delete them and repeat the
     command.  This is the "SCF EDITOR" I mentioned at the beginning of
     this article.

     This saves MUCH time over typing in whole lines again, especially when
     dealing with long full pathlists.  If you're not the best typist, it
     can be a life saver.  It also comes in handy if, for example, you have
     several similar files to copy.  By changing only the actual filename
     part of the pathlist you could move several files without retyping
     much.

     On the other hand, when in doubt about where you are, you can usually
     enter a full pathlist to "feed the hungry computer".  (Sometimes,
     specific programs might not allow that).

                                      -8-











     There are other things that can really frustrate the beginner.  One
     thing is the time it takes to do certain tasks according to the
     manual.  For example, at some point you will wish to rewrite your
     startup file. Beginners haul out the "build" command and start a new
     startup file from scratch as instructed by the manual.  One tiny error
     and you're back to deleting, renaming, rewriting or what all, from the
     top down.

     Startup is actually a text file called a script.  (This may be in the
     manual somewhere, but I've never found it.  It is definitely not in my
     indexes).  Each command is on a separate line.  If you can get hold of
     a line editor such as SLED from Delphi, (or a word processor) you can
     load such a script as "startup" and add or subtract at will.  Just
     loading one and looking at it will take much of the mystery out of it.

     Always press <ENTER> after each command as you would on the keyboard.
     Just as in regular word processing, this will start a new line for the
     next command.

     If you wish to keep a copy of the original startup file you can rename
     it the way the manual suggests - before starting on a new one.  Then
     when you are finished with the new one you save it to disk as
     "startup" just like the original.  If your line editor has an
     overwrite feature (such as the one in SLED) you can just write the
     file into the space where the original was.  Once you get comfortable
     with the system you will probably do this.

     The "edit" utility that comes with OS9 can do this job.  If you find
     it easy to use, by all means do so.  But with a regular text editor
     you can see it all at once and use the arrow keys to edit.

     Since a script is just a series of commands in a text file, you can
     write different scripts to do different things and call them just as
     you would any other command.  This is a good way to set up a series of
     commands you use repeatedly.  If a particular program calls for doing
     several things to prepare for it, you can probably do them in a
     script.  You could put your preparatory commands in it, save it in the
     "cmds" directory as "pstart", for program start, and do the job by
     just entering "pstart" (assuming your chx was set to "cmds").

     Scripts are really very easy to write.  You'll see.  But all is not
     rose petals here either.  Sometimes, even when the script lines appear
     to be perfect, a line will just not work.  Swapping lines sometimes
     makes a difference.  Script lines do not give error messages.  Shell+
     will automatically get a script from the execution directory (set by
     chx).  You can NOT load a script into memory like other commands
     unless you upgrade to Shell+ v2.0 or higher.

     I have tried to say (perhaps warn), in a simple way, how complex OS9
     can be.  (Even the explanation has become somewhat complex.)  I have
     tried to offer some preparation for dealing with that by covering an
     area or two that has been especially problematic for the new OS9 user
     - the manuals can be very frustrating sometimes.  Perhaps the best
     preparation is to tell you that this is just the "tip of the iceberg."

                                      -9-










                        The Firing Line

     Since directories and the CHD and CHX commands are at the center of a
     lot of beginners problems here is still more to help make things
     clear.

     When you type in a line like:

          list /d1/modules/bootlist

     the system looks for those names on the disk.  It looks first for
     "list" in the execution directory then looks for a descriptor named
     "d0", a directory named "modules" and a file named "bootlist".  It
     must have the numbers that these names represent, and it scours one or
     more disks looking for them in logical ways.

     But when you use CHD and CHX those numbers are stored for quick use.
     If the "CMDS" directory is, for example, on line 1 to drive 1 and on
     sector 872, the CHX command stores that information.  It is as if a
     big arrow were pointing to that sector.  After that, any time the
     system "sees" a command it jumps to those numbers - that sector.  That
     is why it cannot look for the "CMDS" directory by name.

     Here are some typical command line problems.

     Say you have put a system disk in drive 0 and issued a "CHX /d0/cmds"
     command.  Then you enter:

                copy /d0/sys/stdptrs  /d1/sys/stdptrs

     Things will probably be okay.  But if you were in a hurry it may be:

                cpy /d0/sys/stdptrs  /d1/sys/strptrs

     The system cannot find "cpy" and you get a 216 error.

     If you put the disk in but forgot the CHX command, a perfect command
     line will probably give you a 215 error - bad pathname - because the
     system jumped to sector so-and-so and there was no "CMDS" directory
     there!  See??  Right there is where a lot of frustration comes in.
     (Sometimes this may work, because if the command is in memory [where
     the system first looks] it will work anyway.)

                 "copy /d0/sys/stdptrs /d1/sys.stdptrs" isn't a hard
     mistake to make if you're not a good typist.  This will cause the
     system to store a file in the directory last indicated by CHD and name
     it "sys.stdptrs."

                 "copy /d0/sys/strptrs /d0/sys/stdptrs" will probably give
     you a 218 error - file already exists.

                 "copy /d0/sys/stdptrs /d1/sys/stdprts" will not give you
     an immediate error.  But when something looks for "stdptrs" and there
     is nothing but "strprts" it is 216 time again.

                                     -10-










     Believe it or not, if you have set CHX to /d1/cmds, for instance, and
     you decide to use a command (let's say "list") which is in your
     /d0/cmds directory you can enter something like:

                 /d0/cmds/list /d0/txt/message.

     Lastly let me touch on redirection again.  While making up a new
     bootfile (OS9Boot) I had some problems.  I decided to use the "ident"
     utility to look at what was in the file.  With 30 or 40 or more
     modules in OS9Boot you just can't get the idea on the screen.  So I
     redirected the output of the ident.  A normal ident on a single module
     might look like this:

                 ident /d0/modules/cc3disk.dr

     By redirecting output like this:

                 ident /d0/OS9Boot >/p

     I had all of the modules information sets printed out in hardcopy
     instead of the screen.

     You don't have to be typing command lines to get errors.  Some
     utilities REQUIRE certain CHD settings, and if you just forgot to do
     one the utility could be getting the wrong information or none at all.

     To really bring your system up to date, RICKULAND is distributing some
     very cheap sets of all the things you need to make a new system out of
     what you started out with.  Contact him on the OS9 Sig.

     This is really a good idea, because you can spend days, weeks or even
     months acquiring all the patches and getting them flawlessly into
     place.  AND you will find that some of the very good public domain
     software available does not work well unless the original bugs are
     eliminated from the operating system itself.

     I'm going to mention something Rick suggested, so you can "chew" on
     it. It comes with a sort of catch 22 built in so be careful how you
     size it up.

     Although the OS9Boot file must be in one contiguous file, not stored
     in various parts of the disk, it does not need to start at the
     beginning of the disk.  So you could put your commands directory on
     the disk first - on all your system disks - and the pointer set up by
     the CHX command would be the same for every disk.  Therefore you would
     not have to reset it except for times when you used /d1.

     The trick here is that by the time you might feel you have the
     expertise to do this you would probably have several system disks set
     up the other way.  Those disks would require "CHXing" as usual and the
     mix might not be worth the effort.


     Jim LaLone    (upper middle class neophyte)     On Delphi: TERMITE

                                     -11-