Classic Computer Magazine Archive ANTIC VOL. 5, NO. 1 / MAY 1986


Personal Pascal


Optimized Systems Software, the people who wrote DOS, BASIC, MAC/65 and ACTION! for the 8-bit Atari Computers, have entered the growing market for ST development tools with Personal Pascal. As might be expected by those familiar with the OSS reputation, this comprehensive and well-documented package firmly establishes Bill Wilkinson's company as a top supplier of high-quality ST systems software.

With Personal Pascal, OSS has attempted to provide a complete language system for ST users who want to develop professional-quality applications. The software comes on one single-sided disk and consists of editor, compiler, include files, linker, libraries, and demonstration programs. There is also a desktop-style "Manager" program that ties everything together by providing an integrated development environment much more straightforward and friendly than the standard C command-driven system.

To begin a programming session, double-click on the PASCAL.PRG icon to run the Personal Pascal Manager. From here, choose "Edit" from the file menu to summon the text editor.

I reviewed version 1.0 of Personal Pascal, which included a traditional keyboard-based screen editor reminiscent of the editor in the 8-bit ACTION! cartridge. Even the totally mouse-bound should have no problem here. It uses the top screen line for status information, leaving the other 24 for text. The entire keyboard, including the function keys, is used for cursor control and command entry, and all operations are mnemonic. Also, if you're a veteran of WordStar, you may use the same control-key commands.

The editor can be told to automatically backup your files, and it offers two special features: autoindent and chaining to compilation. When autoindent mode is on, pressing [RETURN] will indent the cursor on the next line to the same character position as the beginning of the line above it. This makes it easier to produce readable code. When you are through with an editing session, pressing [F9] will save your file, then automatically compile and link it, returning you to the normal Manager screen upon completion.


Before we discuss the compiler itself, look at Listing 1 in the Software Library section. This is a sample Personal Pascal application that I wrote in a couple of hours after a quick reading of the manual. It will present the GEM Item Selector dialog, allowing the user to select a file, then count the number of lines of text in the file. The result is reported in an alert box, and the process continues until the user clicks the Cancel button in the Item Selector.

The source code for this program is 1740 bytes and the executable file produced by compiling with default options--is 8939 bytes. From the editor, the entire compile-and-link takes less than two minutes on a single-sided, one-drive system. With all the necessary programs and files on the disk, there is still about 60K available as disk workspace. Personal Pascal is compatible with both RAMdisks and hard disk drives for even faster program development.

Personal Pascal adheres to the Level Zero 1982 ISO Pascal Standard, with several common extensions and many ST-specific library subprograms and language directives. It is an excellent language for use with both introductory university computer science courses and the Advanced Placement Computer Science curriculum in high schools.

Personal Pascal provides a full implementation of the standard language. The only significant omission is the conformant-array parimeter found only in the Level One 1982 ISO Standard. (Conformant-array parameters allow procedures to receive array arguments without knowing their exact dimensions. For example, you could create a library of generic matrix manipulation procedures.)

Useful extensions for structured programming include the LOOP EXIT-IF END construction, which makes its test in the middle of the loop--in contrast to WHILE and REPEAT-UNTIL, which test at the beginning and end, respectively. Other extensions include predeclared subprograms for string manipulation, bit-shifting, file management, clock access, program chaining, and command line argument retrieval. Five ST-specific language directives are provided:

EXTERNAL allows Pascal programs to call subprograms written in assembly language. The documentation gives some information on the internal format of the various data types and the protocol for parameter passing, but it could be more complete.

C does the same for subprograms written in compiled C. To be used by a Pascal program, external and C subprograms must be in object code format and linked to the compiled Pascal program.

BIOS, XBIOS, and GEMDOS are directives that each take an integer constant as argument and execute the corresponding BIOS, extended BIOS, or GEMDOS function. The manual is very sketchy on the use of these directives, but one of the demonstration programs provides an example.

The Personal Pascal compiler produces .O object files directly without an intervening assembly step. These files can be linked either with the supplied linker (called from the Manager) or with the linker supplied in Atari's Development Package. Files intended for either linker are compatible with the other.

Native-code compilation has the advantage of speed which I personally feel outweighs the benefit of having assembly language source code output to modify before assembling yourself. My experience makes me confident that the Personal Pascal compiler generates efficient code for my applications.


The area where Personal Pascal really shines is GEM support. OSS has provided a library of procedures and functions, called PASGEM, that greatly simplify the task of programming for GEM VDI and AES routines. With Personal Pascal, it is easy to start programming with windows, menus, and dialog boxes without having ever seen Atari's monstrous development package.

GEM's basic services are divided into the following categories: Initializing and Exiting, Alert Boxes, Dialog Boxes, The Menu Bar, Window Management, Window Text and Graphics, Mouse Control, Event Management, and Miscellaneous Routines. For each of these areas, Personal Pascal provides one or more subprograms to control the GEM features.

In designing this interface to GEM, OSS chose to disregard the bindings and standard calls used in the ST Development Kit software (C and assembly language). The Pascal routines have many similarities with those discussed in the GEM VDI and AES manuals, but they are essentially a reworking of the system. Of course, they themselves make calls on the ROM GEM routines at the machine language level, but to the Pascal programmer they are a different set of routines.

As far as I am concerned, OSS has made the right choice in reworking the GEM calls in this fashion, and has done it well. I found it quite simple to write the CountLines program (Listing 1) using a few common GEM facilities, within minutes of first running Personal Pascal. In my experience the supplied routines work perfectly. It is true that not every single GEM call is supported by Personal Pascal, but all the essentials are there. Assembly language or C programmers can add whatever functions they need and link them to compiled Pascal programs.


However, the most important aspect of Personal Pascal's GEM interface is its accessibility. The manual devotes nearly half of its 283 pages to the GEM/Pascal Library, carefully explaining each sub-program and discussing global issues like event management and user-interface philosophy. This documentation can never fully replace Atari's own, but it does a better job of teaching GEM programming and giving programmers a quick start in producing applications.

The manual also adequately documents the Manager program, editor, compiler, and linker. Strangely though, the documentation leaves its reader wanting more. This is not because the documentation is incomplete. It is because the reader wishes OSS could have answered all the other questions about the ST. 138 pages are just not enough to provide all the information necessary to produce professional ST program. What about BIOS, XBIOS, and GEMDOS functions? What about the Line-A graphics routines that include bit-block transfer and seed-fill operations? What about controlling peripherals?

If you have Atari's $300 Development Package, you can answer some of these questions within Personal Pascal. For example, to write a sub-program to control the ST sound chip you need to determine from the BIOS Technical Reference Manual what parameters need to be passed to which XBIOS function number--- information that is stamped "Confidential" and not generally available.

OSS is currently working to address all of these areas. But even without complete documentation on all aspects of ST programming, Personal Pascal will be more than adequate for most user projects.

There is little to dislike about Personal Pascal. A few minor bugs in the first release were quickly fixed. By the time this review is published, a new version should be available. According to OSS, it will feature a GEM-based program editor capable of handling multiple files simultaneously in separate windows, more GEM support and documentation, more Pascal extensions, and improved code generation.

Conformant-array support is under consideration. Additionally, a BIOS/XBIOS/GEMDOS support library with full documentation was to be available in March. Finally, if you want to distribute your Personal Pascal software commercially, OSS only requires that you visibly acknowledge the role of their product in developing yours. No royalties.

Anyone who is considering programming the ST, with or without the GEM interface, either commercially or as a hobby should also consider purchasing Personal Pascal. OSS has always followed up on its quality products with free newsletter, voice telephone and BBS support (you have to pay the long-distance company, not OSS). Like the TV commercial says, when you buy Personal Pascal, you buy a company. This is the best feature a software package can have.

Optimized Systems Software
1221-B Kentwood Avenue
San Jose, CA 95129
(408) 446-3099

Modula-2 ST

Reviewed by TIM OREN

Modula-2 is a relatively new computer language developed by Professor Niklaus Wirth, the inventor of Pascal. Like Pascal and C, Medula is a block-structured, compiled language. If you are used to interpreted BASIC, this means that any Modula code which you enter must be run through a program called a compiler, which converts Modula into machine code, which in turn is loaded into the ST and run. Block structuring means that rather than assigning statement numbers to lines, they are grouped in blocks by surrounding keywords. The blocks may then be used as one statement in IF or loop statements.

Like Pascal, Modula is a strongly "typed" language. This means you must declare all variables and routines before you use them. When they are declared they are given a type, such as INTEGER or CARDINAL. The compiler requires that you always perform operations on variables of like type. For instance, you would not be allowed to directly add a REAL and an INTEGER. However, there are type conversion functions to allow this. The purpose of this restriction is to prevent inconsistencies in the use of a variable from creeping into the code and causing errors.

Most of Modula's syntax is derived directly from Pascal. However, two important features have been added. The first is the concept of modules (hence the name). A module is a collection of routines which perform related functions. For instance, the routines to insert, retrieve, and delete information in a data structure might be combined into a module. The purpose of modularity is to divide a program into smaller, easier to understand pieces.

Communication between modules is by means of IMPORT and EXPORT- lists, which define exactly what each module is allowed to know about the others. This gives you freedom to make any changes you want within a module, so long as the exported variables and routines still behave the same. Since the function of each module is well understood, you can reuse them in other programs and build up a library of code to speed your work.

The second addition in Modula is support for concurrent processes and co-routines. The language provides the ability to send messages and flags between modules which appear to execute simultaneously. The run-time library provided with Modula handles the switching between tasks. While many users may never require this facility, it allows Modula to be used for some projects which have required assembly coding up to now.


TDI software of Bristol, England has acquired the rights to commercially distribute the Modula compiler and related software developed by Dr. Wirth. Modula-2/ST is their implementation for the Atari 520 ST. It is supplied on two single-sided disks, and includes the Modula compiler and linker, as well as a GEM-based program editor. The package has extensive library modules which provide the Modula run-time services and complete access to the ST's BIOS and DOS, and the GEM VDI and AES.

I tested TDI Modula on a 520ST with two single-sided drives and RAM-based GEM. Since I am fluent in C and have some knowledge of Pascal, I skimmed over a copy of Wirth's primer on Modula-2 to prepare and then worked my way through the examples given in TDI's manual. Finally, I modified the example programs both to experiment with the editor, and to create some error cases to test the compiler and the tools supplied.


I found the compiler itself to be robust and reasonably fast, even on a floppy-based system. While testing, I deliberately made coding errors which are apt to crash compilers, such as misarranging the block structure of the program. In every case, TDI Modula correctly diagnosed the problem.

The compiler itself consists of a main program and a set of overlay files, which are loaded into memory one after another to perform the various phases of the compile. This makes for a good deal of disk I/O, but the Atari drives were up to it and the delays were not annoying.

The editor supplied with Modula is a straight-forward programmer's tool. Again, I found no bugs here. The linker which must be run after the compile to prepare the PRG file is quite fast, especially to anyone who has used the LINK68 program in the Atari developer's kit.

There is one major deficiency in the Modula-2 package: a debugger. Everyone makes errors, and the use of a breakpoint debugger is probably the best way to find the mistakes. The Medula linker does not produce a symbol file, so there is no way to substitute another program, such as the SID provided to Atari developers. The programmer must resort to inserting print statements within the program to get test output. This an important shortage in a language as sophisticated as Modula.

The only bug I encountered while using the package is actually a problem in GEMDOS (TOS). It seems that under some conditions the DOS does not free the memory allocated to a file when it is closed. After a while, it runs out of memory and just stops opening new files. This produces interesting effects such as Desktop windows which are empty, or compiler runs with no output! Given the amount of file accessing performed by Modula, I was forced to reboot after every three runs to avoid the problem.


TDI has come up with a clever way to handle compile errors. Instead of being written directly to the screen and then scrolling off the top, they are written out to an error file. When the editor next loads up the program's source-code, the error file is also read and the offending locations are marked. Positioning the edit cursor at the mark causes the error number and description to be printed at the bottom of the editing window. After fixing the error, you may delete the error marker or the editor will do this automatically when it writes the file out.

My only criticism of this scheme is that the error messages seem to be stored on disk, and the editor pauses to access them whenever the cursor hits an error mark. This can often be annoying when moving rapidly through the text. TDI could improve this feature by waiting for the cursor to stay in one place for a while before writing out the error.

Assembler and C programs which commit run-time errors on the ST are prone to disappear in a barrage of bombs, never to be seen again. So, it was a relief to see a friendly alert box appear on the screen when I deliberately caused a divide by zero error. This service is provided by the Modula run-time library which traps error conditions before they get to the ST's bomb code.


TDI Modula is provided with a simple, wire-bound user's manual. This does not purport to teach you Modula. For that you are expected to buy one of the tutorial books available on the language. I chose Programming in Modula-2 by Wirth himself, and found it adequate for an experienced programmer but probably heavy going for a beginner.

Over half of the TDI manual consists of listings and catalogs of library functions. The remainder is a short tutorial on using the package, and slightly longer descriptions of the compiler, linker, and editor. I found the tutorial itself poorly organized and probably confusing to the beginner. No reference is made to where the various files may be found. You are expected to work it out yourself. While you must use the editor to enter the sample program in Chapter Two, the editor itself is not described until Chapter Four, and the keys which make it work are defined in Appendix B.

While TDI Modula includes a complete set of bindings (subroutine calls) for the BIOS and DOS, VDI and AES, they are documented only with one or two line entries showing their calling parameters. For more information, one is referred to the documentation supplied with the GEM manuals supplied with the Atari Developer's Kit. Since this kit costs $300 and includes an entire C compiler itself, this seems a rather questionable approach to the problem.


When a generic piece of code, such as Wirth's Modula compiler, is moved from machine to machine you can expect to see some traces of the process. Although all of its components use the GEM windowing services, Modula-2/ST shows its non-ST origins clearly. Two examples will suffice. The first problem is in the edit- compile-link-test cycle. The editor, compiler, and linker each bring up a file selector when they are run. You must then select the appropriate file, and edit the path if your file is on a different drive. This process can get quite annoying after awhile. It seems reasonable that TDI could overcome this difficulty and make the whole system easier to use, by creating a supervisor program to move you between the various programs in the system without dropping back to the Desktop each time.

The editor is also minimally adapted from a text-only version. For instance, drag-selection of text is not possible. You must mark text blocks by positioning the cursor and selecting a menu item for both the beginning and end.

While the ST's cursor keys are used, augmented functions such as word left or end of line are clumsily placed on the function keys. Due to the ST's layout, touch typists must take their fingers off the home row to hit the function keys, which slows things down. Menu alternatives are provided, but this involves taking the hand entirely off the keyboard and performing two mouse actions. A frequent user will probably find the editor to be slow and a bit frustrating.


Because of the merits of the language itself and the quality of the compiler, TDI Modula-2 has the potential to be a great product. However, insufficient attention has been paid to adapting it to the ST. In addition, TDI seems to be confused over who might buy this package.

For the amateur programmer interested in trying something beyond BASIC, the $149 price tag is rather steep. A Modula textbook will have to he purchased in addition to the manual. The TDI manual itself requires some puzzling to get started with the package.

For the professional, the level of operating system and graphics support provided is inadequate. Anyone expecting to do serious work will also have to purchase the $300 developer's kit from Atari. The lack of a debugger will be especially felt in any large project.

This reviewer would like to see TDI either upgrade this product, or release a second version of Modula for the ST. The compiler itself is good enough that an adequate set of support tools could make this into a truly excellent language for the Atari ST.

TDI Software Ltd,
1040 Markison Road
Dallas, TX 75138
(814) 340-4944

Tim Oren needs little intoduction to members of the ST developers community. Currently user interface designer with Activenture--the firm which designed the CD-ROM software for the ST--Tim was previously involved with Digital Research in designing GEM. He is also the author of DR LOGO and the Resource Construction Set. ST Resource readers who want to get to know Tim better should take a Iook at his highly informative Professional GEM columns in the ST SECTION of ANTIC-On Line on CompuServe.