A82: Re: Maybe Oshell was perfect *AND* Here is the plan!
[Prev][Next][Index][Thread]
A82: Re: Maybe Oshell was perfect *AND* Here is the plan!
I totally agree, that this is a major problem with TI82 asm and we should
try to fix this asap (Jason and i have just been discussing this too). From
what i have seen my self and heard from others this error occurs no matter
how simpel the input is (2+2 can cause it). So to identify the error we
should look at what happens when an expression is entered. Generally only
two things occurs which alters the mem and could cause problems, the system
updates ANS ans LASTENTRY. So it is probably i good guess that the problem
is on of these vars.
The rpoblem with locating any error concerning ANS is that is might involve
split stack memory, which we do not know enough about. There no one has been
looking into the format of the ANS data and the function dealing with it.
LASTENTRY seems to be rather easy to understand, but noone has yet
documented anything about, which makes it harder to investigate.
Since so little is know about the two things, it is hard to now what could
be wrong. I do however feel that it is very unlikely that the error is
caused by any of the vars used to start Ash/OS82. One of them is mapped to
the rom which, if you look at the ti82 variable functions should mean that
it is never ever moved. The other vars is a var like anyother, except for
the name, which should in no way cause any problems since no of the
functions found checks this.
If you look into what happens when you enter an expression i think you will
agree with me that it is more likely that the errors are caused by ANS or
LASTENTRY.
ANS:
When a new value is calculated, the old ANS "variable" is deleted, and a new
is created. How this really happens is not know, it might depend on wether
splits tack manegement is used or not. But it is most likely that it uses
the normal delete function.
LASTENTRY:
The last entry is an array of entries indexed by some pointers/lenght placed
in the beginning of the var. When e new expresion is entered the calc checks
wether there is room for a new entry or not. If there is room ebough the
entry ies added, if not one entry is deleted and the new one is added. The
old one is probably deleted using the normal delete function.
So if one of the two data areas was messed up for some reason, the delete
rutine would probably be call with a wrong lenght/pointer, This would
normally cause the calc to crash.
If the reason that the calc crashes is that the LASTENTRY data area is
messed up for some reason, a few things which might seem strange when you
look at this problem is explained.
1. Why does it not take the same amount of calculations from you exit the
shell till it crashes each time?
2. How come the error is the same in Ash and OS82 ?
3. Why was this not seen at all when this method was tested with ZShell on
the TI85 ?
I think that the answers are as follows:
1. You never know wether the buffer is empty or full when you enter the
shell or what data it holds. This menas that you can not be sure how long
time it will take for the error to show even if you change the same thing in
the buffer every time you exit the shell. Also unless you do the exact same
calculations each time they tale up a different amount of space.
2. This question is easier to answer a bit later.
3. The TI85 does not have the same kind of LASTENTRY var as the TI82.
If this is true it should be possible to get the error by pressing 2nd ENTER
a few times, since this also uses the buffer. I have tested this on my calc
and it acutally generates the same error ! But when you do this you also see
something which is even more interesting, just before crashing the calc
shows a string which is very important. As most people will regonize :-)
this is the string generated when you try to get the name of token 0! With
this we can answer question 2.
2. The error is not caused by bad programming of the shells, but by
themethod used to start them.
Let me explain. When the shells are started abasic program is executed a
basic program is run, this sets the shell as the current input handler and
exits. The next time a key is pressed the shell is started. But before this
something else happens. Since a new entry is started, the room for that is
allocated in the buffer used to store LASTENTRY. Then the shell is called,
and when it exits the buffer holds an empty entry with the value 0 (This is
why the strange string is shown when you press 2nd entry alot of times).
Since the data for this entry is invalid the calc crashes every time t tries
to delete it. So basically the only method know for running asm on the ti82
destroys parts of the system mem which makes the calc crash.
The question now is how can this be solved ? Some one needs to find the
format of the LASTENTRY buffer, so we can correct the error in it befire
exiting the shell. So if people want asm on the ti82 which does not crash
you calc, someone should sit down and find the format of the var. The sooner
this gets done the sooner it can be corrected. Jason Todd will of cause try
to include this feature in our shell.
If anyone decides to look at this i will be glad to help with any problems
you might have. Unfortunatly i have very little time for programming right
now (too much to do at the university).
Dines
-----Original Message-----
From: ilya winham <ilyamojo@geocities.com>
To: CALC-TI@LISTS.PPP.TI.COM <CALC-TI@LISTS.PPP.TI.COM>;
assembly-82@lists.ticalc.org <assembly-82@lists.ticalc.org>
Date: 12. september 1997 23:24
Subject: A82: Maybe Oshell was perfect *AND* Here is the plan!
>First of all I would like to congratulate all the 82 shell
>developers. You have done a wonderful job. Assembly on the 82 is looking
>good thanks to the few (but good) game developers. But there is one
>major thing that must be recognized and fixed - the constant crahing of
>your calculator when doing math or any other stuff. This is a big
>problem, bigger than you may think. If I give someone the asm games from
>my calc, there calc has always crashed within a week, no kidding. I and
>other people have lost valuable information and programs when this
>happens. When it is test day for precalc I nor anyone else would risk
>having Ash or OS-82 on our calcs. Just today my calc crashed 2 times
>doing simple math and graphing. It is just such a hassle to have to
>backup your calc everyday to your computer and give everybody backups
>constantly, and loose all my wonderful math programs during class. So I
>have some solutions to consider for the upcoming Ash+OS-82 Shell which
>Jason Todd and Dines J. are working on, I hope you two are reading this!
>
>Presenting.........."HERE IS THE PLAN!" by-Ilya Winham, Junior
> Now there are a bunch of choices to choose from when making the new
>asm shell. Should it contain this, or maybe that, but ultimatly a vote
>needs to be taken. So here are some ideas to eliminate (possibly!) those
>god damn awfull crashes that have destroyed me and others during school.
>Again, these are in no particular order so lets begin....
> 1.) This is probably the best one to think about, and easiest. When
>Oshell was first released it use 'Q' as its asm accessing variable. The
>problem with this was that some basic programs use Q and then boom,
>crashes your calc. Besides that I don't recall there being any other
>random crashes caused by general use. So why doesn't the new shell
>use:(list follows of possible variables, variables must be 'real' or
>crashes will occur as with Ash3.0 using 'dummy' variables)
> -r6, r5, r4 etc..
> -GDB6, GDB5 etc..
> -Pic (7-16) (you remember the program that allows 16 pics! use one of
>those!!!)
> -Paratmetric functions X1t,Y1t etc...
>These variables are very, very rarely used and would work great!!
> 2.)If you must use a 'dummy variable' then make sure it is somewhere
>in memory that isn't 'used' much. This is my theory on the crashes now.
>When doing anything on your calc things are moving around in memory
>constantly. It is only a matter of time before something will move to
>or be affected by the dummy variable and crash your calc. So a variable
>would have to be used that isn't in a 'hot spot' for memory movement, (I
>don't know if I am making sense because I don't no a lot of technical
>stuff about the 82) Maybe try 'Time' or 'Web' Normally these can only be
>accessed when in a certain graphing mode. Or if you could create a
>totally new variable? or use like I said above pictures (7-16 not all
>but one) as a dummy variable.
> 3.)Here is another theory of mine. The shell is changing something
>when it is executed and not returning that thing back to where it was
>before. So when the calc looks for that when doing normal operations,
>boom, your calc has just crashed.
>Conclusion:I hope one of these suggestions works. And I would like to
>know Jason Todd's, Dines J., AVD, and, Hruska's opinion about finally
>fixing this huge bug problem (yes it is huge, and excuse any
>misspellings)
>
>
>Ilya -- mailto:ilyamojo@geocities.com
>
Follow-Ups: