Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!cbmvax!grr
From: grr@cbmvax.UUCP (George Robbins)
Newsgroups: comp.sys.amiga
Subject: Re: 14.31818 MHz 68010 Upgrade
Message-ID: <2184@cbmvax.UUCP>
Date: Thu, 6-Aug-87 11:43:46 EDT
Article-I.D.: cbmvax.2184
Posted: Thu Aug  6 11:43:46 1987
Date-Received: Sat, 8-Aug-87 14:17:30 EDT
References: <19965@ucbvax.BERKELEY.EDU>
Reply-To: grr@cbmvax.UUCP (George Robbins)
Distribution: na
Organization: Commodore Technology, West Chester, PA
Lines: 37

In article <19965@ucbvax.BERKELEY.EDU> robinson@renoir.Berkeley.EDU (Michael Robinson) writes:
> I have located part numbers and suppliers for a circuit which will deliver
> an exactly doubled, crystal controlled, syncronized clock signal to a 
> 16MHz 68010 sitting on a daughter board in the processor socket.
> 
> This will, in theory, double (plus some) the processor speed of the
> Amiga.  To the rest of the system, this will mean the processor will be
> making data requests every clock cycle, instead of every other. 

	I am not familiar with a 68010 board of this description, however
	there are some common issues to consider.

	1) even if the processor is running at twice the speed, it must
	   externally emulate a 68000 to interact with the on-board logic
	   and to access the onboard RAM.  This would mean that multi-cycle
	   instructions would go faster, but memory bound ones would not.

	2) expansion RAM could conceivably handle faster cycles by returning
	   DTACK themselves, rather than accepting the default system timing,
	   however i am not aware of any boards that do this.

	3) for real speed, you would have to put some RAM on your adapter
	   board that runs a roughly processor speed.  Life will soon become
	   complicated.

	4) if you're going to all the trouble to do the above, you might as
	   well use a 68020 and get some real performance.  The software
	   already supports this.

	5) some memory boards use traditional demand/contention based
	   refresh, others use hidden refresh, knowing that unless they
	   do something special, memory cycles are double length.

-- 
George Robbins - now working for,	uucp: {ihnp4|seismo|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@seismo.css.GOV
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)