Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!rutgers!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: 14 Mhz Hack
Message-ID: <21510@cbmvax.commodore.com>
Date: 13 May 91 17:37:25 GMT
References: <1991May10.104421.22314@rulway.LeidenUniv.nl>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 97

In article <1991May10.104421.22314@rulway.LeidenUniv.nl> breemen@rulcvx.LeidenUniv.nl (E. van Breemen) writes:

>I have received a lot of mail lately of people who asked me how I made
>the 14 Mhz Hack work. It is very simple, just follow the guidelines of 
>Dave H. I know, a lot of people think they are smart and can avoid all the 
>stuff which Dave writes about. 

And there's a pretty good reason for that.  No, not that I'm some kind of 
super wiz or anything.  Mainly, these guidelines (from the '89 DevCon notes
and stuff posted here) were developed by me over the course of the A2620,
A2630, and A3000 development.  Being that these were done by Commodore, I
really didn't have the option of taking any shortcuts or being incompatible
with any hardware out there that was possible to support in any way.  It's
doubtful that anyone hacking parttime on these goodies is going to come 
across some dramatically simple and elegent shortcut to compatibly get around
the stuff I've been working reasonably fulltime hours on for four or so years.

>They may seem to work for 1 minute, 1 day but sooner or later they will break
>down. 

That's actually the expected behavior for the kind of failure you're likely
to see when you take shortcuts, especially the more drastic and unobvious
shortcuts people take when designing "asynchronous" accelerators, trying to
avoid taking synchronization delays.

>The reason why it jumped is still not clear to me, but it disappeared as
>soon as I sampled the DTACK only at the end of S4. Before the end of S4,
>the DTACK is not valid. 

That's actually a convention right out of the 68000 book, and the Amiga
system takes full advantage of it.

>I think that the Amiga can give DTACK for example in S3 but pull it up again 
>in the beginning of S4. So if you sample DTACK at any time, you can read an 
>invalid DTACK. 

There are actually two problems in sampling DTACK early.  DTACK is managed in
all pre-A3000 systems based on address space, either by Gary (A500, A2000) or
a PAL that does the same thing.  First of all, for a number of address spaces,
DTACK is driven directly from AS, so it may come out in S2 or S3.  That's the
first problem.  The second problem is that, for expansion space, DTACK may be
controlled by an expansion board.  Such a board can't start it's control logic
until it sees AS.  But remember, AS will be making a DTACK instantly.  So by
the time the expansion board has delayed (via XRDY) or taken over (via OVR) the
system DTACK, it's already low.  The board's timing on XRDY and OVR will get
DTACK back up again long before S4.  Any accelerator card that though it could
sample DTACK prior to the S4/S5 edge, however, may see these false DTACKs and
incorrectly handle the cycle.

It's actually a little cleaner on the A3000.  The only DTACK in the system is
on the expansion bus.  This is typically driven during S3, giving any Zorro II
card a chance to OVR or XRDY before DTACK ever goes low.  This is functionally
the same, but makes things a little less noisy.

>The Amiga can do this if it sees that the processor can't finish the buscycle
>in time (Dave correct me if I am wrong). 

The on-board DTACK logic never asserts, then negates, DTACK on its own like
that.  The only wait states inserted are for Chip cycles, and the Gary or
Gary equivalent knows whether a wait will be necessary before DTACK is ever
sent out.  The false early DTACK, as I mentioned up above, is the result of
interaction with expansion cards.  And a perfectly valid part of the 68000
bus protocol.

>A month ago, I found another problem. My board broke down, after a lot of
> AND #$..,$bfe001 instructions. This is a read/write instruction with an 
>E-clock. First thought: the E-clock emulation is bad. Wrong! I didn't 
>synchronize the AS. After the E-clock cycle, the Amiga sometimes didn't 
>see a flank for sampling the AS. Result: Guru.

Yup, you really want to synchronize AS* and DS*.  The Amiga chips themselves
aren't really sensitive to this, but some of the bus control logic, like Gary,
as well as expansion cards, may be very sensitive to when AS* happens.

>For me the 14 Mhz started as Hack with one Flipflop and a 12.5 Mhz processor.
>I ended up with a 16 Mhz processor and 7 chips (no wire needed for CDAC).
>This is really a minimal configuration, so all the boards using just 2 or 3 
>chips won't work, it is sad but true.

Sounds good.  I never sat down and figured out the proper way to do a 68000
speedup, I have only dealt with the 68020/30 bus processors.  Similar rules
apply for either, though.  And while the A2620/30 might be optimized a bit
were I to do it all over again, they could never be trivial designs and still
be as compatible as they are.  

>BTW To the designers: don't publish your board before it works 100%. It
>will avoid a lot of anger and disappointment.

Really.  This original 14MHz hack seems to have generated an amazing amount
of news, and probably an even larger number of grumbles from people who had
problems with it.  At the very least, if you post something before it's been
through a suitable acid test, surround it with bright red flags that indicate
it may cause problems.
-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
      "That's me in the corner, that's me in the spotlight" -R.E.M.