It appears that TI has added two new variable types: improper fractions and mixed fractions (complex fractions of any type aren't supported). It seems they were designed to allow fraction representations to be preserved in variables and even propagate through expressions so that the answer will be represented in the same format if possible. They are stored in the same fashion as a real float, except the type byte is 18h for improper fractions and 19h for mixed fractions. Like complex numbers, this type value is reflected in the first ("sign") byte of the float so bits 3 and 4 are set, and bit 0 as well for mixed fractions.
With two new types of numbers introduced to this well-featured calculator, it's not unsurprising that there would be a few teething issues. I've discovered some so far, and I suspect there may be more that I simply haven't run into yet.
▪ Mixed fraction types do not propagate through just about anything, and get converted to improper fractions.
▪ When parsing lists entered by users, if any element in the list contains a typed-out decimal point, all elements in the list are forced to be floating type.
▪ The Horizontal and Vertical commands do not accept fraction type arguments and throw a data type error.
▪ The conj( and real( commands do not let fraction types propagate through and always return float types.
[ANNOYING] Sometimes when performing a ram clear of the calculator, the group variables are hidden. The fix is to press the reset button.
ohernandez wrote:
[ANNOYING] Sometimes when performing a ram clear of the calculator, the group variables are hidden. The fix is to press the reset button.
Have you found anything that triggers this particular bug? Or does it seem to happen on random RAM Clears? Are these RAM Clears triggered by ASM bugs, or from the Memory menu?
This bug sometimes happens when I do a RAM clear from the memory menu. I'm not sure what triggers it.
[ANNOYING]When graphing, it takes about 5 seconds for the graph to show up on a zStandard graphscreen
Only found this because a freind let me 'borrow' his to look at and make a game for.
Was trying to transfer Pic1 from my CSE to my PC, and that's the issue it gives me at about 70% completed.
[ANNOYING] TI-Connect marks TI-84+CSE Apps with the extension .8xk as "Incompatible" regardless of the contents of the 801 app header field, and apps with .8ck as compatible even if the 801 header field contains the 0104 (non-color) key. (9/14/2013)
Under some circumstances, when the screen is scrolled, a pixel is drawn where it shouldn't be. (Examples: a lowercase "w" in an even-numbered column will be drawn incorrectly when scrolling down, and a slash in an even column will be drawn incorrectly when scrolling up.)
Patch: at F0:42FF and at F0:499A, change 3C to 00.
FloppusMaximus wrote:
Under some circumstances, when the screen is scrolled, a pixel is drawn where it shouldn't be. (Examples: a lowercase "w" in an even-numbered column will be drawn incorrectly when scrolling down, and a slash in an even column will be drawn incorrectly when scrolling up.)
Patch: at F0:42FF and at F0:499A, change 3C to 00.
This sounds like a good thing to pass along to TI.
Indeed, though they tend to like letting annoying bugs unfixed despite knowledgeable community members pointing out the fix to them...
Among others BrandonW tried to help, but TI didn't take advantage of it... let alone take advantage of PolyPatch84.
Lionel Debroux wrote:
Indeed, though they tend to like letting annoying bugs unfixed despite knowledgeable community members pointing out the fix to them...
Among others BrandonW tried to help, but TI didn't take advantage of it... let alone take advantage of PolyPatch84.
They still haven't dealt with the lowercase letter problem for OpenLib(, although I mentioned it to them and hopefully 4.1 or 4.0.x will address it.
Have you asked them if they are even working on an OS update? It'd be cool if their programmers could at least keep us updated on such things.
tifreak8x wrote:
Have you asked them if they are even working on an OS update? It'd be cool if their programmers could at least keep us updated on such things.
I actually haven't; I'll do so. I know that they backed off the App development they had planned, so I wouldn't be stunned if the next OS version was a long way off.
*bump*
[FATAL] The OS 4.0 code contains a notable bug. The ldir at 01:668D incorrectly copies $104 bytes rather than $103 bytes to clear textShadow, in the process trashing textShadowCur. In certain context-switching cases (namely changing between Classic and MathPrint modes), this can cause a crash. In practice, this bug is masked by the homescreen PutAway vectors. Many thanks to BrandonW for helping me find this. (10/14/2013)
Not really much of an issue in general, but I noticed some issues with the Flash APPs menu: If you have two apps with the same name, but different casing (for example, one of the two IViewer apps I had was in all-caps), they'll both appear in the memory manager, but not in the APPS menu. What will happen instead in the APPS menu is that one of your other app will appear twice and if you try to run an APP after scrolling way down from the top of the menu then going back up with the cursor, the wrong APP will be ran.
Here's a really fun one that you can try at home!
1) Open the application menu.
2) Close the application menu.
3) Open the Y= screen.
4) Open the color and line properties dialog for an equation.
5) Press ALPHA + some letter.
The calculator will then act as if you had pressed ALPHA + that letter in the program menu and print your list of programs starting from that letter, and you'll end up in a weird glitched state where the calculator partially thinks it's in the program menu, the application menu, and the color and line properties dialog all at once. From here, you can press ALPHA + a letter again to reprint the list of programs from that menu, you can press a number that would correspond to an application in the application menu to get a validation error, or most fun, you can navigate the glitched dialog. You can scroll up and down through an infinite number number of scrollboxes which sometimes move around and sometimes cause pretty sweet graphical glitches. Pressing left and right at these scrollboxes can give you interesting results. Fun ones include one that lets you scroll through the entire character set, and one that lets you scroll through a set of tokens displayed with bizarre foreground and background colors.
Here's a nice sample of what I managed to get my screen to look like after a minute or two of playing with it:
THis appears to happen when drawing stuff on the graph screen too!
1) Open the graph screen
2) Select a drawing command, such as Line()
3) Press APPS
4) Hit CLEAR
5) Press F5 to open the Line style box
6) Press ALPHA then a letter, then prepare for glitchiness.
New bug discovered at T^3 2014: If you set the TraceStep, then the OS changes the Xmax to correspond, which should not happen. The Xmax should only get adjusted when deltaX is modified, not TraceStep. The teachers here were rather baffled by it, and I promised to pass it along to the Powers that Be if possible.
OS 4.2 for 84+CSE shows that TI cares more about PTT mode than about fixing bugs...
Ever since OS 1.00, there's been a bug in the unarchive code that causes ERR:BAD ADDRESS if a variable is archived onto a page with 11-18 bytes left, depending on the name length. (thepenguin77 isolated the cause of this bug, in
this Omnimaga topic) In OS 4.0, the faulty code lies at FC:6699:
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
B8 cp b
28xx jr z, somewhere
30xx jr nc, error
010040 ld bc, $4000
ED42 sbc hl, bc
38xx jr c, error
thepenguin77's description: Quote:
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.
calc84maniac also claims there's a bug in the app defragmentation code in the B&W calcs, which randomly corrupts apps; there's no reason to believe TI fixed the bug in OS4.0.
Both these bugs must be marked as SUPER FATAL because they cause permanent data loss. EDIT: Actually, you can fix the BAD ADDRESS issue by archiving, then unarchiving (or deleting) a variable that appears earlier on the sector, and then forcing a garbage collection cycle. This will move the variable, so it doesn't straddle page boundaries.