Path: utzoo!attcan!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!hp4nl!philmds!prle!cstw01!meulenbr
From: meulenbr@cstw01.UUCP (Frans Meulenbroeks)
Newsgroups: comp.sys.m68k
Subject: 68000 vs. 68020 question.
Message-ID: <322@cstw01.UUCP>
Date: 2 Jan 89 09:15:14 GMT
Reply-To: meulenbr@cst.UUCP ()
Organization: Centre for Software Technology, Philips Eindhoven
Lines: 45

Happy New Year.

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.

However this does not hold.
The system (an Atari ST) has the video memory access interleaved with
the cpu. This means that every 4 clock cycles the video makes a memory
access. Normally this runs quite smooth.

The upgraded system shows some performance degradation, due to different
timing.
Measurements with an analyser have lead to the following theory:
Somewhere in the 020 user manual it is stated that instruction prefetch
is always a longword operation. This results in two bus cycles when
using a 16 bit bus. In the simplest case two instructions are fetched.
One is executed during the prefetch. The other one cannot complete in
time, thus needing an extra clock cycle to complete. 
This extra cycle however, causes that the next instruction prefetch is
delayed since otherwise it would interfere with the video thus giving
additional delay.

My questions:
- is the above scenario a plausible explanation (the instruction used in
  the test was a NOP).
- will the 020 start instruction execution while the second bus cycle is
  still in progress?
- 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??

Many thanks!
-- 
Frans Meulenbroeks        (meulenbr@cst.prl.philips.nl)
	Centre for Software Technology
	( or try: ...!mcvax!philmds!prle!cst!meulenbr)