                         TWEAKING T-DOS

        A few notes on getting the most power from T-DOS
                        By Ronald Collins

    I have been working in the T-DOS environment since it's early 
development days.   I have watched this fabulous operating system 
by Tony Morehen of AJM Software grow from "NEWCCP" in 1987, to  a 
fledgling replacement for CP/M in late 1988.  As new hardware was 
developed by Big John at Orphanware, Don Pearlman at IHS and many 
others, T-DOS was modified to provide support for it.  When large 
disk drives were placed on the market, T-DOS was already to go to 
make it work on an ADAM.  When the clock card was released,  that 
to  was provided for in T-DOS.  When those hard drives we've  all 
been  reading about became available, T-DOS again  was  enhanced.  
Mark Gordon's new PowerMate system, with it's new two serial port 
set-up, called for yet more changes.  T-DOS again met the need! 

     Whether the changes involved larger disk drive sizes, bigger 
memory expanders, printer interfaces, new hard drives, or even 80 
column video units, T-DOS was written to support it all!  AJM has 
two of the finest Z80 programmers I've ever known on it's  staff.  
In fact, these two programmers comprise the entire are the staff! 
Tony  Morehen and Guy Cousineau, though now separated by  several 
provinces in CANADA, continue to provide support and enhancements 
for this most powerful of ADAM operating systems!

     You would think that by now I'd have figured out every trick 
in the T-DOS book wouldn't you?  Well, I've figured out a lot  of 
things, but nobody can learn everything on his own.  When I  went 
to ADAMCON 03, Guy Cousineau passed along some special "speed-up" 
hints.   Tony Morehen gave me a few more.  Rob Friedman, the  CPM 
SYSOP on CompuServe's Computer Club Forum even came up with a new 
twist that I want to pass along.  So, if you've ever wanted me to 
show you how T-DOS can "do something", just stick around.  I'm so 
sure  you'll be able to use some of these things to enhance  your 
use of the ADAM that I can't wait to get some feedback from you!

     For a lot of the tricks I'm going to pass along, you will be 
using a TEXT EDITOR.  I use VDE or ZDE, both similar versions  of 
a very popular PUBLIC DOMAIN word processors.  A good deal of the 
tricks involve SUBMIT files which you will have to write.  That's 
why we'll need the editor.

                        SAVING DISK SPACE

     This one is easy.  When you instal T-DOS, you are asked,  as 
one of the options, what you want to set up as your DEFAULT PATH.  
For those who don't know what a PATH is, let's take a minute  and 
look at one.  T-DOS always looks at anything you type.  When  you 
press the RETURN, T-DOS looks for a command that matches what you 
have typed.  If you typed IMP and pressed the return, T-DOS would 
look at where you now are for a file named IMP.COM.  If you typed 
this command on drive B:, user area 3: (B3:) for instance, the OS 
would look for IMP.COM to be on B3: and ready to run.  If it does 
not find it there, it's default path is to go to user area "0" to 
find the file.  Since we are on drive B:, T-DOS would look for it 
to be on B0: if IMP.COM is not found on B3:  If it's not there, a 
search is then made to the main file search area; A0:  If it's in 
some other user area or drive, then T-DOS will give you an "IMP?"
error message telling you that it couldn't find the file.

     Now that you know what a path is, let's figure a way to make 
it work for us.  When you start to load files onto your disk or a 
hard drive, try to figure out WHERE you want certain files to be.  
I  have a hard disk with 5 partitions, A:,B:,C:,D: and E:.   Each 
of these has 32 different user areas into which I can place files 
to keep like programs together.  If you only have one disk drive, 
or even one data drive, you still have 32 user areas available.

     The idea is, you can get out a piece of paper and use it  to 
"map out" your system.  I, like most hard drive users, don't have 
an  overabundance of space on my A: drive.  For this reason,  you 
can separate files into specific areas.  I have placed all of  my 
UTILITY files onto E15: My WordSTAR files are on C0: and my MODEM 
programs  are on A1:  To make all of this work, I took  advantage 
of the PATH option when I installed T-DOS.  The system told me it 
was set-up for a single path option A0:.  It then asks CHANGE Y/N
to which I answered Y(es).  The new path I typed in was: 
A0: A1: C0: E15:   I pressed the return and was asked again if  I 
wanted to change it.  I pressed the N(o) and the new path was set 
when I finished the installation and booted the new system.

     Now,  if that IMP program isn't on B3:, T-DOS will look  for 
it in the same places as before, but it will also search A1:, C0: 
and E15 for it.  Since IMP will be with my other modem programs I 
have stored on A1:, T-DOS will find it and boot the program.  Now 
I can boot selected software from just about anywhere on my ADAM!
The  result of all this work is to free up space on my most  used 
drive area, A0:. There are many programs that require all support 
files to be located on A0:.  It just makes good sense to leave as 
much space for this type of program on your A: drive as possible.  
Space that used to be taken up by utility programs can now reside 
on  some other, less used drive/user area.  The  extensive  T-DOS 
path capability has freed up more than 5 megabytes on my drive A, 
so it's easy to see how truly useful it can be.

                 PROGRAM NAMES REALLY DO MATTER!      

     Now, let's take a look at how T-DOS processes a command that 
you have typed. T-DOS has the ability to use multiple commands in 
order, one after the other.  All you do is place a semi-colon ";" 
between commands.  For instance, I could have gotten a directory, 
cleared  the display screen and then booted that IMP program  all 
with one command line.  That line, separated by semi-colons would 
be:    DIR;CLS;IMP followed by a RETURN.  Now, suppose that EVERY 
time  I want to use IMP, I do exactly that i/e: get a  directory, 
clear the screen and then, finally, boot IMP.  Wouldn't it be  so 
much faster to only type IMP than to type DIR;CLS;IMP?  Sure!

     We  have  done things like this before using  SUBMIT.COM  or 
EX15.COM.   These programs read a series of commands from a  text 
file  and go to work processing each command in line.   When  one 
task  is done, the next one in line is activated.  This  goes  on 
until  everything in the text file has been processed!  Nice  and 
neat!

     To  make that sort of thing possible, Tony built the  submit 
utility right into T-DOS!  This built-in submit processor is  one 
of the most feature-packed, powerful versions I've ever seen.   A 
feature of T-DOS is that when you type a command (any command), a 
search will first be made to find a submit file by that name. The 
submit files all have the extension of .SUB, by the way.  In  the 
case of that IMP command, T-DOS looked for IMP.SUB first.   Since 
it didn't find it, it then looked for IMP.COM.  This it DID  find 
and subsequently booted.  This double search, through the  entire 
path takes only milliseconds... but it still takes more time than 
you may want to wait.  There are a few ways you can speed  things 
along.  Let's take a look at some of them.

             CALL IT WHAT YOU WANT T-DOS TO LOOK FOR

     Rather than just type IMP and pressing the RETURN key, T-DOS 
would be able to load my modem program ever so much faster if  it 
new EXACTLY what I wanted it to load... and from WHERE!  Since it 
is located in my MODEM files area on A1:, I could have gotten IMP 
to  load in the blink of an eye by simply typing  A1:IMP.COM  and 
then pressing the return.  T-DOS would instantly jump to A1, boot 
IMP  for me and come up... all with me still on B3: and ready  to 
go!  Nice and simple.

              BUILD UP A USEFUL SUBMIT FILE INSTEAD

     To get a directory read and then clear the screen before IMP 
loads is still quite possible.  The key is to using that built-in 
submit processor to our advantage.  Let's built up a simple one I 
like to use with our favorite text editor.  Be sure to do this in 
a NON-Document mode so that now extra control commands get  saved 
with the file!  I'll be using ZDE for this, you can use what ever 
program you prefer.  To start it, I type ZDE IMP.SUB /N  This way 
ZDE will boot and create a non-document text file called  IMP.SUB 
and wait for me to fill in the text.  Our text will be simply:
DIR;CLS;A1:IMP.COM  I have to press the return after this line to 
move the cursor down to the next line.  To save the file, I  just 
hold  in the ESCAPE key and press the "X" key on my keyboard.   I 
now have a file called IMP.SUB on my disk.  If I put this file on 
the  user "0" area of each disk, no matter WHERE I'm at, I'll  be 
able to use it!

             SOME HELPFUL SUBMIT FILES YOU CAN BUILD

     There are many complex or just simple tasks that can be done 
easier  with the aid of a submit file.  For instance,  no  matter 
where you are on your system, you can get back to the A0: area in 
a really FAST way if you put a file called A.SUB on each "0" area 
of your disk or hard drive partition.  The text of A.SUB is just:
A0: followed by a return (which doesn't show up).

     I  have a T.SUB in that same "0" area to always give me  the 
time.  T.SUB reads: E15:TIME.COM followed by a return.

     I also wrote a help file that lists the names of my favorite 
utilities  and tells me what they are called.  It also  describes 
each file briefly.  This way, if I forget what I've named one  of 
my utilities, I have a simple way to find it. I first typed up my 
help file and saved it as HLP.TXT.  Next, I wrote a submit file I 
will use when I need to read that text file.  This file is called 
HELP.SUB and is also put into the "0" area of each disk.  The SUB 
file  is simply: TYPE HLP.TXT followed by a return.  When I  type 
HELP and press the return, T-DOS looks for a file called HELP.SUB 
which it finds.  HELP.SUB tells it to type out HLP.TXT on the  TV 
display.

     I wanted to have a MOVE program written for T-DOS  recently, 
but  Rob Friedman came up with a slick way to use this SUBMIT  to 
do the same job.  MOVE is a way to take a file on one  drive/user 
area and move it completely to some other drive/user.The original 
file should be gone when you are done.  What I wanted this for is 
to help with my file maintenance.  When I download a new file  to 
my ADAM, I always try to store that file on my D0:DOWNLOAD> area.  
This is a good central location that is used for nothing but  the 
download and testing of new software.  When a new program  checks 
out as a good, workable file, I determine where that program will 
best be moved to.  Modem programs, for instance, would always  be 
copied to A1: where it will be with other "like" programs.   When 
the program has been copied to it's new home directory, I have to 
go back and delete the copy of that file on D0:.  I wanted a MOVE 
program that would copy that file where ever I told it, then auto 
delete the original copy.  Doesn't it make sense to type:

                       MOVE IMP245.LBR A1: 
instead of:
                       COPY IMP245.LBR A1:
and then:              DEL IMP245.LBR

     I should make a note here about the multiple command  option 
that Tony's built-in submit function provides. By placing several 
commands on one line, each separated by a semi-colon ";".  Take a 
look back at that submit file I wrote to load IMP.  You remember, 
it was: DIR;CLS;A1:IMP.COM  That use of the semi-colon could have 
been used in this situation as well.  I could have typed:

COPY IMP245.LBR A1:;DEL IMP245.LBR

     That's not to bad, but I still need to type the same sort of 
thing for each successive file I want to move.  A MOVE.COM  would 
save me (an you) a great deal of time.  When I mentioned this  to 
Rob  Friedman on CompuServe recently, he decided to try the  same 
thing with some of those lesser documented features of T-DOS.  If 
you  have a string of commands that you would likely repeat  from 
once session to another, but with differing files, then what  you 
need is a sort of "task processing."  By the use of the "%"  key, 
you can substitute a number from 1 to 9 followed by a %.  What is 
typed first will represent 1%, what is typed next will equal  2%, 
and so on.  Using this ability of T-DOS, Rob wrote MOVE.SUB....

COPY %1:%2 %3;DEL %1:%2

     In this submit file, Rob has issued the COPY command with  3 
parameters  following it.  Remember, a file has a filename and  a 
file type (as in IMP.LBR)  The period between the two words keeps 
the filename and the file type together.  In his submit file, Rob 
has  used a colon ":" to tie the two parts.  Notice the %1:%2  in 
the file?  Now, where we want the file to go is the third part of 
the command.  This is represented by %3.  Next, a semi-colon told 
T-DOS  to look for another command to perform, which is DEL  (for 
delete).  It isn't necessary to tell the system those names again 
because we've already done that.  All we have to do is remind the 
system which file names we mean by repeating the %1:%2. 
      
If we type MOVE IMP245.LBR A1:, T-DOS looks at it and replaces  % 
place holders with what we've issued as data.  In this case, it's 
represented like this:

MOVE IMP245.LBR A1: which is seen as:  COPY 1%:2% 3%;DEL 1%:2%
This is stored in command memory as: COPY IMP.LBR A1:;DEL IMP.LBR

     In  nothing flat, T-DOS smoothly moves my file over  to  A1: 
and deletes the copy of it from D0:  This will work no matter how 
the  program is named.  I've placed a copy of this MOVE.SUB  file 
on the "0" user area of each valid drive where it can be used  on 
each drive as needed. 

       USING XSUB TO AUTOMATE DIFFICULT OR REPETITIVE TASKS

     This next section was taught to me by Guy Cousineau at ADAM-
CON 03.  Guy and I had been discussing some of the things he  had 
figured out as real time savers. Some of what we've covered above 
was first learned from Guy at that convention.  Using XSUB is one 
thing I've never quite understood.  What's it for and what does a 
person use it for?  Well, thanks to Guy, I now know some of  what 
XSUB can do!  "XSUB" is a program that can be used with a  submit 
file to "fill in the blanks" so to speak.  If you've ever used an 
installation  program, you know how repetitive it can be to  copy 
each command over and over again.  PASCAL programs, for instance, 
all  use the same installation routines.  Rather than repeat  the 
same  answers to each question you are asked by the  installation 
program, why not do it only once?

     The trick is to write down your answers on a piece of  paper 
as you type them in.  Your response to each question, in the same 
order you made it, can then be written into a submit file with  a 
word processor for later use with other programs.  When you  want 
to install another PASCAL program for use on your ADAM, just  use 
your new INSTALL.SUB to do it for you automatically!

     What  started Guy's lesson was my mention that  I  sometimes 
reinstalled T-DOS for different configurations, depending on what 
I happened to be working on.  I might need 40 column or 80 column 
video, need to support only data drives or maybe 4 disk drives. I 
might  only need to install a new version of T-DOS on  my  normal 
hardware set-up.  In each case, a small submit file could be made 
to answer all the T-DOS installation questions as they are asked.

     At  Guy's request, I went through a complete T-DOS  install, 
right down to installing SmartKey strings.  As each question  was 
answered, I copied the answer to it onto a piece of paper.   When 
this  was all completed, the paper was transcribed into a  SUBMIT 
file using ZDE.  XSUB was used to send each answer as needed.  It 
all ended up looking like this:

e15:xsub.com
80bhd45.com
3
b

3
5
0
2
15
0
1
3
0
y
a0: e15: a1: c0:

y
y
y
n
n
n

     Each  of the blank lines you see is simply a <return>.   The 
use of the submit file is pretty easy.  Just type INSTALL  80TDOS 
and press <return>.  T-DOS will read the file named  INSTALL.SUB, 
follow it's first command and load XSUB.COM from drive E15:,  and 
then load the program 80TDOS.COM.  As 80TDOS asks for information 
on  how I want it to be set up, the answer will be read  by  XSUB 
from the submit file.  The answers will be supplied in the  order 
they are written, much as in a SmartBasic data statement!

     When it's all done, I can simply pull the computer reset  to 
load  up my newly installed copy of T-DOS.  Another, simpler, use 
of the XSUB command in a submit file can be demonstrated.  I have 
a very powerful database package called CONDOR.  This package has 
certain questions that must be answered each time you boot it. As 
the program is loaded,  it asks you for your license number.  You 
must fill this in if you want to edit data fields, etc.  Next, it 
wants to know what your master disk will be. This is where CONDOR 
will look for all of it's support files.  Finally, to look proper 
on your video screen, you must tell it what terminal emulation is 
being  used.   That license number is nobody's business but  your 
own (to stop software pirates), but the rest is essential to  the 
use of CONDOR.   For this reason, the license number can not even 
be  used with XSUB... it just ignores the submit file data  until 
the user either supplies that number manually or presses the <cr>

     Once  the return is pressed, CONDOR knows that someone  else 
is using it and limits some of the program capabilities.  This is 
useful for employees to enter data while you keep the ability  to 
edit parameters.  As soon as it's been directed by this info, the 
software will then except data supplied by the XSUB file.  I keep 
CONDOR on C12:, so drive C: will be my MASTER directory.  To tell 
this to CONDOR, I have to type SET MASTER C: and press the return 
key.  To tell it that my terminal type resembles a LEAR ADM-3,  I 
have to type TERM=LEAR and press the return. The submit file then 
is written as:

E15:XSUB.COM
C12:CONDOR.COM
SET MASTER C:
TERM=LEAR

     To  use it, I've named the submit file, CONDOR.SUB.  When  I 
type CONDOR and press the return, the submit file is loaded and a 
quick booting is taken care of.  I'm sure there are many  similar 
uses that you can find for combining XSUB and the built-in submit 
processor.  If you've found any other good ideas on  streamlining 
the use of T-DOS or programs under T-DOS, let me know.  I think a 
sharing of information is essential to keeping the ADAM community 
more of a FAMILY.  If nothing else, I've learned a long term need 
for attending those ADAM conventions each year.  I hope to see  a 
good turn out at the 1992 convention July 23 to the 26th of 1992.  
I hope to see YOU there!

                                             Ronald Collins
  