Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!rutgers!ucla-cs!zen!ucbvax!renoir.Berkeley.EDU!robinson
From: robinson@renoir.Berkeley.EDU (Michael Robinson)
Newsgroups: comp.sys.amiga
Subject: Re: 14.31818 MHz 68010 Upgrade
Message-ID: <20005@ucbvax.BERKELEY.EDU>
Date: Thu, 6-Aug-87 22:17:35 EDT
Article-I.D.: ucbvax.20005
Posted: Thu Aug  6 22:17:35 1987
Date-Received: Sat, 8-Aug-87 14:56:49 EDT
References: <19965@ucbvax.BERKELEY.EDU> <2184@cbmvax.UUCP>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: robinson@renoir.Berkeley.EDU.UUCP (Michael Robinson)
Distribution: na
Organization: University of California, Berkeley
Lines: 56

In article <2184@cbmvax.UUCP> George Robbins write:
>In article <19965@ucbvax.BERKELEY.EDU> I write:
>> 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.

Sorry if I wasn't clear.  The circuit does not exist yet, but will if I 
decide to make it.

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

Exactly why I am concerned about the behavior of "fast" memory expansion.

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

I do not want faster cycles, but rather maximum usage of the cycles that
are already there.  That is, by doubling the speed of a 68010, it will
access the bus on every system cycle, rather than every other system 
cycle.

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

The design I have is extremely simple and inexpensive (<$20), and if I
can make it work without extra headaches, all the better.

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

Since I do not intend to go to the trouble of #3, #4 is equally out of 
the question.

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

This is what I need to know--which boards to demand/contention refresh,
and which boards cheat.

------------------------------------------------------------------------------
Mike Robinson                                 USENET:  ucbvax!ernie!robinson
                                              ARPA: robinson@ernie.berkeley.edu