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

Groups > comp.sys.apple2.programmer > #2364

Re: Streamlining Applesoft - The garbage collector

Show key headers only | View raw

gids.rs wrote:
> On Tuesday, February 23, 2016 at 9:36:53 AM UTC-6, Benoit0123 wrote:
>> gids.rs wrote:
>> >> This is great work!
>> >> 
>> >> >  This would give us and allow for 256 string pointers through each
>> >> >  pass
>> >> >  through the variable tables.  I apologize for mis-leading you to
>> >> >  think
>> >> >  we are only collecting 128 strings at a time, but such is the
>> >> >  suspense
>> >> >  of story telling.
>> >> 
>> >> Question that is tangential to this:
>> >> 
>> >> Is there a limit on the number of strings Applesoft can handle, aside
>> >> from a memory one? 256 max strings? i.e. if LOMEM was set to something
>> >> ridiculous so that Applesoft had ~32K available, is there a hard limit
>> >> to
>> >> the number of strings or is strictly memory limited?
>> > 
>> > 
>> > Applesoft limits each array indice to 65536.  So the array
>> > NAME$(65536,65536,65536) is a valid array and would allow for, lets
>> > just
>> > say that is a really big number of strings.  The array itself would not
>> > even fit in memory, let alone any strings.  But even if it did have the
>> > memory, this is much larger than the 16 Mb file limit of Prodos.
>> Small adjustment: Plain vanilla Applesoft accepts indice values from 1 to
>> 32767 while handling DIM statements and from 0 to 32767 within array
>> element
>> lookup.
>> For instance,
>> DIM A%(32768) will lead to an "?ILLEGAL QUANTITY ERROR" raised at the
>> time
>> the indice value is evaluated..
>> DIM A%(32767) will lead to an "?OUT OF MEMORY ERROR" instead, raised
>> afterwards when time is coming for ensuring enough RAM available within
>> the
>> heap.
>> At the time of Applesoft release, this was a sensible choice as
>> adressable
>> mémory was limited to 64K and smallest element size for arrays was the
>> 16bits (2 bytes wide) integer (65536 / 2 = 32768)...
>> 
> 
> 
> Thanks for the correction.  I always thought applesoft limited the max
> dimension size to 32767 but I thought that was only for integer variables,
> and I could not find where it was limited at, in my applesoft
> dissassembly.
> I finally found it.  The limitation was not in the dimensioning routine,
> but instead was in the conversion from floating point to an integer in
> applesoft.  And it affects all array variables, string, floating point and
> integer.
> 
> This limitation will be removed in my version of a streamlined applesoft
> since there will be no FP to INT conversions.

If you are interested in enhancing Applesoft in the array management domain,
may I suggest that you take a look of an article by John R. Vokey Ph.D who
wrote a very interesting article for managing Applesoft arrays live from
ProDOS files (sort of virtual memory, hence the article title) and published
in Nibble magazine?
Likewise the array size limitation barrier is pushed some kilobytes further
away ;-) if that is your goal (I understand "letting Applesoft evolve/mutate
according to 'new' Apple // hardware platform capabilities").
It appeared in the August 1990 issue of Nibble magazine. The utility runs
under ProDOS 8 (BASIC.SYSTEM) and a provided demo (provided on the disk)
illustrates well what this utility could be used for.
The disk section of the magazine site's address is given below:
http://www.nibblemagazine.com/nibble_disks.htm

By the way, thanks to the author of this utility, M. Vokey Ph.D, for having
shared his works and experiments, to M. Harvey for having managed such a
great magazine at the time and to Stavros Karatsoridis for having prepared
the Nibble disks now available to the community.



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

Back to comp.sys.apple2.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Streamlining Applesoft - The garbage collector gids.rs@sasktel.net - 2016-02-20 20:33 -0800
  Re: Streamlining Applesoft - The garbage collector Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-02-22 13:58 -0800
    Re: Streamlining Applesoft - The garbage collector "Anton Treuenfels" <teamtempest@yahoo.com> - 2016-02-22 17:55 -0600
    Re: Streamlining Applesoft - The garbage collector gids.rs@sasktel.net - 2016-02-22 21:46 -0800
      Re: Streamlining Applesoft - The garbage collector Benoit0123 <bgilon@free.fr> - 2016-02-23 15:33 +0000
        Re: Streamlining Applesoft - The garbage collector gids.rs@sasktel.net - 2016-02-23 08:09 -0800
          Re: Streamlining Applesoft - The garbage collector Benoit0123 <bgilon@free.fr> - 2016-02-23 18:08 +0000
            Re: Streamlining Applesoft - The garbage collector Michael J. Mahon <mjmahon@aol.com> - 2016-02-23 12:52 -0600
              Re: Streamlining Applesoft - The garbage collector Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-02-23 12:15 -0800
                Re: Streamlining Applesoft - The garbage collector Michael J. Mahon <mjmahon@aol.com> - 2016-02-24 00:46 -0600
            Re: Streamlining Applesoft - The garbage collector gids.rs@sasktel.net - 2016-02-23 21:47 -0800
      Re: Streamlining Applesoft - The garbage collector Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2016-02-28 04:51 -0600
        Re: Streamlining Applesoft - The garbage collector D Finnigan <dog_cow@macgui.com> - 2016-02-29 23:09 +0000
          Re: Streamlining Applesoft - The garbage collector Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-03-01 09:05 -0800
            Re: Streamlining Applesoft - The garbage collector D Finnigan <dog_cow@macgui.com> - 2016-03-01 18:04 +0000
              Re: Streamlining Applesoft - The garbage collector Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-03-01 12:22 -0800
    Re: Streamlining Applesoft - The garbage collector Michael J. Mahon <mjmahon@aol.com> - 2016-02-23 12:40 -0600

csiph-web