------------------------------------------------------------------------------ TI-92 L I N K I N T E R F A C E P R O T O C O L As unraveled by: Ben Eater (themouse@wam.umd.edu) George Nachman (ltduck@wam.umd.edu) ------------------------------------------------------------------------------ 1. PACKET INFORMATION All information is sent in packets. The format of a packet is as follows: 0 1 byte deviceType 1 1 byte command 2 1 word dataLength 4 n bytes data 4+n 1 word checksum (if dataLength > 0, omitted otherwise) Each packet identifies what device is sending the packet. Since the protocol and data formats are slightly different for each calculator, it is important for the protocol to identify which calculator we are dealing with. Valid values for deviceType are: Value Meaning 0x82 TI-82 -> computer 0x85 TI-85 -> computer 0x89 TI-92 -> computer 0x02 computer -> TI-82 0x05 computer -> TI-85 0x09 computer -> TI-92 others CBL? (don't have one to play with) Note: This document only discusses issues related to the TI-92. Other devices are similar, but some experimentation may be required. Next, the packet identifies its purpose using the command. This byte is used to tell the receiving device what sort of data the packet contains. Valid values for command are: Value Meaning 0x06 Variable header - The device wants to send a variable. This packet will contain information about the forthcoming variable. 0x09 Request for data - The device is requesting data as described by a variable header just sent to it. This packet contains no data. 0x15 Data - This packet contains variable data as described in previous variable header or a screen dump. 0x56 Acknowledgment - Indicates successful reception of information. This packet contains no data. 0x6D Request screen dump - Computer would like calculator to send it a screen dump. This packet contains no data. 0x92 End of transmission - Sending device has no more variables to send. This packet contains no data. Checksums are calculated by summing of all of the bytes in the data section of the packet and anding it with 0xffff. 2. SENDING VARIABLES FROM CALCULATOR TO COMPUTER To initiate sending the variable, the calculator sends a variable header. The format of a variable header is as follows: 0 word variableLength 2 byte unknown (always 0 as far as I can tell) 3 byte unknown (always 0 as far as I can tell) 4 byte varType 5 byte nameLength 6 n bytes name variableLength is the length of the variable (as shown in the var-link screen on the TI-92). The unknown bytes always seem to be 0 and changing them doesn't appear to have any effect. More information on this is appreciated. varType describes the type of variable being sent and can be any of the following: Value Meaning 0x0a DATA Data 0x00 EXPR Expression (includes numeric values) 0x0e FIG Geometry session 0x13 FUNC Function 0x0d GDB Graph database 0x04 LIST List 0x14 MAC Macro for a geometry session 0x06 MAT Matrix 0x10 PIC Picture of a graph 0x12 PRGM Program 0x0c STR String 0x0b TEXT Text editor session The name length is the length of the variable name in bytes and name is the variable name. The calculator sends the variable header then waits for an ACK from the computer. Then the calculator waits for the computer to request data. We have never managed to get the calculator to do anything but request data here. We would like to think that the calculator can report out of memory errors, skipped variables, etc, but it doesn't seem to. Any other information about this is appreciated. After the computer requests data, the calculator sends an ACK followed by the data. The data is sent in the following format: 0 byte unknown 1 byte unknown 2 byte unknown 3 byte unknown 4 byte high byte of variable size (the entire size is also contained in the variable header) 5 n byte variable data (as it's stored in the calculator) After sending the data, the calculator waits for the computer to send an ACK. If the calculator has more variables to send, it sends another variable header and repeats the above process. If it's done sending variables, it sends an end of transmission packet. Summary (> is sender, < is receiver): > Variable header < ACK < Request for data > ACK > Data < ACK > EOT or another variable header 3. DOWNLOADING SCREEN DUMPS FROM THE CALCULATOR If the computer wants to request a screen dump from the calculator, it sends it a request screen dump packet (0x6d). This packet contains no data. The calculator will then send back an ACK followed by a data packet containing 3840 bytes of screen memory. The computer should then send an ack. 4. *.92@ FILE FORMAT The .92@ file format was introduced by version 1.0 of link92xp. This is NOT a standard file format from TI, but was based on their previous file formats for the TI-85. The reason this file format was introduced was because TI was delayed in their release of the link92 software for the IBM-PC and we were prompted to write our own. Later versions of link92xp will hopefully support TI's file format when it is released. The format of the .92@ is as follows: File header: 0 8 bytes "**TI92**" Signature 8 3 bytes "\032\014\000" EOF and more signature 11 42 bytes Description of file contents (not null terminated) 53 1 word Bytes left in file x bytes Variable entries (see below) x+53 1 word Checksum for variable Variable entries: 0 1 word Bytes from next byte to end of file 2 1 word Data length 4 1 byte Variable type 5 1 byte Name length 6 n bytes Name n+6 1 word Length of variable n+8 m bytes Variable data 5. OTHER INTERESTING THINGS WE NOTICED If you enter the self test menu (, /diamond/+<(>, from the home screen), when you return to the home screen, the results of anything done in the home screen are sent out through the link port. Each transmission does NOT include a packet header or checksum, but is terminated with 0xff. Also, if the high byte of the data length in the variable header is different from the high byte sent with the data, the calculator will behave strangly. It seems that it can allocate more memory than actually needed for the variable which means that accessing the variable can let you access other parts of RAM beyond the original boundaries of the variable. You can even send such a malformed variable back to the computer and get other bits of RAM with it. You will also find that your calculator will crash a whole lot while doing this. 6. LOW LEVEL (HARDWARE) PROTOCOL OF LINK Here's some code that does it: /* * Sends a byte to the calculator */ int put92(char data) { int bit; for (bit=0; bit<8; bit++) { if (bit==1) tx(1); if (data&1) { outportb(lpt_out, 2); while (inportb(lpt_in)&0x10); outportb(lpt_out, 3); while ((inportb(lpt_in)&0x10)==0x00); } else { outportb(lpt_out, 1); while (inportb(lpt_in)&0x20); outportb(lpt_out, 3); while ((inportb(lpt_in)&0x20)==0x00); } data>>=1; // may need 10us delay here } } /* * Reads a byte from the calculator */ unsigned char get92(void) { int bit; unsigned char data=0, v; for (bit=0; bit<8; bit++) { while ((v=inportb(lpt_in)&0x30) == 0x30); if (v==0x10) { data=(data>>1)|0x80; outportb(lpt_out, 1); while ((inportb(lpt_in)&0x20)==0x00); outportb(lpt_out, 3); } else { data=data>>1; outportb(lpt_out, 2); while ((inportb(lpt_in)&0x10)==0x00); outportb(lpt_out, 3); } // may need 10us delay here } return data; } For information on hardware, look at http://www.inf.tu-dresden.de/~aw4/ti85 which contains instructions for building the parallel link cable which works with the above code.