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

0 Members and 1 Guest are viewing this topic.

#### Xeda112358

• they/them
• Moderator
• LV12 Extreme Poster (Next: 5000)
• Posts: 4667
• Rating: +718/-6
• Calc-u-lator, do doo doo do do do.
##### Re: TI-83+/84+ OS glitches compilation thread (all OSes)
« Reply #180 on: January 31, 2013, 07:56:31 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

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

• Hey cool I can set a custom title now :)
• LV9 Veteran (Next: 1337)
• Posts: 1002
• Rating: +125/-4
• Asm noob
##### Re: TI-83+/84+ OS glitches compilation thread (all OSes)
« Reply #181 on: January 31, 2013, 01:30:50 pm »
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.
My projects
- The Lost Survivors (Unreal Engine) ACTIVE [GameCommandoSquad main project]
- Oxo, with single-calc multiplayer and AI (axe) RELEASED (screenshot) (topic)
- An android version of oxo (java)  ACTIVE
- A 3D collision detection library (axe) RELEASED! (topic)(screenshot)(more recent screenshot)(screenshot of it being used in a tilemapper)
Spoiler For inactive:
- A first person shooter with a polygon-based 3d engine. (z80, will probably be recoded in axe using GLib) ON HOLD (screenshot)
- A java MORPG. (pc) DEEP COMA(read more)(screenshot)
- a minecraft game in axe DEAD (source code available)
- a 3D racing game (axe) ON HOLD (outdated screenshot of asm version)

This signature was last updated on 20/04/2015 and may be outdated

#### Xeda112358

• they/them
• Moderator
• LV12 Extreme Poster (Next: 5000)
• Posts: 4667
• Rating: +718/-6
• Calc-u-lator, do doo doo do do do.
##### Re: TI-83+/84+ OS glitches compilation thread (all OSes)
« 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

• Moderator
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: TI-83+/84+ OS glitches compilation thread (all OSes)
« 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.
« Last Edit: April 21, 2013, 10:29:37 am by Runer112 »

#### Xeda112358

• they/them
• Moderator
• LV12 Extreme Poster (Next: 5000)
• Posts: 4667
• Rating: +718/-6
• Calc-u-lator, do doo doo do do do.
##### Re: TI-83+/84+ OS glitches compilation thread (all OSes)
« 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

• Posts: 290
• Rating: +57/-5
##### Re: TI-83+/84+ OS glitches compilation thread (all OSes)
« Reply #185 on: April 21, 2013, 07:01:05 pm »
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

• Posts: 225
• Rating: +22/-0
##### Re: TI-83+/84+ OS glitches compilation thread (all OSes)
« 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.
"My world is Black & White. But if I blink fast enough, I see it in Grayscale." -tr1p1ea
Spoiler For some of the calcs I own:

(actually I have quite a few more than this, but I don't feel like making bars for them all.)

#### DJ Omnimaga

• Former TI programmer
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55872
• Rating: +3151/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: TI-83+/84+ OS glitches compilation thread (all OSes)
« 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.

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.

« Last Edit: May 11, 2013, 12:46:20 am by DJ Omnimaga »

#### DJ Omnimaga

• Former TI programmer
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55872
• Rating: +3151/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: TI-83+/84+ OS glitches compilation thread (all OSes)
« 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

• LV6 Super Member (Next: 500)
• Posts: 389
• Rating: +25/-5
##### Re: TI-83+/84+ OS glitches compilation thread (all OSes)
« 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::Endand this doesn't
Code: [Select]
:For(x,1,1:Blah:If blah::End

"Always code as if the person who will maintain your code is a maniac serial killer that knows where you live" -Unknown

"If you've done something right no one will know that you've done anything at all" -Futurama

"Have a nice day, or not, the choice is yours." Tom Steiner

#### Jsec42

• LV2 Member (Next: 40)
• Posts: 20
• Rating: +0/-0
##### Re: TI-83+/84+ OS glitches compilation thread (all OSes)
« 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...
« Last Edit: September 02, 2015, 08:06:02 am by Jsec42 »

Computer Science is not the only science that matters, but it's definitely the most interesting.