January 90 - THE APPLE II DEVELOPMENT DYNAMO
THE APPLE II DEVELOPMENT DYNAMO
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
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
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
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
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.
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
lda varspace+1,y ;move high 8 bits
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:
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
temp equ 30
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
sta varspace+temp ;set low byte to 27
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:
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.
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
_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][weight];
Using Dynamo and the macro interface, this is:
_array #stuff,w,#5,#6,#7,#8 ;activate array "stuff"
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
mat1loc equ $1000 ;storage for mat1
mat2loc equ $1080 ;storage for mat2
mat1 _array #mat1loc,w,#8,#8
mat2 _array #mat2loc,w,#8,#8
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
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|
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
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
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. *