INSIGHT: ST

Bill Wilkinson

GEM Quirks

The Atari ST is a computer with excellent hardware, but all too often problems with its system software obscure this excellence. Admittedly, most users will never actually see these problems, since software developers work hard to circumvent them. Luckily, application programmers can make a real contribution to the users' perceptions of a machine.

For example, consider the ST's floppy disk drives. In theory they are among the fastest available for any microcomputer. And indeed, when you load a program, the speed is impressive. However, when a program starts performing file input/output using ordinary record sizes, there is so much operating system overhead to overcome that the ST performance is only fair. Creating a new file with 512-byte records is only a little more than twice as fast on an ST as it is on an Atari 400/800, XL, or XE.

Possible solution: The application program can read and write very large blocks to the disk (for example, 4K or bigger), performing the file buffering itself. Suddenly the performance is quite good again. This requires a little more work on the part of the application programmer, but the net effect is pleasing for the user.

Similarly, using a hard disk on the ST is an experience not to be forgotten. For example, compiling an average-length program with Personal Pascal usually takes one to two minutes using floppies. When using a hard disk, those times improve to 10 or 15 seconds. That's because the hard disk port on the ST is capable of transferring more than one megabyte per second.

But something happens as the hard disk starts filling up. Access times can double before the disk is even half full, Again, there's a solution: Partition the 20-megabyte disk into four smaller, five-megabyte "logical" drives. And, since the ST uses subdirectories so successfully, this is usually a practical solution.

Gullible GEM

Perhaps the biggest problem with GEM (the Graphics Environment Manager) is that it is too gullible— tell it a lie and it believes you. Consider what happens on an Atari 400/800, XL, or XE when an Atari BASIC programmer uses a PRINT statement to display a message which is wider than the screen: The text wraps around to the next line.

When programming with GEM, the easiest way to display something on the screen is via an alert box. This is the small window which pops up to report errors and so forth. To display an alert box, a programmer simply defines a string of the proper form and makes an easy call to a GEM routine. But if the programmer errs when defining that string (for example, by entering too many characters or leaving out some special characters), crash! Time to hit the old reset button.

Now, granted, the proper form of that string is easy to validate before calling GEM, so a well-written application program will never reveal this particular problem to its user. However, this is symptomatic of much of GEM. Application programmers must do a lot of work to insure that GEM is given only legal values to work with. GEM does not seem to follow the GIGO rule (Garbage In, Garbage Out); with GEM it is more like GIC (Garbage In, Crash!). So be careful if you're writing programs on the ST. Avoid crashes by double-checking all data before calling GEM routines.

The Software Explosion

To a beginner, the ST with its GEM operating system looks complex. And, truly, there is a lot to learn before you can write programs which show off all the capabilities of the ST. But, despite my comments above, experienced programmers find that GEM does so much of the work for them that they can develop fairly complex programs relatively quickly. Too, the capabilities and accessibility of higher-level languages for the ST (such as C, Pascal, and Modula-2) have made programmers more productive. As a result, there is arguably more software available for the ST, at this point in its life, than for any previous computer at a comparable point in its life.

For instance, one year after the Macintosh was introduced, it had far fewer programs available than the ST has about one year after its introduction. Not only that, the ST programs tend to be considerably less expensive than their Macintosh counterparts.

One of the reasons so much software is appearing is that the cost of developing for an ST is relatively low. A part-time ST programmer can have a full-blown ST development system for not much over $2,000 (including hard disk, printer, color and monochrome monitors, development software, and so forth). In the early days of the Mac, $10,000 was more the order of the day, so development tended to be restricted to established software companies.

The flip side of this coin is that the quantity of high-quality software for the ST is certainly not greater than what was available for the Macintosh. Since most early Mac developers were major software companies, their quality standards were generally higher than that of part-time hackers.

Bottom line: Try to see a demo of any ST software you are planning to purchase. There are a lot of excellent ST programs, but there are also some turkeys.