back2roots/padua/padua.7z/padua/misc/SetCPU-1.60.lzh/SetCPU.txt

Text File | 1990-08-16 | 20.5 KB | 454 lines

             SetCPU V1.60
            by Dave Haynie
            June 15, 1990

    SetCPU V1.60 is a program designed for identification and
modification of system parameters roughly related to different versions
of the Motorola 68000 family processors.  The program will identify the
various types of processors and coprocessors in any 680x0 system.  It also
makes an attempt to correctly identify an incorrectly designed but still
possibly functional 68020 system, several of which are known to exist as
Amiga coprocessor boards.  It contains MMU code to locate kernel ROM in
write protected 32 bit ROM.

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

    SetCPU [INST|DATA] [[NO]CACHE|[NO]BURST] [CONFIG n]  [BITS n] [TRAP n]
           [KICKROM path|dfN: [DELAY n] [KEEPEXEC]] [CARDROM path] [VERBOSE]
           [[NO]FASTROM [path] [KEYPATCH n] [HEAD] [NOSTACK]] [ROMBOOT]
           [CHECK 680x0|68851|6888x|MMU|FPU|MMUON|MMUROM|MMUALIEN]

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: 68030 68882 FASTROM (INST: CACHE NOBURST) (DATA: CACHE NOBURST)

This indicates I have a 68030/68882 system, I've previously installed the
FASTROM translation, and both caches are turned on.  Issuing the command
"SetCPU FASTOM CACHE" would recreate such a setup.  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.

[0] CHANGES

    Since the V1.50 release of SetCPU, the following changes have been
made to the SetCPU program:

    - FASTROM now supports loading of a ROM image file.

    - The patch manager has been removed, except for the KEYPATCH
      option.

    - ROMs beyond 256K are now supported, from both file and special
      KickStart disk.

    - ROM images are supported assembled for various memory locations,
      so that Commodore's developer files assembled at $00F00000, for
      example, will work.  SetCPU determines the size, base, and
      jump address of a ROM independently.

    - ExecBase can be erased on KICKROM resets to prevent Chip RAM
      sizing problems and other OS switching errors.

    - A programmable KICKROM DELAY option allows KICKROM to work on
      better on some machines with extremely slow 8520 startup times.

    - Caching for any Bridge Card memory will always be disabled.

    - The system stack, if found in Chip memory, is relocated to Fast
      memory for FASTROM translations.

    - Some 2.0 functions are activated when run under the 2.0 OS, so
      that most if not all of the basic SetCPU functions operate
      properly.

    - The MMU code is intelligent enough to avoid trashing an MMU setup
      not generated by SetCPU.

[1] DISTRIBUTION

    This program is placed in the public domain, and may be used or
distributed as you like.


[2] CPU IDENTIFICATION

    There are two basic types of functions performed by SetCPU.  The
first of these is CPU system identification and cache control.  SetCPU will
tell about the type of CPU setup in your machine, which consists of the CPU
itself and sometimes FPU or MMU coprocessors.  If the CPU supports caches,
SetCPU will let you switch these caches, and associated cache line burst mode,
on and off.  Finally, SetCPU can be used in a Startup-Sequence or other script
to make decisions based on the system that's running.  This is quite useful
with accelerator cards like the Commodore A2620 that let you boot the machine
with either 68020 or 68000 in charge.  The individual CPU group 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 qualifies a CACHE or BURST operation to restrict its application
    to the instruction cache only.

DATA
    This qualifies a CACHE or BURST operation to restrict its application
    to the data cache only.

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        "
        68040        "
        68851        "
        68881        "
        68882        "
        FPU        Matches 68881, 68882, or 68040
        MMU        Matches 68851, 68030, or 68040
            MMUON        Matches any case in which the MMU is enabled
        MMUROM        Matches an active SetCPU ROM translation
        MMUALIEN    Matches any MMU setup no created by SetCPU

If any cache parameter doesn't apply to the system in use, it'll just be
ignored.  Use the data cache and all burst modes with caution.  Some
68030 systems aren't designed to correctly support the data cache, so
switching it on may cause an instant system crash.  Even on systems that
correctly support the 68030 data cache, some device drivers, especially
those for DMA devices, may not work properly with the data cache enabled.
You may wish to check with your system vendors to make sure before using
the data cache in your standard system setup.  The Commodore A2091's device
driver does correctly support data caching.  However, the use of the data
cache is not recommended without an MMU setup, such as FASTROM or one of
the KICK setups, invoked.  The Amiga OS uses memory that's the same in
both Supervisor and User modes of the 680x0.  This requires the setting
of the 68030's Write Allocate bit for safe operation, and SetCPU will
always insure that Write Allocate is set.  However, this mode causes the
data cache to be updated on longword writes even for locations that are
driven noncacheable in hardware.  So data caching without a proper MMU
setup can cause problems with some I/O devices.  With the MMU setup,
SetCPU will map the standard Amiga I/O regions as noncachable.

    SetCPU may report a "FPU Logic Error" on certain 68020 systems.
This is indicating a hardware problem with that board's floating point
coprocessor decoding, which results in the FPU responding to the MMU
addresses as well as its own.  SetCPU knows how to handle such a board,
but future software using the MMU may not, so it's a good idea to report
this problem to the board vendor for repair.


[3] ROM TRANSLATIONS

    The second thing that SetCPU V1.60 manages are ROM translations.
Using the MMU on systems so equipped, it can locate the Kernel ROM in the
much faster 32 bit wide memory provided on many 32 bit systems.  It can
also boot a ROM based system with an alternate version of KickStart.
Most of the options here relate to MMU translation setup and various
modifications of the basic translation premise.

    As of this release, SetCPU's MMU configurations will support
memory outside of the 68000's 24 bit address space, when it is present.
Such memory will be automatically recognized and supported by SetCPU if
it is linked into the free memory lists when SetCPU builds its FASTROM
or KICKROM.  Alternatively, the number of significant bits of address
in the system can be specified by the BITS command, and SetCPU will
build the appropriate MMU table for such a system.

    Another feature of this release is support for ROM images of either
256K or 512K in size.  KickROMs may be assembled for locations other than the
$00FC0000 or $00F80000 base used by physical systems.  SetCPU will compute
the size, base address, and start address for any KickROM image.  ROM
images can now be loaded from disk for FASTROM translations as well as
KICKROM translations, though a FASTROM image must be the same KickStart
release as the current ROM in the system.  This facility's main purpose is
to support loading of patched ROMs with the necessity of rebooting via
KICKROM.  As a result of this, the only patch now done by SetCPU itself is
the optional KEYPATCH, which may be required for proper operation of the
accelerated ROM code on some systems.


[NO]FASTROM
    This activates the FASTROM translation on or off an MMU equipped
    system.  When switching on, it first allocates at least 256K of
    memory for the ROM image, then at least 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
    NOFASTROM option will switch off the MMU and reclaim the memory used
    for the ROM image and MMU table.  If any other program set up the MMU
    for something, invoking this option 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.
    If you have an A2620 or A2630 system, this option will always get 32
    bit memory for you; if not, you'll have to make sure that your 32 bit
    memory is the first MEMF_FAST memory in the memory list for it to be
    used for the ROM image.  Also, that ROM image will be allocated as far
    back on that memory list as possible unless the "HEAD" option is
    specified.  The SetCPU "SYSTEM" line will report this setup as a
    "FASTROM" setup.

Suboptions are:

    file
        Specifying a file with a valid ROM image will load that ROM
        image instead of the system's physical ROM image.  The one
        restriction is that the disk-loaded ROM image must be the
        same ROM revision as the current system ROM.  If they aren't
        the same revision, the KICKROM option can be used instead,
        but that'll require a reboot.  This option can be used to
        load a patched version of the current ROM without reboot in
        most cases.

    KEYPATCH n
        This will patch the keyboard scanning routine for machines
        that have Cherry keyboards (small function keys).  The "n"
        parameter allows a variable delay between 1 and 100 to be
        specified; the delay depends on the keyboard, but should
        be pretty independent of CPU speed.

    NOSTACK
        This will prevent the attempted translation of supervisor
        stack into 32 bit memory.  By default, such translation will
        be done if the supervisor stack is found in Chip memory.


CARDROM path

    When used in conjunction with the FASTROM option, this allows ROMs
    from expansion cards to be located in fast memory as well.  The
    path should reference a file containing lists of expansion cards
    that should be translated if found.  It's necessary to read this
    from a user-defined file, rather than from the expansion environment
    itself, since an expansion device's ROM could be located close to
    that device's registers; there's no way for SetCPU to know it's
    safe to translate a card ROM image unless you tell it.  On my system
    I read a file called CardROMList, which currently contains the single
    line:

        0x202 0x01 0x10000 0x8000 0x4000 CBM_2090A_Disk_Controller

    All the numbers given are in C language hex format.  The parameters
    are, in order, the device's manufacturer code, product code, the
    device's size (in bytes), the ROM's offset from the configured board's
    base address (in bytes), and the size of the ROM area to be
    translated (in bytes).  The final item is text string to identify
    the device; this'll be displayed by the VERBOSE option if the ROM
    translation does in fact take place.  The "_" characters in the
    name will be translated to " " characters.  Note that the CardROM
    translations are currently based on 16K chunks, and SetCPU will
    ignore requests for translations of less than 16K, and round down to
    16K boundaries for larger translation requests.

HEAD
    This option causes the SetCPU memory allocator to attempt memory
    allocation for its translated objects from the start of 32 bit
    memory instead from the end, as it usually does.  Allocation from
    the end usually results in less fragmentation than from the start
    (due to the alignment restrictions of MMU objects), though this
    option is useful when dealing with merged memory lists.  It is
    ignored when the ROM image and tables are in chip/$00C00000 memory.

KICKROM path|dfN:

    The KickROM option allows the system to be restarted with an
    alternate ROM image.  This can be from a KickStart disk in a
    specified floppy drive, or from a given file name.  If the
    ROM image is accessible, this command will cause the system to
    be immediately rebooted into the new OS.  Note that pre-1.3
    versions of the Amiga operating system will probably have some
    trouble with expansion cards, especially autoboot cards.  For
    that reason there's the CONFIG 0 option, which is explained
    later.

    The KICKROM command will reboot the machine with the new OS, but
    that ROM image will be physically located in either memory at
    $00C00000, if it's available, otherwise it'll use Chip memory.  Once
    the new OS has started up, issuing either "SetCPU FASTROM ..." or
    "SetCPU KICKROM..." will cause that image to be moved into fast
    memory, and the slow memory will be given back to the system.  The
    SetCPU "SYSTEM" line will report a 16 bit KICKROM image as a
    "SLOWKICK", and a 32 bit KICKROM image as a "FASTKICK".  A machine
    running from a SLOWKICK kernel can't be re-KICKROMed, but can be
    from a FASTKICK kernel.

Suboptions are:

    DELAY n
        This option sets the delay after reset before any code is
        run.  The parameter may be set from 0 to 100, where 0 sets
        no delay.  The default value is 10, which sets the delay
        value used in SetCPU V1.50.  The need for a delay depends
        on the machine you're on.  If your machine hangs after
        SetCPU loads KickStart, there's a real good chance that
        you need a longer delay.

    KEEPEXEC
        Normally, KICKROM will clear the ExecBase pointer, to cause a
        the new version of the ROM to be rebuild from a cold boot
        condition.  This option prevents that clearing action.

CONFIG n
    This option controls if and how expansion devices are recognized on
    a KICKROM boot.  At the default configuration level, level 2, the
    expansion cards are left alone, allowing the new Kernel to try and
    configure them.  Since some older operating system will choke on
    autoboot devices, this option will allow suppression of them for the
    rebooting process.  When requesting a KICKROM boot, a CONFIG level
    of 0 or 1 will prevent the devices from being recoginzed.

    Once rebooted in the new OS, moving from a SLOW    to a FAST Kick image,
    as described above, the CONFIG status will be honored.  If the
    devices weren't suppressed, nothing special happens.  If they were,
    they'll stay suppressed, and you very likely won't have the memory
    to support a FAST Kick image.  Specifying a CONFIG level of 2 at
    this point will attempt to configure the devices without autobooting.
    At level 1, the devices will be made visable to the system again,
    but nothing will be done with them.

    As of the latest release, CONFIG 0 appears to be required with the
    1.2 operating system, at least if there's any autoboot device, even if
    you're attempting to move from a slow to fast kick image.  The next
    release will attempt to allow 1.2 to configure non-autobooting devices
    at this point.

TRAP n
    This option controls the level of error trapping handled for
    you by the SetCPU system.  The numeric parameter is actually
    optional for compatibility with SetCPU V1.4.  If no TRAP is
    specified, the default level 2 is enacted.  If the TRAP command is
    given without a parameter, trap level 0 will be setup.

    Trap level 0 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.  Trap
    level 1 will set up the MMU to only look at 24 bits of address space.
    Trap level 2 works like level 1, but additionally sets up a trap
    handler for the Bus Error exception (which usually surfaces as a
    GURU #2).  For normal operation (eg, running other people's code),
    Trap level 2 is probably what you want.  For final testing of your
    own code, levels 0 or 1 can catch things which would go unnoticed
    on a 68000 machine, such as writing to ROM space or out of the 24
    bit address space.

    The exception handler used for level 2 trapping catches things like
    writes to protected areas of memory.  It just tells the bus machine
    not to complete the write, and signals no error.  There's a slight
    chance that this won't be enough repair for a program doing something
    really outlandish -- at that point, running at level 1 will let the
    GURU happen, which might help if you're debugging your own code.
    Other that that, there's probably nothing you can do to get such a
    program working with the MMU turned on, other than having it fixed.
    The other thing to consider is that this exception handler could
    conflict with another system-level handler installed by a GOMF-like
    program.  That shouldn't cause a big problem, since you'll the one
    that was installed later, both of which presumably trap the error,
    but it's something to be aware of.

    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 at level 1 or 2 will avoid gurus with these commands.


BITS    n
    This option forces the MMU table for KICKROM or FASTROM to be built
    to support a specific number of bits, regardless of the actual bits
    apparently used by the system.  Valid significant bits range from 24
    through 32.

ROMBOOT
    This option forces a reset to physical ROM without hanging the system,
    even when the MMU is active.

VERBOSE
    This option more fully describes the system translations.


[4] ROM FILE FORMATS

    The 256K KickStart disk the KICKROM option will look for is the
standard Commodore KickStart format, which is a standard format floppy
with the work "KICK" at the start of the disk, followed by 512 blocks of
512 bytes each, a plain dump of the ROM image.  512K KickStart disks
look just the same, only, of course, with 512K of ROM.  The KickStart
loader will actually check the first 32 blocks of disk for the start of
ROM.

    The size of the KickStart image is determined by the first longword
of the file.  Optionally, disk files can contain two extra longwords at the
beginning of the file, the first being a $00000000, second the expected
size of the ROM image.  That expected size will be compared with the expected
based on the first longword in the ROM image and the actual length of the
loaded file, in the case of a disk file rather than a KickStart. The base
address and starting address are determined from the ROM image, and SetCPU
will attempt to use them.  Some ROM images can cause a conflict with other
system resources.

[5] CREDITS

    While this program is an entirely original work, nothing happens in
vaccuum, this one included.  I'd like to mention folks who, directly or
indirectly, helped make this thing happen, by providing example MMU code,
suggestions, and incentives.  These folks include Neil Katin, Jez San,
GVP Inc., Dale Luck, Bryce Nesbitt, Andy Finkel, and the other Commodore-Amiga
software people, and the Commodore-Amiga Technical Support folks.

[6] POTENTIAL BUGS AND OTHER NOTES

    I should point out here that much of what SetCPU does is of a rather
dubious nature.  Everything that's possible to do correctly under the 2.0
release of the OS, including CPU/FPU identifications and cache control, is
done via the approved 2.0 methods when running in 2.0, and via my own tricks
when run under 1.3 or earlier releases.

    While it's impossible for an application to correctly use the MMU under
1.3 or 2.0, SetCPU attempts to be intelligent about its use of the MMU.  It
will check for the use of the MMU by an agent other than SetCPU, and refuse to
modify the current MMU setup if such an alien MMU setup is found.  For systems
with an unused MMU, SetCPU will do it's best to be safe about the modifications
it makes to the memory map.  There may be problems with this program's MMU
code on the Amiga 3000, but based on the SuperKickStart and CPU programs that
are shipped with the first A3000s, this should not be of immediate concern,
since the A3000 comes with equivalent functionality.  Should an A3000-safe
version of SetCPU eventually become needed, I'll make the attempt to track
down any A3000 bugs I can find.  Just because you help design a machine doesn't
necessarily mean you have one to code and test on at home.

    Finally, if you wish to contact me regarding bug reports, new
releases, contributions of cash or macadamia nuts, or pretty much anything
else, I can be reached at the below addresses.


            -Dave Haynie

        Logical Address:
             PLINK:        hazy
             bix:        hazy
             usenet:    {uunet,rutgers}!cbmvax!daveh

        Physical Address:

             284 Memorial Drive
             Gibbstown, NJ
             08027