Author Topic: TI-83+/84+ OS glitches compilation thread (all OSes) (Read 135121 times)

Xeda112358 · « **Reply #180 on:** January 31, 2013, 07:56:31 am »

Quote from: DJ_O on January 31, 2013, 03:51:02 am

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

Quote from: DJ_O on January 31, 2013, 03:51:02 am

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.

ben_g · « **Reply #181 on:** January 31, 2013, 01:30:50 pm »

Quote from: DJ_O on January 31, 2013, 03:51:02 am

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.

Xeda112358 · « **Reply #182 on:** April 21, 2013, 10:23:06 am »

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:

Code: [Select]

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.

Runer112 · « **Reply #183 on:** April 21, 2013, 10:26:59 am »

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.

Xeda112358 · « **Reply #184 on:** April 21, 2013, 02:12:09 pm »

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.

FloppusMaximus · « **Reply #185 on:** April 21, 2013, 07:01:05 pm »

Quote from: Runer112 on April 21, 2013, 10:26:59 am

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.)

Hooloovoo · « **Reply #186 on:** May 10, 2013, 06:02:34 pm »

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.

DJ Omnimaga · « **Reply #187 on:** May 11, 2013, 12:35:46 am »

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.

Quote from: Xeda112358 on January 31, 2013, 07:56:31 am

Quote from: DJ_O on January 31, 2013, 03:51:02 am
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:

Quote from: Kerm @ http://www.cemetech.net/forum/viewtopic.php?t=8870

[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.

DJ Omnimaga · « **Reply #188 on:** October 07, 2014, 12:18:35 pm »

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.

JonimusPrime · « **Reply #189 on:** April 08, 2015, 12:56:06 pm »

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

Code: [Select]

:For(x,1,1
:If blah
:
:End

and this doesn't

Code: [Select]

:For(x,1,1
:Blah
:If blah
:
:End

Jsec42 · « **Reply #190 on:** April 30, 2015, 09:22:53 pm »

~~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...

OmniGamma · « **Reply #191 on:** January 12, 2023, 12:06:28 pm »

The Equ>String bug also messes up the screen when you hover over Y2 in the Y= menu

Author Topic: TI-83+/84+ OS glitches compilation thread (all OSes) (Read 135121 times)

Xeda112358

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

ben_g

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

Xeda112358

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

Runer112

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

Xeda112358

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

FloppusMaximus

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

Hooloovoo

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

DJ Omnimaga

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

DJ Omnimaga

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

JonimusPrime

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

Jsec42

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

OmniGamma

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