Multitasking

What is Multitasking?

By Martyn Tidd

<img src="/images/atari-phile/mt_t.png" ALT="[Graphic]" align="left">"Multitasking" 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

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

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?

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.

<img SRC="/images/atari-phile/mt_g.png" ALT="[Geneva]">

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.

<img SRC="/images/atari-phile/mt_m.png" ALT="[MagiC]">

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 <A HREF="****.htm">desktop</A> 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 <A HREF="mt_dsk.htm">disk space</A> and <A HREF="mt_mem.htm">memory</A> 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 <A HREF="mt_bas.htm">minimum</A> installation, with <A HREF="mt_nvdi.htm">NVDI,</A> and what I would expect to be something akin to an <A HREF="mt_full.htm">average</A> installation for most people.

Also of great importance is the <A HREF="mt_spd.htm">speed</A> 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

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

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

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

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

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...

Contact:	Titan Designs on 0121-693 6669
E-Mail:	100345.2350@CompuServe.COM
Price:	£59.95 - £79.95 with NeoDesk
Contact:	System Solutions on 01753 832212
E-Mail:	ssolutions@cix.compulink.co.uk
Price:	v5 £69.95+pp - v2 £39.95+pp