Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!uunet!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Use of SuperState() call
Message-ID: <7019@cbmvax.UUCP>
Date: 31 May 89 16:57:26 GMT
References: <10975@behemoth.phx.mcd.mot.com>
Organization: Commodore Technology, West Chester, PA
Lines: 67

in article <10975@behemoth.phx.mcd.mot.com>, mph@behemoth.phx.mcd.mot.com (Mark Huth) says:
> Keywords: supervisor guru
> 
> 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.  

It's probably nothing to do with the cache; more on that in a bit...

> 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?

Yup.  For starters, UserState() is broken, at least on 68020/30 machines.
So you can never get back that way.  Here's how I do it in SetCPU:

	LVOSupervisor	EQU	-30

	;======================================================================
	;
	;	This function sets the value of the 68020/68030 CACR register.  
	;	It assumes a 68020 or 68030 based system.
	;
	;	void SetCACR(cacr)
	;	ULONG cacr;
	;
	;======================================================================

	_SetCACR:
		move.l	4(sp),d0		; New CACR is on stack
	 	move.l	4,a6			; Get ExecBase
		btst.b	#AFB_68020,ATNFLGS(a6)	; Does the OS think an '020 is here?
		bne	1$
		rts				; No CACR here, pal
	1$
		move.l	a5,-(sp)		; Save this register
		lea	2$,a5			; Get the start of the supervisor code
		CALLSYS	Supervisor
		move.l	(sp)+,a5		; Give it back
		rts
	2$
		movec	d0,cacr			; Set the CACR
		rte

Note that the Supervisor function isn't often mentioned.  I figure the main 
reason for that is that, as it's exited via RTE instead of RTS, it can't be
called directly from C.  In any case, this method will work on your A2620.

If you installed your A2620 yourself, and you're using a DMA driven hard
drive, you may have a known problem.  A2000s built with a 74ALS245 bus driver
chip made by Signetics at the U605 position can run into trouble with DMA
and an A2620 or possibly any other fast Coprocessor card that supports DMA
into it's fast memory.  The problem is that with the Signetics part, a
critical expansion bus signal doesn't get pulled up fast enough at the end
of a DMA transfer.  Changing the buffer chip would of course fix the problem,
but the suggested fix (dealers are supposed to know this) is to add a 3.3k
pullup resistor to the signal in question.  This resistor goes between pin
20 and pin 11 of U605.  The Signetics part can be identified by a big "S"
on it; no other manufacturer's part has shown any signs of this problem.

> Thank You,
> Mark Huth
-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession