[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ProDOS Madness!
- Subject: Re: ProDOS Madness!
- From: nparker@cie-2.uoregon.edu (Neil Parker)
- Date: 11 Mar 1995 02:48:42 GMT
- Newsgroups: comp.sys.apple2
- Organization: University of Oregon Campus Information Exchange
- References: <3joqer$bd8@acme.freenet.columbus.oh.us>
In article <3joqer$bd8@acme.freenet.columbus.oh.us>
dalloff@freenet.columbus.oh.us (Dave Althoff) writes:
>[...]
>Anyway, I have an Applesoft program which fiddles with a lot of strings,
>and fills up memory pretty fast. It runs slightly faster under 3.3 than
>under ProDOS, because DOS 3.3 (after issuing a MAXFILES 1 command) leaves
>more memory available for BASIC by only taking up *one* *256-byte* file
>buffer.
>[...]
>Q1: Is there any way to get ProDOS to surrender six or so of its oversize
>(512-byte) file buffers to BASIC variable space?
The short answer: No.
By default (unless you patch the appropriate code on the disk), DOS 3.3
allocates three file buffers of 595 (not 256) bytes each at boot time.
This leaves HIMEM set to $9600. The number of buffers and their locations
are fixed, until you issue the MAXFILES command. By lowering MAXFILES to
1, you can raise HIMEM as high as $9BA6 (of course, you also rather
severely limit the number of things DOS can do at once).
When ProDOS boots, it allocates one 1024-byte buffer, leaving HIMEM at
$9600. If any additional buffers are needed, BASIC.SYSTEM allocates them
automatically (by lowering HIMEM and moving the strings down to make room),
and frees them up again as soon as they're no longer needed (by raising
HIMEM and moving the strings up). There must always be at least one
buffer, so HIMEM can never safely be raised above $9600.
>Q2: Didn't I hear that ProDOS had an improved string garbage-collection
>routine written into it? How can I force this instead of the *SLOW*
>Applesoft garbage collection? Or am I hallucinating?
As others have mentioned, PRINT CHR$(4)"FRE".
Also, ProDOS will automatically garbage-collect the strings whenever a new
file buffer must be allocated--i.e. whenever you open a file.
By the way, if you're stuck using the slow Applesoft garbage collection
under DOS 3.3, you can make life considerably less painful by liberally
sprinkling your program with X=FRE(0). This forces garbage collection,
and if you do it frequenty while the amount of garbage to be collected is
still relatively small, you won't have to worry about garbage building up
to the point where it becomes a problem. I stick lots of these in any
routine that does heavy string manipulation.
- Neil Parker
--
Neil Parker No cute ASCII art...no cute quote...no cute
nparker@cie-2.uoregon.edu disclaimer...no deposit, no return...
nparker@cie.uoregon.edu (This space intentionally left blank: )