Re: Virtual String Memory for Applesoft

["ict@ccess" <gids.rs@sasktel.net>]

> In several programs I've written, I needed to be able to process
> large files (>>64KB) while building several tables of an unpredictable
> size.
>
> I found that a single, sparse, binary file, accessed using BLOAD and
> BSAVE with B (byte-offset) parameters worked quite well.  The binary
> file has a potentially huge size, but its sparseness greatly reduces
> the actual disk allocation.

I had use the BLOAD function as well and used the B paramter.  B equal
record # times record length

I should explain a little bit of the reason I wrote this virtual
memory for strings.  I was enjoying playing Wades fantastic game
Leadlight, so I decided to copy it over to a disk that I use for
work.  I could then jump back and forth, to work, to play, to work, to
play.

I had used Prodos 8 to copy the files when I noticed that his text
files for his rooms, descriptions and extras were quite large.  The
descripts text file was a whopping 300 blocks while on his disk image
it only took up 189 blocks.  I knew it was a RAT file so I figured it
was saved as a sparse file.  I opened it up in a word processor to see
what it was all about.  I had finished the game already, so no secrets
were lost, but some secrets were exposed how this great game was
written.

So, for sh_ts and giggles (where the heck did that saying originate
from?), I wanted to see how much space was wasted by all the filler
characters.  I started out removing them manually, but that quickly
ended, so I wrote a program that input'd each line and printed them
back to another text file using the sequential method.

Walla!  The text file saved in just 89 blocks which is still quite a
savings over a sparse file.  But now the kicker.  How to access each
line without having to read each previous line first.

Answer.  With pointers of course.  3 bytes would be needed to point to
strings >64 kb.  Using the compressed pointer method stated above, for
the 89 block text file with around 500 lines of text, only two extra
blocks were needed for a total of 91 blocks compared to 189.  That is
over 50% hard drive savings of a sparse text file.

Or another way to look at it.  You can fit twice as much text in the
same size file.  :)

And the greatest advantage is you can use a word processor to make
these files since it is not easy to pad each line to be the same
length.

Rob

Allowing Applesoft to play with the big boys