RE: A83: Re: Re: Filesystem-scanner
[Prev][Next][Index][Thread]
RE: A83: Re: Re: Filesystem-scanner
There's a little problem we've been overlooking... how dou yopu get this
program on a creashed/corrupted Ti83?? and if it already is there, how do we
make sure that this program itself isn't corupted?
the last could probably be 'fixed' by using som sort of checksum...
> -----Oorspronkelijk bericht-----
> Van: owner-assembly-83@lists.ticalc.org
> [mailto:owner-assembly-83@lists.ticalc.org]Namens Henk Poley
> Verzonden: vrijdag 2 februari 2001 8:58
> Aan: assembly-83@lists.ticalc.org
> Onderwerp: 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:
References: