STEP 1: Understanding Atari GDOS Part II
Maurice Molyneaux designs game graphics, consults for software companies and creates animated cartoon productions using his ST. Despite a ridiculously French name, he was born in Vicenza, Italy, and denies vicious rumors that he eats escargots and calamari while computing. His DELPHI username is MAURICEM.
I hope the past 30 days has been enough time for you to digest all the information about GDOS provided in last issue's Step 1. This time we'll get away from what GDOS is and discuss using it, and problems associated with it. In any case, you may want to keep last month's issue handy in case you find a need to refer back to part one of this subject.
Giving it the boot
As stated last issue, GDOS is a program that must be installed by placing a copy of it in the AUTO folder of your boot disk and starting or resetting your machine. When the system is booted or reset, it runs all programs from the AUTO folder before going to the GEM Desktop. Remember, it will only run .PRG programs. If a program has a different extender, it won't run (so you can't use the .APP [Application] extender). You should know what your boot drive is, but just in case, we'll cover that now (if you know this, and most of you probably do, skip over the next paragraph).
The boot drive is where your ST looks for the AUTO folder, desk accessories and a DESKTOP.INF file. If your system is floppy-based, then your boot disk is drive A (the internal drive on a 520STfm, 1040ST or Mega). If you have a hard disk, it is possible that it is the boot disk, but whether or not this is the case depends on how the hard drive is configured. Every hard drive I've ever used for the ST can be set up to auto-boot. If auto-booting is enabled, the first partition of the hard disk, usually drive C, is the boot drive. If not, it will be drive A, as usual. In the case of some hard-disk driver software, the hard disk can be treated as the boot drive, but this will only happen if a special hard-disk driver program is present on the A drive, which forces the system to turn around and boot from the hard disk.
If you have an auto-booting hard disk, but are running your GDOS software from floppy, you can force the system to boot from the floppy (and thus run GDOS from the AUTO folder there) by simultaneously pressing and holding down the alternate, shift and control keys while booting the machine (if your machine has the Mega ROMs you should not press these keys down until the floppy drive light comes on, otherwise the system won't boot from the floppy).
Be warned, however, that forcing this type of boot can, with some hard-disk driver software, cause the system to forget the hard disk is present. You will have to test this on your system to see if this is the case. If it turns out that booting in this fashion does cause you to lose access to the hard disk, you will either have to place a copy of your hard driver's booting program to the AUTO folder on the floppy disk of the GDOS application, or install GDOS on your hard disk (which is the easier way to go).
If you're using a floppy-based system, you can probably boot with a backup copy of the GDOS application you are planning to run, as chances are it will already have an AUTO folder and GDOS set to go automatically. This might be fine most of the time, but if you want to change any aspect of what GDOS does and uses (such as adding or deleting fonts and device drivers), or if you want to have more than GDOS alone run from the AUTO folder, you'll probably want to put it on another disk, along with other AUTO folder programs, desk accessories, etc. This is also the reason hard-disk users will probably want to put GDOS on their hard drives.
To install GDOS on a disk other than the application disk the first thing you need to do is copy it to the AUTO folder of your boot disk (if you don't have an AUTO folder on your boot drive, create one), and that does it for the program. Next, you should make sure that GDOS's ASSIGN.SYS file is in the root directory of the boot drive, and that the drivers and fonts (discussed last time) are in the directory specified by the ASSIGN.SYS file. If, for any reason these files are not where the ASSIGN.SYS file says they are, you will either have to move them to the correct place or edit the ASSIGN.SYS file to reflect their actual location. (For information on the structure and editing of an ASSIGN.SYS file, see last month's article).
Once all this is done, you should be ready to roll. You just boot your system and GDOS should install (you'll see a message stating as much during the boot-up process). You can then run your GDOS application and everything should be hunky-dory.
"Should be" are the operative words. If your GDOS application uses GDOS fonts, try to see if they are available. If none are, either none were present or the ASSIGN.SYS file told GDOS to load them from the wrong place (or contained the wrong filenames). If the application stores its data as a Metafile (see last issue) it probably uses a META.SYS driver to do so. If you find you cannot save your work, this may be the problem. For example, if Easy Draw cannot find the META.SYS file, when you attempt to save your work, an alert box will appear stating as much, and giving you the option of retrying or cancelling. If META.SYS is loaded from a floppy, it's possible that you have the wrong disk in the drive. If so, insert the correct disk and try again (if the program you're using permits). If these files were to be loaded off of your hard disk, then the problem is probably with the ASSIGN.SYS file and the path it sets for GDOS to load such files from.
Every silver lining
…is accompanied by a dark cloud. In this case, the silver lining is the power that GDOS gives (multiple font styles and sizes, resolution-independent images, Metafiles that can be ported from one GDOS application to another). The dark cloud is the many problems with GDOS and its use.
The first and most noticeable problem many GDOS users encounter is that of speed. Because GDOS is a "patch" to the ST's OS, it is pretty much invisible to the user. But just because you can't see it doesn't mean it isn't there and working. The trouble with GDOS is that it often slows the entire system down. Windows don't open quite as fast (particularly in a GDOS application), cursors don't move smoothly. The whole system seems to bog down and act sluggish. It can be a bit of a problem to move—and particularly fine-position—elements when the system acts so clunkily. You move the mouse a bit, but the cursor doesn't budge, so you continue to move it, and blip! The cursor suddenly jumps over—too far.
This problem was the subject of intense discussion, and, on the DELPHI telecommunication system, the target of a heated debate. The word from Atari was first that the GDOS slowdown was a myth, and later that it happened only on some machines. It later became evident that the problem was not with a handful of machines, but with GDOS itself. For a time the slowdown problem was such a common point of discussion that Andy Eddy (associate editor for ST-LOG) bestowed upon GDOS the nickname "G-DOZE," which stuck for quite a while.
Beyond the slowdown problem there are others. GDOS does not seem to like some programs. We're not talking GDOS applications here, but non-GDOS programs. In some cases, if such a program is run while GDOS is in memory, either it will be prone to failures or sometimes won't function properly at all. For example, DC-FORMAT will crash if GDOS is present. Usually, this is the fault of the program being run.
But these problems are dwarfed by the biggest annoyance that GDOS presents; namely, that it can load one and only one ASSIGN.SYS file. This may not seem to be much of a problem, but if you routinely use several GDOS applications, it can become a real migraine. The ASSIGN.SYS file used by Easy Draw is not the same as the one used for DEGAS Elite or for Timeworks Desktop Publisher. Sure, it's possible to create one all-purpose ASSIGN.SYS file containing all the fonts and device drives used by all your GDOS applications, but that file would be large, unwieldy, and not necessarily work as you intended it to.
The real pain here comes because GDOS reads the ASSIGN.SYS file only once, at boot-up. It cannot and does not read it again during a work session. Therefore, if you had multiple (different, and with different names) .SYS files, it would only read one (the one named ASSIGN.SYS), and ignore the rest. If that file was for Easy Draw, it would not help you if you were working with DEGAS Elite. The only way to get GDOS to load a different .SYS file is boot with a disk containing GDOS and a different .SYS file. On a hard drive you would be forced to rename the one you want to use to ASSIGN.SYS (after changing the current one to some other name) and then reboot! Yup. If you want a different ASSIGN.SYS file, you have to reset or restart your ST. This is not a very clever or convenient system. Having to rename .SYS files makes it bothersome.
Some solutions
How can you avoid these problems? Well, you could always just throw GDOS out the window and forget it. But no, that's a bit like curing the bug by erasing the program. There is a solution to just about every problem listed, but it means using a commercial program that serves as a replacement for GDOS. More on that later, right now let's talk about what you can do to alleviate problems for minimal cost.
The GDOS slowdown is caused, primarily, because GDOS runs in a constant loop, and monitors the ST's TRAP #2 vector. I'd better explain this: "TRAP" is the 68000 assembly language term for an interrupt/exception. The ST has 16 TRAPs; #1 is used by and for GEMDOS, #2 the VDI and AES (Virtual Device Interface and Application Environment Services, respectively, discussed in Step 1, January 1989 ST-LOG), and so on.
GDOS monitors TRAP #2, looking for certain VDI calls. The trouble is that the VDI is always active, reporting keyboard activity and mouse movement, amongst other things, so GDOS is watching all of this even though most of it is unimportant to GDOS itself. This slowdown is not all that noticeable if GDOS and a GDOS application are the only things in memory, but if you add any other programs that make use of the TRAP #2 call, that bogs the system down because of the amount of "traffic" going through that interrupt vector. The easiest way to see this slowdown is to load a few desk accessories. These make a lot of AES calls, which use TRAP #2, and thus add to what I call the "TRAP #2 bottleneck."
Why this happens is not just due to the business of TRAP #2, but can be attributed to the way GDOS monitors the TRAP. The code for this is not optimized and takes more time than it should. This is partly because GDOS was written in C and not in assembly language, which would have been faster.
The way around this is not to use accessories unless you really have to. This will ease the amount of VDI and AES calls and allow GDOS to run faster. I don't consider this to be a great solution, but a workable one.
Another solution is to boot with GDOS when and only when you intend to use a GDOS application. If you don't want to use GDOS, you can either boot with a disk that doesn't have it or you can use one of those AUTO-folder-program-selection utilities (which let you choose which programs in an AUTO folder to run), like Desk Manager.
The next problem is that of multiple ASSIGN.SYS files. If you're working with a floppy-based system, the easiest way around this is to keep your GDOS applications on different disks, and on each of those disks place an AUTO folder containing GDOS, and place the ASSIGN.SYS file for that program in the root/main directory of that disk (also be sure to copy the fonts and drivers to that disk as well, and make certain that the ASSIGN.SYS file sets the proper path for them). When you want to use a given GDOS application, you just boot with the appropriate disk, and voila!
If you have a regular boot disk or boot from a hard drive, there is another solution. Both the shareware and commercial versions of Desk Manager, by Charles F. Johnson (not the version originally published in ST-LOG #16), have a feature which allows the user to choose an ASSIGN.SYS file at boot-up. The Desk Manager program runs from the AUTO folder and allows the user to select which AUTO folder programs to run (as mentioned above), what accessories to load, and even choose between multiple ASSIGN.SYS files.
This is done by copying all your different ASSIGN.SYS files to a subfolder in the AUTO folder called DESKMGR and giving them descriptive names with a .SYS extender, like EASYDRAW.SYS or DEGAS.SYS. If a program starting with the letters GDOS is active in the AUTO folder, you will be allowed to select any one of the .SYS files you copied to the Desk Manager folder. When you have made your selection, Desk Manager copies the selected file to the boot disk's root directory and names it ASSIGN.SYS. Then, when GDOS runs, it will find and use the file you selected. In this manner, you can keep several ASSIGN.SYS files on a single disk and never have to manually rename them again.
Shareware versions of Desk Manager are available on all the major on-line services and from some user group libraries. The latest, commercial version is not freely distributable and is one of the many programs on the Code-Head Utilities disk from Code-Head Software.
These two solutions ease the slow down and eliminate the annoying renaming problem, but it does not eliminate the forced rebooting in order to switch ASSIGN.SYS files, nor does it eliminate the malfunctions and crashes some software experiences when GDOS is in RAM.
The best bet yet
If you use a lot of GDOS applications, the biggest favor you can do for yourself and your ST is to shove GDOS into the archives (maybe even flush it down the toilet) and forget it. Of course, you have to replace it with something, and the answer is to buy G+Plus (the "+" is silent; consider it a stylized hyphen), from Code-Head Software (I don't usually like to plug commercial software, but there is simply nothing else out there that can do what this program does.)
G+Plus rectifies just about every one of GDOS's failings while maintaining a compatibility level that is nothing short of miraculous. The slowdown is gone with a vengeance, ASSIGN.SYS files are no longer a hassle, and most of the problems with other programs have been eliminated.
This program will cost you $34.95 (list), but if you use a lot of GDOS applications it's worth every penny of that price.
GDOS errata
It has been said that there has been more myth, mythconception, mythunderstanding and downright mythinformation (sorry) about GDOS than about any other part of the ST or any of its software. A lot of the blame for this falls upon the shoulders of Atari, which took a great deal of time to produce a fairly flawed GDOS, and which hasn't provided developers with the kind of detailed information and guidelines they need.
Then again, many developers have failed to adequately cover the use of GDOS in their manuals, even though GDOS comes with their programs and did not originally come with the ST. In many cases where GDOS is discussed in a product manual, the information presented is inaccurate. I have seen manuals that explain how to set up an ASSIGN.SYS file for a program, and the instructions are wrong!
Here are a few common myths and misconceptions we can shoot down:
Myth: A GDOS application must have GDOS present to run.
Sometimes, but not always. The most common instance of users assuming this is with DEGAS Elite. That program uses GDOS for one thing and one thing only: to load fonts other than the system font. So, if you don't need the extra fonts, you don't need GDOS. Other programs do need GDOS to function. As I mentioned earlier, Easy Draw cannot save a .GEM file if it cannot find the META.SYS driver loaded by GDOS. A little experimenting will show you which GDOS programs you must use GDOS with and for which functions, and which ones you can safely use without GDOS.
Myth: GDOS is a memory hog. GDOS is a fairly puny program, and it does not load fonts and drivers until they are called for. The fact that it must load multiple font files for multiple sizes of a single font style is the one thing that can make it hog memory. And, as stated last issue, GDOS can and does unload fonts, contrary to the prevailing notion which says it can't or doesn't.
Final recommendations
If you use GDOS, let's sum up with the following pointers:
- —Don't install GDOS if you're not going to use a GDOS application. Using a program that allows you to select which AUTO programs to run makes this easy.
- —If you are using GDOS, limiting or eliminating desk accessories can help alleviate the "G-DOZE" slowdown syndrome.
- —Don't make an all-purpose ASSIGN.SYS file for multiple applications. Get a program like Desk Manager so that you can pick and choose .SYS files.
- —If you use a lot of GDOS applications, consider purchasing G+Plus, because it will make your life a lot easier.
And that's all. I hope this article and its predecessor have been useful to those of you who use (and probably have suffered with) GDOS. As always, I've tried to cover the topic as exhaustively as possible and present all the information I think end users can use. But it's possible I might have missed something or even made a mistake So if you have any comments or corrections, please let me know about them, in writing, care of this magazine. Any omissions or errors reported will be mentioned in future columns.
Addenda: In response to the "Of Mice and Megabytes" articles in the November and December '88 issues, I have received a few pieces of written mail and quite a few electronic mail messages from readers who were interested in obtaining one or both of the animated videotapes mentioned in those articles. To everyone interested, I'm sorry, but the answer is no. This is because I am still trying to sell the Balance of Terror game demo, so I cannot release it. And, in regard to the Art & Film Director demo, that tape is distributed by Epyx Inc., which uses it for dealers, distributors and trade shows. If at any time either of these become available, I'll let you know here.