COMPUTE! ISSUE 72 / MAY 1986 / PAGE 95
Hi—welcome to “Insight: ST,” COMPUTE!’s new monthly column for the Atari ST-series computers. Over the coming months, we’re going to help you become more familiar with the ins and outs of the Atari ST, its operating system, GEM, and ST BASIC. The ST series is the most powerful line of computers ever released by Atari—one of the most powerful in the industry, in fact—so there’s a great deal to learn and explore.
Before getting started, I want to reassure those of you who still own and use the eight-bit Atari 400/800, XL, and XE computers. Veteran readers will recognize that I’ve been writing the “Insight: Atari” column on these machines for the past five years in COMPUTE!, This new column does not mean that we’re dropping Insight: Atari. In fact, I plan to continue writing Insight: Atari in addition to Insight: ST for the next few months. Eventually I’ll turn over Insight: ST to someone more specialized in ST BASIC. Don’t be surprised, though, to find occasional ST tidbits in Insight: Atari as well. Both columns will be of continuing interest to all Atari enthusiasts.
Just what is an Atari ST computer? Even if you already own an ST, I may have some surprising answers for you.
From a hardware viewpoint, the ST is most commonly compared to the Apple Macintosh and the Commodore Amiga. Indeed, it shares characteristics with both. All three use a Motorola 68000-series microprocessor, 3½-inch floppy disk drives, bit-mapped screen display, a range of peripheral interfaces, and more—generally the things we’ve come to expect from today’s advanced personal computers. Both the ST and the Amiga have one advantage over the Macintosh: color graphics (though admittedly only the Amiga uses a sophisticated graphics processor chip to display true sprites).
Even the user interfaces of the three machines are similar: All have a system of icons, multiple screen windows, and a mouse controller to visually display and manipulate the contents of disks and perform general “maintenance” chores.
Finally, as long as we’re making comparisons, we should be fair and mention that the Macintosh has much, much more software available for it than either of its competitors. But that situation is changing rapidly, even as I write.
What makes the ST stand out from other computers? Well, the Atari marketing department has a whole series of answers, but let me tell you the ones which impress me. First and foremost is the built-in hard disk port. It’s capable of transferring data to or from a hard disk (or a network or external RAM disk or whatever) at a rate of up to 1,300,000 bytes per second. That means you could, in theory, fill the 512K RAM memory of a 520ST in under half a second.
Theory is nice, but what does this mean in practice? Well, for me (or any other programmer) it means that after writing source code with a text editor, I can save the source file to disk, exit the editor, load a compiler, compile the source code I just saved, link the resulting object code with both system and GEM libraries, and maybe (if I swallow fast) finish eating a bite or two of a sandwich. Elapsed time: between 10 and 15 seconds, depending on the size of the program. On an IBM PC with a hard disk, it would take four to six times as long. And on the Macintosh, most external hard disks aren’t much faster than the ST’s floppies.
Thanks to its fast processor and amazing hard disk speed, for sheer computing power there is probably no “home” computer available which can touch the ST. Exception; If you’re doing heavy work with floating-point math (for example, scientific or engineering computing), an IBM PC with 8087 floating-point chip will win hands down. (Are you listening, Atari?)
The only other hardware features which are distinctively Atari are the built-in MIDI (Musical Instrument Digital Interface) ports, the cartridge slot, and the absolutely beautiful black-and-white display. Now MIDI will be of interest to musicians, and the cartridge port may have some interesting future applications (perhaps a way to get that fast floating-point chip?), but the surprise here is the 640 × 400 monochrome display. Why do I rave about this on a machine with advanced color graphics?
Although I enjoy color displays, I will probably never create one. I’m not particularly artistic and I don’t write games. But I do write programs. Which means I appreciate an easy to read, rock-steady display. Atari went to the trouble to equip the ST with a completely separate monochrome video port, and its quality is nothing short of amazing. And, besides, it costs $200 less than a color system. (But be forewarned: Many games only run on a color monitor. Poor software design, in my opinion, but that’s how it is.)
Next month, we’ll begin turning the Atari ST inside out and exploring the intricacies of TOS, its multilevel operating system.
COMPUTE! ISSUE 73 / JUNE 1986 / PAGE 107
Okay, you’ve got your shiny new ST computer plugged in and running. You can use the mouse to select programs, copy files, and format disks. It’s fun, and it certainly is easier to learn than figuring out what
COPY B:\SYSTEM\MSGS.TXT/A=A:SPCL*.MS?
is supposed to mean, (That’s a real and possible IBM PC command.) But how did this system get built? Glad you asked.
Collectively, the software built into the Atari is called TOS (Tramiel Operating System). When the 520ST was first shipped, TOS was delivered on a disk. If you’re still using the disk-based TOS, stop now. Go out and buy the ROM (Read Only Memory) version of TOS, It should cost no more than $25 or so. Installation is not too difficult, though if you have as many left thumbs as I do, you might be advised to find a dealer or service center to install the chips for you (maybe $20 to $30 extra).
TOS in ROM is actually composed of six separate pieces. Usually, we lump these pieces into two groups of three: the graphics processing section and the underlying operating system. As we shall see, that operating system—a derivative of CP/M-68K—is very similar to MS-DOS and PC-DOS, which are both derivatives of CP/M.
In one sense, we can say that the lowest level of the ST’s operating system is the BIOS (Basic Input/Output System), a holdover from the earliest days of CP/M. At this level, we find routines for such basic tasks as sending a single character to a device, reading a disk sector (by sector number—a very dangerous practice), and so on. In CP/M, there was only one legitimate reason to call the BIOS directly: speed. With TOS, though, only the BIOS provides some of the facilities which even a moderately sophisticated program will need (admittedly, often because of bugs in the upper levels of the operating system).
On the ST, a BIOS call is implemented as a TRAP instruction in 68000 machine language. All the necessary parameters, including the BIOS call number, are passed onto the stack. If you aren’t quite sure what we’re talking about, don’t worry about it. Virtually every programming language for the ST has some way to use these routines which mask the mechanics of TOS calls. It’s a good thing, too, since some of those mechanics can get pretty hairy.
The next higher component of TOS is the XBIOS (extended BIOS). XBIOS supplies the Atari-unique routines needed to do such things as access the sound registers, screen hardware, and so on.
The third component of the operating system is called GEMDOS Graphics Environment Manager/Disk Operating System). Actually, this is a misnomer. The GEMDOS routines have nothing whatsoever to do with graphics. GEMDOS is essentially an MS-DOS or PC-DOS emulator. Want to open a file? Read a block of bytes? Get a character from the keyboard? Given the differences between the 68000 of the ST and the 8088 of the IBM PC, the similarities between GEMDOS calls and MS-DOS calls are almost scary.
Okay, enough about the underlying operating system. Let’s take a look at the graphics systems which comprise GEM, The most familiar part is the GEM desktop which appears when you turn on your ST. But the desktop is not really a special program at all; it simply calls the lower-level routines. Again, there are three levels of graphics routines.
The lowest-level graphics, not officially part of GEM but merely one means of implementing it, are those called the Line-A Routines. This sounds cryptic, but it simply refers to the fact that certain machine instructions of the 68000 (including those of the form $Axxx hex—hence “line-A”) are reserved and cause a special hardware trap into the OS. As you might expect, routines implemented in this fashion are of the most fundamental type: draw a line, plot a point, and so forth. Most are very fast.
The next level up in graphics is the VDI (Virtual Device Interface). In theory, VDI is capable of supporting several types of graphics devices in a uniform fashion. For example, you might use the same set of calls to draw a curve on a plotter or on the screen. Unfortunately, no such drivers are yet available (or, as far as I can tell, even in the works) for the ST. Still, the possibility exists.
VDI does all the actual graphics work on the ST, It draws simple rectangles, bordered ovals, and text in various styles, sizes, and colors. Someone who learns nothing on the ST except how to call VDI could still do some remarkable graphics work.
Finally, at the highest level, is AES (Applications Environment System). AES is what GEM uses to present you with that nice, pretty desktop, complete with menus, dialog boxes, alert boxes, windows, and icons. Perhaps more important to programmers, though, is the fact that AES allows us to use all the features of GEM in a relatively consistent, properly desktop-compatible manner. It is through this mechanism that even a lowly spreadsheet program can have drop-down menus, mouse-controlled windows, and all the rest of those impressive features.
COMPUTE! ISSUE 74 / JULY 1986 / PAGE 108
This month we’re going to explore a handful of quirks in the GEM desktop: things you can do to make your system more useful… things you can do to make your system crash! Since I’m a natural-bom pessimist, let’s start with the crash.
The bug I’m about to demonstrate infests the ROM (Read Only Memory) version of the TOS operating system. Even so, if you don’t already have the TOS ROMs, get them today. The difference in overall system performance and capability is only a little short of great.
To see this bug, simply boot your system and bring up the Control Panel. Select either the date or time field. Then type an underline character (SHIFT-hyphen). Watch your system bomb. The only recovery is to press the reset button or turn off the power.
Problem: The Control Panel is a form of dialog box, and it uses what are known as editable text fields to display and let you modify the date and time. An editable text field is designed to restrict the user to typing certain characters. For example, the date and time fields of the Control Panel are editable fields which allow only numbers to be typed. Unfortunately, somehow a bug crept into the ROM-based TOS. Anytime you edit a numeric-only field, typing the underline causes something nasty to occur. Editable fields for filenames have a similar, though usually nonfatal, problem.
Solution: A GEM application program that needs to accept numeric-only input from the user has two choices: (1) Use an editable field which allows any character and then validate the user’s input after the dialog box returns; (2) Retrieve keystrokes one at a time, checking them on the fly, and print only the valid ones on the screen. The former solution is kind of ugly because the user doesn’t get immediate response to incorrect input. The latter solution is a lot of work. Take your pick.
Many of you already know how to customize the GEM desktop so your preferences appear automatically when you boot up the ST. When you select the Save Desktop item under the Options menu, GEM saves a file to the disk in drive A called DESKTOP.INF which stores these preferences. You can rearrange the icons on the screen, change screen colors, resize the windows, and so on, and GEM remembers it all for you.
DESKTOP.INF is an ordinary ASCII file, so it can be modified with most text editors and word processors. This lets you personalize GEM even more. (See “ST Hints & Tips,” COMPUTE!, June 1986.)
The first thing we’ll do is the easiest. Using a text editor or word processor that handles ASCII files, load and examine DESKTOP.INF. You should see one or two lines which contain the words FLOPPY DISK (among other things). These are the labels which appear beneath the disk icons. I usually rename the labels —Top—Disk— and Bottom—Disk. (I’ve used dashes here to show where I typed a space—magazine typesetting sometimes makes it hard to indicate spaces.)
Save the modified file back on disk in ASCII format. The next time you boot from that disk, the names should appear as you have modified them. Just for fun, sometimes I change the name of the trash can to Junk! or Garbage or something equally silly.
There are even more interesting things you can do with DESKTOP.INF. If, like me, you have a disk or subdirectory in which you do most of your work, you’ll soon find that you can’t see all of the filenames or icons on the screen at once. Although it’s a minor nuisance, it always seems that the files (or, more likely, programs) which I want the most are always off the screen. How can we force them back on the screen? Preferably in the upper-left position?
One solution, since the default display mode under the Show menu is Sort by Name, is to name your favorite files AARDVARK.PRG or AAABASIC.PRG, But that’s kind of messy. A better method might be to choose Sort by Date if you could change the file’s creation date. But I think Mark Rose (of Optimized Systems Software) has hit upon the best scheme.
First, he chooses Sort by Type. Second, he renames his most-used programs so they have no type (filename extension) at all. Third, he loads DESKTOP.INF and adds a line or so. To figure out exactly what to add, look for a line in DESKTOP.INF similar to this:
#G 03 FF *.PRG@ @
This line tells the desktop that all files which match the *.PRG specifier are GEM (G) program files. Now, let’s say the program you want to appear at the top-left of the screen was called PASCAL.PRG and has been renamed to simply PASCAL. You would add this line to the end of the DESKTOP.INF file;
#G 03 FF PASCAL.@ @
This tells GEM that PASCAL is actually a GEM-based program. Neat, huh? What’s more, you can do this for several files. However, I do not recommend using the *. wildcard in such a line—general untyped files end up looking like programs, a dangerous practice.
COMPUTE! ISSUE 75 / AUGUST 1986 / PAGE 110
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.
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.
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.