This document is an additional explaination of the circle diagram i 
posted.  It goes further into depth about each system driver portion and 
parts of the Kernal.  I hope it answers some of your questions.  If you have
 any comments or ideas, please send them to me as soon as possible at 
kaus@cybrzn.com  
	Thank you,
	Jonathan Kaus

	The OS, as stated before, may be broken down into parts, each part
 doing its job and interacting with other parts to create an efficient and
modular program design.  These parts I like to call System Drivers, because
 each part 'drives' a part of the main 'system' (the calculator and e2, along 
with other devices.)

	The first Driver is the one that is common in current assembly 
programs.  It is the Physical Input/Ouput System Driver (PIO).  It is the
 functions that both write to the TI-85's screen and get input from its keyboard.
  Usgard (and ZShell) have functions like  GETKEY  and CLRSCR and 
D_ZM_STR.  These functions are part of the old ROM based PIO system,
 although it was not called that.  That was pretty much the extent of the system. 
 Only a few of the functions discussed further in this document were supported 
by even Usgard, and even some of those were hard to do.  
	The PIO for the new, DH85, OS will have its equivalents of the above 
functions, along with the rest supported by ZShell and Usgard.  It will also 
have some more as standard, such as a line input routine.  But, they will have
 more standardized names for the programmers to use so that they are more 
similar to other programming languages and platforms.  Many of the functions
 will be using the original ROM calls, although redirected through the OS like 
the other shells did.  Some new ones will be barnd new and coded into the OS
 itself.

	The second System Driver to be talked about is the RAM Input/Ouput 
System Driver (RIO).  Its functions are used to manage the RAM on the TI-85.
  It is in charge of all the Arena setups (blocks of memory in ram).  It has 
functions to allocate and deallocate RAM amounts for different purposes and 
put data into them.  It can copy the arenas to each other, or parts of them.
It relocates the code in the program arenas to run correctly at there current 
positions.  This driver also takes care of modifying the ZShell/Usgard programs
 to be usable by the new OS.  It also calls programs at arenas and calls library 
functions.  It modifies the Usgard programs that use VAR functions to be emulated
 in an arena, so we dont have to face the problems associated with deletion and 
resizing variables.  It has a small TSR section that every so often rearanges the
 arenas that can be moved  so that they are more efficient.  This can also be forced.

	Another important System Driver is the Communications Input/Ouput System
 Driver (CIO).  This driver allows the OS to exist, because this is what communicates
 directly with the E2.  It also communicates with any connected networks or additional
 calculators.  It has a TSR section that automatically recieves data and handles requests
 for data.  It has control over the E2's module port for Enhanced Communications.  With 
lib support, it can allow for functions like: Send packet on network, recieve packet on 
network.  We could have an ethernet style network  that sends out packets and have 
TSR's on the connected calcs pick up the packet, check it for data sent to its calc, and
 send it along if not.

	The fourth System Driver is the File Input/Ouput System Driver (FIO).  This driver
 is the intermediate between the CIO and the RIO.  It takes the data from the E2 and gets 
it ready to be sent into an arena in RAM.  Or, the other way around, or even directs the 
sending to other devices or networks.

I hope this document has cleared up some more of everyone's questions, and... dare i
 hope...  Gives you some ideas and insights.