Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cbmvax!bagate!dsinc!unix.cis.pitt.edu!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!psuvm!blekul11!ghgaqa4
From: GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: 68000 Exceptions
Message-ID: <91158.111341GHGAQA4@cc1.kuleuven.ac.be>
Date: 7 Jun 91 11:11:41 GMT
References: <phil.676256558@adam.adelaide.edu.au>
Organization: K.U.Leuven - Academic Computing Center
Lines: 48

>What doesKS13 do when the 680[01]0 processor gets an F-line exception?
>Does it just bring up the GURU Alert or does it check for the presence
>of a coprocessor (68881.resource??) and then pass control to it if it
>exists?

If you have a 6888(1 or 2) you will not get an F-line exception
(provided you have a 68020 or 30). I don't know what will happen when
you use the 68000 or 10 with a coprocessor. My guess is that you will
get a GURU alert saying F-line exception. I don't think KS1.3 handles
this (but I may be wrong ofcourse).

>Is there an OS friendly way of inserting exception vectors, rather
>than for example:
>
>    LEA      MyException, A0
>    MOVE.L   A0, FLine_exception_vector
>
>Which would really annoy the Enforcer?

You have several options for this.
  1. Use the above code but execute it in supervisor (With the
     execbase SuperVisor function). That way, enforcer will not
     complain (I think). If Enforcer still complains you can use
     special supervisor instructions to move values in memory without
     using the MMU table, but I don't know these instructions from
     memory (I think MOVES is the one).
     Ofcourse this is not very OS-friendly.
  2. You can handle all the exceptions if you set the TC_TRAPCODE
     (or something like that) field in your task structure to your
     own routine. This routine will be executing in supervisor mode.
     The top of the (supervisor) stackframe will contain a longword
     with the exception number. The rest of the stackframe is the
     680x0 exception stack frame. To end this routine you must
     remove the longword (put there by Exec) and execute RTE (return
     from exception). This way you are OS-friendly but you can only
     trap exceptions for one task (or rather, for each task you
     patch this way).
  3. There is still another way. You can use the TRAPCODE field in
     the exec base structure. The only problem with this approach, is
     that the task-held or software error requester will appear before
     your exception routine is called. I don't know how to solve this
     (except by patching AutoRequest, EasyRequest, ...). Maybe someone
     else has an idea ?

>Thanks,
>Phil.

                           Jorrit Tyberghein