+++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + DHOS EII Control Protocol Specification + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + DHS 2 - version 3 - released 10/20/98 + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + By: Jonathan Kaus + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Section 1 ========= This section will overview and introduce the material presented in the specification. Section 1.1 ----------- This document describes the bytewise protocol between the calculator and the ECP (E2 Control Protocol). Several operations can be performed in this protocol, and herein we will define them all. Section 1.2 ----------- The ECP is the second "layer", if you will, in inter-device communications. In this case, it is soley for the E2 <-> calc communications. No other devices use it. The 1st layer, the hardware, bitwise, layer, is the TIP (TI-protocol). This determines how each of the control lines are changed and used to transfer a byte over the link port on the TI calculators. Section 1.3 ----------- Bryan Rittmeyer, the author of the E2 Usgard driver, as well as the designer of the EII itself, has replied to my contact, and we are going to be allowed the use of the basic TIP and ECP routines from his driver, which we may modify or shrink. Of course, we must give him credit for the work he has done. Section 2 ========= This section will actually specify the protocols of the ECP. The ECP can be broken down into several sections, another layer on the protocol pile :) Section 2.1 ----------- Basicly, the ECP consists of sending a command byte to the E2, and then either sending some control data, or recieving information, or transmitting data. For instance, to use a SRP (described in the next subsection), you would do this sequence: sendbyte(SRPcommand) recvbyte(statusbyte) Section 2.2 ----------- The first 3rd layer protocol to be defined in this text is the SRP [Status Request Protocol]. This protocol contains 3 commands. Section 2.2.1: The Memory Chip Status Request operation, which gets the status of the memory chip. I do not know what this byte value means, because I don't have an E2 to test it on yet. sendbyte($57) ;the command for this operation recvbyte(statusbyte) Section 2.2.2: The E2 firmware revision request operation gets a byte value which tells more about the E2 that is being used. Anything 4 or less is a EuP, which operates the same, but does not have a module port. A 5 or above is the more modern EII, which does include module port support. A 6 is the one which is being sold now. I need to contact Bryan again concerning this for sure, but my E2 emulation project will also have a E2 version number for itself. Perhaps FF or such. sendbyte($FF) ;this is the command for this operation recvbyte(revisionnumber) Section 2.2.3: The Copyright notice string is another SRP, but one which I do not know how many bytes it returns. I will need to expirament with this, but I can tell you what I know. sendbyte('C') ; this is the command for the copyright recvbyte(copyrightstringbyte1) ;i dont know the length Section 2.3 ----------- The next major protocol on layer 3 is the MPCP (Module Port Control Protocol). This allows us to set and read the status of the individual port pins. You can additionally control the direction of the data flow on the pins. I am not sure how to use the direction control and won't until I get my E2 up and running. However, until I do get to test this, I am going to make some assumptions: Section 2.3.1: First, to send a bit over the module port, first set the bit in the data register. Then set the direction for that pin to out. Then, after the duration required that you must hold that logic level on the line, you reset the direction for that pin to input. This will allow the other calculators to control the bus (if that is what we use it for) when this calculator does not need it. Section 2.3.2: The First of the MPCP operations is the direction control operation. This sends a byte to the Direction control register of the E2 controller. Only the lower 6 bits of this byte do anything. They directly correspond to the module port data pins. A 1 in the 0th bit will set the pin's direction to out. A 0 in this place will set the pin's direction to in. sendbyte($22) ;the direction control command sendbyte(directionbyte) Section 2.3.3: Next, the port's data register commands are important. The write command puts a values into this register to output to the data lines. Only bits 0-5 are important in this byte also. sendbyte($21) ;write data to mod port command sendbyte(databyte) ;byte to output Section 2.3.4: The Port Read command reads the values of the pins of the module port. Only bits 0-5 hold valid data. sendbyte($20) ;read data to mod port command recvbyte(databyte) Section 2.4 ----------- Finally, the most important part of the ECP is the DTP, or Data Transfer Protocol. This sends and recives data to pages on the E2 memory chip. Now, the procedure for this is a bit odd to understand, but makes a little sense :) Also, you must remember how the data goes from the calculator to the E2 memory chip and to the correct page to stop yourself inadvertantly from screwing up. Section 2.4.1: On a read operation, data is transfered inside the E2 mem chip from the source page to the pagebuffer section. Now, this transfers the _entire_ page to the buffer, even if you only told it to get part of the page. Then, the data that you actually requested is sent from the pagebuffer over the link port to the calculator. That is fine. The wierd part is on a write operation. When this occurs, you write the sections of data you want to onto the pagebuffer. The old contents are not erased, and so if you begin writting at position 5, bytes 0-4 still have the old data leftover. So, when all the data has been written, the _entire_ pagebuffer goes to the page you want it at. The _entire_ page is replaced with the contents of the pagebuffer!!!! This means that thos bytes 0-4 will be replaced with the contents of the pagebuffer, which were put there either by the last read or write operation. So, if you meant to save some data int he page by beginning after it, you will actually write over it with meaningless data! And so, as a general rule, only read an entire page at a time, and only write one page at a time. So, The OS will provide the setup of on calc page buffers, so that you can read an entire page, modify what you want, and then write it all back. This will make the above screwup nearly impossible to make. Section 2.4.2: First of all, operations with the DTP use a specific header format, as follows: sendbyte($52) ;the read command byte, $82=write page ;now you shift the page number word left one bit ; if hl contains the page number ( about 2000 or so per ; e2): add hl,hl sendbyte(highpagebyte) ; aka: H sendbyte(lowpagebyte) ;aka: L ;then you send the page offset to begin at. remember, ; it is a bad idea to start at other than 00, but it can ; be done. you cannot start at bytes 256-264 sendbyte(offset); ;we will be using $00 to get the ; whole thing ;next is the size of the data you are going to transfer ; the first byte must be full before you start the next ; byte. if there will be no second byte, you send an $80 ; instead sendbyte(firstsizepart) ; for all 264 bytes, use $ff sendbyte(secondsizepart) ; for all bytes, use $09 ; if we wnated only 255 or less ; we would use $ff, then $80 After this header section, the actually data transfer begins. Section 2.4.3: On a read operation, the command byte is $52. After the header is transfered, you then recieve as many bytes as you specified. Section 2.4.4: On a write operation, the command byte is $82. After the header is transfered, you send as many bytes as you specified. Section 3 ========= Now I would like to sum up our protocols and layers, as well as possible later expansions. I will do this in a tree-like format. Section 3.1 ----------- This is what the tree looks like currently, after the protocols specified in this document: TIP (TI- protocol, at the hardware level) | ECP (E2 control protocol, at the 2nd level) | +---------+-------+ SRP MPCP DTP (3rd level. E2 operations) Status Module Data Request Port Transmission Protocol Control Protocol Protocol Section 3.2 ----------- After we get the networking drivers for i2c/mbus compatibility completed, the protocol tree might look like this: TIP (TI- protocol, at the hardware level) | ECP (E2 control protocol, at the 2nd level) | +---------+-------+ | | | SRP MPCP DTP (3rd level. E2 operations) Status Module Data Request Port Transmission Protocol Control Protocol Protocol | Tri-mapped channels (dividing the 6 line mod port into | 3 SDA, 3 SCK lines for serial | communications.) +----+----+ | | TIP I2C (for communication with other calcs (TIP) | or an i2c network (I2C)) MBUS (for MBUS network compatibility)