Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #5526 > unrolled thread

Applesoft -Out Of Memory

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Applesoft -Out Of Memory btt071871@gmail.com - 2020-05-03 09:31 -0700
    Re: Applesoft -Out Of Memory David Schmidt <schmidtd@my-deja.com> - 2020-05-03 12:45 -0400
      Re: Applesoft -Out Of Memory btt071871@gmail.com - 2020-05-03 09:49 -0700
        Re: Applesoft -Out Of Memory David Schmidt <schmidtd@my-deja.com> - 2020-05-03 13:34 -0400
          Re: Applesoft -Out Of Memory btt071871@gmail.com - 2020-05-03 10:38 -0700
            Re: Applesoft -Out Of Memory Michael Barry <barrym95838@yahoo.com> - 2020-05-03 11:06 -0700
              Re: Applesoft -Out Of Memory Michael Barry <barrym95838@yahoo.com> - 2020-05-03 11:21 -0700
          Re: Applesoft -Out Of Memory btt071871@gmail.com - 2020-05-03 11:59 -0700
            Re: Applesoft -Out Of Memory Michael Barry <barrym95838@yahoo.com> - 2020-05-03 13:49 -0700
              Re: Applesoft -Out Of Memory btt071871@gmail.com - 2020-05-07 04:11 -0700
    Re: Applesoft -Out Of Memory Marco Verpelli <mverpelli@libero.it> - 2020-05-03 09:57 -0700

#5526 — Applesoft -Out Of Memory

Been trying to get rather large (old Star Trek) to run in Applesoft for awhile now... Thought I would reach out for any advice...
Nothing fancy going on here (no Graphics, assembly code, etc.)
My basic question is, what would cause an Out-Of-Memory error when the fre(0) command reports plenty of memory?
Here are the basic stats:
after loading:
Himem reports (dec 48640)(I am using David Dos for more free RAM)
Lomem reports (dec 32695)
for a free space of (dec 15945)

I put in a routine fre(0) command during execution just to keep watch.  And it always reports a value of at least (dec 10000).

After 5-15 minutes of play, I get and Out-Of-Memory crash at random locations in the code.

Any ideas of what I can look at?

Thanks!
-BT

[toc] | [next] | [standalone]

#5527

On 5/3/20 12:31 PM, btt071871@gmail.com wrote:
> [...]
> After 5-15 minutes of play, I get and Out-Of-Memory crash at random locations in the code.
> 
> Any ideas of what I can look at?

Not all "out of memory" situations are about free memory.  Some are 
about the stack.  Try this:

PRINT 1+(2+(3+(4+(5+(6+(7+(8+(9+(10+(11+(12+13)))))))))))

[toc] | [prev] | [next] | [standalone]

#5528

Ahhh, I see.  I suspected there might be something else going on..
Are there any techniques to better manage the stack to prevent this?
-BT

[toc] | [prev] | [next] | [standalone]

#5530

On 5/3/20 12:49 PM, btt071871@gmail.com wrote:
> Ahhh, I see.  I suspected there might be something else going on..
> Are there any techniques to better manage the stack to prevent this?

The problem you have is something is pushing, but not popping, the 
stack.  Something is open-ended, and not closing itself properly.  It 
could be some kind of increasingly-complex evaluation I showed, or it 
could be a leak out of a GOSUB routine without a RETURN, it could be a 
few more complex things - a comprehensive understanding of your 
program's flow is going to be required to solve it.  Maybe start with 
GOTO statements, especially those that could possibly go into or out of 
what should be GOSUB/RETURN subroutines.

[toc] | [prev] | [next] | [standalone]

#5531

Thank you.  This was really helpful.  It is old code, which has been shortened over the years to get it to work in a smaller footprint.  And it is messy, lots of re-directions and not very efficient.  Makes be believe the issue is exactly what you are saying.  Gives me a great place to start working.
-BT

[toc] | [prev] | [next] | [standalone]

#5532

On Sunday, May 3, 2020 at 10:38:17 AM UTC-7, btt0...@gmail.com wrote:
> Thank you.  This was really helpful.  It is old code, which has been shortened over the years to get it to work in a smaller footprint.  And it is messy, lots of re-directions and not very efficient.  Makes be believe the issue is exactly what you are saying.  Gives me a great place to start working.
> -BT

Integer BASIC was kind enough to tell you the specific cause (RAM full, FOR stack full, GOSUB stack full, evaluation stack full) ... Apple$oft, not so much.

Mike B.

[toc] | [prev] | [next] | [standalone]

#5533

On Sunday, May 3, 2020 at 11:06:09 AM UTC-7, Michael Barry wrote:
> 
> Integer BASIC was kind enough to tell you the specific cause (RAM full, FOR
> stack full, GOSUB stack full, evaluation stack full) ... Apple$oft, not so
> much.
> 
> Mike B.

I have recently received some detailed notes of an Integer BASIC reverse-
 engineering attempt by a 6502 guru.  The notes prompt more questions than
 they provide answers, but I have some excellent new information to try to
 digest.

Mike B.

[toc] | [prev] | [next] | [standalone]

#5534

I am test driving a potential work-around.
I found call 54915 - clear stack routine.
So i put this in my program in a place that gets frequented often, but is not within any FOR loops or SUB-Routines.
That's no substitute for a real fix if the program has an issue, but it does appear to keep the program running with no ill effects that I can detect thus far.
-BT

[toc] | [prev] | [next] | [standalone]

#5535

On Sunday, May 3, 2020 at 11:59:31 AM UTC-7, btt0...@gmail.com wrote:
> That's no substitute for a real fix if the program has an issue, but it does
> appear to keep the program running with no ill effects that I can detect
> thus far.
> -BT

Maybe not a "proper" substitute, but apparently a "viable" one.
Congratulations.

Mike B.

[toc] | [prev] | [next] | [standalone]

#5542

One followup, I think I found the *actual* problem...
When I went over the code carefully, I noticed that any IF THEN statement that had conditional operations (x=10 AND y=20, for example), enclosed each of those operations in (), and not to set priority.  The version of basic the original program utilized must have had that as a requirement.  Although it ran in Applesoft, that somehow must have been taxing the stack unnecessarily? (just my guess here).  Well anyway, I took the time to manually go through and remove all those redundant ().  I have test played for a couple hours and have yet to have a crash.  So I *think* that was the solution...Thanks Schmidtd for pointing me in the direction of the stack.  That really helped troubleshoot this...
-BT

[toc] | [prev] | [next] | [standalone]

#5529

On Sunday, May 3, 2020 at 6:31:04 PM UTC+2, btt0...@gmail.com wrote:
> Been trying to get rather large (old Star Trek) to run in Applesoft for awhile now... Thought I would reach out for any advice...
> Nothing fancy going on here (no Graphics, assembly code, etc.)
> My basic question is, what would cause an Out-Of-Memory error when the fre(0) command reports plenty of memory?
> Here are the basic stats:
> after loading:
> Himem reports (dec 48640)(I am using David Dos for more free RAM)
> Lomem reports (dec 32695)
> for a free space of (dec 15945)
> 
> I put in a routine fre(0) command during execution just to keep watch.  And it always reports a value of at least (dec 10000).
> 
> After 5-15 minutes of play, I get and Out-Of-Memory crash at random locations in the code.
> 
> Any ideas of what I can look at?
> 
> Thanks!
> -BT

Also too many GOSUB and the stack runs out of space

Marco

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web