ticalc.org
Basics Archives Community Services Programming
Hardware Help About Search Your Account
   Home :: Community :: Articles :: Is it Time to Replace TI-BASIC?
Is it Time to Replace TI-BASIC?

Posted on 21 February 2005

The following text was written by George Limpert:

Anyone who remembers coding in TI-BASIC on the TI-81 or TI-85 and has then has coded for a more modern calculator knows the language has made great strides. Many of these changes have been influenced by the collection of nerds and gamers we affectionately refer to as the TI community. When TI created their original graphing calculator models, they never envisioned they would be used for the purposes we have found for them. A large portion of the changes to the language reflect the ideas of students over a decade ago who envisioned their calculators entertaining them during boring lectures. Despite the many changes to TI-BASIC, the language is still looked upon by the best game programmers as inadequate at best.

The complaint of many programmers about TI-BASIC is its speed, or the lack thereof. Unfortunately this issue is unlikely to be addressed anytime soon. When TI designed the language, they envisioned a way of adding new math functionality to the calculator, but with safeguards in place to prevent harmful behavior by programs. Speed of program execution is nice but doesn't appear to have been one of TI's primary objectives when creating the language.

Some people will suggest any serious programming ought to be done in assembly language. Compared with programming in TI-BASIC, it's like going hunting with a rifle instead of a pocket knife; it's faster, more powerful, and there's nothing to stop you from aiming that rifle squarely at your foot. If you make an error programming in TI-BASIC, you get an error message awaiting you to press a key. A mistake programming in assembly might give you a sudden boost of free RAM in exchange for your valued programs, equations, and notes. It's probably best to do serious game programming in assembly, but what about other types of programs?

Not too long ago, a fellow with a fine idea for calculator programming visited the flagship IRC channel for discussing TI calculators. Instead of compiling TI-BASIC programs so they run faster, he proposed replacing the language altogether. While he was met with ridicule, the idea is worthy of further discussion.

Last semester, I took a course on data compression techniques. One project assigned was to implement a Huffman encoder and decoder in C or Java. The discussion in class about Huffman coding went in one ear and out the other. Instead of struggling with C, I decided to implement the project first on my TI-89 because I expected TI-BASIC to be simpler. After about five minutes into coding, however, I hit a roadblock; there's no easy way to implement any sort of trees. Sure, it's possible, but to many programmers it's not obvious how to create or manipulate trees. The solution is to represent each node as a list; the first element is the value and the second and third elements are the names of child nodes within the binary tree. The child nodes are then accessed using a wonderful feature of the language known as indirection. On the TI-83 line of calculators, however, indirection isn't possible, and one would have to use a matrix, instead. Manipulating a matrix is slow and makes the programming involved even more complicated.

A tree is one of the fundamental techniques used in programming. It's applicable to many algorithms including searches and sorts. Unfortunately it can't easily be done within TI-BASIC.

This discussion also addresses another major limitation of TI-BASIC. What if, instead of storing the name of a child node, I want to store another data structure, such as a list, in one of those spots? The answer, of course, is it's not possible. One might ask why anyone would want to do this. Consider, for example, if a programming task involved pushing an integer and a list to a stack. While no such task readily comes to mind, it's a reasonable proposition. Stacks are another fundamental technique of programming. And, of course, complex data structures alone are useful at times.

There are many other such examples of why TI-BASIC is inadequate. Even if it will never be a fast language, simple programming techniques in the language ought to be exactly that -- simple. These limitations make TI-BASIC useless to many applications that are not at all related to gaming.

Programming in assembly can be difficult and dangerous to your data. It also usually requires a computer, a link cable, and a lot of patience. If that's not the best option and TI-BASIC is inadequate, maybe another programming language isn't so absurd of an idea after all.

The obvious question then becomes what features should such a language have. If a language is to truly replace TI-BASIC, it ought to have all the features that TI-BASIC currently has with some additions to fix the limitations with TI-BASIC. It's likely a replacement for TI-BASIC would need to be interpreted instead of compiled. One might assume that if we're creating a new interpreted language that has more features than TI-BASIC that it would be even slower. This is not necessarily the case.

The architecture of compilers and interpreters are very similar. The first step in either is referred to as a lexical scanner. This scans through the program text for keywords and symbols. The output generated is a series of tokens which represent the text of the original program. TI-BASIC does this as well; on some calculators, programs are always represented as tokens, but on others you will notice a delay when running a program for the first time due to this conversion. The next step of a compiler or interpreter is a parser. This deals with the syntax of the language, converting the string of tokens to a tree structure. A tree in an accurate representation of how a language is actually evaluated. Following this step is semantic analysis. A statement in a language may be syntactically correct but still make no sense to the compiler or interpreter. At this step, actions such as checking type and scope of variables are performed. At this point, compilers and interpreters diverge. An interpreter will evaluate the parse tree and execute the statements while a compiler will output another language such as assembly language or machine code.

This discussion on the architecture of interpreters is relevant because the implementation of TI-BASIC is not necessarily the most efficient scheme. Most likely, TI-BASIC stores programs merely as a stream of tokens because of the space required to store a representation of a parse tree. A parse tree, however, can be converted back to plain text just as the stream of tokens can. If parsing is only done once instead of being done constantly during execution, greater speed can be realized. One need not stop after parsing, however. Much of the semantic analysis step can also be performed at this time without modifying the parse tree. One may view this as a trade-off between program size and execution speed, but it need not be the case. A parse tree, when outputted to a file, can be compressed and then uncompressed at runtime, which may gain back some or all of the space lost to representing the program as a parse tree.

Another major change to such a new language is in the area of variables. There is no method within TI-BASIC to store a reference to another variable. Therefore any reference variables will necessarily be local to the interpreted program. Such a language, however, would still need to provide easy access to variables from TI-BASIC. This means that any variables that are to use the additional features of this language will need to be declared within the program. If this is the case, it allows for a few other enhancements to the language. One potential enhancement is the concept of aggregate data types.

Dealing with variables is a major slow point of TI-BASIC. The language on some calculators provides two very useful features for programmers -- dynamic types and dynamic resizing of variables. Dynamic types mean that if I have an variable currently storing an integer and I choose to store a string it it, the variable becomes a string variable. Dynamic resizing of variables means that the space used to store a variable is automatically expanded or contracted depending on how much space is needed to store the data. While these are very useful enhancements, they are also slow. A new language could make these features optional to programmers, providing an additional speed boost.

In spite of these and other possible enhancements, some tasks are better suited for assembly language. Furthermore, programmers shouldn't have to reinvent the wheel every time they write a program. PHP had a good idea when it allowed modules to be added to the interpreter that extend the functionality of the language. While a new calculator language may be at the core a replacement for TI-BASIC, the ability to extend the language through modules instead of writing a new interpreter makes the language far more powerful than it would be otherwise.

TI-BASIC is a fine language suitable for many tasks. Assembly has many advantages over TI-BASIC and has many uses as well. There are, however, many programming tasks that for one reason are another are not suited well to either language. A replacement for TI-BASIC, if sufficiently enhanced, can make TI calculators a far more powerful tool. The question of a new programming language shouldn't be a question of if but of how and what.

  Reply to this item

[OT] Board problems?
Travis Evans  Account Info

Is it just me, or is anyone getting an error similar to the following every time they post to this article?

Error: No article to respond to is specified!

My posts still go through, though.

Reply to this comment    21 February 2005, 23:20 GMT

Re: [OT] Board problems?
Coolv  Account Info
(Web Page)

Just you...

Reply to this comment    22 February 2005, 02:20 GMT


Re: [OT] Board problems?
Coolv  Account Info
(Web Page)

WAIT A MINUTE!!!

IF you post and wait, it DOES do that!

Reply to this comment    22 February 2005, 02:21 GMT

Yes and No
Jason Malinowski  Account Info

Replaced? No. Augmented? Yes.

Say it with me: "there is no perfect language."

Of course TI-BASIC isn't perfect. No language is. You may say "C is perfect," but tell that to the user that doesn't have a linkcable. You may say "assembly is perfect," but many people (even some coming from other languages) can't think in assembly language.

TI-BASIC has one advantage: it's really easy to learn. It wasn't designed to be powerful, and it wasn't designed to be fast, but it does a really good job at being easy to use--this is precisely what TI wanted the language to do. They did a good job at that. I'm sure that writing sidescrolling greyscale games that run at 30 fps wasn't in the TI programmer's mind when they wrote the first TI-BASIC parser.

Also, right now TI can't remove TI-BASIC due to backwards compatability. I'm sure the primary reason that most of us have calculators is because they were prescribed for a math class. Many teachers will instruct their students how to do certain tasks with TI-BASIC (recursive functions comes to mind). If suddenly TI-BASIC was changed to something completly different, many teachers would be confused, and would consequently not recommend the calculator (which would hurt TI's bottom line.)

That said, yes, TI-BASIC can use many, many improvements, and George did outline some key ones. I would use a substitute if one showed up (although I don't use BASIC much in the first place.) I think Lewk Of Serthic is right in his post above: TI isn't going to step forward...it'll have to be one of us.

Reply to this comment    22 February 2005, 00:22 GMT


Re: Yes and No
anykey  Account Info
(Web Page)

The new language probably wouldn't be built into the OS, but would instead be a shell (like MirageOS).
You could implement an on calc editor with debugging tools, and maybe even an interactive interpreter (like Python).

Reply to this comment    22 February 2005, 02:32 GMT

Re: Is it Time to Replace TI-BASIC?
tim qiao  Account Info

I have had the same thought for a while. Basic needs to be replaced. I'M SERIOUS!!!!!! :()

Reply to this comment    22 February 2005, 00:51 GMT


Re: Re: Is it Time to Replace TI-BASIC?
shorty174 Account Info

Here's what I think. I am currently taking a Java class and I say, either get Java on the calcs or a similir OOP language. And from what I've seen, Java can eliminate all the problems mentioned with TI-BASIC.

Reply to this comment    22 February 2005, 02:58 GMT

[ ! ]
anykey  Account Info
(Web Page)

Most real languages can.
EOL

Reply to this comment    23 February 2005, 03:59 GMT


Re: [ ! ]
ti_is_good_++  Account Info

BASIC isn't real?

Reply to this comment    24 February 2005, 00:14 GMT


[ ! ]
anykey  Account Info
(Web Page)

...there is no spoon...
I mean computer languages.
EOL

Reply to this comment    24 February 2005, 03:52 GMT


Re: [ ! ]
ti_is_good_++  Account Info

TI-BASIC is a computer language.
A TI graphing calculator is a computer. It's a relatively low-powered computer by today's standards, but it's still a computer. TI-BASIC can be used to program a TI graphing calculator. The only thing preventing it from being run on a PC-or any other platform-is the lack of a PC interpreter/compiler. Thus, TI-BASIC is a computer language.
A Voyage 200 outperforms an average 1996 PC in almost every category but screen size.
A TI-82 could fly a manned spacecraft to the Moon by itself. That's not trivial.

Reply to this comment    24 February 2005, 04:43 GMT

Re: Re: [ ! ]
Kevin Kofler Account Info
(Web Page)

That's about 10-15 years off. A 1996 PC has a CPU somewhere in the 100-200 MHz range, RAM in the 8-64 MB range and a HD in the 1-4 GB range. This is a lot more CPU speed and memory than the Voyage 200.

Reply to this comment    25 February 2005, 21:50 GMT


Re: Re: Re: [ ! ]
ti_is_good_++  Account Info

As I see that the last comment wasn't posted, I'll repeat:

My comparison to 1996 was based purely on memory of the computers from around that time. However, you'd be hard-pressed to find a market computer from 1981-1986 with a TI graphing calculator's specs. I had a computer from that period and it was about half as powerful as a TI-89.

Reply to this comment    26 February 2005, 02:34 GMT


[ ! ]
anykey  Account Info
(Web Page)

You know what I mean.
A PC!
But wait! Calcs are personal, AND computors!

Reply to this comment    26 February 2005, 02:04 GMT


Re: [ ! ]
ti_is_good_++  Account Info

TI-BASIC could be run on PC if there was an interpreter for it.

Reply to this comment    26 February 2005, 02:35 GMT


Re: Re: [ ! ]
ti_is_good_++  Account Info

Programs made with it, that is.

Reply to this comment    26 February 2005, 02:36 GMT


Re: Re: Re: Is it Time to Replace TI-BASIC?
burntfuse  Account Info
(Web Page)

I think this has been discussed on other message boards here...Java is too large, slow, and bloated to run on a calc. It's fine on a PC with all the processing power and memory, but nowhere else...

Reply to this comment    26 February 2005, 02:17 GMT

Re: Is it Time to Replace TI-BASIC?
nyall Account Info
(Web Page)

Ultimately you are going to get more bang for the buck by writing high powered asm routines for tibasic to call.

On the 89 I've used VTI to trace into some very important rom routines. Searching for variables has a lot of room for improvement. Searching through a decent sized table could be at least 8x faster just by optimizing the linear search the AMS already does, and much faster if changed to a binary search. Unfortunealy there are a lot of small variable tables where the local vars are kept so a binary will often not be the optimal solution.

Also the 89s tibasic tokenized code does not store offsets to instantly skip over code that an if-statement decides not to execute. The 89 will process through unexecuted code till it finds the token for the 'Endif'. This process routine is also used in other places, like processing through a list to access elements. I've released a demo that shows how this routine can be much faster.

p.s. a question for a ti86 asm coder: The ti86 has 8k (?) of ram for asm program execution set aside. How volatile is this ram? Suppose a 1k ti86 asm program would fill the last 6k of this 8k buffer with binary data (say provided by a string where that data was provided as ascii text) in this way a tileset could be initialized then used by other asm programs (to do displaying) that are small enough that they would not overwrite the tileset data.

Reply to this comment    22 February 2005, 04:06 GMT


Re: Re: Is it Time to Replace TI-BASIC?
burntfuse  Account Info
(Web Page)

That would work...but most decent-sized programs aren't 1 KB or under. However, I've found from experience that you can stuff as much as 9200 bytes into the program area without overwriting the hardware stack or anything.

Reply to this comment    26 February 2005, 02:20 GMT


reply to thy
nyall Account Info
(Web Page)

To be more clear the idea is that a master basic program (a game) will only call small assembly programs. The first small program will load the remaining ram with sprite/tile data at initiation, then other small programs can be called to display the sprites/tiles.

Reply to this comment    27 February 2005, 02:53 GMT

no need to replace it, just to fix it up
Joe Somebody  Account Info

imho, TI-Basic (for the 68k calcs) is the ultimate programming language. Very little, if any, extra coding needs to be added. However, there are two features I would like to see soon:

TI-COMPUTER BASIC: not something like VB6: rather, a language designed to run on a computer modled after the TI-Basic language. It would be identical to the 68k calculator language, would include AMS, advanced picture commands, etc, but would have a few improvements for dealing with high-resolution color monitors, the computer's slightly different layout and keycodes, and mabye even HID joysticks.

A compiler: this is absolutely critical if the language is to land on the moon, as it deserves to. It's certain that with far less effort than it took to make TI-GCC a compiler could be developed, and the result would be a language both simpler and more powerful than C - ESPECIALLY for writing games (the advanced picture commands are really useful for that)
of course, the compiler can afford to use ROM calls for the AMS, since AMS is too complicated to duplicate, and is not going to work much faster if their commands are compiled (that would just make compiled basic programs far too large to be useful)

Reply to this comment    22 February 2005, 04:55 GMT


Re: no need to replace it, just to fix it up
Kevin Kofler Account Info
(Web Page)

The result would also be cr*ppy code. GCC is that complex for a reason.

Reply to this comment    22 February 2005, 22:14 GMT


Re: Re: no need to replace it, just to fix it up
mstrmnd34 Account Info

cr*ppy? i dont think so.
imho, TI-Basic is the ultimate language for anything, it just needs more speed.

Reply to this comment    23 February 2005, 18:18 GMT


Re: Re: Re: no need to replace it, just to fix it up
Kevin Kofler Account Info
(Web Page)

I wasn't even talking about the language to be compiled (even though TI-BASIC is actually not at all a language adapted for compilation, you'd need to drop/change a lot of things, such as dynamic typing or symbolic manipulation, to get efficiency anywhere near TIGCC, and then it wouldn't be TI-BASIC anymore!), but about the arrogant "with far less effort than it took to make TI-GCC" affirmation. Some naive people seem to think good compilers are trivial to write, this is actually very far from the truth.

Reply to this comment    25 February 2005, 21:55 GMT


Re: Re: Re: Re: no need to replace it, just to fix it up
ti_is_good_++  Account Info

Everybody thinks a job is easy until they have to do it, don't they?

Reply to this comment    26 February 2005, 00:45 GMT

1  2  3  4  5  6  7  

You can change the number of comments per page in Account Preferences.

  Copyright © 1996-2012, the ticalc.org project. All rights reserved. | Contact Us | Disclaimer