merthsoft wrote:
You want to sum up the integer value of the bytes, not the nibbles. So if hex array is ['21','01','00','EF','07','45'], you'll want to sum up the values [33, 1, 0, 239, 7, 69] = 349 = 0x15D0 (big endian) = 0xD015 (little endian) (if I've done all that right).


Thanks much Merth, quite easy actually:


Code:
>>> int('21',16)+int('01',16)+int('00',16)+int('EF',16)+int('07',16)+int('45',16)
349
>>> hex(349)
'0x15d'
>>>
Yeah, well, I did it in my head.
merthsoft wrote:
Yeah, well, I did it in my head.


I'm afraid Assemblex IDE doesn't have a head of his own Laughing
Merthsoft, you have indeed done that correctly. And of course it's mod 65536 (2^16), so if the sum goes over that, it just wraps around.

Code:
sample8xp = "2A2A54493833462A1A0A0046696C652067656E657261746564206279205761626269745369676E0000000000000000000000000000"""+
littleEndian+"0D0018000650524F4752414D00000018001600BB6D"+programData+"0000"
         
         hexArray = [sample8xp[x:x+2] for x in xrange(0,len(sample8xp),2)]
         
         sum=0
         for i in range(0,len(hexArray[76:len(hexArray)-2])):
            sum += int(str(hexArray[76+i]),16)
         
         sum = hex(sum % 256 * 256 + (sum / 256))
         
         print sum



For 210100EF0745, it returns 349 as the size of all the bytes, CORRECT.
When I make it hex, it returns '0x15d', CORRECT (the 0 missing though).
Then, when I make it little endian, it returns 0x5d01, INCORRECT.

I'm using the same code I use for the size to get little endian.

Thanks merth and Kerm ;D

Edit by Merth: You really need to start using line breaks...
Actually, I think I did it wrong. I said 0x15D0, but I'm pretty sure it should've been 0x015D, so in little endian it would be 0x5D01.
merthsoft wrote:
Actually, I think I did it wrong. I said 0x15D0, but I'm pretty sure it should've been 0x015D, so in little endian it would be 0x5D01.


I got to the conclusion that yes, I had to be right, the mechanism worked for the size, why not for the checksum?

Now, I've got a checksum working, I only need one more thing (before the name and comment, but those are not my priority)...

The size of the variable data, data, and checksum.



EDIT: Finished the comment:


Code:
46696c652067656e65726174656420627920417373656d626c6578202d20446176696420476f6d657300


It says:


Code:
File generated by Assemblex - David Gomes


EDIT 2:

I have a very important question now, what is the variable data and variable header?
My size of the variable data is 1800 (a value that's actually repeated)
And the size of the rest of the data is 1600 (two less than 1800).

I really need to know from where to where the variable data and header are please.
Have you taken a look at http://merthsoft.com/linkguide/ti83+/fformat.html to figure that out? It clearly specifies "Data section - consists of a number of variable entries (described below)." where the data section is.
I had already checked that page, but I lost the link Kerm.

I rechecked it now but I still have doubts.

The 1# offset in this post is what's troubling me.

Also, I noticed I'm not calculating the checksum correctly.
The checksum is the sum of the integer value of all bytes of the actual program.

But anyways, my problem is what I stated before... What exactly is the variable.

My head is on fire right now... I've been thinking about this for hours. I'm probably giving up.

Meh, screw it.
Don't look at that screenshot, it's wrong. Alberthro was trying to make a file from scratch, I think, and did so incorrectly. Anyway, let's call the size of the whole .8xp file S. We know that the checksum is two bytes, and the main header (comment etc) is 55 bytes. We'll call the "variable/data" part therefore of size S-(55+2) = S-57.

55 bytes: header
S-57 bytes: variable/data
2 bytes: checksum

At offset 53, we have the little-endian, two byte value (S-57). Then, we have the actual variable/data itself, which starts at offset 55. At offset 2 and offset 15 into that, in other words offset (55+2) and (55+15) = 57 and 70 overall, we have two copies of just the size of the contents of the actual program (/ picture / string / list / etc). Incidentally, because the variable's header is 17 bytes, the value of those two size fields is S-57-17 = S-74.
Okay, I'm back to working on this.

I'm gonna restart it all.


Checksum:


Code:
sumo=0
for i in range(0,len(hexArray[76:len(hexArray)-2])):
    sumo += int(str(hexArray[76+i]),16)
         
sumo = hex(sumo % 256 * 256 + (sumo / 256))


So, this is my code, but it doesn't seem to be right. I don't have much time for now, any ideas?
Does hex() generate a little-endian two-byte word out of the result? And make sure about order of operations; try "% (256 * 256)". Also, why are you adding sumo / 256? Try this:


Code:
sumo=0 
for i in range(0,len(hexArray[76:len(hexArray)-2])): 
    sumo = (sumo + int(str(hexArray[76+i]),16)) % (256*256)
         

sumo_string = hex(sumo- 256*int(sumo/256)) + hex(sumo/256)
KermMartian wrote:
Does hex() generate a little-endian two-byte word out of the result? And make sure about order of operations; try "% (256 * 256)". Also, why are you adding sumo / 256? Try this:


Code:
sumo=0 
for i in range(0,len(hexArray[76:len(hexArray)-2])): 
    sumo = (sumo + int(str(hexArray[76+i]),16)) % (256*256)
         

sumo_string = hex(sumo- 256*int(sumo/256)) + hex(sumo/256)


hex(65535) = 0xffff

Not little endian, though.
does hex(255) = 0xff? If so, then the code I gave you should work properly.
KermMartian wrote:
does hex(255) = 0xff? If so, then the code I gave you should work properly.


hex(255) = 0xff, sir.

Thanks, I will try it right away.

EDIT:


Code:
>>> def getCheckSum(hexArray):
   sumo=0   
   for i in range(0,len(hexArray[76:len(hexArray)-2])):   
       sumo = (sumo + int(str(hexArray[76+i]),16)) % (256*256)
         

   sumo_string = hex(sumo- 256*int(sumo/256)) + hex(sumo/256)
   return sumo_string

>>> print getCheckSum("210100")
0x00x0
>>>


Kind of working (=P), I'm gonna check it later.

/me goes study Chemistry.
Wait, why are we doing this in strings like "0x00" instead of real bytes?
KermMartian wrote:
Wait, why are we doing this in strings like "0x00" instead of real bytes?


You mean bytearrays? My original mechanism is having a hex string and then converting it to binary and writing it in the file.


ByteArrays, seems like a good idea Smile
Yeah, I'm very uncomfortable with the concept of building it as a string first; I'd rather it be a bytearray first, or later a string too if you must display it for the same of debugging or something. If you do that, then in my checksum code, hex(sumo- 256*int(sumo/256)) is the first byte of the checksum, and hex(sumo/256) is the second.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 3 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement