[A83] Re: Applications...


[Prev][Next][Index][Thread]

[A83] Re: Applications...




Programs are copied to an 8k area when run (_asm_exec_ram).  Programs are
not automatically copied back after they run.  This is an advantage.  It
lets you to trash the exec area, allowing things like self extracting
programs.  This is what sets the 8k limit for programs.

There is a free RAM page (RAM page 1) available for use by programs.  This
gives programs a total of 24k free RAM while executing.

There are two swappable RAM/ROM banks on the 86, located at $4000 and $8000.
RAM page 1 is normally located at $8000.  If a program needs more than 24k,
then there are a variety of options available.

One option is to use relocation techniques to (easiest is to merely swap the
data) position the actual program data at the beginning of a RAM page (since
it could be split along two pages) and swap that to into $4000.  The program
would be run from there.  Because it is RAM, non damaging self modifying
code could still be run (almost all self modifying code is non damaging).
This gives 24k free memory for the program to use.

Another option is to allocate memory into a string, and relocate it to the
beginning of a page, and swap it into $4000.  This requires the user to have
free memory available.  This can be combined with the first technique, to
have a full 16k of memory on the page that will be at $4000.  This would
give 32k of free memory, 40k including the program code.

To achieve another 8k, memory can be allocated to store the system data at
$c000.  This can also be combined with the other techniques.

Usually, 8k of code is enough.  If the rest is data (sprites, maps, etc.),
then there is an easy solution.  Keep the data separate, and compile it into
a string.  At runtime, copy the string data to $8000.  Because the code
needs to access exact addresses in the data, assemble the string first.
Save the symbol table as an include file that is included into the main
program.  Thus the main program has all the addresses in the data.  Zelda 86
uses this technique.  Assembly Studio 8x has build steps which make it easy
to do this.  These features were added due to Zelda 86 requiring them.

Sometimes, you have more than 16k of data, but you only need direct access
to 16k of it at once.  This is the case with Zelda 86.  The sprite data,
text, etc. fits in 16k.  The maps do not.  Because the maps are small (128
bytes), and only one is needed at once (a single screen is displayed, like
the original Zelda, or the Game Boy version), they are simply copied when
needed.

If maps (or other data) are larger, then copying isn't an option.  In this
case, relocation techniques can be used to swap the map data into $4000.
The unreleased Commander Keen uses this technique.  Remember that becase the
ROM relocation table (page D) is located at $4000, when this technique is
used, no ROM calls can be used.  Or if they are, page D must be swapped in
first.  Because the RAM pages are messed up due to the relocation, one must
be careful to call anything that would access the VAT and RAM pages.

There are probably some other techniques that can be used, but this should
cover most of them.  The 86 is very flexible, and is a lot of fun to
program.  Unfortunately, I can't say the same of the 83.

> Doesn't the TI86 also have it's limits, like you need to split huge
> programs, and writeback isn't automatic?





Follow-Ups: References: