A83: Re: Re: Filesystem-scanner
[Prev][Next][Index][Thread]
A83: Re: Re: Filesystem-scanner
But most of the errors in the filesysten can be fixed:
1. Wrong sizes,
The TIOS doesn't calculate the size from the VAT, it just looks at the
size-bytes. These could be recalculated via the VAT. I know, most of the
time the program itself is corrupted too...
But you could fix the size-byte and then delete the program (which is
corrupted), if you do that the normal way via "Mem"+"Delete"+"All", then
the calc will (almost certainly) crash, because of the wrong size bytes.
Fixing this will help you to recover that program (BASIC, okay) you just
wrote and really need on a test/exam/etc.
2. Memory leeks,
Like Ion removing the "link" between Lists and the string that's stored in
it. These things allocate memory, but don't show up in the VAT, they should
be deleted, saving memory...
3. A program crashed while running it under Ion,
Sometime your calc is only bit unstable after this, but if you start Ion it
begeins to run the program that crashed... Not really the thing you want,
because it will corrupt you calc more and more. Fixing this should be
simple...
etc. etc.
Maybe you don't need this 'repairing-feature' most of the time, but it can
be really nice sometimes. And being able to program such a
"filesystem-scanner" does say something about your programming
capabilities...
Henk Poley
-------
> It's ram. It's all write-able (i.e. unprotected), and there isn't very
much
> of it. So it isn't really feasible or possible on the 83. On the 83+,
you
> can just archive everything, and if the ram gets corrupted, load it back
> into ram from the archive. On the 86, it is sometimes possible to
restore
> from a crash, because the vat is stored on page 6, which isn't normally
> swapped into usable ram. There is a checksum of the memory that the OS
uses
> to know whether or not to reset when recovering from a program
misbehaving.
> And there are at least a couple programs to protect against crashes and
even
> resets. Sorry, not possible on the 83, because the 83 just plain (ok,
won't
> say it considering it is the A83 list).
>
> > Most of the time when my calc crashes, I've seen that the variables in
ram
> > are behaving strange, variables that *are* >1meg big, same name used
> twice,
> > etc.
> >
> > Most of these things are caused by assembly programs...
> >
> > Even some strange thing: I don't know why it happens.
> > Store a string into a list, so it's automaticly updating the numbers,
then
> > start Ion, the link between the string part and the list-var will we
> > broken, but it still allocates memory...
Follow-Ups: