I got interesting in making TI calc string variables from scratch, since there wasn't any tool to do it, and I have an interesting project that will need it quite a bit.

Needless to say, the obvious thing to do is to find and read specs!
However, as interesting and informative as they are, I have no idea what they mean!

So here's what I know:
- Start with the TI-83+ variable file format
- Use Y variable format, since Str is the same, just not graphable
- Use tokens to fill the string
- A dictionary really helps (I may use the one here: http://tibasicdev.wikidot.com/forum/t-184793/python-ti83-basic-converter)
- BYTES BYTES BYTES

What I want to know:
- I have no idea what the spec is talking about. Start from the beginning (the header/var format) and explain all the number/char/spec frenzy!
- Example how to decode and encode that format
- How does Python handle the bytes, and how can I get it to read/compare/write bytes based on hex/whatever?
- Variable naming - difference between Str(sub 0) and Str0, as represented in the file
- ...and more as I go on into token manipulatioon, Str data, etc.

I'm using http://merthsoft.com/linkguide/ti83+/format.html, http://merthsoft.com/linkguide/ti83+/vars.html#equation, and http://merthsoft.com/linkguide/ti83+/tokens.html as a reference.

This is the best guide for that I've seen so far:

http://www.ticalc.org/archives/files/fileinfo/247/24750.html

It's got everythinng you need to know for the format of a string (or any other var). You can also use a hex editor like XVI32 to open up string vars and see how it works for yourself.

I've made a var writer already, so if you need more help just ask Or anyone else.

1) Create a program with SourceCoder
2) Change a single byte in the result to make it a String instead of a Program.

Yup, it really is that simple. If there's a lot of demand for this, I can easily create an "Export String" button in the SC2.5 editor.

Ahh yes, about that. The links I posted are that guide, just online.
The problem is that I don't get it at all. I can stare at my variable in ghex2 all day, but the only thing I recognize is the header, and maybe the letters.

Any thoughts on what I said? Or are you convinced that you want to make a tool to do it yourself?

I'm going to make a tool to do it myself. I do it because...
1) The project itself requires it to be done locally and quickly (unless you decide to open an API on SC2.5 for random conversions via POST or something of the sort, which you probably won't do)
2) It's a great learning experience!
3) It's another free CLI tool that will be released in the end!

Why don't you have Merthsoft add it to Tokens, then? That's clientside, and also has program exporting.

Last time I checked, Tokens doesn't work on Linux. (And I just checked again - Mono dies.... more like crashes.)

Unless it becomes CLI (with argument handling and the fun), I'd rather write the backbone code myself.

EDIT: I would like to add that all of the conversions MUST be done automatically. I'm not to make an IDE (although I might attempt one with SDL in the future).

Ah, I see. Well, good luck with this, please continue to ask your questions.

Jonimus is working on something to do this, I'm not sure how far it is, though.

Actually so far all my program could do would be change the type byte of a program to be that of a string, I hadn't really looked into the actual creation of vars though that was maybe planed for the future. As for how I'd go about this I would most likely look into using Merth's tokens.dll, or w/e its called (Merth correct me on this), and make a basic C# cli wrapper for the dll in place of the TokenIDE gui.

Yeah, that's basically how I'd do it. I could even make a program really quickly that could do this from the command line, but I figured I'd leave that to the reader as an exercise

Yeah, I'll take the Python route - creating the var creation code from scratch. It's a much more interesting and educational, plus I feel better using my own code. (Not that I mind using libraries and the such, but I love writing code that does interesting things!)

To tell you the truth, I'm really not into C#, so I kinda ditched .NET for my good ol' Python, which is probably why I will never be able to write a CLI wrapper for tokens.dll.

So first question: could someone explain the "The TI-83+ variable file format" (strangely located on this page: http://merthsoft.com/linkguide/ti83+/fformat.html)? I get the first part with the 8 char signature, but lose it... well, everything after it - from "3-byte further signature" to "File checksum".
(For this question, just respond for that first section. I'm not ready for variable entries yet.)

All right, breaking it down:

1. 
   Code:
   
   0        8 bytes        8-character signature. The signature is always "**TI83F*".
   
   
   Pretty clear, just start the file with the ASCII chars "**TI83F*" (it's
   
   
   Code:
   
   0x2A, 0x2A, 0x54, 0x49, 0x38, 0x33, 0x46, 0x2A
   
   
   if you want the hex).
   
   
2. 
   Code:
   
   8        3 bytes        3-byte further signature. These three bytes always contain {1Ah, 0Ah, 00h} = {26, 10, 0}
   
   
   Also pretty simple. Put these three bytes after the "**TI83F*" above.
   
   
3. 
   Code:
   
   11 (Bh)        42 (2Ah) bytes        Comment. The comment is either zero-terminated or padded on the right with space characters.
   
   
   This is the first place where you actually have to choose what you put in. It's just a comment, nothing else. It doesn't appear in the actual program or anything; it's just in the .8xs file, and no one sees it unless they want to see it. You can make it "M4D3 W/ MY V3RY 0WN pr0g!!!1111" if you want. Just remember to always, always pad it (with zeros) so that it's exactly 42 bytes long.
   
   
4. 
   Code:
   
   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.
   
   
   This is where you actually have to start calculating things. These two bytes should hold the size (in little endian) of the entire data section of the file. The easiest way to do this is to set it to 0 first, wait till after you finish the rest of the file, then take the size of the entire file, subtract 57, and stick it here.

That's the first (main) header. I'll post the var header later.

That's only half the header. The other half of the "header" is technically part of a second header, and contains the variable type, archive status, variable name, and variable size.

Yep, here it is.

Now for the variable header:

1. 
   Code:
   
   0        2 bytes        Always has a value of 11 or 13 (Bh or Dh).
   
   
   Just make it $0D, $00. Nice and simple
   
   
2. 
   Code:
   
   2        2 bytes        Length, in bytes, of the variable data.
   
   
   Leave it as zero and calculate it later.
   
   
3. 
   Code:
   
   4        1 byte        variable type ID byte
   
   
   As it says, click the link, find the ID, and store it here.
   
   
4. 
   Code:
   
   5        8 bytes        Variable name, padded with NULL characters (0h) on the right.
   
   
   Exactly as it says. This is easy if it's a program or a named list, but if it's a string, it would be $AA followed by the number of the string (Str1 is $00, Str0 is $09). #4 and #5 are explained pretty well here.
   
   
5. 
   Code:
   
   13 (Dh)        1 byte        Version. Usually set to 0 (present if first bytes are Dh).
   
   
   I usually make this 1. Probably not a good idea, but it works.
   
   
6. 
   Code:
   
   14 (Eh)        1 byte        Flag. Set to 80h if variable is archived, 00h else (present if first bytes are Dh).
   
   
   Exactly as it says.
   
   
7. 
   Code:
   
   15 (Fh)        2 bytes        Length, in bytes, of the variable data. (This is a copy of the value in offset 2)
   
   
   Exact same value as #1 above. So calculate it after you add the actual data.

That would be the variable entry which will happen next.

So that's what the hex is, eh? OK, so I got bored and cracked open a hex editor (it doesn't let you create new files, so "touch test.8Xs" is needed). This is what I got:



Is this right? (Assuming I counted correctly and the total bytes are 66)
EDIT: Gah, you guys are fast! I'll work on the variable side tomorrow.

For the actual variable data:

1. It starts with two bytes holding the size of the rest of the data. This is kinda weird, but basically it's just two less than the value of #2 and #7 above (because these two bytes are counted as part of the data in #2 and #7 (hope this makes sense)).
   
   
2. The rest of it's just token data. It's not the same as an ASCII string, so look here for all the tokens used by the TI-83 Plus family.

Finally, the checksum:

[list=1][*]This is just a sum of all the bytes in the data section. Something like


Code:


should work.

Now that the list is complete, you can go ahead and calculate the four size sections.

First, calculate the file size (len(hexArray)). Subtract 57, and that's the value for #4 in the main header section.

Then calculate the data size for #1 in this post. It's just the number of bytes under #2 in this post.

Then add two and you get the values for #2 and #7 in the variable header.

And that's pretty much it

EDIT: alberthrocks, just noticed your post above. Nope, some of that wouldn't work. Make sure you store the numbers according to how many bytes it should take up.

Thanks for the thourough breakdown of everything, but I'll have to postpone it for tomorrow! I have to now crawl back into my shell and do more studying of AP chem (which isn't an easy class, btw).... You'll have to explain to me about the problem tomorrow!

And just an outline/plan/steps for anyone else interested in my work:
1) Figure out format and understand it
2) Create it from hex
3) Write Python code to create the same stuff
4) Move on to next part of the format!

That's extremely thorough, Deep Thought. I think I need you to hang out here more often and explain things, you're quite good at it.