Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!cornell!batcomputer!braner
From: braner@batcomputer.tn.cornell.edu (braner)
Newsgroups: comp.sys.atari.st
Subject: Re: Problem doing screen dump (BUCKET)
Message-ID: <2065@batcomputer.tn.cornell.edu>
Date: Sun, 18-Jan-87 13:37:19 EST
Article-I.D.: batcompu.2065
Posted: Sun Jan 18 13:37:19 1987
Date-Received: Mon, 19-Jan-87 18:57:09 EST
References: <2064@batcomputer.tn.cornell.edu>
Reply-To: braner@batcomputer.UUCP (braner)
Organization: Theory Center, Cornell University, Ithaca NY
Lines: 46
Summary: Don't use BUCKET until you read this!

[]

WARNING: BUCKET is flawed.  Don't use it until you read what follows.

As usual, mysterious problems are caused by undocumented features of TOS.
(The following IS known to many, but I couldn't find it in the Megamax
nor the 'ST Internals' documentation for Ptermres()!)

The Ptermres() function (GEMDOS $31) cannot leave your program with more
memory than it already has.  When executed, a program is given all of free
RAM (the TPA, Transient Program Area, roughly the RAM area which is bounded
below by the resident programs and above by the default screen RAM area.)
If your program does a Setblock() call (GEMDOS $4A), releasing most of the
TPA back to TOS (as programs are supposed to do), an later exit via
Ptermres() asking more than what's left is ineffective.  You will not notice
any problem for a while, whether because your resident code doesn't yet
write over all that RAM, or because no other program is executed.  But it's
a time bomb.

The solution is to keep, in Setblock(), all the RAM you might want to keep
resident later.  Alternatively, if your program is not a GEM program (i.e.
no desk accessories will be invoked until the Ptermres()) you can skip
Setblock() altogether.  But what can you do if you're writing the program
using a compiler that includes the Setblock() call automatically?

To fix BUCKET you have to use a debugger.   Look, near the beginning of the
executable BUCKET.TOS, for the code fragment:

	move	#$4A,-(sp)
	trap	#1

and overwrite the 'trap #1' with a 'nop'.  That will avoid the Setblock()
altogether.  (Alternatively, look a few lines above that for the calculation
of the amount to keep, and change it.  In a program compiled with Megamax C,
for example, look for 'add.l #$2100,d0'.  That's Megamax adding space for an
8K stack.  Increase that amount by as much as you need.)

I am now working on an improved version of BUCKET (to be called BARREL),
avoiding that problem and adding features such as screen-dumps to RAM and
built-in SCODE-ing.  (If you were wondering why BUCKET doesn't capture
Alt-Help screen dumps, it's because the ROM screen-dump code manipulates
the printer port directly, not via the BIOS trap.)  Suggestions on what
should be done in BUCKET (or on how to solve the Setblock() problem without
resorting to post-compilation patching) are welcome.

- Moshe Braner