« previous next »
Pages: [1]   Go Down

Author Topic: 8xp file format  (Read 10192 times)

0 Members and 1 Guest are viewing this topic.

Offline quasi_Phthalo

  • LV3 Member (Next: 100)
  • ***
  • Posts: 90
  • Rating: +1/-1
    • View Profile
8xp file format
« on: June 24, 2010, 06:48:16 pm »
Does anyone know what the file format for .8xp files is for compiled* asm progs.

*compiled, as if AsmComp() had been run on it

thanks
Logged

Offline Michael.3545

  • LV3 Member (Next: 100)
  • ***
  • Posts: 69
  • Rating: +13/-7
    • View Profile
Re: 8xp file format
« Reply #1 on: June 24, 2010, 06:58:16 pm »
It would remain an 8xp file, it is the contents of the file that changes.
Logged

Offline BuckeyeDude

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 283
  • Rating: +42/-0
    • View Profile
Re: 8xp file format
« Reply #2 on: June 24, 2010, 06:58:51 pm »
Do you mean the file format on your computer, or the contents of the file when loaded on calc?

If its the former, than its the same as the BASIC format, with TI's header, comment, size, etc. Followed by the contents.
The contents on calc are just the compiled opcodes (the same output as an assembler would produce). Lets say you had a program as such:
Code: [Select]
AsmPrgm
EF4540C9I think thats the bcall to clear the lcd.

When the OS stores this in memory, the AsmPrgm token takes two bytes, while the rest take 1 byte. The AsmPrgm is replaced with the bytes BB 6D signifying it as an assembly program. Then each pair of letters is converted to a number between 0 and 255 and stored to memory (EF is 239, 45 is 69, etc). So the program size essentially gets cut in half.
Logged

Offline quasi_Phthalo

  • LV3 Member (Next: 100)
  • ***
  • Posts: 90
  • Rating: +1/-1
    • View Profile
Re: 8xp file format
« Reply #3 on: June 24, 2010, 08:00:56 pm »
(yes, i am talking about the file on a computer)

so, let me get this straight (i looked at the the hex code of several 8xp's)
the header (in hex): 2A2A54493833462A1A0A00 ? (i think that's the 83 header. what about 84PSE?)
42 bytes of comment padded with 00?
7 mysterious bytes
name (8 chars, padded with 00)
2 or 4 more mysterious bytes (?)
2 byte size (little endian)
BB6D then hex code of the program
a few mysterious bytes at the end?

EDIT: actually, i'm getting conflicting information: i've seen AsmPrgm as $BB6D and $BB6C ?!?!?!
also, the same source says in one place that the word at offset 0x35-0x36 is the program length + 0x13
but in another place, it says that it should be program length + 0x11 ?!?!?!?!

also, does the program length include the $BB6(D/C) ?

EDIT2:
consulted ti83plus.inc: BB6C is for uncompiled asm progs, BB6D is for compiled ones
and i'm pretty sure the length does include those 2 bytes
« Last Edit: June 24, 2010, 11:47:41 pm by quasi_Phthalo »
Logged

Offline Iambian

  • Coder Of Tomorrow
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 739
  • Rating: +216/-3
  • Cherry Flavoured Nommer of Fishies
    • View Profile
Re: 8xp file format
« Reply #4 on: June 24, 2010, 11:52:24 pm »
This may help you. http://www.ticalc.org/archives/files/fileinfo/247/24750.html

Reading the info from that helped me write a small script that packaged some binary file into the .8xp format. It doesn't actually matter what's in the program, since it could be just about anything, be it a BASIC program, an ASM program, or some mess or manner of data. The header and footer (that's the two mystery bytes) just make it so the computer-to-calculator link program knows what to do with the file.
« Last Edit: June 24, 2010, 11:54:23 pm by Iambian »
Logged
A Cherry-Flavored Iambian draws near... what do you do? ...

Offline BuckeyeDude

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 283
  • Rating: +42/-0
    • View Profile
Re: 8xp file format
« Reply #5 on: June 24, 2010, 11:59:31 pm »
Pretty good analysis. You're dead on for most of it. The first 8 bytes are the header for the 83 plus, followed by a 3 byte further sig that you have down. 84 plus is the exact same as the 83plus. The next 43 bytes are the comment as you said, with the last always being a null. The next number is the size from this point to the end of the data. TI likes to include this a lot. The next part is another header section, this time for the data. The next number i'm pretty sure is the size of the header, its always 0Bh or 0Dh. The next two bytes are the size again. Then the variable type ID. Then the variable name. Then the version number which doesnt really matter. then comes the flag, 80h for archive, 00h for RAM. Then the length AGAIN, for good measure, and finally the variable data. The last two bytes are always a checksum of the data section, which always confused me, but is apparently just lowest 16 bits of the sum of all the data.
http://www.ticalc.org/archives/files/fileinfo/247/24750.html does a pretty good job detail this all. I can maybe answer any other questions you have
Logged
Pages: [1]   Go Up
« previous next »