Crawly Crypt Collection 1/crawlyvol1.bin/utility/bnchmark/profl153/profile.txt

Text File | 1994-03-24 | 48KB | 891 lines

                                 PROFILE v1.53
                              by Linnhe Computing
          Copyright (c) 1993, 1994 Mark S Baines All Rights Reserved

Mark S Baines asserts the moral right to be identified as the owner of this
work.


PROFILE IS A FREEWARE PROGRAM
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
PROFILE is protected under UK and International copyright law, and is NOT
public domain software. That is, Mark S Baines still owns the copyright to this
program and the document files. You are hereby granted a licence to use this
copy for private, non-commercial use. You are not allowed to alter the program
in any way, to do so is an infringement of my rights. FREEWARE is NOT Public
Domain!

If you do feel like rewarding my efforts with a small remuneration then please
send a payment of at least £5.00 (five UK pounds cash, postal order or UK
cheque) to me.

Please make your payment to "Mark S Baines" and **NOT** "Linnhe Computing" and
state which version you have and where you obtained it.

    Linnhe Computing
    'Linnhe'
    Shore Street
    Inver, by Tain
    Ross-shire
    IV20 1SF


Bulletin Board Sysops and managers of Public Domain libraries are allowed to
make this program freely available to their users and customers as long as this
document is included with the program and both remain unaltered.

The FaST Club may place this program on its Disk Magazine which is available to
subscribers. Floppyshop and The FaST Club may also include it on their
Catalogue disks.

No other magazine, whether commercial or free, professional or amateur, may
place PROFILE on a disk magazine or magazine cover disk without the express
permission of Mark S Baines at the above address. This includes Atari ST User
and ST Format. ST Review was given permission to include this version on their
cover disk on 19th February 1994. Mark S Baines reserves the right to demand
the appropriate remuneration from commercial magazines and disk magazine
publishers for permission to publish PROFILE on their disks. If you make a
profit out of selling a magazine with a cover disk, then it is only right that
some of that profit should be distributed to the authors of the software
contained therein.


PROFILE - INVENTORY
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
When distributed through any means whatsoever, this total package must not be
separated.

PROFILE.PRG  The program
PROFILE.TXT  The documentation in standard ASCII text file
PROFILE.ASC  The documentation in reformatable ASCII text file
             (not for ST Review cover disk)

It is essential that this program is not renamed to PROFILE.TOS. If you do,
then don't blame me for the crash. This is NOT a bug!


PROFILE - WHAT IS IT?
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Atari, in their wisdom, have created a situation where there are many different
types of STs, TTs and Falcons around the world. What have we got?
There are at least 15 different TOS versions, many different versions of GEMDOS
and the AES, different versions of GDOS (GDOS, FONTGDOS, FSMGDOS and
SpeedoGDOS), 17 different nationalities of ROM, BLiTTER chips, different
resolutions and many different amounts of RAM memory from 256K to 4Mb on an ST
and beyond on TTs and Falcons. I'll leave it to you to work out all the
different permutations.

All this can create problems for software developers and subsequent 'bug'
troubleshooters. If you ring up or write to your software company for some
technical advice, reporting a bug or undocumented 'feature', it is a great help
to them to know what system the program is running on. HiSoft provide a program
called CHECKST.PRG which provides them with this information but it is not
Public Domain. I have therefore written this program which does the same thing
(and more besides) for all you non-HiSoft software users!

PROFILE is a development of ST_TYPE which was replaced with ST_DATA2. Both
these earlier versions have known problems although updated versions of
ST_DATA2 are available. ST_TYPE is not supported any more and cannot be relied
upon, unfortunately. You should not be using it. ST_DATA2 will now cease to be
supported with the release of PROFILE. PROFILE was known as STDATA3 when beta
tested. If you have seen a copy of this program called STDATA3 then it is an
unofficial release and should not be available. Please tell me about it and
where you saw it. PD libraries must delete it and no one has my permission to
distribute it or use it including the beta testers! Thank you.

At its simplest level, PROFILE can tell you what TOS you have, its date and how
much memory you have, whether the installed DESKTOP.INF configuration is valid,
what the mouse double-click speed is, whether a Cookie Jar is installed...

Power users, programmers, people who like to hack about with other people's
code and programs, hardware and system developers, repairers, those wanting to
get the best from the configuration of their system with numerous ACCs and
AUTOs and any other nosey folk, all want to know what exactly they have in
front of them and what is going on behind the scenes. PROFILE provides
extensive information to help you sort out which vectors are pointing where,
what VBLs are set and the nature of the installed Cookie Jar (if present) and
more. This level of use requires knowledge of the system and what the details
reported by PROFILE mean. I'm not going to explain them all here I'm afraid, on
the basis that if you don't know what they mean then you don't need to know
what the values are. Sources of data are few and far between and the following
may help:

Modern Atari System Software (1993); HiSoft; ISBN 0-948517-63-8; HiSoft

The Atari Compendium (1993); Sanders, Scott; ISBN 0-9638331-0-3; SDS Publishing

Atari ST Internals (1988); R. Brückman, L. Englisch and K. Gerits; ISBN 0-
916439-46-1; Data Becker GmbH

Concise Atari ST 68000 Programmer's Reference (1986); K. Peel; ISBN 1-85181-
017-X; Glentop Publishers Ltd.

A Hitchhikers Guide to the BIOS (1986); Atari Corp. PD text file

Rainbow TOS Release Notes (1989); Atari Corp.

STE TOS Release Notes (1989); Atari Corp.

TT030 TOS Release Notes (1990); Atari Corp.

Atari DocSupport Developer's Kit (1991); Atari Corp.

The Atari A to Z (1994); M. S. Baines; FaST Club (soon - contact FaST Club)

ST Application magazine, (monthly); FaST Club

Compiler program manuals are good sources of this sort of 'inside' information.

Until recently, much of the developer's notes were not normally available to
individuals but they can be bought now from Atari UK as their DocSupport
Developer's Kit. It's also surprising what is available as text files on the
Bulletin Board networks and through PD libraries! Because of this ridiculous
dearth of data on the ST/TT/Falcon systems, caused primarily by Atari
themselves, any serious user of the ST involved in programming and system
development must either register with Atari as an official developer to get the
necessary documentation or buy some of it separately which isn't cheap.
Involvement in the comms world using the BBS networks and services such as CIX
and CompuServe will enable you to ask others in the know, as I was forced to on
many occasions.

PROFILE can be run under two kinds of conditions. Firstly, under an empty
system, devoid of Accessories and AUTO folder programs, under GEM and from a
floppy. This will tell you what sort of default set up you have and be your
standard for telling others such as software companies, what system you have.
Computer repairers and upgraders often need this information as well as the
private user wanting to confirm his purchase.

Secondly, you may run PROFILE under various configurations, with hard disk boot
programs, Accessories, AUTOs, Desktop replacements, hardware modifications etc.
and see what effect these programs have on your system. Changing the
configuration of your system (programs like Superboot and XBoot make this
incredibly easy and convenient) will tell you much about the effects of
individual programs and what they do to your computer and perhaps to each
other. This can be an invaluable aid to bug hunting, virus hunting, program
incompatibilities etc.


PROFILE - THE PROGRAM
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
PROFILE will print a report to the screen, printer or disk of your computer's
hardware and software configuration.

A list of the details provided is:

1   Hardware, TOS and Memory Details - 4 pages (1 extra for Falcon)
1.1 Hardware, TOS, Screen
    Most of this is self explanatory. Some of it will only appear if you have a
    Cookie Jar installed with relevant values. Some items default to the basic
    type (Machine, Floppy Disk Drive). If PROFILE reports an incorrect value
    then perhaps you ought to update your Cookie Jar with a suitable program.
    For full information on some of these items then refer to the Cookie Jar
    page 7.

    Note that the two alternative numbering systems for the TOS version number
    have been used where appropriate. Therefore, TOS 1.04 is the same as 1.4.
    It is my contention, and others, that Atari's attempt to change the TOS
    numbering system for the early TOSes after the old numbers have been
    accepted for several years, is ridiculous. To add to the confusion they
    still refer to both TOS numbers in documentation and in personal
    conversations. TOS 1.0 remains so or may in Atari's eyes be called TOS
    1.00. Atari would like to change TOS 1.2, 1.4 and 1.6 to TOS 1.02, 1.04 and
    1.06. However, TOS 1.62 remains as such (although I saw someone sadly refer
    to it as 1.062 recently! You can't get 1.062 from the BCD value $0162 that
    the ROM contains and this just demonstrates the confusion that Atari have
    caused) which under their new system implies a far greater upgrade from TOS
    1.06 than is actual! The TOS version number is stored in the ROM at offset
    $02. For TOS 1.4 the value is $0104. Each byte therefore has a value of 1
    and 4, hence 1.4. If the first byte is 1 and not 01, then the second byte
    must also be 4 and not 04! The fact that this confusion exists and that I
    spent time ranting about it here, shows how foolish Atari can get.

    As far as I know, the present TOS version numbers are thus:

        os_version    Old     New     Name
        _sysbase+2    Number  Number

        0x0100        1.0     1.00    ROM TOS or Old TOS
        0x0102        1.2     1.02    BLiTTER TOS or Mega TOS
        0x0104        1.4     1.04    Rainbow TOS
        0x0106        1.6     1.06    STE TOS
        0x0162        1.62    1.62    STE TOS
        0x0201                2.01    Mega STE TOS
        0x0205                2.05    Mega STE TOS
        0x0206                2.06    Mega STE TOS
        0x0301                3.01    TT030 TOS
        0x0305                3.05    TT030 TOS
        0x0306                3.06    TT030 TOS
        0x0400                4.00    FalconTOS
        0x0401                4.01    FalconTOS
        0x0402                4.02    FalconTOS
        0x0404                4.04    FalconTOS

    Some people have claimed to have a TOS 1.09 in the UK. It has always been
    my belief up until recently, that this was due to certain programs
    inaccurately reporting the GEMDOS version rather than the TOS version
    number. TOS 1.0 and 1.2 do have a GEMDOS version number of 0.19. After some
    recent discussions on the BBS, it would appear that a true version number
    of TOS 1.09 does exist. It is not, however, a mainstream TOS and it would
    appear that it is a pre-TOS 1.2 version that Atari UK produced to cater for
    the BLiTTER chip before TOS 1.2 was made available by Atari US.

    There is a little confusion over the GEMDOS version number and whether it
    should be shown as hex/BCD format as with the TOS version number or decimal
    format. This gives two differing numbers, of course. The GEMDOS version
    number for TOS 1.4 could be 0.15 or 0.21 according to which format you
    subscribe to. Atari choose the former and I make it the default here but
    also show the decimal format.

    An attempt is made to work out the effective processor speed compared to a
    MC68000. The reported speed does not take the RAM caches of hardware
    accelerators or CPU on-chip caches into account, so that the speed *is not*
    the hardware CPU rate but the effective processing speed of the CPU. This
    figure may vary slightly depending on what processes you have going on in
    the background, for instance AUTO folder TSRs and Accessories. Compare the
    'empty system' result with other configurations to see how some software
    may affect the speed of your computer.

    On a Falcon and computers with video cards the Current Getrez Screen Mode
    will report an incorrect value except with ST compatible modes. This isn't
    a fault of PROFILE but the resolution the computer sees itself running
    using the old and almost defunct Getrez() function. The function should
    return a value of 3 for a Falcon, for instance, but usually returns a value
    of 2 which means ST High Resolution Mono mode. Whether this is a bug in TOS
    4 is yet to be determined.

    Some users are confused as to what PROFILE reports here. No program should
    use Getrez() to find out the resolution of the screen as its return values
    are too limited and don't allow for video cards, overscanned screens and
    the Falcon. However, some programs *do* still use it and can give problems
    for a user when they come up with a "Can't run in this resolution" alert.
    PROFILE reports this value so that the user may know what screen mode the
    system thinks it is running in using the Getrez function and so help to
    sort out these problems.

    Apart from this use, this information is meaningless on anything but a
    standard ST(E). For the true screen resolution and other video details see
    the "Current Resolution" and following lines on this page.

1.2 Memory and MiNT Details
    The total amount of ST RAM and Fast Alternate TT RAM (if fitted) is
    reported as well as the largest single block of each that is free, except
    under MultiTOS where such interrogations are essentially dangerous in a
    multitasking situation. However, on a TT the total amount of Fast Alternate
    RAM can only be calculated by an undocumented feature, which is simple
    enough but relies on that memory always starting at the address $01000000.
    There is no 100% guarantee that it always will, but then there is no real
    reason why it shouldn't. If this causes problems, then please tell me.
    Which items are reported on this page depends on what is installed and
    available and whether MiNT/MultiTOS is running.

    If MiNT or the MiNT kernel of MultiTOS is installed then some details are
    given on the limitations of the installed version.

1.2 Miscellaneous Falcon030 Details (Only if Falcon)
    Various specific Falcon details are reported here such as the video mode
    and whether the DSP or sound system has been taken over. The video mode
    details are the currently set ones and may disagree with those set on the
    Desktop and shown in the NEWDESK.INF details page if the latter hasn't been
    saved.

    This page isn't seen on non-Falcons.

1.2 Disk Drive Details (or if Falcon)
1.3 Disk Drive Details
    Again, mostly self-explanatory. The BIOS Parameter Block or BPB of the
    current drive is shown. This information is stored on the disk and informs
    TOS of the details of the drive's format. TOS needs to know how big the
    sectors are and where the FAT and data sectors start.

1.4 Disk Drives - pun_info Structure Details (or if Falcon)
1.4 Disk Drives - pun_info Structure Details
    The pun_info structure is provided by TOS for any hard disk driver to make
    a relationship between the logical drives installed on the desktop and the
    physical units connected to the computer. Logical drives A: and B: are
    assumed to be floppies and everything else a hard disk. RAM disks are
    reported in the list of logical drives (as they are on page 3) but they are
    not included in the 'Partitions' table, of course, as they do not have a
    physical unit counterpart.

    Not all hard disk drivers fully initialise the pun_info structure. As far
    as I know, only Atari's AHDI version 3 or later does and also uses the
    extended pun_info data at the end of the structure. The commonly used ICD
    drivers do not even properly initialise the table linking the logical units
    with the physical sectors. With current versions of the ICD drivers, the
    partition start sector is offset by four partitions, so that the start
    sector for partition C is that listed under partition G, partition H is for
    D and so on. However, the ACSI device number is correct for each partition.
    An ACSI device number of 7 designates that that partition does not exist
    (accepted range is 0 - 6) and should relate to the list of logical devices
    above that (RAM disks excepting, of course). I also list the Driver ID
    found before the pun_info structure for non-AHDI drivers but this doesn't
    seem to be in standard use except by ICD.

2   Operating System Header Block and Basepages Details - 2 pages
2.1 Operating System Header Block Details
    This is simply a record of the first bytes in the TOS ROMs pointed to by
    the system variable _sysbase, where some important hard coded details are
    kept. Some of these details do not appear on TOS 1.0 STs. Note that under
    MultiTOS the OS PAL/NTSC and Country Code entry is modified from that
    actually contained within the ROM. This is because under TOS 4 and AES 4
    these details are stored in Cookie Jar entries.

2.2 Program Basepage Details
    The BASEPAGE structure is detailed here for the current program i.e.
    PROFILE and the PROFILE's parent process. The latter is normally the
    Desktop or replacement Desktop or Shell program, that is, the program that
    PROFILE was run from. It is envisaged that it will be this list that users
    will find useful rather than the current process basepage.

3   Cartridge and Some Control Panel Settings - 1 page
    If a program cartridge is attached then the details of this are reported.
    The cartridge has to have a program ROM installed, so cartridges that are
    just dongles or interfaces for hardware, such as scanners are not seen by
    PROFILE as there is nothing to report.

    PROFILE should be able to distinguish between the four types of GDOS (GDOS,
    FONTGDOS, FSMGDOS and SpeedoGDOS). Some copies of FSMGDOS are available but
    officially it was never released by Atari. It was replaced by SpeedoGDOS
    which is now available.

    The other items reported here are controlled by Control Panel type programs
    and may be contained in the DESKTOP.INF or NEWDESK.INF file and these are
    the currently installed values. These may differ from those in the
    DESKTOP.INF or NEWDESK.INF file itself because another program has taken
    over the setting of these items, such as NeoDesk. Also, be aware that some
    of the DESKTOP.INF file settings are not installed unless a Control Panel
    program is run or a Read Only Control Panel (an AUTO program that reads the
    installed DESKTOP.INF file in memory, activates the settings and quits).

4   Some Important System Configuration Addresses
    This page contains some of the most important items that people may need to
    know. They are mostly repeats of details contained elsewhere (System
    Variables) but have the advantage of having a little explanation and
    contained together. Some of these are important if you suspect the presence
    of a virus attaching itself to the Reset Vector or Hard Disk routines, for
    instance. These details can be followed up in Section 9, perhaps using the
    XBRA checks.

    Checks are made on the Reset Vector values and those for the Memory
    Configuration to note their validity.

5   Installed DESKTOP/NEWDESK.INF File Details - 2 pages
5.1 DESKTOP.INF settings
    These details are a report of the AES's internal shell buffer which is the
    RAM version of the DESKTOP/NEWDESK.INF file and are not necessarily those
    current and in operation. The AES internal shell buffer is only updated
    when the desktop is saved and so any changes made without saving the
    desktop will not be detected by PROFILE.

    Note that for the RGB Colour Values there are sixteen sets of three digits,
    each digit for Red, Green and Blue. On the ST, this range of digits for
    each colour value is 0 to 7, so that white is 000 and black is 777.
    However, on the STE, the colour range was extended to fifteen, but instead
    of using the hexadecimal representation of numbers Atari chose to use the
    character set 0 to 9 and : for 10, ; for 11, < for 12, = for 13, > for 14
    and ? for 15. Therefore, if you get a RGB colour value of "?;<" it isn't
    nonsense!

    The representation of some of the values shown here differ from those in
    Section 3. Note that the system will install a default set up if a
    DESKTOP/NEWDESK.INF file isn't available at boot up. I really recommend a
    ROCP (Read Only Control Panel) program, which Linnhe Computing can supply.

5.2 DESKTOP.INF continued and NEWDESK.INF settings
    If NEWDESK.INF is used instead of DESKTOP.INF then more details are shown.
    Extra NEWDESK.INF file settings for TOS 4 on the Falcon are also shown
    concerning the video setup. There appears to be an additional problem in
    that the XCONTROL PANEL accessory doesn't update the DESKTOP/NEWDESK.INF
    file when making changes to the Serial port and Printer details. Here, the
    earlier CONTROL PANEL had an advantage and may be used to install a
    DESKTOP/NEWDESK.INF file with the correct '#a' and '#b' lines before using
    the XCONTROL PANEL. Again note that the Falcon video mode details here may
    not agree with those displayed in section 1 page 2. Save the Desktop then
    they should both agree.

6   Vertical Blank Interrupt Details - 1 page
    Many Accessories and AUTO folder programs need to keep doing something
    periodically after being loaded, that is, they stay in memory and are a
    form of multitasking (though not in the proper sense of the word). These
    are TSR programs or Terminate and Stay Resident programs. Some install
    routines as Vertical Blank routines or VBLs. These are called every time
    the screen raster scan moves from the bottom right hand corner to the top
    left of the screen when drawing the screen display. This occurs every 70th
    of a second on a mono monitor such as the SM124/5 and every 50th or 60th of
    a second on ST colour monitors. Again, you can check on these addresses
    under Section 9 to see if any of them were installed by XNAM compliant
    programs. Memory monitor programs can be used to see what is present at
    these addresses, as well.

    Although, it is possible but unusual to have more that eight VBLs, eight is
    the default number in every system. PROFILE makes no attempt to look at any
    more. If there is a need for this then please let me know.

7   Cookie Jar Configuration Details - 2 pages
7.1 Cookie Jar List
    The Cookie Jar was introduced with TOS 1.6 and is automatically installed
    in TOSes 1.6 and later. It is possible to modify or install your own Cookie
    Jar in any system with any TOS. The Cookie Jar is an attempt to provide
    programs with information about the type of system they are running on,
    especially the type of hardware. This would normally be difficult for any
    program to establish. Many programs need to know which processor is
    installed and whether a floating point coprocessor is available so as to
    make use of their facilities. The type of video SHIFTER and sound
    facilities are also different on various systems and a graphics program
    perhaps needs to know if the STE type video SHIFTER is installed to use the
    extra colours present.

    The Cookie Jar is a list of IDs and values, stored in memory the address of
    which is pointed to by the system variable _p_cookies at address $5A0. The
    values often just show the presence of a machine's facility or its type or
    the presence of an active TSR program. Other values may be addresses of
    routines or data structures in memory or a version number. There is no
    standard for these. IDs are four ASCII characters and each should be unique
    and descriptive. Atari have reserved the underline character '_' as the
    first character of their IDs.

    This page lists in order, the IDs and their values in hex and decimal and
    the size of the Cookie Jar. Note that any Cookie Jar program can modify the
    size of the Cookie Jar. Some programs use incorrect characters for the
    Cookie ID and PROFILE tries to trap these. Atari's own MACCEL3 is one of
    these with the intention of making its Cookie ID of $AA006E look like MOOSE
    which is supposedly close enough to be mistaken for MOUSE! Absolutely
    pathetic - talk about breaking your own rules!!

7.2 Official Atari Cookie IDs Interpretation
    This page interprets the values of the Official Atari IDs. Of course, it
    would be impossible to do the same for all IDs as anyone can invent them
    with a meaning unknown to me. Recognising an ID is usually simple enough,
    for instance, "OVER" means OverScan, "FrmD" is FormDoIt, "LTMF" is Let 'em
    Fly, "NFnt" is NeoDesk Font, "NLdr" is NeoDesk Loader etc etc. However,
    understanding what their values mean is anybody's guess and usually of no
    concern anyway. Some are version numbers, others are addresses in RAM where
    that program is loaded and some point to another identifier (usually four
    characters) or a version number in memory. In most cases it doesn't matter
    to the user what they mean.

    PROFILE is capable of detecting all the official and semi-official Atari
    Cookies, the latter of which include the presence of the new GDOSes,
    Poolfix, TOS 1.6 patch, MiNT Kernel and the Diablo driver for SLM laser
    printer. The new International Date and Time Cookie and Nationality
    Language/Keyboard Cookie are included and versions of various installed
    software that have written a cookie shown, such as _NET, _FLK and MiNT.

8   Environment Variables Strings - 1 page
    Many alternative desktops, command line interface shells and programs set
    up environment variables in particular the PATH= variable which informs TOS
    or any program which directories to search through when looking for
    resource or data files.

    The standard GEMDOS environment string set up for the AUTO folder and
    Desktop has a bug where a NUL is placed after the '=' sign as in
    PATH=$0A:\$0$0. It should not be there. The two trailing NULs correctly
    designate the end of the strings. Secondly, it is always drive A:\ even if
    booting from drive C:\. Some programs get around this and some others
    misuse it. Atari have recommended that it shouldn't be used. PROFILE will
    trap the first NUL.

    Sorry about the messy displays you can sometimes get here, especially if
    running under a pseudo-terminal such as MiniWin with its very long
    'termcap' lines. At present I can't find a satisfactory way to present
    overlong lines and stop the screen from scrolling on occasions.

9   Complete System Variables Contents - 7 pages
    This is the complete list as of TOS 4. The address and official Atari name
    is given together with the values they contain in hex and decimal. I've
    added some prefixes to some names to aid identification. These are where a
    system variable is 'divided' into many parts, like _themd which consists of
    four longs and _bufl which consists of two. I've given these suffixes to
    indicate which long is referenced. The same applies for each of the
    _vbl_list, xconstat, xconin, xcostat and xconout system variables where
    I've added a number on the end.

    Please note that some of these names are not the same as those in The
    Hitchhiker's Guide or Atari ST Internals. My names are taken from official
    Atari US source code and developer's documentation.

    Those that are vectors will have a number on the far left which can be
    typed after the SPACE key is pressed to check for XBRA compliance. See
    below.

10  Exception Vectors Contents including the TRAPs and MFP 68901 Interrupts - 4
    pages
    Only those Exception Vectors that are important and usually of significance
    are shown. There are 256 exception vectors in low memory and most of those
    after number 79 usually have the same default values on all systems, either
    being reserved or available for user programs. If you need to see the other
    200 vectors then let me know and I will include them in a future revision.
    However, at the moment I thought it best to leave out another ten full
    screens of useless numbers!

    By default, many of the values shown are in two parts. The last six hex
    digits are an address of a routine executed in ROM when that exception is
    called due to some sort of error when a crash may be imminent. The first
    two hex digits are the number of bombs shown just before that crash and is
    the same as the vector number (in hex). Because of this pattern, scanning
    down the list can show quite easily any vectors taken over by user programs
    installed in the system.


XBRA and XNAM
¯¯¯¯¯¯¯¯¯¯¯¯¯
The System Variables and Exception Vectors can be analysed for XBRA and XNAM
compliance providing a powerful debugging tool for software and system
developers. Some system variables and all the exception vectors contain vector
addresses, that is, addresses that point to another part of memory that may be
the start of an executable routine.

Many AUTO folder programs such as TSRs (Terminate and Stay Resident) and
Accessories install themselves in memory using the XBRA and XNAM protocols.
Essentially, they hook into or take over various vectors, such as those pointed
to by some system variables or exception vectors, so that when TOS (or other
programs) transfer control via these vector addresses to run the routine
pointed to by them, the TSR routine is run instead. Normally, if several of
these programs want to do this to the same vector then problems could arise.
Some programs do not save the address originally stored at this vector and so
the last installed program usually wins kicking out the others. Most others do
save the vector address but do so in non-standard ways incompatible with each
other. The XBRA protocol, however, does introduce a standard so that each
program can store the vector address and replace it with its own in a
compatible manner. After any XBRA compliant program is called and run, it can
then call the old address thus enabling another previously installed program to
run and so on down the chain until the last original address is reached. In
this way, all the programs get to run their routines at the appropriate time.
Note however, that if any program intercepts a vector without using the XBRA
protocol, then it will break the chain and PROFILE will not show any more XBRA
IDs even if some still exist. This is not PROFILE's fault but one inherent in
the system, and will remain so until all programs use the XBRA protocol.

XNAM protocol programs don't maintain the old address and thus cannot be
chained. They commonly appear as VBL routines.

A good example of an exception vector that gets used for this is number 46 -
TRAP #14 Instruction (XBIOS). Several programs may use this vector to point to
their routines, such as Quick ST3, OverScan, NeoDesk etc.

ST Applications Issue 11 November 1991 gives a good account of the XBRA
Protocol.


PROFILE - USING IT
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
The program is run by double-clicking on it from the Desktop except under
MultiTOS where you should run it in a MiniWin window by dragging PROFILE.PRG to
the MiniWin icon or filename. You can also use a MW window (if you have it)
using the command line 'TOS PROFILE.PRG'. Here, it will run very happily in a
multitasking window. Do not be confused by the fact that PROFILE has a .PRG
file name extender. This is necessary under normal TOS for certain functions to
work.

    PROFILE MUST NOT BE RENAMED TO PROFILE.TOS.

PROFILE can also be run from the desktop under MultiTOS but it is far less
satisfactory, with the key responses being very poor and some screen corruption
inevitable with the mouse breaking through. Of course, in this mode, program
switching will be unavailable. Run PROFILE from a window and all will be OK.

PROFILE will run on all STs, STEs, TTs and Falcons and under MultiTOS (as of
compile date shown under Main Menu Information), in most resolutions but will
be untidy in ST low resolution and other 40 columns modes which I refuse to
support!

The Main Menu screen provides access to each individual section of the program
which is essentially the list above under PROFILE -THE PROGRAM. A section may
have more than one page (screen) of information.

When each page is displayed you can move to the next page or section by using
the left and right cursor keys. This means you don't have to go back to the
Main Menu page to access another section. Each page can be individually printed
to the parallel printer port by pressing 'P' or 'p' or sent to an ASCII disk
file by pressing 'D' or 'd'. The default name of the file will be PROFILE.Pxx
where xx is the page number displayed. You can change the filename of course,
using the file selector provided.

The RETURN key will always get you back to the Main Menu page.

You can send the whole report, which is around 28K long, to the printer or disk
by pressing 'P' (or 'p') or 'D' (or 'd') from the Main Menu screen. The default
name for the whole report disk file is PROFILE.LST. Again, you can change that
if you wish.

In the Systems Variables section, some system variables contain vector
addresses that can be checked for XBRA and XNAM compliance, as mentioned above.
Pressing the SPACE key will enable you to type in the number of the system
variable you want to investigate, as shown in the first column to the left of
the system variable address.

The vector or system variable address is shown and its value, which should be
another address. Attempts are made to check this value - to see if it is in the
ROM or illegal (pointing to protected memory or outside that available to the
system). If a XBRA or XNAM compliant ID (four characters) is found then it is
reported and the next address in the chain is shown until the chain ends.

For exception vectors, the technique is the same, just type in the exception
vector number in the first column. The display is the same as for system
variables except that the exception vector number is shown as well as its
address and value.

At present these values cannot be printed or saved to disk (other than a normal
screen dump) as that didn't seem worthwhile for such small amounts of data.
However, if you think that you need that facility then please ask.

Please note that any check on a vector will only show if that vector was
installed by a XBRA or XNAM compliant program. Many programs, especially older
ones don't use this protocol. It doesn't make that address pointed to by the
vector less valid. It was installed by something!

The Main Menu screen provides rudimentary Help by pressing 'H' or 'h' and
Information on the program (such as compile date, about Linnhe Computing,
acknowledgements etc.) by pressing 'I' or 'i'.

The program can only be Quit by using the Main Menu 'Q' or 'q' key. Simple eh!


PROFILE - SOME COMMENTS
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
I have written this program using legal methods everywhere, as far as I know.
It has been extensively tested on mostly all TOS versions and various setups
including STs, STEs, TTs and Falcon030s all running MultiTOS. As far as myself
and the beta testers can ascertain all the information reported by PROFILE is
accurate. That is, what is reported is what is found by PROFILE. However, it
may be that some strange figures are seen which appear at odds with what you
know to be true. In many respects this is the point of running PROFILE. It will
report the configuration that exists not what you thought existed! Be very
aware that running many different programs, such as Accessories and AUTO
programs, different hardware such a OverScan, accelerators, emulators etc. all
affect the internal configuration of your computer. To make themselves known to
the system and work they may well fiddle with some system variables, vectors,
interrupts or even the apparent appearance of the ROM - all of which may or may
not be what you thought or know to exist.

For instance, AutoSwitch OverScan messes with various system variables such as
'exec_os'. This system variable normally tells the system where the start of
the AES is, like $E13D94 under TOS 1.6. That makes sense because the AES is in
the ROM starting at $E00000 on TOS 1.6. But, OverScan can set this to something
like $708C8 way down in RAM. Normally you may think this is a great mistake on
PROFILE's part as it doesn't make sense - until you read the AutoSwitch
OverScan manual and see that this is documented. However, not all software, by
any means, documents what it is doing internally to your system - hence
PROFILE!

Something else you may notice is that PROFILE reports that you have less memory
than you thought. This may well be because you have a RAM Disk installed that
has altered the system variable 'phystop' to point, not to the top of physical
memory, but to the memory address directly underneath the memory reserved for
the RAM Disk. PROFILE will catch this.

Logbase and Physbase are two more vectors that cause concern. Physbase will
normally point to the base of memory holding the data for the physical screen
(the one actually displayed). Logbase normally points to the base of the
logical screen (the one onto which any drawing by the GEM VDI is done). Usually
these addresses are both the same but do not have to be. For instance, a
program may have a screen displayed (at Physbase) whilst writing another (at
Logbase) and swap between them for quick, snappy screen draws. However,
AutoSwitch OverScan is a program that messes with these values to the extent
that any call to Physbase will return the Logbase value when OverScan software
is installed. If you didn't know this and are writing a program using Logbase
and Physbase calls which repeatedly return the wrong values, PROFILE will help
solve this problem for you.

PROFILE is as extensive as a program like this can be and yet remain compatible
on all ST/TT/Falcon systems. That was of paramount importance when being
written. There are some deficiencies in its reporting. These are for many
reasons.

1   I don't know about them. If you do then why not tell me what I missed.
2   I didn't know how to find that data whilst retaining compatibility across
    all platforms.
3   There is no acceptable means of finding that data using sensible, accurate
    and legal methods. The TT Fast RAM situation in the TT is a case in point.
    As far as I and several developers in the UK and Europe can ascertain,
    involving consultation with Atari UK and Atari US, there is no 100%
    reliable legal way to report the total amount of 32-bit Fast Alternative
    RAM in a TT. PROFILE will report the amount of TT RAM using an undocumented
    feature which I'm taking a chance on. It should be alright.
4   A detail may be of too little importance to report or too esoteric and used
    by only one or two people.
5   Other programs do it better, like disk diagnostic programs or system speed
    analysers.
6   A detail may require the presence of third party hardware which I consider
    to be outside the scope of this program.
7   Atari are moving the goal posts every day with MultiTOS and the Falcon. I'm
    trying to keep up!

If you wish to comment on any of these points then please do, I am very
receptive to program changes and suggestions and am not the sort of programmer
that gets in a huff if someone complains of their work although totally
thoughtless and destructive criticism may well get ignored! However, I am all
too aware of my limitations and PROFILE isn't perfect by any means.

PROFILE v2 GEM version is in the pipeline and hopefully won't be long.


PROFILE - BUGS AND INACCURACIES?
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
My programming isn't perfect, of course, but PROFILE has been tested by myself
and six knowledgable beta testers who have different systems. PROFILE has been
developed over much time and with much thought. If you find any problems  -
tell me!

I do know that it crashes under some circumstances when run under ST Low
Resolution but as I can't be bothered with 40 column mode (I make no apologies)
I haven't found the problem yet.


PROFILE - VERSION HISTORY
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
V1.0
First release February 1993

V1.1
March 1993
    Falcon fixes:
       Cookie ID _MCH Machine Type now recognised
       "Screen Area Memory" now reports correct value (I think!)

V1.2
March 1993
    Bug fix in Environment Variables page which displayed some garbage under
       some situations (thanks to Steve Taylor)

V1.3
April 1993
    Cookies _AKP and _IDT now added
    Some cosmetic changes to Cookies screen display
    "ROM Nationality" and "Current Resolution" not shown on Falcon

V1.4β - beta test release
June 1993
    Falcon "Nationality" added
    More Hardware details added to first page
       "Current Resolution" (as opposed to Screen Mode) added
       "TOS-mode Screen Size" added
       "Number of Predefined Colours" added
       "Palette Size" added
       "Displayed Screen Size" added
    "Screen Area Memory" fixed again for good
    Some details on drives moved to Disk Drives page
    "Current Directory Path" added
    "BPB of Current Drive" added
    "pun_info Structure" added
    "Current Program and Parents Basepage" structures added
    Rewrite of some functions giving increased speed and smaller size
    OS Header now shows last 3 items for TOS 1.2 instead of 1.4
    _SND Cookie bug fixed (didn't show Falcon Matrix varieties)
    "Falcon NEWDESK.INF" video details added
    "Confirm Overwrite File" added to DESKTOP.INF section
    Floating point not used for memory percentages making for a smaller file
    Various cosmetic changes

V1.41β - beta test release
August 1993
    Hack introduced (thanks to Steve Taylor) to get around the crashes on a
       Falcon when redirecting to screen (CON:) or printer (PRN:) using C.
       Looks very much like another TOS 4 bug!
    Various minor cosmetic changes

V1.42β - beta test release
August 1993
    Use Floprate to get floppy disk seek rate for both floppies instead of just
       using the system variable for TOSes >= 1.4

V1.43
September 1993
    Incorporates all the above beta version changes
    Date and Time now updated when shown
    SpeedoGDOS now recognised
    FSMC cookie recognised (FONT, FSM or Speedo GDOS installed)
    More rows of data can be catered for on large screens
    Various minor cosmetic changes

V1.44
September 1993
    Effective processor speed added (thanks to Jon Waite)
    Removed the clear workstation function call that made a mess of MultiTOS
       screens when running in a MiniWin window

V1.5
February 1994
    Change GEMDOS version number to show Hex/BCD format as default as well as
       decimal format
    "Number of AES Concurrent Applications" added
    "Falcon Monitor Type" added
    "MiNT Limitations" and other details added to Memory page
    Minor mods to Cookie strings
    "PMMU cookie" added
    Update languages and countries to include two more
    Screen Mode and NEWDESK.INF info should show 'Falcon resolution'
    New page for "Misc Falcon Details" only seen on a Falcon showing video
       modecode, DSP and Sound System on/off, DSP wordsize, Record/Playback
       buffers on/off
    Falcon TOS video memory function alternative to screen size
    True colour mode detected
    "Number of Background Colours" added
    More... prompt added on Cookie page
    _NET cookie publisher_id and version number of installer added
    _FLK now shows version number of installer
    Changes to GDOS detection and reporting, especially for font scaling types
       including inclusion of version number and quality setting in GDOS and
       Cookie sections
    Update to basepage p_flags
    Released to ST Review magazine cover disk

V1.51
March 1994
    Bug fixed in function that gets the currently mounted drive letters which
       didn't see non-contiguous letters and truncated the list and also failed
       to note those over P (i.e. in MultiTOS)
    Added a "Not suitable for ST Low resolution" alert warning. PROFILE's
       display is not formatted properly for 40 columns but 'D' from Main Menu
       can be used.
    Added a "Processing... please wait" message as apparently it takes a long
       time to load on some systems (takes 1 second on mine!)

V1.52
March 1994
    Minor update to stop holes appearing in screen when mouse moved during
       "Processing...please wait" message

V1.53
March 1994
    Updated DESKTOP/NEWDESK.INF RGB Colour Values to cater for the extended
       palette in STE etc. where the DESKTOP/NEWDESK.INF file can contain
       "?>=<;:" characters as well as the digits 0 - 7. Thanks to Karl Foley.
    Now checks for less than 80 columns rather than just ST Low Resolution mode
       and warns against using PROFILE in that resolution.
    "Current Screen Mode" now changed to "Current Getrez Screen Mode" and "see
       docs" to encourage users to RTFM!


PROFILE - THE ACKNOWLEDGEMENTS
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Thanks go to the beta testers Lasse Eldrup, John Eason, Daniel Hastings, Daron
Brewood, Paul Hargreaves and Steve Taylor, all very generous and patient guys.
PROFILE wouldn't be anywhere near as useful without them - my warm thanks to
you all for your testing, encouragement, bits of code and inside information.

Thanks to Jon Waite for the assembly code to calculate the effective processor
speed. It slotted in beautifully!

Thanks to Karl Foley, Eric Chapman, Ofir Gal, Graeme Rutt, Chris Goodwin, Paul
Alder, Stephen Nathan, Richard Gorbutt, Jon Ellis, Mathew Lodge and Flemming
Nielsen for ideas, bits of code, inside details and encouragement. Sorry if I
forgot anyone else who made some contribution to my knowledge, enthusiasm or
PROFILE. Those are all my memory and comms log-book recall.

Lastly, thanks to Jane, a supportive and understanding wife who has a enormous
capacity to listen to the load of rubbish I utter on my computing exploits and
even remember it when I test her!! ;-)


Slàinte mhath
Mark S Baines
Linnhe Computing
23rd March 1994

E-mail:
Internet:  [e-mail]
FidoNet:   2:259/[e-mail]
NeST:      90:105/[e-mail]
TurboNet:  100:106/[e-mail]