with regards to the app defragmentation code, what exactly happens that causes the data loss, and how does the calc behave after the bug has occured?
DrDnar wrote:

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.


It's not a bug in the defragmentation code itself and it's not random either; it's the fact that CopyFlashPage assumes that pages starting with FFh are empty and doesn't copy them. An easy fix is to make sure none of your app pages start with FFh, but that's not really an option in TI-Boy where I can't choose what data is in the ROM. And yes, this is not fixed in OS 4.0.
KermMartian wrote:
[FATAL] Changing the TraceStep in the Window menu incorrectly forces Xmax to change, which means that you cannot set (for example) a TraceStep of 1 while keeping a window narrower or wider than Xmax-Xmin=165. (3/8/2014

No closing parentheses around the date.
I put together a short BASIC program that will reproduce the BAD ADDRESS bug.

Steps to reproduce:
1. Reset the archive.
2. Enter the following BASIC program:
SourceCoder 3 wrote:
:999->dim(|LTS
:816->dim(|LTS2
:{0->|LTS3
:Archive |LTS
:Archive |LTS2
:Archive |LTS3
:Unarchive |LTS3

3. Execute the program. The calculator will pause while it archives the lists, and then throw the BAD ADDRESS error. You can verify that TS, TS2, and TS3 are all created successfully from the memory management menu, and verify that TS and TS2 can be unarchived, but not TS3.
4. Delete either TS or TS2. Then, force a garbage collection cycle. Note that now TS3 can be unarchived and has valid data.

Notes: The first two lists must have a total length of 1815 elements; the third can be any length. The combined length of the names of the three lists must be exactly eight bytes. The exact data in the lists is irrelevant. If you start on the first byte of a clean page, change the name of the first list to TS1; this compensates for the status byte you normally get on the first byte of the first page of a clean sector.

Screen shot of the bug in action:
Weregoose, CVSoft, and I were all able to replicate this bug on various OS versions, including the monochrome calculators. Quite concerning indeed.
Shock

I definitively hope that we won't already be grandparents when those bugs are fixed.
I'm not quite sure whether this has been mentioned, but when executing code such as this:

Code:

While 1
For(A,1,250
randint(10,18→B
TextColor(B
Text(1.A,"CEMETECH
End
End

Asides from being flashy and rainbow-colored, the moving text displays
an odd residue, and this also occurs on the TI-83 wabbitemu emulator with similar code.
Does anyone know why?
jetlego wrote:
I'm not quite sure whether this has been mentioned, but when executing code such as this:

Code:

While 1
For(A,1,250
randint(10,18→B
TextColor(B
Text(1.A,"CEMETECH
End
End

Asides from being flashy and rainbow-colored, the moving text displays
an odd residue, and this also occurs on the TI-83 wabbitemu emulator with similar code.
Does anyone know why?

Are you talking about on the left or on the right? The so-called residue on the left is because the old text is not erased when you display new text. You move over one pixel to the right, so the left-most column of the old text remains when you display new text. Try adding a space before the text. The remains of characters on the right of the screen are there because the OS doesn't clip the letters if they don't fit on-screen.
Okay! I see how that works. Thank you!

Code:
:While 1
:{0}→u(nMin)
:End

ERROR: INVALID on End.

Code:
:For(N,1,5)
:Disp N
:{0}→v(nMin)
:End

ERROR: UNDEFINED on End.

Code:
PROGRAM:MAIN
:prgmSUB
:Disp 1

Code:
PROGRAM:SUB
:{0}→w(nMin)
:Return

ERROR: INVALID on Disp.

It's a bug in the BCALL _StoOther. It doesn't remove the value from the floating-point stack when you're storing to the following variables: u(nMin), v(nMin), w(nMin), Zu(nMin), Zv(nMin), and Zw(nMin). With the FPS messed up, subprograms and loops will behave very erratically afterward.
Perhaps this isn't a bug per se, but the routines AppStartMouse, AppUpdateMouse, and AppEraseMouse are still in the OS. However, all the LCD code has been stripped out, so although they don't crash, nothing visible appears on-screen. TI could have freed up a bunch of space on page 5 by just removing the routines entirely and replacing them with a ret stub. Somebody clearly intended to fix the mouse routines, but seriously, does anybody think TI will actually ever do that?

For the curious:

Code:
mouseRow      equ 9E4Eh ; formerly 986Dh
mouseCol      equ 9E4Fh ; formerly 986Eh
_AppMouseForceKey   .equ   4E3Ah
_AppSetupMouseMemCoords   .equ   4E3Dh ;this is _AppSetupMouseMem except you pass starting coordinates in HL
_AppMoveMouse      .equ   4E40h ;this is _AppMouseForceKey and then updating coordinates
_AppStartMouse      .equ   4D2Fh
_AppStartMouseNoSetup   .equ   4D32h
_AppMouseGetKey      .equ   4D35h
_AppDispMouse      .equ   4D38h
_AppEraseMouse      .equ   4D3Bh
_AppSetupMouseMem   .equ   4D3Eh
_AppUpdateMouse      .equ   4D4Dh
_AppDispPrevMouse   .equ   4D50h ;might bring previous keypress's movement to current coordinates with flags to not display
Here's something weird:
84+SE with 2.55MP:

84+CSE:


Extended:


Looks like the small Text( font maybe mislocated a character?

Looks like all they did was mess up [ λ and μ:
I found a weird bug with lists (may just be my calc)

Code:
:For([var],[start],[end]
:L1(L2([var]
:End


some of the vars (A-Z, θ), not sure which ones, will cause it to give you an invalid dim even though it's valid.
I also believe it has anything to do with lists, not just that specific setup

Edit: I think it might have some correlation to vars that can/can't be archived, though I'm not sure
Edit2: Nope ^
Tried to replicate... something fixed itself. I had this problem earlier, and a ram clear didn't do anything to fix it.
Observe, 16aroth6:

Code:
:{5,7,6→L1
:{1,2,3,i→L2
:For(A,1,3
:L1(L2(A
:End

What seem to be purely real elements inside a complex list will still be treated as having imaginary parts, and are therefore useless for pointing to another list's elements.
Weregoose wrote:
What seem to be purely real elements inside a complex list will still be treated as having imaginary parts, and are therefore useless for pointing to another list's elements.


As far as I know, it was caused by using the letters Q and Z, not sure how many others. It was also two real lists. the problem was not the lists itself, but rather the var pointing into them.
I would have something like this:


Code:
4->dim(L1
Fill(1,L1
2->Q
Disp L1,Q
Disp L1(Q

It was the last line that would give me the Dim error
I tried it out in programs, and on the home screen. It didn't change anything.
I can't reproduce that. Can you try resetting your RAM?
16aroth6 wrote:
I had this problem earlier, and a ram clear didn't do anything to fix it.
well, I had this problem again, and It was repeatable... at least a couple of times. I ran another different program, then the one that contained the list thing, while in DCS7, and it crashed it. I ran it again from the home screen and it didn't crash...
I will try some other things to see if I can get more info on this bug. (or fix the fault within my program, though I'm about 99% sure it's not my program)
You were using DCS7? This is not the right forum for that. This is the forum for 84+ Color OS bugs.
I've been working on a Spirograph program that combines parametric graphing and StorePic, and it took me forever to track down why my graphs were not appearing after RecallPic:

[FATAL] StorePic does not store graphed functions if a Text( command was used since the last time context was switched to the graphscreen. Workaround: Disp before StorePic. (9/5/2014)
  
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, 4, 5 ... 9, 10, 11  Next
» View previous topic :: View next topic  
Page 4 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

 

Advertisement