Omnimaga

Omnimaga => News => Topic started by: DJ Omnimaga on January 10, 2011, 01:34:31 am

Title: Casio Prizm 3rd-party development: The good and the bad news
Post by: DJ Omnimaga on January 10, 2011, 01:34:31 am
First of all, the bad news is that Casio USA and Japan both apparently have no (http://cemetech.net/forum/viewtopic.php?p=128842#128842) plan (http://ourl.ca/8207/161393) 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 (http://www.ticalc.org/archives/news/articles/14/145/145316.html) a (http://www.ticalc.org/archives/news/articles/14/145/145828.html) TI (http://www.ticalc.org/archives/news/articles/14/146/146504.html) 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:

(http://www.omnimaga.org/images/screenshots/prizmcrash.png)

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.
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: JosJuice on January 10, 2011, 01:36:07 am
overclocking for four milliseconds is so fun < 3>
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: Munchor on January 10, 2011, 09:02:36 am
This is great news!
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: fb39ca4 on January 10, 2011, 01:25:03 pm
This is good that we can run our own code, but bad as the sdk wouldve included an emulator.
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: AngelFish on January 10, 2011, 01:32:14 pm
Quote
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 :P
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: fb39ca4 on January 10, 2011, 01:36:50 pm
SuperH is supported by gcc, tho.
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: AngelFish on January 10, 2011, 01:58:52 pm
But you still have to insert the hex into a add-in, which would be 28 KB of data  :P
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: DJ Omnimaga on January 10, 2011, 02:14:50 pm
This is good that we can run our own code, but bad as the sdk wouldve included an emulator.
There will most likely still be some sort of emulator or computer version of the Prizm, like TI did with the Nspire. However, like the Nspire, it won't include a SDK.
Quote
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 :P
I see. Hopefully eventually someone can make an ASM IDE and maybe another language like Axe for it. First, the most important part is running code, though.

I wonder if this calc supports parser hooks?
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: AngelFish on January 10, 2011, 02:23:06 pm
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.
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: z80man on January 11, 2011, 01:41:46 am
I'm almost certain that hooks are supported because a few of the apps add basic commands you can use.
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: Builderboy on January 11, 2011, 01:51:29 am
This is amazing!  I can't believe we already have code running on the Prizm :D 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 :D (not that I think they would :P Casio is cool unlike TI) great work everybody! ^^ Can't wait to see what people dream up with this :)
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: jnesselr on January 11, 2011, 12:59:30 pm
This is amazing!  I can't believe we already have code running on the Prizm :D 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 :D (not that I think they would :P Casio is cool unlike TI) great work everybody! ^^ Can't wait to see what people dream up with this :)
Lol, Casio is cool. I sure hope they don't change it. I wonder if they would give protocols and such
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: DJ Omnimaga on January 11, 2011, 03:37:27 pm
I'M not sure. It seemed like it was them that wanted info on how we did our stuff. :P

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? :P
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: willrandship on January 11, 2011, 05:35:12 pm
I don't think there's room for complaint on the basic front, compared to the nspire :P At least it has Pt-On
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: ztrumpet on January 11, 2011, 05:36:58 pm
Awesome job!  Good luck progressing this further. :)
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: fb39ca4 on January 11, 2011, 06:45:05 pm
I'M not sure. It seemed like it was them that wanted info on how we did our stuff. :P

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? :P
That needs to be done for the nspire too.
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: DJ Omnimaga on January 11, 2011, 09:35:01 pm
Why did you just quote me without saying anything? ???
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: z80man on January 11, 2011, 09:56:43 pm
I don't think there's room for complaint on the basic front, compared to the nspire :P At least it has Pt-On
Actually the Prizm doesn't have a Pt-On command. Just Pxl-On. I'm hoping though that basic gets faster in the future as only OS 1.00.100 is out right now. Later versions might even overclock the proc. but then again, TI didn't do to well with making newer, faster OS's. eg. OS 2.53 <_<
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: fb39ca4 on January 12, 2011, 12:14:07 am
Why did you just quote me without saying anything? ???
Whoops! I must've wrote what I was saying inside the quotes. ;)
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: DJ Omnimaga on January 13, 2011, 12:02:38 am
I don't think there's room for complaint on the basic front, compared to the nspire :P At least it has Pt-On
Actually the Prizm doesn't have a Pt-On command. Just Pxl-On. I'm hoping though that basic gets faster in the future as only OS 1.00.100 is out right now. Later versions might even overclock the proc. but then again, TI didn't do to well with making newer, faster OS's. eg. OS 2.53 <_<
Someone could maybe write a new interpreter or a parser hook that installs sprite commands to the Casio BASIC, like Doors CS, xLIB and Celtic did for the z80 calcs. Heck, maybe an entire interpreter could be done, although that could be complicated. A new language would be welcome as well, but not only C. We need something like C, ASM and Axe or BASIC, because some people can't stand ASM and C and will be singled out. However, that stuff would probably be for later, I guess.
Why did you just quote me without saying anything? ???
Whoops! I must've wrote what I was saying inside the quotes. ;)
Lol I see now. And yeah I agree. The Nspire is really in need of new commands like getkey, Output and pxl-On. I think for Nspire BASIC the real issue is not its speed, but rather its lack of decent display/output or key input commands.
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: z80man on January 13, 2011, 02:04:48 am
It seems like BASIC has a lot of issues. Today at school I made a snake game and it was extremely slow. Because the snake was only one pixel wide and the screen is 384x216 it takes forever to hit a wall. Also screen drawing is so slow that the Prizm can only draw 2 or 3 pixels a second. After 5 minutes in a boring game a decided to commit suicide and it then took me another minute to reach the closest wall.  :P Perhaps the code (which I will post later) can be optimized a bit, but even then that won't change how slow the drawing routines are.
Title: Re: Casio Prizm 3rd-party development: The good and the bad news
Post by: DJ Omnimaga on January 13, 2011, 02:39:54 am
darn this sucks. What about an home screen snake? Also, is text drawing on the graph screen very slow too? You should check if pictures are supported and how they behave. I am curious if text sprites could be used on the Prizm. On the 83+ people used them to draw graphics faster.

On the 83+, for example:

ClrDraw
For(Z,0,7
Text(-1,8Z,0,"LLLLLLLLLLLLLLLL
End
Storepic 0
For(Z,0,7
Text(-1,8Z,0,"SSSSSSSSSSSSSSSS
End
Recallpic 0

Gave some interesting results sometimes. On the 83+, pic recalling uses the OR logic, though. If Casio Prizm pic recalling uses Overwrite logic, then we can forget about that type of text sprites. Let me make a screenshot.

EDIT: Screenshot: