First of all, the bad news is that Casio USA and Japan both apparently have no plan to release a SDK in the near future. The good news, however, is that programmers may not even need that SDK, after all, providing that Casio won't pull a TI on them.

It appears that z80man has managed to run 3rd-party machine code on his Casio Prizm. Qwerty.55 wrote machine code that clocks the calculator to 58 MHz (twice its default speed) for approximately 4 milliseconds, then a reset occurs. After it was put into fx-cg10 add-in format (the Casio equivalent of TI-83 Plus Flash applications), FinaleTI tried to launch it on his calc, but it wouldn't show up in the main menu. Finally, z80man edited the application with the same checksum as Casio's Conversion add-in, then ran the application on his calculator. As z80man expected, the calculator crashed with the following screen:



Afterward, it appeared that USB transfers stopped working. z80man had to reset the calculator storage (archive) memory to fix that problem. Thankfully, his calc remained safe from this "torture session". However, there still remains the fact that machine code was executed, causing the calculator to perform things that it wouldn't normally.

Assuming that Casio won't start trying to release software updates preventing such add-ins from being executed on the Casio Prizm models, could this mean that assembly or even C for this new calculator is already at our door?

Link to the post announcing that 3rd-party code was run: http://ourl.ca/8207/162012

More discussion is also available earlier in that thread.

This is great news!

Assuming that Casio won't start trying to release software updates preventing such add-ins from being executed on the Casio Prizm models, could this mean that assembly or even C for this new calculator is already at our door?

They'd almost certainly break compatibility with their own software if they released updates blocking this entry point. I'm sure they have more than one unreleased add-in that they'd have to rewrite to accommodate new changes. And C might be a bit far off at the moment. I'd settle for being able to run any code without crashing 

But you still have to insert the hex into a add-in, which would be 28 KB of data 

Even if it doesn't, we can always set up a redirect through a third party parser that can read any commands meant for itself then pass everything else off to the OS parser.

This is amazing!  I can't believe we already have code running on the Prizm And the way they have implemented add-in's makes it impossible for them to block the apps we are making without also breaking compatibility with their own apps (not that I think they would Casio is cool unlike TI) great work everybody! ^^ Can't wait to see what people dream up with this

I'M not sure. It seemed like it was them that wanted info on how we did our stuff.

Also while they may be more open to third-party development (not sure yet), they should really spend more effort at optimizing their BASIC interpreters. Heck, maybe someone could write a new one and send it to them?

Awesome job!  Good luck progressing this further.