Difference between revisions of "Extended BASIC"
Stephen Shaw (talk | contribs) (→Programming Hints: new heading- how to validate a number input including blank) |
Stephen Shaw (talk | contribs) (→Built in: add reference to new article on User Writte sub programs) |
||
Line 117: | Line 117: | ||
CALL LOAD requires expansion memory and allows you to place values directly into CPU ram. These can be used for a variety of purposes, see the samples in [[Speech]] and [[Sound with CALL LOAD]]. | CALL LOAD requires expansion memory and allows you to place values directly into CPU ram. These can be used for a variety of purposes, see the samples in [[Speech]] and [[Sound with CALL LOAD]]. | ||
Also see [[Programming#Useful CALL LOADs|Programming article]] | Also see [[Programming#Useful CALL LOADs|Programming article]] and some examples of user written subprograms in Extended BASIC in [[CALL subprograms]] | ||
====Your own sub programs==== | ====Your own sub programs==== |
Revision as of 21:00, 27 October 2014
First TI produced TI BASIC, built into the console. Then came the first attempt at an Extended BASIC, in module format, which returned the value of 100 with CALL VERSION(A). This first version is quite rare and suffered several problems.
Very quickly a rewrite was issued. The second version was still called TI Extended BASIC but this time when you used CALL VERsion(A) it returned a value of 110. It was faster. (Mostly because it was no longer trying to keep track of graphic sprites that you weren't using).
Subsequent versions of Extended Basic from third parties added more powerful versions of commands or new commands- some example versions are:
Triton Super Extended BASIC (Returned 120 with CALL VERSION(A) )
General Notes
This page links to some notes on using Extended Basic generically and where possible each comment will address the variations.
Program Line content
PROGRAM LINES: May now contain more than one command, and can be entered up to 5 screen lines long (but limited to 128 bytes long internally).
You may use IN COMMAND MODE for instance: FOR A=110 to 220 :: CALL SOUND(200,A,0) :: NEXT A
The double colon is a statement separator. In TI Basic you could enter PRINT A::B::C.
In Extended Basic you must leave a space between the colons: PRINT A: :B: :C
(A program in TI Basic is converted automatically by the machine to the new format, but you must take care when typing in a program. Due to an omission in the error handling system, typing too many colons together in Extended Basic can cause the processor to 'lock out')
When this is linked to the new capabilities of the IF...THEN command, it is possible to put together some very powerful program lines:
IF A=B THEN C=5 :: PRINT A :: ELSE IF A=8 AND B=C THEN GOTO 3400 ELSE CALL SOUND(100,110,0) :: GOTO 200
As the lines become longer and more complex, you do need to take greater care, but the language gives you a very powerful tool.
In addition to using REM after double colons, you may use a 'tail remark', which is a '!' as follows:
140 SCORE=0 ! RESET SCORE
Memory Usage
EXTENDED BASIC uses some of the system RAM, and you do not have quite as much memory available for your programs. In addition, the cassette loader cannot handle programs over 12k.
The good news is that with Extended Basic you may access the memory expansion unit, which permits you to load (from DISK) a program up to 24k, and still have some 14k available for variables and so on.
REDO key
The new function key REDO will repeat your last entry, and if the last entry was a program line (either just entered, or recalled using FCTN X) the line reappears on the screen with the cursor at the beginning of the line NUMBER, allowing you to change the line number if you wish. This function is useful if your program contains a lot of lines either the same or with only small differences.
Alpha Lock
A program using the joysticks requires the alpha lock is UP, a relic of the TI99/4 days.
If your program requires the alpha lock to be DOWN for input etc you can instruct the console it is down:
Insert a dummy line CALL KEY(3, Z, Z)
The use of key unit 3 tells the computer to treat the alpha lock as if it were down whilst the program is running, unless we reset. Use of key unit 0 has no effect on alpha lock status. Key unit 5 will reset normal operation.
Using Sprites with different consoles
Sprite speed depends to some degree to the VDP speed, and PAL and NTSC consoles differ significantly. This can cause problems especially in Extended Basic games where sprite auto-motion is used, as the speeds will vary.
Here is a little Extended BASIC test program (could be useful when setting up emulators?):
100 CALL SPRITE(#1,32,1,100,1,0,60) :: FOR C=1 T0 71 :: NEXT C :: CALL POSIT ION(#1,C,C) :: CALL DELSPRITE(#1) :: PRINT C :: GOTO 100
Now, when you run this tiny ExBas program, a string of numbers will scroll up the screen. They will fall between two values, with a difference of 5 or 6 between the upper and lower limits.
On my consoles the range is 53 to 59. However, on USA consoles, operating at differing speeds, the sprite can travel farther, and on 26 USA consoles, the value range ie 64 to 69.
For a number of American written Extended Basic games I had to amend sprite speeds to prevent the sprites moving too far.
Expansion Memory Test
"Is the 32K expansion connected?" (in Extended Basic programs) - there is no need to trouble the user with this, the computer can answer this question itself:
CALL PEEK(-45, A, B, C) IF A+ B+ C> 0 THEN (the 32K RAM is attached!)
Machine code programs
An added attraction of the module is that it permits you to load and run Assembly language programs, provided you have the extra peripherals required.
Example: In the USA, TI release TI INVADERS on disk for half the price of the module. You require a disk system and the 32k memory expansion.
Console Crashes
If you use CALL PEEK at some locations the console will cease to respond.
Users have encountered more system lock outs due to dirty module contacts with Extended Basic as it uses more of them than most modules.
Sound and Sprites Pausing
From time to time you may notice your sprites freeze for a moment or a musical note sound just a little longer than it should. This is due to the computer having a clearout of redundant variables, making room for more. In Extended Basic you can take charge of this fairly random behaviour. Refer to the article Garbage collection.
Extended BASIC commands
ACCEPT AT, DISPLAY AT
IF THEN ELSE
LET
LINPUT
LIST
ON BREAK NEXT
ON ERROR
RUN
SAVE
Speech
See article Speech
SIZE
SUB PROGRAMS
Built in
CALL LOAD requires expansion memory and allows you to place values directly into CPU ram. These can be used for a variety of purposes, see the samples in Speech and Sound with CALL LOAD.
Also see Programming article and some examples of user written subprograms in Extended BASIC in CALL subprograms
Your own sub programs
As well as the built in CALLs Extended BASIC allows you to create your own sub programs.
If in a program the colours of character sets 1 to 8 are regularly changed.
It could be done with a subroutine, setting variables and then using GO SUB:
200 X=2 210 Y=4 220 GOSUB 8OO 230 GOTO 230 800 FOR T=1 TO 8 810 CALL COLOR(T,X,Y) 820 NEXT T 830 RETURN
In Extended Basic we can create a sub program called COLOUR (NOTE: English spelling! now you can call color or colour, one is built in, one you have written... ) .
Sub programs MUST appear at the end of your program. Only other sub programs can follow them.
Example:
200 CALL COLOUR(2,4) 210 GOTO 210 2000 SUB COLOUR(X,Y) :: FOR T=1 TO 8 :: CALL COLOR(X,Y) :: NEXT T :: SUBEND
Thats it!
In this example of a sub program, we have passed two VALUES to the sub program, which are taken by the local variables X and Y in the subprogram.
IMPORTANT: If X and Y are used in your main program, or indeed in other sub programs, their values are NOT changed by their use here! This X and Y are unique to this sub program.
If instead of numbers. we use variables CALL COLOUR(A,B), then in this form, the values of A and B may be changed in the sub program.
Further example:
10 CALL EXAMPLE(A,B) 11 PRINT A,B 12 GOTO 12 20 SUB EXAMPLE(X.Y) :: X=2*X :: PRINT X :: SUBEND
In this format, if A=2 and B=4 when the CALL is executed, the values of A and B are passed to X and Y in the sub program. At the end of the sub program, the values of X and Y are passed BACK to A and B, thus the sub program has changed variables in the main program.
If you do not want this to happen, it doesn't have to. You can pass variables with their values protected by using extra brackets:
CALL EXAMPLE((A))(B))
The same SUB will take its values from A and B, but at the end of the sub program, A and B will retain their original values: they will not be changed bv the sub program. Just place the variables in the CALL in brackets.
Programming Hints
Using CALL LOAD in Extended Basic
Refer to Programming article.
Convert decimal to binary number
This little routine will work for any 16 bit digital number - nothing over 65,536. Decimal 5 is binary 1100 - now quickly what is the binary form of 365? Try this:
100 INPUT D :: D=D/16^4 :: FOR X=0 T0 15 :: D=2*(D-INT(D)) :: PRINT (D>=1) :: NEXT X
Pre-scan control
Pre-scan is used to allocate memory before the BASIC program starts. It causes a notable pause before the first statement executes, because the pre-scan process scans the whole program for variables and subprograms. Extended Basic allows for a quicker start-up by turning pre-scan off and on; these lines are specific comment lines.
100 GOTO 150 110 A=0 :: B$="" 120 DATA 1 150 !@P-
turns off pre-scan after line 150
200 !@P+
turns it on after line 200. Pre-scan is enabled by default.
Pre-scan must be active for the following program parts:
- The first DATA statement
- The first use of a variable or an array
- OPTION BASE (if used)
- Reference to each subprogram called in the program
- DEFs
- SUB and SUBEND
Variables introduced in the SUB statement (formal arguments) are locally valid, so they must be included. CALLs in the pre-scan need not list actual arguments. You do not need to build correct assignments to variables either. However, the lines must not be executed, or an error will occur.
100 GOTO 150 110 CALL SCREEN :: CALL MYOWNSUB :: CALL CLEAR :: A,B,C=D :: E :: NAME$ :: !@P- 120 DATA 10 150 CALL CLEAR 160 REM REST OF PROGRAM
Because pre scan uses "dead code" that you can place after a GOTO it is acceptable and demonstrated in the TI Extended Basic Addendum to use the following format:
10 DATA 3 20 GOTO 100 :: DELAY :: CALL CHAR :: CALL CLEAR :: CALL HCHAR :: CALL VCHAR :: !@p- 100 CALL CLEAR
(where DELAY is a variable)
DATA statements at the top or the end?
Where does DATA belong?
The answer is not so simple. It depends on whether or not your program uses RESTORE.
With DATA at the start of your program, RESTORE is faster but READ is slower, while conversely if your DATA is at the end of your program, RESTORE slows down a lot but READ is much faster. NB: this MAY differ on consoles with differing operating systems.
On average, how many RESTORES do you process, and how many READs?
If the number of RESTOREs TIMES FIVE exceeds the number of READs, place your data at the beginning. If the number of reads is more than five tines the number of RESTOREs, place the data at the end. The difference in the timing of RESTORE in a 10k progran is unbeleivable!
Catching errors on numeric entry
If someone just presses ENTER when they should input a number, it can be disruptive.
Using ACCEPT AT for a numeric variable, you can insert a default input value, and use a negative size, and also use VALIDATE.
However, the user CAN blank the default variable with CLEAR, and if the input variable is a numeric variable, trying to input a blank will cause an error condition.
Using ON WARNING NEXT will test for the nul input and go back for you. Try it.
eg 100 ON WARNING NEXT 110 ACCEPT AT(4,5)ERASE ALL VALIDATE(DIGIT):A 120 GOTO 110
Right Adjust displayed numbers
To right adjust money or other decimal numbers so that numeric input of 4 or 4.5 or 4.26 neatly line up:
DISPLAY AT(R,C):USING "####.##":VALUE
Using this command, any positive number up to 9999.99 with no decimal places, or one or two decimal places, will display correctly lined up and showing two decimal places.
On Error (not a bug) workround
100 ON ERROR 600 110 RUN "DSK1.NOFILE" 600 ON ERROR 600 :: RETURN
the RETURN will fail as the failed RUN seems to remove the internal pointers.
This is a deliberate ploy by TI to avoid the "accidental" removal of the List Protection flag- which happens with Version 100 of ExBas.
You need to use the format RETURN XXXX where XXXX is a line number to go to which will RUN your original program again- you could use RUN 100 or something if required. The second RUN will of course reset all required pointers.
eg
100 ON ERROR 600 110 RUN "DSK1.NOFILE" 120 GOTO 120 550 RUN 100 600 ON ERROR 600 :: RETURN 550
Exchanging Variable Values
Nice bit of code here for you to look at. Let's suppose we have CAT=6 and DOG=9, how do we change those around?
We could set up a, temporary variable like this:
10 CAT=6 :: DOG=9 20 PET=CAT :: CAT=DOG :: DOG=PET 30 PRINT CAT;DOG
But we can save a little variable storage space and produce more interesting code like this...
10 CAT=6 :: DOG=9 20 CAT=CAT+DOG :: DOG=CAT-DOG :: CAT=CAT-DOG 30 PRINT CAT;DOG
Try it- it works! And saving variable names is of great value if you are programming for THE MISSING LINK, which only has limited VDP space for variable storage.
Purely in the interests of science, ExBas programmers can tackle this another way, but it is slower:
10 CAT=6 :: DOG=9 20 CAT=CAT XOR DOG :: DOG=CAT XOR DOG :: CAT=CAT XOR DOG 30 PRINT CAT:DOG