Path: utzoo!mnetor!uunet!portal!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: Trapping errors
Message-ID: <968@atari.UUCP>
Date: 2 Feb 88 20:43:44 GMT
References: <19880126193720.1.JRD@GRACKLE.SCRC.Symbolics.COM>
Organization: Atari Corp., Sunnyvale CA
Lines: 33

in article <19880126193720.1.JRD@GRACKLE.SCRC.Symbolics.COM>, 
jrd@STONY-BROOK.SCRC.Symbolics.COM (John R. Dunning) says:

> [...] or at least the get TOS to give control back to me
> with a pointer to the crash data.  I would expect there to be some sort
> of OS call for this, but haven't seen it.
> 
> Related question:  Does MUSHROOM.PRG work?
> Is there a better substitute for MUSHROOM, or
> documentation on where to find the crash data and how to interpret it?

If you mean the MUSHROOM.PRG from Silas Warner (a PLATO programmer from
way back, and author of Castle Lichtenstein (?) on the Apple ][), it does
work as far as it goes, but then it causes bombs and overwrites all that
stack information.

There is no TOS call to get control in bomb-like situations.  Since you
ask for one, it is possible that you don't have enough understanding of
68000 exceptions to port the debugger.  I wrote an ultra-cool debugger
for the ST, and it handles all the bomb-type errors.  You have to take
over the exceptions (bus error, address error, illegal instruction,
etc.) yourself. 

The Hitchhiker's Guide to the BIOS has the definitive description of the
bomb-save area.  It contains the values of all the registers, including
PC, USP, and SSP, and the top few words of the supervisor stack at the
time of the bomb.  The format can be found in the Guide, and possibly
in such places as Abacus books (but I *never* trust an Abacus book to
get it right.)

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt