Don't have an account? Register now to chat, post, use our tools, and much more.
» Goto page Previous  1, 2, 3, 4  Next
Comic, based on what Shaun and I have been discussing, at first it seemed that it was based on no-common-suffixes rather than no-common-prefixes, but we're not 100% on that yet.
I think it's safe to assume that there are no ambiguities, and any we find are our mistakes and need to be investigated further.
merthsoft wrote:
I think it's safe to assume that there are no ambiguities, and any we find are our mistakes and need to be investigated further.
Sounds good. I'll do more code-writing on my framework to support Casio programs in SourceCoder in the meantime, then, and let me know if there's anything I can do to help with the token tables.
Qwerty.55 wrote:
The .g3m file format a very simple format, with three sections of security bytes that were slightly
annoying to figure out. Here are the rules governing each of the sections. Numbers of the form 0xNNh
refer to addresses offset from the starting address of the file while \$NN refers to hex numbers.

0x14h - 0x13h = \$48
0x1C - 0x1Dh = \$1D
0x14h - 0x1Dh = \$C3
0x13h - 0x1Ch = \$5E
0x0Eh + 0x48h = \$72
\$38 - 0x48h = 0x1Dh

0x48h = (Length of the rest of the data) - \$3.
There are always 13 00 bytes following 0x48h.
Algorithm for computing the security sequences:

\$38 - 0x48h → 0x1Dh
\$72 - 0x48h → 0x0Eh
0x1Dh + \$C3 → 0x14h
0x14h - \$48 → 0x13h
0x13h - \$5E → 0x1Ch

0x00h through 0x0Dh:
AA AC BD AF 90 88 9A 8D 8A FF EF FF EF FF

0x0Fh through 0x12h:
FF FF FF

0x15h through 0x1Bh:
01 00 00 00 00 00 00

0x1Eh through 0x3Bh:
FF FE 50 52 4F 47 52 41 4D 00 00 00 00 00 00 00 00 00 00 00 00 01 73 79 73 74 65 6D 00 00

0x3Ch through 0x43h:
8 byte ASCII code for file name.

0x44h through 0x47h:
01 00 00 00

0x49h through 0x55h:

8 byte ASCII password to lock the program. Null bytes if no password

Afterwards: BASIC code
I think this is wrong, I think \$47 and \$48 hold the size of the data section - 3. You have it as just \$48, and \$47 being a constant 0, which is true if the program is smaller than 255 (for example, take a look at the HEX2 program tanner links to, it's has \$47 = 07, and \$48 = 64).
And do you think that that size includes or excludes the password? Is it just the raw tokens in the program itself, which I presume start at 0x56?
It's the number of bytes after \$48 minus 3. So, the HEX2 program ends at 0x7AF. 0x7AF-0x48-3 = 0x764. So it could be size_of_program_data + 0xB.
merthsoft wrote:
It's the number of bytes after \$48 minus 3. So, the HEX2 program ends at 0x7AF. 0x7AF-0x48-3 = 0x764. So it could be size_of_program_data + 0xB.
Indeed, now I'm doing:

Code:
```   //size    \$presize = strlen(\$out)+13-3;   //data + password - 3    \$sizefield = chr(floor(\$presize/256)).chr(\$presize%256);    \$thisout .= \$sizefield; ```
merthsoft wrote:
I think this is wrong, I think \$47 and \$48 hold the size of the data section - 3.

That's what I said, although I didn't observe anything with 0x47 in my tests.
Qwerty.55 wrote:
merthsoft wrote:
I think this is wrong, I think \$47 and \$48 hold the size of the data section - 3.

That's what I said, although I didn't observe anything with 0x47 in my tests.
Did you do any testing with programs with more than 256 bytes of tokens?
For what it's worth, I processed that CSV file linked in the first post into this:

http://pastebin.com/HmmnhcZ6

Let me know when there's more!
KermMartian wrote:
and let me know if there's anything I can do to help with the token tables.
This goes for anyone really. I need help finding the computer equivalent, or at least their names for most of the characters in this post.

I tried to make them as straight as possible in-case anyone wanted to make a program to extract the little image squares that way. I also have the 15MP photos if that'd help anyone; these have been been pre-cropped for ease.

I can release the HEX values of each program from each image, and we can go from there, making the CSV('s).
Whoops, sorry about the double-post. I see that I seem to be missing most of the single-byte tokens, presumably mostly single characters; do we have those somewhere?
I have all five text files with the HEX Values for each program in the pictures posted in the link above in my post and on the previous page.

There are a few single byte values, perhaps 40-50% are single bytes.
I can easily (easy except for time spent) find the Unicode characters for those five screens, although the ASCII equivalent sequences are going to royally suck. Did we get hex for them yet? Oh, you just said we did.
Yes, we do. Shall I host those five files or wait until I can just copy the list next to a column of ASCII characters?

If everyone who has access to the spreadsheet take a bit of time to find and add the ASCII, to say Sheet's 6-11, we can get this done in a few days I imagine. Then all I'd have to do is copy paste this list into each Sheet then we could export as a CSV and go from there.
I plan on (at least for the XML file I'm using now and any additions you post) coming up with the typeable equivalents like I have with the 8xp tokens that I use for TokenIDE, so I'll post those as I make them.
Alright, if I release the HEX Codes now, without a corresponding column for their character counterparts, would you be able to work off that? (Given you look at the pictures) Or would you rather me/everyone find as many characters as possible before sending a CSV/Text file over?
I'll help find the equivalents, or if you do them before I get to it, even better. I'll probably end up, like the TI files, having my base tables use Unicode equivalents (escaped as &xBLAH; HTML sequences) and a conversion table that turns the Unicode to and from {ASCII equivalent}s. It would be helpful if we could coordinate on the equivalents, Shaun
I agree. I assume this'll mostly be happening while I'm on vacation, so I'll probably just end up using whatever you use. Though if I change anything along the way, I'll let you know.
Sounds great. I have my first successes, in the form of Shaun's hearts program:

BASIC Code wrote:
:
:
:
:[
:]
:{
:}
:ClrText
:2->X
:2->Y
:While 1
:Getkey->K
:If K!=0:Then
:Locate X,Y," "
:IfEnd
:If K=27 And X<20
:Then
:X+1->X
:IfEnd
:If K=38 And X>1
:Then
:X-1->X
:IfEnd
:If K=28 And Y>1
:Then
:Y-1->Y
:IfEnd
:If K=37 And Y<7
:Then
:Y+1->Y
:IfEnd
:Red Locate X,Y,"{<3} "
:WhileEnd
Generated by SourceCoder, © 2005-2011 Cemetech

As you can see, and as I said last night, I just need to clean up the trailing post-null characters.

Edit: Done. Code above edited accordingly.

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.

»
» Goto page Previous  1, 2, 3, 4  Next
» All times are GMT - 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