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

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

AppleSoft free memory without using FRE(0)

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

Contents

  AppleSoft free memory without using FRE(0) Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2016-02-28 05:08 -0600
    Re: AppleSoft free memory without using FRE(0) gids.rs@sasktel.net - 2016-02-28 07:16 -0800
      Re: AppleSoft free memory without using FRE(0) Michael J. Mahon <mjmahon@aol.com> - 2016-02-28 17:19 -0600
      Re: AppleSoft free memory without using FRE(0) Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2016-02-28 22:20 -0600
        Re: AppleSoft free memory without using FRE(0) awanderin <awanderin@gmail.com> - 2016-02-28 21:58 -0700
          Re: AppleSoft free memory without using FRE(0) Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-02-29 12:48 -0800
          Re: AppleSoft free memory without using FRE(0) Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2016-02-29 19:18 -0600
            Re: AppleSoft free memory without using FRE(0) gids.rs@sasktel.net - 2016-02-29 17:53 -0800
              Re: AppleSoft free memory without using FRE(0) Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2016-02-29 23:07 -0600
            Re: AppleSoft free memory without using FRE(0) awanderin <awanderin@gmail.com> - 2016-02-29 22:46 -0700
              Re: AppleSoft free memory without using FRE(0) Benoit0123 <bgilon@free.fr> - 2016-03-04 13:19 +0000
                Re: AppleSoft free memory without using FRE(0) gids.rs@sasktel.net - 2016-03-04 07:48 -0800

#2381 — AppleSoft free memory without using FRE(0)

I'd like to get a free memory figure without waiting for AppleSoft's 
painfully slow garbage collection. Does BASIC.system's FRE command leave 
the info behind somewhere? Or is there some other reasonably compact method?

[toc] | [next] | [standalone]

#2382

On Sunday, February 28, 2016 at 5:09:00 AM UTC-6, Brian Patrie wrote:
> I'd like to get a free memory figure without waiting for AppleSoft's 
> painfully slow garbage collection. Does BASIC.system's FRE command leave 
> the info behind somewhere? Or is there some other reasonably compact method?


it is just the difference between the start of string space and the end of array space.

FM = (PEEK(111)+256*PEEK(112)) - (PEEK(109)+256*PEEK(110))

or in ML

 SEC
 LDA $6F
 SBC $6D
 STA $6
 LDA $70
 SBC $6E
 STA $7
 LDX $6
 JMP $F941

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

#2383

<gids.rs@sasktel.net> wrote:
> On Sunday, February 28, 2016 at 5:09:00 AM UTC-6, Brian Patrie wrote:
>> I'd like to get a free memory figure without waiting for AppleSoft's 
>> painfully slow garbage collection. Does BASIC.system's FRE command leave 
>> the info behind somewhere? Or is there some other reasonably compact method?
> 
> 
> it is just the difference between the start of string space and the end of array space.
> 
> FM = (PEEK(111)+256*PEEK(112)) - (PEEK(109)+256*PEEK(110))
> 
> or in ML
> 
>  SEC
>  LDA $6F
>  SBC $6D
>  STA $6
>  LDA $70
>  SBC $6E
>  STA $7
>  LDX $6
>  JMP $F941
> 

And that result is only *really* the free space if no garbage has been
created since the last garbage collection--which is why FRE() does a
garbage collection. 

This difference is, however, what determines how close you are to a forced
garbage collection. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

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

#2384

On 2016-02-28 09:16, gids.rs@sasktel.net wrote:
> it is just the difference between the start of string space and the end of array space.
> FM = (PEEK(111)+256*PEEK(112)) - (PEEK(109)+256*PEEK(110))

Exactly what i needed. I was hoping it would be that simple. Thanks!

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

#2385

Brian Patrie <bpatrie@bellsouth.spamisicky.net> writes:

> On 2016-02-28 09:16, gids.rs@sasktel.net wrote:
>> it is just the difference between the start of string space and the
>> end of array space.
>> FM = (PEEK(111)+256*PEEK(112)) - (PEEK(109)+256*PEEK(110))
>
> Exactly what i needed. I was hoping it would be that simple. Thanks!


You could also do a ProDOS "FRE" followed by the applesloth FRE(0) and
get your number fairly quickly.  If you don't have much string action in
your program, the Applesoft FRE(0) is not going to take long anyhow.

--
Jerry    awanderin at gmail dot com

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

#2389

On Sunday, February 28, 2016 at 8:58:14 PM UTC-8, awanderin wrote:
> applesloth

Ha! That's a beautiful intentional "Freudian slip" Love it !

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

#2392

On 2016-02-28 22:58, awanderin wrote:
> You could also do a ProDOS "FRE" followed by the applesloth FRE(0) and
> get your number fairly quickly.  If you don't have much string action in
> your program, the Applesoft FRE(0) is not going to take long anyhow.

I'd tried that; FRE(0) still took ever. (The immediately relevant 
program is a catalog browser, that uses several large arrays.)

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

#2395

On Monday, February 29, 2016 at 7:18:28 PM UTC-6, Brian Patrie wrote:
> On 2016-02-28 22:58, awanderin wrote:
> > You could also do a ProDOS "FRE" followed by the applesloth FRE(0) and
> > get your number fairly quickly.  If you don't have much string action in
> > your program, the Applesoft FRE(0) is not going to take long anyhow.
> 
> I'd tried that; FRE(0) still took ever. (The immediately relevant 
> program is a catalog browser, that uses several large arrays.)


The Basic.system garbage collector automatically kicks in when it sees there is less than 2 pages of free memory left.  The applesoft garbage collector kicks in when it sees there is less than one page of free memory.

Since the Basic.system version takes priority and runs first, the applesoft version should never engage, but may engage if memory is full and the Basic.system version could not compress the strings any further.  In which case, you would basically get an "Out of Memory Error" anyways.

The best way to allow for the most strings in memory is to keep your applesoft program as small as possible, removing REM's, combining repeated routines into subroutines and using GOSUB, keeping redundant code out of your program such as a free-memory checking routine.  This is done automatically by Basic.system and is unnecessary.

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

#2399

On 2016-02-29 19:53, gids.rs@sasktel.net wrote:
 > The best way to allow for the most strings in memory is to keep your
 > applesoft program as small as possible, removing REM's, combining
 > repeated routines into subroutines and using GOSUB, keeping redundant
 > code out of your program such as a free-memory checking routine.
 > This is done automatically by Basic.system and is unnecessary.

It's only for display purposes, just so i can see what's going on.  I 
suppose it's a little frivolous, but it's only 97 bytes in a 6k prog. 
If i eventually need the space i can rip it out. :)

My main code space constraint is keeping out of the first hi-res screen. 
  Trimming things up to make room for new features has been a big part 
of the fun of writing the thing. :)

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

#2400

Brian Patrie <bpatrie@bellsouth.spamisicky.net> writes:

> On 2016-02-28 22:58, awanderin wrote:
>> You could also do a ProDOS "FRE" followed by the applesloth FRE(0) and
>> get your number fairly quickly.  If you don't have much string action in
>> your program, the Applesoft FRE(0) is not going to take long anyhow.
>
> I'd tried that; FRE(0) still took ever. (The immediately relevant
> program is a catalog browser, that uses several large arrays.)

Oh right, I forgot that BASIC.SYSTEM actually turns on TRACE mode and
hides the output, so that it can spy on variable use after each
statement.  I believe that is how it auto-issues the FRE command.

--
Jerry    awanderin at gmail dot com

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

#2428

awanderin wrote:
> Brian Patrie <bpatrie@bellsouth.spamisicky.net> writes:
> 
>> On 2016-02-28 22:58, awanderin wrote:
>>> You could also do a ProDOS "FRE" followed by the applesloth FRE(0) and
>>> get your number fairly quickly.  If you don't have much string action in
>>> your program, the Applesoft FRE(0) is not going to take long anyhow.
>>
>> I'd tried that; FRE(0) still took ever. (The immediately relevant
>> program is a catalog browser, that uses several large arrays.)
> 
> Oh right, I forgot that BASIC.SYSTEM actually turns on TRACE mode and
> hides the output, so that it can spy on variable use after each
> statement.  I believe that is how it auto-issues the FRE command.
> 
> --
> Jerry    awanderin at gmail dot com
>
IMHO the intercept at this level only serves as being able to parse command
texts from the Applesoft main loop (starting at $D7D2) to properly render
the TRACE output on screen/printer while parsing a ProDOS BI command or
writing to a file;
I don't think that such hook serves as automatic garbage collection (based
on BASIC SYSTEM 1.1 listing study by M. Mossberg) which still needs to be
manually triggered by using the PRINT CHR$(4);"FRE" sequence from a BASIC
program, unlike the Applesoft internal FRE(0) which remains automatic.
Has this state evolved in subsequent BASIC.SYSTEM release (from 1.3 to
1.5).. I do not know..



-- 
Growing old is mandatory..
growing up is optional..
But the other way round is as true.

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

#2430

> >> On 2016-02-28 22:58, awanderin wrote:
> >>> You could also do a ProDOS "FRE" followed by the applesloth FRE(0) and
> >>> get your number fairly quickly.  If you don't have much string action in
> >>> your program, the Applesoft FRE(0) is not going to take long anyhow.
> >>
> >> I'd tried that; FRE(0) still took ever. (The immediately relevant
> >> program is a catalog browser, that uses several large arrays.)
> > 
> > Oh right, I forgot that BASIC.SYSTEM actually turns on TRACE mode and
> > hides the output, so that it can spy on variable use after each
> > statement.  I believe that is how it auto-issues the FRE command.
> > 
> > --
> > Jerry    awanderin at gmail dot com
> >
> IMHO the intercept at this level only serves as being able to parse command
> texts from the Applesoft main loop (starting at $D7D2) to properly render
> the TRACE output on screen/printer while parsing a ProDOS BI command or
> writing to a file;
> I don't think that such hook serves as automatic garbage collection (based
> on BASIC SYSTEM 1.1 listing study by M. Mossberg) which still needs to be
> manually triggered by using the PRINT CHR$(4);"FRE" sequence from a BASIC
> program, unlike the Applesoft internal FRE(0) which remains automatic.
> Has this state evolved in subsequent BASIC.SYSTEM release (from 1.3 to
> 1.5).. I do not know..


Basic.system's v1.4 and 1.5 have an automatic garbage collector which are at $9ED3 and $9ED2, which checks to to see if there is less than 2 pages of free memory before engaging.

[toc] | [prev] | [standalone]

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

csiph-web