Path: utzoo!mnetor!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!pacbell!att-ih!att-cb!clyde!watmath!watcgl!lily!jafischer
From: jafischer@lily.waterloo.edu (Jonathan A. Fischer)
Newsgroups: comp.sys.atari.st
Subject: Re: TRAP handler question
Message-ID: <3806@watcgl.waterloo.edu>
Date: 30 Mar 88 19:29:28 GMT
References: <3738@watcgl.waterloo.edu> <197@bdt.UUCP>
Sender: daemon@watcgl.waterloo.edu
Reply-To: jafischer@lily.waterloo.edu (Jonathan A. Fischer)
Organization: U. of Waterloo, Ontario
Lines: 27

[]
	First off, thanks for your response, David.  Exactly why I posted the
question.  Oh yeah, and by "bug" I was really referring to a bug in the way I
was trying to do it, certainly not a bug on the ST's part.

	Since I posted the question, I've hardly had any time for further
twiddling, but I did discover that in fact, a7 was pointing to the supervisor
stack, although db.prg, after stopping the program at the breakpoint, had a7
pointing to the user mode stack.  That's where the main confusion lay.  I did
a dump of the supervisor stack and discovered that that's what my program was
examining.  And the words that were changing after the 'cmpi' instruction were
_from_ the supervisor stack.  I.e., when the breakpoint was reached, telling
db.prg to print out the stack (by saying "a7,6?x") resulted in:
	XXXX XXXX 0000 0009 YYYY YYYY
and after stepping through the 'cmpi' instruction, saying "a7,6?x" showed:
	XXXX XXXX AAAA AAAA YYYY YYYY,
where AAAA AAAA is the second longword from the supervisor stack, not the user
stack.  Weird or what?

	Well, I'll see what I can do as to actually trapping everything that
prints to the screen, rather than trapping Cconws().  And I'm implementing the
VT52 escapes in a lazy way, in that I just pass them to the real Cconws(). 
Didn't want to reinvent the wheel as far as that goes.
--
	- Jonathan A. Fischer,    jafischer@lily.waterloo.edu
...{ihnp4,allegra,decvax,utzoo,utcsri}!watmath!lily!jafischer
	Pascal SUCC()'s.