I think that this is a good idea except for one thing, Everyone that knows TI-BASIC would have to re-learn everything they know. In my opinion we should keep the language but TI should add more commands and spped it up slightly. I think that if someone made an TI-BASIC to assembly compiler that runs on the calc that would compile a TI-BASIC file to an assembly file most of the speed problems would be solved. I would work on this but I am just learning asm now.

That would definitally work, although it would take a large amount of time and resources, but it is definitally possible. Also, TI could do work behind the scenes of the TI-BASIC interpreter, and speed it up by optimizing the interpreter to assembler more, but still keeping the same commands (and therefore speeding up the programs). I am not sure if TI will be willing to do that though, as their main focus in is on classroom applications of the calculator, not necessarily the geeks who try to push the calc to the limits (althought they often get many pointers from these geeks, too.)

There is a computer program for turning basic to assembly. I don't remember if it is for Mac or PC, but I'm assuming it's for PC. Check it out in the file archives

I tried it, but couldn't get it to work...

I know that there is one for the computer. I mean one for the calc so you wouldn't have to waste your time moving the program to the computer and back again.

BTW I can't seem to make the program work anyway

I cant get that basic to assembly program to work either, if any one has gotten it to work, tell me how plz.

I a redone Ti-Basic would be best, use same commands and structures but add more functionality, like more commands, more data types, more speed etc. I think a good option would be that ti should make their own basic to assembly program for the computer (one that works) that would compile basic programs for max speed, but have the ease of programing as basic. That or someone make a program of their own if ti doesnt have the time.

I have tried for a couple of years to learn assembly and C but i havent found a good enuff tutoral on it to learn anything more that "Hello World". The hard part for me isnt the writing of the programs but the compiling of them. That and all the tutorals expect you to know the termonlogy already so half the the things they say you dont understand. If any one has a good tutoral on either launguage that is well completed and in ENGLISH, plz post(a link to) it.

You surely haven't looked at the z80 docs directory in the archives of this very site, have you? 28 days is all you need.

The speed (or slowness) of Basic is not the primary concern at the moment. I know that's what we've been calling for years, but now George Limpert mentioned a way more interesting point.
Even though it's always been widely known there are a lot of things Basic can't do (graphics, memory management, ...), I don't think people have often realized you can't properly create a tree in Basic, or define your own data types for example. For instance, I've personally always known which data types I could use, but I can't remember consiously being aware of the limitation of not being able to create a simple record (Pascal) or struct (C). Working around these limitations quickly became a second nature, and I never even consiously saw them.
The way I see it, the inherent limitations of Basic, and whether they are so severe they warrant the development of another language, should be the central point of this discussion. Speed is quite irrelavant, there will always be enough tricks to get extra speed.

You can create a tree in 89 or 92+ BASIC, if you're clever.

On those calculators, you can encode a list or a matrix to a string using the string() function. Then you can store the string in another list or matrix.

Then you can extract the string and convert it back into its original list or matrix using the expr() function.

I fairly recently discovered this trick and it's been very helpful in complex programs. You can even store lists or matrices several layers deep. But it's a little inconvenient because you have to keep using string() or expr() to convert the embeeded lists or matrices. And if you want to modify an embeeded list or matrix, you have to first extract it, store it to a temporary variable, change it, and then convert it back to a string. But it works.

There is an easier way.

1) Extract an element from a list or matrix.
2) Use GetType to check if it is a string or number.
If it is a number then you are done.
It it is a string, then the string is a name of another list/matrix. You can use indirection (# operator) on the string to access this list.

That would work, except you'd lose the convenience of storing an entire tree in one file, and you'd have to come up with unique names for all the lists/matrices so they wouldn't conflict with existing ones.

I made a program ("GPShell") that made a tree using a different method: each item was stored as a row in a matrix, and it had "pointers" to the rows of its parent and child items in the same matrix (each time an item was added, the row was appended to the end of the matrix and the pointers were written accordingly). I could easily have the program crawl down an entire branch of a tree (e.g., for copying or moving it to somewhere else in the structure) by using a recursive subroutine.

Except that just having it stored as an ASM file doesn't necessarily make it faster... it'd have to include osme kind of optimizing routine so that extraneous ASM was removed before saving the file as an ASM one...

BASIC as it is has to be converted to machine code to run anyway, but afaik it is all curently done at run-time as it comes across each BASIC instruction.

Does anyone know if Python would be a feasible language for a TI calc? IIRC, you can extend the language with modules written in other languages, like C or ASM. It's also pretty easy to learn, and quite powerful.

I think Ti Basic should work more like Python; you can have modules and dynamic variables.
Here's an example of how Python does modules:

I've got a program called example.py that contains an object that I'd like to use in my main program, main.py
example.py:
def say(text):
(tab)print text

main.py:
import example
say("Hello World!")

See? That was easy. You can also import specific functions without having to import the whole thing.

You can define local functions in TI-BASIC.

Define func(x,y)=Func
[code]
EndFunc

Yes, but not on the z80 calcs (no, I'm not going to buy an 89!).
EOL

Yeah, that's something that has bugged me about the BASIC programming of the z80 series. It can make them really inefficient. A better structured language would probably also cut down on size because of things like this.

I agree, BASIC for the 68k calcs doesn't seem bad, with support for functions and different var scopes and things like that, but it's BASIC for the z80 calcs that REALLY can't do much (without a lot of effort on the part of the programmer), as if TI just put it in as a last-minute thought or something.

I was impressed at the improvement of 89 and 92+ BASIC, but I still have a lot of gripes. Here are some off the top of my head (there may be others that I forgot about):

1. Subroutines are still a pain if you don't want them stored in separate files cluttering everything up. You could use the Local statement to create local subs that are deleted automatically when the program quits, but then they can't call each other. The only other solution I can find is define the subs and functions in your program and delete them manually when it exists, which has its own disadvantages. (One being, if an error occurs or I break the program and choose GOTO, I often forget that my changes will be overwritten when I restart the program unless I remember to edit the *original* program instead (and I have to search for the sub or function there to do that). Changing code only to have it overwritten and have to do it again isn't fun.)

2. Functions can't use instructions or I/O operations. (Whose dumb idea was that, anyway?) If you want something to use instructions or I/O and have it return a value, you have to resort to global variables (ugh).

3. Variables can't be passed to subs or functions by reference, which means that if you want a sub or function to modify a variable, you once again have to resort to globals.

4. Navigating large program files is a pain (the Find... function helps, but it would be nice to have true inline subs/functions and be able to jump to them using a menu).

5. No debugging tools.

6. Local variables are cleared when a program hits a runtime error, making debugging difficult unless you change them to globals or put Disp or Pause statements in your programs.

Here are the rest (ticalc.org enforces a limit on post length--too bad we can't use a mailing list or something to discuss this).

7. For some reason, when an error occurs and I choose GOTO, the cursor doesn't always appear exactly where the error actually is (and then it takes me forever to figure out what's wrong as a result).

8. Inconsistent syntax/parameters for some functions.

Example 1: RclPic takes picname, picrow (y-axis), and piccol (x-axis), but StoPic takes picname, picrow (y-axis), piccol (x-axis), width (x-axis), and height (y-axis). It would seem more logical for the order to be height (y-axis), width (x-axis) instead, for StoPic.

Example 2: Output takes row, col, expr, but PxlText takes str, row, col. Logically, it should be either expr/str, row col, or row, col, expr/str for both instructions.

9. Toolbar instructions require using Lbls, so they essentially force you to use Gotos. (Even if you don't actually use the Goto command, the menus are essentially Goto statements.)

10. A few instructions would work better as functions (e.g., SortA and SortD), so you could use them in functions (although I think instructions should have been allowed in functions, anyway).

11. Some functions/instructions are too "picky" as far as data types are concerned. Example: checkTmr() gives an Argument error if you pass it a value in the Approx mode setting, even if it is an integer. In that case, you have to use the exact() function on the argument for it to be accepted.

Anyone have any others?

1. Create a folder to put the functions in.

4. The editor is not the language. But yes we need a better editor.

8. Example 1. An existing picture has its dimensions as part of the picture. So RclPic lets you specify the cordinates to display the picture at. StoPic lets you specify the cordinates to grab the picture and the dimensions of the picture. The two commands are consistent, but one requires more arguments.
Example 2. I'll agree.

1. True, but if I have to do that with every one of my programs, I'll have too many folders cluttering the list (since the 89 doesn't support nested folders), and then I'm back to a similar problem. :)

4. Oops. Okay, maybe I should have said "TI-BASIC and its editor."

8 ex. 1. It's inconsistent to me, because the second and third arguments of StoPic take y and x-axis coordinates, but the fourth and fifth arguments require me to think of the dimensions in the reverse order (x- then y-axis). I keep wanting to enter height then width instead of width then height (since I entered the row then column of the position). Hope that made sense.

Speaking of the program editor, I just remembered another thing (this applies to the text editor too): Page up and down are too slow. They're not much faster than just using the arrow keys.

I've never really understood why the TI calc editors have to scroll one line at a time to page up or down (that's probably why it's so slow). I've never seen any other software need to do that.

Another major problem in the OS is that there is no cut and paste in the editor. This would be an extremely useful feature. In addition, in the next Ti graphing calculator, there should be an implementation of a QWERTY keyboard. I just hate hunting for a letter on the keypad. A way to implement this easily would be to make a program for the desktop that could open and edit TI-BASIC programs.

Off the top of my head, I'd like an errornum for "Wrong Calculator Model," a checkbox/radiobuttons, a mouse, simple buttons, external labels, and windows.

Also,a wait or delay command would be nice for z80 calcs.

Faster For loops, too.

Yep. Although For loops are still faster than the other types of loops, as far as I know. But they still seem slower than on the Z80 calcs.

For is actually about the slowest loop.

It is? In my tests, the following types of loops would always execute slower on my 89 than a For loop:

:Local x
:0->x
:While x<50
:x+1->x
:EndWhile

:Local x
:Lbl a
:x+1->x
:If x<50:Goto a

etc.

It's always been slower on my tests on 92+, 89, V200 and 89Ti, VTI and hardware. It might have something to do with the local variables. I don't know.

Try retokenizing your program with Tokens89 (available at my web page). The builtin tokenizer sometimes leaves the offsets at 0, to be computed at runtime. Tokens89 always computes the offsets, leading to faster loop execution.

Hmm... I'll check. Does that have anything to do with the reason why after tokenizing a program with embedded Subs/Functions, the subs/functions will sometimes still have delays until they've been run a second time?

Oops, you didn't mention the platform it runs on (I didn't know it was a PC program). I'd have to see if it will run under WINE successfully on my Linux system (some Win32 programs do, others don't (mainly programs that use non-standard GUIS)).

I don't know if it works under WINE. I can try it (I have a Windows/Linux dual boot), but I'm not sure I can do anything for you if it doesn't. Tokens89 should really be rewritten in a more efficient, more adapted to the purpose and more portable language than VB. C would be a good candidate. But I have so many other projects...

1. Local subroutines can too call other local subroutines. I do it all the time.

2. It's common programming practice to disallow/restrict/dissapprove of input/output statements in calculational functions. The point of a function (in 68k locution, function vs. program) is to do a calculation with data input through the parameters, and output through a Return command. It is not supposed to disrupt the calling program's input/output scheme (maybe the end programmer likes a different format than you do). They can, too use instructions, just not all of them. The TI-89/92+ manual has upwards of fifty pages on the commands available built-in, and a list of maybe ten or fifteen commands that function's can't use.

3. Point. (Although I've never had reason to use reference variables.)

4. Point. I get around this by using descriptive comments and searching for those or memorizing a unique line of code in the section (usually the label).

5. Point.

6. That's the point of local variables. Changing them to globals is as simple as commenting out the "local" statement.

7. It appears at the beginning of the line, sometimes. That's all a C or Java or Cocoa compiler gives you anyway, so be happy when the cursor is in the middle of the line.

8. Point.

9. And this is a problem.....how?

10. Point.

11. I leave my calculator in Exact, anyway, so I've never had this problem.

Overall, TI appears to make you use as much of the MVC paradigm as possible in a function-oriented language. Kudos, although it can be irritating at times. It could also be entirely accidental.