Omnimaga
Calculator Community => TI Calculators => TI-BASIC => Topic started by: ACagliano on July 01, 2010, 08:31:20 pm
-
I am asking this just to see what the general consensus is amongst you guys. Will, any program, over some time of usage on a system (with or without interference from other programs), eventually become unstable. If so, why?
-
Probably not, unless you somehow corrupted your ROM and it now spews out random data to random places :(
I've had problems copying ASM programs (using DCS, for example), where some of the hex is replaced by BASIC tokens, and if it's copied enough times, there would be a good chance it could start a crash. I've also had tokens getting replaced randomly by Axe when I tried compiling while the source was in Archive. According to Quigibo, it's a bug that's been fixed since 0.3.0 (I haven't tried the newer versions yet).
Without any outside interference, I don't see how a program could get "unstable", since the only way for that to happen is if its data is corrupted. Besides, "unstable" BASIC programs (seeing the name of the board in which you posted this topic) don't really do much except break and display some arbitrary ERR: message to help you fix the program.
EDIT: Is there something wrong with your calculator, or are you just asking this out of curiosity?
-
No, just out of curiousity and slightly out of experience. I have had a few issues with a program that I designed over a year ago, called EMPFORM.8xp. Then, I let a year go by. When I returned to it a year later, it randomly gave me an Err: Domain, that I couldn't pinpoint.
-
It could be that some of the code was dependent on settings in the calc somehow, like going from radians to degrees with trig functions or something of the sort. I don't know what else would have changed if you did not alter the code and the calc did not receive some interference from another program on it.
-
No. The program was tested extensively on my calc after I made it. Another program probably interfered. I'm scanning the code, line by line, to figure it out.
-
Some corruption might have occured. It is usually rare, but it can happen. I think it's worse with group files, though. I ungrouped Mana Force 2 to test it a year later once and got an ERR:SYNTAX in the code
-
Groups are strangely susceptible to corruption. No clue why. I'd like to blame it on TI's crappy code :P
-
How is group data organized, anyway? I read all the way through 28D, but it didn't say anything about it.
Groups are strangely susceptible to corruption. No clue why. I'd like to blame it on TI's crappy code :P
Yeah, I've lost several projects because of a stupid ERR:VERSION. For some reason, groups seemed less stable with MOS installed.
-
It used to be much worse with older OSes, though. It happened with about half of the group files.
-
Err:VERSION is not much of a problem, there exists software like GroupTool that is capable of ungrouping those.
I once had a detailed document about group structure, but I don't know where I found it.
-
Be carefull with grouptool, I once had it corrupt an entire group of Serenity progress with token FF
-
I don't know if it counts but, back when Calc84Maniac was overloading us with projects and demos, I was one of the persons testing them. I happened to have a newer calc than most of the other people and somehow during the test of one of his games my calc got corrupted. He did give me a few lines of asm( code and my calc worked again, altho slower. As example, Chips Challenges' greyscale flickers a bit and works obviously slower than on other calcs. It wasn't Chip's that corrupted my calc though, can't really remember what that project was.
Damn it has been a long time.
-
I've actually had a program error on a line that it shouldn't, I then copied the program down onto paper and then re-entered it into my calc and it worked, I compared the two, and there was no change, it just seems that somehow the token was corrupt or something x.x
-
Can CalcSys fix ERR:VERSION problems? If so, how?
-
I remember I once had a problem when transfering groups to a calculator, are you tranfering as a group or as a program? Because it might help to ungroup them on your computer if that is the case
-
If ungrouping with TI-Connect fails, you can always try with SourceCoder too, altough when ungrouping, I don't know if SC lets you save your program in 8xp form.
-
Be carefull with grouptool, I once had it corrupt an entire group of Serenity progress with token FF
From my experience, DO NOT use Group Tool. The one time I used it, it killed my calc as I did a Mem Clear to fix my problem. It really messed with the VAT and other stuff. :(
-
Be carefull with grouptool, I once had it corrupt an entire group of Serenity progress with token FF
From my experience, DO NOT use Group Tool. The one time I used it, it killed my calc as I did a Mem Clear to fix my problem. It really messed with the VAT and other stuff. :(
The worst GroupTool has done to my calc is reset my lower case flag.
But I didn't use it that much, because I found with the 83+'s limited memory it was easier to back stuff up on my computer than create groups.
-
GroupTool never caused me any trouble. but, it seems that Celtic III has made it obsolete.
-
The worst GroupTool has done to my calc is reset my lower case flag.
Do you mean that the calc cursor got locked down to lowercase ALPHA, not letting you turning it off? I remember back in the days it happened to some people at school and I always wondered how to fix it without forcing a RAM clear
-
The worst GroupTool has done to my calc is reset my lower case flag.
Do you mean that the calc cursor got locked down to lowercase ALPHA, not letting you turning it off? I remember back in the days it happened to some people at school and I always wondered how to fix it without forcing a RAM clear
No, I mean the system flag that defines whether lower case is on or off was reset, disabling lower case on the calculator. It can easily be reset using CalcSys or an assembly program that changes the flag- it was just annoying to have to do each time I used GroupTool.
-
Oh ok. At least I am glad it is not what I said. That one was annoying because you couldn't access most menus anymore since it wouldn't let you go out of ALPHA mode anymore
-
* calcdude goes searching for the right flag combos that cause this :P (lol j/k)
That must be annoying, DJ. Anyway, I don't see why GroupTool would reset that flag... weird. (I can see TI doing it, but not the author, who I cannot remember)
-
I only saw this twice, on other ppl calc. I never got able to recreate this.
-
*calcdude goes searching for the right flag combos that cause this :P (lol j/k)
I actually did that once on purpose on my own calculator (probably stupid of me). I think it was fixed simply by pulling a battery out, though.
-
Late reaction @DJ: It's possible to fix ERR:VERSION problems with calcsys in normal programs, not in groups. There is a byte in the VAT (I refer to day 21 of asmin28 days, since I don't remember the offset), that is called the version byte and it is never used. Sometimes, it ends up as $ff. You simply have to correct it to a zero, and then everything should work fine (transferring etc.).
-
Aaaah ok I see. Unfortunately the only ERR:VERSIONs I ever got were in groups, though, so it wouldn't help me much if it happened :(
Thanks, though.
-
so I hear that you can reset bits (make them 0) on the archive, does this mean you could set the byte FF to 00 and fix it?
-
How are groups stored on the calculator anyway? 28D seemed to skip right past them :P
-
I was the one that wrote GroupTool, many years ago. It's poorly coded and if I had the time, I'd rewrite it. It probably sets or resets that lowercase flag without regard to whatever it was before launching it.
Groups are complicated to explain (it's also been a really long time since I looked at them). If I remember correctly, they're a series of VAT entries and variable data, one after the other. You'd just have to pick one apart and look at it in a hex editor.
-
The result of my instability was accidentally launching Celtic3 a few times, without regard to what was stored in Str0 or 9.
-
What does Str0 or 9 do in particular with Celtic III launching? Is tehre stuff stored in them upon launch/install?
-
maybe it was one of the super early program based beta CelticIII's? o.O
-
idk, it's weird x.x
Maybe Iambian could answer, since he made CIII after all :P
-
It's probably the early program version. If you ran CIII RAM version without regard for whatever the inputs are, you can most certainly screw up CIII RAM. I forget which string it was, but one of them is for input. And the Ans? I think that's also input. If you're messing that up, you might run into some unexpected problems.
I'm sorry if that answer's a bit sketchy. Even though I made that program, it's been *years* since I seriously looked at that program. My development is focused on the app version of CIII, along with E:SoR (not relevant to this discussion).
Now... if you're talking about the APP version of CIII, none of the strings or real variables will have anything to do with it unless you're feeding in faulty inputs to CIII.