Draft                                                        P. Marheine
                                                          August 3, 2010


                  TI Serial Data Interchange Protocol

Abstract

   This RFC defines a simple protocol layer (the TI-SDIP) suitable for
   use as a data interchange among TI graphing calculators and
   associated devices in a link- and software-independent manner.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  2
     1.2.  Objectives . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Data formatting  . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Figures  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Byte and bit ordering  . . . . . . . . . . . . . . . . . .  3
     2.3.  Reserved fields  . . . . . . . . . . . . . . . . . . . . .  3
   3.  Protocol description . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Packet format  . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Conversation format  . . . . . . . . . . . . . . . . . . .  5
   4.  Simple List  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Figures  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Subsections and Tables . . . . . . . . . . . . . . . . . . . .  6
     6.1.  A Subsection . . . . . . . . . . . . . . . . . . . . . . .  6
     6.2.  Tables . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   7.  More about Lists . . . . . . . . . . . . . . . . . . . . . . .  7
     7.1.  Numbering Lists across Lists and Sections  . . . . . . . .  7
     7.2.  Where the List Numbering Continues . . . . . . . . . . . .  8
   8.  Example of Code or MIB Module To Be Extracted  . . . . . . . .  9
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   10. Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     11.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10











Marheine                                                        [Page 1]

                   TI Serial Data Interchange Protocol       August 2010


1.  Introduction

   The graphing calculators produced by Texas Instruments (TI) are very
   flexible bits of commodity hardware, well-suited to customization.
   However, the proprietary serial link protocol used by the devices is
   needlessly complex for most purposes as well as being implemented in
   an incredubly arcane manner despite the valiant reverse-engineering
   efforts of several developers, resulting in such documents as the TI
   Link Protocol & File Format Guide [TILPFFG], which, while useful,
   remains a pain to implement.

   For the sanity of developers targeting such platforms, this document
   specifies a data interchange protocol suitable for use on all TI
   calculators and associated peripherals or devices.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.2.  Objectives

   The designer has sought to meet certain objectives in the design of
   the protocol, as outlined in this section.

   Ease of implementation
         The proposal seeks to replace a proprietary and difficult-to-
         implement protocol, so ease of implementation is very much
         desirable.

   Robustness
         Linking between devices is usually done across noisy links and
         in the presence of potentially careless users, so the protocol
         should be able to handle data errors and unexpected loss of
         connection.

   Speed
         Data transfers are typically done in the presence of users and
         in an interactive manner, so a reasonably high effective data
         rate is desired in order to impose less upon the user's time.
         As this document makes no claims about the link layer in use,
         the specification should seek only to minimize protocol
         overhead.







Marheine                                                        [Page 2]

                   TI Serial Data Interchange Protocol       August 2010


2.  Data formatting

   The TI-SDIP is byte-oriented, and expects to receive data from the
   link layer in 8-bit bytes.  This section outlines the terminology
   used to refer to bytes and subdivisions thereof.

2.1.  Figures

   In illustrations, a '+' is used to delimit individual bits of a
   field, while '|' delimits fields, and '][' denotes a byte boundary.

2.2.  Byte and bit ordering

   Byte values are represented in this specification as groupings of 8
   bits, numbered right to left from 0 to 7.  When bit groupings are
   used to represent integers, bit 0 is the least significant bit, with
   significance increasing in order with bit number.

                          Byte 1            Byte 2
                     +-+-+-+-+-+-+-+-][-+-+-+-+-+-+-+-+
                     |7 6 5 4 3 2 1 0][7 6 5 4 3 2 1 0|
                     |_______________][_______________|

                   Figure 1: Bit numbering within bytes

   When multi-byte integers are used, the value is transmitted LSB-
   first, followed by additional bytes in order of increasing
   significance.

                      Multi-byte integer transmission

                                 Time -->
                           +----+----+----+----+
                           | 78 | 56 | 34 | 12 |
                           |____|____|____|____|

                       Figure 2: Sending 0x12345678

2.3.  Reserved fields

   Fields marked as reserved MUST be both read and written as zero (all
   bits reset).  Reserved values MUST NOT be written to the
   corresponding field and packets containing such reserved values
   SHOULD be rejected by a receiver.







Marheine                                                        [Page 3]

                   TI Serial Data Interchange Protocol       August 2010


3.  Protocol description

   The protocol is based on the concept of a 'conversation', with only
   one device transmitting at once.  Each conversation consists of a
   packet transferred from the sender followed by a response from the
   receiver, repeating until an implicit end to the conversation.

3.1.  Packet format

                  Header                   Payload         Checksum
    +-+-+-+-+-+-+-+-][-+-+-+-+-+-+-+-][- - - - - - - -][-+-+-+-+-+-+-+-+
    | P | R |       ][               ][               ][               |
    | R | E |  PID  ][     PSIZE     ][      DATA     ][     CKSUM     |
    | V | S |       ][               ][               ][               |
    |___|___|_______][_______________][_ _ _ _ _ _ _ _][_______________|


                          Figure 3: Packet format

   Every packet consists of a short header, payload of up to 255 bytes,
   and checksum, as outlined in Figure 3, with the header containing
   several subfields.  Each field is detailed below.

   PSIZE
         8-bit unsigned value giving the size of the packet's payload,
         in bytes, in the range of 0 to 255.

   DATA
         PSIZE-byte block containing the payload.  Meaning is context-
         specific for conversation and PID.

   CKSUM
         Eight-bit modular checksum of the entire packet up to this
         point.  An example checksum algorithm in Z80 assembly is
         provided in Figure 4.
















Marheine                                                        [Page 4]

                   TI Serial Data Interchange Protocol       August 2010


   00 | cksum_verify:
   01 |    ld a,(hl)               ;PRV, RES, PID
   02 |    inc hl
   03 |    add a,(hl)              ;PSIZE
   04 |    ld b,(hl)
   05 |    inc b                   ;PSIZE+1 iterations
   06 | cksum_verify_loop:
   07 |    inc hl
   08 |    add a,(hl)              ;DATA, CKSUM last iteration
   09 |    djnz packet_cksum_loop
   10 | cksum_verify_done:

         HL points to a buffer containing a complete packet, returns A=0
         if checksum is valid.  To calculate a checksum, write the two's
         complement of A to CKSUM at line 08 in the last iteration
         rather than adding CKSUM to A.

                 Figure 4: Packet checksum verification for Z80

   PRV
         The PRV field indicates which protocol version is in use.
         Compliant implementations MUST write as 0 and reject any
         packets in which PRV is non-zero, as the meaning of this value
         will change in future protocol revisions.

   RES
         Reserved.  See Section 2.3 for details.

   PID
         Packet ID, which identifies the message type contained in the
         packet.  Legal PID symbols and the corresponding values are
         listed in Table 1 and symbol meanings are defined in
         Section 3.2.

                    +-------+------+-------+----------+
                    | Value | Type | Value |   Type   |
                    +-------+------+-------+----------+
                    |  0000 |  ACK |  0100 | Reserved |
                    |  0001 |  NAK |   |   |     |    |
                    |  0010 |  VTN |   v   |     v    |
                    |  0011 |  VTP |  1111 | Reserved |
                    +-------+------+-------+----------+

                            Table 1: PID values

3.2.  Conversation format





Marheine                                                        [Page 5]