Message-ID: <2895@allegra.UUCP>
Date: Sat, 10-Nov-84 00:15:57 EST
Article-I.D.: allegra.2895
Posted: Sat Nov 10 00:15:57 1984
Date-Received: Sat, 10-Nov-84 09:58:46 EST
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 9

I'm running a terminal/modem program written in Basic (basically the
program from Byte earlier this year).  It uses strings, but they're all
initialized at the beginning of the program and never grow or shrink
thereafter.  Yet I still occasionally see basic pausing for 25 seconds
or so, presumably doing a garbage collection.  Is there any way to
avoid this?  It's not the delay that's the problem, but the resulting
loss of characters from the host is.
	Mark Plotnick
	{far too many sites}!allegra!mp

Message-ID: <85@unc.UUCP>
Date: Mon, 12-Nov-84 21:51:48 EST
Article-I.D.: unc.85
Posted: Mon Nov 12 21:51:48 1984
Date-Received: Wed, 14-Nov-84 05:34:20 EST
References: <2895@allegra.UUCP>
Organization: CS Dept., U. of N. Carolina at Chapel Hill
Lines: 18

.
	The reason you are getting garbage collects is that the BASIC
GET# instruction, which you are probably using to read the serial port,
allocates a new string buffer to put the character in every time the 
instruction is used.  The only way around that, though not too difficult,
is to avoid using the GET# instruction in your terminal emulator and
get the characters using a short machine language routine to call the
appropriate kernel routines.  Just poke the sequence

  162, 2, 32, 198, 255, 32, 228, 255, 133, 3, 162, 0, 32, 198, 255, 96

into your favorite unused memory area, SYS to it, and a character will
be magically left at location 3.  From that point, PEEK(3) will give
you what you would have gotten from GET#n.  And no more garbage collects!

Jim Ericksen
Dept of Comp Sci
UNC Chapel Hill

Message-ID: <43@vax2.fluke.UUCP>
Date: Thu, 15-Nov-84 11:59:37 EST
Article-I.D.: vax2.43
Posted: Thu Nov 15 11:59:37 1984
Date-Received: Sat, 17-Nov-84 04:16:52 EST
References: <85@unc.UUCP>
Organization: John Fluke Mfg. Co., Everett, WA
Lines: 11

There should be another way to get around the garbage collects.  In
microsoft BASIC, the FRE function does a garbage collect before reporting
the free memory space.  If you do a X=FRE(X) every couple hundred GET#'s,
the garbage collection will be performed in a situation where there is
little garbage, which will minimize the length of dead time during the
garbage collect.  This will allow you to use BASIC's admittedly pitiful I/O
rather than resorting to peeks and pokes.
-- 
Kurt Guntheroth
John Fluke Mfg. Co., Inc.
{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurt

Message-ID: <324@ubu.UUCP>
Date: Tue, 20-Nov-84 11:15:50 EST
Article-I.D.: ubu.324
Posted: Tue Nov 20 11:15:50 1984
Date-Received: Fri, 23-Nov-84 07:49:46 EST
Organization: Computer Science, Warwick University, UK
Lines: 15

Newsgroups: net.micro.cbm
Subject: Re: long pauses when running C64 basic
References: <85@unc.UUCP> <43@vax2.fluke.UUCP>

> There should be another way to get around the garbage collects.  In
> microsoft BASIC, the FRE function does a garbage collect before reporting
> the free memory space.  If you do a X=FRE(X) every couple hundred GET#'s,
> the garbage collection will be performed in a situation where there is
> little garbage, which will minimize the length of dead time during the
> garbage collect.  This will allow you to use BASIC's admittedly pitiful I/O
> rather than resorting to peeks and pokes.

I'm afraid to say this method will make programs that use lots of string
space slower in I/O rather than faster.  If this is the case use the
PEEK/POKE methos described in a previous article.

Message-ID: <532@uwmacc.UUCP>
Date: Tue, 4-Dec-84 18:52:28 EST
Article-I.D.: uwmacc.532
Posted: Tue Dec  4 18:52:28 1984
Date-Received: Fri, 7-Dec-84 02:20:48 EST
References: <85@unc.UUCP> <43@vax2.fluke.UUCP>
Reply-To: bllklly@uwmacc.UUCP (Bill Kelly)
Organization: UWisconsin-Madison Academic Comp Center
Lines: 18
Summary: 

In article <43@vax2.fluke.UUCP> kurt@fluke.UUCP (Kurt Guntheroth) writes:
>There should be another way to get around the garbage collects.
>If you do a X=FRE(X) every couple hundred GET#'s,
>the garbage collection will be performed in a situation where there is
>little garbage, which will minimize the length of dead time during the
>garbage collect.

I saw an article, I believe by Jim Butterfield, which said the major delay
in C64 garbage collection was in looking for the garbage, not in freeing
it, and hence using FRE() would not help.
-- 

Bill Kelly
{allegra, ihnp4, seismo}!uwvax!uwmacc!bllklly
1210 West Dayton St/U Wisconsin Madison/Mad WI 53706

"Sometimes, Penfold, I wish I was just drawing the cartoons,
 not starring in them."