Hi,

Today I sent arTIfiCE and asmhook together with some programs to the calculator of a friend, so that he could play games on his calculator, for example.

But he sees something on his calculator screen which causes him to think that it might crash and become unusable.
He said he was seeing stripes at the top of the screen..
He also had trouble with something with the graph screen after using my own board game written in TI-BASIC.
I don't know exactly what he saw, it was a vaguely description, but I don't think a TI-BASIC program can cause anything bad?
He said me a few hours ago that he believes it's too dangerous and that he doesn't want to buy a new calculator if anything goes wrong.

But my question is: Is it even possible that your calculator becomes useless?
Because some of you have very much experience with the TI calculators I think you'll be able to give a trustable answer to this.

It's technically possible to brick a calculator, but outside of using Bootswap or Cauldron (which don't work on the -T anyway), you'd have to be extremely deliberate about it. You can get it into a state where you have to press the reset button on the back, or, very rarely, into a state where you have to reinstall the OS, but it's basically impossible to make a calculator permanently unusable without taking a hammer to it.

What he's probably seeing is the corruption of pixelShadow by a C program, which is expected and completely harmless - pixelShadow is basically an image of the homescreen used by the OS to display the homescreen after exiting a menu, and it takes up a lot of RAM. As a result, C programs use pixelShadow to store data while they are running, which can result in a corrupted-looking image being restored to the homescreen after the program exits. This is purely visual, though - pressing clear will cause pixelShadow to be deleted anyway, so it won't affect the operation of the calculator in any way.

As for the graph screen, that's probably just that the graph settings being changed by the TI-BASIC program. You can usually reset those as a user by pressing zoom, then 6, to reset the zoom, and possibly turning axes on by pressing 2nd+0 then selecting AxesOn.
As the program developer, you can also save and restore the graph settings to and from a GDB.

Yes, its possible to brick it with ASM. As far as I know, there's no way to brick your calculator in TI-Basic. I suspect what he was seeing was just some garbage at the top of the screen left by an asm or C program not cleaning up after itself. If that's the case, its not harmful and just clearing the graph screen would make it go away.

Yes, or pressing 2nd>ZOOM and selecting everything on the left.

I totally get why your friend is worried since they don't understand how the calculator functions. However, as others said above, so long as you aren't intentionally finding ways to mess with the Boot Code, it's difficult to brick the calculator. If your friend ever encounters something that a simple RAM reset doesn't fix, be sure to keep this recovery guide in mind.

Cermastr and some corrupted ASM programs can brick the CE. A few times, when I edited a program, I would scroll through garbage code (that seems to be nonstop), and encounter a lot of question marks, or names of variables that I didn't have in my program, but that I did have elsewhere on the calculator. If I scroll far enough, anything I do to exit it will cause the screen to shift and reveal a lot of garbage. After you reset the calculator, I remember it turning it off. You could not turn it back on, no matter what you did. I think it was caused by an error with ungrouping.

Pictures that I still have:


Additionally, on the CE, I noticed that if an ASM program resets, and you have Cesium to back up your RAM, you can get an error like this:

This error repeats if you try to quit. Sometimes, if you turn the calculator off, you can't turn it back on.

0x5 I've never heard of a corrupt ASM program bricking a calc. All those errors you found can still be fixed with a simple RAM reset. Nevertheless, be sure to backup often.

How did you get a screenshot of this / how can I reproduce it? Thanks

The easiest way I replicated this was:

Code:

56 zeroes.

Though it can occur with other ASM programs. I had this error a lot, a few years back.
If it causes a crash/RAM reset, this infinite Memory loop can occur. I think you need Cesium's backup feature to get this to occur.

That doesn't really help - that program is non-deterministic, since it does nothing and then doesn't exit. It does something completely different depending on the previous contents of userMem (e.g. the last program you ran, or the contents of your calculator's memory).

Does Cesium do that every time it resets, or only for some programs? Here's one that just resets the calculator:

Code:

Yesterday he sent me a photo of his screen with the question if it was normal.
I told him if it just goes away with pressing [clear] it wouldn't be worrying.
I wasn't able to reproduce it like that though.
He said he had also run the program getlcd because he had forgotten wat it was and wanted to know..

Only for some. But I guess you are right that it depends on other data points in the calculator's memory. Sometimes a reset occurs without the "RAM cleared" message, and other times it's an infinite "Error: Memory" loop.

Also, when I said "corrupted ASM programs" could brick your calculator, I remembered that it was actually a Basic program that got corrupted (probably due to ungrouping causing bit errors), and I was able to infintely scroll down in Cesium's editor.

Well, if used improperly, "sure" (and then again, there can be ways to salvage the calc depending on what was done). But that's why people should follow tutorials etc. and not blindly press random keys on random programs like I'm sure some do.

And the OS itself can damage the certificate memory's contents on its own. That's what happened to my 83PCE non-EP while testing the transfer of some valid, official FlashApp transfers with libti*+tilp. It started identifying itself as SerCertNotSet NoCertProductName.
That's a testimony to both the fact that TI's code has bugs, and the fact that it's hard to brick a TI-eZ80, possibly even harder than bricking a TI-68k.

Those look like the standard effects of a C program. It's completely harmless and purely graphical, and pressing clear should fix it.