Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!princeton!phoenix!pucc!SRMASTER
From: SRMASTER@pucc.Princeton.EDU (Stephen Master)
Newsgroups: comp.sys.atari.st
Subject: Re: Since you asked...GEMBOOT V1.10
Message-ID: <3071@pucc.Princeton.EDU>
Date: Fri, 3-Jul-87 12:24:52 EDT
Article-I.D.: pucc.3071
Posted: Fri Jul  3 12:24:52 1987
Date-Received: Sat, 4-Jul-87 13:56:06 EDT
References: <3069@pucc.Princeton.EDU> <361@hechcx.HEC.HARRIS.COM> <8706290606.AA00991@ucbvax.Berkeley.EDU> <260@auvax.UUCP>
Reply-To: SRMASTER@pucc.Princeton.EDU
Organization: Princeton University - Princeton, New Jersey
Lines: 50
Disclaimer: Author bears full responsibility for contents of this article


...and here is GEMBOOT documentation.
=========================================================================
 
The uuencoded ARC file GEMSOFT.ARC contains a program GEMBOOT which serves as a
plaster for the old TOS problem: the 40 folder limit.
To state clearly, GEMBOOT does not *cure* the TOS bug, but it prevents the
primary error from happening in most cases.
 
As far as I could find out, the 40 folder limit is a two fold TOS bug.
The error symptoms are caused by GEMDOS being "out of system memory".
GEMDOS has a limited system memory area of 3000 words used for memory
descriptors, media descriptors, directory blocks, etc.
The problem of memory fragmentation has been discussed in articles before.
 
Tracing GEMDOS internal data I found the system memory overflow being forced
by multiple duplicates of directory blocks.
It seems to me that GEMDOS sometimes forgets to set a special flag in the
currently used directory block.  This flag should indicate that the
corresponding directory has been read and directory blocks for every
subdirectory have been created.
Thus next time GEMDOS needs a file located in this directory it creates
another set of subdirectory blocks.
This happens on and on until the system memory is totally trashed with useless
duplicates.
If the device is a floppy drive you have a chance because all assigned
directory blocks are released after a media change.
 
Unfortunately I couldn't locate a special GEMDOS call causing the flag error.
Nevertheless the duo Fsfirst()-Fsnext() seems to create directory blocks with
set flags.
Thus GEMBOOT adds 300 directory blocks to the system memory and scans all
directories to built up a complete directory tree (with set flags).
 
Additionally GEMBOOT provides a 80 character path buffer for DESKTOP which
may be modified by the program SETPATH.
Last not least it has a build in startup batch feature which uses a standard
command shell without creating a "memory hole" in front of resident programs.
A ramdisk installation program can be supplied with params within your startup
batch procedure.
 
I'm using GEMBOOT since a few month and have 200 directories on my hard disk
without any problems.
The program is based on the german ROM-TOS version, I don't know whether it
works with the US version. If there are any problems, let me hear.
Enjoy.
 
  Konrad A. Hahn
  Dept. of Computer Science @ Techn. University Darmstadt
  BITNET: XBR4D76H@DDATHD21