Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!labrea!aurora!ames!sdcsvax!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: <20038@ucbvax.BERKELEY.EDU> Date: Sun, 9-Aug-87 14:45:45 EDT Article-I.D.: ucbvax.20038 Posted: Sun Aug 9 14:45:45 1987 Date-Received: Sun, 9-Aug-87 22:40:48 EDT References: <19965@ucbvax.BERKELEY.EDU> <204@dana.UUCP> <942@omepd> Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: robinson@renoir.Berkeley.EDU.UUCP (Michael Robinson) Distribution: world Organization: University of California, Berkeley Lines: 44 In article <942@omepd> hah@mipon3.UUCP (Hans Hansen) writes: >In article <204@dana.UUCP> rap@dana.UUCP (Rob Peck) writes: >>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. >[devil's, devil advocate mode on] > >2) Not all 68K cycles are also memory cycles. Therefore all multiple >processor cycles will be sped up. The big win (which many people seem to be overlooking) is that the 68000 and 68010 only use half the memory bandwidth available (the "every other" phenomenon). This circuit will hopefully remedy that situation. >***** Problem ***** > >The R/W access of a 68000/68010 running at 14MHz will not allow sufficient >address setup time for the DRAMs and the 8520s. A 1 micro cycle delay is >needed during all reads and writes to the existing DRAM and 8520s. I >proposed such a circuit to Bill Kolb in Dec 1984 or Jan 1985. never followed up on due to the lack of 14.5MHz 68000/68010s at that time.> How is this so? According to my 68000 timing diagrams, the address lines are set and stable upon assertion of AS, and will remain so for at least one and a half processor cycles after assertion of DTACK. Supposedly, the processor should not get DTACK until the address has been decoded and there is valid data on the bus. I thought that was the whole point of asynchonous bus control. If this is not the case with the Amiga, why not? >Second problem: The TrackDisk device will need to be tuned. Why? >Third problem: Copy protected programs will for the most part not load. Well, f*@# them. For me, doubled performance is more important than catering to juvenile paranoia. ------------------------------------------------------------------------------ Mike Robinson USENET: ucbvax!ernie!robinson ARPA: robinson@ernie.berkeley.edu