(Turn on word wrap if you don't have it on.)

This file contains notes on the format of TI-89 text files (*.89t files), recorded here while I was figuring it out in preparation for writing FromTxt, and so on. I checked online later to confirm what I'd determined, and that's where I found out how the checksum was done (I'd already figured out it was a checksum, but hadn't tried to figure out how to calculate it yet), and what the two bytes at 0x58 were (cursor position). I'm going to refer to it a few times in this document, and its URL is http://www3.sympatico.ca/michel.brodeur/michel.brodeur/ .

Notes:
<NN NN NN NN> indicates hex bytes, each NN being one byte.
If not inside <>, anything in hex is written 0xNN. 
Strings are enclosed in ""s. If you see punctuation at the end of a string, inside the ""s, it is part of the string. If I want to have punctuation there but it's not part of a string, I put it outside the string, even though that isn't proper english. (For quotes and such I would put it inside the "" as per proper english, but in the interests of clarity I don't with literal strings and such)
Variable names may have a $ prepended to their name to make it clear that they're variables. They may simply represent concepts, by the way, such as $filesize, which is the size of the file (But that should be obvious from the name, heh).
Strings of a fixed length are represented as char[LEN] VARNAME, with LEN being the length of the character-array, and VARNAME being whatever we're calling the string - something that's representative of its meaning, hopefully. In all fixed-length strings, if the string data would not be as long as the character-array, then the empty spots in the array, to the right of the string data (which always starts at the first index of the array), will all be filled with 0x00s (Also called NULLs).

0x00: "**TI89**" or "**TI92P*" (FromTxt writes "**TI89**", so does TI Connect, etc. The old TI-89 Graphlink program writes "**TI92P*" on 89t files you create in the graphlink program itself)
0x08: <01 00> (Never changes)
0x0a: char[8] folderName.
0x12: char[40] comment. Default: "TextObject file $date, $time" with $date="MM/DD/YY" and $time="HH:mm" - No AM or PM, so I'm guessing HH is in 24-hour time, though I haven't looked closely at a bunch of .89t files transferred at different times to see if that's correct. Replace MM, DD, YY, HH, and mm with the month, day, year, hour, and minute, respectively. All are two digits long with a leading 0 if < 10. To be clear, the year is definitely two digits long, which makes me frown, but oh well. It's not terribly important, it's only a comment which nobody ever reads.

FromTxt writes "Text file converted by FromTxt". I wanted to write "TI-89 Text File (.89t) converted by FromTxt", but we only have 40 characters to work with!

0x3a: <01 00 52 00 00 00> (this means 'one variable, with its data starting at position 0x52' (see online doc I referred to earlier))
0x40: char[8] fileName.
0x48: <0B> (Type ID for text files)
0x49: Flag. 0x00 is normal, 0x02 is archived, and 0x01 is probably read-only. I don't have any read-only files on my TI-89 ATM, so I'm guessing about read-only (It isn't relevant to ToTxt or FromTxt), but archived files from my TI-89 do have 0x02; This contradicts the documentation I found online, though, which says that archived should be 0x03. ToTxt ignores this, and FromTxt always writes 0x00. Of course, if you have a locked or archived file on your TI-89 and try to send a copy from the computer to the TI-89, it won't work, because the locked/archived one is in the way and has to be unlocked, unarchived, or deleted first.
0x4a: <00 00> for TI89, <FF 00> if the old TI-89 Graphlink software made the file (it would also write "**TI89P*" earlier).
0x4c: The file-size, four bytes long, written with the lowest byte first. For clarity, this is written in FromTxt with four fputc calls instead of one fwrite call. Well, the fwrite call was written, but I commented it out and replaced it while hunting a bug during testing. For some reason, the MS Platform SDK docs I downloaded don't include any sort of reference for fwrite, fputc, etc, and I can never remember which of the two size parameters is the # of variables and which is the # of bytes per variable, so it's clearer (for me) just to manually do the byte-by-byte writing.
0x50: <A5 5A> (This is a signature, and never changes.)
0x52: <00 00 00 00>
0x56: <HH LL>, where HH is the high byte and LL the low byte of $textsize (Read on for the definition of $textsize). I wonder why this is in HH LL order - The filesize was in LL HH order, as is the '01 00 52 00 00 00' part. If you're curious why I'm calling these HH LL or LL HH order, instead of little-endian or big-endian, it's because I can never remember which order is little-endian or big-endian. There are two ends, you know. You'd think I could remember which was which or at least which end was the end the name referred to, but nooooo, my memory is too full of useless stuff like how to say & write 1999 in french, phone numbers I had years and years ago, old PIN numbers that I haven't needed in years, old addresses, zip codes, area codes, practically every password I've had for the past decade (Most of them 8 or more letters of random gibberish), and on and on...
0x58: <00 01> (actually, this is the cursor position, 00 01 being the very start of the file, apparently)
0x5a: <20> (This is the start of the first line, and this COULD be 0x0c, 0x43, or 0x50, if the first line was a special line (command, etc))
0x5b: Start of text

$textsize is the filesize minus 0x5a (That's the easy way to calculate it).

At the very end of the text, write 00 E0 $checksum, where $checksum is two bytes, in LL HH order.
$checksum is:
	 "Checksum. This is the lower 16 bits of the sum of all bytes in the variable data." to quote that online reference. And indeed, that is correct, and works. More specifically, $checksum should be the sum of every byte written starting at 0x52 and continuing to the end, EXCLUDING the checksum itself written at the very end, but you should only write the lowest two bytes of $checksum. .... However, it seems that you CAN write all four bytes if you really want to, and the TI-89 disregards the extra. FromTxt doesn't write all four, mind you, because that would be a (tiny) waste of space. But I had it doing that at one point during testing, when the checksums weren't matching the original ones and I wanted to see the entire checksum value, and was slightly surprised when I noticed that the TI-89 didn't complain when I sent one of the files with the four-byte checksums over (and opened it in the TI-89 text editor to see if it worked). It worked just fine. (There wasn't a problem after all, I had just forgotten that ToTxt had changed some symbols when it made the .txt files)

Some more notes about the text which gets written starting at 0x5b:

Every line of text (usually) begins with 0x20, and the start of a new line (where you have a : displayed on the TI-89) is marked with 0x0d. There is pretty much always a 0x20 after each 0x0d, mind you. (Technically 0x0d means 'end-of-line,' which is why the first line doesn't start with 0x0d)

According to that online reference, 0x0d marks the end of a line, and the next character marks the type of the next line, with 0x20 being a normal line. To quote: "Line type: 0Ch=page break, 20h=normal, 43h=Command, 50h=PrintObj". 0x0C is a non-normal character, but 0x43 and 0x50 are 'C' and 'P' respectively, so I have made the 89t->txt code change 0x43 to 0x0e and 0x50 to 0x0f *IF* those characters are encountered immediately after a 0x0d, and the 89t<-txt routines translate 0x0e and 0x0f back to 0x43 and 0x50 respectively *IF* they are encountered immediately after an endline. Note that neither 0x0e or 0x0f is something that you would normally use in a text file, either on the TI-89 or a computer, and it's not something either the TI-89 or computer should react to, but 0x0c (the code the TI-89 uses for page-break) actually does mean page-break to some text-editors (But not Notepad).

There are a boatload of characters on the TI-89 that don't translate to anything normal in PC fonts, which would be a PITA for FromTxt if I wanted to make it convert them to something readable on a PC (You could probably just view the files with the font the TI graph-link program installs, that would be easier). As for the few characters that I use which aren't in PC fonts, I made ToTxt convert them into something readable and understandable on a PC, and I don't need them translated back into their original symbols when FromTxt is run, so FromTxt does not attempt to figure out if you've got any text written out which was originally some symbol. It just writes it as text. That's important to remember if you're testing ToTxt and FromTxt to see if the checksums come out the same, 'cause they won't if you had a symbol in there which got changed to something else by ToTxt, heh, but the checksums are still correct for the data, the data's just different. Fun, hmm?

Okay, that's all.

