Greetings.  This text document was written to explain the way
in which the DH85 OS system will allow the programmers to create huge
programs and games benefitting from the large amounts of memory on the
EII hardware.  This system is not new.  It has been around a long time.
It is often called "overlaying" or "swapping."  It is where a program
is broken up into pieces of code that are related to each other.  These
pieces of code are each in different files on the hard drive (or in our
case, the E2).  Each of these pieces are small enought to fit on the 
real physical RAM on the calculator ( or computer)  in our case, after
taking out the OS room and the room for the VIDEO, its about 24K.  
Each piece does its stuff almsot autonomously.  When a new piece is 
needed, it is loaded into RAM "over"  (overlaying) other code if there
is not enough free RAM.  The old stuff wouldnt be needed right then.
Then the new piece is executed.  True, this loading from the e2 would
cause a slight pause in the program operation, but this is to be 
expected, and if done in the correct places, the user wouldnt notice
a big time lapse.  Then, when a new piece is needed, it is done all
over again.  I have drawn some diagrams to go with this description.
( I hope you liked the text style from the BOOTSTRAP document :)

(1) The OS is in the RAM, in its own arena.  A program is also loaded.
The program's basic controller kernal is the part currently loaded.
This is the part that controls loading each piece into RAM and 
switching control to them. this section would be pretty small, and
wouldnt need to do much.  or it could be the main program, and only
seldom used parts are swapped in. It all depends on the programmer's
choice.
	+--------------+Arena0
	|OS Kernal     |
	+--------------+A1
	|prog frame    |
	+--------------+A2
	|FREEEEE       |
	|FREEEEE       |
	|FREEEEE       |
	|FREEEEE       |
	|FREEEEE       |
	|FREEEEE       |
	|FREEEEE       |
	|FREEEEE       |
	+--------------+

(2)Now, the framwork decides to load and call the first piece, say the 
introduction screen and initial options code for a game.  So, it
allocates an arena and loads up the code file, following by the code
just loaded being executed.
	+--------------+Arena0
	|OS Kernal     |
	+--------------+A1
	|prog frame    |
	+--------------+A2
	|intro piece   |  yeah, its big.  i exagerated.  maybe the
	|              | intro has lots of pics, a movie or two, 
	|              | extensive credits, etc.
	|              |
	+--------------+A3
	|FREEEEE       |
	|FREEEEE       |
	|FREEEEE       |
	+--------------+

(3) The user decides to begin the game, so why does the intro need to 
be in RAM anymore?  the piece transfers control back to the frame, which
removes the intro piece by deallocating it, and loads in the main game 
kernal, and perhaps the first level map.
	+--------------+Arena0
	|OS Kernal     |
	+--------------+A1
	|prog frame    |
	+--------------+A2
	|main game loop|
	+--------------+A3
	|Map # 1       |
	|              |
	+--------------+A4
	|FREEEEE       |
	|FREEEEE       |
	|FREEEEE       |
	+--------------+

(4)  Then a battle begins (pretend its a huge classic style RPG), so
	the battle and AI code is loaded, along with an extensive stat
	lib for the monster, the user stats and weapons code, and cool
	graphics for an aniamted battle.
	+--------------+Arena0
	|OS Kernal     |
	+--------------+A1
	|prog frame    |
	+--------------+A2
	|battle code   |
	+--------------+A3
	|weapon code   |
	+--------------+A4
	|enemy AI      |
	+--------------+A5
	|data area     |
	+--------------+A6
	|FREEEEE       |
	|FREEEEE       |
	+--------------+

(5) Ok, battle is done, the player goes back into the main game (see 4)
	Then, the player wins!!!  (yeah! good job!)
	So, a cool huge game-end movie plays.  its huge, like most of 
	the rest of the mem.
	+--------------+Arena0
	|OS Kernal     |
	+--------------+A1
	|prog frame    |
	+--------------+A2
	|minimovie plyr|
	+--------------+A3
	|moviescreens  |
	|	       |
	|	       |
	|              |
	|              |
	+--------------+

(6) Game over!!  The frame has control again, and maybe it goes back to
	the intro (see 2). or maybe it quits back to the os again.
	+--------------+Arena0
	|OS Kernal     |
	+--------------+A1
	|FREEEEE       |
	|FREEEEE       |
	|FREEEEE       |
	|FREEEEE       |
	|FREEEEE       |
	|FREEEEE       |
	|FREEEEE       |
	|FREEEEE       |
	|FREEEEE       |
	|FREEEEE       |
	+--------------+

OK.  I hope that gives you a rudimentary understanding of the overlay
system for DHOS.  any further questions, email me or something. :)
Note:  A shell probly would be in there too, i just forgot to put it in
in the diagrams.  of course, your defualt shell could be the game....
in which case you need to get some more games!! =)
Also, each piece is relocated on loading to the RAM (see the bootstrap 
text for a little bit of more information on this.)
	Thanks for reading!
	Jonathan Kaus