------- 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 - 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.)