Club Amiga de Montreal

home *** CD-ROM | disk | FTP | other *** search

/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 378.lha / MemMometer_V2.1 / mm.doc < prev next >

Wrap

Text File | 1990-05-02 | 20.1 KB | 329 lines

/* * Information for MM Version 2.10, 24-Mar-1990 * * MemMometer - A program hacked from Tom Rokicki's WFrags more or less... * (in fact, a heck of a lot) in the style of Peter Da Silva's "Gauge." * The program opens a narrow window with the same dimensions as the * disk capacity gadget found in the top-level workbench window for * a floppy volume. The sizing gadget is like the one in Gauge; to * resize the window, just click the left mouse button over the "E". * The "F" is the program title in this rather short manifestation of * an Amiga Intuition window drag bar. * * My bin copy of Gauge broke when I put a Michigan Insider in my A1000. * I did not have source for the Gauge program, so I conjured this one. * To my chagrin, MM 1.0 broke when I got a 2000 (more on that shortly), * so I can hardly wait to see what the 3000 does to this version... * Changes with this version include a Priority menu item, automatic * column configuration of from one to three columns, compatibility * with the eight-color workbench, and timing via VBLANK signals from * the timer.device, replacing the notorious Delay(arrrgh) function * suspected to be linked with the treacherous floppy disk track 40 * wipeout syndrome. With the 2.10 version, the colors have been set * to more closely conform with the CBM workbench colors, the warps * recognition algorithm has been modified to detect a bitwise logical * true condition (0xffffffff) in addition to the usual bitwise and * otherwise logical false condition (0x00000000), and the titled crash * warning requester has been simplified at the expense of getting just * the title "F", but with the gain of not having the dummy window under * the requester. * * MemMometer may be started from an icon, a CLI, or the Run command * from a CLI. MM uses dynamic allocation for its display data, and * does its own resource tracking. MM will surrender any resources * which it has successfully obtained from allocation requests if, * while MM is running, requested resources are denied. This type * of fault (exit code 20) proceeds silently, and without prior notice. * * Now for a run through MemMometer's menu mechanics. MemMometer opens * with a non-interlaced-screen-height narrow window at the left side of * the Workbench screen. The window width is the same as the width of the * capacity gauge which Workbench renders at the left side of the top * level window for a floppy volume. As with Peter Da Silva's gauge, the * MemMometer has an E at the bottom of the window, and an F at the top. * The E and the F are respectively, the window sizing gadget, and the * window titlebar. New this version, the sizing gadget color identifies * the program MODE, and the title color reveals the selected memory * configuration. While MemMometer can and does automatically arrange * the window to suit the memory configuration, it depends on the user to * select appropriate memory size and address values via the menus. The * menu style is the usual Amiga Intuition menu set; selection is achieved * by clicking the left mouse button while the mouse pointer is anywhere * within the program's window boundary, and then activating the menu bar * by holding down the right mouse button and sliding the mouse pointer * along the Workbench screen title bar at the top of the Workbench screen. * * At the left side of the Workbench screen title is the Project Menu. The * Project Menu has three options. The first option is "Front", which is a * window-to-front command for the event that the MM window was partially * buried by the opening of new windows after MM was invoked. If the * right mouse button is released while the mouse pointer is directly over * the Front menu item, the MM window will oblige by popping forward to an * unobstructed view. The second menu option is the "Back" item, which * will move the MM window back behind any other windows that have been * opened on the Workbench screen (with exception of a backdrop window). * The third Project menu option is the "Quit" option, which directs MM to * close its window and release the AmigaDOS resources MM has allocated. * The normal return code is zero. * * The second Intuition menu is the Setup menu. There are two Setup menu * items. The first item is the "Mode" item. MM has two modes, and they * are selected by sliding the mouse pointer straight down from the screen * title bar over the Mode item , and then moving the pointer to the right * as the mode submenu is activated. The activated submenu provides two * choices, "Frags" and "Warps". Frags are rather much the same as they * were in Da Silva's gauge program. "Frags" is the default menu selection * with which MM is first initialized. The Frags display is described in * the following table: * * 2-Color Workbench 4-Color Workbench 8-Color Workbench * Unallocated Blue Black Black * Allocated White Orange Yellow * Fragmented Blue Blue Blue * * Unallocated memory is free memory available to programs. The programs * may obtain this memory from AmigaDOS through allocation requests. The * Allocated memory is memory assigned to programs running under AmigaDOS. * Fragmented memory consists of interleaved small memhunks, some of which * are assigned to programs and some of which are in the free memory pool. * The smallest fragments are 8 bytes, and the largest memhunks may be more * than a megabyte. The fragmented class is assigned when, in making the * MM window display, a single horizontal pixel line was found to represent * both allocated and unallocated memhunks. For this reason, for a full * window height MemMometer, the resolution of the fragmentation is shown * in more detail on interlaced Amiga Workbench screens. * * The second mode item selection is the "Warps" mode. While the Frags * mode is usually utilized as a low-priority background indicator, the * Warps mode is usually utilized at a somewhat higher priority for the * purpose of tracking bugs and system irregularities. In this context, * I define warps as a form of discretized sample-to-sample differencing * function for some arbitrary segment of memory. Warps are determined by * dividing the selected address space evenly among the MemMometer display * pixels, computing an assignment checkfunction for each pixel line of the * display on the associated assigned memory space at some sample time, and * then, while retaining the previous pixel-by-pixel record, repeating the * same evaluation the second sample time and comparing the sequentially * determined checksums. A "checksum" is computed by means of a sequential * bit-wise eXclusive OR assignment. This type of checksum can readily * detect zeroed or changed values. In the table below, logical FALSE is * zero, logical TRUE is taken as 0xffffffff and VALUE is anything else. * Colors indicate the type of change. Colors for the most part follow * the standard CBM workbench color set, shown as follows: * * Pen # Color Pen # Color * 0 Blue 4 Green * 1 White 5 Red * 2 Black 6 Cyan * 3 Orange 7 Yellow * * These colors are used to map the changes in memory content from sample * to sample as programs multitask together: * * Condition 2-Color Workbench 4-Color Workbench 8-Color Workbench * * VALUE ===> VALUE Blue Blue Blue * VALUE =/=> VALUE White Orange Orange * FALSE ===> FALSE Blue Black Black * FALSE ---> VALUE White Orange Yellow * VALUE ---> FALSE White White Red * TRUE ---> FALSE Blue Black Cyan * TRUE ---> VALUE Blue Black Cyan * TRUE ===> TRUE Blue Blue Green * FALSE ---> TRUE Blue Blue Green * VALUE ---> TRUE Blue Blue Green * * The second Setup menu item is a Frequency selection submenu. While the * selected value does set a minimum frequency with which the memory state * will be examined, it's done by introducing a delay between measurements. * The introduced delay will be equal in seconds to the value selected in * the submenu. The delay is accomplished by the AmigaDOS timer.device * using the VBLANK mode. It was not thought worth the difficulty to make * the timing as precise as would be possible using the cia.resource, as * that might make the resource less useful to other programs, and as well * would mean extra effort adjusting for memory size-dependent scan times * from the various memory sizes selectable with the MM program. Delay * intervals of 1, 2, 5, and 10 seconds are available. * * The third Intuition menu is a Priority menu. This menu applies only to * the MemMometer program and its associated CLI process. Initially it is * at priority 0 with the expectation that the user will set it lower once * the program is running, in order to give more time to the other active * processes the user will be running. A value of -50 is recommended. In * the event the Priority of MM is changed via the menu, the CLI inherits * MemMometer's new priority and retains that priority even after MM quits. * Thus, with extreme priority settings, it may be better to "Run MM" to * keep from passing the extreme priority to subsequent processes spawned * from the CLI that was used to invoke MemMometer. Also, go easy with the * positive priorities; remember that with AmigaDOS version 1.3 the DOS * input.device runs priority 20, FileSystem is priority 10, and the CON: * and trackdisk.device are priority 5 usually. The first three menu items * are used to increment or decrement a selected priority. Selection of * the "NORM" menu item removes any increment or decrement setting. * * The remaining Intuition menu selections are provided so that the range * and base address of the memory examined may be adjusted for the user's * Amiga memory configuration. Note that the base address must always be * set to the correct base address for the given memory configuration, but * that the range may be adjusted to give a better resolution for the first * segments above the base address, if desired. Menus are provided for * Chip memory, Slow-Fast (C00000/Ranger) memory, and Fast memory. While I * have had no difficulty as a result of selecting a range of memory that * involved a non-existent seqment for Chip or Fast memory, when I selected * non-existent SFMemory on my Fat Agnus Amiga 2000, it resulted in a total * system-wide big red Guru 4 (illegal instruction exception). * * After that, I decided to post a requester for the user that issues a * terse a warning that a crash is _possible_ with incorrectly specified * Slow-Fast (non-existent) memory. Since it is possible to access this * forbidden zone through inappropriate settings of the Fast Mem base, MM * also calls the requester if the Fast Mem base is changed. The requester * displays the message: * * WARNING! CRASH POSSIBLE * MENU MEMORY SELECTIONS MUST * REFERENCE EXISTING MEMORY * * Risk It Retreat * * You don't have to worry about a crash if you really have an amount of * Slow-Fast memory equal or greater than the amount you specified in the * menu selection, and the base address is what you specified (the default * base address is C00000). I'm sorry to have to do this, but I don't want * to put in code that monkeys with AmigaDOS's handling of the exception * vectors. I feel justified, though, since my code does not change with * the type of memory segment examined; AmigaDOS evidently does have code * that handles the exceptions properly for the other memory segments. * So, here you see the two options. The left button says - Risk It - a * comfortable gamble if you know your Slow-Fast memory configuration. * Pre Fat-Agnus Amiga 2000 machines have 512K of Slow-Fast memory. Newer * Amiga 2000 machines have no Slow Fast memory - so beware of this and try * it when you have nothing else going on. The - Retreat - option sets * the SFMemory Size internal to the MemMometer program to zero and clears * the display. (It does leave the menu items checked, though, so you will * have to remember to re-select suitable menu values in order to get the * display to show something in each existing memory type. For Chip and * Fast memory this will simply entail going back into the menu and again * selecting whatever was previously checked. The Slow-Fast memory size * should then be set either to appropriate values or to "NONE".) * * Note that in the display there may at any time be anywhere from one * to three MemMometers - for Chip (left-hand column), another for the * Slow Fast mem (center column) and yet another for Fast mem (right-hand * column). These MemMometers can be turned on or off as desired by * selecting "NONE" or the various items in the Size menus. * * Parts of several freely distributable programs have been used to make * MemMometer. Menus, for instance, are done in the style VT100 (Wecker, * et al). As with the VT100 program, MemMometer has preset variables. * However, the program does not yet contain a script file reader or an * AREXX interface with which to automatically set the variables. Likely * it is that I'll write the code for that some time this century! * * MemMometer uses forbid() and permit() when it examines the mem list in * Frags mode. I suppose it is possible with large amounts of memory to * scan, that some gross treachery can happen while the list is locked. * However, with my 3 meg Amiga 2000 I've not seen it. It takes a while * after startup to settle out and display the large byte counts associated * with Fast mem, so be patient... MemMometer is most useful for finding * out why large programs won't load. It's also useful in development for * seeing the impact your application is having on memory fragmentation. * The Warps mode displays any change it sees in memory from one sample * to the next; BUT this mode only works sensibly when JUST ONE memory size * selection is active (set others to "NONE"). The memory space is scanned * asynchronously, so it can have sample alias difficulties. However, the * Warps mode does not use forbid(), permit(), enable(), disable(), or any * other constrictive system call. I just does a lot of read-only memory * cycles and writes the result in its own dynamically allocated memory * space. * * To run MemMometer, simply type * * run MM * * or click on the icon. * * Then open the menu item selections and set them for your configuration. * Frags mode, and 512K of CHIP @0, 0 Meg of Fast mem @ 200000, 0 Meg of * SF mem @ @C00000 are the defaults. The modes selected are color coded * into the "F" and "E" indicators: * * Mode Indicator 2 color WB 4 Color WB 8 Color WB * * Frags E Blue Blue Blue * Warps E White Orange Yellow * * One column: * Chip F Blue Blue Blue * Slow-Fast F Blue Black Cyan * Fast F White Orange Yellow * * Two columns: * Chip +SF F Blue Blue Blue * Chip +Fast F Blue Black Cyan * SF + Fast F White Orange Yellow * * Three columns: * C + SF + Fast F Blue Blue Blue * None F White Orange Orange * * The source code included with this distribution was compiled with the * Manx Aztec C compiler, version 3.6a in 16-bit integer mode. Numerous * type casts in the code, as well as other non-alignments with the Lattice * environment would make compilation under versions of Lattice difficult. * Sorry. Compilation instructions are of course in the makefile included * in the distribution. * * About my part of C code - it wasn't done for speed, as I am sure you can * tell. If I wanted speed I would have used assembly language. It also * likely isn't elegant code, by a long shot (unless it's the part I got * from Rokicki's WFrags). But assembly language is time-consuming to * write, so that won't happen any time soon. Maybe the next thing will be * the AREXX port - so that other programs can specify a low address and a * byte count range for one of the MemMometers to display (say, within the * specified menu selection span). Gross comments about the code or bug * reports may be e-mailed to me at the site domain specified below. * * About everyone else's C code in MM - Let's see, VT100 (Wecker et al) has * been freely distributable since the early days of the Amiga. When VT100 * was first posted, Wecker did not prepend a copyright to the code. He * later discovered that his employer (DEC) routinely required employees to * sign a contract statement which granted to DEC all rights with respect * to codes written by DEC employees, whether the codes were written on the * company's time/facilities or otherwise. I do not know how the matter * was resolved, but VT100 still seems to be on the freely distributable * software list; the VT100 codes, now with parts from many contributors, * are currently maintained by Antony C. Sumrall (acs@ahmdahl.com). The * menus in MM, while styled with the same code forms as were used with * VT100 v2.3, are of course different in content in any case. The WFrags * program was, I believe, a version by Tom Rokicki (the Amiga Tex guy) * probably evolved from the Frags program originally submitted to the net * by Mike Meyer. WFrags was submitted to the net without a prepended * copyright notice, evidently intended as freely distributable software. * * The spirit of these contributions is that they are not to be used for * commercial purposes, and the original authors certainly appreciate * being cited for their work. So I just did that. The timer codes are * exerpted from a network article by Andy Finkel of CBM, submitted as a * demonstration of the ease of implementing the Amiga timer.device in C. * There are supposedly at least two ways to implement the timer.device, * either as a message port to the Amiga Exec, or as an IDCMP feature in * Amiga Intuition. It would seem that the latter would be better for a * program (such as this one) which makes resolute use of Intuition IDCMP * features. However, Andy's code was for the former, and rather than do * whatever would have been required to utilize the IDCMP TIMER flag, I * just went with what Andy originally wrote. So, for my part, I add no * further restrictions to the codes in MM, though I expect everyone must * regard the MM code as owned by Rokicki - even if he is not in any way * responsible for maintaining the codes or controlling the result of their * use. Thus, I submit the following Standard Disclaimer: * * The authors accept no responsibility for anything either beneficial or * detrimental that may happen as a result of using the codes in MM. The * codes are intended for non-commercial use only. * * * Howard Hull hull@ncar.ucar.edu * */