Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: Two problems with home-build '020 accelarator. Help needed.
Message-ID: <22708@cbmvax.commodore.com>
Date: 26 Jun 91 19:27:33 GMT
References: <1991Jun19.192747.6888@rulway.LeidenUniv.nl>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 55

In article <1991Jun19.192747.6888@rulway.LeidenUniv.nl> breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes:

>Problem I
>SetCPU V1.6 locks up the machine completely. Maybe this is
>caused when SetCPU executes a MMU instruction. Our board
>only responds to FPU instructions, because it decodes the
>FCx lines and A13 through A19. The '020 probably
>never receives a *DSACKx and will wait forever...
>Has anyone encountered this problem? Are there official 
>guidelines that solve this kind of problems?

That shouldn't be a problem, because SetCPU is clever about the way it asks
for an MMU.  It runs a supervisor mode MMU instruction which maps as a valid 
user-mode FPU instruction.  If the MMU is present, the code takes a privilige
violation.  If the MMU isn't there and the FPU is quiet, the code takes an
F-line exception (all coprocessor space codes are F-line).  If the FPU responds
as an MMU, no exception is taken.  

I don't think you have to do anything special to get the F-line to happen in
the absence of the MMU.  For the missing FPU, you need to decode FPU space and 
generate a bus error to get an F-line exception, but the FPU is a slave
coprocessor, while MMUs are master coprocessors and generally take care of
everything themselves.  I never built one without the MMU, so I'm a little
unclear on that part of the coprocessor protocol.

>Problem II
>The other problem occurs when booting a Promigos harddisk.
>This hd starts up, but after a few startup-sequence commands,
>it crashes (guru 4). Since all other software works great,
>we suspect the hd-device driver software to cause the problem.

If this is a DMA-driven hard disk controller, you may have some marginal
timing in your bus arbitration logic, but in general, bus arbitration mess
ups result in hanging, not crashing.  The most common result of hardware
related memory corruption is the level 3 and 4 exceptions, which can result
in a DMA system if one device gets on the bus before the current master 
gives it up.

On the other hand, if you're dealing with a programmed I/O hard disk, I would
suspect the software before anything else.  Most driver code these days is
tight coded assembly code, they have been having "speed wars" in the hard disk
business.  That's a bit more prone to errors and 680x0 family compatibility
problems than the C or M2 used for many application programs.  Alternately, you
may have some 68000 bus timing disagreement between your board and the disk
controller hardware.  You might be marginally off the 68000 timings, or they
may be counting on observed behavior of a particular 68000 production run (eg,
what their development system looked like on the 'scope), rather than the spec
sheet.



-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
	"This is my mistake.  Let me make it good." -R.E.M.