Calculator Community > Other Calculators

TI-83+/84+ OS glitches compilation thread (all OSes)

(1/39) > >>

DJ Omnimaga:
I thought about making a topic where we could compile various TI-OS glitches we encountered so far in BASIC programming or just by using our calc without ASM programs.

In some cases, having the latest OS version is the best way to avoid nasty crashes. However, for some reasons, you might want to keep an old OS installed on your calc: For example, OS 1.12 apparently runs slightly faster than newer OSes. In rare occasions, some games, such as Illusiat 6, might work better on older OSes. So it's still good to know what to avoid doing on these old operating systems.

All OSes
String STO glitch
Trigger: Combine a large amount of string together (Str1+Str1+Str2...etc) or multile large strings together.
Effect: Huge memory leak of around 2000-8000 bytes. Program runs between 40% and 75% slower than normal.
Fix: To get rid of the memory leak, exit the program
Workaround: Store concatenated strings in smaller chunks separately. The size of strings at which the bug starts being triggered is unknown, though.

Tested on OS 1.18 or higher, unconfirmed on older OSes
For( glitch
Trigger: The For( loop must contain either a lone If with no Then where the condition is false, or usage of IS>( and DS<(. In all cases, the For( instruction closing parhentesis must be omitted
Effect: These instructions are processed considerably slower than if the For( parhentesis was closed. Also causes the entire program/game to run slower afterward and possibly (not confirmed) a memory leak.
Fix: Exit the program
Workaround: Always close the parhentesis for the For( instruction when the loop only contains a lone If instruction or if it contains the IS/DS instructions.

All OSes
Goto/prgm called inside itself memory leak
Trigger: Use a Goto instruction inside a For(/While/Repeat/If/Then/Else instruction or run a program from inside itself.
Effect: Maybe not really a bug, but causes a memory leak.
Fix: Use Return or exit the program.
Workaround: Do not use Goto inside loops and conditions

Possibly all OSes
Cubic root & fPart glitch
Trigger: Use the cubic root function inside a fPart function.
Effect: In some cases, this will return 1 instead of 0. Someone reported this sometimes returns 2 or even numbers such as 1*10^-12.
Fix: None
Workaround: Not using cubic root function with fPart(

OS 1.13 ONLY
PRGM menu bug
Trigger: Have at least 50 programs on your calculator, open the PRGM editor, press PRGM from there, then go in EXEC and scroll down the program list.
Effect: RAM Clear, Blue Screen/Lines Of Death, Static, ROM/RAM Fail, OS reinstall screen
Fix: Remove battery, put it back then turn calc back ON.
Workaround: Do not scroll the PRGM list from the PRGM Editor when you have many of them or simply switch to a different OS version.

OS 1.13 or below & all TI-84+/SE OSes
Text( additional pixel row bug
Trigger: Unknown on 83+ OS 1.12/13 (happened twice to me in 8 years). On 84+, simply go in the MODE menu, which will sometimes trigger it
Effect: An additional row of pixel is erased below text displayed using Text( commands.
Fix: use DispTable, switch the prgm to G-T mode while it's on graph screen
Workaround: Unknown on regular 83+/83+SE. On 84+, Do not access the mode menu before using the program. Since your program migth be destined to public use, this might be hard to make sure people won't do so, so have your game start with a Pixel turned ON, then a Text( command called right on top of it. If the pixel gets turned OFF, have the game do one of the things mentionned in "Fix:".

OS 1.03 through 1.14. Unconfirmed on OS 1.15 through 1.17.
Equ>String bug
Trigger: Press Y=, CLEAR, GRAPH, Y= again, type zero in Y1 then on homescreen type Equ>String(Y1,Str1 and execute this 4 times.
Effect: Large files of around 40 KB will appear in the Mem menu and garbage will appear in Y= functions. Moving the cursor over them will cause the calc to crash then either lock-up the calc or trigger a RAM clear.
Fix: In most cases, turn the calc back on (sometimes a battery must be pulled before doing so). In worst cases, a full memory reset (Archive+RAM) or an OS re-install will be required.
Workaround: Update to latest OS version.

TI-83+SE OS 1.13 ONLY
4-5 MHz speed glitch
Trigger: Unknown. Happened often when turning the calc OFF then ON or through the Finance app, though.
Effect: calculator runs 3 times slower than normal or about 80% slower than a regular 83+
Fix: RAM clear
Workaround: Update to another OS.

TI-83+SE OS 1.13 & 1.14 (unconfirmed on OS 1.15 through 1.17) and TI-84+/SE
ERR:BAD ADDRESS
Trigger: Archive a program in the MEM menu. This glitch is random and occurs very rarely.
Effect: The program will no longer be unarchivable. RAM will still be allocated for the program, but you'll get a BAD ADDRESS error and it will remain archived. The RAM is only recoverable with a RAM reset.
Fix: RAM clear and delete the program
Workaround: Update to another OS.

All OSes, altough it seems less frequent on newer OSes
Modified Group content bug
Trigger: Group files.
Effect: Sometimes, a byte of data is modified in grouped files. This can occasionally cause program content to be slightly altered, for example instead of 2+2->A, you might get shit like 2+ANOVA(A, causing your program to error. In more frequent cases, especially on OS 1.13 and 1.14, ERR:VERSION will occur when ungrouping the file, which will delete the other copy from the RAM in the process.
Fix: None
Workaround: To prevent ERR:VERSION, always group your stuff twice then ungroup each groups to make sure everything is correct or update to latest OS. For the rest, you just need luck, altough this is much less frequent on newer OSes, if it happens at all.

TI-83+SE OS 1.13 and 1.14 (no clue about OS 1.15 through 1.17)
Grouping archived files
Trigger: Have the archive memory be saturated, which means close to GarbageCollection time (when archiving starts taking a long while)
Effect: The closer to a garbage collection you are, the more archived files will show up in the GROUP menu when selecting files to group. At first, very few files will show up, but eventually, every archived program shows up. DO NOT TRY THE FOLLOWING IF YOUR WARRANTY IS VOID. I WON'T HOLD RESPONSIBLE FOR DAMAGES CAUSED TO YOUR CALC! THIS IS EXTREMLY DANGEROUS!!!!!!!Grouping such file causes bad effects ranging from RAM Clears to bricked calc (the first time I intentionally did this, I had to return my calc to Staples with the receipt to get a new one in exchange. The second time I accidentally selected one of these files when doing a backup of one of my game I was working on and the calc simply locked up, but it could have been worse, altough I think the calc was still under warranty at this time)
Fix: Garbage Collect. If you grouped such bad files, do the battery pull trick then press ON, else, do it again while holding DEL then follow instructions on screen. Else, try reinstalling the OS. If that fails too, take your calc back to the store with your receipt.
Workaround: Update to another OS.

All OSes
"Then" glitch
Trigger: Put either two ":" characters or a line break plus a ":" character before the "Then" instruction. In some rarer cases, putting a ":" right after "Then" then a linebreak on OS 1.12 will also trigger that glitch.
Effect: The TI-OS will interpret it as an invalid syntax, even if it's just line breaks or code lines separators. In other words, you'll get an ERR:SYNTAX
Fix: Make sure there's only one type of code line separator between "If" conditions and "Then" instructions, such as a line break or ":" character.
Workaround: None.

All OSes
String STO glitch with matrix [H]
Trigger: Store the symbol for matrix H to a string, as in: "[H]->Str1
Effect: Do a variable recall on the string (2nd, RCL), and you will get "lcm(" which also happens to be the 8th item in the MATH->NUM menu (coincidence, eh?).
Workaround: Waste a byte or two, and store the actual characters for '[' 'H' and ']'.

Possibly all OSes
String recall glitch
Trigger: During the recalling of a string in the PRGM editor, the Y= menu, the List editor, the equation solver or the home screen, where recalling is done char by char, have 1 byte of RAM left when the next character is a 2 byte token.
Effects:
-1) If recalled at the end of the program, it scrolls through random tokens garbage during several minutes, then freezes until a battery is pulled.
-2) If recalled somewhere else in the program, it scrolls at the end of the program line, freezes during several seconds, then shows the checkerboard cursor. The token changes to something else.
-3) If recalled in the Y= editor, the EQU solver, the List editor or the home screen, it freezes until a battery is pulled.
Fix/Workaround: Try to keep your RAM from going too low while using 2nd+STO a lot. More info about this bug at http://ourl.ca/4593/110645

OSes: 84+ tested with 2.53 and 2.55
trigger: put in the homescreen in one line: a function that calls the graph, an ":" and then a function that calls back the homescreen
effect: the graph screen is now the background of the homescreen
fix: press [clear]

Probably All OSes:
Trigger: Storing to u(nMin), v(nMin), w(nMin), Zu(nMin), Zv(nMin), or Zw(nMin)
Effect: It messes up the floating point stack causing programs and subroutines to misbehave (they don't return properly to the parent program).
Fix: None, yet.

Probably All OSes:
Trigger: Disp <<value that doesn't fit on one line>> followed by Pause <<value that fits on the line>>
Effect: The value that follows Pause will be able to scroll, even though it shouldn't. Example:

--- Code: ---:{1,2,3,4,5,6,7
:Disp Ans/3
:Pause sum(Ans

--- End code ---
Fix: None, yet.

cooliojazz:
Wow, those are quite interesting.  Did you find all these yourself?  Also, I back on my old 84+, before I lost it and got an 84+SE a few moths ago, I had Doors CS 6, Mirage OS, and Dark Pheonix on it. (I had other things, of course, but those are inapplicable to this situation :P) I would run Dark Pheonix from one of the shells( I think it was mirage, but it could've been Doors), and once in a while it would do the same  kinda speed glitch thing, where you would have to hold a key for around 3-5 seconds before a response, and the only way to fix it was to either go into the other shell (I think Doors, but once again, I could be wrong) which would only fix it maybe %30 of the time, or do a ram clear.  I don't know if this is related to the one you mentioned...

calc84maniac:

--- Quote from: cooliojazz on September 20, 2009, 09:30:54 pm ---Wow, those are quite interesting.  Did you find all these yourself?  Also, I back on my old 84+, before I lost it and got an 84+SE a few moths ago, I had Doors CS 6, Mirage OS, and Dark Pheonix on it. (I had other things, of course, but those are inapplicable to this situation :P) I would run Dark Pheonix from one of the shells( I think it was mirage, but it could've been Doors), and once in a while it would do the same  kinda speed glitch thing, where you would have to hold a key for around 3-5 seconds before a response, and the only way to fix it was to either go into the other shell (I think Doors, but once again, I could be wrong) which would only fix it maybe %30 of the time, or do a ram clear.  I don't know if this is related to the one you mentioned...

--- End quote ---
That glitch sounds like a program change the status of the link port, making the OS constantly wait for data. That should be fixable by entering anything on the homescreen and pressing Enter (like "0")

cooliojazz:
No, nothing you would do would ever fix it, except sometimes running the other shell and/or ram clear.  And it wasn't just the keys, it was everything.  If I actually took the time to run a program, which takes quite a while at that speed, everything about it would be slow.

miotatsu:
that for( bug is interesting, i'll have to pay more attention to my for loops in the future, i wasn't aware of that until now

Navigation

[0] Message Index

[#] Next page