memory error on 83


[Prev][Next][Index][Thread]

memory error on 83



> Hello,
>
> You probably have something like this somewhere:
>
> If something
> Then
> ...
> If something else
> Goto A
> ...
> Goto B
> End
>
> The problem is the way the calc runs loops and if/thens. Here is
> simplified version of why it works (because I don't know or care about
> the details):
>
> Everytime the calc reaches a "if/then", it adds a value to a
> stack(something it uses to know where to go during program execution,
> a list of memory addresses, I figure). When it reached an "end", it
> removes it. If you keep adding tokens without removing them, your
> stack grows, and grows, and grows... 'til you know what.
>
> The solutions:
>
> 1-Don't use gotos in loops or after if/then. Don't use Gotos at all if
> you can, they're _really_ slow and often cause these kinds of
> problems. With a little bit of creativity, you can do almost anyhing
> with the different kinds of loops.
>
> 2-Get around the problem by putting an End after your label:
>
> ...
> Lbl A
> End
> ....
>
> This will only work if the section of code after the label is _always_
> called from inside a loop or if/then thingie. Else, you get a syntax
> error. This is relatively rare because people usually prefer to use
> subprograms in these cases, it's simpler and faster.
>
> 3-What you do if you can't avoid the goto statement and the block of
> code is accessed in diferent ways:
>
> Instead of just putting your label, do this:
>
> If 0
> Then
> Lbl A
> End
>
> Simple, isn't it :-) It slows stuff down a tiny bit, but testing
> wether 0 is equal to 0 doesn't take very long...
>
> I'm hoping this was understood, and that it helped,
>
> Just let me say it again, _don't_ use goto's unless you are positive
> you can take care of MEM errrors and you are ready to sacrifice a lot
> of speed! I have never found a program that couldn't be written
> without using labels except for changing between different parts of
> the prog (Main menu, options menu and game engine, for example)
>
> Why is it so slow? Because everytime the calc finds a goto, it starts
> searching the prog from that point on for the right label, when it
> reaches the end it starts at the beginning. In very small programs,
> this doesn't matter much because the search time is short, but it gets
> a lot longer bery fast.
>
> That's all I have to say,
>
> Philipp Keller
>
> Sim CEO <simceo@aol.com> wrote in message
> news:19990115223839.07042.00001668@ng-fr1.aol.com...
> >I made a game on the TI-83, which is an arena fighting game, and it
> keeps going
> >back through the same thing over and over, not in repeat loops but in
> label
> >loops if you want to put it that way. My friend was testing the game,
> because I
> >finally got it to function properly, when after around 100 turns the
> calculator
> >siad "Memory Error" and the program stopped. How do I avoid this
> error?
>

I also had a problem with memory errors.  I was working on my own
version of Monopoly.  Because the game was so long it essentially, for
all intents and purpouses, went forever.  As you were playing it the
thing would slowly slow down and then, eventually, error.  I, too, got
the information about using goto's from within anything that had an end
statement and went back and fixed ALL of them that were in the program.
However, that didn't completely solve the problem.  Granted, the program
would go a _a lot_ longer, but it would still error out eventually.
There is another possible solution, however, depending on how the game
works. At any point within your game do you have to prompt the user for
any sort of input?  Specifically, is there an 'Input' or 'Prompt'
command?  If so, then you should be able to make this idea work.  What
it does is Stop the program at that point and then restart it right
where it left off.  To be honest, I don't exactly what the details are
when this happens, but if you think about it everything makes sense.  As
far as the calculator is concerned you are just starting up any old
program and it is designed to handle that.

Okay, here is how it works. Instead of having the 'Input' command, you
will need a getkey loop. Before you go through the getkey loop display a
question mark, just like how the 'Input' would look.  Now, when the user
presses a number - say, a 1 - the calculator will return the getkey
number - 92.  Convert that number from the getkey number into the number
that was actually pressed.  In this example convert the 92 into a 1.
Then display that number.  Actually Output that number right beside the
question mark so it still _looks_ like what would happen with 'Input'
command.  Then, after outputing the number, set some unused variable to
some way-out-there absurd number that would probably never be used any
other time for anything.  For example, I like to use the variable O and
set it to 346.  All this does is provide a pointer.  Next, put in the
'Stop' command.  Now think about just exactly what's happening.  The
user sees a question mark and goes to press a number.  When they do,
that number is displayed exactly like it should be.  The program then
stops.  However, the only sign that the program has stopped will be a
cursor will start blinking.  The user probably won't notice that this is
a little odd, and they will just press enter - exactly like they would
if they were at an input statement.  When they press enter the program
will automatically restart at the beginning.  This is where you will
need to have the lines that will direct your program to go down to just
after the stop so it can pick up where it left off.  Lastly, you'll need
to stick a label in there so that the program will know where to pick up
where it left off, and you will need to change O when it gets there so
that it won't jump there when you really do want to start the program at
the start.  It should look something like this:
:If O=346
:Goto X
:......
:......
:Output(1,1,"?
:Repeat Ans
:Getkey
:End
:Ouput(1,2,3(abs(iPart(Ans/10)-10)-1)+10fPart(Ans/10)-1+2(K=102
:346->O
:Stop
:LblX
:.......

Jody Snider
jody1@alaska.net