TI BASIC Bug - crashes, crazy sprites, and a possible jailbreak ?

[Tornadoboy]

I don't know if it's the same thing being discussed here, but I remember what was either a basic or XB game called "AL Capone's Vault" or something in which you had to figure out a combination. If you tried to cheat and list the program to see what the code was before you got to it you would see a REM which said "If you won't play fair, then I won't play fair", then while trying to show the next line the graphics would glitch and the computer would reset. I got around this by simply figuring out what line # was crashing it and listing everything AFTER that line 

[RXB]

3 hours ago, OLD CS1 said:

Rich, I cannot believe you, of all people, are so dense and obtuse as to not understand what is happening here, as if you cannot see past your nose.  The user is most certainly not filling up memory, but is doing something which is seemingly innocuous.

Well, no shit, Sherlock, but what is causing the computer to think it is out of memory, and how?  THAT is the question.  You are simply looking at the symptoms, not the problem.

Right.  A couple of maxims apply here:

• Unpredictable errors are, by definition, unpredictable.
• Nothing can be made fool-proof, because fools are so ingenious.

But the original question here is what I asked earlier: why do those statements, in the absence of everything else, cause the system to misbehave, including thinking it is out of memory.

Typing in A=A/

Results in a token error as it is looking for a value but as it is blank, thus after all it can not go to NUD TABLE to find the Token so it ends up never getting to the error routine for Syntax Error.

This explains why in TI Basic or any XB it hangs at GROM >16CB which is the text for Cassette routine and the system going into LA LA LAND!

 

If you type in A=A/ normally in TI Basic or XB it will report * SYNTAX ERROR *

 

But you previously put in

H=346764563534535346327263547254763264727335672367357427354734547234673547236476547

 

You have purposely overflowed the VDP Stack Routine so when it looks for an error it is overflowed and can not get the ERROR routine to work so ends up in LA LA LAND.

 

I should add a few steps later it ends up at GROM >18C8 and that is about the time you see sprites pop up randomly.

 

Edited May 23 by RXB
missing text

[+Ksarul]

Thanks for taking the time to analyze this one in the end, @RXB. That answers the first half of the original poster's question. Now we just need to figure out if it will also lead to an alternate method of jailbreaking. Playground is a neat tool, but if this leads to another path, that gives us another great solution.

[RXB]

1 hour ago, Ksarul said:

Thanks for taking the time to analyze this one in the end, @RXB. That answers the first half of the original poster's question. Now we just need to figure out if it will also lead to an alternate method of jailbreaking. Playground is a neat tool, but if this leads to another path, that gives us another great solution.

I forgot to include that the VDP STACK is overflowed, but GPL Subroutine stack also is emptied so it starts just picking GROM address which is why it is in GROM 0 for no reason.

[Retrospect]

I've seen similar threads to this a time or two before, and I always recommend this online app here ... you get rid of the example code , delete it, type your own thing in ... you can then save it out as a .BIN but if you get rid of the file extension it will load as a program file in either Classic99 or Js99er.

 

Use this program to exploit TI Basic (And Extended basic) .... what it does is, it allows you to enter things that the Basic parser would never let you do.  It forces it into a program.

 

Chances are the program might crash upon loading but if it doesn't, you may be able to exploit things?

 

For example, to see a colourful crash, type things without line numbers and save it out and then load it in to the emulators.

 

Or anything, really.  See what you can do.

https://nivelleringslikaren.eu/ti994a_basic/index.html

 

 

[senior_falcon]

I have played around with this a bit, hoping to come up with a way to get sprites that you can control with TI BASIC.

The idea is that you could define a few sprites using CALL COLOR, and change the motion table with CALL CHAR(143) and higher.

 

Start with this program:

10 A$="NOW IS THE TIME FOR ALL GOOD MEN TO COME T "   

I used the debugger to modify the space after the final T to be >10. This byte will wind up at >837A which is the maximum number of sprites in motion. For testing you could leave this as a space to allow movement of 32 sprites.

Save it.

10+down arrow to edit line 10. Change A$ to B$ and enter.

Then enter A= and the sprites will appear on the screen. Two important things have happened. v0300 is now F0 so now sprites are enabled, and >837A is >10 to allow sprite motion.

Enter NEW. BASIC doesn't restore v0300 and >837A because it thinks they cannot be changed.

The top of memory pointer at >8370 is wrong and needs to be reset. CALL FILES(1) or (3) will reset the memory pointer at >8370

CALL COLOR works as expected.

But if you try CALL CHAR(143,"1111") you get an INCORRECT STATEMENT message.

If you run

10 A$="Hello World"

20 GOTO 10

the debugger shows everything normally until the screen gets colorful. Evidently it is not doing the garbage collection and is just plowing through the color table and other VDP areas.

 

So I have come to believe that not much useful can come from this.

I suppose you could have a program that preloaded the color table and the pattern table to define sprites and their motion, then modify line 10 and do A= to demo some sprites. But I think BASIC is damaged enough to be unusable for anything but the simplest of programs.

 

 

 

 

 

[cph1776]

On 5/23/2024 at 11:26 AM, Tornadoboy said:

I don't know if it's the same thing being discussed here, but I remember what was either a basic or XB game called "AL Capone's Vault" or something in which you had to figure out a combination. If you tried to cheat and list the program to see what the code was before you got to it you would see a REM which said "If you won't play fair, then I won't play fair", then while trying to show the next line the graphics would glitch and the computer would reset. I got around this by simply figuring out what line # was crashing it and listing everything AFTER that line 

Some years ago, I wrote a long program. Somehow part of the file became damaged, and, if you listed it past (say, Line 1000 or so) it would hang up/restart the computer. Yes, you could list past that line and everything would be OK. Program ran fine, though.

[Tursi]

4 hours ago, cph1776 said:

Some years ago, I wrote a long program. Somehow part of the file became damaged, and, if you listed it past (say, Line 1000 or so) it would hang up/restart the computer. Yes, you could list past that line and everything would be OK. Program ran fine, though.

I had a tape program that was similar to that. It was the only time I didn't verify the save, and it was corrupted. I was able to load it (repeatedly) by rewinding the tape at the end, and playing a little more of it. After that, the beginning of the program was corrupt - listing it would hang the computer in an eternal token dump, and RUN would fail. But it was just the title page that was corrupt, so I could RUN 500 (or whatever it was), and it would run fine.

 

I attempted to fix it once by deleting the broken lines, but the corruption just moved to the next line. So for years I just accepted it like that. Sadly I don't have it anymore, could probably fix it today.