Difference between revisions of "Extended BASIC"

From Ninerpedia
Jump to navigation Jump to search
(→‎Programming Hints: new heading- how to validate a number input including blank)
(→‎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:

Myarc Extended BASIC II

Triton Super Extended BASIC (Returned 120 with CALL VERSION(A) )

Extended BASIC III


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