Path: utzoo!attcan!uunet!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.m68k
Subject: Re: 68000 vs. 68020 question.
Message-ID: <5613@cbmvax.UUCP>
Date: 3 Jan 89 18:40:05 GMT
References: <322@cstw01.UUCP>
Organization: Commodore Technology, West Chester, PA
Lines: 75

in article <322@cstw01.UUCP>, meulenbr@cstw01.UUCP (Frans Meulenbroeks) says:

> I've been upgrading my 68000 system by replacing the 68000 with a 68020
> using 16 bit bus cycles (and the addition of some glue to generate
> things like E and VMA).
> The system runs on the same clock frequency.
> The upgrade works, but leaves the following question:
> The expected performance gain due to the cache is not realised.
> I expected the 020 to run about the same speed as the 68000 with the
> cache disabled and about 20-30% faster due to the cache.

No, the '020 will actually run slower in most cases on a 16 bit bus, with
cache disabled, than the 68000 will.  As you guessed below, the cache
pre-fetch is to blame -- whether the cache is enabled or not, the '020
will always fetch a full longword for instruction fetches.  Half of the
pre-fetched longword may not be used, especially if the cache is turned
off.  With the cache on, you get the advantage of caching the whole longword,
plus normal other cache benefits that generally make the '020 come out
faster, though depending on application, maybe not all that faster.  The
'030 extends this "feature" to data fetches as well, so you will find that
the '030 with caches disabled on a 16 bit bus runs a little slower than
the '020.

> - is the above scenario a plausible explanation (the instruction used in
>   the test was a NOP).

Yup.

> - will the 020 start instruction execution while the second bus cycle is
>   still in progress?

I don't think so; though I've never actually proven it, based on the way I
think the cache fetch mechanism works, this would be impossible.

> - if I want to speed up the 020 by going to 16 Mhz (synchronously with
>   the system clock) at which signals should I pay attention. 
>   I know that I should look at DSACK/DTACK since they may be asserted
>   before data are valid on a read cycle. Also AS loooks like something
>   to look at. Anyone knows about other signals to keep an eye on?
>   Any suggestions about the problems that may occur on write cycles??

You may be able to simplify the design based on Atari ST particulars, but
in general, you have to emulate important edges of the 68000.  These include:

	- Clock external /AS during S2, and /UDS-/LDS during S2 (READ) or 
	  S4 (WRITE).

	- Only sample /DTACK on the falling edge of S4.

	- Sample data on the falling edge of S6.  Depending on what the ST and
	  any peripherals may do, you may have to latch it.  Also, you'll have
	  to coordinate your assertion of /DSACK1 to this, making sure your
	  '020 will have data in time.

	- Always end your external cycles on S7.  I end my internal cycles
	  slightly after S7.

	- You may have to clock /BG on the 68000's 8MHz clock, depending on
	  the assumptions of the system (eg, how dependent is the external
	  system on the 68000 specs).

	- You may have to sample the /IPL0-2 lines on an 8MHz clock, again
	  depending on the external system.

That should be enough to get it doing something interesting.

> Many thanks!
> -- 
> Frans Meulenbroeks        (meulenbr@cst.prl.philips.nl)
> 	Centre for Software Technology
> 	( or try: ...!mcvax!philmds!prle!cst!meulenbr)
-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession