Subject: REVIEW: GigaMem 2.0
From: [email-masked] (Markus Illenseer)
Date: 20 Feb 1993 03:28:54 GMT
Newsgroups: comp.sys.amiga.reviews

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: [email-masked]
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:	[email-masked]
   Request information:	[email-masked]
   Moderator mail:	[email-masked]