| Author |
Message |
|
hotdog1234
Advanced Member
Joined: 14 Aug 2009
Posts: 291
|
 Posted: 23 Jan 2010 05:14:26 pm Post subject: |
|
|
| If I want to create an appvar using only a computer, what data does the file need to have before I start filling it with whatever binary data I want to? |
|
| Back to top |
|
|
simplethinker
snjwffl
Active Member
Joined: 25 Jul 2006
Posts: 700
|
| Posted: 23 Jan 2010 07:27:17 pm Post subject: |
|
|
Hot Dog wrote: If I want to create an appvar using only a computer, what data does the file need to have before I start filling it with whatever binary data I want to?
The file header format (if you mean converting a binary file to .8xv) is (this is lifted from my to8x program written in python, so that's why the format looks odd, and also note the \xHH escape is the character with hex value 0xHH):
Code:
**TI83F*\x1A\x0A\x00{comment, 42 bytes}{data length, 2 bytes}
\x0D\x00{vlen, 2 bytes}\x15{name, 8 bytes}\x00{flag}{vlen, 2 bytes}
{data}
{checksum of the second line, 2 bytes}
In the first line, the "\x0D" should be "\x0B" if it's not an 83+
"data length" is the length of the second line plus the length of the data
"vlen" is the length of just the data (third line)
"flag" is \x80 if archived, \x00 else
Note that the brackets designate a field, not actual symbols.
Also note those newlines won't be there.
Last edited by Guest on 23 Jan 2010 07:28:32 pm; edited 1 time in total |
|
| Back to top |
|
|
hotdog1234
Advanced Member
Joined: 14 Aug 2009
Posts: 291
|
| Posted: 23 Jan 2010 07:43:10 pm Post subject: |
|
|
Just what I needed. So then, a couple questions:
1. Does \x0D get used for Ti-84+ app variables as well?
2. Any reason that vlen is used twice?
3. What is checksum? |
|
| Back to top |
|
|
simplethinker
snjwffl
Active Member
Joined: 25 Jul 2006
Posts: 700
|
| Posted: 23 Jan 2010 07:56:13 pm Post subject: |
|
|
Hot Dog wrote: 1. Does \x0D get used for Ti-84+ app variables as well? I believe so. My notes just say "$000D if 83+, else $000B". My information on .8x* formats comes from various documents on ticalc.org and dissecting files with a hex viewer, but since that was months ago I can only comment with what my notes say 
Quote: 2. Any reason that vlen is used twice? I have no idea why, but it's supposed to be there twice.
Quote: 3. What is checksum? You take the sum of all the hex values of the tokens and use just the last two bytes. For example, with the numbers 0xFFFF and 0x9D95, they sum to 0x00019D94, the checksum would be 0x9D94.
Some things I forgot to mention in the first post:
- You need to use tokens for each hex value, and not just the two letters/numbers in the number. I believe chr(0xHH) is what accomplishes this in most languages.
- All of the two-byte fields are in little-endian
- The comment field needs to be padded to 42 bytes with null characters
- The name field needs to be padded to 8 bytes with null characters (for other variables like lists and strings the name format is not this simple)
Last edited by Guest on 23 Jan 2010 07:59:27 pm; edited 1 time in total |
|
| Back to top |
|
|
DrDnar
Member
Joined: 28 Aug 2009
Posts: 116
|
| Posted: 24 Jan 2010 02:38:20 am Post subject: |
|
|
The TI Link Guide has all this information.
The 0Dh is actually the length of the next field in file, which is the variable header. The length appears the first time in the variable header, and the second time as the length field for the actual variable. Since you're generating an appvar, you need to place the length in there a third time, at the start of the variable data, because all appvars start with a length field in the calculator. The 15h is the variable type ID, which is the same as those that appear in the VAT.
You can calculate a checksum by starting with zero, and then, for each byte, adding its numeric value to your checksum variable and taking the sum modulus 65536 (216), which effectively masks out the high bits. If your language supports bitwise logical operations, do AND 0xFFFF. If you use a 16-bit integer and your language isn't bothered by overflow, you don't even have to do that. The checksum is little endian; the bytes are reversed, so that if the checksum is 1234h, they appear in the file as 34h, 12h.
Last edited by Guest on 24 Jan 2010 02:44:21 am; edited 1 time in total |
|
| Back to top |
|
|
Mapar007
Advanced Member
Joined: 04 Oct 2008
Posts: 365
|
| Posted: 24 Jan 2010 04:47:56 am Post subject: |
|
|
| I think the length is actually repeated thrice in the file. 0.0 Weird TI... |
|
| Back to top |
|
|
simplethinker
snjwffl
Active Member
Joined: 25 Jul 2006
Posts: 700
|
| Posted: 24 Jan 2010 11:02:13 am Post subject: |
|
|
Mapar007 wrote: I think the length is actually repeated thrice in the file. 0.0 Weird TI...
For appvars, there are four "length" fields (but only three are distinct), and I suppose technically there's a fifth:
1) What I called "data length", which is the size of the data section in the file (from "\0x0D" to the end of the actual data)
2/3) "vlen", which is the size of the data alone, appears twice
4) The length field inside the appvar data itself, which are the first two bytes
5) The 0x00D or 0x00B, which is the size of the header from {vlen} to {flag} |
|
| Back to top |
|
|
DrDnar
Member
Joined: 28 Aug 2009
Posts: 116
|
| Posted: 24 Jan 2010 12:08:47 pm Post subject: |
|
|
| I find it strange that 8XPs get a checksum, but that variables on-calc don't get a checksum. My calculator's data gets corrupted more often than files on my computer. |
|
| Back to top |
|
|
Mapar007
Advanced Member
Joined: 04 Oct 2008
Posts: 365
|
| Posted: 26 Jan 2010 03:24:38 pm Post subject: |
|
|
I've been thinking that a LOT... 
They must have thought of that too late, and for the sake of compatibility, never implemented it. </guess> |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 26 Jan 2010 09:34:47 pm Post subject: |
|
|
You can, of course, implement a checksum yourself, if you think your data files need it. ZShell programs, for instance, have a checksum to prevent you from running a program that has been corrupted.
In a lot of cases, though, a better idea is to program defensively and be tolerant of errors, so that a corrupted data file can still be somewhat useful. |
|
| Back to top |
|
|
idiot0000
Newbie
Joined: 13 Apr 2009
Posts: 4
|
| Posted: 19 Jun 2010 08:50:48 am Post subject: |
|
|
hmm after reading this I don't really get what needs to be in there. Mostly that is because of the odd format your python conversion program gives...
could someone please please please write it out in a somewhat mroe conveniant way?
Thank You Very Much |
|
| Back to top |
|
|
|
Z80 & 68k Assembly => z80 & ez80 Assembly
