START PICKS PACKAGES FOR DEVELOPERS
by Christopher F. Chabris
Looking for an alternative to the $300 Atari Developer's Toolkit? You say you want to do some programming but don't have 200 bucks to blow on C? Have we got a deal for you! Christopher Chabris takes a close look at the ST operating system, then rounds up all the tools you'll need to develop ST programs-at bargain basement rates.
Many
ST owners, eager to develop software with the growing number of structured,
high-level languages, are dismayed by the high cost of Atari's development
kit, or that of the other "professional" packages, such as Megamax C. But
affordable software development tools do exist.
I looked over the field and discovered four powerful compiler languages that sell for less than $100, as well as free or inexpensive debuggers, RAM-disks, print spoolers, and other tools you may need in your development effort.
Note that I said "compiler", a language that translates your programs directly into machine language or some similarly compact code before execution. We will cover the following compilers:
- GST-C, v. 1.02, GST Holdings Limited
- Personal Pascal, v 1.02, Optimized Systems Software
- Modula-2/ST, v. 2.00B, TDI Software Inc.
- Softworks BASIC, v. 1.2C, Softworks Limited
THE 16-BIT TREND
The Atari ST computers exemplify some fundamental trends underlying the evolution of personal computers from glorified game machines into truly useful productivity workstations.
The most obvious trend, the window/icon/mouse interface, was made famous with the Apple Macintosh and affordable with the Atari ST. It is now the defacto standard for new microcomputers. Manufacturers from IBM to Sun Microsystems offer graphics-based interfaces for their systems.
Operating systems are undergoing a similar transformation. Early microcomputers had tiny control programs that did little more than print characters to the screen, read and write disk sectors, and service interrupts. The sophisticated, minicomputer-like operating systems of the ST and its competitors provide not only the traditional services but also memory management, graphics primitives, and, of course, user interaction facilities. The next direction, towards true multitasking environments, is already evident on the ST in background desk accessories like Thunder! and alternative operating systems like the MT C-Shell.
A third trend is the growing use of high-level, block-structured programming languages, and the corresponding movement away from assembly language and BASIC, formerly the languages of choice and necessity for microcomputer programming. Most commercial ST software today is written in the C programming language.
ANATOMY OF THE ST
The Atari ST is a general purpose personal computer built around the Motorola MC68000 16/32-bit central processing unit, supported by both off-the-shelf and proprietary chips. The ST's operating system, TOS, consists of several distinct modules that call on each other to perform system housekeeping and user services:
program must
actually execute an
unimplemented
instruction to
call the routine!
1. BIOS: Basic Input/Output System. The ST BIOS provides low-level system services such as character I/O with the keyboard, screen, and peripheral ports.
2. XBIOS: Extended BIOS. The XBIOS provides services similar to those of the BIOS, but oriented towards ST-specific hardware functions such as MIDI-port I/O, disk controller commands, disk sector I/O, and the like. It also includes miscellaneous functions such as system clock maintenance and switching the processor in and out of supervisor mode.
3. GEMDOS: GEM Disk Operating System, a relatively machine-independent DOS designed by Digital Research Inc. (DRI) to be quite similar to MS-DOS as used on the IBM PC and compatible computers. GEMDOS provides high-level access to the disk file system (opening and closing files, creating and removing subdirectories, etc.) as well as other features not tied exclusively to the ST hardware.
4. Line-A: The lowest level of graphics capability available on the ST short of storing bits directly into screen memory (not a good idea if you want your programs to be compatible with future ST models). Line-A is the underlying set of graphic functions that GEM itself uses to draw on the screen. Reportedly, Line-A routines will access the long-awaited "blitter" chip so that all properly-written software will run without modification or recompilation by the vendor.
5. VDI: Virtual Device Interface, one of the two main parts of GEM, the Graphics Environment Manager, which was also designed by DRI. VDI, in concept, is intended to provide a set of device-independent graphics functions that an application can use for all of its output regardless of the device on which that output will eventually appear. The idea is that the user can choose whatever output device(s) he wants to use, such as the screen, a printer, or even a camera, and simply direct the program's output to it. Supposedly, the software developer who plays by DRI's (and Atari's) rules need not be concerned with the details of driving all possible devices; the VDI will take care of it. A powerful idea indeed, but as we shall see, it's not yet a reality on the ST.
6. GDOS: Graphics Device Operating System, the silent partner of the VDI. The GDOS is the portion of GEM that does the hard work behind all the device-independent output magic that the VDI takes credit for-and it is missing from your ST ROM. Why? For one thing, there is not enough room. For another, well, DRI and Atari have been a little slow on this one. GDOS has been a part of the MS-DOS, IBM PC version of GEM since day one, and Atari has been promising it to developers for months, but as of September 1986, only Migraph had obtained it for their Easy-Draw package, and Tom Hudson was using it for DEGAS Elite. As implemented on the ST, GDOS is booted from an AUTO folder as a Terminate-and-Stay-Resident program. GDOS is to come with a set of standard fonts and output device drivers that may be augmented in the future. For more on the subject, read "Tracking the Elusive GDOS: Those Missing Metafiles" in START, Vol.1, #1, Summer 1986.
7. AES: Application Environment Services, the second main part of GEM, consists of routines for user-interface functions such as drop-down menus, windows, dialog boxes, and the like. AES also coordinates the limited multitasking available to desk accessories. The AES will manage up to six desk accessories. Strictly speaking, desk accessories are independent programs and not part of TOS.
Several items are most certainly not in TOS. The GEM Desktop, though stored in ROM along with TOS, is really nothing more than a GEM application. In addition, TOS has no command-line interface (like MS-DOS), although several are sold as normal ST applications. Also, the only support for arithmetic is that provided by the 68000 instruction set, i.e., the ST has no floating-point math package built into it like the Atari 8-bit OS. And lastly, there is no support for full multitasking. As alternatives to TOS, both OS-9 and the MT C-Shell provide for multitasking several programs (or users).
PROGRAMMING THE ST
There are two fundamental ways of programming the ST: You may create a full-blown GEM application with drop-down menus, multiple output windows, and all the trappings; or a simpler program that ignores GEM VDI and AES, relying instead on the BIOS, XBIOS, and GEMDOS routines for all user interaction. The former type, known as a GEM Application, is generally encouraged, especially for commercial products. The latter, referred to as a TOS Application, is recognizable by its lack of windows and mouse and, as often as not, its blinking cursor. A TOS application is often preferable when speed is of primary importance and ease-of-use is a secondary goal. Some confusion exists over the terms TOS and GEM as applied to applications. Although TOS is a label for the whole ST operating system (including AES and VDI), a TOS application uses only part of the available system (omitting AES and VDI). The TOS application label came about because most TOS applications use a TOS extender which the OS recognizes as a non-GEM program. This confusion is unfortunate, but we're stuck with it. So when you see further on in this article that a language includes "GEM routines," I mean that it contains all the routines in the TOS operating system, ranging from BIOS to AES.
Applications well-suited to GEM might include word processors, graphics programs, and spreadsheets. The classic, text-based form might be more appropriate for a database management system, a programming language, or a short utility program. In general though, any application can benefit from GEM's features if its programmer is creative enough to use them well.
Desk accessories, by definition, rely on GEM and are only available from within GEM-based programs that implement the Desk menu. Videogames on the ST are seldom GEM programs and often rely exclusively on the Line-A interface to obtain the optimal combination of speed and portability. They are normally written in assembly language (again for speed), so we will not cover the techniques for programming them here. To those interested, I recommend one of the assemblers reviewed in "ST Assemblers: A START Comparison" (START, Vol. 1, #1, Summer 1986) and a reference to the Line-A routines, such as Atari ST Internals from Abacus Software.
THE DEVELOPMENT PROCESS
The software development process on the ST consists of an edit-compile-link (crash)-debug cycle that continues indefinitely until you, the programmer, are satisfied with its results. The flow chart in Figure 1 illustrates this process and adds some details. This basic cycle applies, with minor variation, to all four products we will consider. Considerations of procedure, however, are not as important as GEM support and quality of documentation.
Again, we are considering high-level languages only. Most ST developers prefer high-level languages and use assembly language only for optimizing time-critical routines. C is the language of choice, with Pascal and Modula-2 gaining in popularity. And a compiled BASIC can help old 8-bit hands make the transition to the ST in style.
INTERFACING WITH TOS
A few words are in order about the method ST software uses to interface itself with TOS, that is, how a user program actually calls the routines that are built into ROM (or loaded with the GDOS patch). The 68000 processor has an instruction called TRAP, which causes a sort of interrupt in the system. There are sixteen different traps, each with its own service routine that is automatically invoked by the 68000 when the appropriate trap is used. On the ST, most of the traps are unused by TOS, except for these:
#01: GEMDOS routines
#02: GEM routines (both VDI and AES)
#13: BIOS routines
#14: XBIOS routines
The other 12 traps are available for future expansion. Normally, the parameters to GEMDOS, BIOS, and XBIOS routines are passed on the stack and an error code returned in 68000 register D0. However, as usual, there can be exceptions. TRAP #02 is used differently: all the necessary parameters to the GEM routines are placed in various pre-allocated system global arrays; GEM determines from this data which function is desired and what its parameters are. To further complicate things, the Line-A breaks just about every rule. As with the VDI, you must fill up a parameter array before making the call. Here, however, your program must actually execute an unimplemented instruction to call the routine! Sometimes I feel that the secret objective of the TOS designers was to make life difficult for poor assembly-language programmers!
Fortunately, if you're willing to forego access to Line-A, you can remain entirely within the bounds of your chosen language and forget about all the messy details. All four language packages discussed here come with easy-to-use methods for calling GEM routines. Each compiler presents libraries of short machine language routines called "bindings." These routines set up the parameters in the proper locations and execute the appropriate trap instruction. When you link your object code, these bindings are extracted from their libraries and added into your final output program, just as functions from a floating-point library would be inserted if your code called them. Therefore, you can make whatever GEM calls you want in the same language as the rest of your code. For example, Figure 2 shows a call to XBIOS function 19-Verify Disk Sector-coded in both C and assembly language (from Atari ST Internals, page 181).
GST-C
First we will examine GST-C, an inexpensive C language compiler from
the company that brought us 1ST Word. GST-C includes the compiler, a linker
(GST-Link), an assembler (GST-ASM), and a superb text editor (GST-Edit),
plus various libraries to provide access to GEM routines. An executive
program, or "shell," similar to the GEM Desktop, controls the system. It
lets the programmer invoke the various components using drop-down menu
selections. A log window keeps a record of all the commands issued during
the development session. Overall, the package is thoughtfully designed
and complemented by a well-written user manual. (For an in-depth evaluation
of GST-C, see "Which C for Me?", START, Vol. 1, #2, Fall 1986.)
| FIGURE 2 | In C:
err=flopover(buffer,filler,dev,sector,side,count), In Assembly Language:
|
A demonstration program written in GST-C appears on a separate disk included in the package. Called Fractal Factory, it is a full-fledged GEM application, complete with windows, menus, and mouse control. Besides being fun to play with, it can also be instructive if you buy the complete source code- sold separately for $19.95. While I found the source code interesting, I would have learned much more from it had it included more documentation than the in-line commentary. The Fractal Factory disk also contains a library that is completely undocumented. This is especially disappointing considering that it may implement some techniques for getting around the lack of floating-point arithmetic in GST-C.
That's right, GST-C has no floating-point capability. Nor does it support multidimensional arrays or structures. In short, three serious deficiencies that might restrict your development efforts, since several GEM routines (which are written in C themselves) take structures as input parameters. A brief document on one of the disks explains how you can sometimes circumvent the structure problem with arrays, but no official solutions to the other two problems will be offered earlier than the release of a new version of GST-C. Version 2.00 is currently scheduled to be available in early 1987. Do you want to wait?
Despite its shortcomings GST-C is a viable development system for many applications; witness the fact that GST used it to develop 1ST Word, an application that can hardly be called simple. The programmer who works in GST-C benefits from the popularity of C as a language; far more sample C code exists in the public domain than for any other ST language, including ST BASIC. This also means that if you choose GST-C, you should be able to easily find help from other C programmers.
The real bonus you get with GST-C is its unique "GEM superstructure library" that provides a layer of functions above even the AES to make life easier for programmers who want to use standard GEM graphics windows and text. With nothing special, a program can cause its ordinary standard text output to appear in a complete GEM window that can be moved, resized, closed, etc. The library also takes care of redrawing windows when necessary. It does not provide any assistance with menus or dialog boxes, but it simplifies GEM window management for the uninitiated.
With a comprehensive set of libraries, GST-C offers a high level of access to GEM routines. It is deficient in just a couple of areas: GEMDOS, for which several bindings are absent, and Line-A, for which no support is provided. While the latter is excusable on the grounds that no high-level ST language provides Line-A bindings, the former is not. The UNIX library is also not as good as it could be. Perhaps the libraries can be improved by an update before the new version comes out. In any case, the superstructure library is always there to keep you happy while you wait.
GST-C comes with an excellent manual, which describes the use of the shell program to edit, compile, and assemble programs. Unfortunately, the linker documentation is obscure and will be difficult for beginners to understand. An appendix documents the compiler's code generation sufficiently to interface assembly language routines. A quick reference to all the standard libraries is included, as well as brief descriptions of each individual routine. However, no examples are provided in the manual and only one is included on the disks. Despite its ease of use, even the GEM superstructure library could use an example or two. And needless to say, you will need separate documentation for GEM if you intend to go beyond it.
I like the GST-C package, and you should find it adequate for most development needs. It features ease of use, the superstructure library, and the C language itself. The optional Fractal Factory source code may help experienced C programmers having a little trouble with GEM, but others will find the documentation insufficient.
PERSONAL PASCAL
I reviewed OSS's Personal Pascal in Antic Magazine, Vol. 5, #1, May 1986. Personal Pascal is an extremely clean, well-integrated development system that tops even GST-C in ease of use. From a central "Manager" program, the programmer uses menu selections to invoke the editor (a simple but adequate text-only application that is the weakest link in the product), compiler, linker, and final output program. There is no need for linker control files or complicated option settings; two simple dialog boxes give you control over code generation, libraries, etc.
With the unique PASGEM library of routines supplied with the compiler, OSS has chosen to provide simplified access to GEM routines at the expense of compatibility with outside documentation, which usually follows the C standard. While most of GEM is available through the PASGEM routines, many calls were left out. However, the excellent user's manual fully documents PASGEM by providing not only descriptions of the function of each routine but also examples and discussions of GEM program design.
If you choose Personal Pascal, you can benefit from the experiences of many ST programmers who were befuddled by C and irritated by BASIC. They learned the art of GEM with Personal Pascal and produced scores of high-quality public-domain programs that are usually available with source code. Their efforts include several terminal emulators, a "word processor" desk accessory, a multi-window file browser, an intriguing navigation program, and several graphics utilities. Many are available on CompuServe and from user's groups. I would rate the availability of source examples for Personal Pascal second only to C, but better than BASIC, assembler, and everything else.
OSS's quality after-purchase support for Personal Pascal has so far produced a slew of example programs, documentation enhancements, and tutorial articles available on the OSS BBS (telephone number in List of Manufacturers). Among them have been patch programs to fix hugs, manual errata, information on creating desk accessories and making BIOS/XBIOS/GEMDOS calls, and more. However, I must second OSS's recommendation that serious programmers obtain ST technical documentation to supplement the user's manual.
Although the product was first shipped in January of 1986, it has not yet been updated aside from a few minor bug fixes. OSS is planning a major upgrade for late 1986 or early 1987, but is being tight-lipped about the details. Likely improvements would include a GEM-based editor, support of Level One of the ISO Pascal Standard, the ability to include inline assembly-language code, and expanded access to GEM routines. A source-level translator for Turbo Pascal code would also he a welcome addition.
I think Personal Pascal is the best choice for beginners who are learning their first structured language. C and Modula-2, although more powerful, are more advanced and harder to learn. Beginners will also appreciate what OSS has done to simplify GEM. By fully implementing the standard Pascal language, Personal Pascal provides compatibility with most "generic Pascal" books, and by sticking close to Turbo Pascal, the emerging microcomputer standard, Personal Pascal provides an easy way to port programs into the GEM environment. Overall, Personal Pascal is the cleanest, the smoothest, and the most fun to use of the development systems covered here.
MODULA-2/ST
Although TDI's Modula-2/ST has also been reviewed in Antic (Vol. 5, #1, May 1986), it has changed significantly since then. An evolving product, Modula-2/ST has recently been revised to version 2.00B and split into two packages, a "regular" version and a "developer's" version. The latter is the same package as the former except for the addition of a toolkit disk of source code and utilities-including a post-mortem symbolic debugger and the Resource Construction Program supplied with Megamax C. At $149.95, the developer's version of Modula-2 leaves the realm of shoestring development, but the addition of both a debugger and a Resource Construction Program make it a more complete developer's package at a lower price than any other available combination.
Modula-2 was designed by Professor Niklaus Wirth, the creator of Pascal, to succeed Pascal and become the language of choice for both applications and system programming. It offers several advantages over Pascal, including increased support for modular programming, support for multitasking within programs, high-level support for low-level machine operations, and a highly elegant and standardized set of libraries to allow for easy porting of applications between operating systems and machines.
On the ST, Modula-2/ST achieves those goals well by providing a host of features and modules that offer all the abilities of Modula-2 and GEM in an easy-to-use system. The entire set of GEM calls is available to Modula-2 programmers, as are the capabilities to directly manipulate memory locations like the low-memory TOS globals. In the developer's version, TDI has included RAMdisk and print spooler source code that demonstrates the suitability of Modula-2/ST to such low-level programming projects. I would recommend it over the other three packages if your interests lie there. With the CODE directive, you can even make Line-A calls by including machine language code in the compiler's output (not assembly language-you must hand assemble, a formidable task in 68000).
developer's version
of Modula-2/ST leaves
the realm of shoe-
string developement.
I prefer the Modula-2 language and TDI's implementation of it over both C and Pascal for all types of software development on the ST. However, Modula2/ST's user interface leaves a lot to be desired. There are two basic ways of using the compiler: either from the GEM Desktop or from within the M2DESK Modula-2 Desktop program. Since it is cumbersome to constantly have to go through the GEM Desktop and File Selector dialog box, most users will choose the Modula-2 Desktop. This clever program presents the main aspects of the system-editor, compiler, and linker-as icons on the left side of the screen.
Modula-2/ST is a great idea that is flawed in its execution. The Modula-2 Desktop only displays modules in one directory path, making it cumbersome for those using multiple folders or drives. Additionally, the compiler and linker options, such as search paths and code generation flags, are set by a desk accessory that is cumbersome to use and should be integrated into the Desktop. Also, the text editor violates some basic GEM conventions, making its use non-intuitive and awkward. Altogether, the system needs work to become as easy to use as either GST-C or Personal Pascal.
The manual makes a valiant effort to document the enormous Modula-2/ST system, and most of the time it succeeds. Unfortunately, its 370 pages lack an index and do not completely document GEM. Since the regular version makes no attempt to go beyond the standard GEM calls, you will need other sources of information. My reaction to Modula-2/ST is mixed: it has enormous potential to become the premier development system for the ST, since it provides all the tools of Atari's kit at half the price. I really like the Modula-2 language and TDI's implementation of it, which is documented well. Unfortunately, I find the system crippled because it's difficult to use.
SOFTWORKS BASIC
Softworks' ST version of their BASIC compiler appears to have been ported over from the Macintosh, but the necessary ST-specific enhancements have been made to both the software and the documentation. My personal feeling is that compiled BASIC is like interpreted Pascal: a kludgy solution to a problem that could be more cleanly solved by switching languages. Softworks clearly disagrees and has supported their side of the issue well with a good, but not great, BASIC compiler.
Softworks BASIC, as a language, is quite different from ST BASIC: line numbers are optional, Pascal-like record variables are supported, and the commands to access GEM routines look less like mystical incantations and more like their C or Modula-2 equivalents. The language is well-suited to business applications development, with extensive support for both sequential and random access disk file input/output. PRINT USING is supported, as well as many routines for low-level system access, such as VARPTR, TIME, and BYTE-MOVE. Via the familiar ON ERROR GOTO statement, errors may be trapped and dealt with by the program before the user sees them.
The manual solidly describes the language but will be tough sledding for beginners. While it advises readers to examine the plentiful sample programs provided on disk, it recommends no books or other references. Since Softworks' dialect of BASIC is unique, you may have trouble picking it up unless you have used TrueBASIC or one of the BASIC implementations on the Macintosh (especially Softworks).
I was pleased to find an appendix entitled "Toolbox Calls for the Atari" that listed all the GEM routines accessible from BASIC programs. The list includes all the BIOS, XBIOS, GEMDOS, VDI, and AES services I could think of, mostly named by the conventions in Atari's documentation. Interestingly, all GEM routines are called with the same BASIC statement, TOOLBOX (an artifact of the Macintosh version terminology), regardless of which trap is used to call them or what they do.
debugger lets you
unravel the tree of
procedure calls that
led to the crash.
Figure 3 shows the code a program would use to call on the AES's "wait for multiple events" routine. Since the Soft-works Compiler uses the standard parameter names, you will be able to use outside documentation of GEM. Such references will be necessary because Softworks' explanation of the GEM calls is limited to terse descriptions.
Interfacing machine language routines with Softworks BASIC programs,
either assembled or compiled from other languages, is a fairly easy task.
It supports the XCALL command, which executes machine language routines
with arbitrary arguments.
| TOOLBOX | EvntMulti,flags,bclicks,bmask,bstate,m1flags,m1x,
m1y,m1width,m1length,m2flags,m2x,m2y,m2width, m2height,mgpbuff,tlocount,thicount,mox,moy,mobutton, mokstate,kreturn,breturn,mwhich |
I found working with Softworks BASIC extremely easy. There are no libraries, linker control files, or anything else to confuse you. Just run the compiler program, type in the name of the source file, and watch it go. However, you pay a price by having to run your compiled programs under a special run-time system. This is a simple process, but many programmers may want to produce completely independent, runnable applications for distribution.
If that is your intention, the Softworks licensing agreement requires that you pay an additional, one-time $25.00 fee for the right to distribute unlimited copies of the BRUN.PRG runtime system along with your program. (Editors note: Softworks President, Bob Salita, informed us of his intention to make a version of BRUN.PRG available for download on CompuServe and other bulletin boards so that hobbyists could upload compiled programs without worrying about the $25.00 licensing fee.)
If you want to stick with the BASIC language (admittedly, this is a quite modern dialect of it), Softworks BASIC may be for you. It offers full GEM access and many powerful commands to make development easy. Strangely enough, though, a text editor is not included on the disk. You will have to use 1ST Word, or some other text editor.
DEBUGGING
Of these four language compilers, only the developer's version of TDI's Modula2/ST offers a debugger (And that will set you back and extra $70 over the other packages.) But a debugger can be perhaps the most essential tool after the compiler itself!
The TDI debugger, specifically geared to Modula-2 programs, is called a "postmortem" debugger because it takes over after the system has crashed. At that point, it analyzes a dump of the ST's memory as it was before the run-time error, and lets you unravel the tree of procedure calls that led to the crash.
But how can you debug your GST-C, Personal Pascal, or Softworks BASIC programs? As of September 1986, I was aware of only three debuggers for the ST: SID68 supplied by Atari in the Developer's Kit, MonST included by HiSoft in their DevPac ST assembler, and KISSED from MichTron, the prolific ST software publisher KISSED is the only separately available ST debugger.
KISSED is a tiny, 13K program that will be unobtrusive in your ST's memory. Unlike the TDI debugger, KISSED executes in tandem with the program you want to debug. First you run KISSED, then use a KISSED command to load your program. At this point you can disassemble the code, set breakpoints, trace execution, examine and modify memory, and perform a host of other useful debugging operations. You can switch back and forth between the KISSED window and your program's display screen.
In short, KISSED is excellent for debugging assembly language programs like videogames, and for doing things like memory dumps and searches (great for finding strings). But how useful is it for debugging programs compiled from high-level languages? I found it difficult to get used to debugging high-level code from the machine language. KISSED will disassemble your program into assembly language, but you won't see any of the procedure or variable names you used in the source code; that is, it is not a symbolic debugger. Even so, with practice it is possible to become proficient at using such a tool. Nerves of steel may be necessary, but it is possible.
GST-C would be the easiest language to use with KISSED, as it compiles to assembly language source code, which is then assembled by the included GSTASM program. Additionally, the GST documentation provides extensive information on register usage and the form of the machine code generated by the compiler. Armed with the assembly language code and the documentation, you should he able to track down some bugs. It's not the ideal, but it's as close as you'll get. Modula-2/ST also offers excellent information on code generation, but since you never see any intermediate source code, you only have your original Modula source to refer to while debugging. Personal Pascal gives even less of the necessary information. And Softworks BASIC offers none whatsoever; in fact, the manual doesn't even say whether a program is compiled into pure machine language or some intermediate code which is then interpreted by the runtime system. Talk about secretive!
that GST used their C
to develop 1 ST Word.
The ST development community desperately needs a standard source-level debugger that can be customized to fit a variety of language compilers. Perhaps Jim Dunion's forthcoming STDDT will fill the bill. Until then, ST programmers will have to debug courageously with primitive tools. One book that helped me is "How to Write Macintosh Software" by Scott Knaster of Apple Computer (no kidding!). It has an extensive discussion of debugging high-level languages. Since the Macintosh also uses the 68000 processor, many of Knaster's suggestions and practical hints apply to the ST. You should also read the articles "Voodoo Computing: The Pragmatic Art of Defensive Programming" by David Small, and "Of Diagnostics and Debugging: Procedures for the 68000" by Jim Dunion, both of which appeared in START, Vol. 1, #1, Summer 1986.
OTHER TOOLS
The ST programmer's toolbox isn't complete with just a compiler inside. Many utilities are available, both commercially and in the public domain.
- RAMdisks are programs that reserve a part of your ST's memory for use as a simulated disk drive. Such a disk is extremely fast, since no moving parts are involved, but also extremely volatile, since no permanent medium receives the data. In software development, RAMdisks are best used as temporary storage areas for intermediate files produced by compilers, such as the assembly language code output by GST-C. You may also want to put copies of frequently run programs on the RAMdisk for faster access. Several RAMdisks are available in the public domain, many are sold (including A-RAM from The Catalog and M-DISK from MichTron), and a few are provided as bonuses with memory upgrade installations. Any of these "poor man's hard disks" will increase your efficiency as long as you are careful to keep backups of all your important files, especially your source code!
- Print Spoolers are small programs that reside in memory at all times. Often packaged as desk accessories, they send a file to the printer while the computer works on something else. RAMdisks and print spoolers are plentiful in both the public and commercial domains. MichTron offers Soft Spool and, of course, the developer's version of Modula- 2/ST includes full source code to both a RAMdisk and a print spooler (You must compile them yourself.)
- Text Fditors are used to edit text. Surprised? The real surprise is the paucity of good text editors available for the ST. The fact is that only GSTC comes with what I would call a good editor (it's actually a modified version of 1ST WORD). The only other good editor. I have seen is the public-domain Micro EMACS, a microcomputer implementation of the popular minicomputer EMACS editor Check out the many versions of it that are floating around and choose the one that suits you best.
- Command-Line Interfaces are programs that implement a "shell" through which you can give GEMDOS commands in a manner similar to MS-DOS. Many experienced users find the GEM Desktop cumbersome and prefer to type commands directly from the keyboard. Usually shell programs offer more functionality than the Desktop, such as wildcard copying and batch processing. Batch processing is especially useful for developers, who can create "script" files containing all the necessary commands to compile and link programs using their development system. (Atari provides a special batch file processor with the developer's kit.) While there are a few public-domain shell programs, the best are commercial. MichTron's DOS SHELL emulates MS-DOS, and MICRO C-Shell from Beckemeyer Development Tools emulates the Berkeley UNIX C-Shell. Beckemeyer also sells MICRO C-Tools, a set of assorted development tools.
- Make Utilities are programs patterned after the famous UNIX "make" command, which essentially constructs an executable copy of the program you're developing by automatically assembling, compiling, and linking just those files that have changed since the last time the program was built. There are a few make versions in the public domain, and Beckemeyer sells its MICRO-Make. However, I think the language packages reviewed here are simple enough to use that a make utility is not required.
- Resource Editors are programs for creating the "resources" used by a GEM program. Resource files describe the familiar objects you see on the screen, such as drop-down menus, dialog boxes, and the like. While they can be constructed with various AES routines, resources are far easier to define when you can use the mouse to draw them on the screen. A program like Atari's Resource Construction Set (supplied with the Developer's Kit) or the Megamax Resource Construction Program (supplied with the developer's version of Modula-2/ST) will do just that. As of this writing, there were no resource editors in the public domain. A resource editor is primarily a convenience, since there is nothing you cannot do if you don't have one.
All four languages reviewed here allow access to most, if not all, of the GEM routines. But, in my opinion, none provide enough information to properly program with those routines. Fortunately, there are now several books in print that do cover the ST in the same depth as Atari's Developer's Kit documentation. Briefly, they are:
- Programmer's Guide to GEM (SYBEX, 504 pages) is the best book available on all aspects of the GEM system. It covers both the IBM and ST versions by noting the places where the latter differs from the former It includes numerous examples in C, all tested on an ST Among them is a revised "DEMO" program- a complete GEM application for doodling. Obviously, this book will be most useful to GSTC programmers. However, since Modula-2/ST and Softworks BASIC generally follow the C conventions in their GEM libraries, it should be useful for those languages as well. Personal Pascal users may feel that they already have enough GEM documentation in their manual, but they will be able to benefit from the SYBEX book when they start to use the advanced GEM features not covered in the PASGEM library. By the way, since this book pretends GDOS is a part of ST GEM, you will have to wait for its arrival to run some of the examples. The authors say they tested everything on an ST, so they must have used a prerelease version of GDOS.
- Atari ST internals (Abacus, 446 pages) is currently the definitive third-party guide to everything in the ST besides GEM. It covers the hardware architecture, the keyboard, and the BIOS, XBIOS, GEMDOS, and Line-A calls. Also included is a disassembly of the BIOS and a short discussion of 68000 assembly language that should provide just the .information a high-level language programmer will need. The first edition is marred by several factual errors (some of which were undoubtedly reproduced from Atari's documentation); a second edition may come out to correct them.
- Atari ST GEM Programmer's Reference (Abacus, 414 pages) is a GEM manual that is less tutorial than the SYBEX offering, but completely ST specific. It gives examples of using the Atari Developer's Kit and of calling GEM in both C and assembly language, with several short programs. It summarizes each AES and VDI routine on a separate page, giving the parameters, examples, and known problems. Like the Internals book, this one suffers from errors.
- Atari ST Tricks and Tips (Abacus, 260 pages), is a highly useful collection of programs, techniques, and random bits of information that should be of interest to all ST programmers. It includes source code for a RAMdisk, a print spooler, and numerous other utilities. The programs are written in C, assembly language, and occasionaly BASIC, but the techniques discussed are portable across languages to any GEM project. Extremely valuable.
User groups are often the cheapest and best sources of technical information on the ST: most have several ST experts among their membership, and all offer public-domain software disks for small or no fees. I have found that sometimes a high-quality public-domain utility can make the difference between frustrated exhaustion and the completion of a project. User groups can also match you up with owners of commercial products you're thinking of purchasing.
On-line services can also provide megabytes of ST programming assistance. CompuServe seems to be leading the pack right now with an ST Forum as well as an Atari Developer's Forum through which Atari Corp. supports its registered developers (purchasers of the Developer's Kit). Don't be afraid to join a forum and ask questions of general interest, or even to address specific questions to specific individuals you think may be able to help. Most Atari users, whether they subscribe to CompuServe, Delphi, GEnie, BIX, or whatever; are eager to share their expertise with anyone who will ask for it! UNIX users should also know that Usenet has an active net.micro.ataril6 newsgroup for ST-related discussions.
I truly believe that you can't go wrong with any of the products (compilers, tools, books, and online services) that we have discussed. The language systems will get the job done one way or another, and the other tools will help you do it. The most important thing to remember is that developing ST software is not simple, so you should not expect to duplicate DEGAS with a weekend's work. However, it is quite possible to write professional-quality ST programs without spending a fortune and still have fun doing it.
LIST OF MANUFACTURERS
GST-C ($79.95)
CIRCLE 435 ON READER SERVICE CARD
Fractal Factory Source Code
($19.95)
CIRCLE 436 ON READER SERVICE CARD
GST Holdings Limited
91 High Street
Longstanton, Cambridge
England
Available from:
The Catalog
524 Second Street
San Francisco, CA 94107
(415) 957-0886
Orders: (800) 443-0100, ext. 133
Personal Pascal ($74.95)
CIRCLE 368 ON READER SERVICE CARD
Optimized Systems Software, Inc.
1221 B Kentwood Avenue
San Jose, CA 95129
(408) 446-3099
BBS: (408) 446-3451
Modula-2/ST ($79.95)
$149.95 for developer's version)
CIRCLE 369 ON READER SERVICE CARD
TDI Software, Inc.
10410 Markison Road
Dallas, TX 75238
(214) 340-4942
Telex: 888-442
Softworks BASIC ($79.00)
CIRCLE 348 ON READER SERVICE CARD
Softworks Limited
2944 N. Broadway
Chicago, IL 60657
(312) 975-4030
KISSED ($39.95)
CIRCLE 437 ON READER SERVICE CARD
M-DISK ($39.95)
CIRCLE 438 ON READER SERVICE CARD
SOFT-SPOOL ($49.95)
CIRCLE 439 ON READER SERVICE CARD
DOS SHELL ($39.95).
CIRCLE 44D ON READER SERVICE CARD
MichTron Inc.
576 5. Telegraph
Pontiac, Ml 48053
(313) 334-5700
BBS: (313) 332-5452
MT C-Shell ($129.95)
CIRCLE 441 ON READER SERVICE CARD
MICRO C-Shell ($49.95)
CIRCLE 442 ON READER SERVICE CARD
MICRO C-Tools ($24.95)
CIRCLE 443 ON READER SERVICE CARD
MICRO Make ($34.95)
CIRCLE 444 ON READER SERVICE CARD
Beckemeyer Development Tools
592 Jean Street #304
Oakland, CA 94610
(415) 658-5318
Atari ST Internals by Klaus Gerits, Lothar Englisch, and RoIf Bruckmann
(December 1985) ($19.95)
CIRCLE 128 ON READER SERVICE CARD
Atari ST GEM Programmer's Reference by Norbert Szczepanowski and Berud
Gunther (January 1986) ($19.95)
CIRCLE 125 ON READER SERVICE CARD
Atari ST Tricks & Tips by Rolf Bruckmann, Lothar Englisch, Jorg
Walkowiak, and Klaus Gerits (March 1986) ($19.95)
CIRCLE 127 ON READER SERVICE CARD
Abacus Software
P.O. Box 7211
Grand Rapids, MI 49510
(616) 241-5510
Telex: 709-101
Programmer's Guide to GEM by Phillip Balma and William Filter ($19.95
+ $2.00 postage and handling)
CIRCLE 134 ON READER SERVICE CARD
SYBEX Computer Books
2344 Sixth Street
Berkeley, CA 94710
(415) 848-8233
Telex: 336311
Orders: (800) 227-2346