home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Fujiology Archive
/
fujiology_archive_v1_0.iso
/
!MAGS
/
!BONUS
/
COVERDSK
/
STFORMAT
/
STF27.ZIP
/
STF27.MSA
/
SHOMEM_SHOWMEM4.TXT
< prev
next >
Wrap
Text File
|
1987-04-21
|
5KB
|
112 lines
*******************************************************
* *
* ShowMem4 - The Displayer - runs as .PRG _or_ .ACC *
* Copyright 1988 John Eidsvoog *
* Revision date: Saturday, June 22, 1991 *
* *
*******************************************************
This program is Freeware. It may not be sold or distributed
commercially without my written permission. You may freely
distribute it otherwise as long as the files are included in
their entirety with no modifications.
Included files:
SHOWMEM4.PRG The Program/Accessory
SHOWMEM4.TXT This text file
ShowMem4 1.4 Fixes Problem
--------------------------
ShowMem4 now works correctly on TOS 1.4 and later. Previously you may
have had to run it twice in order to display a valid listing or it may
have even crashed upon running the first time.
Fast RAM Support
----------------
ShowMem4 now recognized memory blocks in "fast RAM", either on the TT030
or any other computer implementing "fast RAM". The start address of
memory blocks in fast RAM will be displayed in inverse text.
-----------------------------------------------------------------------
About ShowMem4
--------------
ShowMem4 is specially written so that it can be run as either an
accessory _or_ a program. All you have to do is change the name (using
Show Info) so that the extension (last three letters) is .ACC for an
accessory, or .PRG for a program.
ShowMem4 allows you to examine the GEMDOS memory descriptor lists. The
locations of these lists in memory is not documented by Atari. There is
a search routine that should find these lists in all ROM versions
(including future ones). If this search should fail, you will be
alerted that this is an unknown ROM.
You may list the information to the screen or to a printer. This is
selected from the initial alert box. The listing will include all
allocated memory blocks, followed by all memory free blocks. If you
hold down the 'Alternate' key when you select the output device, you
will also get the memory descriptor waiting list (this is my name for it
as until recently its very existence was undocumented). It is now
documented as _root, or a pointer to the OS pool, although the TOS 1.4+
ROMs seems to contain a pointer to a null. When GEMDOS splits a block
into two smaller blocks, it uses this list to get a new descriptor
location. When two contiguous blocks are merged, the unused block is
put back in this list. For this reason, the entries in this list may or
may not contain any useful information.
The leftmost column will show the decimal size of each block as well as
a total for each type of memory blocks.
While the listing is scrolling on the screen, you may pause/continue by
using the mouse button.
------------------------------------------------------------------------
The structure of a memory descriptor is as follows:
long pointer to next descriptor in list or zero (end of list)
long starting address of the block
long number of bytes in block
long pointer to base page of block's owner
(This information is not documented by Atari and you should not rely on
its validity as they are free to change it at any time.)
------------------------------------------------------------------------
One point that should be raised about free memory, is that when GEMDOS
returns the bytes available via Malloc(-1), it returns the size of the
largest available block, _not_ the total available memory. ShowMem is
the only tool (to my knowldege) for the ST that will show you the true
total available memory.
When a program runs, it is given the largest available memory block to
run in. But when a program requests a memory block from GEMDOS, it is
given the smallest memory block that is large enough to fill the
request. This means that smaller, fragmented block may still be useful
to many applications. It may also be confusing to someone who is using
a "regular" method of determining free memory.
You might check free memory and be told that there is 800K free, while
there might be a fragmented 33K block which is unseen. Then you might
tell a program to allocate a screen buffer of 32K. Your free memory
display will still show 800K because the 32K of the 33K block will be
supplied as the screen buffer. This whole scenario can be examined by
using ShowMem.
John Eidsvoog
CodeHead Software