More Than One Pair of Hands - AP#4
It says at the beginning of the documentation for Freedom, the non-modal
file selector, "is the future for Atari software". This is probably
something of an overstatement but nevertheless multitasking does add an
extra level of functionality and flexibility to the TOS range of
computers. It's a bit like a hard drive, once you have it you wonder how
you ever managed to do without it. Adding multitasking to your Atari will
also bring it more into line with the capabilities of the more mainstream
platforms. The PC has had multitasking since Windows 3 and the Mac got it
with System 7. Their ability to multitask is one of their major selling
points.
Multitasking has two main uses: you can use it to perform lengthy
tasks in the background whilst you get on with something more
productive or you can switch quickly between applications without
having to quit from one and thereby (in most cases) losing your
place. The former is the more glamourous but the latter is much more
useful. Need to format a disk whilst using yout word processor? Or
copy some files, draw a picture, create a spreadsheet? No problem.
The Downside Multitasking is not all beer and skittles
though. It does bring with it some problems. You would expect that
running a number of programs at the same time would involve the
operating system in more work and therefore slow the system down.
Happily, two of the three multitasking systems available for the
Atari actually speed the system up and for the most part you can toil
away unaware of any slow-down. Of course, if you run lots of programs
concurrently you are going to experience sluggishness. Two or three
won't make any discernable difference to speed though.
Installing any system software takes up memory and multitasking is no
exception. On top of that of course you will have the added overhead
of all the programs you have running too. Both Geneva and MagiC claim
to be installable in 0.5Mb but this won't really leave you any room
to actually use them. For practical purposes 2Mb is the minimum on an
ST, 4 on a Falcon. A hard drive is also highly desirable.
One problem that multitasking brings with it is that of memory
fragmentation. If you load two applications and then terminate the
first, the memory it used is cleared. However TOS will always load
programs into the largest available block of memory and programs must
load into a contiguous block. This means that although your system
may report enough memory, the largest contiguous block may be much
smaller than that. The only way to regain all your memory again is to
terminate all running applications, which kind of defeats the object
of multitasking. If the system is used sensibly however, this should
rarely be a issue.
Although it is possible to write a multitasking system that doesn't
require a Graphical User Interface (it's been done with DOS on the
PC), it's not going to be very intuitive. With a GUI, such as GEM,
the output from each program can be confined to its own window and
the user need only click on a window belonging to another application
to switch between them. Astute readers may already have spotted the
flaw in this plan. Not all Atari programs use GEM and don't,
therefore, output to a window. All three multitasking systems
implement a similar solution to this problem - that of running TOS
programs in a GEM shell and thereby sending their output to a window.
This obviously means a slightly higher memory overhead but the
results are much cleaner than having TOS applications overwrite the
screen and screw up your nice neat display. The main problem is with
programs that don't confine their output to text only and take over
the whole screen as is the case with non-GEM art packages. Unless
they allow some sort of access to the menu bar (usually for running
desk accessories) multitasking is effectively suspended until you
quit that application.
The other problem of course is that GEM only allows seven windows
open at once, which would severely restrict the effectiveness of any
multitasking system. Again, all three systems opt for the same
solution of increasing this limit to something more sensible.
Multitasking flavours There are two ways to persuade a
computer to multitask: pre-emptive and cooperative.
Pre-emptive is theoretically the best option and involves the
CPU allocating each running application a slice of its time.
Additionally, the top process, the one you are actually using, gets a
bigger slice of that time. This is the approach adopted by Windows 95
on the PC and MultiTOS and MagiC on the Atari. In theory, no single
process can hog the system and therefore background operation of
processes is possible. In practice this does not always work as
advertised.
Cooperative multitasking, as it name would suggest, requires that
programs cooperate for it to work. This isn't as bad as it sounds and
doesn't require that programs are multitasking aware. Merely that
they make system calls fairly frequently. Under GEM this basically
means that the program uses evnt_multi() or similar to check for GEM
events, which most do. If another program requires control, usually
by the user switching to it but occasionally by asking for it itself,
control is switched to that application. Most of the time this works
well but if a system call is not made for some time, for example
whilst printing or downloading a file via modem, control is lost and
you, the user, will just have to wait before you can continue
working. Cooperative multitasking is the system used by Windows 3.x
on the PC, System 7 on the Mac and Geneva on the Atari.
What's available? The words "Atari" and "spoiled for choice"
are not often found in the same sentence but with multitasking this
is indeed the case. There are three different systems to choose from.
MultiTOS is the official Atari system. It is slow, memory hungry and
fairly bug ridden. In addition it is no longer supported since Atari
chose to abandon their computer platforms in favour of diving
headlong into oblivion. The other two systems have fairly impressive
pedigrees: Geneva is from American software house Gribnif, and
written by Dan Wilga of Neodesk fame. Neodesk has been around since
the early days of the ST and so, by implication, has Dan. MagiC is
from German software house 2B, the people who brought you NVDI, which
must be installed on almost as many Atari's as GEM.
Although MultiTOS does have its fans, their enthusiasm is generally
for its MinT kernel, which allows the use of alternative operating
systems, rather than its multitasking capabilities. Therefore, this
article will restrict itself to MagiC and Geneva. The comparison will
be distinctly Falcon biased, since that is the machine I use.
However, most the stuff also applies to using the systems on an ST or
TT.
Geneva is supplied on one double sided disk containing all you need
to get you going. The installation program is well up to Gribnif's
usual standard. The programs supplied are Geneva itself; JarXX;
Geneva TOS, the TOS shell; and the Task Manager accessory. There is
also a program that allows the use of Mouse-ka-mania mouse shapes so
that you can annoy the hell out of PC owners with an animated
hourglass instead of the usual busy bee. The manual is a
comprehensive ring-bound tome running to 167 pages. It explains
simply everything there is to know about Geneva and even includes
programmer information. I have owned and used Geneva for about three
years now and it is updated reasonably regularly. The current version
is 1.05 (005) and while this version was not as large an upgrade
1.04, a few new features were introduced such as code to handle
memory fragmentation and much improved (ie. faster) support for the
Geneva/MinT combination which gives all of Geneva's facilities
coupled with MinT pre-emptive multitasking. It can be run either from
the desktop or via the Auto folder, the latter being the preferable
option since memory management is better. Whichever method you use,
JarXX must be installed first. The cookie jar has been a feature of
TOS since version 1.6 and Geneva requires it to work correctly. In
order for earlier TOS to be able to take advantage of Geneva, a
software cookie jar is supplied. However, even if your TOS version is
higher than 1.6, JarXX must be installed before you can run Geneva
(or, for that matter, Neodesk).
Geneva replaces the AES part of GEM with an optimised multitasking
version. Profile will tell you it is version 4.0 but it also includes
some version 4.1 features such as window iconify. One problem here is
that the GEM desktop is not multitasking aware and therefore
multitasking systems cannot use it. Unlike MagiC or MultiTOS, Geneva
does not install its own default desktop. If you launch Geneva on its
own, all you will get is a blank screen with a menu bar. All the
usual desktop functions are available via Geneva's excellent built in
file selector, but are hardly intuitive. When I first got Geneva
there wasn't a multitasking desktop available and I can testify that
it is perfectly usable without one. Now there are a few to choose
from, but Neodesk 4 is designed with Geneva in mind and interfaces
with it seamlessly. Titan Designs do a good deal on a Geneva/Neodesk
bundle.
Programs can be launched via a desktop replacement, the Geneva File
menu, or the Task Manager accessory, whichever is the most convenient
at the time. The Task Manager also acts as a very comprehensive
configuration utility allowing you to customise the keyboard
equivalents; the look and feel of windows, menus and dialogue boxes,
including which font to use (Speedo GDOS is supported); whether to
use pull or drop-down menus; whether alerts should follow the mouse
and a host of other options. Flags can be set for multitasking
options either globally or at individual application level. This
means that applications that misbehave can have their flags set and
force them back into line.
All running applications are listed under the desk menu just above
the accessories (as well as in the Task Manager window). Clicking on
an application name will switch to it. MultiTOS aware applications
that write a proper name to the desk menu also do so under Geneva.
Older programs can be forced to write something more meaningful via
the Task Manager, otherwise the file name is displayed. Tasks can
also be switched by clicking on the menu entry, from the Task
Manager, by clicking on one of their open windows or by cycling
through the applications using the Alternate-Tab keys. This is the
same combination as Windows uses so making things slightly easier if
you use a PC as well as your Atari.
One unique feature of Geneva is its tear-away menus. Any menu from
any program can be "torn off" the menu bar and copied into a window
making it easily accessible at all times. This is primarily useful
for the desk menu, giving you instant one-click access to all running
processes, but works equally well on any AES menu. Geneva will also
add keyboard shortcuts to any selectable item in a dialogue or alert
box. Occasionally, in a multitasking environment, the mouse pointer
can get lost. Neodesk offers a key-combination that will bring it
back, but it's fairly obscure and I always had to look it up. Geneva
has a much simpler solution. By moving the mouse into the menu bar
(you have to guess, obviously) and clicking the left button, the
pointer reappears. This is a very useful option since it is often
impossible to continue work without a pointer leaving nothing for it
but to reboot. If you lose the pointer under MagiC, there is often no
way of retrieving it [unless WinCom is installed - Ed].
Any running process, including Geneva itself, can be "put to sleep".
This means that it is suspended and takes up no processor time. A
single click on its now italicised menu entry will bring it back to
life. Naturally it is impossible to put every running process to
sleep - that would leave you with a frozen computer and rebooting as
the only course of action. Geneva is a well thought out and mature
product which Dan Wilga is still actively developing and new versions
appear fairly regularly. The user interface works in a similar way to
MultiTOS and I suspect that Atari's system was the inspiration here.
However, Geneva has a couple of advantages: it works without crashing
frequently and is considerably faster. Compared to MultiTOS (and
indeed MagiC) program configuration is simplicity itself . Most of
the settings are carried out within the Task Manager and saved to the
Geneva configuration file. Another file, GEM.CNF, can be edited with
a text editor but this is mainly for setting up auto-running
applications and the desktop shell. The system itself is very
configurable right down to individual application level with very few
GEM applications refusing to play ball. My only gripe is with the
lack of a built-in desktop although even this has its advantages
since without one, Geneva has fairly modest memory requirements.
MagiC comes on two double sides disks. There is a installation
program that requires the entry of the disk serial number before it
will work. As well as MagiC itself (which includes a number of
support applications), you also get a couple of CPX modules: one for
configuring MagiC, the other for adjusting the time-slice settings; a
program called Write Back Demon that delays disk writes until the CPU
is twiddling its thumbs; and a number of utilities that may or may
not be useful. I couldn't tell since they were all in German and no
instructions were supplied. The manual doesn't mention them either.
In fact there are a lot of things the manual doesn't mention.
Compared to the Geneva effort, MagiC's manual is more of a short
pamphlet running to just 48 pages. Although there is enough
information to get you up and running, a lot of stuff is either
glossed over or omitted completely. Mention is made of MagiC 4's
ability to use alternate file systems but no clue is given as to how
this is achieved. In the directions for Write Back Demon mention is
made of reserving memory for the cache but no idea is given as to how
this is done. There are also no programming guidelines, although
these are apparently available separately - if your German is up to
it. Because the manual is so poor you get the feeling that there is
more that could be done if only you knew how. For example, MagiC, by
default switches off the blitter chip. There appears to be no way of
over-riding this from within MagiC and I had to resort to the NVDI
configuration to do it.
MagiC replaces the entire operating system, not just the AES portion
as with Geneva. The replacement version is a lot faster than TOS and
for the most part is pretty compatible too. The look and feel is
slightly different and can take a little getting used to. When things
fall over, there are no bombs. They are replaced by a message telling
you what has gone wrong. Unlike Geneva, MagiC does come with its own
default desktop, MagXDesk, which works reasonably well. Replacement
desktops can be used of course - even Neodesk 4 works although it
appears a little sluggish and not totally at home in this
environment. A better option is Ease, which is designed for MagiC and
Thing, the shareware desktop, which was also written with MagiC in
mind [see our desktop roundup - Ed]
Clicking on a blank part of the menu bar drops down a "hidden" menu
which enables you to switch tasks, hide or unhide any running
processes, or start a program. There is also an option to redraw the
screen if some badly behaved program has screwed things up. At the
bottom is an indicator of the amount of free memory available. This
menu is available from within any program that allows access to the
menu bar.
The first thing you notice when running MagiC is just how fast it is.
This is especially noticeable on an 8Mhz ST but it is still pretty
whizzy on a Falcon. Because it completely replaces TOS, the boot
process seems a bit convoluted since once MagiC is loaded from the
auto folder, it starts again. On a Falcon this is where its ST
origins show through most. It spends an inordinate amount of time
checking the floppy drive, something I thought I'd left behind when I
upgraded. It also boots in ST high res until the MAGX.INF file (which
includes the required resolution) is loaded toward the end of the
boot process. None of this is catastrophic of course, just a bit
niggling.
Like Geneva, MagiC is a well thought out and mature product written
by people who really know their stuff. However, version 4 was the
first Falcon compatible version and, considering how long it took to
arrive, not enough has been done to take advantage of the Falcon's
extra features. My impression is that MagiC is a product aimed
primarily at ST users that now also runs on the Falcon. It is
certainly flakier on the Falcon than Geneva, although it is hard to
quantify just how much more often it crashes.
Configuration is almost all carried out by editing the MAGX.INF file,
which is hardly intuitive for the beginner. The manual does give some
guidance in this respect, though not nearly enough. Geneva certainly
is far more configurable than MagiC and it is far easier to do too.
However, most of Geneva's extra options involve the look and feel of
the system and it could be argued that this is not that important.
The inclusion of MagXDesk is certainly better than Geneva's "you
don't need a desktop" approach. MagXDesk is actually quite good
compared to the standard ST affair and even gives Newdesk a run for
its money. I'm told that it's a vast improvement over previous
versions but if you're used to commercial replacements such as Ease
or Neodesk, you're going to be disappointed with it. Still, it only
loads if no alternative is specified and you are therefore not
wasting valuable resources on a utility you are not using. This is in
fact one of MagiC's strengths. It is very modular, only loading
utilities as and when you need them. You can also replace utilities
with better alternatives if you wish so that, for example, if you
prefer that your disks are formatted by Kobold you can specify it as
your preferred disk formatter. MagiC knows all about Kobold and can
be made to interface with it seamlessly. Geneva knows nothing about
Kobold and even Neodesk 4, which does, only has limited support and
requires it to be in memory for it to be utilised.
As of version 5 the MagiC OS also supports Windows 95 VFAT long file
names. This is certainly an improvement on the TOS 8+3 file names but
great care must be taken before setting this up. They can't just be
used willy-nilly - the partition has be allocated as VFAT compatible.
Doing this can cause problems with programs that read your FAT.
Diamond Mirror will report any VFAT partition as having errors. Don't
try to repair it though, unless you're really into restoring your
data from back-up (I speak from experience). Defragmenting a VFAT
partition is also no longer an option. This isn't an Atari thing, the
same also applies to Windows 95. In my opinion, it's not worth the
extra problems it causes. It does, however, add an extra layer of PC
file compatibility which is always a good thing.
Comparison Some parts of a comparison between two packages
can be measured and, out of the goodness of my heart, this is what I
have attempted to do with MagiC and Geneva. I have examined their disk space and memory
consumption. This is important especially to people using "average"
systems without huge amounts of memory and spare hard disk space. I
have tested memory consumption in three different circumstances: a minimum installation, with NVDI, and what I would expect to be something
akin to an average installation for most
people.
Also of great importance is the speed of
operation. Geneva replaces part of GEM and MagiC replaces TOS
completely. Both systems claim speed increases over TOS and this is
in fact one of MagiC's major selling points. The system speed has
been tested under the same three configurations used for memory
consumption. GEM Bench v4.03 was used for these tests.
A full installation of Geneva takes just 449k of space as opposed to
MagiC's 1961k. It should be remembered though (for this and the first
two memory tests) that Geneva does not include its own desktop. Throw
in, for example, Neodesk 4 and you add another 630K to this.
There is a slight problem with the memory tests since Geneva offers
no way of measuring free memory (although MagiC does) without
recourse to additional software. For the tests I used Jeremy Hughes'
Free Memory utility. As you may know, this subtracts its own memory
consumption from the figures giving a true reading of the memory
prior to running it. Or it would be true if both MagiC and Geneva
didn't also run their own TOS shells too. This is not taken into
account but is negligible.
For a basic installation Geneva runs in 688K with MagiC taking up
903K. Most of the time it is unlikely that Geneva would be run in
this way but it is handy to know that it can if memory is tight. Add
NVDI 4.1 and consumption goes up to 1113K and 1309K respectively.
Things get interesting though when a full installation is used. Since
the two systems require slightly different set-ups, it wasn't
possible to run them both with precisely the same auto folder
programs and accessories. Nevertheless I tried to keep them as
similar as possible. The common programs are: Falcon Screen software
with a screen resolution of 768 x 576 in 16 colours, Freedom file
selector and NVDI 4.1. The accessories installed were ST-Guide and Z-
Control. No CPX modules were memory resident. It should be noted that
Freedom isn't that compatible with Geneva and I normally wouldn't use
them together. Geneva installed Neodesk 4 as its desktop, MagiC
installed Thing. Additionally, Geneva added its Task Manager to the
list of accessories. With these set-ups the memory consumption was
pretty close: Geneva used 2248K and MagiC 2329K.
As far as speed goes, MagiC definitely has the edge. The tests were
carried out on a Falcon030 with 4Mb of RAM and TOS 4.02. The screen
resolution referenced against was 640 x 480 in 16 colours. On a
minimal installation Geneva is marginally faster than single-TOS but
MagiC is over 70% faster. It is interesting to note that switching
the blitter on or off makes no difference to MagiC's performance
which leads me to believe that the MagiC version of the operating
system does not utilise the blitter at all.
It was once NVDI was installed that things began to change. Although
MagiC replaces TOS, NVDI replaces the VDI part of GEM, replacing part
of TOS again. With Geneva this means that GEM is effectively
completely overwritten. I was so amazed at the result of these tests
that I had to run them twice more to check that I had got it right.
MagiC's average speed was 232%. Geneva's was 232% - exactly the same.
There were of course many differences in the particular elements that
made up this result but nevertheless, given that one of MagiC's main
selling points is that it speeds up the system, this was pretty
amazing. In a nutshell, although MagiC was faster on most (although
not all) graphics functions, CPU efficiency was better in Geneva.
What this effectively means is that, on a Falcon at any rate, speed
is not a major deciding factor if you also run NVDI.
The more system software is installed, the slower the system will
run. This basic truth is reflected in the results of the average
installation test. MagiC comes out slightly faster than Geneva
However this is the first time that Geneva has had to contend with a
desktop - and a fairly hefty one at that and the 3% difference is
going to be barely noticeable in normal use. Both systems still
managed to run at more than twice the speed of plain vanilla TOS -
with a lot of help from NVDI.
Effectiveness Both systems perform their primary task of
multitasking well although MagiC is probably the slicker package. For
example, if you start a file linked to an application already
running, Geneva will launch another copy of that application. MagiC
will attempt to send a message to that application to load the second
file. This isn't always successful but works on most newer software.
It is especially useful if you have a file viewer such as First Guide
installed. Under Geneva viewing six files simultaneously will result
in six copies of First Guide running. With MagiC, you will only get
the one. Much neater and more memory efficient. To be fair, the
latest version of Neodesk (005) also allows this but Geneva alone
cannot achieve it. MagiC's modular approach to desktop functions is
also very good. You can set up whatever application you prefer for
copy and delete, formatting, and disk searching. Default programs are
supplied but if you've spent an arm and a leg on Kobold, you want to
use it, right?
Geneva, though, doesn't take this lying down. Geneva places no
restriction other than memory on the number of applications than can
be run concurrently and there is an upper limit of 256 windows. MagiC
5 sets the number of concurrent applications to 128 including DAs (up
from previous versions 20) with the maximum number of windows also to
128 (how many applications do you know that restrict themselves to
one window?). Of course, older programs may place there own limit on
the number of windows opened within them but this isn't system wide.
Finally Geneva does something that most Atari owners have wished for
at some time or other: it removes the limit of six accessories.
Ironically, this comes at a time when your need for desk accessories
is diminished because you have a multitasking system. You no longer
need to keep disk formatters et al installed "just in case". If you
need one, you just load it, use it and terminate it or,
alternatively, switch to the desktop and use that. To be fair, the
MagiC manual quite rightly points out that desk accessories go
against the philosophy of multitasking (although it supplies two CPX
modules and you try using them without X-Control, a desk accessory)
but this ignores the fact that the ST is a mature machine and for
most of its life accessories have been an integral part of its use.
Many utilities are only available in this form and some programs,
such as 3D-CAD, rely on them to work properly.
Accessories can be loaded from the desktop using both systems. With
Geneva they load as accessories, under MagiC they load as programs.
Clicking on the closer gadget quits them and deletes them from
memory. This seems to work much better on MagiC 5 than 4 where it was
somewhat hit-and-miss with older accessories. I rather like this
feature since generally, an accessory is only required for a short
period and it's quite memory efficient. Both systems also allow
accessories to be terminated, though if they don't know about Atari's
accessory termination message (introduced with MultiTOS), there could
be problems if they have changed system vectors. Terminating
accessories is actually pretty much of a waste of time. Because they
are loaded fairly early on, termination just leaves an unusable hole
in memory - without increasing the size of the largest block.
The biggest difference between the two systems is, of course, that
Geneva is cooperative and MagiC is pre-emptive. Most of the time this
isn't going to make one iota of difference to the way you work with
either package. The pre-emptive advantage comes when you would like
to continue working whilst some lengthy process is carried out in the
background. Except it doesn't particularly. Lattice C still locks you
out during compilation and even a more recent application such as
Papyrus battles like hell to retain control during printing. If you
do manage to persuade it to allow you switch to another process,
there are long periods when the system is at best sluggish and often
completely unresponsive. You will end up coming to the same
conclusion as you did all those years ago with the background
printing facility in First Word Plus: it isn't worth the frustration.
You're better off going and having a quiet coffee and leaving it to
get on with it. This is apparently set to change though with the
latest release of NVDI (4.11) which supports MagiC 5's multitasking
threads. According to System Solutions, background printing will
become a reality. I hope it's true but I remain to be convinced. This
is not say though, that no applications work well in the background.
I have just archived a bunch of files with LHarc whilst writing this
and there was no discernable slow-down. It also worked with ST-Zip.
To be fair, this was also possible under Geneva but the slow-down was
unacceptable. Although pre-emptive multitasking offers some
advantages over its cooperative counterpart, don't expect it to be
able to perform all tasks in the background.
Ease of use If you can use GEM then you will find either
system reasonably easy to use. It can be slightly disconcerting at
first to find windows from several different programs on screen at
the same time but you soon get used to it. In any case, both MagiC
and Geneva offer ways of getting rid of programs not currently in use
without actually terminating them. MagiC's Hide function does not
always work since it moves the windows off screen and a few programs
object to this (Edith and Kivi spring to mind). When it does work,
which is most of the time, it means that programs continue to work
out of sight. You can also freeze programs from within the Program
Manager, although that part of MagiC doesn't work with BlowUp
installed. Geneva's Sleep option is always successful. Both packages
offer AES 4.1's iconify option. This allows more recent software that
know about it to reduce their windows to an icon at the bottom of the
screen, which is yet another way of clearing the decks.
Of the two, Geneva is probably slightly easier to get on with.
Because it only replaces the AES, most of the system is pretty much
what you are used to with single-TOS, which makes the learning curve
gentler. Additionally, it is considerably easier to configure via the
Task Manager, there is an on-line help system and the manual is
comprehensive and well written. Whilst the MagiC operating system is
TOS compatible, it does have a few quirks of its own that can take a
bit of getting used to.
Compatibility If there is one thing that is essential with
any operating system enhancement it is compatibility with other
software. Happily both systems performed well with almost everything
I was able to throw at them. Naturally I have been unable to test
them with every Atari program ever released, just what is currently
residing on my hard drive.
Geneva has a problem with BlowUp on the Falcon. It is not a serious
problem and only crops up with software that changes the screen
resolution, for example the Apex viewers. The best solution I have
found is not to use BlowUp but to use the PD screen expander Falcon
Screen, which works flawlessly with both Geneva and MagiC.
Atari's Calendar/Appointment manager crashes if loaded as an
accessory but for some reason works when as an application.
Geneva can be persuaded to work with the excellent Thing desktop but
there are a number of problems - not least that Thing ignores the
environment set up by Geneva so that Geneva TOS does not get used for
non-GEM programs. There may be ways round this but I haven't found
them yet.
Finally, Geneva has trouble with Freedom, the file selector designed
for multitasking. It does work, but some of the buttons don't draw
themselves correctly. This is presumably something to do with the way
they are implemented in Freedom since Geneva normally has no trouble
with standard AES buttons. Freedom also will not load using the
FFSEL.INF option that makes it non-memory resident. It must be
installed explicitly either as an application or accessory. Finally,
whatever you do, don't iconify Freedom under Geneva. It doesn't work
and it causes all sorts of strange things to happen.
Having said all that, I have been using Geneva since it was released
- first on the ST and then the Falcon - and it just gets better and
better. Incompatibilities have become fewer with each new version.
Additionally, even programs that initially seem to misbehave can
usually be made to work by changing their Geneva flags. Since this
can be done at application level, you can just set them and forget
them.
MagiC also has it incompatibilities and, at least on the Falcon,
there are more of them. For a start it dislikes the way some programs
implement cascading menus, especially, it seems, programs from Hi-
Soft such as Lattice C, True Paint and True Image, and it shows its
distaste by refusing to display them. One of the mysterious
undocumented programs supplied with MagiC, XMEN_MGR, fixes this but
not completely. In Profile 2, for example, cascading menus cascade
but don't respond to mouse clicks.
There is a bug in TOS 4 that causes Getrez() to return an incorrect
value except with ST compatible screen modes. MagiC fixes this bug.
Most recent software, in accordance with Atari programming
guidelines, doesn't use Getrez so it doesn't really cause too much
trouble. Strangely, having it fixed does. The problem comes with
older programs that test their video resolution using Getrez.
Generally, a GEM program that thinks it's working in ST High will
work just as well on larger screen sizes. If, however, it receives a
screen resolution back that it doesn't recognise, it may refuse to
run. This is the case with Home Accounts 2, which works fine on the
Falcon in VGA 2-colour mode either under single-TOS or Geneva, but
refuses to run under MagiC.
Another problem with older software can be their memory management.
Many older programs grab all the available memory. This is fine under
single-TOS but not particularly desirable when multitasking. Both
MagiC and Geneva offer the option of setting the maximum amount of
memory certain programs should take but under MagiC this is again a
function of MagXDesk and therefore may not be available when using
alternative desktops. This means that although programs like First
Word Plus will run, you will be unable to load anything else until
they have been terminated.
There is also a memory management problem with Superbase Personal 2,
which often reports that it is out of memory. You can get it to
behave by rewinding the file back to the beginning but this can be
inconvenient to say the least. This is a particularly strange
problem. Superbase was one of the first serious applications I bought
back in 1988 and it is one of the cleanest and best written GEM
programs I know. It has followed me from a basic 520 STFM with TOS
1.2 through numerous memory upgrades, TOS 1.4, Overscan, and finally
onto the Falcon, adapting itself to each new environment as it went.
It has never before had any trouble working.
The Sam utility supplied with Falcons does work but many of the
events appear to be carried out differently under MagiC so the sounds
don't play. The only one I could get to work was the keyclick. There
are other purely aesthetic programs that don't work with MagiC, such
as Mouse-Ka-Mania. I'm afraid you're stuck with the dull old arrow
and busy bee.
A number of users have reported problems with ImageCopy 4. Apparently
you need NVDI 4 to cure this. Since this is what I use anyway, I have
never experienced any trouble.
MagiC, like Geneva, has a problem with BlowUp, though not the same
one. Part of MagiC, the Program Manager fails to work properly with
BlowUp installed. It is impossible to get out of and the only cure is
a reboot. Again, this can be cured by using Falcon Screen instead.
When I first bought MagiC, I had just released version 1.0 of
MultiPlicity, the Falcon multimedia authoring package. Although it
had worked well under MultiTOS and Geneva, MultiPlicity had serious
problems with MagiC. The main reason for this was that MagiC installs
a version of the AES below 4 (3.99). This basically means that MagiC
is not wholly MultiTOS compatible - some parts are missing. In
MultiPlicity's case it was the absence of shel_write() in mode 0 that
caused the problems. MultiPlicity and, I believe, Thought 2 are the
only programs that use this feature that I am aware of, but there may
be others. A bigger problem is that MagiC doesn't support AES 4's
toolbox functions. I know from postings on COMP.SYS.ATARI.PROGRAMMING
that many programmers are disappointed about this and, judging from
replies from one member of the MagiC programming team, it is not
something that's going to be changed in the foreseeable future.
Another problem is that since MagiC places a limit on the number of
programs allowed to run concurrently, some programs that check for
multitasking may not detect MagiC as a multitasking system. This was
a problem with MultiPlicity (now fixed) and remains a problem Thought
2.
Connected to this, on the Falcon at any rate, is the fact that most
parts of the operating system installed by MagiC are lower version
numbers than those installed by TOS. For example, on my own TOS 4.02
machine, GEMDOS is version 0.30 but MagiC installs version 0.19 and
TOS becomes version 4.00. This has no adverse effect on performance
and I could be accused of being picky, but it is slightly annoying to
have your computer downgraded, on paper at least. It appears to me
that this is another example of MagiC being aimed mainly at ST owners
but with Falcon compatibility added. There is, of course, nothing
wrong with this. After all, there are far more STs knocking around
than Falcons.
Stability Like any other operating system, both Geneva and
MagiC crash occasionally. Under Geneva, everything is frighteningly
familiar including TOS's bombs, although if you have Neodesk 4
installed too, you can also get a less cryptic explanation as to what
has happened. MagiC doesn't use bombs, it either displays a dialog
box with an error code or, in the case of a system crash, overwrites
a portion of the screen with a message. Perhaps it's me, but these
messages don't seem much more illuminating than the bombs.
What happens after a crash depends on its cause. It's difficult to
quantify, but under Geneva most crashes just take out one program.
This appears to be less the case with MagiC. Certainly I would judge
Geneva to be the more stable of the two systems. MagiC has a couple
of errors that bring the whole system down: a GEMDOS error and
running out of stack space. System Solutions inform me that unlike
TOS, stack space under MagiC is fixed. There is apparently no way of
increasing stack space.
Conclusion You need a reasonably powerful system, certainly
in terms of memory and hard disk, to be able to utilise multitasking.
But if that's what you have got then I would strongly recommend it.
Both MagiC and Geneva are effective and worthwhile additions to your
auto folder, but give MultiTOS a wide berth.
Both systems have their strong points. MagiC is certainly
considerably faster and, for ST owners, you will get an upgraded
operating system thrown in. Its modular design is also very flexible
and allows you to use your favourite utilities for normal desktop
tasks fairly seamlessly. MagXDesk means that MagiC is complete and
ready to run. However, although it is better than the normal GEM
desktop, it really isn't up to the standard of most replacements and
I would expect the majority of users will get something else fairly
quickly. The fact that it is pre-emptive means that some tasks can be
carried out in the background but this doesn't always work and I
certainly wouldn't recommend MagiC over Geneva purely for this. One
hidden advantage of MagiC is its German origin. Consequently it is
well supported by other German programmers, in other words, almost
everyone. For example, a small auto program called Alice enables all
programs to be iconified, not just those written to do so. This is a
facility not to be sneezed at, especially when multitasking. Although
the author says he will write Alice for Geneva and MultiTOS too, if
there is a demand, currently it only works with MagiC. There are also
the Windows 95-alike Appline and Start-Me-Up and the useless but
wonderful Stewart. In contrast, Geneva has very little support except
from the author.
Geneva, on the other hand, uses less memory and disk space than MagiC
and, on the Falcon especially, it is considerably more stable.
Because Geneva only replaces the AES portion of GEM, Geneva is very
similar to single-TOS. Prettier but similar. This makes it easier to
adapt to when you take the plunge into multitasking. By installing
AES 4, Geneva is MultiTOS compatible so programs written to run under
MultiTOS should also run under Geneva without problem. Because it is
so configurable it is usually easier to persuade older software to
run under Geneva than under MagiC. All the configuration is handled
by Geneva itself, whereas MagiC hives off some tasks to MagXDesk,
which could be a problem if you don't actually use MagXDesk. So which
should you buy? If you run an ST, especially with a TOS version below
2.06, MagiC is probably the better buy. Your computer will be faster
and you will get a much better operating system thrown in not to
mention the ability to multitask. MagiC is a fairly mature product on
the ST and is, I am told, very stable. You will need plenty of memory
though. On my daughter's 2Mb machine, running MagiC with NVDI 4 meant
that there wasn't enough memory left to load Papyrus.
On a Falcon the choice is less clear-cut. MagiC 4 was the first
version to be Falcon compatible and it seemed to me that there were
still a few bugs that required eradicating. With version 5 many of
the problems have been dealt with but stability still appears to be
problem, though less so. Also, if you are one of those people who
like to add completely useless but fun enhancements to your system,
such as sound effects connected to events and different mouse
pointers, you may well find that MagiC doesn't want to play. MagiC is
certainly fast though, and its modular nature makes it a joy to use.
Not that Geneva is sluggish in use - far from it. Users of single-TOS
will not see any noticeable slow-down unless they have an inordinate
number of programs running concurrently, and this also applies to
MagiC. Its greater configurability and lower memory requirements are
also big pluses, as is the far superior manual. It is also more
stable than MagiC, and compatibility is better, which to my mind is
very important. There are few things more annoying than a system
crash causing the last n hours work to be lost.
So which one do I use? In truth I still haven't made up my mind and
both systems reside on my hard drive ready to be selected from Stoop
at boot time. Currently my choice is MagiC, but a couple of weeks ago
it was Geneva. By the time you read this it could be Geneva again.
Whichever one I use, I miss features of the other. I had hoped that
the respective version 5s of each program would help me decide but
frankly it just made things worse. Oh well, perhaps version 6...