Just wanted to post a bit of an update on my progress in developing an SDK for the CASIO fx-CP400. This is after I've managed to achieve code execution on the calculator after dumping the firmware and adding a small stub to allow me to run code in a file placed on the calculator's USB storage (the one that appears when you press "USB Flash" when a USB cable is plugged in). If you haven't seen them already, I made a couple blog posts on dumping the firmware and adding a small proof-of-concept modification to show arbitrary code execution. They're below if you want to have a read.
Hacking the fx-CP400 - Part 1 (Getting the Firmware)
Hacking the fx-CP400 - Part 2 (Exploring the Firmware)
Now, onto the progress I've made at developing some sort of SDK for the calculator. Since the calculator lacks any sort of add-on feature, it's first necessary to install a small code stub somewhere in the firmware which can load an executable file into memory and run it. Right now, I've placed this in the System app, under the System > Imaginary Unit menu in the menu bar at the top. This isn't really that important - it's just because it was somewhere I knew the function wouldn't get called when I didn't want it to, and didn't get in the way of any other important OS functions. At the moment, when the Imaginary Unit menu option is pressed, a file run.bin is loaded from the calculator's flash, placed into a (I think) unused section of RAM, and jumps straight to it. This gives me a super easy way to write some code, put it on the calculator, and run it, without having to reflash the whole firmware (which takes >5 minutes....).
Since the calculator doesn't seem to support any type of add-on, it appears to lack a syscall interface. As such, system functions are called directly by their address. So my battle has been sorting through functions in the firmware, finding which are actually useful/won't break the calculator and then documenting them to the best of my ability.
At the moment, I am able to write text to the screen (through functions used in the debug menu/unrecoverable system errors), write directly to the VRAM (set the value of pixels and refresh the LCD), get input (key and touch events) - albeit in a slightly broken way, and do some very minimal GUI stuff.
Here's some proof of being able to write to the VRAM and a slightly broken GUI demo (which I've since fixed)
Goals before I make any kind of release: find a nicer way to start arbitrary code execution. At the moment I'm investigating how the menu (the one with the application icons) is populated, in an attempt to add my own icon for add-on applications. Intent would be to have that launch a browser, where the user can select an executable file to load. Obstacles to this are that testing any modifications to the firmware involves reflashing the calculator, which is a pretty lengthy process as I said above, and having to discover exactly how each of the applications on the menu are implemented.
I started to have issues around that recently (since I don't currently have much of an idea on how each application is started and executed) when I was testing touch screen input. Tapping a point on the screen reports an event with one code, and tapping an icon on the bar at the bottom of the touch screen reports a different code depending on which button is pressed. Issue is - tapping the Menu or Main keys return a structure I haven't figured out the format of at all, and after my code finishes execution the calculator locks up. When I get all this worked out, I'll be much happier to make some sort of release
If anyone's got any questions, fire away.
