Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!jpradley!jpr
From: jpr@jpradley.jpr.com (Jean-Pierre Radley)
Newsgroups: comp.sys.tandy
Subject: Re: tandy 16B and 16 bit compress
Message-ID: <1990Dec15.060825.1350@jpradley.jpr.com>
Date: 15 Dec 90 06:08:25 GMT
References: <1990Dec12.003253.18391@csis.dit.csiro.au>
Reply-To: jpr@jpradley.UUCP (Jean-Pierre Radley)
Organization: NYC Public Unix
Lines: 21

In article <1990Dec12.003253.18391@csis.dit.csiro.au> ken@csis.dit.csiro.au (Ken Yap) writes:
>I was trying to get 16 bit compress working on my 16B (~= 6000) and I
>found I couldn't have a large array in bss. Nor could I malloc or sbrk
>any space larger than 245k or so. Now at boot up the machine claims to
>have 892k (or so) user memory. Where's all that memory?  Do I have to
>reset some limit somewhere?
>

Where did you cop you source?
When 16-bit compress was being developed on CompuServe's UnixForum, I wrote the
make file for the t6k, which is the only machine I had at the time, so clearly
it worked - terrifically- on a t6k.

The memory you own is one thing. The memory you're allowed to use is another.
You need to reconfigure the kernel or patch it, to let MAXMEM be larger. A
utility for this was provided with filePro 1.1. It's also do-able with adb;
there's a 512-byte file called MAXMEM.T6K in LIB 9 of CIS' UnixForum which does
the trick.
-- 

 Jean-Pierre Radley	    NYC Public Unix	jpr@jpr.com	CIS: 72160,1341