Classic Computer Magazine Archive START VOL. 4 NO. 1 / AUGUST 1989


MichTron's DevpacST
A Speedy Way to Code


The most limiting factor in developing software is time. After all, code is the manifestation and crystallization of ideas. Creating code requires a lot of thought, and that can take time. Assembly programming is especially time-consuming because of the high attention to detail that it requires. When buying development software, therefore, an important question for the programmer is: "Will this product save me time?"

Most of a programmer's time is spent in a process referred to as "The Development Cycle" This is the time it takes to write some code, assemble and run it, watch it fail, debug until you understand what's wrong, fix the bugs, and write some more.

A good development system lets you execute the above process as quickly as possible, thereby creating more working code in less time. All systems include an editor, an assembler, a linker and usually a debugger and various utility programs for symbol cross-referencing, formatted printing, etc. Good systems also provide a realistic way for the programmer to put these tools to good use.

Some packages accomplish this by integrating all the software tools used during the development cycle into a unified "environment." In such an environment, any tool is accessible and you can save, edit, assemble, link or run your program instantly. This eliminates the need to hunt for the right tool, or to quit one program and start another. MichTron's DevpacST version 2.0 provides just such a programming environment, and I recommend it strongly to anyone planning to develop quality software in assembly language for the ST.

DevpacST uses an integrated environment; you can access the assembler,
debugger or editor from a GEM menu bar.

Responsive Interface
The first thing you'll notice when using Devpac is how responsive the interface is. Mouse input is clean, not sluggish. You never have to wait while Devpac redraws the screen or switches back and forth from the debugger to the editor to the assembly options dialog. Virtually the entire system was written in assembly, and it shows. Altering, assembling and running the program is very fast. Better yet, debugging is easy and only a keypress away!

The entire system is GEM-based, so you already know what it looks like. It has no special "control panel" nor any exotic interface features-just a menu bar and a full-screen editing window. You can access the various options dialogs directly from the menu bar. Separate screens are maintained for the debugger and the program you're writing. The debugger is not GEM-based, but is a "windowed" text view showing the usual low-level debugging information. There are windows showing the registers, contents of memory; instructions surrounding the program counter and a window for your command input.

The Good, The Better, The Best
Symbols are left-justified in the debugger's instruction window, with the disassembled code indented. Thus the display resembles the programmer's source code, making it intuitively easy to read. The debugger maintains a separate screen, allowing easy debugging of graphics programs.

The editor uses the ST's keypad as a second set of arrow keys and provides key equivalents for every menu entry (for the mouse-a-phobic). The editor screen scrolls sideways automatically when you enter a long line Key equivalents for the editor are WordStar-like, which is nice if you're used to any of the plethora of editors like this.

Devpac comes with a TTP version of the assembler for use in a command shell environment and includes a GEM menu-making utility. It provides IBM-style "[Control]-[Alternate]-[Delete]" resetting during debugging.

The linker can produce symbols for use with HiSoft BASIC, Prospero Fortran and Pascal, Lattice C and Alcyon C (or any DRI-compatible compiler).

Best of all, you can launch any program from within Devpac and can debug programs written in any language.

When you use the editor the [Help] key provides help messages. In the debugger, however, I do not like the [Help] key function. It displays an instruction screen-which contains no readable help of any kind! What's the point? Also, I found the debugger screen to be too crowded. Most of the space is taken up with text; I would have preferred more white space around each item in the display (except for the instruction window, which is very nice.) I appreciate all the information that the debugger gives, but not the eyestrain. Perhaps the ability to "hide" parts of the display would have been better, or the ability to switch between two screens. Better yet, why not make the debugger GEM-based too?

Also, the editor can edit only one file at a time. This is a severe limitation on the whole system and could make the programmer waste time.

The first thing you'll
notice when using
Devpac is how
responsive the
interface is.

Trying It Out
I am primarily a C programmer and generally use assembly only to create optimized versions of functions I have already written in C. I use the Mark Williams C compiler which also comes with a complete "environment" for creating programs. However, Mark Williams C uses a Unix-like command shell as its essential environment. It's "command line-oriented" rather than "mouse-oriented," so, by way of comparison, I also tried out the TTP version of Devpac. To make it work, I had to specify that it was to produce a DRI-compatible object file and then convert that file to Mark Williams format (with a utility provided by Mark Williams). This worked without a hitch.

A problem arose when I tried to run the GEM-based version of Devpac from within the Mark Williams command shell. I got a nasty "TOS error #33" message This is most likely a problem with the Mark Williams command shell, but beware. Gulam, a shareware command shell, runs Devpac without any problems.

Documentation Is Everything
Perhaps the greatest asset that any development system can provide is documentation that's easy to understand. A common flaw in software manuals is that they assume too much knowledge on the part of the reader. Although programmers are generally technically minded, they may be new to the system they're writing for. A well-written manual can save as much time as a debugger.

In this way, Devpac is as suited to the greenhorn ST user as it is to the battle-scarred veteran. The manual starts with an explanation of what readers should do, depending on their level of experience. If you have used an ST and a 68000 assembler before, you won't need to trudge through tutorials. You're given short, sweet instructions on how to get a program assembled and running; then you're directed to the section on the debugger. If you're an experienced assembly programmer but have never used an ST before, one useful section describes the ST interface, the use of tabs in a dialog box, etc. For owners of Devpac version 1.0, another section outlines the new features of version 2.0.

Furthermore, the manual covers the basics of writing GEM-based software and even provides a skeletal GEM program to start with. Notes on writing desk accessories and a useful utility are included that lets you create GEM menus easily without needing a resource construction set. It also has a section on the Motorola 68000 instruction set, but this is just a brief summary-beginners will need a supplementary text.

In general, the manual is very nice except for two annoying details. First, there is no section describing how to best to use Devpac with your particular set-up. Obviously; computer users with a hard drive will organize themselves differently from those with double-sided floppies and one-megabyte RAM disks. Users want help with this kind of stuff because it saves time!

The most limiting
factor in developing
software is Time.

Secondly, an important item appeared out of place. The paragraph describing the typographical conventions used throughout the manual should be at the beginning, but in the Devpac manual it's stuck at the bottom of page 8-at the end of the first tutorial. The "experienced ST users" who were instructed to skip this tutorial would have missed this information.

Nonetheless A Bargain
Still, I consider Devpac a bargain for the serious software developer. It's a complete system that can produce standalone applications or desk accessories that make full use of the GEM interface. Devpac provides everything you need to start programming right away. It will save you time and, after all, that's the name of the game.

Paul Dana is a professional software engineer whose hobbies include musical composition and performance. This is his first publication in START

DevpacST, $99.95. MichTron, 576 S. Telegraph, Pontiac, Ml 48053, (313) 334-5700.