How to install Dynamo and do your first Dynamo build:


1)	Copy the Dynamo disk (or folder) contents into a folder called
	"dynamo" on your hard disk.


2)	Make an addition to the "UserStartup" file for MPW.  This file is found
	in the MPW folder itself.  You need to make an addition for Dynamo
	something like the following:

	#   {dynamo} - Directory that contains dynamo package -- same level as MPW.
				set dynamo "{MPW}":dynamo:
				export dynamo

This example assumes that you created the Dynamo folder at the same directory
level as MPW.  You can actually put it anywhere you want, as long as the
location is reflected in the UserStartup file.


3)	Execute this addition to UserStartup, or restart MPW, so the UserStartup
	addition can take effect.


4)	Issue the following duplicate command:

		duplicate -y "{dynamo}"dynamo.includes "{AIIGSIncludes}"

	You now have the Dynamo include files where AsmIIGS can find them.


5)	Copy the file called BUILDAPP.SYSTEM (in the app.builder directory) to
	a ProDOS disk.  BUILDAPP.SYSTEM is a very useful program builder and
	launcher for 8-bit applications.  See the "buildapp.manual" in the
	"appbuilder" directory for details on "BUILDAPP.SYSTEM".
	You can use the following command lines to copy BUILDAPP.SYSTEM to a
	ProDOS disk:

		SetDirectory                "{Dynamo}"
		duplicate -d                :app.builder:BUILDAPP.SYSTEM :app.builder:TEMP
		setfile -c 'pdos' -t 'FF  ' :app.builder:TEMP
		duplicateiigs -d -mac       :app.builder:TEMP BUILDAPP.SYSTEM
		delete -y                   :app.builder:TEMP


6)	The Dynamo sample application should now be buildable.  Use the
	following commands to set the current directory and copy the
	buildapp.text script to your ProDOS disk.

		SetDirectory          "{Dynamo}"dynamo.sample:
		duplicate -d          buildapp.text TEMP
		duplicateiigs -d -mac TEMP BUILDAPP.TEXT
		delete -y             TEMP

	The above duplicates are necessary due to an old bug in duplicateiigs
	where the destination file was created with a resource fork if the
	source file had one, even if you specified a data fork only copy.


7)	Now use the MPW menu command to do a full build.  The sample program
	name is "sample" (surprise).  Once this is done, you will have a
	ProDOS disk with everything necessary to execute the Dynamo sample
	program.  Just double-click the BUILDAPP.SYSTEM if you are in the IIGS
	finder, or if you have a IIe, then you will need to put ProDOS on the
	disk as well, so it can boot.


_________________________________________________________________________________


Some new stuff and some cool ideas:

If you are familiar with previous versions of Dynamo, you will see that a
number of things have changed and have been reorganized.  The structure is
more conducive to multiple-project development.  Since Dynamo is localized
and the include files are available to AsmIIGS just like other include files,
Dynamo version control is easier.  It is no longer so tempting to make a
simple custom change to the Dynamo ruuntime for just one application, and
therefore end up with multiple versions of Dynamo for different projects.

Another big change is that the source code for BUILDAPP.SYSTEM is now
included.  This is so that extensions in the application build and launch
process can be done by others to better suit their needs.  Currently,
BUILDAPP.SYSTEM simply moves the code to the bank and memory location
described in the build script.  Some more complex methods might be needed
for more complex applications.  An application may need overlays, for
example.  There may be two blocks of code that actually need to run at
the same location, just at different times.  A revised BUILDAPP.SYSTEM
could put these so-designated segments in auxiliary memory, and then the
application could move them to main memory when needed.

For example:  Here is a simple idea for an overlay system:

BUILDAPP.SYSTEM could move designated files to aux ram when it is moving
segments around at application launch time.  This could even be done by
using ProDOS to save the range of memory to /RAM5.  When the main
application needs the code segment, it could simply use ProDOS to load it
into main memory.

Here's a reasonably simple approach to overlays:  When you want to call
a segment of code that may or may not be in main memory, do a jsr to 
an overlay management routine.  (Dynamic segments kind of work this way
on the IIGS.)  The code would look something like:

			sec						;Input for overlay code.
			lda		value			;Input for overlay code.
			ldy		value+1			;Input for overlay code.
			ldx		mode			;Input for overlay code.

			jsr		overlay
			dc.b	jiffyCoolCode	;Segment # we want to call.

The overlay manager would first save the registers and processor status.
Then it would use the return address on the stack to figure out where the
jiffyCoolCode segment number is in memory.  It would then get this byte
from memory.  Once this is done, the return address would be incremented 
by 1 and pushed back onto the stack.

Now that we have the overlay segment #, we would use this to load the
segment from /RAM5.  Once it is loaded, the registers and processor status
would be put back to what they were when the overlay manager was called.
Once this is done, the overlay manager would jump to where the code was
loaded.

A little more logic could be added to see if the code segment requested
is already in main memory.  (Old segment # = requested segment #.)  If
it is, then the loading of the code could be skipped.

As you can see, doing overlays isn't so tough after all.  A simple
system like this can really free up a lot of main ram on an Apple II.

For more readibility, a macro could be used to call the overlay code.
The call might look like:

			_jsr	jiffyCoolCode

The macro would expand to the calling convention shown above.



Anyrate, given that BUILDAPP.SYSTEM isn't the final solution for
everybody, I supplied the code so that everybody could change it
if they wanted to.




Eric Soldan, Apple II DTS
