Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!oliveb!amiga!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: SetCPU 1.4 FASTROM option
Message-ID: <7062@cbmvax.UUCP>
Date: 7 Jun 89 19:46:55 GMT
References: <26925@watmath.waterloo.edu>
Distribution: comp
Organization: Commodore Technology, West Chester, PA
Lines: 63

in article <26925@watmath.waterloo.edu>, grwalter@watmath.waterloo.edu (Fred Walter) says:

> With a recently purchases A2620, and the FASTROM option of SetCPU 1.4 I
> have problems running graphics intensive stuff. For instance - F18
> consistently screws up. Apparently F18 double-buffers, and it looks like one
> of the buffers gets trashed. Without FASTROM set, F18 works fine.

In general, anything that's likely to be sensitive to system timing could mess
up on an A2620.  For example, games.  It's not all that difficult to wide up
with game code that counts on certain things taking a certain time.  Any game
should work as well on a 2500 type machine if you reboot to the 68000, as
you might well imagine.  Some programs almost certainly have a problem with
68020s due to unsupported coding practices like the MOVE SR,<ea> instruction or
self-modifying code.  My advice is to have your system set up so that most of
the normal, everyday stuff runs just fine.  For me, that's with FASTROM 
installed (but if I find a program that doesn't work with FASTROM or the 
'030, I usually toss it).  Follow these steps in the event of something being
screwy; all but the last are reversible.

	1.  REMOVE FASTROM

		If a program seems to act goofy, especially something time
	dependent like a game, first thing you might try is removing the FAST
	ROM code.  "SetCPU NOFASTROM" will free up that memory and turn off the
	MMU, leaving you running from real ROM.  This will help with programs
	that have ROM-dependent software timing problems, or programs that
	cause GURU #2s (protection violations, though SetCPU V1.5 handles 
	these for you in most cases).

	2. TURN OFF THE CACHE

		Additional goofiness can be removed with the cache off; use
	"SetCPU NOCACHE" for this.  Self-Modifying code (which seems to be a
	favorite of game authors, even though it's officially forbidden) will
	certainly work better with this, and it will make the system go 
	slower, which may help if you still have a speed problem.

	3. TURN OFF FAST MEMORY

		The NoFastMem program from 1.3 may allow things that still have
	speed or chip memory addressing problems to function.

	4. BOOT UP ON THE 68000

		If you set out to, you could write a program that works on the
	68000 but not on the 68020, though it's not real easy.  Some folks have,
	however, succeeded without trying.  Perhaps every time you find this
	necessary, you could send a letter to the authors of the program that
	forced you into it.  Maybe they'd upgrade it.

Games work on faster systems better in the Amiga than many other systems because
may of them are video synced, and the video system stays the same here.  Still,
many programs, especially of the "take over the machine" variety, never thought
about running in a speed variable CPU environment -- they're still writing code
with the same tricks they learned on 6502s, many of which are just plain wrong
in the Amiga system.  I believe it's completely possible for most any kind of
program to be written to work as well on the fastest 68030 machine as the plain
A500.  No one said it happens automatically, though; it takes a bit of thought.

-- 
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