Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!mcsun!hp4nl!rulway.LeidenUniv.nl!rulcvx.LeidenUniv.nl!breemen
From: breemen@rulcvx.LeidenUniv.nl (E. van Breemen)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: Two problems with home-build '020 accelarator. Help needed.
Message-ID: <1991Jun27.084032.28883@rulway.LeidenUniv.nl>
Date: 27 Jun 91 08:40:32 GMT
Article-I.D.: rulway.1991Jun27.084032.28883
References: <1991Jun19.192747.6888@rulway.LeidenUniv.nl> <22708@cbmvax.commodore.com>
Sender: root@rulway.LeidenUniv.nl (System PRIVILEGED Account)
Organization: Leiden University, the Netherlands.
Lines: 27
Nntp-Posting-Host: rulcvx.leidenuniv.nl

In article <22708@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes:
>In article <1991Jun19.192747.6888@rulway.LeidenUniv.nl> breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes:
>
>everything themselves.  I never built one without the MMU, so I'm a little
>unclear on that part of the coprocessor protocol.

We have decoded the FPU completely. The problem is that if you address an non
existing MMU, the M68020 will wait for DSACK forever (the FPU won't respond to
it) and the machine 'hangs'.
>
>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

Our board works just fine with an A590 harddrive, so DMA is not the problem.

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

We have been able to patch the driver software by adding some nop's and
everything works just fine.

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

Erwin van Breemen and Raymond Hoving.