Omnimaga
Calculator Community => Other Calculators => Topic started by: DJ Omnimaga on September 20, 2009, 03:55:00 pm
-
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:
:{1,2,3,4,5,6,7
:Disp Ans/3
:Pause sum(Ans
Fix: None, yet.
-
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...
-
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...
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")
-
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.
-
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
-
seconded never knew that 0.o
-
Update: added some more TI-83+SE-only glitches in the list, including one you must not try unless you no longer care about your calc (and if you really no longer caring about your calc, why not just ship it to someone else who would like a calc for very cheap or for free? :P)
-
There's also the GB collect with hidden files + any error glitch. It involves hiding some archived files, garbage collecting, and then causing any error. The calc will crash. (confirmed OS 2.43 and OS 2.40, not sure if it always shows up, though)
EDIT: well, it actually does involve using ASM programs...
-
Yeah the list actually only includes the ones not using any ASM programs, just BASIC ones or no program at all, but a compilation of ASM glitches might be a cool idea
NIce find, though, I never got aware of that one.
-
With ASM glitches, you can put up basically anything that uses the OS for out-of-purpose stuff. By the way, if the words "Application" or "ASM program" or "third-party" occur in your tech-support email, you get the fixed response: "We don't support third-party applications. Contact the developers."
But I guess you meant malfunctioning OS routines :)
Brandon Wilson 's documenting Bcalls as of now, so he'll no doubt encounter some weird stuff.
-
for BASIC bugs, I forgot a bug about the "Then" instruction I think but the issue is that I don't remember exactly how it was triggered, but it involved getting an error when not supposed to
EDIT: added it to bug list.
EDIT 2: added ERR:BAD ADDRESS bug and the modified byte when grouping bug
-
I once had this BAD ADDRESS bug, never figured out what it was, though, since it was before I learned ASM xD
EDIT: The bad address thing was on my 84+ basic, so it does occur on such calcs. ( I already had OS 2.43 back then I think)
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.
Or get GroupTool (Look at Brandon Wilson's author profile at ticalc.org) I've successfully ungrouped such files with it.
Workaround No2: Edit the Version byte in the VAT with calcsys. (if you don't know where this version byte is, open up your calcsys manual and asmin28, day 21)
-
Or get GroupTool (Look at Brandon Wilson's author profile at ticalc.org) I've successfully ungrouped such files with it.
I've come to think that this is the reason for my massive Serenity corruption, as I used it frequently before, and since I stopped using it, have not had the problem again. I ruled out TiConnect, because files that I had not transferred to my computer were later found to be corrupted too D: Anyway, I've stopped using GroupTool, even though it is very very usefull.
-
The For( glitch in action:
(http://xlib.mtv-music-generator.com/forglitch.gif)
Notice the speed difference when the closing parhentesis is removed!
I really need to scan through Metroid II code one day... maybe THIS is what causes the game to suddently slow down after taking an elevator or to just run slow altogether. I mean, how can it run so slow when the walking loop is so small?
-
OS 1.14 (I think) through 1.16
String STO glitch with matrix
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 ']'.
-
does that work with all other matrix tokens too?
-
Only works with [H], but works with all strings. I've seen it on every OS, for every variant of 83/84 I've had access to.
-
Interesting.
The TI-OS hides some strange stuff
-
hmm a glitch i know of in 2.43(i think) involves only being able to select one y equation in y= each time you press another one it turns the first one off no clue how to trigger it though
workaround :ram reset
-
I have expirienced this before as well (2.43), but i also don't know how to trigger it D:
-
Added fPart glitch to the list
-
Thats not an fPart glitch, its a cube root glitch. Try storing the cube root of 64 to a list, and then go and view it in the list editor, it should look like 3.999999999999 or the like. fPart see's this, and due to rounding on the home screen, displayed the decimal part (.99999999) as a 1. There is a way around it by calling round() on the cube root function
This effect is also apparent when doing high precision calculations such as Log(6)/Log(2) and can be atributed to round off errors :(
-
I've had it by repeatedly adding 1/3. It took me an hour to find the error in my code.
To see a number to its full precision, use that variable in the solver.
This is a really nice thread.
-
aaah ok, thanks for clarifying
-
Here's the infamous OS 1.13 PRGM menu scrolling glitch in action. As you will see, I did a RAM clear prior triggering it, and the programs I have on my calc are Illusiat 8, 9, 10, 12, Mana Force and Metroid Pure. None were ran. Look what happens if I create a new/edit a program then from there select a program from the PRGM/EXEC menu!
If you thought by programming in pure BASIC, you were always safe, think again!
EDIT: And now, as 2nd screenshot, the infamous Equ>String( glitch present on OS 1.14 or older, even on the older 83 from 1996!
-
=O
Wow! Those are some epic glitches. This first one looks to be really irksome.
The second one is just insane. Wow. DJ, what button did you press to get the crazy scrolling inverted odd text? Was it graph? Was it down?
Wow...
*ZTrumpet can't believe that Ti failed that hard-Even without programs you could FREEZE your calc...
-
See the first page of this topic, the glitch involving Equ>String should explain what to do to trigger it. Do not try on a real calc, though, in case
-
The Equ>String( glitch is a pretty bad one.
But provides awesome screen shots to laugh on TI mainly because it is present in that many versions of TI-OS.
-
See the first page of this topic, the glitch involving Equ>String should explain what to do to trigger it. Do not try on a real calc, though, in case
Thanks! Does it brick, RAM Clear, or Mem Clear? Edit: Never mind: the first post explains it. :)
The Equ>String( glitch is a pretty bad one.
But provides awesome screen shots to laugh on TI mainly because it is present in that many versions of TI-OS.
lol, yes! ;D
-
idk how bad it can get on 1.12 through 1.14. I heard stories about the glitch being much worse on older 83s and 83+ OSes, tho
-
I've gotten the Equ>String( glitch on my 84+SE with OS 2.30 o_o
I don't think it was caused the exact same way you did, but the results were definitely the same: huge equations show in memory, they turn out to be a gigantic mass of garble in the Y= editor, and then it just goes crazy
-
Really?
Did you have ASM programs on your calc tho? If not, then it could be that the glitch is present in this OS too. Could you try to recreate it again (with backing up first)?
-
I didn't have any asm programs at the time, as far as I can remember. I don't even remember how I got the glitch, just that I did, at least twice. If I knew how to recreate it, I would try though.
-
I had it happen to me a couple of hours ago, i think it was caused by an Axe program though, since i was experimenting with Portals and things were going wrong. The glitch was exactly how the screenshot looked though (the results anyway)
-
Yeah I've had an error like that when playing with axe...it happened when I was writing to L5 or L6.
-
Edited the first post with a summary of the bug reported at http://ourl.ca/4593
-
Good fail on TI's part. I have located the code that causes Err:Bad Address. TI made a beginner programming mistake. Here is their code:
;a is the page of the program
;b is the page of the last flash page available
;hl is the address of the program
cp b
jr z, somewhere
jr nc, error
ld bc, $4000
sbc hl, bc
jr c, error
Anyone see the error? The only way that execution proceeds is if carry is set. TI then doesn't clear the carry flag before subtracting. So what happens if HL = $4000? $4000 - $4000 - 1 = carry = error.
The way to replicate the error is to fill a flash page up almost all the way and leave 11-18 bytes free. (11 for a 1 letter name, 18 for a 8 letter name) This way, when it it gets archived, the entire flash header gets left on one page and the program data is on the next.
I'll be working on a fix for 2.43 and 2.53.
-
cool.
A couple of things with that ^
1. make sure you can still use the patch (i am assuming you are making) if you have a patched os from brandonw
2. You should show ti this :D see what they say.
-
Awesome! I can't wait to have it. :)
Can you please make this patch and the group one work on OS 1.19 too? That'd make me incredibly happy. ;D
-
Ok, they're done. The fix works great, I managed to unarchive that program in the screenshot. When you run them, you'll get a little menu that lets you install/uninstall them.
Making them for 1.19 wouldn't be hard at all. I actually just made a template for OS mods, so it's as easy as plugging in a page, address, and new and old data. But as of right now, there are two things stopping me:
1. I don't have a 1.19 ROM
2. I don't know how to unlock flash on a 83+.
If I get both of those things, I should be able to do it. (Don't put ROM's or unlocking code in this forum. But PM's... ;D)
-
Yay! Another fix! Can't wait for 1.19...
Also, wow, TI.
-
wow nice fix. Also fail at TI x.x
One thing, though, do not share ROMs via PM either. If you got links to any, please delete those PMs. E-mail, please. 1and1 just checked my site a few days ago to help me fix the 500 Internal Server Errors (in case it's on my side) so if they notice ROM links things could go bad...
-
Awesome, thanks! I hope you can figure out how to get them to work on the 83, though. :)
-
Btw can those be installed when Brandon's For() glitch patch and xLIB patch are installed?
-
Hmmm... I would say yes. Most OS patches are just small rearranging of code. The xLib one would be to change about 20 different values. The For( glitch would either be a shift and insert of a small area, or a call to the end of the page where it does something then returns.
Either case, they shouldn't affect this fix. I only actually shift like 5 bytes.
The 1.19 fix is on the way. I've been having some troubles, (I killed about 20 wabbitemus.) But it's coming. It would have been done if it weren't for the fact that the flash paging ports of the 83+ don't AND the value of a flash page that doesn't exist. For instance, on the 84+ BE if you tell it to go to page $7D, it really goes to $7D & $3F = $3D. But on the 83+, if you tell it to go to $7D, it goes to like $02, which will not work.
-
Ah ok. I was worried in case of conflicts that could occur.
-
The 1.19 fix is on the way. I've been having some troubles, (I killed about 20 wabbitemus.) But it's coming. It would have been done if it weren't for the fact that the flash paging ports of the 83+ don't AND the value of a flash page that doesn't exist. For instance, on the 84+ BE if you tell it to go to page $7D, it really goes to $7D & $3F = $3D. But on the 83+, if you tell it to go to $7D, it goes to like $02, which will not work.
That's a little strange, but good luck on it. :) TIA. ;D
-
hmm, my TI-84+ with OS 1.15 (yes, I used one of Brandon's programs to do so..) had the err: version
but I went to 1.19 and it was all better
-
TIA. ;D
Here, do you mean "thanks in advance" or "tits in action"? :P
hmm, my TI-84+ with OS 1.15 (yes, I used one of Brandon's programs to do so..) had the err: version
but I went to 1.19 and it was all better
I got ERR:VERSION on 1.18 personally, when grouping stuff, but MUCH less often than with OS 1.12 through 1.14. I never ever tried OS 1.15 through 1.17. I don't know if I ever got a version error on OS 1.19
-
That was way harder than necessary. I guess my inexperience with 1.19 is partially to blame. 1. The Mode+Alpha+S screen doesn't reenable the text drawing flag. Which meant it was just a blank screen which scared me. And 2. My OS checksum fixing code had a fault that allowed it to work on an 84 but not an 83.
But here it is. This will fix that 1/16384 chance that your program won't open.
-
Nice! Glad you managed to get it to work. Also i think I got the blank MODE screen on the TI-84+ before but I forgot which ASM/Axe program I ran.
Another thing I wonder is if it's possible to fix the bug mentionned in http://tibasicdev.wikidot.com/text in an OS patch?
-
What bug is that? I didn't see any specific error listed. Aside from the eraseBelow flag being set and reset sometimes.
-
The flag being set and not reset when exiting the MODE screen is the bug. It did not happen on the 83+ and 83+SE. On the 84+ it causes some games like Contra to not work properly sometimes.
On OS 1.12 I had this bug happen once but I never noticed how I created it.
-
But here it is. This will fix that 1/16384 chance that your program won't open.
Yay! Thanks! ;D
TIA. ;D
Here, do you mean "thanks in advance" or "tits in action"? :P
Um, randInt(1,2) :P
Another thing I wonder is if it's possible to fix the bug mentionned in http://tibasicdev.wikidot.com/text in an OS patch?
See this topic for more info: http://ourl.ca/4059
-
But here it is. This will fix that 1/16384 chance that your program won't open.
YES THANK YOU!
-
Another thing I wonder is if it's possible to fix the bug mentionned in http://tibasicdev.wikidot.com/text in an OS patch?
See this topic for more info: http://ourl.ca/4059
Well in OS 2.43 or lower, G-T fixes it actually. It's just kinda annoying.
-
hmm, my TI-84+ with OS 1.15 (yes, I used one of Brandon's programs to do so..) had the err: version
but I went to 1.19 and it was all better
I got ERR:VERSION on 1.18 personally, when grouping stuff, but MUCH less often than with OS 1.12 through 1.14. I never ever tried OS 1.15 through 1.17. I don't know if I ever got a version error on OS 1.19
I've gotten it twice on 1.19, so TI definitely did not fix it.
-
orly? thats strange..
damnit, on another note, it seems that a TI-83+ OS does not like being in a TI-84+SE
-
\damnit, on another note, it seems that a TI-83+ OS does not like being in a TI-84+SE
Hmm, why would that be? :P
And anyway, is the 1.19 fix for the ERR:BAD ADDRESS bug?
-
damnit, on another note, it seems that a TI-83+ OS does not like being in a TI-84+SE
I wonder why... :P
And anyway, is the 1.19 fix for the ERR:BAD ADDRESS bug?
Yes. :)
Edit: Get Ninja'd! By 0 seconds! Yea! O0
-
yes, I tihnk so
-
Doesn't the first post say that it's for 1.13 and 1.14 versions of the OS only?
EDIT: Nice, ztrumpet! :D
-
I remember back then people trying to install a TI-73 OS on a 83+ or vice-versa and 84+ OS on 83+ or vice-versa. I think in most cases, it would crash often. BrandonW made a tool to turn a TI-73 into a 83+ a while ago, though, and if I remember, he managed to put a 84+OS on a 83+SE, although it apparently crashed often.
-
I remember back then people trying to install a TI-73 OS on a 83+ or vice-versa and 84+ OS on 83+ or vice-versa. I think in most cases, it would crash often. BrandonW made a tool to turn a TI-73 into a 83+ a while ago, though, and if I remember, he managed to put a 84+OS on a 83+SE, although it apparently crashed often.
I remember Chameleon, but doesn't the 73 have a lot less flash mem?
-
It has the same as the 83+, if I remember. On some 73 OS there are less flash pages available but on some others, there are more than on the regular 83+ (12, if I remember)
-
Oh, so the 73 OS is a different size? I see...
-
The Err:Version definitely happens on an 83+. So I'll fix that today. It is a much more serious issue because it actually doesn't create the group, it just says it does. Whereas a garbage collect would fix error bad address.
Whenever I attach a fix, just look at the last 3 digits of the name. Addr119, Addr243, and Addr253 are for 1.19, 2.43, and 2.53 respectively.
-
The Err:Version definitely happens on an 83+. So I'll fix that today. It is a much more serious issue because it actually doesn't create the group, it just says it does. Whereas a garbage collect would fix error bad address.
Wait, so does this mean that if I get an ERR:VERSION, there's no way to get the files back, even through third-party stuff?
-
Correct. The OS actually double increases the page when going to the next. So for instance, say while making the group header, the OS runs out of space on page 08, it increases to page 09, then increases again to page 0A. This causes two problems, 1. Your files weren't written. And 2. When eventually the OS moves on to write to page 0A, the calculator is going to freeze when it attempts to write to an area that has already been written to.
-
Correct. The OS actually double increases the page when going to the next. So for instance, say while making the group header, the OS runs out of space on page 08, it increases to page 09, then increases again to page 0A. This causes two problems, 1. Your files weren't written. And 2. When eventually the OS moves on to write to page 0A, the calculator is going to freeze when it attempts to write to an area that has already been written to.
I've never had it freeze like that yet. Probably a good thing...
-
Ouch, that could be very bad...
Good luck fixing it! :)
-
Darn this sucks. When ERR:VERSION occured I always thought that the file was created, just not with the right header or something.
When I group shit, I just create two groups, in case. Sometimes 3 might be better. When an ERR:VERSION occurs when ungrouping, you lose the original file copy...
-
When I group shit, I just create two groups, in case. Sometimes 3 might be better. When an ERR:VERSION occurs when ungrouping, you lose the original file copy...
Whoa, really? Thanks for warning me. I've been making a single group, then testing to see if it works by trying to ungroup it. Didn't know it deleted the ones in RAM...
-
Yeah I lost a program due to that once, but thankfully I had a recent backup in an older group. Sadly, when ungrouping it wont even bother asking you to overwrite/rename, it immediately ERR VERSION on it and obliterate it. The trick, I think, is to archive everything that ungrouped successfully and then ungrouping the next group. I would backup before testing, though, in case that also deleted archived stuff. Grouping is definitively not 100% safe. Another thing that can happen is corrupted basic or ASM program. A byte gets changed somewhere in the code, causing an error or display issues while executed.
-
Hehe, I just checked out a TI-83 Plus from our school library. Great for backup :)
But then, I lost my cable :(
-
One that they lend? Wouldn't it be kinda unsafe, though, if other people can use it? Also it sucks about your link cable.
-
Well, it's for the school year. Hopefully I can get some stuff done in that time :P
-
Ah ok good :)
If they lend calcs, I do not recommend bringning yours at school when there are math tests, in case a teacher resets it.
-
Eh, my teachers never reset calcs (which is a good thing, considering I once made a pretty extensive set of math tools :D).
-
Eh, my teachers never reset calcs (which is a good thing, considering I once made a pretty extensive set of math tools :D).
Same here. In fact, I've never had a Math teacher that's discouraged programming. My current one does have a no calc portion of the test to prevent this, though. :)
-
Eh, my teachers never reset calcs (which is a good thing, considering I once made a pretty extensive set of math tools :D).
Same here. In fact, I've never had a Math teacher that's discouraged programming. My current one does have a no calc portion of the test to prevent this, though. :)
Mine actually showed the class how to make a program to calculate Riemann sums. Really, really unoptimized, but at least that means he accepts calc programming :D
-
In my case we could use our calc and programs as much as we want during tests, but the tests were written in a way that made programs useless, as you had to write down the entire solution to the problem (the answer would only count for 25% of the question score). On such test, if all your problem solutions were right but all your final answers were wrong, you would still pass the test with 75/100 mark. (the passing note is 60)
-
Oh, with us, he gave us full credit if we got the answer right, but partial credit if we showed our work and if it was wrong. So there was some incentive to use our calcs, but not much. Of course, there were tests where we couldn't use our calcs at all :P
-
There's a bug with the Clear button in OS 2.53. I'm trying to track it down and reliably duplicate it, but it doesn't appear to be replicable. Sometimes, when one attempts to clear an incomplete expression, the text will partially clear, the cursor will start running down the page, pushing the text to the top and not erasing the pixels. This will cause an infinite loop that requires you to pull out the batteries to exit. Thus, you're automatically given a RAM clear. It's fairly easy to see the bug, as it happens almost every other day for me, but I can't replicate it. Giving it precisely the same input will not always cause a crash after you insert the batteries again. This leads me to believe that it has something to do with previous entries in the memory.
EDIT:
Mine actually showed the class how to make a program to calculate Riemann sums. Really, really unoptimized, but at least that means he accepts calc programming Cheesy
And I suppose you pointed out how you could use a multidimensional array and several For( loops to optimize the code ;)
-
You wouldn't happen to be using omnicalc would you? ;)
That's a glitch when omnicalc tries to partially clear a line. It's really useful outside of mathprint, but whenever you press clear halfway through an equation in mathprint with omnicalc enabled, ram clear.
-
You wouldn't happen to be using omnicalc would you? ;)
That's a glitch when omnicalc tries to partially clear a line. It's really useful outside of mathprint, but whenever you press clear halfway through an equation in mathprint with omnicalc enabled, ram clear.
I have Omnicalc disabled right now. It's not installed, although the App is still there. But I'll see if that is what is causing it.
EDIT: Yep, it's Omnicalc. Good to know.
-
You wouldn't happen to be using omnicalc would you? ;)
That's a glitch when omnicalc tries to partially clear a line. It's really useful outside of mathprint, but whenever you press clear halfway through an equation in mathprint with omnicalc enabled, ram clear.
And that is why I no longer use OS 2.53 MP.
-
You wouldn't happen to be using omnicalc would you? ;)
That's a glitch when omnicalc tries to partially clear a line. It's really useful outside of mathprint, but whenever you press clear halfway through an equation in mathprint with omnicalc enabled, ram clear.
Oh I remember he mentionned that glitch before and could recreate it. I didn't knew he used Omnicalc. So I guess it must be due to Omnicalc, then.
-
When sending programs to the TI-Nspire running OS 2.54MP, after the transfer, sometimes, a "2" appears at the blinking cursor location. ???
-
haha, that happened to me before XD
I thought it was the amount of programs being sent `-`
-
When running an Nspire, having something on homescreen, swap keypads, boot, then swap back (I actively use both, surprisingly enough) and occasionally the homescreen will be partially cleared, partially still full of text.
-
When sending programs to the TI-Nspire running OS 2.54MP, after the transfer, sometimes, a "2" appears at the blinking cursor location. ???
That sounds like textShadow didn't get cleared. If that ever happens again, try pressing [2nd] [mode]. If my guess is right, a whole bunch of text will appear on the screen.
-
This is strange nonetheless.
Another thing:
-Go in CLASSIC mode
-Type
(22222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222, but with about 40x more 2's
-Press ENTER
-Switch to MATHPRINT mode
-Exit to home screen.
Prepare for a LOOOOONG loading time. I wonder if with like 16 KB of 2's it can cause some sort of memory/stack overflow or the like?
-
lolz worse on the nspire even!
-
Ouch, I haven't tried it because I was scared of bad stuff happening.
-
This is strange nonetheless.
Another thing:
-Go in CLASSIC mode
-Type
(22222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222, but with about 40x more 2's
-Press ENTER
-Switch to MATHPRINT mode
-Exit to home screen.
Prepare for a LOOOOONG loading time. I wonder if with like 16 KB of 2's it can cause some sort of memory/stack overflow or the like?
I tried it with a string about 1/3 of RAM. It took a long time (5-10 minutes, possibly more), but it worked.
Sadly, there is no way to break the recalling of a string/etc. :/
-
Here's some glitch I discovered in high school.
You must have CtlgHelp installed, tested on TI-83+, OS 1.19.
- Press 2nd RCL
- Press 2nd CATALOG
- Pick a function with a rather long name and press + to go in help
- Type random characters until you get a checkered cursor
- Press F4 to paste
- You should now get a glitched screen. (Press 2nd ON or CLEAR to quit without harming your calc.)
- Press ENTER (optionally after having typed some random characters)
- If you're (un)lucky, you get an even weirder glitched screen leading to a RAM CLEAR.
-
This is strange nonetheless.
Another thing:
-Go in CLASSIC mode
-Type
(22222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222, but with about 40x more 2's
-Press ENTER
-Switch to MATHPRINT mode
-Exit to home screen.
Prepare for a LOOOOONG loading time. I wonder if with like 16 KB of 2's it can cause some sort of memory/stack overflow or the like?
I tried it with a string about 1/3 of RAM. It took a long time (5-10 minutes, possibly more), but it worked.
Sadly, there is no way to break the recalling of a string/etc. :/
Ah ok. I was not sure if it would crash or something. It's insane that it takes this long, though. I think they should have made the calc automatically switch to classic mode when displaying that many nested parhentesises...Here's some glitch I discovered in high school.
You must have CtlgHelp installed, tested on TI-83+, OS 1.19.
- Press 2nd RCL
- Press 2nd CATALOG
- Pick a function with a rather long name and press + to go in help
- Type random characters until you get a checkered cursor
- Press F4 to paste
- You should now get a glitched screen. (Press 2nd ON or CLEAR to quit without harming your calc.)
- Press ENTER (optionally after having typed some random characters)
- If you're (un)lucky, you get an even weirder glitched screen leading to a RAM CLEAR.
Wow, I never noticed that before. I guess it's a good thing to know if you use CtlgHelp. I used it before because I couldn't remember syntax for commands and I was lucky to not have any crashes, since I was often running low on RAM.
I'll probably not add it to the first post, though, since it's mostly for OS-only glitches (no APP/ASM libs)
-
Yikes, i just had this do horrible things. set Y1=e^(X^2), Y2=nDeriv(Y1,X,X), Y3=nDeriv(Y2,X,X), Y4=nDeriv(Y3,X,X), and Y5=nDeriv(Y4,X,X). Then on the homescreen do Y5(0). I got a RESETING... message. I promptly pulled my batteries, and put them back in.... Grabage Collecting ??? I only lost a small test program in archive and RAM, and was able to replicate it several times with fresh RAM clears. Whats going on??
-
Wow, what OS is that? 83+1.19 gave me 2.000004, as expected.
-
Ti84+SE 2.43
And the correct 5th derivative should be more around 12 i believe.
-
O.O
Strange, it works fine for me on 83+ OS 1.19 too... 84+ glitch?
EDIT: Tested on TI-84+ OS 2.54MP: cannot reproduce crash.
-
I can't replicate it with 2.53 or 2.43. Can you do it on wabbitEmu?
-
Yikes! Wow.
Are you running ZStart or any OS patches?
-
Ti84+SE 2.43
And the correct 5th derivative should be more around 12 i believe.
Y2, Y3, Y4, and Y5 are the same in your post, btw ;)
Still can't get that bug... I'll try it on Wabbit later. As ztrumpet said, any hooks/OS patches?
-
No hooks or patches aside from Axe, and i have had a fresh RAM clear before this has occurred. I tried it on my sisters identical calculator and throws the expected Error Illigal Nest, and doesn't crash, so there is clearly something wrong with my calc... although it seems to be a deeply ingrained issue
-
Did you try reinstalling the OS and resetting the entire archive?
-
Lemme revive this slightly with this little gem I found in 2.53 MP:
(http://img.removedfromgame.com/imgs/magic_parentheses.gif)
Nothing severe, but the OS can't decide whether or not the parentheses should be there (it switches back and forth every time)
I even tried to help it :P
-
Heh, weird. I wonder why it would do that...
Does it ever give you anything more serious?
-
I don't use it ;)
Just something I noticed when I was messing around with 2.53 MP in WabbitEmu. ;D
-
Lol, plus it's slow as hell. X.x
-
Would it be possible to edit the 1st post, adding links to the patches that have been released by ThePenguin77 and BrandonW, fixing some of the OS bugs ?
Sorry if there is allready such a post in another topic: would mean I have missed it.
-
There is one somewhere, but then Thepenguin updated his patch in another place. I would need help finding the links so I can append them all on the first post.
Also some glitches are missing in the first post I think, it might be nice if I could be reminded of what it was and the fix so I can append it to the list.
-
I might have missed something, but I can't use the "bad address" patches posted some pages ago on OSes 2.43/2.53MP.
http://ourl.ca/3687/120342
Note I've had no problem with NODEL243/NODEL253/VERSN243/VERSN253 patches.
I'm using the original unpatched OSes, and a blank TI-84+.
When I press '1', the calculator just seems to freeze.
Of course NODEL243/NODEL253/VERSN243/VERSN253 were taking some secs...
But this time, nothing happens after severall minutes.
Pressing '2' or '3' doesn't seem to trigger anything.
I have to remove a battery, and use the DEL key to access the boot code screen, as the OS doesn't want to boot again.
I've tested:
* addr243 on OS 2.43 (calculator frozen for several minutes...)
* addr253 on OS 2.53 (calculator turned off after several minutes and couldn't be turned back on)
* addr243 on OS 2.53 (calculator turned off after several minutes, could be turned back on showing the same menu without additional information, but the calculator still seems frozen: the '3' key to exit didn't work...)
* addr253 on OS 2.43 (calculator frozen for several minutes... removed battery)
Seems nobody had any problem with that, so I don't understand why I can't make those patches work...
Thanks.
-
Critor, I know exactly why those are crashing. It's because they attempt to write to the boot page and the calculator says no. It's an easy fix and I'll do it later, but that's what the problem is.
And the reason why I never caught these bugs is because wabbitEmu runs them perfectly.
-
Fast answer!
Thank you very much ^^
-
I tried them on my calc a long time ago and wrote it off as a problem on my end. It's good to know that I wasn't the only one to have to resend my OS. I was on 2.43, for the record. :)
-
There you go. I even added in protection so that you can't run it on the wrong OS.
-
Thank you thepenguin77 for being so fast.
Seems to work well with OS 2.43.
But with OS 2.53MP, the program doesn't seem to run: the menu is not shown and the program returns immediately.
A problem with the added protection ?
-
I read about the "[H]" thing a long time ago (I think before I ever even had heard about Celtic 3 and long before I started assembly) and I thought it was neat, so I tried finding another token that did something like that.
-
1 byte makes all the difference.
-
Wow, as critor said, you're fast O.o These fixes are great!
-
wait, what the.....I hadn't heard that one. Is it because it's two bytes, but only reads the first?
-
Are you talking about the "p" thing? The "p" in the statistics menu is 6222 and the Str6 in this case is AA05. I made sure in case it was some other var type because, for example, hacked picture var Pic11 has the name GDB1.
[H]=5C07
lcm(=BB08
So in the "[H]" case, you aren't losing memory, but with the "p" you lose 1 byte of memory by doing the Rcl Ans. However, if you store it to a string and recall the string, you will not lose memory :D
Also, these will work fine if you are recalling it in the program editor. There are a lot of hacked variables that work similarly (if not all of them), but hacked vars usually require assembly intervention :P
-
Here's an interesting thing I need confirmed:
The upside down exclamation mark shows up as a regular one on OS 1.19. I'm wondering if I did something wrong, or did TI just fail. ???
-
I don't know about that one, but when I connect with TI-Connect, after I pull the miniusb out, the cursor gets replaced by a down arrow, and when I press anykey, its a RAM clear, its happened multiple times, too
-
Eleven times out of ten, it's TI that failed
-
@Ztrumpet Screenshot? ???
Also that pack of patches Critor is making on TI-BANK will be awesome. :D (it includes every OS patches in one download)
I don't know about that one, but when I connect with TI-Connect, after I pull the miniusb out, the cursor gets replaced by a down arrow, and when I press anykey, its a RAM clear, its happened multiple times, too
On my Nspire it changes to a 2.
-
me or Ztrumpet? or both?
-
Never mind, it looks like I accidentally changed my original program. Sorry. :-[
-
Yunhua, what kind of down arrow? Was regular arrow (black on white) or an inverted arrow (white on black)? Because if it was inverted, something is wrong as that doesn't exist.
-
Or it just acted like [2nd] was pressed. :)
-
I found a new error message.
It's ERR:MSM and I can't find *any* records of it having ever been reported. It's difficult to replicate though, because running the offending program again changes it to ERR:INV, which is documented.
For the record, I'm using OS v2.55
-
Wut? O.O
I really wonder how to recreate it...
-
I don't think Err:MSM is supposed to happen. I would imagine that the program crashed and jumped to somewhere it wasn't supposed to. I've got Waiting... Please install an operating system now from crashing a program before.
-
Was it preceded by a RAM Fail or ROM Fail msg?
-
i don't know if this is really a bug but maybe:
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]
-
Nice you found a new bug (unless it was intentional from TI?)
Confirmed in this screenshot:
-
Wow, that's a stupid glitch. It becomes present in OS 2.53 so it must have been an oversight when installing mathprint. But I can't really see people running into problems with this one. Who does a drawing command followed by a calculation?
They didn't break Disp, only the auto display ans. So I guess that's a plus.
-
Yeah true, few people should really encounter that glitch.
-
The slow clock glitch sounds to me like an accidental activation of the 84+SE's 6MHz compatibility mode, something that could be fixed with Axe or assembly or anything else with the ability to change that flag. It would be something else to know what exactly was going on when that glitch occurred.
-
Well, on the TI-83+SE OS 1.13, even without a single ASM program, turning ON the calc sometimes activated 6 MHz mode or something. However, it felt much slower than a regular 83+. Afterward, the only way to trigger this was by running MirageOS 1.1. (Those who think Mirage 1.2 is buggy should look at 1.1 O.O)
-
Found this today.
TI-84+SE
2.55MP
Had it in Classic, but I don't think it matters.
Put calc in Frac
Goto the Window menu and change at least one of the options so that it has a thick / in it
Change mode to something other than Frac
Open up the Window menu again
Either scroll down to the option with the thick / in it and then press Y=, or scroll one past.
The z address is now 31 instead of 0 (I counted)
The z address can be reset by turning the calc off then on, but so long as the thick / is present in a Window menu option, it can be retriggered by the above scrolling process.
If the calc APDs while the z address is 31, it wipes the graphscreen without marking it dirty, leaving a blank graphscreen that can be restored with a ClearDraw.
The way to fix this is to remove the thick / from the Window options, or put the calc in Frac mode, and turn it off then back on.
-
Interesting (and nice bump, too). Screenshot? I tried to reproduce it in 2.53MP in Wabbit, but I couldn't.
-
I don't have access to TI-Connect right now, And I won't for a while. I found this on a real calc, by the way. Maybe this means that it's a new bug only present in 2.55?
-
What do you need TI-Connect for? I meant using WabbitEmu, since getting a screenshot from a real calc via TI-Connect doesn't, can't capture the current z-address. ;)
-
I don't have access to Wabbit atm. I said that already. :P
-
when I used 2.55 during non-classic mode, typing 5+(pi*5)^3 gave me a wonderful BSOD. no idea what happened.
Two personal solutions: 1. Imma gonna use my prizm for most math now and 2. I'm re-downgrading to non-MP 2.43 :P
-
I tried to encourage that to ppl with mah avatar before XP
-
Freyaday, I think this one is actually hardware specific. I can't be positive, but I remember there was another topic about this and no one could replicate the glitch. I for one, could not get this to work in wabbitEmu on 2.55 or on my calc on 2.53.
So, when you get the chance, we kinda need you to test this on wabbitEmu. Or even another calculator for that matter.
-
Yeah, I couldn't get that glitch to work. It's kind of similar to the weird fraction glitch nobody could replicate. :\
IIRC, Wabbit does not emulate BSOD.
-
The Mathprint OSes have a lot of glitches that are not reproducible on anything other than your own unit.
-
Yeah. It doesn't happen in Wabbit over here, either. That said, could someone else try it on a real calc please? I don't have another one to try it on. :(
-
Have you tried resending the OS? That might help.
-
It's not really a problem. I've also sometimes seen the text char 228 have the bottom row filled, which is abnormal.
-
okay, I just remembered that I ran into a bug the otherday and I am not sure if it has been posted yet. I would go back and check, but I have limited internet time on a slugish connection (public library+middle of elsewhere). Anyway, I have a screenshot of it on my computer, but not here, so I will try to remember how I managed it. I think I did something like this in the screenshot:
:{1,2,3,4,5,6,7
:Disp Ans/3
:Pause sum(Ans
I think that is what I did. Anyway, what happens is that the when it is paused, you can start to scroll the number left/right as if it is a list or string that is too big to fit on one line. The key, I think, is that the value after Disp needs to be too long to fit on one line.
-
Confirmed for 2.53MP.
-
Normally, I'd come in here and say, "Well obviously the OS isn't setting ... flag." But this time, we are dealing with some really nasty stuff. I'm sure the problem is that a flag is incorrectly set, but the question is, which one? Stuff like this starts to fall into the category of editBuffers, and those are full of so many undocumented things that working with them is almost impossible.
This problem probably isn't worth fixing, but I'll probably still try to figure it out for educational reasons.
-
We finally figure out the fraction glitch. What happens is a side effect in the universal flash unlock ends up modifying the OS. So what I've done is make a mod to the OS so that even when the flash unlock tries to change it, it will end up having no effect.
In short, run this on OS 2.55 and you won't have to worry about the fraction glitch any more.
Edit:
Also, by the way this works, it can't happen in 2.53. However, it does occur in 2.43, though I have no idea what the side effect is.
-
Weregoose found another one here (http://cemete.ch/p175487).
-
On 2.55MP, if you take a fraction and multiply by another fraction, the home screen glitches and starts writing from the middle instead of the top of the screen. Only way I know how to fix is ram reset
-
Found this today.
TI-84+SE
2.55MP
Had it in Classic, but I don't think it matters.
Put calc in Frac
Goto the Window menu and change at least one of the options so that it has a thick / in it
Change mode to something other than Frac
Open up the Window menu again
Either scroll down to the option with the thick / in it and then press Y=, or scroll one past.
The z address is now 31 instead of 0 (I counted)
The z address can be reset by turning the calc off then on, but so long as the thick / is present in a Window menu option, it can be retriggered by the above scrolling process.
If the calc APDs while the z address is 31, it wipes the graphscreen without marking it dirty, leaving a blank graphscreen that can be restored with a ClearDraw.
The way to fix this is to remove the thick / from the Window options, or put the calc in Frac mode, and turn it off then back on.
We finally figure out the fraction glitch. What happens is a side effect in the universal flash unlock ends up modifying the OS. So what I've done is make a mod to the OS so that even when the flash unlock tries to change it, it will end up having no effect.
In short, run this on OS 2.55 and you won't have to worry about the fraction glitch any more.
Edit:
Also, by the way this works, it can't happen in 2.53. However, it does occur in 2.43, though I have no idea what the side effect is.
Lol, the answer to the problem is two posts above yours. But, you're on your way to finding more glitches :D
As a side note, we're trying to get people to use our new universal flash unlock that does not corrupt the OS. This will make this problem less prevalent, but with the large number of deceased programs, my OS patch might be the only cure.
-
On 2.55MP, if you take a fraction and multiply by another fraction, the home screen glitches and starts writing from the middle instead of the top of the screen. Only way I know how to fix is ram reset
I don't see the glitch on WabbitEmu.
-
On 2.55MP, if you take a fraction and multiply by another fraction, the home screen glitches and starts writing from the middle instead of the top of the screen. Only way I know how to fix is ram reset
You need that patched bro.
You can turn your calc off then on again. that fixes it
http://ourl.ca/16086/299943
-
Does anyone have an animated GIF of this glitch?
-
Sorry to throw Axe under the bus, but it's a program you all recognize and it uses the old unlock code.
(http://img.removedfromgame.com/imgs/fraction%20glitch.gif)
Also, wabbitemu crashes when this glitch happens while real calculators tend to change their z-address.
Edit:
The screenshot doesn't show it, but the calc screen turned off when I hit enter. I never actually saw the .666666666667
-
Sorry for the necropost but does the Bad Address error occur on all TI-84+ OSes while newer (1.19) TI-83+ OSes remain unaffected by it?
-
Sorry for the necropost but does the Bad Address error occur on all TI-84+ OSes while newer (1.19) TI-83+ OSes remain unaffected by it?
Every single OS ever made by TI suffers from this bug. Most likely it was created in their alpha builds, (unreleased 0.90 stuff), and the code has not ever been corrected. (Though it has been optimized lol)
Edit:
You can't necropost in a sticky. Besides, I got really excited when I saw a new post here.
-
Maybe TI is trying to make us choose the TI-Nspire, LOL. Did you ever face the bug?
-
I had one once where the keys were messed up badly, example: if you pressed mode it would be like you hit trace
idk what caused it but somehow it got fixed
-
thepenguin77, you made a patch right? Any problems with it?
-
thepenguin77, you made a patch right? Any problems with it?
Nope it just fixes the glitch, and here's a link (http://ourl.ca/7927/141980) for all the future googlers.
-
Sorry for the necropost but does the Bad Address error occur on all TI-84+ OSes while newer (1.19) TI-83+ OSes remain unaffected by it?
Every single OS ever made by TI suffers from this bug. Most likely it was created in their alpha builds, (unreleased 0.90 stuff), and the code has not ever been corrected. (Though it has been optimized lol)
Haha, really? How many bytes did they shave off it?
You can't necropost in a sticky. Besides, I got really excited when I saw a new post here.
Yeah, me too. It's a pretty fun thread.
-
Every single OS ever made by TI suffers from this bug. Most likely it was created in their alpha builds, (unreleased 0.90 stuff), and the code has not ever been corrected. (Though it has been optimized lol)
so they made the glitch faster instaed of fixing it?
-
Sorry for the necropost but does the Bad Address error occur on all TI-84+ OSes while newer (1.19) TI-83+ OSes remain unaffected by it?
Every single OS ever made by TI suffers from this bug. Most likely it was created in their alpha builds, (unreleased 0.90 stuff), and the code has not ever been corrected. (Though it has been optimized lol)
Haha, really? How many bytes did they shave off it?
They didn't cut much off (like 10 bytes out of 200). They took some redundant code and made it into a subroutine. Honestly, I wouldn't be surprised if they made a script to do it for them.
-
OS 2.55 I think sigma glitches in MP (OS 2.55). It doesn't ram clear but it messes with contrast and "shifts" the screen downward. I don't know if it's just me, but it does it when n=1 to 9999.
-
Sorry to throw Axe under the bus, but it's a program you all recognize and it uses the old unlock code.
(http://img.removedfromgame.com/imgs/fraction%20glitch.gif)
Also, wabbitemu crashes when this glitch happens while real calculators tend to change their z-address.
Edit:
The screenshot doesn't show it, but the calc screen turned off when I hit enter. I never actually saw the .666666666667
What is a z-address?
-
@Yeong: I could not reproduce it
@aeTIos: The lcd has the ability to have its pixels shifted down or up. For example, if you shift them up 8 pixels in the normal OS, headers in menus will appear on the bottom of the screen. There are a handful of games that use the z-address to create earthquake effects, too, since it is very fast compared to shifting the whole screen and then updating the LCD, this takes probably at most 38 t-states and however many wait states are required between each LCD write.
@thepenguin77: Z-Addressing appears to work in Wabbit now :D
-
Yeah. The fraction patch fixed it. I'm pretty sure it was just my calc derping
-
Bump:
@Yeong: I could not reproduce it
@aeTIos: The lcd has the ability to have its pixels shifted down or up. For example, if you shift them up 8 pixels in the normal OS, headers in menus will appear on the bottom of the screen. There are a handful of games that use the z-address to create earthquake effects, too, since it is very fast compared to shifting the whole screen and then updating the LCD, this takes probably at most 38 t-states and however many wait states are required between each LCD write.
@thepenguin77: Z-Addressing appears to work in Wabbit now :D
Yep, I make heavy use of Z-addressing in Illusiat 2004, Reuben Quest and to a lesser extent ROL2/3. The reason why I stopped using it was because it only worked in 1 emulator: PindurTI, and it doesn't work on the TI-Nspire 84+ emulator.
Also:
Could someone check the list of bugs on the 1st post and post whatever is missing that was discovered in recent years? It would definitively be nice to complete that list, especially with the MP OSes. Please, only OS bugs, not bugs caused by ASM programs and stuff.
Also who thinks that most OS 2.43 and 2.55 MP bugs will still be present in OS 4.0 for the Color 84+? <_<
-
Could someone check the list of bugs on the 1st post and post whatever is missing that was discovered in recent years? It would definitively be nice to complete that list, especially with the MP OSes. Please, only OS bugs, not bugs caused by ASM programs and stuff.
Okay, I updated it :)
Also who thinks that most OS 2.43 and 2.55 MP bugs will still be present in OS 4.0 for the Color 84+? <_<
The game.
-
Also who thinks that most OS 2.43 and 2.55 MP bugs will still be present in OS 4.0 for the Color 84+? <_<
It depends. If they have the same CPU, they'll probably have copy-pasted everything and only rewrote the drawing code.
-
An interesting bug was found and reported on TI-BD. The glitch and how I managed to reproduce it:
(Note that this was tested on OS 2.55MP)
-First, she created an app with Basic Builder to put a bunch of BASIC programs together
-From there, run one of the programs that uses an Input command
-Once you exit, you cannot use fractions mode, even if you use ►Frac or set it manually in the mode menu.
Fixes:
-Run the app again, exiting before you use an Input command.
or
-Include this program and run it before exiting the app:
AsmPrgmFD362800C9
It took some hunting to figure out which flags were causing the issue. The flags should have nothing to do with displaying fractions, but the OS apparently exits some routine early if they are set:
bit appRunning,(iy+APIFlg)
bit 6,(iy+APIFlg)
For whatever reason, it seems that when an Input command is parsed, the app exits with those two flags still set, but otherwise it returns with them reset. Resetting them seems to fix the problem.
This bug does not seem to be present on OS 2.43, though.
-
Do Basic Builder applications call B_CALL(_ReloadAppEntryVecs) before exiting? If not, I don't think it's an OS bug as much of a Basic Builder bug for not following TI's application exit protocol. I think it was recently noticed in a thread on Cemetech that one of the effects of not calling this (at least on MP OSes) is that the appRunning flag is left set when the application exits and small issues arise, so whether or not you mess around with context vectors and you think you actually need the call, it seems that this call may be important.
-
Hmm, I had never known about that. The problem seems to only arise when the Input command is used (probably because an edit buffer is opened). If the app is run and a program that doesn't use Input is run, it causes no problems and the flags are reset properly.
-
Do Basic Builder applications call B_CALL(_ReloadAppEntryVecs) before exiting? If not, I don't think it's an OS bug as much of a Basic Builder bug for not following TI's application exit protocol. I think it was recently noticed in a thread on Cemetech that one of the effects of not calling this (at least on MP OSes) is that the appRunning flag is left set when the application exits and small issues arise, so whether or not you mess around with context vectors and you think you actually need the call, it seems that this call may be important.
To be clear: if you don't change the context vectors, there is no point in calling ReloadAppEntryVecs (it won't hurt either.)
If you do install custom app vectors, your putaway routine needs to B_CALL ReloadAppEntryVecs, and then either B_JUMP PutAway (recommended) or exit in some other way (not recommended, but seen in some example code from TI.) As a rule, a custom putaway routine should never 'ret'.
(As a side issue, if your program's exit routine does its own cleanup, making the putaway routine unnecessary, you might also choose to call ReloadAppEntryVecs before JForceCmdNoChar. In most cases, though, it makes more sense to put all the cleanup code in the putaway routine, so it will be called regardless of which way you exit.)
-
My math teacher (and about half the class) found a bug in OS 2.53.
When MathPrint is on and you do a regression with an exponent, then recall that regression into any Y-var with RegEQ in the variables->statistics menu, the first exponent can either contain garbage, or the recalling will be cut off after that. As far as I can tell, this is a MathPrint problem, and it seems to have been fixed for OS 2.55.
-
Interesting, I didn't know about that bug. Seems like they're somewhat fast at fixing some math-related bugs, but still slow at others and it takes them a while to notice math bugs.
Also who thinks that most OS 2.43 and 2.55 MP bugs will still be present in OS 4.0 for the Color 84+? <_<
The game.
<_<
Although on a serious note, what I thought was finally right: The 84+CSE does have bugs. Here's Cemetech bug reports post by Kerm quoted below:
[FATAL] Using certain Pt-On commands with color codes shows those points as black until the program ends (2/19/2013)
[FATAL] Scrolling the BASIC editor is unbelievably slow. For [ALPHA][↑] and [ALPHA][↓], do not re-draw intermediate lines? (2/21/2013)
[FATAL] Typing in the BASIC editor is very slow. Typing at a normal speed causes many keystrokes to be missed, requiring the user to type very slowly. (3/13/2013)
[FATAL] If you have insufficient [mono]End[/mono]s for your [mono]For/While/Repeat[/mono] loops, and the graphscreen is active, your program will end with whatever was stored in [mono]Ans[/mono] awkwardly overlaid on the graphscreen. (3/3/2013)
[ANNOYING] Setting [mono]0→Ymin:1→ΔY[/mono] incorrectly sets Ymax to 165 instead of 164. (3/3/2013)
[ANNOYING] Although the [mono]Menu([/mono] command accepts 9 options + 1 title (instead of the old 7 options + 1 title), the last two options appear as ??, and choosing those options causes an ERR:LABEL. (2/23/2013)
[ANNOYING] [ALPHA]-scrolling the BASIC editor scrolls by 7 lines, not 9. (2/26/2013)
[ANNOYING] Typing in an X-value for the right bound of an integral on the graphscreen makes the dotted left bound disappear. (3/13/2013)
[ANNOYING] When setting stat plots, if you use a color number instead of its token (eg: 10 instead of BLUE), it causes an ERR:SYNTAX. (5/4/2013)
[TRIVIAL] The ALPHA-ZOOM (F3) matrix-entry Shortcut menu is baffling to beginners. (3/2/2013)
[TRIVIAL] Scrolling down from the bottom or up from the top of a menu with fewer than one screen of elements (<9 elements) flashes unexpected graphical artifacts. (3/13/2013)
[TRIVIAL] The RAM FREE and ARC FREE numbers in the Memory Management menu aren't far enough to the right. (3/17/2013; thanks DrDnar)
[TRIVIAL]
-To add to that, the gradual scrolling animation when using 2:Goto after quitting a program or when using ALPHA scrolling isn't even necessary. It's so slow that I bet that most people would probably prefer that it's removed.
-The Pt-On glitch only occurs when not using the default 3x3 square shape
-Slow typing also sometimes occurs on the home screen or the Y= menu. It's enough to annoy anyone in math class. In the program editor, though, it's not as bad at the bottom of the screen than the top, so scrolling a few lines up before editing sometimes helps.
-
Not really a bug, but this could be a bit annoying to 84+CSE users who are still learning the ropes about setting up their graph windows properly:
Let's say that you use ZStandard with dotted grid enabled, but decide to change the XScl value to make the grid smaller. If you set it way too low (for example 0.1), the grid will take A LONG while to render and you won't be able to cancel it with ON or anything.
That isn't a problem with GridLine mode nor YScl, just GridDot and XScl.
-
Not sure if anyone has mentioned this but the For( speed bug only happens if the IF is the exact next byte after the for loop without the closing Paren.
Basically this triggers the bug
:For(x,1,1
:If blah
:
:Endand this doesn't
:For(x,1,1
:Blah
:If blah
:
:End
-
Update - the [H] sto glitch has been patched in the new 84+ Color calculators(IE the 84+CSE and the 84+CE)my bad they still do this in classic mode. It seems that MathPrint actually fixes a bug... :o
-
The Equ>String bug also messes up the screen when you hover over Y2 in the Y= menu