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.
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:
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.
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.
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.
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.
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. *