TI-83+ Link Protocol Guide v1.1 - File formats
The TI-83+ Graph Link software stores variables in several types of files. Single variables are stored in files that have an extension that corresponds with their type. Groups of variables are stored in files with the extension ".8Xg". However, all of these file types have a common format.
The different file types and contents that the TI-83+ Graph Link software can read and write are shown below.
Extension | Description |
---|---|
.8Xc |
TI-83+ complex number |
.8Xd |
TI-83+ GDB (function, polar, parametric or sequence) |
.8Xg |
Multiple TI-83+ variables of varying types (group) |
.8Xgrp
|
TiLP only: TI83+ 'group' variable |
.8Xi |
TI-83+ picture (image) |
.8Xk |
TI-83+ FLASH application |
.8Xl |
TI-83+ list |
.8Xm |
TI-83+ matrix |
.8Xn |
TI-83+ real number |
.8Xp |
TI-83+ program |
.8Xq |
TI-83+ FLASH certificate |
.8Xs |
TI-83+ string |
.8Xt |
TI-83+ table setup |
.8Xu |
TI-83+ FLASH Operating System |
.8Xv |
TI-83+ Application Variable |
.8Xw |
TI-83+ window settings (Window or RclWindow) |
.8Xy |
TI-83+ Y-Variable (equation) |
.8Xz |
TI-83+ zoom (saved window settings) |
The TI-83+ variable file format has two parts: a header and several variable entries.
The header appears at the beginning of the file and takes the
following
format:
Note - All 2-byte integers are stored little-endian Intel-style
(least
significant byte first).
Offset | Length | Description |
---|---|---|
0 | 8 bytes | 8-character signature. The signature is always "**TI83F*". |
8 | 3 bytes | 3-byte further signature. These three bytes always contain {1Ah, 0Ah, 00h} = {26, 10, 0} |
11 (Bh) | 42 (2Ah) bytes | Comment. The comment is either zero-terminated or padded on the right with space characters. |
53 (35h) | 2 bytes | Length, in bytes, of the data section of the file. This number should be 57 (39h) bytes less than the file size. |
55 (37h) | n bytes | Data section - consists of a number of variable entries (described below). |
55 (37h)+n | 2 bytes | File checksum. This is the lower 16 bits of the sum of all bytes in the data section. |
Each variable entry follows this format:
Offset | Length | Description |
---|---|---|
0 | 2 bytes | Always has a value of 11 or 13 (Bh or Dh). |
2 | 2 bytes | Length, in bytes, of the variable data. |
4 | 1 byte | variable type ID byte (see variable type ID's) |
5 | 8 bytes | Variable name, padded with NULL characters (0h) on the right. |
13 (Dh) | 1 byte | Version. Usually set to 0
(present if first bytes are Dh). |
14 (Eh) | 1 byte | Flag. Set to 80h if variable is archived, 00h else (present if first bytes are Dh). |
15 (Fh) | 2 bytes | Length, in bytes, of the variable data (This is a copy of the value in offset 2) |
17 (11h) | n bytes | Variable data. Click here for variable data formats. |
The TI-Graph Link software for the TI-83 does not have backup capability. However, the calculator itself does. The following format is not readable by TI's software.
Here is the format for backup files that FastLink & TiLP uses (it's the same format than the TI82/83 one):
Offset | Length | Description |
---|---|---|
0 | 8 bytes | 8-character signature. The signature is always "**TI83F*". |
8 | 3 bytes | 3-byte further signature. These three bytes always contain {1Ah, 0Ah, 00h} = {26, 10, 0} |
11 (Bh) | 42 (2Ah) bytes | Comment. The comment is either zero-terminated or padded on the right with space characters. |
53 (35h) | 2 bytes | Length, in bytes, of the backup header and the data sections. This number should be 17 (11h) bytes more than the sum of the lengths of the three data sections as reported in the backup header. |
55 (37h) | 11 bytes | The backup header (format described below). |
66 (42h) | 2 bytes | Length, in bytes, of the first data section. |
68 (44h) | x bytes | First data section. |
68 (44h)+x | 2 bytes | Length, in bytes, of the second data section |
70 (46h)+x | y bytes | Second data section. |
70 (46h)+x+y | 2 bytes | Length, in bytes, of the third data section |
72 (48h)+x+y | z bytes | Third data section |
72 (48h)+x+y+z | 2 bytes | Checksum. This is the lower 16 bits of the sum of all bytes from offset 55 (37h). |
The backup header has this format:
Offset | Length | Description |
---|---|---|
0 | 2 bytes | Offset to data length: Always has a value of 9. |
2 | 2 bytes | Length, in bytes, of the first data section. |
4 | 1 byte | Type ID: Always has a value of 19 (13h). |
5 | 2 bytes | Length, in bytes, of the second data section. |
7 | 2 bytes | Length, in bytes, of the third data section. |
9 | 2 bytes | Memory address |
A FLASH file usually contains between 1 and 3 headers with data and
the header has
the same format than the TI89/92+ one.
Headers can contains : license or data (app/os/certificate).
The header takes the following format :
Note - All 2-byte and 4-byte integers are stored little-endian
Intel-style (least significant byte first).
Offset | Length | Description |
---|---|---|
0 | 8 bytes | 8-character signature. The signature is always "**TIFL**". |
8 | 2 bytes | Revision number (BCD coded): major.minor. |
9 | 1 byte | Flags (usually set to 00h). |
10 (Ah) | 1 byte | Object type (00h). |
12 (Ch) | 4 bytes | Binary-Coded-Decimal date such as {dd, mm, yy, yy} for 'dd/mm/yyyy'. |
16 (10h) | 1 bytes | Name length |
17 (11h) | 8 bytes | Application name or 'basecode' for OS (zero terminated unless 8 characters long). |
25 (19h) | 23 bytes | Filler (unused, set to 00h). |
48 (30h) | 1 byte | Device type (TI73: 74h, TI83+: 73h, TI89: 98h, TI92+: 88h) |
49 (31h) | 1 byte | Data type (os: 23h, application: 24h, certificate: 25h, license: 3Eh) |
50 (32H) | 24 bytes | Filler (unused, set to 00h). |
74 (4Ah) | 4 bytes | Size of data in bytes. Beware:
this is size of intelhexa data (in characters), not of pure data (in
bytes). |
78 (4Eh) | n bytes | Data. |
78 (4Eh)+n | 2 bytes | Checksum. This is the lower 16 bits of the sum of all bytes in the variable data. |
By roms: the part below is preliminary, I will have to finish
it...
You are strongly encouraged to take a look at the TI's "TI83+ SDK
guide" (sdk83pguide.pdf) and more particularly the "Hardware Layer"
section.
1) Data encoding:
Data are formatted in a particular way. TI used the 'INTEL Intellec
8/MDS' format, a very popular format used for transferring data to
EPROM programmers, CPU emulators, ...
Format:
+--Number of bytes
| +--Address (called 'page address' or 'address field' in this doc)
| | +--Block type (00: data, 01: end)
| | | +--Data
| | | | +-- Checksum
| | | | |
: 10 0000 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 CR/LF
: 10 0010 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 CR/LF
: 10 0020 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF E0 CR/LF
: 00 0000 01 FF -> end block
Meaning:
- TI specific block, contains the FLASH page number (1D here): :02 0000 02 001D FC
- data block (page address = 4000h): :20 4000 00 80 0F 00 00 6C 24
80
12 01 04 80 21 01 80 31 01 80 48 43 42 4C 45 78 70 6D 74 80 81 02 80 90
03 D9
- end block: :00 0000 01 FF
Each block has an address field. Depending on the operation (App or Os) and the part, the address of the data block can be used as is (absolute addressing without using offset) or not (relative addressing, relocated at @4000h if offset=4000h for instance). Page number is sent as encoded in the specific block.
2) Parts
An app has one part. The part is made up of several blocks: specific blocks, data blocks and an end block. Data are sent with page adress 4000h aka @4000h (offset=0). The page number is specified in the specific block. The flag always equals 80h (FLASH).
An OS has several parts:
- the first part is the OS header information. It is made up of a data
and an end block. It is sent with page address 0000h aka @0000h
(offset=0),
page number 0000h.
- the second part is the data. It is made up of a specific, a data and
an end block. It is sent with page address 0000h modulo 4000h (offset
4000h) aka @4000h.
- and the third part is the digital signature of the data block. It is
made up of a data and an end block. It is sent with page address 0000h
aka @0000h (offset=0), page number 0000h. About flag, the first and
third
block have Fl=80 (FLASH), the second one has always Fl=00 (RAM).
Data are sent to calcs block per block. A incomplete block may need
to
be filled.
It will be filled with:
- 0x00 for App,
- 0xff for OS.