TI-Basic was effectively my first programming language. Instead of paying attention in Calculus, I was making the world's buggiest sudoku solver. Will always have a special place in my heart as well.
TI-Basic and finding new programs and using the ticalc.org forums was my first intro to programming, can't wait to play with this! Thanks for the nostalgia this will unlock!
This is so cool to see and play with, and unlocks plenty of memories. Years ago I built a compiler/decompiler (my first compiler, even) for programs in the TI-84 program format. I never braved any kind of actual _running_ of those programs. Neat project!
While I will always be nostalgic for TI-Basic as my first language, I think it really stunted my programming understanding when I moved on to "real" languages.
I remember absolutely struggling to understand the idea of structs/classes, because in TI-Basic, everything is quite flat and global -- you get nearly no encapsulation.
You have 27 named variables that could hold a floating point number (A-Z and Theta), the Ans variable which was the result of the last computation (and was slightly faster to access than normal variables), 1-indexed lists with maximum length 999, and strings with length bounded only by RAM (something like 16KB or so).
If you wanted to represent any large/complicated data types, you often had to resort to encoding it in strings and doing lots of substring math to slice out the fields. Absolutely insane anti-patterns in any "real" programming language.
It did force you to learn to think outside the box to solve problems though!
Those limitations always baffled me for the TI-83/84 line. They weren't present in the TI-85/86 line. Lists were bounded only by system memory (both in capacity and number of lists), and variables could be up to 8 characters (still limited, but not as bad as only 1 letter names).
The main limitation high school me ran into was when I wanted to implement some recursive programs and had to recreate the call stack using lists as the stack. It was effective, and certainly made understanding an actual call stack easier later on when I got to my CS courses. I stopped using it after 1999, though, when a kid I was tutoring (wasn't sure which one) stole it from me. Replaced it with an HP-48G, I had a lot more fun programming in RPL than BASIC (which I'd been using for close to a decade by that point in some form or another).
I remember all those constraints, but I think for me, it was a really good thing, because it helped me understand the reason for the more complicated features of real programming languages. I knew cramming things into lists or strings was a kludge.
But before I had learned TI-BASIC, I had attempted to learn C and JavaScript. Back in the 90s, I feel like most books on programming in stores were more like language reference manuals than instructional books. It was like, "here is every feature, good luck to you".
After TI-BASIC, I was like, oh, I see why being able to dynamically allocate memory is so great. I see why explicit function parameters are so great. I see why return values are great. Et cetera.
But what really did it for me was learning Z80 assembly. That gave me an understanding of pointers, memory architecture, system calls, build process, toolchain, and so forth.
Between the two very different calculator programming experiences, I was finally primed to be able to learn C.
> If you wanted to represent any large/complicated data types, you often had to resort to encoding it in strings and doing lots of substring math to slice out the fields. Absolutely insane anti-patterns in any "real" programming language.
I think all TI graphing calculators support matrices, certainly the entire 8x line including the 83. It’s a much better way to handle large data sets than string finagling when programming them. You can treat them as a 2 dimensional array. The TI-73 has some dumb price/grade-ranged restrictions on operations and dimensions.
I collect calculators and own almost every model of TI graphing calculator except some of the newer color models.
Matrices were fine if your data mapped to 2 numeric dimensions snugly, but otherwise waste a ton of space. Space was the main constraint here.
With strings, you could get very close to base256 encoding, because you could store any valid token as a single byte, and there were almost 256 tokens. E.g. SIN, COS, TAN are all single tokens. Whereas matrices take up 9 bytes per element.
A lot of games used bitmaps to store sprites or level data, so as long as you avoided a few forbidden patterns, you could encode 8 pixels per token which was pretty cool.
So it embraced an extreme microservice architecture where every result must get serialised to a string and deserialised by the next function/service that processes it. How ahead of its time!
You did your hacks out of string manipulation? I didn't even know that was in there. I just used the list variables (basically vectors and matrices) when I needed more than 27.
In our high school we'd download games like Tetris and Block Dude for our TI84s. You could transfer the games to other calculators with a data cable. High scores would transfer, and you might try to build a collection of games. A text based adventure game was going around with a Mafia setting including drugs, guns, and prostitutes. This one was banned by teachers with severe punishment if found, but I had liked the mechanics of the game and learned TI-Basic to recreate the game with a tamer pirate theme. This led to scripting calculations for Chemistry and hiding notes in the code written in the limited character set.
In a math class in college they said we were only allowed to use our TI-83s. So I wrote some programs (from scratch) that solved the types of equations we were doing and breezed through the class. I think that application of the rule was ethical though unforeseen.
At first I thought this was about the TI-99/4A ad was wondering if would support the built in basic or the extended basic cartridge. then I found it was about the calculator instead.
20 comments
[ 2.8 ms ] story [ 44.6 ms ] threadWith a family move to a new city during summer break, purchased an '85 and spent the entirety of the last summer month just programming things in it.
Haven't stopped programing since.
Also, a game where the player tried to catch a bird that hopped randomly around the screen. Somewhere I’ve got those programs written on paper.
I remember absolutely struggling to understand the idea of structs/classes, because in TI-Basic, everything is quite flat and global -- you get nearly no encapsulation.
You have 27 named variables that could hold a floating point number (A-Z and Theta), the Ans variable which was the result of the last computation (and was slightly faster to access than normal variables), 1-indexed lists with maximum length 999, and strings with length bounded only by RAM (something like 16KB or so).
If you wanted to represent any large/complicated data types, you often had to resort to encoding it in strings and doing lots of substring math to slice out the fields. Absolutely insane anti-patterns in any "real" programming language.
It did force you to learn to think outside the box to solve problems though!
The main limitation high school me ran into was when I wanted to implement some recursive programs and had to recreate the call stack using lists as the stack. It was effective, and certainly made understanding an actual call stack easier later on when I got to my CS courses. I stopped using it after 1999, though, when a kid I was tutoring (wasn't sure which one) stole it from me. Replaced it with an HP-48G, I had a lot more fun programming in RPL than BASIC (which I'd been using for close to a decade by that point in some form or another).
But before I had learned TI-BASIC, I had attempted to learn C and JavaScript. Back in the 90s, I feel like most books on programming in stores were more like language reference manuals than instructional books. It was like, "here is every feature, good luck to you".
After TI-BASIC, I was like, oh, I see why being able to dynamically allocate memory is so great. I see why explicit function parameters are so great. I see why return values are great. Et cetera.
But what really did it for me was learning Z80 assembly. That gave me an understanding of pointers, memory architecture, system calls, build process, toolchain, and so forth.
Between the two very different calculator programming experiences, I was finally primed to be able to learn C.
I think all TI graphing calculators support matrices, certainly the entire 8x line including the 83. It’s a much better way to handle large data sets than string finagling when programming them. You can treat them as a 2 dimensional array. The TI-73 has some dumb price/grade-ranged restrictions on operations and dimensions.
I collect calculators and own almost every model of TI graphing calculator except some of the newer color models.
http://blogs.jccc.edu/math/files/2011/12/Matrices-and-the-TI...
With strings, you could get very close to base256 encoding, because you could store any valid token as a single byte, and there were almost 256 tokens. E.g. SIN, COS, TAN are all single tokens. Whereas matrices take up 9 bytes per element.
A lot of games used bitmaps to store sprites or level data, so as long as you avoided a few forbidden patterns, you could encode 8 pixels per token which was pretty cool.