I am running 2.53 MP, but I have never experienced something like this while editing a program before Doors CS 7. Also, what is BrandoW's patch? Where could I get it?
Here:
http://brandonw.net/calcstuff/84PlusOS_2.53_fixed.8xu
It basically fixes the xLib incompatibility with 2.53.
http://brandonw.net/calcstuff/84PlusOS_2.53_fixed.8xu
It basically fixes the xLib incompatibility with 2.53.
calcdude84se wrote:
Though DCS7 makes that patch unnecessary 
It does indeed. 
Kpa4941, this only happened once after a fair amount of time spend editing and running programs, correct? I'm still trying to gather enough information to be able to replicate the problem and try to find where in the TI-OS (or DCS?) the problem is occurring. 2.53MP is definitely the commonality to all users with the problem, though. 
KermMartian wrote:
calc84maniac wrote:
Well, does your parser hook use bcalls to other pages of DCS without making sure the base page table is intact?
Ooooh, you make an excellent point. It sounds to me like it would be pretty expensive to re-generate the base table every time the hook is invoked, though, especially when it's getting invoked for real(), identity(), det(), and sum() commands. Any suggestions?Probably the simplest thing would be to implement your own off-page call method (which would certainly be faster than bcall anyway) for use in these cases.
This is a very nasty bug. Do NOT even attempt to try this bug unless you've backed up EVERYTHING (yes, including archive stuff), and that you've checked that everything has been backed up 5 times.
...and with that said, this is the bug:
While I was playing around with list manipulation, regression finding, and etc. with TI Basic (everyone will get a chance to harass/optimize the code soon), it suddenly crashed with MEM (Memory full), and when I pressed 2 to see the code.... the code did show, but it was all messed up. For instance, For(A,1,200) became For(A, ClrHome. There were more severe code damage, but it's up to your imagination now.
Afterwards, I restored a backup and kept on working, taking care to not fill the memory. When I tried making another backup, it failed. After choosing each program individually, it worked. However, after attempting to extract the group, it faltered with a messed up screen. Note that it did NOT RAM clear at all. When I went to do a RAM clear, and then extracted the archive, it either said "ERR: Memory" or had nothing show up in the list of extracted files. Only after a full mem clear (archive + RAM), everything goes back to normal.
That's all - very little memory (solid, like filling lists) + running BASIC program + scroll to code = RAM and archive corruption.
To reproduce, make sure you backup backup backup first, then do the following:
1) Create a BASIC program called AARAND:
Code:
(note that this program is NOT the one that I was working on, although the functions used are in this one - this is just a testcase)
You WILL need to modify the For( loop accordingly to get it to fill up the memory around the tipping point. The goal is for it to have a MEM error at the LinReg part.
2) Run it.
3) When prompted, press 2 to see code. If the crash has occurred, tokens will be all over the place, and the code will NOT run anymore.
4) Experiment with grouping. Errors may or may not occur there, depending on impact of memory damage.
That's all! Hopefully you'll be able to catch this bug as well.
Luckily, I was able to recover my data, since the grouping function still worked, but refused to work until I wiped the entire mem. (Really lucky, since the corruption could damage the actual group function itself!)
Oh, and remember that run ASM program from HS, crash with Input( BASIC at desktop bug? It is still there and reproducible, even after an entire mem clear and OS reinstall. I'll make a video soon to show the bug, since you can't seem to reproduce that one.
BOTH bugs occur with the following specs: OS is 2.53MP, DCS 7.1 B1
...and with that said, this is the bug:
While I was playing around with list manipulation, regression finding, and etc. with TI Basic (everyone will get a chance to harass/optimize the code soon), it suddenly crashed with MEM (Memory full), and when I pressed 2 to see the code.... the code did show, but it was all messed up. For instance, For(A,1,200) became For(A, ClrHome. There were more severe code damage, but it's up to your imagination now.
Afterwards, I restored a backup and kept on working, taking care to not fill the memory. When I tried making another backup, it failed. After choosing each program individually, it worked. However, after attempting to extract the group, it faltered with a messed up screen. Note that it did NOT RAM clear at all. When I went to do a RAM clear, and then extracted the archive, it either said "ERR: Memory" or had nothing show up in the list of extracted files. Only after a full mem clear (archive + RAM), everything goes back to normal.
That's all - very little memory (solid, like filling lists) + running BASIC program + scroll to code = RAM and archive corruption.
To reproduce, make sure you backup backup backup first, then do the following:
1) Create a BASIC program called AARAND:
Code:
:ClrHome
:ClrAllLists
:Output(1,1,"Cleared data!")
:Output(1,1,"Randomizing dat:")
:For(A,1,577)
:Output(2,1," /577")
:Output(2,9,A)
:randInt(10000,20000)->L1(A)
:randInt(100000,200000)->L2(A)
:randInt(0,20000)->L3(A)
:randInt(100000,200000)->L4(A)
:End
:Output(3,1,"Linear reg...")
:LinReg(ax+b) Y1
:Output(4,1,"Quadratic reg...")
:QuadReg Y1
:Output(5,1,"Cubic reg...")
:CubicReg Y1
:Output(6,1,"Quartic reg...")
:QuartReg Y1
:Output(8,1,"Done! :)")
:Pause
:ClrHome
:Output(1,1,"")
(note that this program is NOT the one that I was working on, although the functions used are in this one - this is just a testcase)
You WILL need to modify the For( loop accordingly to get it to fill up the memory around the tipping point. The goal is for it to have a MEM error at the LinReg part.
2) Run it.
3) When prompted, press 2 to see code. If the crash has occurred, tokens will be all over the place, and the code will NOT run anymore.
4) Experiment with grouping. Errors may or may not occur there, depending on impact of memory damage.
That's all!
Hopefully you'll be able to catch this bug as well.
Luckily, I was able to recover my data, since the grouping function still worked, but refused to work until I wiped the entire mem. (Really lucky, since the corruption could damage the actual group function itself!)
Oh, and remember that run ASM program from HS, crash with Input( BASIC at desktop bug? It is still there and reproducible, even after an entire mem clear and OS reinstall. I'll make a video soon to show the bug, since you can't seem to reproduce that one.
BOTH bugs occur with the following specs: OS is 2.53MP, DCS 7.1 B1
BrandonW's Modded OS and what TI-Calc?
Sorry if some people know this, I don't and am curious.
Sorry if some people know this, I don't and am curious.
There are two types of people in the world: those who can extrapolate data from incomplete data
comicIDIOT wrote:
BrandonW's Modded OS and what TI-Calc?
Sorry if some people know this, I don't and am curious.
Sorry if some people know this, I don't and am curious.
Unmodded (from TI's website), 2.53MP "vanilla" (if you want to call it that), and I own a TI-84+ SE.
Backup backup backup!
alberthrocks wrote:
Oh, and remember that run ASM program from HS, crash with Input( BASIC at desktop bug
No, I don't. You'll have to remind me. So 2.53MP is definitely responsible for this in some way. With those steps, reproducing should be much easier. Someone please remind me to update my To-Do List tomorrow? 
alberthrocks wrote:
This is a very nasty bug. Do NOT even attempt to try this bug unless you've backed up EVERYTHING (yes, including archive stuff), and that you've checked that everything has been backed up 5 times.
...and with that said, this is the bug:
While I was playing around with list manipulation, regression finding, and etc. with TI Basic (everyone will get a chance to harass/optimize the code soon), it suddenly crashed with MEM (Memory full), and when I pressed 2 to see the code.... the code did show, but it was all messed up. For instance, For(A,1,200) became For(A, ClrHome. There were more severe code damage, but it's up to your imagination now.
Afterwards, I restored a backup and kept on working, taking care to not fill the memory. When I tried making another backup, it failed. After choosing each program individually, it worked. However, after attempting to extract the group, it faltered with a messed up screen. Note that it did NOT RAM clear at all. When I went to do a RAM clear, and then extracted the archive, it either said "ERR: Memory" or had nothing show up in the list of extracted files. Only after a full mem clear (archive + RAM), everything goes back to normal.
That's all - very little memory (solid, like filling lists) + running BASIC program + scroll to code = RAM and archive corruption.
To reproduce, make sure you backup backup backup first, then do the following:
1) Create a BASIC program called AARAND:
Code:
(note that this program is NOT the one that I was working on, although the functions used are in this one - this is just a testcase)
You WILL need to modify the For( loop accordingly to get it to fill up the memory around the tipping point. The goal is for it to have a MEM error at the LinReg part.
2) Run it.
3) When prompted, press 2 to see code. If the crash has occurred, tokens will be all over the place, and the code will NOT run anymore.
4) Experiment with grouping. Errors may or may not occur there, depending on impact of memory damage.
That's all! Hopefully you'll be able to catch this bug as well.
Luckily, I was able to recover my data, since the grouping function still worked, but refused to work until I wiped the entire mem. (Really lucky, since the corruption could damage the actual group function itself!)
Oh, and remember that run ASM program from HS, crash with Input( BASIC at desktop bug? It is still there and reproducible, even after an entire mem clear and OS reinstall. I'll make a video soon to show the bug, since you can't seem to reproduce that one.
BOTH bugs occur with the following specs: OS is 2.53MP, DCS 7.1 B1
...and with that said, this is the bug:
While I was playing around with list manipulation, regression finding, and etc. with TI Basic (everyone will get a chance to harass/optimize the code soon), it suddenly crashed with MEM (Memory full), and when I pressed 2 to see the code.... the code did show, but it was all messed up. For instance, For(A,1,200) became For(A, ClrHome. There were more severe code damage, but it's up to your imagination now.
Afterwards, I restored a backup and kept on working, taking care to not fill the memory. When I tried making another backup, it failed. After choosing each program individually, it worked. However, after attempting to extract the group, it faltered with a messed up screen. Note that it did NOT RAM clear at all. When I went to do a RAM clear, and then extracted the archive, it either said "ERR: Memory" or had nothing show up in the list of extracted files. Only after a full mem clear (archive + RAM), everything goes back to normal.
That's all - very little memory (solid, like filling lists) + running BASIC program + scroll to code = RAM and archive corruption.
To reproduce, make sure you backup backup backup first, then do the following:
1) Create a BASIC program called AARAND:
Code:
:ClrHome
:ClrAllLists
:Output(1,1,"Cleared data!")
:Output(1,1,"Randomizing dat:")
:For(A,1,577)
:Output(2,1," /577")
:Output(2,9,A)
:randInt(10000,20000)->L1(A)
:randInt(100000,200000)->L2(A)
:randInt(0,20000)->L3(A)
:randInt(100000,200000)->L4(A)
:End
:Output(3,1,"Linear reg...")
:LinReg(ax+b) Y1
:Output(4,1,"Quadratic reg...")
:QuadReg Y1
:Output(5,1,"Cubic reg...")
:CubicReg Y1
:Output(6,1,"Quartic reg...")
:QuartReg Y1
:Output(8,1,"Done! :)")
:Pause
:ClrHome
:Output(1,1,"")
(note that this program is NOT the one that I was working on, although the functions used are in this one - this is just a testcase)
You WILL need to modify the For( loop accordingly to get it to fill up the memory around the tipping point. The goal is for it to have a MEM error at the LinReg part.
2) Run it.
3) When prompted, press 2 to see code. If the crash has occurred, tokens will be all over the place, and the code will NOT run anymore.
4) Experiment with grouping. Errors may or may not occur there, depending on impact of memory damage.
That's all!
Hopefully you'll be able to catch this bug as well.
Luckily, I was able to recover my data, since the grouping function still worked, but refused to work until I wiped the entire mem. (Really lucky, since the corruption could damage the actual group function itself!)
Oh, and remember that run ASM program from HS, crash with Input( BASIC at desktop bug? It is still there and reproducible, even after an entire mem clear and OS reinstall. I'll make a video soon to show the bug, since you can't seem to reproduce that one.
BOTH bugs occur with the following specs: OS is 2.53MP, DCS 7.1 B1
Heh, funny, I thought that this was a fault on Kerm's side until I saw "MP". and I confirm this btw (I tried it on one of my school calcs after school `-`)
qazz42 wrote:
I had DCS on it. but hey, it probably happens without it too `-`
Probably. If someone with a 2.53MP calculator could make sure that the bug still happens even without Doors CS, they'd be doing me a big service towards validating that DCS is not the culprit at all, and 2.53MP is entirely to blame. 
I think I may have found a bug in DoorsCS7.
I created the following HEX file:
Code:
When I run it as Asm(prgmA it works fine (displays 5).
When i go to doors, it recognizes it as a Basic TI-OS file and gives me Syn error when running it :S
I created the following HEX file:
Code:
:AsmPrgm
:210100
:23
:23
:23
:23
:EF0745
:C9When I run it as Asm(prgmA it works fine (displays 5).
When i go to doors, it recognizes it as a Basic TI-OS file and gives me Syn error when running it :S
ScoutDavid wrote:
I think I may have found a bug in DoorsCS7.
I created the following HEX file:
Code:
When I run it as Asm(prgmA it works fine (displays 5).
When i go to doors, it recognizes it as a Basic TI-OS file and gives me Syn error when running it :S
Use AsmComp(). I created the following HEX file:
Code:
:AsmPrgm
:210100
:23
:23
:23
:23
:EF0745
:C9When I run it as Asm(prgmA it works fine (displays 5).
When i go to doors, it recognizes it as a Basic TI-OS file and gives me Syn error when running it :S
KermMartian wrote:
ScoutDavid wrote:
I think I may have found a bug in DoorsCS7.
I created the following HEX file:
Code:
When I run it as Asm(prgmA it works fine (displays 5).
When i go to doors, it recognizes it as a Basic TI-OS file and gives me Syn error when running it :S
Use AsmComp().I created the following HEX file:
Code:
:AsmPrgm
:210100
:23
:23
:23
:23
:EF0745
:C9When I run it as Asm(prgmA it works fine (displays 5).
When i go to doors, it recognizes it as a Basic TI-OS file and gives me Syn error when running it :S
Hum. Now why?
EDIT:
Code:
:AsmComp(
:210100
:23
:23
:23
:23
:EF0745
:C9is also recognized as TI-BASIC
Register to Join the Conversation
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
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