THE APPLE II DEVELOPMENT DYNAMO

ERIC SOLDAN

The new Dynamo 8-bit Development Package from DTS makes developing software for the Apple II family easier and faster. This article highlights the capabilities of the package and describes how it meets developers' needs. Dynamo includes a run-time module with a macro interface and an Apple II application loader. It offers routines for handling strings, variables, arrays, and integer math.

Because of the speed and memory limitations of 8-bit Apple IIs, Apple's opinion that assembly language is the best choice for development has not changed over the years. Assembly language, however, places a heavy burden on the developer.

The more popular high-level languages depend on a processor being able to handle a large stack as part of its instruction set. Because the 6502 doesn't support a large stack, high-level languages on the Apple II generally implement their stacks in software and pay a considerable penalty in speed and memory.

Given the disadvantage of a processor not specifically designed with high-level languages in mind, the authors of the available Apple II languages have done an admirable job. These languages are very useful for many applications. Programs that require lots of speed and memory, however, can't afford the overhead of a high-level language.

WHAT DO YOU REALLY NEED?

As a developer, you don't need a specific high-level language or a particular tool set. You do need what successful languages and tool sets were designed for: to provide help in meeting fundamental development objectives. Developers need to produce code:

• that is fast
• that takes the least amount of development time
• that consumes the least memory
• that is easy to read
• that is reliable

How well does assembly language meet these needs? Assembly produces the fastest code possible. This is especially important on the Apple II, where your code may be running at one megahertz, and every cycle counts.

It is difficult to write good assembly language code quickly. All the housekeeping demands painstaking attention to detail and carefully constructed code.

For code compactness, assembly language is excellent. It is actually difficult to develop assembly code that consumes as much memory as a good compiler.

Assembly language is hard to read. If you need to understand the code a year from now, you had better provide very good comments and plenty of them. Also, you may not be the only one who will need to understand your code.

Assembly is not well known for bug-free code production. You build the ifs, loops and data constructs yourself from assembly language statements. There is no compiler to check your syntax.

After pondering developers' needs, DTS implemented a new environment for Apple II assembly language to help make 8-bit development easier and faster, called Dynamo. The core of Dynamo is a small library of run-time routines. Dynamo has macro definitions that generate very short code fragments that use the library routines. Given that the library is all assembly language, and the macros generate the minimum code necessary to interface to the library, the code stays small and fast. Dynamo handles things that are usually cumbersome in assembly language--namely variable, string, and array management, as well as integer math. The macros add a high-level flavor to the environment, and you get speedy development of readable and dependable code. Let's take a closer look at how the different aspects of Dynamo work.

MANAGING VARIABLES

In developing Dynamo, it was important to look at typical operations within a program. We studied how long it took to code these in assembly, how big the code was, and how long the code took to execute. One such operation is assigning a value to a variable. Some examples (in Pascal) look like this:

   aardvark := buffalo;
    cat := 1000;
    dog := elephant * fish / goat + 12345;

If you had a collection of run-time routines to do the real work, the main line of code would just do things like determine what happens to which variables. We looked at several ideas and started coming up with assembly code that looked like the following:

   ldx     #aardvark   ;load pointer to aardvark
    ldy     #buffalo    ;load pointer to buffalo
    jsr     varcpy      ;move buffalo to aardvark (16 bits)

The x-register is loaded with a constant (from 0 to 254) that represents the variable aardvark. The y-register is loaded with a constant that represents the variable buffalo. These constants are like pointers they are offsets into a variable table. Then we call a routine to copy the value of the 16-bit variable buffalo to the 16-bit variable aardvark. The routine looks like this:

varcpy lda varspace,y      ;move low 8 bits
        sta varspace,x
        lda varspace+1,y        ;move high 8 bits
        sta varspace+1,x
        rts

Varspace is some location in memory where the integer variables reside. Since we are indexing into it with a 1-byte index, the maximum size of this space is 256 bytes, and since integers take 2 bytes, the maximum number of variables is 128. This 128 variable limit may seem small, but a typical program just doesn't have that many simple variables.

Now, by using a macro to become part of the interface, this can become:

   _varcpy     aardvark,buffalo

This means "copy the value of the variable buffalo to the variable aardvark." It isn't Pascal, but it isn't trying to be.

Remember that the variable names represent 8-bit numbers. They are declared by equating them to values from 0 to 254. Don't mistake the variable names for addresses. Saying:

       temp    equ     30
        lda     #27
        sta     temp
        lda     #00
        sta     temp+1

will store the number 27 in zero page location 30, something you don't want to do. The _varcpy routine takes the argument temp as an index into the variable table that starts at varspace. To explicitly store 27 in variable temp without using the Dynamo routines, you would say:

       temp    equ     30
        lda     #27
        sta     varspace+temp       ;set low byte to 27
        lda     #00
        sta     varspace+temp+1     ;and high byte to zero

As long as you use the Dynamo interface to deal with variables, you can treat them as if the name refers to the value.

Now, does this code meet our five objectives?

It isn't as fast as it could be. The fastest code would be:

       lda     buffalo
        sta     aardvark
        lda     buffalo+1
        sta     aardvark+1

This code, although faster, takes more memory. If we were copying an integer from one place in zero-page to another, the fast code would be 8 bytes. If we were copying an integer not in zero-page, it would be 12 bytes. The slower way would be only 7 bytes. The _varcpy routine takes up some space, but it is in memory only once so it doesn't really count.

Although we lost some speed, the code got smaller. It also became easier to read and faster to write and to debug. A good compromise, given that it is more readable, and is inherently more reliable.

Using these routines and macros, some sample code that assigns some variables, adds, multiplies, and divides looks like this:

       aardvark    equ     0           ;declare 16-bit variables
        buffalo     equ     2
        cat         equ     4
        dog         equ     6
        elephant    equ     8
        fish        equ     10
        goat        equ     12
            _varcpy aardvark,buffalo    ;aardvark := buffalo
            _set    cat,#1000           ;cat := 1000
            _varcpy dog,elephant        ;dog := elephant
            _mulvar .fish               ;dog := dog*fish
            _divvar goat                ;goat := goat/dog
            _add    #12345              ;goat := goat+12345

Notice that dog doesn't have to be mentioned on the _mulvar line. All the Dynamo library routines preserve the x-register, so the x-register still has the constant for dog in it. If there is no destination variable, _mulvar generates code that leaves the x-register alone.

MANAGING ARRAYS

We typically store large blocks of data in arrays, which is why the 128 simple variable limit is not so bad. Arrays are a little trickier than variables, and a pointer-based system works best. When you calculate a base pointer to a row, the row elements will be in linear order from there on in memory. So, for a two- dimensional array, tell Dynamo what row to work with, and treat that row as if it were a one-dimensional array. The array routines are good for up to four dimensions. Increasing this is rather easy, but the overhead goes up slightly for each dimension you add.

Here's code for a four-dimensional array:

       _array      #$4000,w,#3,#4,#5,#6    ;activate array at $4000
        _index      #1,#3,#4
        _getw       value1,#3               ;value1 := array[1,3,4,3]
        _putw       value2,#5               ;array[1,3,4,5] := value2

The _array macro defines the size of the array elements, the number of elements in each dimension, and the location of the array. This example has a four-dimensional array whose dimensions are 3 x 4 x 5 x 6. The array starts at address $4000, and the element size is a word. _array is an assembly-time macro and does its calculating at assembly-time. This means the arguments must be constants like literals or equates. If the first argument had an * instead of a #, it would be used as the address of a pointer to the base address. _index is a run-time macro and can use literals or variables.

The _index macro indexes into the array, up to but not including the final subscript or index. The _index macro is used to calculate a pointer to a row of data. Once this is done, access to the row is as if the array were linear, and you can make multiple accesses to the array. Since the address of the row does not have to be recalculated, the last subscript is simply used as an index into the row of data.

This example uses the _getw macro to get a word element of the row and place the value into a variable. Element #3 (from zero) of the row is moved to the variable value1. Finally, the value of the variable value2 is placed in element #5 of the row.

_getb and _putb work with byte elements, and _vgetb, _vgetw, _vputb, and _vputw use a variable as an index instead of a constant:

You can also use a variable value when calculating an index to a row of the array--for example, to get an element from the array stuff[] and save it in thing. For you C dudes, this looks like:

   thing = stuff[color][size][3][weight];

Using Dynamo and the macro interface, this is:

       _array      #stuff,w,#5,#6,#7,#8    ;activate array "stuff"
        _vindex     color,size
        _index      ,,#3
        _vgetw      thing,weight

You can mix variable and constant subscripts, as long as you remember the commas as place holders on the second line. Also, if the first index hasn't changed, you don't need to mention it.

There can be only one active array at a time, and _array sets the active array. Instead of putting code in-line to activate an array, you can define simple routines to set active arrays.

       jsr     mat1            ;set mat1 active
        _vindex row             ;set pointer to rowth row
        _vgetw  thing,column    ;thing := mat1[row,col]
        jsr     mat2            ;set mat2 active
        _vindex row             ;set pointer to rowth row
        _vputw  thing,column    ;mat2[row,col] := thing
        rts
mat1loc equ     $1000           ;storage for mat1
mat2loc equ     $1080           ;storage for mat2
mat1    _array  #mat1loc,w,#8,#8
        rts
mat2    _array  #mat2loc,w,#8,#8
        rts

The # in #mat1loc and #mat2loc means use the value of mat1loc and mat2loc as base addresses for the arrays. If the #s are replaced with *s, you get another level of indirection, and the contents of mat1loc and mat2loc would be used as the array location instead. All of these tricks add up to very efficient and flexible array access in assembly language.

MANAGING STRINGS

String management works much like variable management. The x-register holds the constant representing the destination string. You can perform operations on a destination string, like copying another string into it, reading string data into it, appending another string, appending some portion of a string, printing the string, and so forth. Just like the variable management routines, the x-register is always preserved. Of course, all of these functions are done with macros for readability.

PUTTING IT ALL TOGETHER

These simple things make programming in assembly language immensely easier. The only cost is some loss of speed. If a particular routine needs to be as fast as possible, you can still write it in straight assembly code. After all, you are using an assembler.

The Dynamo runtime library is very small. A breakdown of the various routine types is as follows:

initialization & char output routines:	154
integer variables & intmath routines:	787
random generator routines:	139
string handling/output routines:	505
read data (ints & strings) routines:	77
multi-dimension array handling:	358
TOTAL	2020

These values apply only if you use all the routines in a particular area. The linker only includes what you use.

The new MPW IIgs Cross-Development System is another step toward a better development environment. It is the most powerful development environment available for the Apple II and IIgs. Having the most powerful system is important. Developers are the ultimate power users. Developers spend an incredible amount of time using computers. The less time they spend editing code and waiting for assemblies, the more time they have for real development work. MPW lets you keep several windows of source code open at the same time. And since the Mac is not used to test the software, you don't have to boot out of your development environment every time you test your program. You can look at main code and subroutines or data structures while your program is running on your Apple II. Also, the speed of the system reduces development time. There is nothing wrong with developing Apple II software on an Apple II. It just takes longer. If you can afford a Mac and the MPW IIgs Cross- Development System, you should really consider developing with it. It should pay for itself very quickly in terms of development time dollars.

One last statement: Dynamo was not difficult to develop, so if it isn't perfect for your development needs, develop your own macro interface. Just remember, you can keep memory use down and speed up by working in assembly language.

The source code and user's manual for Dynamo are included on develop, the CD and the Apple II source code disks from APDA. *

Eric Soldan, Apple II DTS engineer, specializes in Toolboxes, printing, and making trouble. He's been with Apple since 8/8/88, a day he claims the Chinese think is an extremely good day ("eight"pronounced in Chinese means "prosperity"). At the University of Missouri-Rolla, he studied math and computer science, with a minor in beer. When he's not making trouble, he's tending his own enterprise, Educational Software Systems, a business he shares with his wife. Other interests include racquet sports, chess, and piano. *

For this development environment, variables are two-byte integers. There is no support for floating point. For that, you could use SANE or various other solutions. *

Dynamo MPW requires a Macintosh that can run the Macintosh Programmer's Workshop (MPW) and an 8-bit Apple II or Apple IIgs with a 3.5" drive. You'll also need MPW, MPW IIgs Tools, MPW IIgs Assembler, and ProDOS with the Dynamo package. *