I'm not sure what exactly you were trying to say in this post, and I caution you that some of your posts are trending dangerously close to the signal-to-noise ratio barrier for constructive, helpful posts. We don't want to turn into a forum where every post is four words and adds very little to the topic. I'd prefer if posts are more insightful and have a higher quality even if it means the forum having fewer total posts.

Kevin, I assume this means that your calculator has arrived; congrats! I need to get on the ball about getting my own Prizm.

Indeed it arrived, although almost a month after buying it.

Now my work schedule got a bit lower (although its stability is still not guaranteed), so I will split some of my additional free time to mess around with the calculator.

Geez, did someone walk to your house from the factory? That's some pretty pathetic shipping time in my opinion. I look forward to seeing what t.you make with i

My post on the formatting of Casio-BASIC files. Cross-posted from Omnimaga:

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:

00 00 00 00 00 00 00 00 00 00 00 00 00

That's some top-notch reverse engineering work; nice job! Next step is to make a program to generate these. What is the size of the images, fullscreen?

What images? The .g3m format is used to hold BASIC programs.

Oh, my mistake, I thought that was the image-storage format. Sorry about that.

It's fine. Casio's filetype system is admittedly pretty confusing. You're thinking of the .g3p filetype, though.

In other news, it *is* possible to run SH3 Assembly without crashing and the Prizm OS appears to run at 58 MHz. If it truly does, then Casio really screwed something up to make the BASIC interpreter run slower than the TI-84+ series

<.<

Oh dear, that's quite disappointing. The TI-BASIC parser is already a mass of spaghetti code; I can only imagine what Casio's parser looks like. Was it written in C and compiled, do you think? That could be part of the problem.

I think that's very likely.

Good, then they need to share their development environment with us.

This is why once (if?) people manages to jailbreak the Prizm or successfully run custom add-ins on it there should be a third-party language ported to the calculator (like Axe, for example) a DCS-like BASIC extender or maybe even a new BASIC parser, although I guess the latter would be much harder, unless only the drawing commands were re-made.

DJ, we can for all intents and purposes make custom add-ins. The only remaining limitation is that the Checksum remain the same, because Casio uses a non-standard CRC polynomial to validate add-ins.

Ok, but if that's the case, couldn't that way be temporary (or alternatively) be used to create stuff? Someone could just write a PC software that gets rid of all the changeable code inside an existing add-in then allow the user to insert his own code or something? That wouldn't be as convenient, but that could work, right?

What's preventing us from doing the same? Not knowing what that polynomial is? Reverse-engineering it sounds like a fun project.

Yeah, we don't know what the polynomial is. I haven't looked into it because it's not preventing us from running code, only designing pretty menu icons. That's not exactly the worst limitation in the world. I believe another member is trying to figure it out, though.

If you could give me the relevant items, I would love to whip up a quick program to attack the problem. Hopefully you have a bunch of add-ons and their associated CRCs?

Edit: ooooh, if you have a lot of CRCs and code, this would be a perfect application to test a neural-network trainer I'm building for research! Neural networks are good at solving polynomials.

There are three add-ins released. They can be found here:
http://edu.casio.com/navidl/

I think the CRC is at 0x0016...

Oh, only three CRCs doesn't make for a reliably-solvable sysmem; I was hoping it was a CRC per 128-byte block or something. Are you using CRC as a general term, or do you think it actually uses a CRC algorithm?

It's an actual CRC-16, as far as I'm aware.