Xref: utzoo unix-pc.general:3988 comp.sys.att:7917
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!rutgers!mit-eddie!andante!ulysses!dptg!mtunb!jcm
From: jcm@mtunb.ATT.COM (was-John McMillan)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: 68020/68881 Anyone?
Summary: gack
Keywords: faster faster faster
Message-ID: <1689@mtunb.ATT.COM>
Date: 30 Oct 89 14:44:25 GMT
References: <13@bagend.UUCP> <2457@umbc3.UMBC.EDU>
Reply-To: jcm@mtunb.UUCP (was-John McMillan)
Organization: AT&T ISL Middletown NJ USA
Lines: 28

In article <13@bagend.UUCP> jan@bagend.UUCP (Jan Isley) writes:
[ discussion about adding a 6820/68881 daughter board ]
>I am neither a software or hardware gooroo, can't even spell it, but some
>preliminary questions come to mind for the gurus out there:
>
>  Are there any *known* reasons why an 020/881 would present a problem 
>  hardware wise?  I think this would be the easy part?
>
>  Any 020/881 fatal code in the software?

1) I believe the 68020 interrupts generate a longer/different
	restart vector.  (Since poltergeists have taken my manual
	I cannot confirm this.)  The likely result of this is the
	BOOT ROMS, kernel and diagnostics won't work without
	re-writing.

2) I "have been told" that the 68020 control timings (address assertion,
	etc.) are radically altered, and many of us know how narrow
	the 3B1's tolerances are.  Wouldn't it would be awkward to
	guarantee the reliability of any such mod'.

3) The ain't much room in the inn.  Where wouldja hang the mess?

4) Those who interfaced a 68881 w/in AT&T were NOT impressed with
	the gains.  The overhead of managing the chip reduced its
	floating point advantages.

john mcmillan	-- att!mtunb!jcm