08/1997
Path: menudo.uh.edu!menudo.uh.edu!usenet From: markus@techfak.uni-bielefeld.de (Markus Illenseer) Newsgroups: comp.sys.amiga.reviews Subject: REVIEW: GigaMem 2.0 Followup-To: comp.sys.amiga.applications Date: 20 Feb 1993 03:28:54 GMT Organization: The Amiga Online Review Column - ed. Daniel Barrett Lines: 488 Sender: amiga-reviews@math.uh.edu (comp.sys.amiga.reviews moderator) Distribution: world Message-ID: <1m48hmINN90u@menudo.uh.edu> Reply-To: markus@techfak.uni-bielefeld.de (Markus Illenseer) NNTP-Posting-Host: karazm.math.uh.edu Keywords: virtual memory, MMU, RAM, commercial PRODUCT NAME GigaMem 2.0 (GigaMem 3.0 with 68040 support is available now) BRIEF DESCRIPTION GigaMem is a software package which provides virtual memory for Amiga Systems that have Memory Management Units (MMU) and a hard drive. AUTHOR/COMPANY INFORMATION GERMAN DISTRIBUTOR Name: BSC Bueroautmomation AG Address: Lerchenstrasse 5 D-8000 Muenchen Germany Phone: +49 89 357 130 0 FAX: +49 89 357 130 99 USA DISTRIBUTOR Name: INOVAtronics Address: 8499 Greenville Ave., Suite 209b Dallas, TX 75231 USA Phone: (214) 340-4991 LIST PRICE (approximate) 149.- DM, which is approximately $100 US. SPECIAL HARDWARE AND SOFTWARE REQUIREMENTS HARDWARE GigaMem needs an Amiga System with a working Memory Management Unit (MMU), which is available on most accelerator cards (e.g., A2620, A2630) or in the Amiga 3000 and Amiga 4000. It does not work with the 68000, 68020 without 68851 (MMU), 680EC20 (can only address 16 MB of RAM), nor 680EC30 (MMU-less version of 68030), as all of them do not come with a built-in MMU. To be able to swap the content of the virtual memory, GigaMem needs a reliable medium. In most terms, this is a hard drive. The more space is available on this hard drive, the more virtual memory you can obtain with GigaMem. Basically, at least 100K of (real) RAM are required. The more RAM you have, the faster GigaMem will work. SOFTWARE Amiga DOS Version 2.04 or higher is recommended. Amiga DOS Version 1.2 and 1.3 are supported. COPY PROTECTION None. GigaMem installs on a hard drive using the standard Commodore Installer program. MACHINE USED FOR TESTING GigaMem was tested on an Amiga 2000 with A2630 turbo card (4 MB of 32Bit RAM), A2091 SCSI adapter with several hard drives, and 4 MB of 16 Bit RAM. It was also tested with 1 and 2 MB Chip RAM on this A2000. A second test platform was an Amiga 3000 with 2 MB Chip, 8 MB Fast RAM and several hard drives. On this system, a 1.9 GB DEC drive was used for testing real large amounts of virtual RAM. On both Amigas, AmigaDOS 2.04 and Kickstart 37.175 was used. For some further tests, a A2065 Ethernet card was used. As other hardware is not needed for a virtual memory system, it will not be mentioned here unless it interfered with GigaMem. OVERVIEW When virtual memory systems started becoming available for the Amiga, I wondered how they could be useful on an Amiga at all. At my university, I work with several image processing packages and like to port some these to my Amiga. Image processing is an expensive job requiring a lot of memory. It uses a large amount of data (pictures in any form) and requires a fast CPU (to use filters, detectors, etc.). A single 512x512 24Bit Image uses 700KB of RAM! Now imagine if you have a whole sequence of pictures, or if you have to compare several pictures simultaneously! On the Amiga, you always get in trouble with this if you don't have enough RAM. For that purpose, a virtual memory system is exactly what you need. It provides a way to simulate RAM on an external medium, such as a hard drive. GigaMem is such a product and will be tested on the platform mentioned above. ANY virtual memory system needs a MMU to be able to provide such a service. In addition, the OS must be able to track memory resources somewhat. Fortunately, AmigaDOS does that with AllocMem() and AllocVec(). Even better, Amiga DOS provides a way to allocate specific RAM, such as Public and Chip RAM. Basically, the 68030 together with the 68851 (MMU), is able to address 4 GB RAM. The Amiga system does split this into two 2 GB partitions of RAM. So, any virtual memory system could supply 2 GB as maximum amount of RAM. GigaMem does provide 1 GB RAM max. During my tests, I was able to add more, but I unfortunately encountered a bug in GigaMem 2.0 here. There was no check for more than 1 GB RAM. This problem vanishes with GigaMem V3.0. You might consider 1 GB of virtual RAM as Utopian, but I know of many purposes where this amount is really needed. INSTALLATION GigaMem comes on one disk. It can be installed manually or with the supplied Commodore Installer program. The Installer works only on a correctly set up Amiga system. From within WB 2.0, programs can be started at WB start time by placing them into the SYS:WBStartup drawer. A wrongly installed system will not allow a correct setup of GigaMem using Installer. GigaMem will install itself in the SYS:WBStartup drawer and copy some files to its own directory. Also, a vmem.library will be copied to the Libs: drawer. Preferably, GigaMem works on hard drive based systems. Floppy-only systems won't have much luck using the package, but it can be done. (I have not tested this.) Following the instructions in the manual, GigaMem-Prefs is started. A full flavored, Style-Guide-compliant, Intuitionized window opens and allows the user to install the virtual memory system on the Amiga. The window is "localized" with the text is in English by default. German and French text are also available. The window is separated into two main parts: Memory Configuration, and Program Database. The part for the memory configuration has Gadgets for Virtual Memory, Buffer Memory, Cache Memory, and entries for the Swapping Medium. The manual explains the Gadgets and their functions in detail. Just let it be mentioned that the Buffer Memory is essential for the speed of the virtual memory, as this buffer will be swapped. The larger this buffer, the more real memory will be used for swapping, and the faster GigaMem will work. The Swapping Medium can be defined in two ways. You can designate a partition of a hard drive for GigaMem's use, or use a normal, sequential AmigaDOS File on any hard drive or other AmigaDOS media. The solution with the partition is preferred: AmigaDOS is not used, so it is faster and will not interfere with any AmigaDOS partition. Any hard drive should work here. Special informations for the mask-entry are read from the Rigid Disk Block (RDB) of the hard drive; if this is not available, the Devs:Mountlist file is scanned (for Amigas with no autoboot capability). I couldn't test GigaMem on a system which does not provide the RDB, but I see no reason why it should not work. Using an AmigaDOS File allows to set up GigaMem quickly and is useful for temporary usage. This solution is slower, but it works on every medium; even swapping via network is possible. After defining the amount of virtual memory and the way of swapping the memory, the installation is almost done. On the left part of the window, a database will show up in a listview (scrolling list) gadget. This lets you specify how the virtual memory should be used by individual programs. Some programs are already listed: AdPro, Cygnus Ed, Audio Master, Maple, Pagemaster and many more. Some entries have specific configurations already prepared. For AdPro, the configuration shows that the authors of GigaMem intended to give it virtual memory first. For AudioMaster, a comment states not to use the HiFi-Play-Mode. This is because AudioMaster will disable the system in this mode, and therefore disable GigaMem as well. For each Program in the database, a priority of the use of virtual memory can be given: use virtual memory before using real memory, use real memory first, use only virtual memory, or use only real memory. Thus, the user can provide specific types and amounts of memory to specific programs. This is a very nice feature of GigaMem: it shows that the programmers have been aware of the MEMF_PUBLIC problem. (This is a flag in AllocMem() to specify special RAM, but it was misinterpreted by some programmers in the past.) An automatic way of detecting the need for virtual memory using this flag will probably fail on many programs. The database of GigaMem allows the user to enable or disable the access to the virtual memory to a specific program. New programs can be added to the database using a standard (ASL) file requester or by dropping the icon on the GigaMemPrefs window (AmigaDOS 2.0 and higher only). There is a special entry, External Programs, which allows one to specify the settings for the programs supporting virtual memory via the supplied vmem.library. After setting the database, one can save the actual configuration, or just use it temporarily. GigaMem is a Commodity under OS 2.0 and higher, so its preferences can be changed online using a hotkey or the Commodities Exchange tool. Under WB 1.2 and 1.3, the GigMemPrefs Tool has to be started again. After either a reboot, or after starting GigaMem, the system will provide virtual memory. It is really nice to see this new entry on the WB Screen: 1,502,106 CHIP 3,436,340 other RAM 39,345,234 VMem (Snapshot, 40MB virtual memory) Also, the 'Avail' command shows the new amount of RAM: Type Available In-Use Maximum Largest chip 1473680 622448 2096128 1260560 fast 8423928 5207560 13631488 5242880 total 9897608 5830008 15727616 5242880 (Snapshot, 5MB virtual memory) This shows that the largest available Block is at least of the size of the amount of provided virtual memory. This is important for many programs, as they need contiguous RAM. TESTING Now, as everything is set up, we can start testing. Using both ways of swapping the virtual RAM, I've set up several test configurations on both of the Amigas listed above: 40 MB partition using 40 MB vmem 1 MB Buffer Cache 40 MB Amiga DOS File using 40 MB vmem 1 MB Buffer Cache 512 MB partition using 512 MB vmem 2 MB Buffer Cache 1 GB partition using 1 GB vmem 4 MB Buffer Cache The buffer cache is not very large but seemed to be sufficient during the tests. The manual states that the half of the real RAM should be used as a buffer. You have to find a suitable configuration yourself here (usage of real RAM vs. usage of VMem). On the software side, I tested AdPro, PBMPlus (an image converter package), CygnusEd, Maple V, and several other programs known to like large amounts of memory. As a "stress test," I launched several commodities and other programs (a music player, a 'Dir sys: All' in a shell and such), to test the behavior of GigaMem in a multitasking system. The initial test was to copy many large files into RAM:. After filling up the normal (real) RAM which was left, the virtual memory is used. The hard drive begins to spin and ... nothing happens. The files were all copied into RAM:, no problem at all. In all 4 configuration, this test worked. I admit, this is not a good test, but it tests if GigaMem is working OK. The next test was to use the commonly known memory-hog AdPro (Art Department Professional), an image processing toolkit. It likes to eat all the available RAM in the system. This is also the case when using it with GigaMem. AdPro failed to run with the 1GB VMEM configuration (rather funny, I think); it just liked to work with 512 MB. Converting a large (75%) JPEG picture (1600x1280x24) into an IFF picture takes a long time, but it did work without any problems. Using some of the filters was successful and still showed the stability of GigaMem. The same JPEG-picture was used with the PBMPlus-library. The Amiga Version of PBMPlus can use both, RAM and file-oriented conversion. If enough (contiguous) RAM is available, RAM is used. PBMPlus had no problem with GigaMem at all, even though, like AdPro, it is a real memory-eater. All configurations worked fine. For Cygnus Ed, I created a large text file (10MB) containing only the character 'a' in it. This file was then loaded into CED and a global search-and-replace operation was performed to turn every 'a' into 'b'. A simple test, but very effective, since every byte has to be replaced, which means a lot of swapping and paging to the hard drive. GigaMem worked fine in all configurations. The next test was Maple V, a powerful mathematical software package for several computer platforms. Maple can calculate to arbitrary floating point precision. The simple test was to copy the number pi (3.14159...) with more than 1E399 decimal places of accuracy into another variable. This was a very heavy test, but did not fail on any configuration. But it did take a great deal of time. *sigh* All of the above tests were successful, except for the one where AdPro refused to work with more than 512 MB RAM. GigaMem takes time, and the hard drive is stressed, but it works fine. The overall speed is not bad, and it gives me the feeling of having a Unix machine under my fingers. A Sun 3/60 or 3/80 would swap more than GigaMem, but they don't work the same way. It is really astonishing to see how easily GigaMem worked with large amounts of data. I tried to setup more than 1 GB of virtual memory, as though the manual states at most 1 GB is possible. I was told that this is the maximum size. Any other size could not be tested. To make it short, I've been able to work with 1.5 GB of virtual memory without any problems. The only problem I had was to fill that memory! It takes a long time to fill 1.5 GB of RAM. For using the "AmigaDOS file" method of swapping data, I tried another nasty solution: I mounted a hard drive from a UNIX environment to my Amiga via NFS (Network FileSystem) and the Amiga TCP/IP, using a A2065 Ethernet card. The speed of the Ethernet card is about 300 KB/second. This test was made to test the behavior of GigaMem and the usage of the Zorro Bus: large amounts of data have to fit into the bus, and the Ethernet card is not as fast as a hard drive, and it has only a 8K buffer for its FIFO buffer.... GigaMem had no problems at all accessing this remote file. The FASTROM option of CPU (WB2.0 command) and SetCPU (PD program by Dave Haynie) which also creates a MMU table worked fine with GigaMem. DOCUMENTATION The documentation is a full flavored binder, separated into two main parts, the German and the English manual. The two differ in some ways, but only in some details. It looks like someone of the Relog AG wrote the English manual first, and someone from BSC wrote the German manual. One can see some strange translations, but at least they are used throughout the whole manual. The manual itself is very clear from the beginning. The different ways of installing a virtual memory system are explained with their basic advantages and disadvantages. The problems which may occur are discussed and the ways to solve them are shortly but accurately explained. Some hints and tricks are given for more experienced users, along with special tricks for some special programs which normally would not work with virtual memory. The manual leaves almost nothing unmentioned, though some points are not really clear afterwards. For instance, the problems with some Mountlists and special DOS Flags could be made clearer. The manual tries to address itself to both beginners and intermediate users. Experts won't have any problems at all, but won't be satisfied as the manual does not explain in depth the details of GigaMem. For the beginners, the manual is not easy to read and requires regular use of the Amiga System and some knowledge of Mountlists and devices. On the disk, a file "LastMinute.doc" gives some facts about some new features, or warns about using a specific product which has not been listed in the printed manual. LIKES AND DISLIKES Personally, I really like the Intuitionized appearance of the setup of GigaMem. It does provide a very easy way to configure the virtual memory, the needs of specific programs, and the needs of the user. The system itself is almost invisible to the user, once started. It is very transparent and very reliable. I like the way the installation works, using the Commodore Installer. Of course, it requires a correct setup of the Amiga to start with. The best advantage is that you are able to give virtual memory to very specific programs, and even more, tell them not to use virtual memory, if you know they don't like it. This offers high security to your system. I don't like the German part of the manual, but only because it uses some very uncommon words (bad translation?). Why didn't the (German speaking) authors write the manual themselves? It looks like they want to invent a new language, rather than use commonly known words. The problems which may occur on some systems using a non-standard way to hook up a hard drive are not clearly explained. Of course, this is not a problem of GigaMem, but the user is left alone here. I am almost sorry, but I have no wishes for the next version. COMPARISON TO OTHER SIMILAR PRODUCTS I have used the VMEM system of my old Evolution SCSI adapter (Macro Systems) two years ago already. I was never satisfied of the way it provides virtual memory. VMEM did only run with the Evolution adapter, and only on specific partitions on the hard drive. But the partition was not read out of the partition table -- the specs were given manually by the user -- so if the user made a typo, VMEM could crash your machine immediately and seriously. Also, the system was not very stable and did not work with some programs. There was no way to enable or to disable the virtual memory for specific programs. Another product is available on the market to provide virtual memory. It's called XMEM. Unfortunately, I wasn't able to test it yet. I was told it is a bit faster than GigaMem, but less reliable. It does use the MEMF_PUBLIC flag of the AllocMem() function to detect whether a program desires virtual memory. There are some PD systems providing virtual memory. One of them appeared on a PD disk of the German Amiga Mag "Amiga". This one never worked for me. The binary was not executable. Another could be found on the Internet, but was not more than a developer system, and didn't provided a way to give virtual memory to the whole system, but to a linked program. Of course, one might compare GigaMem with a working UNIX (TM) system. There, the system always is set up with a specific amount of virtual memory. But the OS already provides virtual memory; thus, we can't really compare it with any of the Amiga virtual memory systems. BUGS I was not able to find a major bug. I am steadily in contact with one of the authors of GigaMem, and talked with him about future versions of GigaMem. The problem with the 040 MMU have been elaborated. A working version is available right now. As I am writing this, GigaMem Version 3.0 is available. This version merely is a bug fix release. No really new features have been included. VENDOR SUPPORT I am in the lucky situation to know two of the authors of GigaMem. But I purchased GigaMem the normal way. I bought it when it was just coming out last year. The distributor had no idea how to distribute GigaMem then, so I got just the manual and one disk. This should have been changed by now; e.g., a box or a nice folder. At least I was impressed by how fast I got the system (1 week). One plus for the distributor. As I have had no problem with GigaMem yet, I have not contacted the vendor nor the authors for an update or bugfix yet. The distributor, BSC, does have a HotLine especially for GigaMem. WARRANTY Standard warranty applies to GigaMem. In case of a disk damage, the disk will be replaced according to the manual. No specific warranty time is given. In Germany, it is at least 6 months by law. CONCLUSIONS The product offers a fair way to add more temporary RAM to your system; thus, any price below the price of REAL RAM is justified. Even a large hard drive is far cheaper than the same amount of (virtual) RAM. GigaMem is useful for everybody: for someone who has to deal with large amounts of RAM every day, and for the one who has a use for it only once a month. Professionals might consider real RAM before purchasing GigaMem; but for testing and temporary using large (real large) amounts of RAM, GigaMem really fits. On a list of 0 up to 5 stars, i would give 4.5 stars. COPYRIGHT NOTICE This review is Copyright 1993 Markus Illenseer. All rights reserved. Include the standard disclaimer here. The author of this text is not responsible for anything if you get into some serious problems due to this text. -- Markus Illenseer EMail: markus@TechFak.Uni-Bielefeld.de Universitaet Bielefeld Technische Fakultaet < this space intentionally left blank > D-4800 BIELEFELD 1 'TTY-fighters attacking!', Con Solo shouted --- Daniel Barrett, Moderator, comp.sys.amiga.reviews Send reviews to: amiga-reviews-submissions@math.uh.edu Request information: amiga-reviews-requests@math.uh.edu Moderator mail: amiga-reviews@math.uh.edu