Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site calma.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!sun!calma!hedges
From: hedges@calma.UUCP (Tom Hedges)
Newsgroups: net.micro.mac
Subject: Re: Re: Hyperdrive 2000 info from GCC
Message-ID: <139@calma.UUCP>
Date: Mon, 3-Feb-86 13:53:17 EST
Article-I.D.: calma.139
Posted: Mon Feb  3 13:53:17 1986
Date-Received: Wed, 5-Feb-86 01:31:47 EST
References: <412@sol1.UUCP> <290@ius2.cs.cmu.edu> <263@tolerant.UUCP>
Reply-To: hedges@calma.UUCP (Tom Hedges)
Organization: GE/Calma Co., R&D Systems Engineering, Milpitas, CA
Lines: 17

In article <263@tolerant.UUCP> berry@tolerant.UUCP (David Berry) writes:
>
>	I would think that the 16Mhz 68020 would actually break less software
>than the 12Mhz 68000, since it has a superset of the 68K instruction set and
>the double speed clock should be significantly easier to drop down to 8Mhz
>when absolutely necessary.  The only that should be timing dependent anyway
>is copy protection code that does it's own searching for file marks.

   Another unavoidable area of timing dependence is the Sound Buffer filling
code. Since the sound buffer is a fixed location and length and DMA occurs
comtinuously wrapping from end to front, it is necessary to 'lead' DMA
load address in hardware, known as the 'beam', by a phase factor that is
necessarily CPU timing dependent. This factor is fairly clock insensitive,
but a change of 2 to 1 or more would probably cause problems, especially
with some of the newer sound products that don't use the ROM sound driver.

   Tom Hedges