SetCPU V1.4
		       by Dave Haynie 
		(released to the public domain)


	This program is designed to allow the user to detect and modify
various parameters related to 32 bit CPUs in Amiga computers.  This program
began life as "WhatCPU", which did little more than read the proper place
in ExecBase and report what kind of CPU/FPU was in the system.  The first
version of SetCPU added the capability to identify a 68030 and to change the 
cache parameters of the 68020 and 68030 systems.  The recently released SetCPU
V1.3 also did tests for 68882 vs. 68881, and for the presence of an MMU.  It
was supposed to allow for checking of a particular thing in a startup 
sequence, but unfortunately the CHECK code in V1.3 was broken.

	That brings us up to V1.4.  As well as fixing and extending the CHECK
code, SetCPU V1.4 also has some simple MMU code to allow 32 bit systems with
MMUs to copy ROM into RAM and then relocate this RAM as ROM, thus greatly
enhancing the speed of ROM based operations.  This "FASTROM" code isn't
extremely sophisticated, and could possibly run into trouble on other 32 bit
systems, but it has been tested on the A2620.  It will certainly have to be 
rethought to work properly with memory outside of the 68000 compatible 24 bit
address space.

	In any case, the syntax of the program is given as follows:

		SetCPU [INST|DATA] [[NO]CACHE|[NO]BURST]
		       [[NO]FASTROM [TRAP]] [NOMMUTEST]
		       [CHECK 680x0|68851|6888x|MMU|FPU]

where "[]" indicates an optional parameter, "|" indicates a choice of
parameters.  Typing "SetCPU ?" will retrieve this same syntax diagram.
Typing SetCPU alone will result in the SYSTEM configuration being 
send to the console, my current system returns this:

	SYSTEM: 68020 68881 68851 FASTROM (INST: CACHE)

This indicates I have a 68020/68881/68851 system (eg, standard A2620), I've
previously installed the FASTROM translation, and my instruction cache is
turned on (done by AmigaOS V1.2 or V1.3).  Note that any parameters that
don't make sense to the real system configuration, such as asking to modify
the data cache on a 68020 system or install the FASTROM translation on a
68000 system are just ignored.

	The individual commands are given below in detail:


[NO]CACHE
	This command will switch on or off 68020 and 68030 caches.  If
	not qualified, it'll act on both instruction and data caches of
	the 68030.

[NO]BURST
	This command will switch on or off the burst cache line fill 
	request of the 68030.  If not qualified, it'll act on both 
	instruction and data caches.

INST
	This preceeds a CACHE or BURST operation to restrict it's application
	to the instruction cache only.

DATA
	This preceeds a CACHE or BURST operation to restrict it's application
	to the data cache only.

[NO]FASTROM [TRAP]
	This activates the FASTROM translation on or off an MMU equipped 
	system.  When switching on, it first allocates 256K of memory for
	the ROM image, then currenly 512 bytes of memory for the MMU table.
	It copies the ROM into the image area, then applies the translation
	by pointing the MMU at the table and activating it.  The TRAP option
	causes the MMU to look at all 32 bits of address; access to any 
	memory outside of the 24 bit space will result in an exception, which
	if unhandled, results in a GURU 2.  When TRAP is not specified, the 
	MMU is only looking at 24 bits of address space.  This is the mode 
	you'd normally run in.  Under V1.3 and earlier releases, a DOS bug 
	can cause invalid accesses, which cause the exception, when running 
	the EndCLI or NewCLI/NewShell programs; running untrapped will avoid 
	gurus with these commands.  It's still possible to run into an 
	exception when running without the TRAP option.  One easy way is 
	writing to the ROM image, which is write protected by the MMU.  The 
	NOFASTROM option will switch off the MMU and reclaim the memory used
	for the ROM image and MMU table.  Note that this is achieved by 
	locating these items via the appropriate MMU registers.  If any other
	program set up the MMU for something, this could be a very bad thing
	to do.  In general, until there's some level of OS support for the 
	MMU in Amiga systems, you're really safe using only one MMU tool at 
	a time.

NOMMUTEST
	This option won't normally be necessary.  However, some 68020 boards
	out there apparently have hardware bugs of some sort that make
	testing for the MMU impossible, at least as near as I can tell.  If
	your 68020 board freezes, or crashes with some kind of coprocessor 
	protocol violation GURU (probably numbers $0D or $0E), you have a
	problem with your 68020 board.  The most common bug is the 68020
	board hardware failing to fully decode CPU space, such that the FPU
	in the system also responds to the MMU's address space.

CHECK 
	This option lets you check for the existence of a particular
	CPU system component in a script.  It works like this:

		SetCPU CHECK 68020
		If WARN
			echo "No 68020 here!"
		Else
			echo "Sho nuff got a 68020 here!"
		Endif

	The arguments to CHECK can be any of:

		68000	Matches the obvious
		68010	"
		68020	"
		68030	"
		68851	"
		68881	"
		68882	"
		FPU	Matches 68881 or 68882
		MMU	Matches 68851 or 68030

That's about it.  As mentioned, this code is public domain, and you're
free to do anything with it you like.  Even make it better!  For any real
MMU programming, I'd recommend both "MC68030 Enhanced 32-Bit Microprocessor
User's Manual" and "MC68881 Paged Memory Management Unit User's Manual",
both from Motorola.  There are some differences between the two, please make 
sure, if you're writing any MMU code, that you either write code that works
on both, or you specifically check for each MMU and act accordingly.

Also note that much of what SetCPU does may be wrong in a future release of
the OS, so it's a very bad idea to put any of this stuff in a commercial
program.  Things like identifying the MMU, CPU, or FPU that aren't fully
done in 1.3 may still work in a future OS release, but if that OS is
correctly identifying the MMU, CPU (eg, 68020 vs. 68030), or FPU (eg,
68881 vs. 68882), SetCPU should be using the OS's opinion of these items,
not testing itself.  On a more drastic note, if an OS ever starts using
the MMU, the FASTROM code will certainly break.  It's the job of the OS to
arbitrate the MMU, and if the OS is doing that, no legal program would be
able to come along and muck with the MMU registers without reeking havoc
on the operating system.

One final note, if you have a 68020 board that locks up without the
NOMMUTEST option, you'd be wise to express your concerns to the vendor
of that board.  There's an awful good chance that if, in the future, 
Amiga releases an operating system that knows about the MMU, it'll test
for it in some way, probably similar to what I do here.  If your board
locks up on MMU operations, you may not be able to run this future OS
on your 68020 board.  Maybe the vendors can fix these now, instead of
later when you really need this fixed.

			-Dave Haynie
			 PLINK:		D-Dave H
			 bix:		hazy
			 usenet:	{uunet,rutgers}!cbmvax!daveh