Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!noao!asuvax!behemoth!mph
From: mph@behemoth.phx.mcd.mot.com (Mark Huth)
Newsgroups: comp.sys.amiga.tech
Subject: Use of SuperState() call
Keywords: supervisor guru
Message-ID: <10975@behemoth.phx.mcd.mot.com>
Date: 30 May 89 22:12:52 GMT
Reply-To: mph@behemoth.UUCP (Mark Huth)
Organization: Motorola Microcomputer Division, Tempe, Az.
Lines: 35

While working this weekend on my 2620 system I experienced a lot of
gurus.  In an attempt to isolate the cause, I wanted to turn of the
cache.  I don't have SetCPU yet, so I decided to try some real simple
assembly code.

INCLUDE "exec/types.i"
INCLUDE "exec/libraries.i"
INCLUDE "exec/????.i" - you know, the one where the function offsets
			get defined

AbsExecBase EQU 4
CacheOff EQU 8

start:
	movem.l d0-d7/a0-a6,-(a7)	save regs
	movea.l AbsExecBase.w,a6	sets exec lib base register
	callsys SuperState		get into supervisor mode
	moveq.l #CacheOff,d1		constant to disable cache
	movec   d1,cacr			write it to the cache control reg
	callsys UserState
	movem.l (a7)+,d0-d7/a0-a6
	rts


This program reliably gurus - 3 or 4, don't remember.  When I trace
into the code with Lattice CPR, I lose it when the trap occurs - not
real surprising.  But looking at the code that is disasembled in the
trap handler, this should work great.  I've tried not tracing through
the exec call, but I never get control back from the SuperState call -
it's always off to the guru.

Is there a secret that I'm missing?

Thank You,
Mark Huth