Omnimaga
Calculator Community => TI Calculators => General Calculator Help => Topic started by: Darl181 on January 09, 2012, 02:39:41 pm
-
I've been having multiple problems with the garbageCollect thing, and recently it's gotten bad enough to corrupt the OS to the point where changing contrast causes a crash.
The routine itself runs normally afaict, but afterwards it writes some junk tokens to the homescreen and crashes, more often then not corrupting the vat, flash and etc.
So, a few questions...
- has anyone else had similar problems?
- Where is the garbageCollect routine? (boot or OS)
- If it's in the OS, why haven't OS re-sends fixed it?
- If it's in the boot, will anything fix it short of a reflash?
- Can it be fixed? Or replaced with a hook or something?
- in the VAT, is there supposed to be an appvar named (http://tibasicdev.wikidot.com/local--files/83lgfont/0Fh_LhexF.gif)(http://tibasicdev.wikidot.com/local--files/83lgfont/D0h_Lblock.gif)(http://tibasicdev.wikidot.com/local--files/83lgfont/D0h_Lblock.gif)(http://tibasicdev.wikidot.com/local--files/83lgfont/D0h_Lblock.gif)(http://tibasicdev.wikidot.com/local--files/83lgfont/27h_Lapostrophe.gif)(http://tibasicdev.wikidot.com/local--files/83lgfont/D0h_Lblock.gif) that doesn't appear outside of Calcsys, or is this a problem as well?
-
Did you recently run any ASM or APP on your calc? This is most likely the cause of the problem, assuming there was any bad code in there. Otherwise it must be due to your recurrent missing archive pages calculator problem (your 84+ only had 10 pages, right?)
-
Hmm, if it was a computer, I'd say that appvar name looks pretty suggestive, but if you have known issues with your flash, it could just be getting worse :/
-
I think it is likely that the problem isn't GarbageCollect, but running the GC causes a crash because of something else that has been plaguing your calculator for so long. Hasn't your calc been having multiple problems in the past?
-
- in the VAT, is there supposed to be an appvar named (http://tibasicdev.wikidot.com/local--files/83lgfont/0Fh_LhexF.gif)(http://tibasicdev.wikidot.com/local--files/83lgfont/D0h_Lblock.gif)(http://tibasicdev.wikidot.com/local--files/83lgfont/D0h_Lblock.gif)(http://tibasicdev.wikidot.com/local--files/83lgfont/D0h_Lblock.gif)(http://tibasicdev.wikidot.com/local--files/83lgfont/27h_Lapostrophe.gif)(http://tibasicdev.wikidot.com/local--files/83lgfont/D0h_Lblock.gif) that doesn't appear outside of Calcsys, or is this a problem as well?
That's zStart, I mentioned it in the readme, but you know... That's where I store information like the location of the font and the page omnicalc is on. It will always be first in the vat no matter how hard you try to move it. (Unless of course you disable those features of zStart.)
- Where is the garbageCollect routine? (boot or OS)
It's in the OS. It's probably not corrupted.
- Can it be fixed? Or replaced with a hook or something?
My guess is that your archive is corrupted, run this (http://www.ticalc.org/archives/files/fileinfo/443/44349.html). (It clears ram, but, that's not really a problem for you at this point ;D)
-
I have the atchive cleaner and use it something like once a week :P
(Tho I got it from here (http://ourl.ca/12245/234994), is the ticalc.org version different?)
Anyways immediately after whatever the problem is occured, I ran it and the problem remained.
I've been having these issues for a while, maybe since around axe 1.0? Maybe I should do a full backup or something and clear mem?
(Also I guess it is a long-standing thing if it's in the OS, it's persisted throughout multiple OS re-sends (even 2.55 0.o))
Edit: So that zStart appvar thing was in the readme? Odd, I have it printed out and in plastic sleeves and still don't remember it XD
Post-Edit: just looked through again..it mentions an appvar but doesn't name it.
Edit2: ok so..
84 pbe
S-0305B (full 128k ram)
OS 2.43
Installed apps: Axe 111, zStart, and Omnicalc through zStart. Also MSD8X's and MirageOS's hooks
Edit3: @DJ I eventually got around that, though I don't remember exactly how. Something about a swap sector iirc.
-
Have you ever done a full reset of your calculator? ie: backup anything important and then clear all memory, RAM and ROM and resend the OS?
-
About once every six months or so, when things start to get really bad, meaning either things are getting corrupted or there's too much stuff in the archive and might as well clear all while I'm at it. :P
Should I do that now, and see if the problem reoccurs afterwards?
-
I think so. If you backup everything important, it can't hurt your calc, and if the problem still persists, that will narrow down the possibilities greatly. It would also probably help to have a fresh calc with no hooks or asm programs that could have messed up something to test on.
-
Have you tried making and deleting an app. For some reason, the defrag it causes tends to fix the problems i have.
-
Ok I feel smart right now...I put in another set of batteries and the issues disappeared.
Does TIOS have problems detecting the battery level of NiMH's, by any chance? It might just be writing to the archive running on batteries it doesn't know are too low XD
-
I'm not sure, but things do tend to act wonky sometimes when the batteries are low. I know (pc) linking fails or acts really strangely with low battery levels.
-
:(
Just happened again, using batteries that were recharged less than 48 hours ago. Those same batteries, just before the recharging, had gone strong in the Prizm for a couple weeks before running down. I guess rule out the batteries? I have multimeter at home, and can check how the batts are doing...
I'm guessing the part of the OS or whatever (hopefully not boot code) it affects is the startup--last time, the screen wouldn't initialize and turn up the contrast. This time it's the same, except you can barely see the stuff on the screen.
Edit: I just put back in the battery that I took out of it ~10 minutes ago, and it's behaving. So I guess removing a battery for a bit fixes it? (Makes sense, last time it was "fixed" after there hadn't been any aaa's in it for a whole night, this time just one for >10 minutes.)
Btw I ran the archive cleaner immediately after and it still had the problems.
-
NiMH, if anything, runs more stably, as they stick to a higher voltage (not overall, they do run a bit lower than alkalines at full charge) until you get to near-dead battery levels. Alkalines gradually decrease their voltage output as they run down in a linear fashion, whereas NiMH have a very small slope that suddenly drops. The battery will think it's full enough until the last few minutes of running, but not so extremely as to cause problems.
-
The thing is, these NiMHes seem to be perfectly healthy when it comes to charge. On top of that I just recharged them less than two days ago.
-
Disable zStart and try doing stuff. I know sometimes when I reinstall it (from computer) the calculator will sometimes crash.
If this fixes it, I believe there are two problems:
1. TI doesn't update the hook pointers perfectly (I think this is an issue already, but I've never looked into it)
2. You have a garbage app somewhere, check Calcsys for a gap in the app numbers.
-
Ok I feel smart right now...I put in another set of batteries and the issues disappeared.
Does TIOS have problems detecting the battery level of NiMH's, by any chance?
Yes and no. The OS tends to complain about low batteries before the NiMH batteries are actually nearing depletion because NiMH batteries operate at a lower voltage, nominally 1.2 V, which means four of them give a nominal 4.8 V. This is a problem because the original TI-83+ was designed to run on 5.0 V and that's what the OS checks for. However, the TI-84+ family is designed around 3.3 V logic, so the actual hardware will run just fine on 4.8 V; the OS just doesn't know this. In fact, if you write your own operating system or patch the OS, you can see that the calculator will indeed run just fine on less than four volts, including archiving and unarchiving &c. The only thing that won't work is the USB driver, because part of the USB spec requires a 5.0 V bus. Unfortunately, random parts of the OS code check the current voltage and may silently abort if the voltage is low, so you can still get strange behavior.
tl;dr: NiMH batteries supply a lower voltage than what the OS expects. The hardware itself works fine on that voltage, but the OS doesn't know that, so it tends to give up (and fail silently) when it shouldn't.
Also, if you want, thepenguin77 or I could throw together a program that does a true full memory clear (except for the boot code, of course).
-
Hm, so maybe during a GarbageCollect it 'silently fails' to write something and doesn't notify?
-
No, thepenguin's archive cleaner would fix that. Though it might be worth it to check for a garbage app.
Also, the full memory clear I suggested above can be done using the boot code self-test: remove a battery, hold MODE, replace the battery, and turn the calculator on.
-
So, this mode+batt self-test is different from the mode, alpha+s self-test?
-
So, this mode+batt self-test is different from the mode, alpha+s self-test?
Extremely. The normal self-test won't erase your operating system, for example. The only function of the boot's self-test is to ensure the flash chip is functional. It does not, however, test the certificate or boot code for integrity.
By the way, the boot-code self-test loops forever. Also, after performing it and reinstalling your OS, you'll appear to have an extra 64 K of archive space because there is no swap sector. Do 2nd+Mem>Reset>All Memory before loading any apps or programs or else the next the garbage collect will fail.
-
I haven't tried the full-erase yet, but I just got the problem again and this time looked at it more closely.
- The problem is always the same: the OS can't seem to change the contrast
- When turning on the calc, the LCD is at minimum contrast. zStart app reports that it's set to something like 63.
- Trying to turn up contrast prints a junk token where the number normally appears (0D (http://tibasicdev.wikidot.com/local--files/83lgfont/D0h_Lblock.gif)) and achieves nothing.
- Trying to run the contrast down seems to cut almost all power to the LCD, maybe minimum contrast? It looks like it's printing something here as well.
- Asm programs can change the contrast successfully, such as an axe program containing Shade()
- When the contrast is turned down/off, and fixed by an asm program, the junk token changes.
- While clearing RAM, the contrast is set properly. It doesn't fix the glitch tho. However once the calc is turned off this is apparently lost, and on the next startup it's low again.
- The On+Del trick sets the contrast right, albeit clearing ram. Haven't tried OS self-test.
- At times, it seems to be fixed, when turning the calc on/off works properly. However, installing, or maybe just running, an app (maybe any app?) tends to break it again.
- I looked at calcsys for a bit, the App vat seems to have the numbers going in sequential order, starting with Axe on page 62 and ending with Calcsys on page 69.
Edit: after uninstalling zStart and clearing ram, it's back to normal. When I re-install zStart the glitch returns.
Maybe I ought to re-send that one app, see if it works?
Edit2: unchecked everything and installed, and it' working properly. Now to find the culprit setting..
Post-edit: It doesn't seem to be any setting..installing any part of it seems to cause problems. Even running the app seems to cause the err...
What's weird is that it only started doing this recently, after something, maybe or maybe not garbageCollect, messed up multiple times.
Edit3: zStart 1.3.005 btw
-
That's funny, Darl; I have a similar glitch with zStart messing with the contrast in a method similar to how you mention it, only less seriously. For me, here is what's still true: (bolded words changed from the original)
- When turning on the calc, the LCD is infrequently at minimum contrast. zStart app reports that it's set to something like 48.
- Trying to run the contrast down seems to cut almost all power to the LCD, maybe minimum contrast?
- While clearing RAM, the contrast is set properly. It doesn't fix the glitch tho. However once the calc is turned off this is apparently lost, and on the startup it's infrequently low again.
Edit: after uninstalling zStart and clearing ram, it's back to normal. When I re-install zStart the glitch returns.
Maybe I ought to re-send that one app, see if it works?
Edit2: unchecked everything and installed, and it appears to work properly for a while and then resorts back to its old habits.
It's something zStart related.
-
In the meantime, I've been able to "fix" the problem by having an axe program run on startup, the source of which is just Shade(48) ;D
(just need to not turn it down accidentally :P)
Edit. Uninstalled everything in zStart, uninstalled zStart itself, deleted the appvar, cleared ram and reinstalled stuff. It's been working properly for ~20 minutes now :D
-
This is really strange. It must be some bug running around that has gone unnoticed or has been introduced recently. There must be something in Zstart that is triggering the contrast to be set to minimum on certain conditions, or perhaps a setting isn't being changed back properly upon exiting. Very strange though...
-
Evidently the problem was something weird with the appvar mentioned two posts above, the calc's been behaving for the entire day.
:D
-
Oh, still really strange. I'm glad to hear that your calc. appears to be behaving normally now though. :)