home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Frozen Fish 1: Amiga
/
FrozenFish-Apr94.iso
/
bbs
/
alib
/
d1xx
/
d187
/
setcpu.lha
/
SetCPU
/
SetCPU.txt
< prev
next >
Wrap
Text File
|
1989-02-26
|
7KB
|
157 lines
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