Berkeley Softwork's GEOS operating system is undoubtedly the single most significant software development for Commodore computers during the last few years. Programmers can now take full advantage of GEOS with GEOPROGRAMMER, a powerful assembly language development system.
Back in 1986, when most Commodore 64 applications were text based and disk access was slow, the introduction of GEOS was a major event. Many Commodore users are now familiar with the convenient deskTop, and sophisticated GEOS applications such as geoPaint. Adept users soon discovered the benefits of integrated software. Text can easily be displayed in a multitude of fonts and combined with graphics. But overall, with support for innumerable printers, the new RAM expansion units, and 1351 mouse, GEOS is clearly the operating system which makes best use of the latest in Commodore hardware resources.
By the beginning of 1987, Berkeley Softworks was encouraging programmers to take advantage of GEOS by developing their own GEOS applications. The Official GEOS Programmer's Reference Guide was soon available, explaining most of the finer details of GEOS programming. Merely providing information about GEOS routines and examples of source code was not enough for most programmers. Few of the available assemblers could handle the detailed source code listings. None of them could produce an entire GEOS application.
Berkeley Softworks designed GEOS within their own programming environment running on UNIX workstations, machines that are larger and faster than an Amiga 2000. geoProgrammer is a scaled-down version of this environment for the Commodore 64. Berkeley Softworks claims that geoProgrammer contains nearly all of the functionality of their own system.
The geoProgrammer package consists of geoAssembler, geoLinker, and geoDebugger, sample source code for three GEOS applications, and over 400 pages of documentation. Other files include a complete listings of GEOS symbols, constants, routines, macros, and a memory map - everything necessary to begin programming.
The immense user's manual, by Matthew G. Loveless, is exceptional. It clearly covers all of the features of the geoProgrammer assembler, linker, and debugger. Tutorials cover the step by step production of a sample application and debugging sessions. A fourteen page glossary gives definitions of programming terminology. The index is organized by subject and alphabetically, making the manual a key part of the package.
Although it is not a course in assembly language or GEOS programming, the manual includes additional information about the GEOS operating system not available elsewhere. Source code files for sample VLIR and SEQuential applications and a sample desk accessory, which are also included on the disk, are provided as examples of GEOS programming and can be used as the basis for new GEOS applications.
The heart of the geoProgrammer package is geoAssembler. It is responsible for reading assembly language source code and producing relocatable machine language object files. What makes geoAssembler distinctive is that it makes use of resources in the GEOS environment.
Source code for geoAssembler is created with geoWrite. All of geoWrite's special features can be used in the creation of source code. Different fonts or text styles can be selected in order to emphasize sections of source code. Since assembly language is often repetitive, the cut and paste functions are especially helpful in preparing source code.
Adding graphics to source code is likewise performed by geoWrite's cut and paste functions. Icons and other bitmap images are easily created with geoPaint and pasted into source code documents. Whenever geoAssembler encounters a Photo Scrap in your source code, it translates the image into binary data. Incorporating graphics into a program has never been easier.
Source code for geoAssembler uses symbols, standard assembly language mnemonics and addressing modes. In a symbolic assembler, symbols can be defined to represent constants, variables, and subroutines, or other sections of code. Unlike other assemblers, symbols can be up to 20 characters in length, and contain upper and lower case characters.
Another time saving feature is the use of macros. Macros are user definable routines which are made up of smaller routines. For example, this is a macro definition to move a byte from one memory location to another:
.macro MoveB source,destination
lda source
sta destination
.endm
From then on, whenever you need to move a byte, you can use the MoveB macro. When geoAssembler encounters a macro in the source code, it automatically substitutes the macro's definition and includes the values passed to it.
geoAssembler incorporates some features found in high level languages. A built-in expression evaluator is capable of 16 bit math and includes 26 math and logical operators. Besides the usual addition, subtraction, multiplication and division operators, the expression evaluator can also handle such uncommon operators as bitwise one's complement and modulus (remainder of integer division). Furthermore, the expression evaluator can differentiate between logical and bitwise AND, OR, and XOR operations.
Conditional assembly is an aspect of geoAssembler which resembles the IF, THEN, and ELSE statements found in BASIC 7.0. Sections of code can be assembled or not, depending on the values of expressions. In this way, different versions of a program can be assembled from the same source code. A common use for conditional assembly is to include special code for test versions of a program. By changing the value of an equate, the test code won't get assembled into final versions of the program.
geoAssembler is one of the fastest assemblers ever for the Commodore 64. Assembling a test file of 390 lines of source code took 2:45 using an old favorite standard assembler. The same file was crunched into object code in only 45 seconds by geoAssembler. That was with both the input and output files on disk. Assembly can run even faster by exploiting the high speed input/output now available with RAM expansion units. A RAM expansion unit is highly recommended for use with geoProgrammer, and GEOS in general.
If errors are encountered during assembly, they are sent to an error file. geoAssembler produces 52 different error messages. Error messages are exceptionally descriptive, pointing out the exact location in the source code where the error will be found.
Unlike many assemblers, geoAssembler doesn't directly produce runnable programs. All of the object files output by geoAssembler are relocatable, that is, they can be made to run in different parts of program memory. geoLinker is used to adjust an object file to run in a specific part of memory.
More importantly, geoLinker can combine multiple object files into an executable program. This encourages structured programming. You can develop a library of object modules to perform common routines. Small modules are easier to develop, test, and debug than complete applications. Modules can then be linked as needed to create new applications.
To simplify the linking of multiple modules, geoLinker supports external references. An external reference is a symbol which resides in one module but is called from another module. For example, a module could consist of a subroutine to clear the screen. The clear screen subroutine is called from the main application module. When geoLinker links these files, it will resolve the external reference by assigning an address to the clear screen subroutine. Atypical of linkers and assemblers, geoLinker and geoAssembler do not require that external references be declared.
Among geoLinker's GEOS specific functions are the ability to attach file headers and create VLIR applications. A file header is the part of a file which consists of information about the purpose of the file and the file's deskTop icon. VLIR applications are made up of a main module with overlay modules that are loaded into memory as required. Before geoProgrammer, both of these structures were difficult to manipulate, demanding special effort on the programmer's part. geoLinker automatically links file headers and VLIR programs.
geoLinker operates in much the same way as geoAssembler. It accepts commands from a geoWrite file, and produces a detailed error file if things go sour during the linking process.
One fact of life is that as long as there are programs, there are bugs. Bugs have an annoying habit of infesting even the most carefully planned source code. The good news is that geoDebugger gives you the right stuff to help you stamp out bugs.
geoDebugger is actually two different programs. If you use a 1750 or 1764 RAM expansion unit (which is recommended), double clicking on the geoDebugger icon will load the Super-debugger into expansion RAM. Super-debugger is the full-featured version of geoDebugger. Dedicated hackers will be pleased to learn that the Super-debugger isn't lacking in features. More than 80 commands enable you to flip almost any bit in your computer. If that wasn't enough, you can even design your own commands using geoDebugger's macro features.
If you don't have a RAM expansion unit, you'll be limited to using the Mini-debugger. However, the Mini-debugger is hardly limited. It still has most of the functionality of the Super-debugger, but because it has to reside in the computer's RAM along with any application you might be debugging, there's always the possibility that it will get in the way of some needed memory. Moreover, it is much less likely to survive a first strike if a program bombs.
At first glance, geoDebugger seems to be much like the monitor built into the Commodore 128. It has all of the usual monitor commands to assemble, disassemble, hunt, move, and otherwise display and alter memory. That's about as far as the similarity goes. Additionally, geoDebugger has commands that enable disk sectors to be read into a buffer, altered, and written back to disk. But geoDebugger is much more than a disk editor also.
The operation of geoDebugger is reminiscent of some of the software transparent memory dump and screen dump cartridges which can halt a running program in order to carry out their functions. geoDebugger sits out of harm's way in the RAM expansion unit (or an unused part of memory if you are using the Mini-debugger) and lets the program you are debugging have free reign of the computer. At any time, simply tapping the RESTORE key will put geoDebugger in control.
When geoDebugger is active, you have all the options previously mentioned. geoDebugger maintains it's own screen display separate from the one used by the application. Pressing the F7 key toggles screens between geoDebugger and the application.
Disassembling an application with geoDebugger is truly a pleasure. During linking, geoLinker sends symbols and their addresses to a debugging file. geoDebugger uses this file to include symbols while disassembling. As a result, the output during disassembly has a close resemblance to the original source code.
By using macros, Super-debugger commands can be added or altered as desired. Macros consist of geoDebugger commands and simulate the pressing of the required keys when executed. Macros can contain as many as 250 keystrokes. Macro files created with geoWrite are automatically loaded when geoDebugger is run. If a macro named AUTOEXEC is included in the macro file, it will configure geoDebugger to your liking during startup.
There are fewer bugs in geoProgrammer than personal dislikes. The first version of geoProgrammer to be shipped had problems with both geoAssembler and geoLinker. Fortunately, Berkeley Softworks released a file with details of how to patch the programs to make them run properly. Interestingly enough, geoDebugger is used to install the patches. The patch file is available on Q-link.
Of all the commands available in geoDebugger, there is no way to send debugger output to a printer. This basic function of many simple monitors is sorely missed.
The most bothersome problem is the way in which files can get replaced without warning. If you want to save previously assembled versions of a program, you'll have to rename them or transfer them to another disk. If you don't, geoAssembler will replace them with a new version the next time you assemble the same source code. The same problem is present while using geoLinker. If you happen to specify the same name for your output file as your source code file, your source code will be overwritten when the file is linked. You'll never get it back.
geoProgrammer is a complete assembly language development system. Combining powerful programming tools with a thorough, clearly written manual and the ease of use GEOS is famous for, makes geoProgrammer an excellent choice, with enough features for even the most demanding programmer.