We could probably get them without too much effort.

BTW: The Hello World was me testing the table. You can see the full edited version if you look at it again.

Here it is:

https://edu.casio.com/download_service/download/category.php

@z80man: On the fx-9860G, the addins and the OS used a similar checksum. IIRC, the checksum for the addins on the fx-9860G was simply a sum of some 32 bytes in the header. For reference, here are the specs of the fx-9860G header: http://www.casiocalc.org?s=&showtopic=2622&view=findpost&p=36912. For the OS, it was just a sum of all the bytes in the OS placed into a 4 byte integer at the end of the OS image.

Quote from: DJ Omnimaga on December 28, 2010, 01:53:56 am

Yeah they say on their site it has 61 KB of user RAM. Are we sure that it's not just user RAM though?

Yes, you have 61KB of storage for your BASIC programs.

Some bad news:

Quote

Thank you for sending e-mail.

Also we appreciate for your running of a website for Casio scientific
calculators.
However we regret to say that Casio has no schedule for releasing a SDK for Prism
as for now.

This attractive model, developed as new education equipment, we are suggesting
new function and specification which were not able to achieved by previous
graph function.

Especially Picture Plot Function, it is favored so much, we are going to spread
more useful functions in our website contents as needed.
We would highly appreciate for your effectively usage and continued patronage
of our products.

Best regards

I guess they really don't have plans for a SDK. This came directly from their headquarters in Japan.

But if the header format get cracked, we'll be able to run our own custom code on the Prizm and we can figure out how to program it ourselves.

That sucks. Well, I guess our only way for now is hacking. I hope they don't try to counter every hacking attempt like TI did for a while with the Nspire.

Code: [Select]

16 FE FF FE B9 57 9F ; picture plot
16 FE FF F4 75 57 9F ; geometry
C2 FE FF FF 8E 03 4B ; conversion

I figured out part of the copy protection. First of the 2nd and 3rd bytes appear to always be FE anf FF, but thats pretty obvious. More interesting was if you subtract from the picture app's 4th, 5th, and 6th bytes by the geometry app's 4th, 5th and 6th you get the same difference of their file size not including the header. You will notice though that for the 4th, 5th and 6th that the conversion app has the greatest number and the geometry the smallest which may seem strange at first considering that the conversion app is the smallest and he geometry app is the smallest. Checking it over again I noticed that the bytes were written in inverse binary. As in the 1's became 0's and the 0's became 1's. So these bytes are just the file size written in inverse.

Now correct me if i'm wrong but if we swap two bytes, the checksum should be the same and the program should run right?  However it would fail if one of the bytes was the checksum right?  Maybe this could be used to find out where the checksum is if we don't know it already?

Looks like we're already working on the hacking 

Yeah I mean I hope that we can succeed in running 3rd party ASM code on it. Then we have to re-do it everytime Casio release a patch/OS that blocks it (unless they don't care).

Nice. That makes me wonder, though: if they use the same system as their old calcs, this means maybe we could crack the 9860G too? On the 9860G we already have a SDK, but no way to run ASM programs from BASIC, for example.