BASIC Parms
        (PC World Star-Dot-Star Vol 1 No 8 November 1983)

     BASPARM.BAS shows how a Compiled BASIC program can access DOS
command line parameters.  Using this technique, a compiled program
can pick up the parameters on the DOS command and take action.  For
example, if you type PROGA B:DATAFILE.TXT;NEW as a command or in a
batch file, this routine will place in the variable PARM$ the string
B:DATAFILE.TXT;NEW.  You can then strip away any blanks and separate
the individual parts of the parameter string as needed by the
particular program.
     In this example, the program PROGA may have been written to open
a file and to add data to it.  The program expects to open the file as
an append file unless the NEW part was specified on the command, in
which case the file would be opened as an output file.
     The comments in the BASPARM.BAS provide detailed documentation of
what the routine does.  Note the warning that the routine works in a
compiled program only and that it should not be altered unless you are
very careful not to cause any string variables to be generated.  The
best way to use this routine is to place it at the beginning of the
program.
- - - - -
10 'BASPARM.BAS: Routine to determine parameters on DOS
20 'Calling sequence from BASIC: (compiler only)
30 'It is very important not to alter the sequence of these
40 'instructions or insert any code without full knowledge of 
50 'the interface structure
60 DEF SEG    'Point data segment register to BASIC segment
70 DIM SUBR%(3)    'Array to contain machine subroutine
80 DEF USRO=VARPTR(SUBR%(0))    'Get subroutine's segment offset
90 SUBR%(0)=&H5B59     'POP   CX     POP   BX
100 SUBR%(1)=&H5153    'PUSH   BX     PUSH   CX
110 SUBR%(2)=&HEB83    'SUB   BX,10H
120 SUBR%(3)=&HCB10    'RETF
130 I%=0               'Dummy parameter to function call
140 PSP%=USRO(I%)      'Get program segment prefix's segment
150 DEF SEG=PSP%       'Set Base register at that segment
160 PARMLEN%=PEEK(&H80)   'Get command parameter length
170 PARM$=""              'Set up string to receive parameters
180 FOR I% = 1 TO PARMLEN%    'Loop through parameter string
190 PARM$=PARM$+CHR$(PEEK(&H80+I%))   '& concatenate characters
200 NEXT I%                        'together until end of string
210 DEF SEG                        'Return to normal data string
300 FIL$=MID$(PARM$,2)
     
----------------------------------------------------------------
                           BASIC Tips
         (PC World Star-Dot-Star Vol No 8 November 1983)

     You don't need to put a closing double quote around file names
that are the only parameter of a command; LOAD "FILESPEC is just as
acceptable as LOAD "FILESPEC".
     You can use square brackets to dimension and index arrays.  This
can make statements that have many parentheses easier to read:

DIM A[20] OR A[1,2] works just fine.

     You don't need to put a comma, semicolon, blank, or concatenation
symbol between items that constitute a parameter list for PRINT.  For
example, PRINT "STRING"STRING$(10,40)A$ is an acceptable entry.
     If you are using a color monitor, you can work in DOS in color
by typing the following in BASICA: COLOR n : CLS : SYSTEM in which
"n" is the number of the color you want.
     If you are using Boolean data and need all 16 bits that can be
stored in a 2-byte integer, write your data in hexadecimal or octal.
This avoids the necessity of computing the two's complement of your
constant to turn on the high bit (two's complement notation is the
way negative numbers are stored).  For example, PRINT &H0FHOF
OR &HFOFO.
     You don't need to put the number sign (#) in front of file
numbers for file statements such as CLOSE, FIELD, GET, etc.; GET
1,10 is the same as GET #1,10.
     You can't put a comment at the end of a DATA statement --
DATA 10,20,30 'comment won't work.  This flaw can be overcome by
starting a new statement:  DATA 10,20,30:'comment.

-----------------------------------------------------------------
                     BASIC Variable Checker
         (PC World Star-Dot-Star Vol 2 No 4 April 1984)

     It is often necessary to examine the current values of variables
while you are trying to debug a BASIC program.  The listing VARCHKR.BAS
is a BASIC subroutine that displays the scalar variables from a BASIC
program.  It was developed as a general debugging aid for use on any
program in place of inserting the ad hoc PRINT statements usually
used to help find errors.  When called, the subroutine will list all
the scalar (not dimen-sioned) variables and their current values.
Variable type symbols (%,!,#,$) are included in the listing regardless
of how the variable names appear in the main program so that no
confusion exists between variables of different types with the same
letter names.
     The line numbers are high so as not to interfere with the line
numbers in your program.  Also, all the subroutine's variable names
contain a period (.), minimizing the chances of duplicating a variable
name in your program.  The subroutine's variables will not be listed.
If your program uses any of this subroutine's variable names, change
those names in your program to keep the subroutine from changing a
program variable when it is called.
     After the subroutine has been entered and SAVEd (with the ASCII
option) as VARCHKR, use it as follows. With your BASIC program loaded
in memory, issue the command MERGE B:VARCHKR (assuming you have the
subroutine on the disk in drive B) and insert GOSUB 60000 in your
program wherever you want a dump.

64000 P.%=PEEK(858)-6:Q.%=PEEK(859)
64010 A.%=PEEK(856)+256*PEEK(857)
64020 T.%=PEEK(A.%):E.%=PEEK(A.%+3):L.%=T.%+E.%+3
64030 N.%$=CHR$(PEEK(A.%+1)):IF PEEK(A.%+2)>.0 THEN N.$=N.$+CHR$
(PEEK(A.%+2))
64040 IF E.%>0 THEN FOR K.%=1 TO E.%:N.$=n.$+CHR$(PEEK
(A.%+3+K.%)MOD 128):NEXT
64050 IF T.%=3 THEN 64120
64060 V.$="":FOR K.%=1 TO T.%:V.$=CHR$(PEEK(A.%+L.%-K.%+1))
+V.$:NEXT
64070 ON T.%/2 GOTO 64080,64090,64180,64100
64080 V.!=CVI(V.$):T.$="%":GOTO 64110
64090 V.!=CVS(V.$):T.$="!":GOTO 64110
64100 V.!=CVD(V.$):T.$="#"
64110 PRINT N.$;T.$;"=";V.!:GOTO 64150
64120 B.!=PEEK(A.%+L.%-1)+256*PEEK(A.%+L.%)
64130 T.$="":FOR K.%=1 TO PEEK(A.%+L.%-2):T.$+CHR$(PEEK
(B.!+K.%-1)):NEXT
64140 PRINT N.$"$=";CHR$(34);T.$;CHR$(34)
64150 IF A.%+L.%<P.%+256*Q.%-1 THEN A.%+L.%+1:N.$="":GOTO 64020
64160 V.$=INPUT$(1)
64170 POKE 859,Q.%:POKE 858,P.%:RETURN
64180 PRINT "error in dump routine"

-----------------------------------------------------------------
                         BASIC Labeling
      (PC Magazine Vol 3 No 18 Sept 18, 1984 by J. Thacker)

     Labeling with BASIC is a simple programming method that can become
second nature to you once you have tried and mastered it.  Reserve the
first four lines of each BASIC program (Figure 1).  The first line (10)
is a "skip" instruction; it simply jumps to the start of the program.
The second line (20) is a REMARK statement.  The third line (30) is a
RETURN statement.  The fourth line (40) is the actual start of the
program.  Line numbers 20-30 are reserved for subroutine and branching
labels.
     No matter how many times a program is renumbered, lines 10 and 20
remain the same.  Consider line 20 your "home base," the one location
within the program that remains unchanged regardless of what happens
to the rest of the program.  All future subroutines will refer to this
line number.
     Say, for example, that in step 820 in your program you want to
reference a subroutine to compute interest.  The subroutine is written
in an obscure location that has not been used before (Figure 2).  To
label this subroutine for future reference, define statement 820 as:
          820 S$="INTEREST":GOSUB 20
And, in the subroutine for labels, which starts at line 20, add:
          21 IF S$="INTEREST" THEN GOSUB 10000
You can define other subroutines in the same manner by using line
numbers after line 20 (Figure 3).
     When line 820 is reached during program execution, the reserved
variable S$ is defined as "INTEREST" and the program branches to line
20.  The various subroutine names that have been placed after line 20
will be evaluated, and those that match the current definition of S$
will be executed.  The program will return automatically to the
instruction following the GOSUB after execution.  Any time you want to
execute subroutine INTEREST (anywhere in the program and as many times
as you wish), simply insert a line similar to line 200.  If the program
is renumbered, lines 10 and 20 remain the same and, even though line 21
within the label subroutine and line 10000 for the subroutine INTEREST
will change, it doesn't matter, since S$="INTEREST":GOSUB 20 will
always execute the subroutine and return.  The line number of the
subroutine does not need to be remembered.
     Any number of subroutines can be processed in this manner.
Initially, only nine subroutine lines can be added between lines 20
and 30.  As you renumber your program, additional line numbers become
available and as many subroutines as necessary can be added after line
20.  Note that with each renumbering, the first line of the program
(10) automatically branches to the first step of the program, no matter
what it might be.  Subroutines can be given any name and can include
spaces and punctuation marks.  In other words, any valid string may be
used as a subroutine name.  This is a feature some of the most
sophisticated structured languages do not allow.
     There is a slight hitch to this technique.  Each time the program
is renumbered, the subroutines are renumbered as well and will
immediately follow your last program step.  This leaves only a few
additional spaces for more program statements.  This could be a
drawback were it not for an easy fix.
     Immediately after line 20, add a statement that "points" to the
starting location of all the subroutines used in the program.  The
dummy statement might appear something like:
      21 IF S$="FIRST LINE NUMBER IF SUBROUTINES" THEN GOSUB 5000
Then at line 5000 insert a statement such as:
          5000 REM ***First line number of subroutines***
All subroutines would then be defined with line numbers higher than
5000.  Now, everytime a program is renumbered, you should list line
numbers 20-100 and look for the statement above, which might now
appear as:
       40 IF S$="FIRST LINE NUMBER OF SUBROUTINES" THEN GOSUB 470
Note that both the first line number and the last number have changed
because of the renumbering.  Now, renumber the program with the
statement RENUM 10000,470.  This procedure has no effect on the first
460 lines of the program, which include the main program, but it moves
all subroutines to line numbers higher than 10000.  Any time the
program is listed (such as LIST 100-1000), only the main program will
appear, and not the subroutines, which have been shoved out of the way
to the end of the line, leaving plenty of space for further program
development.
     Once you develop the habit of regularly renumbering your program
and immediately shoving subroutines out of the way with a second
renumbering command, you will quicky learn to assign very high
temporary line numbers to new subroutines that you create.  Each time
you renumber this high range is free to use again.
     The procedure for labeling GOTO statements is virtually identical
to that used for subroutines.  When you want to branch regularly to a
particular program step, simply add a statement such as the following
to label the subroutine:
          22 IF S$="MENU" THEN GOTO xxx
To branch to this place in the program, the following statement is
added wherever the branch is to be made:
          xxx S#="MENU":GOTO 20
No matter how many times you renumber a program, MENU can be accessed
by defining S$ as "MENU" and a GOTO 20.  You don't need to remember
the line number for the segment called MENU.
     The difference between GOSUB 20 and GOTO 20 is, of course, that
the GOSUB executes a subroutine and returns, while GOTO branches
permanently to a new program step.
     A minor inconvenience of the labeling technique is that it cannot
be used directly with BASIC's ON (expression) GOTO n1,n2,n3,...
statement.  Other means of accomplishing this same objective can be
used, however.  The ON...GO...statements can still be used with labels
with a modification.  A brief example of how a program might be
structured for multiple branching is show in Figure 4.
     In this example, if the variable MONTH is 3, the program will
branch to statement 1540, which sets S$ to "MAR" and then branches to
line 20.  After line 20 you would add:
          IF S$="MAR" THEN GOTO xxx
to complete the branch.
     Using the ON...GOSUB... is a move complex procedure, since the
program is only temporarily branching and will be returning when the
appropriate subroutine is completed.  Thus you must prepare for the
return.  The example in Figure 4 might be modified (as in Figure 5)
were GOSUB used instead of branching.
     Liberal use of comments while developing a program and documenting
with REMARK statements are good practices.  Labeled subroutines make
this easy.
     Programmers often begin subroutines with a header marked with
asterisks (Figure 6).  When the program is listed, this type of header
flags each subroutine.
- - - - - - - - - -
Figure 1: Introductory program lines

10 GOTO 40  ****SKIP TO THE BODY OF THE PROGRAM****
20 REM        SUBROUTINE AND GOTO LABELS
30 RETURN
40 REM      ****BODY OF YOUR PROGRAM****
- - - - - - - - - - 
Figure 2: INTEREST calculation subroutine

10000 REM   SUBROUTINE *** INTEREST ***
10100 REM
10200 REM   CALCULATES INTEREST
10300            .
10400       (BODY OF THE SUBROUTINE)
10500            .
10600 RETURN
- - - - - - - - - -
Figure 3: Type first program steps

20 REM     SUBROUTINE AND GOTO LABELS
21 IF S$="INTEREST" THEN GOSUB 10000
22 IF S$="AMORTIZATION" THEN GOSUB 12000
23 IF S$="END OF PAY PERIOD" THEN GOSUB 15000
24 IF S$="INITIALIZE PRINTER" THEN GOSUB 20000
25 IF S$="PRINT REPORT" THEN GOSUB 30000
30 RETURN
- - - - - - - - - -
Figure 4: Program structured for multiple branching

1510 ON MONTH GOTO 1520,1530,1540,1550,. . .
1520 S$="JAN":GOTO 20
1530 S$="FEB":GOTO 20
1540 S$="MAR":GOTO 20
- - - - - - - - - -
Figure 5: GOSUB alternative to simple branching

1510 ON MONTH GOTO 1520,1530,1540,1550,. . .
1520 S$="JAN":GOTO 1600
1530 S$="FEB":GOTO 1600
1540 S$="MAR":GOTO 1600
.        .          .
.        .          .
1600 GOSUB 20
1610 REM  ****CONTINUATION OF THE PROGRAM****
- - - - - - - - - -
Figure 6: Beginning of subroutine

7000 '****************************************************
7010 '*                                                  *
7020 '*         SUBROUTINE TO COMPUTE INTEREST           *
7030 '*                                                  *
7040 '*              CALLED "INTEREST"                   *
7050 '*                                                  *
7060 '****************************************************
7070 ' BEGINNING OF SUBROUTINE

-----------------------------------------------------------------
                    Assembling a Port Switch
      (PC Magazine Vol 3 No 18 Sept 18, 1984 User-to-User)

The following BASIC routine will run two printers:
     
10 DEF SEG=&H40
20 A=PEEK(&H8):B=PEEK(&h9)
30 C=PEEK(&HA):D=PEEK(&HB)
40 POKE &H8,C:POKE &H9,D
50 POKE &HA,A:POKE &HB,B
60 LPT$="2"
70 IF A=&H78 THEN LTP$="1"
80 PRINT "Primary printer = LPT";LPT$+":"
90 END

-----------------------------------------------------------------
                      BASIC Rounding Errors
               (PC Age August 1983 by D. Hohnadel)

     Many small scientific programs in BASIC that perform simple
calculations need to have the output rounded or truncated to a specific
number of decimal places.  A couple of common programming techniques
can be used to truncate or round numbers to a fixed number of decimal
places.  For example, to truncate the number x to two decimal places,
use the following:

10 X = 17.8792
20 Y = INT(100*X)
30 Z = Y/100
40 PRINT Z

     To change the number of decimals in the answer simply change the
multiplication and division factors in the above program.  For three
places, multiply x by 1000 and divide y by 1000 and so on for other
similar types of changes.  This process of truncating to a variable
number of places can be made easier by using an input statement for the
number of decimals as line 5 and changing the program as follows:

5  INPUT"Enter number of decimals required";A
10 X = 17.8792
20 Y = INT(10^A*X)
30 Z = Y/10^A
40 PRINT Z

If a rounded number is required, change the program to:

10 X = 17.8792
20 Y = INT(100*X+0.5)
30 Z = Y/100
40 PRINT

     IBM BASIC has an even simpler way to round numbers using the
command CINT; however, CINT does not, in every case, round down.
Another general form of rounding numbers using CINT is:
          Y = CINT(10^N*X)/10^N
With N=1, a simple example follows:
          10 X = 124.1477
          20 Y = PRINT CINT(10*124.1477)/10
The result is 124.1.
    These techniques, which work without error on many small computers,
only work sometimes on the IBM PC.  For example, see the following
program for conversion of degrees F to C.

A. Truncated results:  10 FOR F = 0 TO 212
                       20 D = (5*(F-32))/9
                       30 C = INT(D*100)/100
                       40 LPRINT F,D,C
                       50 NEXT F

B. Round results:  10 FOR F = 0 TO 212
                   20 D = (5*(F-32))/9
                   30 C = CINT(D*100)/100
                   40 LPRINT F,D,C
                   50 NEXT F

     When either of these programs is run, certain values of F cause
the output in degrees C, which should be two decimals, to become five
decimals.  Different values of F cause the problem with INT, than
those that cause the problem with CINT.  The problem can be shown to
to occur with the multiplication and division steps.  CINT and INT
seem to work properly when the programs are further extended to
produce separate steps for each of the program actinos.  The same
rounding results are produced (with the same errors) when line 30
below is substituted in the truncation program:
          30 C = INT(D*100+0.5)/100
As was stated earlier, adding 0.5 to the INT line will produce a
rounded equivalent of the CINT command.
    The values of F that produce an incorrent output with INT (that is,
too many decimals) are listed in the Table below.  The values of F that
produce errors at one decimal setting are not the same if different
multipliers and divisors are used in 30.
     The rounding problem is significant since different errors occur
depending on the number of decimal places.  It isn't possible to
predict which values will produce problems.  It is possible to correct
the problem by changing programming technique.
     The problem can be corrected or avoided by allowing the IBM PC
to format the result by using LPRINT USING or PRINT USING for output
rather than LPRINT or PRINT.  In this way the required number of
decimals can be produced.  Another way to also produce a correct
result is to use double-precision numbers for all calculations.

                         Decimal Places 

Value of F     One       Two       Three     Four

     16         X         -          -        -
     17         X         -          -        -
     48         -         -          X        X
     49         X         X          -        -
    186         -         -          -        X
    188         -         -          -        X
    190         -         X          -        -
    195         -         -          -        X
    197         -         -          -        X
    199         -         X          -        -
    204         -         -          -        X
    206         -         -          -        X
    208         -         X          -        -

-----------------------------------------------------------------
BASIC hint:  With BASIC's FILES command, you can use filespecs and
wildcard characters (? and *), just as you do with the DIR command
in DOS. To view only your BASIC files on a particular disk, use
the command:  FILES "*.BAS"
-----------------------------------------------------------------
BASIC hint:  If you want to display a high-resolution graphics image
in color, use the command OUT 985, colornum, where colornum is the
number of the desired color.  For example, the command SCREEN 2:OUT
985,14 changes everything on the screen to yellow, as yellow is
color number 14.  Note that this changes the foreground color; the
background remains black.  The command does not require DEF SEG,
because no PEEKing or POKEing is involved.  The OUT command can be
used to change colors as often as needed.
-----------------------------------------------------------------
                            Bug Hunt
               (PC World Vol 1 No 4 Star-Dot-Star)

     An annoying error with the VAL function is that it is used
frequently to detect the presence (or absence) of a numeric sequence
at the beginning of a string.  VAL is also often used to extract the
leading numeric content of a string.  A string with E of D (or
lowercase e or d) causes an overflow error.  It appears that on the
PC, BASIC is looking at the E and D as part of a scientific notation
instead of a simple alpha character.
     Attempting to convert the string `15%' causes a syntax error but
strings such as `15#' and `15!' convert OK.  Try these for yourself:
X$="E45" or X$="D45" or X$="5e45" or X$="15% and type PRINT VAL(X$).
     If VAL sees a purely numeric string, it works OK.  If the string
has alpha characters in it, however, under some conditions VAL will not
work as documented.  The presence of the percent sign is also apt to
cause errors.

-----------------------------------------------------------------
                        BASIC Parentheses
              (PC World Vol 1 No 4 The Help Screen)

     BASIC uses parentheses for two different purposes.  One use is to
enclose subscripts for variables, e.g., ALIAS(1), ALIAS(2), ALIAS(3),
each of which may be set to a different value.  Parentheses are also
used by some BASIC statements and by almost all BASIC functions to
enclose the arguments requried for a particular operation.  For
example, to find the square root of 4 we type PRINT SQR(4) and the
computer responds with 2.  If we type PRINT SQR (4) (note the space
between R and the opening parenthesis), we will get the same result.
However, if this extra space is included before the opening parenthesis
in the functions SPC(n) or TAB(n), BASIC will not recognize the intended
function; instead, BASIC interprets the intended function as a
subscripted variable.  Although BASIC will properly interpret all other
statements, subscripted variables and functions containing spaces before
parentheses, e.g., KEY (x) ON, SIN (y), and VARIABLE (z), it would be
wise to avoid having spaces before any parenthesis in all statements,
functions and subscripted variables of a BASIC program.

-----------------------------------------------------------------
             IBM BASIC's Undocumented SHELL Command
    (COMPUTE! Magazine Vol 7 No 4 April 1985 by M. Covington)

     The SHELL command in IBM BASIC takes one parameter, a character
string containing the DOS command to be executed.  SHELL works by
loading, from drive A, a second copy of COMMAND.COM (the DOS command
processor) and invoking it as a subprocess.  (Note that this implies
that COMMAND.COM must be present on the disk in drive A when the
SHELL command is executed.)  The top level COMMAND.COM and the BASIC
interpreter are in suspended animation until the subprocess finishes;
then control returns to BASIC.
     SHELL handles the cursor somewhat awkwardly.  When the SHELL
command is executed, the screen is cleared from the current cursor
position to the bottom; DOS writes its output there, scrolling as
needed (the 25th line scrolls along with the others).  But when
control returns to BASIC, the cursor suddenly appears one line below
where it was when the subprocess started, ignoring all screen activity
that took place under the subprocess.
     The best way to prevent chaos on the screen is to execute a CLS
immediately after each SHELL, or as soon afterward as you're done
looking at the output.
     The one command that SHELL cannot issue, either directly or
indirectly, is BASIC(A). If you try to do this, you get the message
"You cannot run Basic as a Child of Basic" -- naturally enough, you
can't run BASIC(A) in the subprocess because most of BASIC is in ROM
and there's only one copy of it in the machine.  If you issue a SHELL
and COMMAND.COM is not on drive A, you get a "File not found" error
within BASIC.
     The most useful SHELL commands are probably:
          SHELL "A:"
          SHELL "B:"
and the like, to change logged disks.  These are foolproof commands;
they produce no messages to clutter up the screen, and they can't
terminate abnormally.
     You can also use SHELL without parameters, in immediate mode,
to enter the DOS command mode. The advantage of this over SYSTEM is
that when you're done issuing DOS commands, you can type EXIT and
return to BASIC with your program undisturbed.
     Most kinds of errors in the subprocess will return you to BASIC
with no problem, but a few, such as typing A in response to "Abort,
Retry, Ignore," will leave you in the DOS command level of the
subprocess, in which case you must type EXIT to get back to BASIC.
     Don't issue several SHELL commands in succession if you can
avoid it; each of them loads COMMAND.COM all over again.  Instead,
if you have a series of commands to issue, write them onto a .BAT
file from within BASIC, and give one command to run the whole file.
The accompanying program demonstrates one way to use SHELL to create
a menu-driven user interface for DOS.  Naturally, a practical program
would include many more options and more error-checking.

                             SUMMARY
Purpose :  Executes a DOS command from within BASIC(A).  This is 
           done by loading a second copy of COMMAND.COM and invoking
           it as a subprocess.
Versions:  Cassette - no; Disk - yes; Advanced - yes
Format  :  SHELL  or  SHELL X$
Remarks :  X$ is a character string constant, variable or expression
           containing any valid DOS command.  In order for SHELL to
           work COMMAND.COM must be present on disk A.  If it is not,
           the message "File not found" is displayed.  X$ can be an
           internal DOS command or invoke a .COM, .EXE or .BAT file.
           However, the BASIC interpreter cannot be invoked using SHELL;
           if it is attempted, the message "You cannot run Basic as a
           Child of Basic" is displayed.  The amount of memory available
           in the subprocess is markedly less than is available in DOS
           by itself.  If X$ is omitted, the user is placed at the DOS
           command level of the subprocess.  To return to the calling
           BASIC program, type the command EXIT.  Certain fatal errors
           in the subprocess may also leave the user at the DOS command
           level of the subprocess; again, typing EXIT returns control
           to BASIC.  However, most errors in the subprocess return
           control to the calling BASIC program automatically.

Examples:  SHELL            (to go temporarily into command mode)
           SHELL "B:"       (to change logged disk)
           SHELL "DIR A:  :SORT  :MORE"
           SHELL "MYFIL"    (to invoke MYFIL.xxx)

See the BASIC disk for the program mentioned above.

-----------------------------------------------------------------
BASIC Hint: Add a dummy REM statement at the end of a BASIC program
to help in locating invalid line references and to delete blocks of
code.  Example:

10 PI=3.14
20 'Loop to get and print area
30 INPUT R
40 PRINT "Area = "PI*R^2
50 GOTO 20
65529 REM

It is easy to inadvertently delete a line reference by a GOTO or GOSUB
elsewhere in the program. For example, delete line 20.  In doing so,
you have created a dead-end reference in line 50.  But there's an easy
way to check for this.  Run:
          RENUM 65529,65529
This RENUM command will have no effect on the line numbers in the
program, but will list all invalid line references. In this case, the
following will be printed:
          Undefined line 20 in 50
Having "65529 REM" as the last line of the program is also useful when
deleting from mid-program to the end, since BASIC accepts
"DELETE 30-65529" but rejects "DELETE 30-".  Using this consistently
will save hunting for the last statement in your program.

-----------------------------------------------------------------
                    WHILE ...WEND vs. INKEY$
       (PC Magazine Vol 3 No 24 Dec 11, 1984 User-to-User)

     When most users want to poll the keyboard for a key press or
input a single character from the keyboard they include the line:
          100 A$=INKEY$:IF A$="" THEN 100
While this method works, a better choice would be:
          100 WHILE A$=" ":A$=INKEY$:WEND
The second method is better because:
     - There is a small decrease in program size
     - The first method varies according to the line's number, while
the second is independent of any GOTOs (an advantage during renumbering)
     - While debugging with the TRON trace command, the first method
fills the screen with <100>s while the second shows just one <100>
     - The second method allows the addition of statements on the same
line without any tedious IF ...THEN ...ELSE baggage, i.e.:
          10 WHILE A$="":A$=INKEY$:WEND:LOCATE X,Y:PRINT A$
rather than
          10 A$=INKEY$:IF A$="" THEN 10 ELSE LOCATE X,Y
     Make sure the value of the variable you use in the WHILE ...WEND
loop is null by inserting an A$="" before you use it.
     INKEY$ is really designed to allow program flow to continue
unimpeded if no key is pressed.  If you're looping through some tedious
math that can be interrupted if necessary, or running a loop to put
repeated graphics images on the screen, INKEY$ can allow the program to
continue running until a key is struck.  But INPUT$(1) can sit and wait
for a one-character input such as a menu selection of a Y or N.  INKEY$
has to be used when the user might hit a key that generates an extended
code (a two-character code where the first chracter is a null, or
CHR$(0)).
     For instance, run the following programs and hit the cursor keys
as inputs. INPUT$(1) grabs only the first character, the null, while
INKEY$ reads in the whole code.

100 A$=INKEY$:IF A$="" THEN 100
110 PRINT "**";A$;"**"
120 GOTO 100

100 A$=INPUT$(1)
110 PRINT "**";A$;"**"
120 GOTO 100

In the following case, the WHILE ...WEND method just spins the first
value that you enter down the left edge of the screen unless you first
take the trouble to null it:

100 A$=""
110 WHILE A$="":A$=INKEY$:WEND
120 PRINT "**";A$;"**"
130 GOTO 100

-----------------------------------------------------------------
                       BASIC Debugging Aid
       (PC Magazine Vol 3 No 24 Dec 11, 1984 User-to-User)

     DEBUGGER.BAS is a program that shows you the error number and the
line in which the error occurred.  It will automatically set up the
troublesome line to edit.

100 'DEBUGGER.BAS
110 ON ERROR GOTO 140
120 OPEN "e:test" FOR OUTPUT AS #1
130 END
140 RPINT "Error number";ERR;"in statement";ERL
150 EDIT .

     Editor's Note: The BASIC interpreter is good about telling you
what error it encounters and which statements were involved.  It is
useful for programs with short lines; however, for long, complex
program statements, having it say there's a syntax error somewhere
within the densely packed 254 characters doesn't help much.  The trick
of following the word EDIT with a period is valuable.  If you're going
to include this in the program, however, the interpreter won't tell you
what the error is.  However, by adding two lines:
          101 KEY 9,CHR$(31)+"RUN 10000"+CHR$(13)
          10000 ERROR ERR
you can have BASIC describe the error to you.  After you run the
original program and choke on an error, simply hit the F9 key and these
new lines will spell out what the error is.  As a matter of fact, you
can even do this in direct mode -- just get into BASIC, type the word
ERROR followed by a low integer, and then hit the Enter key.

-----------------------------------------------------------------
                      My Favorite Stripper
        (PC Magazine Vol 4 No 5 Mar 5, 1985 User-to-User)

     NUMSTRIP.BAS simply removes the spaces on either side of a
number.  BASIC prints a space to the left of a number to use for a
negative sign, when appropriate.  The DEF FNST$(Z) defined function
will do away with this space, so it really doubles as an absolute
value function (except that FNST$(Z) turns numbers into strings while
ABS(Z) returns numerical values). BASIC also prints a space to the
right of a number, and DEF FNST$(Z) gets rid of this as well.  It's
much cleaner and easier when mixing text and numbers to treat
everything like strings, and this makes it simple.  Otherwise, BASIC
pads every positive number with an extra space.
- - - - -
100 'NUMSTRIP.BAS (not for negative numbers)
110 DEF FNST$(Z)=RIGHT$(STR$(Z),LEN(STR$(Z))-1)
120 INPUT "Enter a number: ",N
130 PRINT "***";N;"***"
140 PRINT "***";FNST$(N);"***"

-----------------------------------------------------------------
                         Better Stripper
      (PC Magazine Vol 4 No 13 June 25, 1985 User-to-User)

     Since negative numbers occur just as often as positive numbers,
"My Favorite Stripper" (PC Mag Vol 4 No 5) could use a little
enhancement.  First, add the little-used SGN() function, which
returns a -1 if the number is negative and a +1 if the number is
positive.  This will work for all positive and negative numbers, but
not zero.  However, we can check to see if the number is zero, within
the formula, by using another trick.  If Z=0, that part of the formula
evaluates to -1, which will in turn remove the leading space.
- - - - -

Stripper Enhancement that works for negative numbers:
          DEF FNST$(Z)=RIGHT$(STR$(Z),LEN(STR$(Z))-SGN(Z))

Stripper that works with both negatives and zero:
          DEF FNST$(Z)=RIGHT$(STR$(Z),LEN(STR$(Z))-SGN(Z)+(Z=0))

-----------------------------------------------------------------
                        Ultimate Stripper
       (PC Magazine Vol 4 No 23 Nov 12, 1985 User-to-User)

     There is an even better way using a feature of the MID$ function
to strip leading blanks.  If the third argument is omitted, MID$
returns all characters from the position indicated by the second
argument to the end of the string, which means you don't have to use
either the LEN or SGN function.  The FNST$(Z) stripper below works
because the expression 2+(Z < 0) evaluates to 2 if Z is 0 or greater
and 1 if Z is negative.  Thus, MID$ will strip the leading blank from
STR$(Z) only if Z is not negative.
- - - - -
100 'BSTSTRIP.BAS
110 DEF FNST$(Z)=MID$(STR$(Z),2+(Z<0))
120 FOR A=-1 TO 1 STEP .5
130 PRINT "OLD: ***";A;"***";TAB(20);
140 PRINT "NEW: ###";FNST$(A);"###"
150 NEXT

-----------------------------------------------------------------
                         A Better INKEY$
       (PC Magazine Vol 4 No 14 July 9, 1985 User-to-User)

     It's possible to access extended functions (cursor keys, Ctrl key
combinations, etc.) through the BASIC INKEY$ system variable.  This
takes more understanding of the mechanics of INKEY$ than IBM is willing
to describe in its BASIC or Technical Reference manuals, however.  In
addition, INKEY$ distinguishes between uppercase and lowercase letters,
something that occasionally forces the user to look for both in
IF ...THEN filters.
    Programmers can use the machine-code subroutine in the INKEYNEW.BAS
program instead of INKEY$.  There are lots of ways to do this, but the
one illustrated in INKEYNEW.BAS POKEs values out of DATA statements
directly into memory (in this case into a protected area high in the
default segment for BASIC).  When CALLed, the subroutine returns the
ASCII code of the key pressed in the variable ASCI and the extended
code in the variable CODE.
     Notice that the CODE variable is the same for each key whether or
not the uppercase or lowercase version of it was typed.  This makes for
much more direct manipulation of key inputs than INKEY$ and at a cost
of only 29 bytes.
     Editor's Note:  This technique makes it easy to use such keys as
the Function keys, cursor arrows, Del, Ins, Home, and so forth for
program control.  And, it makes it a snap to pose "Yes/No" or "Choose
A, B, or C" questions without having to use the four or five popular
tricks to make the response insensitive to the case of the letter
entered.
- - - - -
100 'INKEYNEW.BAS
110 DATA 55,89,E5,8B,7E,6,8B,76,8,31
120 DATA C0,31,DB,CD,16,88,E3,30,E4
130 DATA 89,5,89,F7,89,1D,5D,CA,4,0
140 CLEAR,&HEFFF:DEFINT A-Z:INKE=&HF000
150 FOR X=1 TO 29
160 READ A$:A=VAL("&H"+A$):POKE X+&HEFFF,A
170 NEXT X
180 PRINT "Now start hitting keys....."
190 PRINT "CODE","ASCI";SPC(6);"CHR$(ASCI)" 
200 CALL INKE (CODE,ASCI)
210 PRINT CODE,ASCI,CHR$(ASCI)
220 GOTO 200

-----------------------------------------------------------------
                          Better Delays
      (PC Magazine Vol 4 No 12 June 11, 1985 User-to-User)

     Custom programming for the IBM PC works nicely on the PC AT except
for FOR ...NEXT timing loops to produce short delays.  The same loop on
the AT runs too fast for the desired effect.  To solve this problem,
use the following routine:

10 X = TIMER + 3.5
20 WHILE TIMER < X
30 WEND

(substituting the number of seconds you want to delay for the 3.5
above). This works on all PC systems and is accurate to about a tenth
of a second.
     Editor's Note:  This solves one of the timing problems on the
supercharged AT; the other is that it's more difficult now to
synchronize music with routines that print characters on the AT's
lightning quick screen.

-----------------------------------------------------------------
                     Foolproof BASIC Delayer
       (PC Magazine Vol 4 No 16 Aug 6, 1985 User-to-User)

     PC Vol 4 No 12 (above) offered a way to create a time-delay loop.
The BASIC manual mentions a trick using the SOUND statement that solves
this problem for all PCs, XTs, ATs and compatibles in both interpretive
and compiled versions.  The demo program below illustrates how this
works.  Using the TIMER function would also do the job, except that
this can't be handled by the BASIC 1.1 compiler, which is long overdue
for some updates.  This program produces a small speaker click which is
annoying, perhaps, but it works on every PC configuration.

100 'DELAYER.BAS
110 INPUT "Enter the number of seconds to delay: ",N
120 TIME$ = "00"
130 SOUND 32767,(N * 18.2):SOUND 32767,1
140 PRINT "The delay lasted exactly ";TIME$

-----------------------------------------------------------------
                  Finding BASIC's Data Segment
         (PC Magazine Vol 4 No 16 Aug 6, 1985 PC Tutor)

     Take a BASIC program that uses about 8K of file space when saved.
The program contains a 27-byte machine language program and is poked
into supposedly reserved space just below the 64K upper boundary of the
BASIC workspace. Additionally, a 16K screen display is BLOADed adjacent
to the machine language, also below the 64K boundary. A CLEAR statement
is used to reserve 17K of high memory for this purpose.
     However, when the display data is loaded, starting at absolute
48128 (segment &HBC0), everything dies.  The program was altered to put
the machine language program and display data just above the 64K
boundary, starting at 65536 (&H1000).  The program then works fine for
about 50 minutes, after which the data and machine language programs
get written over by new data.
     DOS 2.0 is used.  Why can't the machine language routines be just
about 64K?  Why, for an 8K program with DOS and BASIC loaded, can't the
routines be just below the 64K boundary?
     Editor's Response:  You are confusing the space requirements of
BASICA with the absolute addresses in the PC.  There are always other
programs in the PC, such as the operating system, that also take up
address space.  Suppose that the operating system takes up 45K.  The
BASIC interpreter takes up another 27K.  In this case, the 64K BASIC
program area would actually begin at address 72K (45 + 27) and would
continue on through 136K (72 + 64).  What you really need to know,
then, is the actual starting address of the BASIC data segment that
corresponds to the interpreted program and its storage.  The simplest
way to find this is with a PEEK instruction, as follows:

10 DEF SEG = 0      'Look at low memory
20 SEGMENT = PEEK(&H510) + 256 * PEEK(&H511)
30 'Now SEGMENT is the segment address of BASIC's data
40 'area (the program + data).