Something something notable omission Sad
elfprince13 wrote:
Something something notable omission Sad
I didn't have a way to test OpenLib(/ExecLib( yet. I am trying to find the right people to ask about it.
Did you already include in the list:
[FIXED] Starting a BASIC program with UNARCHIVE makes Doors think that it is an ASM program and upon execution it will crash the calc.

Is/Was this a Doors problem or a problem with the OS?
That's a Doors CS (Doors CSE?) bug and should be posted in that thread, if it hasn't been already. I wasn't aware of this bug. Smile
FindOSHeaderSubField (BCALL $8075 on TI-OS 4.x) has unexpected failure behavior for unknown fields. Instead of skipping unknown fields, it returns immediately, even if the field in question is not the requested one. For example, when FindOSHeaderSubField is called to find the end-of-header (807) field, and the header contains an unknown field type, it tries to start executing the App in the data for that field instead of continuing to actually find the 807 field.
TRIVIAL, even useful sometimes:


A list index can be used as the variable in a For( loop. When this is done, the loop will operate and exit normally, but the list will not be affected. For instance, this program

:Disp "X
:Disp L1

will output:


Found it by accident-ish; noticed that in a program I used

and figured it'd be fine to use L1(1) as the loop variable. Nope.

This throws an ERR:UNDEFINED when it reaches the End statement on the monochrome calculators as if you had DelVar'd the loop variable.
How about this? #weird:

[FATAL] Entering the stat wizards during an Input or Prompt, then breaking with ON will eventually cause the calculator to reset.

Tested on 4.2, although it appears on any OS version (monochrome or color) that uses 'stat wizards' (the custom input forms for commands like seq( or the Distr stuff), although it behaves a bit differently. It also behaves differently when DCSE is open, but again, it still resets the calculator eventually.


1. Run a BASIC program that has an Input or Prompt command somewhere in it.

2. When the program gets to the Input/Prompt, find one of the commands that uses a Stat Wizard to input its data (stat wizards must be enabled in the MODE menu, of course). These include seq( [2nd->List->Ops->option 5], the rand*( commands [Math->Prob->Options 5 through 8] or anything in the Distr menu [2nd->Vars->anything].

3. Press [ON].
- 3a. If you have DCSE installed, it could do any number of things; show the splash screen (sometimes corrupted) and reset when you press Enter, reset right away, fill the screen with random garbage and then reset, freeze the calc requiring you to manually reset... the list goes on. Ignore everything below, since no matter what your calc will reset here if you have DCSE.
- 3b. If you don't have DCSE installed, though (or are on a monochrome calc, I haven't tested with DCS on monochrome), it'll give you the ERROR:BREAK screen. On the CSE, it'll display 'A' as a description (probably a shortened version of 'Action is Stopped', the normal break message). You'll have two options, as normal, being Quit and Goto.

4a. If you press Goto, your calculator will freeze, requiring you to either press the reset button or take out the batteries (depending on your calc).
4b. If you press Quit, it'll take you to a corrupted-ish version of the homescreen (and the stat wizard menu you broke from) with the cursor in the middle of the screen. You can't do anything here except press 2nd-Quit, or Clear; on the monochrome calc, doing this will reset your calc immediately. On the CSE, this will either do that or fill the screen with random characters and reset when it reaches the bottom.

Two CSE gifs:

"Nice" - confirmed on the CE as well on both 5.0.0 and 5.0.1 (84+CE, but probably the 83PCE too), but the behaviour isn't exactly the same. This has to be reported and *must* be fixed....
Edit: same on the 83PCE (on Smartview CE, since I don't have an actual 83PCE yet), unsurprisingly.
I'm currently reporting the bug to TI directly (linking the post above and this one)

Anyway, here's what I have:

I still get the same error description ("A"), but :

- If I choose "Quit", I get stuck on the home screen where I can't type anything, so I have to press [on] or [clear]. Then, the "ERROR: ARCHIVED" screen appears. If I choose "Quit", it goes back to the same "error archived" screen. And If I choose "Goto", the calc freezes and I can only reset.

- If I choose "Goto", the calc gets in a pretty bad state that can only end up with a reset AFAICS (you can type things and all, but you're still kind of in the middle of the stat wizard, and glitches appear everywhere... then at some point it will just freak out and fill the screen with black etc. But if you do reach the "Paste" thing and hit Enter, the calc will enter an endless loop (not frozen...) and you'll have to reset.)

Some screenshots:

PS: If I try to turn off the calc while in the error screens, it won't turn back on, a reset is needed.

PS2: USB connectivity may not work during all these things...
So I just ran into a funny bug on the CE (which I just got): When you perform a full memory reset it says RAM Cleared instead of Mem Cleared. Not that it's anywhere close to problematic, but I thought that was a bit weird... Shock
I found an error in the catalog for the Repeat token. It says "commands(cond=true)", but Repeat actually runs commands while the condition is false. Here is a gif of that:

maybe "Repeat until true"?
No, thats right.
Essentially, if the condition turns true, the loop stops.


Reapeat while getkey is not true // getkey is condition
keypress //getkey is true now
other commands
No, I think it is a bug. If you look at the catalog help for both While and Repeat, you will see that they say the exact same thing except for a different token. Look at the screenshots:

With While, you can != and =, so I guess its half right for while? But, anyways, it makes sense.
Based on that, readroof is correct. Repeat loops only loop if the condition is false. Repeat 0 and While 1 do exactly the same thing, and even the OS routines for these imply that. Oh well. Probably just another copy/paste mistake that isn't too important for functionality, although a help menu that doesn't help is somewhat ironic.
The monochrome calculators had a fast circle routine that could be triggered by supplying the Circle( command with a complex list (usually {i}) as its fourth argument.
Trying that throws an ERROR: DATA TYPE on the CSE (since it now expects a color code for the fourth argument), but the calculator apparently has and can use the routine.

1. Open Doors CSE 8.1.3. [I'm not actually sure if this post should be in this thread, since DCSE triggers it]
1a. Make sure you have Improve BASIC Editor checked in the Options menu.
2. From within DCSE, make a new program. Name it anything.
3. Type anything you want in it, just as long as it won't throw an error when run and won't require breaking with ON to quit.
4. Run the new program. When it's finished running, quit DCSE.
5. Press [GRAPH] to bring up the graphscreen.
6. Open the Draw menu and select option 9 [Circle(]
7. Press ENTER, move the cursor a bit with the arrow keys, and press ENTER again.

It'll be using the fast circle routine, drawing each fourth of the circle simultaneously instead of going all around the circle like usual.
The {i} indeed no longer triggers the fast circle routine, but I believe that Doors CSE sets the fast circle flag for TI-BASIC programs anyway. To double-check this, please try creating a program that calls Circle() through the normal editor, then running it with and without Doors CSE. Does it render as a fast circle?
M. I. Wright wrote:
The monochrome calculators had a fast circle routine that could be triggered by supplying the Circle( command with a complex list (usually {i}) as its fourth argument.
Trying that throws an ERROR: DATA TYPE on the CSE (since it now expects a color code for the fourth argument), but the calculator apparently has and can use the routine.

Although a shame, this is not actually a bug, as the capability was undocumented by TI so should not be expected to work in future versions.
On the CE, you can flag the Menu( bug as FIXED, starting with OS 5.1 Smile (Source).
It'll be interesting to see if they have fixed other things as well.

I don't know if there are going to be any updates for the 84+CSE though.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3 ... 5, 6, 7 ... 9, 10, 11  Next
» View previous topic :: View next topic  
Page 6 of 11
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum