------- NBASIC.EXE -------
This programme is a copy of GWBASIC.EXE with several patches:
(0) The cassette routines have been disabled to allow the space to be
used for other patches.
(1) The INPUT statement has been patched so that brackets and parentheses
are interchangable as subscript list delimiters just as in most other
statements. (The use of "[]" for subscripts was an undocumented
feature that wasn't properly implemented for all statements -- INPUT
and CHAIN still only allowed parentheses.)
(1A) The CHAIN statement has also been patched to check for both
parentheses and brackets in COMMON statements. You may now also use:
COMMON A, B, X[], Y[], Z$[]
as an optional variation of
COMMON A, B, X(), Y(), Z$()
and CHAIN will now handle it as you would wish it to do.
(2) By changing the call for evaluation of a string literal into a call to
the expression evaluation routine, the INPUT statement has been made
to accept any string expression as a prompt, subject to the condition
that it MUST begin with a string literal (which may be an empty string)
and it must not exceed the normal string limit of 255 characters.
You may now legally use
10 INPUT "Please type your name ---> " + chr$(34) +
"____________" + chr$(34) + string$(13,29) + chr$(7), USER$
20 INPUT "Well, " + USER$ + "," + chr$(13) +
"How do you like computers"; ANS$
30 PRINT "Hmmm! Verrrry interesting!"
..
..
etc.
(3) By swapping the positions of the two words, MOTOR and MERGE in
the keyword table, it is now possible to press <Alt>-<M> and get
"MERGE" instead of "MOTOR". A much more useful situation in my
opinion.
(4) The default extension for SAVE and LOAD has been changed from "BAS"
to "NBS" to prevent erroneous mixing of programmes with "NBASIC
extensions" with "Standard" BASIC programmes. A programme that runs
correctly with "NBASIC" will probably need changes if any of the "new"
features of NBASIC are used. The different default extension will
allow you to better keep track of which programmes need changes to be
"portable" to GW-BASIC. The default extension can still be
overridden if necessary. A file saved with
SAVE "MYPROG"
will be saved as MYPROG.BAS with GW-BASIC and as MYPROG.NBS with
NBASIC. A file saved with
SAVE "MYPROG.BAS"
or with
SAVE "MYPROG.NBS"
or with
SAVE "MYPROG.XYZ"
will be saved the same way with both BASICS. The command,
LOAD "MYPROG"
will look for the file MYPROG.BAS with GW-BASIC and for MYPROG.NBS
with NBASIC. The commands,
LOAD "MYPROG.BAS"
and
LOAD "MYPROG.NBS"
and
LOAD "MYPROG.XYZ"
will work the same with both BASICs.
(5) LCOPY did NOTHING except a syntax check on what followed to conform
to the syntax of the LCOPY statement that IS implemented on other
versions of GW-BASIC. The syntax is:
LCOPY
or LCOPY byte_expression
(ie. LCOPY [ byte_expression ] )
where byte_expression is a numeric expression in the range of 0 - 255.
In NBASIC.EXE, I have changed the CALL to a routine to do NOTHING into
a "NOP" instruction, followed by an "INT 05" instruction that invokes
the system-defined screen-dump routine. NOW, LCOPY will perform a
screen-dump as in other versions of GW-BASIC.
A screen dump may now be done under programme control with the
statement:
LCOPY
(A byte argument may follow but the value is ignored except for
verifying that it is in the range 0 to 255.)
(6) The default and initial colour settings and palette settings have been
changed so that:
(a) the initial screen attribute is bright white on blue instead
of dull white on black (and the initial colour for the
function keys is now green on red instead of dull white on
black),
(b) and the initial palette settings and the settings (re)set on exit
are now the same as the settings that you have at the initial
DOS prompt (the colours used for other programmes will be
changed if you run GW-BASIC and exit from it but that is no
longer the case with NBASIC.)
(7) The SYSTEM statement has been modified. The OLD syntax was
SYSTEM
with NO arguments allowed. THAT SYNTAX IS STILL VALID and does the
same as it used to, exiting from BASIC with an ERRORLEVEL of zero.
An optional argument is now allowed so A NEW ALTERNATE SYNTAX is
SYSTEM return_code
where "return_code" is a numeric expression with a value from zero
to two hundred fifty-five ( 0 to 255 ). The return_code is passed
back to COMMAND.COM when BASIC exits and can be tested with the
ERRORLEVEL function in a batch file. A BASIC programme that is run
by a batch file can cause the batch file to branch to take into
consideration some condition that was tested for or discovered by
the BASIC programme.
(8) String literals may now contain a quotation mark by using it twice
where you want a single quote. The statement:
PRINT "Press ""A"", ""B"", or ""C"" for selection... -->"
will print:
Press "A", "B", or "C" for selection... -->
The statement
Q$ = CHR$(34)
may now be written as
Q$ = """"
instead.
(9) GW-BASIC could incorrectly tokenize the keywords GOTO and GOSUB in
some circumstances. The tokenizer was written to allow optional
spaces after the "GO" part of the keyword. The routines that parse
the statement to look for "GO", "TO", and "SUB" were faulty and
attempted corrections by the original programmers made things even
worse. WITH NBASIC, THE BUG IS FIXED.
(10) Comments may now be included in the middle of programme lines by
enclosing them in braces, "{}", where-ever insignificant spaces are
allowed, except for one restriction that I have found:
-- Remarks embedded in a number are deleted. Something else must
precede the remark for the remark to remain. (The same thing
happens to spaces.)
10 {please} print x {times} * 3 {hundred} 5 6 {miles}
becomes
10 {please} PRINT X {times} * 356 {miles}
Remarks MAY be included in a BASIC source programme embedded in
numeric constants IF the source programme is producedand edited by
a word processor capable of producing an ordinary ASCII text file.
Note, this applies to decimal and octal constants only, NOT
hexadecimal constants. Embedded remarks or spaces are not allowed
in hexadecimal constants.
Braces within quotes are not treated as remarks, but as literals, and
quotes within braces do not begin literals.
50 PRINT "{xxx}"
WILL print
{xxx}
and the quote in the remark
60 Q$ = { a quote (") } CHR$(34)
will act the same as
60 Q$ = CHR$(34)
I haven't tested the in-line remarks with DATA and READ statements
but from the way DATA and READ handle strings, I suspect that it would
be safer to avoid the use of remarks in DATA statements. You can have
80 ON RESPONSE {to menu selection}
GOTO 100 {debit}, 200 {credit},
300 {adjustment, we goofed},
400 {adjustment, customer goofed},
{or} 500 {quit while we're ahead}
(11) The keyword "MID$" was not treated in a consistant manner. When used
as a function, spaces were allowed between the keyword and its list
of parameters. When used as a command for assignment to a substring
of another string, spaces were NOT allowed.
A$ = MID$(B$,C,D) 'Legal
A$ = MID$ (B$,C,D) 'Legal
A$ = MID$ (B$,C,D) 'Legal
MID$(B$,C,D) = A$ 'Legal
MID$ (B$,C,D) = A$ 'ILLEGAL
MID$ (B$,C,D) = A$ 'ILLEGAL
The MID$ COMMAND has now been patched so that ALL of the above are
legal. (Subject to valid arguments of course.)