Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!oliveb!felix!preston
From: preston@felix.UUCP (Preston L. Bannister)
Newsgroups: comp.sys.atari.st
Subject: Expanding the GEMDOS buffer list - is it a good idea??
Message-ID: <2135@felix.UUCP>
Date: Sat, 10-Jan-87 02:35:24 EST
Article-I.D.: felix.2135
Posted: Sat Jan 10 02:35:24 1987
Date-Received: Sat, 10-Jan-87 07:37:36 EST
Sender: root@felix.UUCP
Organization: FileNet Corp., Costa Mesa, CA
Lines: 52


Has anyone tried expanding GEMDOS's build-in buffer lists for data,
directory and FAT sectors?  The BIOS seems to allocate four 512 byte
buffers, two for each list (data sector list, FAT/directory sector
list).


The BIOS Technical Reference manual lists the following system variable:

_bufl (long) $4b4

  Two (GEMDOS) buffer-list headers.  The first list buffers data
  sectors, the second list buffers FAT and directory sectors.  Each of
  these pointers points to a BCB (Buffer Control Block), that looks
  like:

      struct BCB
      {
	      BCB	*b_link;	/* next BCB */
	      int	b_bufdrv;	/* drive#, or -1 */
	      int	b_buftyp;	/* buffer type */
	      int	b_bufrec;	/* record# cached here */
	      int	b_dirty;	/* dirty flag */
	      DMD	*d_dm;		/* -> Drive Media Descriptor */
	      char	*b_bufr;	/* -> buffer itself */
      };

To be slightly more explicit:

  BCB *data_sector_buffer_list		at $4b4
  BCB *FAT_directory_buffer_list	at $4b8


I wouldn't mind allocating a hundred buffers (or so) if it would reduce
the number of disk accesses.  File access is a _lot_ slower than it
should be on my hard disk, due to the large number of disk accesses for
even simple operations.  MS_DOS lets you do something similar by
putting a line like 'BUFFERS=100' to allocate 100 buffers for caching
disk sectors.

Is this a good idea with GEMDOS?  Is it safe?  Will it work?  (Anyone
at Atari or DRI listening?)

I'd be willing try the experiment, but it would be nice if someone
would take a look at the actual GEMDOS code to make sure it isn't a
waste of time.

========================================
Preston L. Bannister
USENET	   :	ucbvax!trwrb!felix!preston
BIX	   :	plb
CompuServe :	177000,176