This document is to discuss the E2 controller protocols.  I refer
 to these as the ECP  (E2 Control Protocol).  In this protocol, I know of
 seven different operations that can be performed.  There may be additional
 ones, but I do not know of these as of yet.  This ECP is implemented as the
 second level in the entire information transfer methods between devices in 
the TI world.  The first and most basic level is the TIP  (TI Protocol) which
 is the method used for bitwise hardware data transfer between the E2 and 
the calculator. 
	As I communicate with Bryan Rittmeyer conscerning thesse protocols,
 I hope to gather more information about them, along with any additional 
ones that may exist.  I also hope that he will allow the DHOS project to 
use the some of the more basic source code from his own E2 driver.  This 
would benefit us by allowing us to assure that the transfers will be 
successful, at least relatively so.  It would also let us forget about 
writing the lower level hardware transfer routines, which are vital.  If
 he does allow this, we would most certainly give him credit, but if he 
does not, then we will write our own code.  Even if he were to allow us 
to use it, we may rewrite some parts of it to better suit us.
	In any case, I have divided the ECP's 7 operations into 3 basic 
catagories of transfers, or even higher level protocols.  The first is the
 SRP  (Status Request Protocol).  This protocol is essentially useless to
 the OS project, but is included for completeness.  Two of the operations
 in this protocol are the Memory Chip Status Request, which I do not know
 much about, but will ask Bryan about when I contact him.  To perform this
 operation, a $57 byte is sent to the E2, followed by a byte being sent 
from the E2 to the Calculator that is the status code byte.  Here are 
Bryan's comments on this, from the source code:

; Requests status of memory chip -- usually 1000000 on all the	;
; chips I've tested... does NOT follow AT45D041 datasheet :(	;

	The second of the SRP operations is the E2 firmware revision 
code request.  This requests the E2 to send a byte containing it's version
 number to the calculator.  The command byte to send to the E2 is $FF.  
The returned byte is the revision number.  If this number is 4 or less, 
it is an old EuP.  This model does not include the module port, but all 
other operation is the same.  A 5 or higher number signifies the EII model.
  Perhaps different memory sized units will have different revision 
numbers, allowing us to determine in the software how much space we have
 to work with.
	The next major protocol division is the MPCP (Module Port Control
 Protocol).  This allows you to set and read the status of the individual
 module port pins.  And Control the direction of the data flow on them.  
Sending a $22 command, followed by a byte of which bits 0 - 5 contain the
 direction of each pin (1 = out, 0 = in).  I do not fully understand how 
the port uses this information, but will find out when I contact Bryan.  
By sending a $21 to the E2, followed by a byte of which bits 0 -5 are the
 logical states to set each pin to, you output data on the port.  I do not
 know if only bits which the direction field says can be changed are the 
only ones that will be changed.  A $20 to the E2 will cause it to send a 
byte to the calculator that bits 0-5 contain data from the module port.  
As I learn more about the MPCP and the direction command, I will update 
this document.
	The third, and last to my knowledge, protocol division for the 
ECP is the DTP (Data Transfer Protocol).  This is the important one.  It
 is a bit more complex than the others, but still managable.  This 
protocol consists of the command byte which indicates the operation to
 perform (either read or write), and then a header block, which tells 
where to get/send the information and how much of it there will be.  After
 that is the actual data bytes.  In a read operation (command $52), this 
data is sent from the E2 to the calculator.  In the write operation 
(command $82) the data is going from the calculator to the E2.
	Before I go furhter in depth into the header specifications, a 
little E2 organization is in order.  The E2 consists of several pages, 
each 264 bytes long.  There is about 2000 of these pages on a standard 
512K E2 memory module.  Each page must be written independantly of the 
others.  Within each page, any number of bytes, starting at any position
 in the page, can be written or read.  
	Now, for the header information.  The header is 5 bytes long.  
The first two bytes are the page number to perform the operation on.  
These bytes are sent in high/low order.  For example, if HL is the page, 
first H is sent, then L.  Antoher thing about this word is the fact that 
before it is sent, it is shifted left one bit.  To do this, you would 
(using HL again) do an ADD HL, HL opcode.  Then it is sent.  
	After the page number word, a single byte is sent that tells 
the byte within the page to begin on.  Note that you only can start on
 byte 0 to 255.  You cannot begin on 256 to 263.  That is ok.  After 
this byte is two bytes that are the length of the data.  However, the
 length of the data is the sum of the two bytes, and the first byte must
 be as large as possible.  If there is no second byte, it must be a $80.
  For example, as a general rule, if the size of the data is less than 
256, you would put the number of bytes in the first byte, and have the 
second byte be $80.  If you have 256 or more bytes, you would use a $FF
 first, and then however many bytes are left over (number of bytes - $FF
 (255)).

	Now I would like to sum up what our protocol is looking like in 
a layered tree-like structure:

TIP   (TI protocol (hardware level))
 |
 +-ECP  (E2 Control Protocol)
    | 
    +-SRP   (Status Request Protocol)
    |
    +-MPCP   (Module Port Control Protocol)
    |
    +-DTP     (Data Transmission Protocol)


Eventually, when the networking drivers for mbus/i2c combatibility are 
completed, the protocol tree might look like the following:


TIP   (TI protocol (hardware level))
 |
 +-ECP  (E2 Control Protocol)
 |  | 
 |  +-SRP   (Status Request Protocol)
 |  |
 |  +-MPCP   (Module Port Control Protocol)
 |     |
 |     +-Tri-Mapped Channels
 |              |
 |              +-TIP  (for communications with other TI calcs)
 |              |
 |              +-I2C  (for I2C communications)
 |		   |
 |                 +-MBUS  (for MBUS network compatibility)
 |
 +-DTP  (Data Transmission Protocol)



Again,  This document is subject to change as I learn more from Bryan.

Thank you, and please comment on this document to a list, or to me directly.

Jonathan Kaus
Kaus@cybrzn.com