From: tetragon@werple.apana.org.au (Gavan McCormack)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: 14Mhz A500 mod info wanted
Date: 14 Oct 92 17:06:49 GMT
Organization: werple public-access UNIX, Melbourne
NNTP-Posting-Host: werple.apana.org.au

grr@cbmvax.commodore.com (George Robbins) writes:

>In article <doiron.0fhd@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
>> In article <35539@cbmvax.commodore.com> grr@cbmvax.commodore.com (George Robbins) writes:
>> > In article <in2a505.717946124@rzaixsrv1.rrz.uni-hamburg.de> in2a505@rzaixsrv1.rrz.uni-hamburg.de (Elvers) writes:
>> > > e52382015@violet.ccit.arizona.edu (EDDY, JONATHAN GABRIEL) writes:
>> > > 
>> > > >I got a file from wuarchive the other day that describes a processor swap
>> > > >for the A500.  You take out the 7Mhz one, and put in a 16Mhz 68000, plus
>> > > >a timing circuit(?), and viola, you have a 14Mhz A500, which should a 
>> > > >+70% performance boost.  Does this work???  I would love to do it, but would 
>> > > >rather be sure it worked.  Heck, at $25, I'll probably do it anyway, but
>> > > >please warn me if I shouldn't.
>> > > >Thanks!
>> > > 
>> > > >jon eddy.
>> > > 
>> > > I did it, and it works !! 
>> > 
>> > Of course it may not work on your particular machine, the A500 "Gary"
>> > gate array and associated logic were not designed with 14MHz in mind
>> > and it is a small miracle that it works at all on any systems.
>> > 
>> > If you want a real headache, start trying to work out all the details
>> > required to make a "spec" 14MHz double speed processor speedup...
>> 
>> Actually, in hacks like these (unless they've changed), only the CPU is
>> clocked at 14mhz, not the rest of the chips.  The result is a 5%-10%
>> speedup (maybe 25 if you're doing lots of multiplications/divisions).
>> Hardly worth the $25 you spend on parts.  It's like the "CMI Processor
>> Accelerator", I'm sure some people here can tell you about THAT thing.

>Most of them are pretty crude.  Having the processor running at 14MHz
>results in the 8520's running at double speed and results in Gary seeing
>signal transition at "unexpected" times relative to the 7MHz processor
>spec's it was designed to, especially with the delay between 28MHz/2
>and the output clocks from Agnus being unspecifed and rather dependent
>on process and temperature.  Gary wasn't designed to support asynchronous
>operation, but manages to limp along well enough for some folks.

>Delaying the _DTACK input on the processor by clocking it on the rising
>edge of the 7MHz processor clock would clean up a lot of the timing
>violations by preventing the processor cycles from "ending early", but
>I don't claim it really makes things right.

>-- 
>George Robbins - now working for,     work:   to be avoided at all costs...
>but no way officially representing:   uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
>Commodore, Engineering Department     domain: grr@cbmvax.commodore.com

This may be a `past' thread, but I'll give it a go anyway,...
Installation 14MHz mods are usually as follows,

There are 3 ways I have seen this done, 
1. Halving the 28MHz clock. This hsa the disadvantage that this clock
can be weak, meaning that the wires must be short, and although
switching `on the fly' is possible with a flip-flop, its flaky, because
of delay problems associated with clock signals.
Also, because the 28MHz clock is used, anything that uses ExClk dosent
work. eg: Genlocks etc.

2. Exclusively Or-ing /7M and CDAC. Advantages are that it uses valid
system clocks, so genlocking is possible (though *I* havent tested this)
and theese lines are more accessible. Disadvantages are that CDAC itself
can be of poor signal quality, _Especially_ on pre-Ecs Agnus, meaning
that it may not work at all. Also, I have found that logically (ie: with
a ff) `switching on the fly' is impossible, although using a cmos
hi-speed analog switch will get you by 99% of the time.

3. Using a delay in the 7M line to produce a psuedo CDAC signal and X-or
the signals. This I dont recomend. It has the disadvantages of both the
first two methods (except for 28M/CDAC sig. degradation) and can be
extremely flaky.

Also, dont underestimate the advantages ~$20 of components can give.
Sure, when the 68k is running in chip, there is no speedup, but for
internal stuff like intensive math, then you eill notice the difference.
But it will really bring results when used with true fast-ram. 

Ofcourse you still have disadvantages that all methods have, ie:
overclocking of the CIA's, but this can actually be an advantage, if you
have a disk drive that can handle fast stepping, and besides, dosent
anybody _want_ faster disk access? Ofcourse you can get around this
problem, either by using CIA slowdown hacks ,and I have seen some, or by
either slowing the cpu down during disk transfers or using a trackdisk
fixer program like DFDelay.

There are other problems such as heat stress in the 16M 68k, but if
you're sensible about it, it shouldnt be a problem.

So if you think it is worth `$20 -$30 I say give it a try, just get all
the info first. It isnt dificult unless you dont know what you are
doing. I hope this will help _someone._

For more info, feel free to email me.

Gavan McCormack.
		tetragon@werple.apana.org.au
`Apologies for typo's, misconceptions, illogical statements, etc.'
Newsgroups: comp.sys.amiga.hardware