[mod.computers.68k] Why I wanted to know about exception handlers

RDROYA01@ULKYVX.BITNET.UUCP (05/18/86)

Yes, I saw your first response.  I looked at the sources to my BIOS.  The
BIOS doesn't do anything, after cold start-up, to re-initialize exeception
vectors.  Should it?  I also discovered that the signal function is funny.
It will catch all traps except trap #1, which still gets through as an
exception.  I should add that it doesn't, of course, catch traps 2 or 3. I
also discovered that it is very difficult to figure out what is going on
with the signal as it does not seem to do anything to the vectors.  DDT
shows the vectors remain unchanged directly before a trap and after.  But
the trap handler does work!  My BIOS catches trap #2 to test for a special
floating point co-processor function.  But if the function number is not
85, it just jumps to BDOS.  The direct BIOS call to set an exception vector
works every time.

The reason I want the CCP to handle the program load.  Well, I don't
actually.  It's just that my word processing program had no dir command,
and rather than write one I set up a signal routine that jsr's to the ccp
_main entry.  This allows any ccp command to be issued, and no errors.
Even the submit function works.  The only problem was if, being sloppy, I
type STAT or some other transient utility's name at the ccp prompt, it
tries to load the program and fails with a priviledge violation.  I just
wanted to be able to recover from this potential disaster and not have to
give up the built-in commands that the ccp gives me.  Also I discovered
that the DDT overlay will load successfully from the ccp even from within
the word processor.  So I believe that the ccp could be used to load any
program with the proper exception handler. Loading additional programs into
memory is rather useless, however, if they each reset when they exit
because you couldn't get back to the original program.  I have also had a
number of problems getting the program load function to work on a regular
basis.

I have another question.  Is it possible to reset the trap #2 vector so
that the reset call could be intercepted?  I thought, for instance, that
trap #4 could be given the present trap #2 vector, that trap #2 would lead
to a routine which would test to see whether d0=0, and whether to call a
trap #4 or service the request itself. That way a transient program could
test an internal flag to see whether the call to reset was from another
loaded program or from itself.  It could then decide whether to pass the
reset call on or not.  What I'm looking for is a way to run the compiler
and linker from "within" microEmacs.  I think I could figure a way to look
at the output from these programs, interpret it and pop back into a buffer
at offending lines, or at least keep a copy of the error messages in a
buffer to do the line hunting manually.