Omnimaga

Calculator Community => Casio Calculators => Casio PRIZM => Topic started by: AngelFish on December 07, 2010, 12:16:09 am

Title: Casio Prizm documentation
Post by: AngelFish on December 07, 2010, 12:16:09 am
Because I know a few people, including myself, are working on projects for the Prizm, I thought it might be helpful to compile ALL of the known information and sources concerning the Prizm in one place for people. Here are all of the official resources of which I am aware:

Casio general specifications (http://www.casio.com/news/content/51D7AC67-A2F7-479C-9250-926471B69BF9/)

Hardware User's guide (http://www.casioeducation.com/resource/manuals/PRIZM%20FX-CG10/Hardware_User_Guide_English.pdf)

Casio Software user's guide (http://edu.casio.com/products/cg_series/data/fxcg10_20_E.pdf)

Spansion Flash memory Datasheet (http://spansion.com/Support/Datasheets/s29gl-n_00_b8_e.pdf)

Pictures for graphing (proprietary format) (http://edu.casio.com/products/cg_series/materials.html#pagelink03)

If you are aware of anything not in this list, please post a link to it.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 07, 2010, 04:03:14 am
I've made a PDF with links to the sources of the animations. You can preview them or just be amazed at what Casio appears to have planned for the Prizm.
Title: Re: Casio Prizm documentation
Post by: SirCmpwn on December 07, 2010, 08:48:28 am
With a color screen, we could probably make a PDF reader ;)
Title: Re: Casio Prizm documentation
Post by: Ashbad on December 07, 2010, 09:04:09 am
very helpful. Thank you! :)
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 07, 2010, 12:48:17 pm
Welcome. I needed it myself, mostly  :P
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 07, 2010, 03:57:27 pm
Thanks for the topic! :D

I made it sticky
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 19, 2010, 03:08:28 pm
I finally feel reasonably confident in this information, so I think it's time to announce this:

As of yesterday, it should now be possible have the Prizm accept and recognize image files. The security bytes in the .g3p file format have been cracked.

In other news, the Prizm appears to use Big Endian notation and it is almost certain that a C compiler of some sort exists for the Prizm. Whether these details will be confirmed by Casio remains to be seen.
Title: Re: Casio Prizm documentation
Post by: JosJuice on December 19, 2010, 03:23:07 pm
As of yesterday, it should now be possible have the Prizm accept and recognize image files. The security bytes in the .g3p file format have been cracked.
(http://zeldaforumet.se/forum/img/smilies/;D.PNG)
In other news, the Prizm appears to use Big Endian notation and it is almost certain that a C compiler of some sort exists for the Prizm. Whether these details will be confirmed by Casio remains to be seen.
it is almost certain that a C compiler of some sort exists for the Prizm.
Spoiler For Large image warning:
(http://i242.photobucket.com/albums/ff80/Azelf_2007/FUCK-YEAR-1.gif)
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 19, 2010, 03:36:09 pm
Yeah, you can get a lot from a file format.

You know, If Casio were TI, they'd probably be watching and laughing because there aren't any real security bytes. They were just to mess with us  :P
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 19, 2010, 04:10:05 pm
Awesome to hear! I hope they don't change the format too often. I guess this means in short terms, we could create our own pics using a converter, like Image Studio for TI calcs or Excale's/Critor TI Nspire image converter?
Title: Re: Casio Prizm documentation
Post by: Hot_Dog on December 19, 2010, 08:00:59 pm
Anyone know the processor speed?
Title: Re: Casio Prizm documentation
Post by: calc84maniac on December 19, 2010, 08:02:48 pm
Anyone know the processor speed?
More importantly, how about the processor architecture?
Title: Re: Casio Prizm documentation
Post by: shmibs on December 19, 2010, 08:59:35 pm
C support?!!
/me is now officially buying a prism.
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 19, 2010, 09:07:19 pm
I wanna buy one, too now. This is good work. I might just go look at the spanish datsheet, fore now.

Edit: how did Spansion become spanish?
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 19, 2010, 09:14:00 pm
Anyone know the processor speed?
More importantly, how about the processor architecture?

Casio has released absolutely no details about the processor. The ability to use Big endian is just what I got from their animation format, which is a near carbon copy of another file format that is specified to be used only with Big Endian processors.

C support?!!
/me is now officially buying a prism.

I never said there was C support, only that a compiler exists :P

Whether Casio releases it or not is the question...
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 19, 2010, 09:37:30 pm
Can you post that usb format in here, for future reference, and because I lost the link.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 19, 2010, 09:58:11 pm
Oh, sure. http://cdnetworks-us-1.dl.sourceforge.net/project/fxsdk/documentation/fxreverse-docs-1/fxreverse-docs-1.pdf (http://cdnetworks-us-1.dl.sourceforge.net/project/fxsdk/documentation/fxreverse-docs-1/fxreverse-docs-1.pdf)

This is NOT the Prizm USB format, but in order to maintain backwards compatibility with their calculators (which is assured in the documentation), they would have had to use normal USB protocols.
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 19, 2010, 10:00:42 pm
Which means we basically need to hope it's not proprietary protocols. If they aren't, and especially if we can do anything with them with the sdk, we can reverse engineer them.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 19, 2010, 10:07:15 pm
If Casio cares at all about 3rd party developers, then they used standard protocols. Of course, that's what we thought with the 84+  <_<
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 19, 2010, 10:11:47 pm
Qwery are you actually in the process of documenting every single thing about the Prizm? O.O
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 19, 2010, 10:15:22 pm
No, just everything I can get my hands on  :P
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 19, 2010, 10:16:17 pm
Ok, I was curious since you've been a lot into that stuff lately, from understanding the image/animation format to USB.
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 19, 2010, 10:17:53 pm
Ok, I was curious since you've been a lot into that stuff lately, from understanding the image/animation format to USB.
If I get one, I'll probably work on USB.

This begs the question that we've all been thinking about, but too afraid to ask. KOS Prizm anyone?
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 19, 2010, 10:19:30 pm
Finished WFRNG OS last week ;D
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 19, 2010, 10:20:46 pm
You are kidding? :P

(More curious about if you actually made a 3rd-party OS already before the calc even comes out :P)
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 19, 2010, 10:21:26 pm
Yeah :p
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 19, 2010, 10:21:53 pm
You are kidding? :P

(More curious about if you actually made a 3rd-party OS already before the calc even comes out :P)
Whoa! I see "You are kidding", but I see the edit when I hit quote even though I don't see it in the post! awesome!

anyway, yeah, he's kidding. I think.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 19, 2010, 10:24:10 pm
I HAVE ported WFRNG to the Prizm, though...

http://ourl.ca/8029 (http://ourl.ca/8029)
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 19, 2010, 10:24:48 pm
Lol
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 19, 2010, 10:25:25 pm
I HAVE ported WFRNG to the Prizm, though...

http://ourl.ca/8029 (http://ourl.ca/8029)
Sure.... I look forward to the day when we actually do. Hopefully there is no 2048 bit key.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 19, 2010, 10:26:16 pm
Hopefully not, but I wouldn't put much faith in it.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 19, 2010, 10:42:52 pm
Next thing we know:
-Jan 1st: Casio Prizm comes out
-Late Feb: Casio SDK comes out
-One day later: Starcraft Prizm arrives. ;D
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 19, 2010, 10:43:47 pm
Next thing we know:
-Jan 1st: Casio Prizm comes out
-Late Feb: Casio SDK comes out
-One day later: Starcraft Prizm arrives. ;D
I actually thought of porting Runescape to the TI calc at one point. A far less detailed one, obviously.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 19, 2010, 10:45:12 pm
X.x lol ok. It would actually be nice if one of the TI RPG was ported but with updated graphics. I would like to see a SNES style RPG, but with 16 bit graphics.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 19, 2010, 10:50:52 pm
Sounds like we need to write a z80/TI-BASIC interpreter for the Prizm...
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 19, 2010, 10:53:02 pm
An alternative to C would be nice. Some people dislike C/ASM and prefer Axe/basic syntax, but they dislike the slow speed of BASIC. Maybe a compiler?
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 19, 2010, 10:55:28 pm
Maybe, but the extra speed of the Prizm's processor would make most games impossible to play compiled  :P
Title: Re: Casio Prizm documentation
Post by: apcalc on December 19, 2010, 11:06:14 pm
I really hope the C compilier (if it is released :P) will be available to download even if you don't own the calculator.  I would love to be able to port some of my games to full color! :D
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 19, 2010, 11:36:52 pm
Seriously, color on a calc is an amazing idea that should have been done already. What are the dimensions of the screen, though?
Title: Re: Casio Prizm documentation
Post by: Hot_Dog on December 19, 2010, 11:59:30 pm
-One day later: Starcraft Prizm arrives. ;D

DJ, no truer words spoken! ;D

Even if not, porting S.A.D. to color is something that someone would have my permission to do.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 20, 2010, 12:04:33 am
Seriously, color on a calc is an amazing idea that should have been done already. What are the dimensions of the screen, though?

216x384.

 BTW: Color has already been done before. Two byte colors have not.
Title: Re: Casio Prizm documentation
Post by: Hot_Dog on December 20, 2010, 12:08:04 am
Seriously, color on a calc is an amazing idea that should have been done already. What are the dimensions of the screen, though?

216x384.

 BTW: Color has already been done before. Two byte colors have not.

Was there any color calculator that had more than 4 colors?
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 20, 2010, 12:10:36 am
I don't believe so.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 20, 2010, 12:50:55 am
The only color calcs there were before were the CFX series, which had blue, orange and green. ANother model had blue, orange, green and black, I think, but it's more rare.
Title: Re: Casio Prizm documentation
Post by: Munchor on December 20, 2010, 08:06:36 am
Seriously, color on a calc is an amazing idea that should have been done already. What are the dimensions of the screen, though?

I don't think colours are important for a calculator, at least, not as many as the Prizm, 8 colours are enough and their only importance is the graph system, so that each function can have its own colour :)
Title: Re: Casio Prizm documentation
Post by: JosJuice on December 20, 2010, 08:19:11 am
Seriously, color on a calc is an amazing idea that should have been done already. What are the dimensions of the screen, though?

I don't think colours are important for a calculator, at least, not as many as the Prizm, 8 colours are enough and their only importance is the graph system, so that each function can have its own colour :)
wait what

You're using calculators for math? ;_;
Title: Re: Casio Prizm documentation
Post by: Munchor on December 20, 2010, 08:32:14 am
Seriously, color on a calc is an amazing idea that should have been done already. What are the dimensions of the screen, though?

I don't think colours are important for a calculator, at least, not as many as the Prizm, 8 colours are enough and their only importance is the graph system, so that each function can have its own colour :)
wait what

You're using calculators for math? ;_;

Indeed I am :/
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 20, 2010, 01:54:04 pm
But we all know that calcs are for gaming. ;D :P

Nah but I think technology needs to elvolve...
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 23, 2010, 05:12:17 pm
I can't believe I didn't notice this before. Looking through the documentation, Casio will apparently have support for .bmp files in the Prizm. Also, the .g3b files that I thought were animation files are listed as "Flipbook files," whatever that means.
Title: Re: Casio Prizm documentation
Post by: calc84maniac on December 23, 2010, 09:04:35 pm
I can't believe I didn't notice this before. Looking through the documentation, Casio will apparently have support for .bmp files in the Prizm. Also, the .g3b files that I thought were animation files are listed as "Flipbook files," whatever that means.
From what I read, the .bmp was for saving screenshots. I'm not sure if it's possible to load/display .bmp files.
Title: Re: Casio Prizm documentation
Post by: Ashbad on December 23, 2010, 09:05:36 pm
Seriously, color on a calc is an amazing idea that should have been done already. What are the dimensions of the screen, though?

I don't think colours are important for a calculator, at least, not as many as the Prizm, 8 colours are enough and their only importance is the graph system, so that each function can have its own colour :)
wait what

You're using calculators for math? ;_;

Indeed I am :/

stone him

now
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 23, 2010, 09:39:28 pm
I can't believe I didn't notice this before. Looking through the documentation, Casio will apparently have support for .bmp files in the Prizm. Also, the .g3b files that I thought were animation files are listed as "Flipbook files," whatever that means.
From what I read, the .bmp was for saving screenshots. I'm not sure if it's possible to load/display .bmp files.

I saw no mention of bitmaps aside from the description of filetypes in the documentation. On a side note, I've confirmed what I thought about the image format. It should be relatively easy to convert from bitmaps to .g3p.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 25, 2010, 10:13:56 pm
FinaleTI got his Prizm!

(http://img.removedfromgame.com/imgs/DispCap1.bmp)

Apparently, like on the FX-9860G, the Output() equivalent on the calc runs blazing fast, even faster than on a 84+. The other BASIC commands are not that fast, but Output speed combined with 7 colors useable in BASIC and the presence of Getkey is a good sign for Casio Prizm BASIC programming.
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 25, 2010, 10:15:45 pm
This is Awesome! Okay, so now FinalTI must give us everything. SDK, programming information, usb protocols, what's up with the little dude in the corner, etc.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 25, 2010, 10:18:32 pm
I don't think the SDK is available yet and there's no info about when/if it's gonna be released. I am glad the calc is not as locked-down as the Nspire in terms of programming, though. Although BASIC by itself is slow, the Nspire didn't even have programming until OS 1.6 I think and it still lacks an Output()/Locate or getkey function. I still hope for some other stuff, though, since in long terms, just BASIC might not interest that many people.
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 25, 2010, 10:19:28 pm
I don't think the SDK is available yet and there's no info about when/if it's gonna be released. I am glad the calc is not as locked-down as the Nspire in terms of programming, though. Although BASIC by itself is slow, the Nspire didn't even have programming until OS 1.6 I think and it still lacks an Output()/Locate or getkey function. I still hope for some other stuff, though, since in long terms, just BASIC might not interest that many people.
okay, that's fine then. Hopefully, we can program this calc better than the TI-NSpire.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 26, 2010, 02:32:08 am
Cross posted from the other thread:

Since it seems some of you are very interested in programming the Prizm, I'll tell you guys this (I apologize if it's very lengthy):

From disassembling the addins given by Casio, the Prizm uses a SuperH 3 processor, which is what Casio has been using in their products for the last decade (fx-9860, fx-9750GII, Classpad 300, Pocket Viewer, etc.) The addins contain a header 0x7000 bytes long which contains info specific to the addin (appname, icon bitmap, date, version, copy protection, size of addin in bytes, etc.) before the actual binary starts. Addins are loaded into memory offset 0x00300000 (execution starts at 0x00307000). You can confirm this yourself if want using objdump that has been cross compiled for SuperH support (such as GCC targeted for sh-elf). SuperH 3 software manual: http://documentation.renesas.com/eng/products/mpumcu/rej09b0317_sh_3sm.pdf (http://documentation.renesas.com/eng/products/mpumcu/rej09b0317_sh_3sm.pdf)

If someone has the time, it should be easy to crack the header format. The header is about ~28KB, large enough to contain the icon bitmap for the addin. Once someone knows what's the icon dimensions are in pixels, you could probably find it in header by using some hex to RGB viewer.

Hardware wise, it seems pretty similar to the fx-9860G (it seems to be just a fx-9860G with an upgraded color screen and a larger flash chip). From this, I'm guessing the operating system is stored in memory offset 0xA0000000 (Area P2).

You can try asking Casio Japan (not the USA branch, they won't be able to help much since they don't design the calcs) for technical info and questions about an SDK. Someone in the community asked Casio Japan for the USB communication specs and their R&D department nicely gave it us. You can keep bugging Casio Japan to release an SDK, but you have to understand it takes them time to make an SDK since they have to polish up their emulator which the R&D guys use in development, package up a compiler/linker, write manuals, etc. Casio doesn't make any money off SDKs, so I don't think it's their top priority. I think when the fx-9860G came out, Casio didn't release an SDK until a year later IIRC, but hopefully we don't have to wait too long this time for the Prizm. According to Casio's website, they plan to release some trial software at the beginning of next year, so you guys should keep a watch out for that since it might include an emulator.

I'd try to find out more, but I'm too busy right now in college. Hopefully you guys will find everything you need to know in the near future. Happy hackings and Merry Christmas!
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 26, 2010, 02:34:54 am
Yeah I hope someone can contact the Japan branch of Casio. Hopefully if they speak english or if someone here knows Japanese maybe they could help. I wonder if they would give more info. It would be kinda nice.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 26, 2010, 02:36:38 am
Yeah.  To tell the truth, I'm kind of disappointed though. A 29 MHz processor was not what I expected. The Nspire blows that out of the water. An Nspire killer it is not, in terms of processor speed at least.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 26, 2010, 02:41:03 am
Are you sure it runs at 29 MHz? Some sources says 59 and others 100. The 9860G was slowed down to 29, I think, but it was possible with a program by Kucalc to set the speed at 59 or something, from what I remember.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 26, 2010, 02:42:12 am
That's still not much compared to the 90/150 MHz of the Nspire.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 26, 2010, 02:44:27 am
Yeah. I guess it will still be enough to do some hardcore games, though. Maybe just not complex polygonal 3D or big real-time strategy games.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 26, 2010, 02:46:40 am
That's assuming that the Prizm is open enough to ASM/C that such games aren't a complete pain to create.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 26, 2010, 02:48:57 am
Yeah that too. That said I think they did a more decent job at not making the BASIC language uber-limited, though. (and the calc price). If TI used a 30 MHz CPU in the 84+, 64 KB of RAM and 10 MB of archive, they would charge $170 for them, I'm pretty sure.
Title: Re: Casio Prizm documentation
Post by: uberspire on December 26, 2010, 03:38:51 am
Are you sure it runs at 29 MHz? Some sources says 59 and others 100. The 9860G was slowed down to 29, I think, but it was possible with a program by Kucalc to set the speed at 59 or something, from what I remember.
Well the fx-9860G ran at 29.5MHz at default to maximize battery life. I have no idea what speed the oscillator in the Prizm is running at. The SuperH 3 processor in the fx-9860G had a register for the internal clock generator which you can modify to quadruple (x4) the clock speed to 118MHz (SuperH processors are capable of running at these frequencies).
Title: Re: Casio Prizm documentation
Post by: TIfanx1999 on December 26, 2010, 01:10:34 pm
Even if it is only 29 MHZ that still isn't terrible. Processor speed isn't everything.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 26, 2010, 03:57:42 pm
Are you sure it runs at 29 MHz? Some sources says 59 and others 100. The 9860G was slowed down to 29, I think, but it was possible with a program by Kucalc to set the speed at 59 or something, from what I remember.
Well the fx-9860G ran at 29.5MHz at default to maximize battery life. I have no idea what speed the oscillator in the Prizm is running at. The SuperH 3 processor in the fx-9860G had a register for the internal clock generator which you can modify to quadruple (x4) the clock speed to 118MHz (SuperH processors are capable of running at these frequencies).
Ah, right. Did your speed upper program let us set the 9860 that high, btw?
Title: Re: Casio Prizm documentation
Post by: Munchor on December 26, 2010, 04:34:08 pm
Even if it is only 29 MHZ that still isn't terrible. Processor speed isn't everything.

29MHZ? The 83+ series is 15MHZ if I'm correct, so that's quite a lot, right?
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 26, 2010, 05:07:18 pm
Even if it is only 29 MHZ that still isn't terrible. Processor speed isn't everything.

29MHZ? The 83+ series is 15MHZ if I'm correct, so that's quite a lot, right?
It's pretty good. For a calc processor, at least.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 26, 2010, 06:19:14 pm
Yep it is. The 83+ is 6 MHz. The BASIC language on it is questionable quality, which is not surprising from Casio, but it depends which functions you are using.

-With locate, if you alternate quickly between yellow and red, for example, you get orange, but it's kinda flickery. It's extremly fast, from what I heard from FinaleTI.
-Pixel drawing command is extremly slow: 38 seconds to draw a 16x16 colored sprite. This means drawing sprites pixel by pixel is out of the question. FinaleTI hasn't found another way to draw stuff, though. Maybe other things are faster. I am curious if Text sprites are fast enough...
-Horizontal/Vertical seemed pretty fast, but he didn't check the other line commands.

In other words, some things are much faster, but other things may be slower. Also I am certain the calc doesn't run at the full processor speed while in OS mode, to save power.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 26, 2010, 06:27:44 pm
The Prizm character set is comprised of at least 207 characters, all of which appear to be ASCII. I have attached the unedited character set.
Title: Re: Casio Prizm documentation
Post by: FinaleTI on December 26, 2010, 06:39:55 pm
The Prizm character set is comprised of at least 207 characters, all of which appear to be ASCII. I have attached the unedited character set.
Where is it?
Title: Re: Casio Prizm documentation
Post by: z80man on December 26, 2010, 06:40:46 pm
After going over the code of of the add-in apps of the Prizm it seems that the application image data starts at location 0x4000 and ends at 0x6DFE. This just about corresponds to an image size of 62x95 pixels which matches the size of the images on the main menu of the Prizm.
This is what I found for the menu icons for the Prizm.
After changing some of the code I was able to modify the image for the conversion app. Now in the main menu the top half of the icon is black.
By the way how can I post the screen-capture image of the modified icon?
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 26, 2010, 07:21:19 pm
The Prizm character set is comprised of at least 207 characters, all of which appear to be ASCII. I have attached the unedited character set.
Where is it?

Oops.

After going over the code of of the add-in apps of the Prizm it seems that the application image data starts at location 0x4000 and ends at 0x6DFE. This just about corresponds to an image size of 62x95 pixels which matches the size of the images on the main menu of the Prizm.
This is what I found for the menu icons for the Prizm.
After changing some of the code I was able to modify the image for the conversion app. Now in the main menu the top half of the icon is black.
By the way how can I post the screen-capture image of the modified icon?

Do you have the screen capture? If you do, then upload it to a file hosting site such as http://img.removedfromgame.com/ (http://img.removedfromgame.com/) and then post the URL of the image in [img]URL[/img] tags.
Title: Re: Casio Prizm documentation
Post by: z80man on December 26, 2010, 08:37:34 pm
It seems that there might be two images stored in the header because the one I edited starting at ox4000 only takes effect when I place the cursor over the icon. What I did was I replaced about 1000 bytes of data with $00 using a hex editor. Most of what I replaced was $FF.
(http://img.removedfromgame.com/imgs/DispCap3.bmp)(http://img.removedfromgame.com/imgs/DispCap4.bmp)
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 26, 2010, 09:18:45 pm
That looks awesome!
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 26, 2010, 09:20:48 pm
Z80man, try editing the data around 0970F0 and see if that makes any difference. Of course, that could very well be app storage space, but...
Title: Re: Casio Prizm documentation
Post by: z80man on December 26, 2010, 11:55:54 pm
I assume you are referring to the Geometry app. After changing the data at 0x0970F0 there was no change in the menu icon, but the OS did refuse to run the app. Also I don't think making changes in this area will do anything to the image because the header ends at 0x7000 and any icons displayed would be before that.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 27, 2010, 12:12:59 am
Hm, I don't see anything else in the header that could be an icon except for the data between 4000 and 6DFD.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 27, 2010, 01:04:48 am
On a side note, does the calc has multiple character fonts? From what I saw on FInaleTI's screenshot, the fonts seemed a bit different than some I saw elsewhere. Maybe it was because his was higher resolution.

Also, on the Japanese website, there appears to be no Prizm listed: http://translate.google.com/translate?hl=en&sl=ja&u=http://casio.jp/&ei=LysYTdigKYKC8gbR9MykAw&sa=X&oi=translate&ct=result&resnum=1&ved=0CB8Q7gEwAA&prev=/search%3Fq%3Dcasio.jp%26hl%3Den%26client%3Dopera%26hs%3DOZR%26rls%3Den%26prmd%3Divns

If it's just an american/european calc, maybe Casio Japan won't even be able to help us with info. :/
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 27, 2010, 01:09:28 am
I screwed up on the character set. I don't know where it is, but what I posted is almost certainly not it. That code repeats itself several times later in the OS.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 27, 2010, 01:18:43 am
That sucks. X.x
Title: Re: Casio Prizm documentation
Post by: z80man on December 27, 2010, 03:23:09 am
Okay in the header there are actually two different icons. One for when the cursor is over the icon and one when it isn't. In my opinion I think Casio could have coded this differently in a way that you only provide one image in the code instead of two considering that the cursor is the same for all apps, but maybe this way is faster. The location for the image when the cursor is not over the icon is at 0x1000 and the one for when the cursor is over the icon is at 0x4000. After changing some of the data you can see a change in the icon, but then the app becomes unrunnable. Any ideas why would be helpful. The only other data in the header is a small amount of text at the beginning and the file name at 0x0EBC. This text at the beginning for the conversion app is  "ª¬½¯.ˆš.ÓÿþÿþÿÂþÿÿŽ.K.É..........'Ød.............ø..............Conversion....................qü@CONV......Conversion..............Conversiæ.n.............Konvert.................Conversion..............Conversæ.o..............µ¥Î»»»Ëã................Conversion..............Conversion...................01.00.0000..2010.0813.0920......". To make things more difficult the geometry app has a bunch of $0 and $7 code in a random order after the initial text. For example a segment of it is "77 77 77 77 77 77 77 77 70 00 00 00 00 07 77 77". The majority of all of the data is 7's. Does anybody have any ideas of what this could be? Not all the apps have this though.
(http://img.removedfromgame.com/imgs/0-DispCap1.bmp)(http://img.removedfromgame.com/imgs/DispCap2.bmp)
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 27, 2010, 03:38:48 am
Wait so are you guys actually modifying the Casio OS to change the menu icons? Unfortunately I'm not tech-savy about that stuff so I am not sure what you are doing. If you are actually editing the OS then sending it to the calc fine, then this is epic. O.O (On the 83+, we had to factor RSA keys to sign third-party OSes)
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 27, 2010, 03:42:37 am
No, he's modify the Casio equivalent of an Application and sending it to his calc. The OS itself has to wait for a bit before we're ready for it.

@z80: I'm not entirely sure about the other stuff, but the text has to do with language localization. On some of the other add-ins, you may notice that the text is actually the title in other languages. You'll notice similar stuff was done with much of the internal text as well.

Also, it would appear from manufacturer documentation that if your program has the proper permissions, you can multiply the clock requency by up to six times, giving a processor ceiling of 174 MHz. The downside is that you need to wait ~100 ms after switching the frequency to start processing again.

source (http://resource.renesas.com/lib/eng/e_learnig/superh_e_learning/36/index.html)
Title: Re: Casio Prizm documentation
Post by: z80man on December 27, 2010, 03:49:01 am
All I'm doing is taking one of the add-in apps, changing some of the data in a hex editor and then sending it back to the calc. I'm not actually making any OS changes though. Changing the image data causes the OS to refuse to run the app even though it is still displayed on the main menu. Actually after changing any of the code whether it is in the header or not causes the OS to refuse to run app. It's as if the OS knows exactly what the app is supposed to look like.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 27, 2010, 03:50:52 am
I suspect they've hidden a checksum or security bytes in their header. Let me take a look.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 27, 2010, 03:51:30 am
Oh ok. So I wonder if it will need some sort of signing?
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 27, 2010, 03:59:02 am
I think my suspicions were right.

Z80, what happens if you change only things that are FF to 00 and vice versa?
Title: Re: Casio Prizm documentation
Post by: uberspire on December 27, 2010, 04:17:30 am
After changing some of the data you can see a change in the icon, but then the app becomes unrunnable. Any ideas why would be helpful.
The first 2 bytes in the headers are 0xAA and 0xAC, right? On the fx-9860, to disable the checksum you would change the first byte (0xAA) to 0xAC. Try and see if that works.
Title: Re: Casio Prizm documentation
Post by: z80man on December 27, 2010, 04:25:51 am
The app still won't run. It seems that the check sum for all apps in between 0x0000 and 0x003F. For conversion app it is AA AC BD AF 90 88 9A 8D D3 FF FE FF FE FF 16 FE FF F4 75 57 9F 00 49 12 00 00 00 00 00 00 00 00 04 1D D1 DC 01 01 00 00 00 00 00 00 00 00 00 0B 1A A4 00 00 00 00 00 00 00 00 00 00 00 00 00 00. About 75% of it identical to other apps
Title: Re: Casio Prizm documentation
Post by: z80man on December 27, 2010, 04:31:55 am
After changing some of the data you can see a change in the icon, but then the app becomes unrunnable. Any ideas why would be helpful.
The first 2 bytes in the headers are 0xAA and 0xAC, right? On the fx-9860, to disable the checksum you would change the first byte (0xAA) to 0xAC. Try and see if that works.
I tried changing the first byte from $AA to $AC, but the app is still not running.
Title: Re: Casio Prizm documentation
Post by: JosJuice on December 27, 2010, 04:38:07 am
After changing some of the data you can see a change in the icon, but then the app becomes unrunnable. Any ideas why would be helpful.
The first 2 bytes in the headers are 0xAA and 0xAC, right? On the fx-9860, to disable the checksum you would change the first byte (0xAA) to 0xAC. Try and see if that works.
I tried changing the first byte from $AA to $AC, but the app is still not running.
What happens if the first byte of an unmodified app is changed to 0xAC?
Title: Re: Casio Prizm documentation
Post by: z80man on December 27, 2010, 04:40:54 am
After changing some of the data you can see a change in the icon, but then the app becomes unrunnable. Any ideas why would be helpful.
The first 2 bytes in the headers are 0xAA and 0xAC, right? On the fx-9860, to disable the checksum you would change the first byte (0xAA) to 0xAC. Try and see if that works.
I tried changing the first byte from $AA to $AC, but the app is still not running.
What happens if the first byte of an unmodified app is changed to 0xAC?
ah ha!! I figured it out!!! ;D ;D ;D ;D The OS uses a modular sum checksum. So as long as I keep the sum of all the bytes added together the app will run. All we need to do now is find out where this sum is located that way we can start modifying some code. Also if you change the first byte to $AC the app does not run.
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 27, 2010, 11:37:08 am
After changing some of the data you can see a change in the icon, but then the app becomes unrunnable. Any ideas why would be helpful.
The first 2 bytes in the headers are 0xAA and 0xAC, right? On the fx-9860, to disable the checksum you would change the first byte (0xAA) to 0xAC. Try and see if that works.
I tried changing the first byte from $AA to $AC, but the app is still not running.
What happens if the first byte of an unmodified app is changed to 0xAC?
ah ha!! I figured it out!!! ;D ;D ;D ;D The OS uses a modular sum checksum. So as long as I keep the sum of all the bytes added together the app will run. All we need to do now is find out where this sum is located that way we can start modifying some code. Also if you change the first byte to $AC the app does not run.
Excellent news there!

I was thinking that maybe they did the two separate icons in case you wanted to change what it was when it was selected.  Also, how did you figure it out? That it was modular sum checksum, I mean.
Title: Re: Casio Prizm documentation
Post by: z80man on December 27, 2010, 01:20:46 pm
Yes there are two icons in the header one at 0x1000 and the other at 0x4000. The former is for when the cursor is off the icon and the latter is when it is on. How I figured out a modular sum checksum was used, Whenever I changed some data in the program I would keep track of how much much I added or subtracted from each byte and When I was done the net change must be at 0. eg. If there is a byte that reads $C0 and I change it $B0 then I must add $10 to another byte. So $60 becomes $70
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 27, 2010, 03:38:03 pm
Yes there are two icons in the header one at 0x1000 and the other at 0x4000. The former is for when the cursor is off the icon and the latter is when it is on. How I figured out a modular sum checksum was used, Whenever I changed some data in the program I would keep track of how much much I added or subtracted from each byte and When I was done the net change must be at 0. eg. If there is a byte that reads $C0 and I change it $B0 then I must add $10 to another byte. So $60 becomes $70
And that's how the file gets accepted. Alright, good. In which case, do you know what the bit length is for the field is? I bet you could figure it out by changing enough data so that if the lower part (say the low 16 bits) are the same, but the higher part isn't, would it reject it?

As in, say your sum was $C9ED. If it only took the lower 8 bits in the checksum, then that means that you can change a bunch of bytes to get $D6ED or something, and you would know that only the lower 8 bits are used in the checksum because the file still transferred.

If we did that, we could possibly figure out where the checksum is. Does the header use fixed location stuff, or does it have ID's of some sort to say that this piece of information is the pic, this piece is the second pic, etc.?
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 27, 2010, 04:23:16 pm
It almost certainly uses fixed location stuff from what I've seen, but we'd have to see a disassembly to confirm it.
Title: Re: Casio Prizm documentation
Post by: z80man on December 27, 2010, 05:14:33 pm
It appears more than one checksum is used. After running a checksum-32 algorithim on the conversion app I got 0027DB. At 0x0020 in the code appears 0027D864. On the Geometry app the algorithim got a result of 014DD578 and at 0x0020 was 014DD1DC. So the checksum doesn't include the entire code. I can't figure out what part is left out though. For the geometry app the first part of the header is AA AC BD AF 90 88 9A 8D D3 FF FE FF FE FF 16 FE FF F4 75 57 9F 00 49 12 00 00 00 00 00 00 00 00 04 1D D1 DC 01 01 00 00 00 00 00 00 00 00 00 0B 1A A4 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 27, 2010, 05:25:00 pm
okay, so that makes it 40 bits? That doesn't seem right. I would think maybe 64 bits at most.  The question is, where is it that the bytes aren't used.  Also, it could be that a checksum is encrypted with something like RSA too.  That would still cause things with the same checksum to have the same signature.
Title: Re: Casio Prizm documentation
Post by: z80man on December 27, 2010, 05:33:41 pm
New find. I believe this is a 32 bit number. At 0x002E on the geometry app is 000B1AA4 which just so happens to be the exact size of the program not including the header. On the conversion app I get 000001F8 also the size of the program not including the header.
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 27, 2010, 05:43:05 pm
Is there a wiki where all this information is being documented?
Title: Re: Casio Prizm documentation
Post by: z80man on December 27, 2010, 06:13:48 pm
There needs to be a site like wikiti.brandonw.net/ (http://wikiti.brandonw.net/) but for casio calcs
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 27, 2010, 07:01:39 pm
There needs to be a site like wikiti.brandonw.net/ (http://wikiti.brandonw.net/) but for casio calcs
I know how to host one on wikidot. Not a wiki per se, though. Just a place to hold info for the time being.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 27, 2010, 07:09:30 pm
My hosting provider refuses to support the software <_<
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 27, 2010, 07:41:26 pm
That's no fun. I can set up a wikidot site pretty easily. I did a fairly basic one for otcalc.wikidot.com.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 27, 2010, 10:54:59 pm
Otherwise it could maybe be put in a topic, but that might get hard to read eventually. I could host a wiki on my other webspace, though, if you don't want to setup a wikidot.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 27, 2010, 11:28:59 pm
This is pure speculation, but it would appear that the Prizm has 61 KB of RAM. If you calculate the bytes, that works out to an address of F400. The hex surrounding that address is:

Code: [Select]
...
0000F3A0:  73 8E 73 8E 7B CF 73 8E 73 8E 7B CF 73 8E 73 8E
0000F3B0:  0D 0A 7B CF 73 8E 73 8E 7B CF 73 8E 73 8E 7B CF
0000F3C0:  73 8E 0D 0A 73 8E 7B CF 73 8E 73 8E 7B CF 73 8E
0000F3D0:  73 8E 73 8E 0D 0A 7B CF 73 8E 73 8E 7B CF 73 8E
0000F3E0:  73 8E 73 8E 73 8E 0D 0A 7B CF 73 8E 73 8E 73 8E
0000F3F0:  7B CF 73 8E 73 8E 73 8E 0D 0A 73 8E 73 8E 73 8E
0000F400:  73 8E 6B 4D 42 2E 21 2E 2E 2E 0D 0A 2E 2E 2E 2E
0000F410:  2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 0D 0A 2E 2E
0000F420:  2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 0D 0A
0000F430:  2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E
0000F440:  0D 0A 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E
0000F450:  2E 2E 0D 0A 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E
0000F460:  2E 2E 2E 2E 0D 0A 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E
...


That may not be very clear, so here's the ASCII equivalent:

Code: [Select]
...
0000F3A0  sŽsŽ{ÏsŽsŽ{ÏsŽsŽ
0000F3B0  {ÏsŽsŽ{ÏsŽsŽ{ÏsŽ
0000F3C0  sŽ{ÏsŽsŽ{ÏsŽsŽsŽ
0000F3D0  {ÏsŽsŽ{ÏsŽsŽsŽsŽ
0000F3E0  {ÏsŽsŽsŽ{ÏsŽsŽsŽ
0000F3F0  sŽsŽsŽsŽkMB.!...
0000F400  ................
0000F410  ................
0000F420  ................
0000F430  ................
0000F440  ................
0000F450  ................
0000F460  ................
...
Title: Re: Casio Prizm documentation
Post by: 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? Maybe there's much more for the screen and other stuff.
Title: Re: Casio Prizm documentation
Post by: uberspire on December 28, 2010, 02:24:34 am
@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 (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.

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.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 28, 2010, 02:38:25 am
Kucalc, thanks for linking that. I have the .g3p file format on my end and the first fourteen bytes of the header are almost identical except for one byte.

.g1a files:

AA AC BD AF 90 88 9A 8D 0C FF EF FF EF FF

.g3p files:

AA AC BD AF 90 88 9A 8d 82 FF EF FF EF FF

This header is the same for all of the 20 or so picture files that I have checked, so it's constant.
Title: Re: Casio Prizm documentation
Post by: JosJuice on December 28, 2010, 08:06:58 am
Has anyone been able to successfully run a modified add-in on the Prizm yet? I can't really understand if the checksum(s) have been figured out already...
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 28, 2010, 05:58:19 pm
We've been able to come close, I think.
For a .g3a file:
AA AC BD AF 90 88 9A 8D D3 FF FE FF

Let's see:
0Ch=0000 1010b=.g1a
82h=1000 0010b=.g3p
D3h=1101 0011b=.g3a

And what are each of those file formats for? This probably means that they are an identification byte.  I don't think they randomly did constants if they are identification files, though. I think that each bit might mean something. In other words, it might be both an identifier, and a flag for that type.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 28, 2010, 06:30:46 pm
.g1a: fx-9860 add-in.
.g3p: fx-CG10/20 picture file.
.g3b: fx-CG10/20 animation file.
.g3a: fx-CG10/20 add-in.

.g3b:
AA AC BD AF 90 88 9A 8D 82 FF EF FF

Same as the .g3p header, which means that the byte doesn't directly translate to a specific filetype. It might relate to how the OS should run it, though. The .g3b format is basically a series of images one after another.
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 28, 2010, 06:35:55 pm
Or that they have the same identification byte. Maybe it's the app that should run it, or something.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 28, 2010, 06:38:51 pm
That's basically what I was saying  :P

Title: Re: Casio Prizm documentation
Post by: z80man on December 28, 2010, 11:40:12 pm
Does anyone know a good disassembler for the SH3
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 29, 2010, 12:00:52 am
I'm currently working with the KPIT GNU tools (http://www.kpitgnutools.com/latestToolchain.php). You have to register to use them, but they're free.
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 29, 2010, 02:15:58 pm
That's basically what I was saying  :P
Oops, sorry. How many other file types are there? What happens if you change the 82 to a 2? or try changing the 82 to C.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 29, 2010, 05:33:45 pm
There are 15 file types:

.g1m
.g1m
.g2m
.g3m
.g1r
.g2r
Data files
.g1e
.g2e
.g3e
E-activity files
.g3aAdd-ins
.g3lAdd-ins and menus
.g3pPicture files
.g3bAnimation files
.bmpScreenshot picture file
.txtText file
.csvCSV file (Matrix, list, or spreadsheet)
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 29, 2010, 05:36:39 pm
And do we have those bytes for all the files? Excluding .bmp, .txt, and .csv of course. And why is hello world listed at the top?
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 29, 2010, 05:42:06 pm
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.

Title: Re: Casio Prizm documentation
Post by: jnesselr on December 29, 2010, 05:43:32 pm
Oh, okay, I see it now. Well, let's attempt to get all the files, then. ;-) Does casio have a main site like education.ti.com?
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 29, 2010, 05:48:28 pm
Here it is:

https://edu.casio.com/download_service/download/category.php (https://edu.casio.com/download_service/download/category.php)
Title: Re: Casio Prizm documentation
Post by: z80man on December 30, 2010, 12:54:02 am
As with previous casio calcs there is a seven byte copy protection at 0x000E, but I can't tell if anyone has cracked it yet. I believe its supposed to be some sort of checksum of the first 32 bytes of the header. Also these sven bytes are largely similar between the picture plot apps and the geometry apps, but not the conversion app
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
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 30, 2010, 12:59:39 am
@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 (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.

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.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 30, 2010, 01:17:47 am
Looks like we're already working on the hacking  :P
Title: Re: Casio Prizm documentation
Post by: z80man on December 30, 2010, 01:23:55 am
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.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 30, 2010, 01:28:01 am
Interesting. Also, I noticed in the .g3p files that certain bytes were copied from other locations in the code, in addition to the aforementioned subtraction.

Of course, I have to credit Xeda for pointing it out to me.
Title: Re: Casio Prizm documentation
Post by: Builderboy on December 30, 2010, 01:32:15 am
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?
Title: Re: Casio Prizm documentation
Post by: z80man on December 30, 2010, 02:05:29 am
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?
Yes if we swap two bytes programs still run. Also at address 0x0020 there is a checksum of the program, but it excludes a few bytes which I have not found yet. There is also a checksum of just the first 32 bytes of the header, but i hav not found that either. So far though most of the header is cracked. Currently I'm writing documentation file for the entire app header which is $7000 bytes long. If we're lucky we could get a test NOP app running before the year ends.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 30, 2010, 03:21:55 am
Looks like we're already working on the hacking  :P
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).
Title: Re: Casio Prizm documentation
Post by: Builderboy on December 30, 2010, 03:35:32 am
It doesn't sound like they care, nor does it sound like its possible for them to block us without breaking compatibility with the previous apps written.  I'll make an analogy to the Apps in the 84/83 series, these apps are like those.  And just like the apps we are used to, these new ones have special data and stuff to make the calculator recognize them and run them.  After we figure out how to get that to work, we can replicate it and the calculator will not even be able to tell the difference :) As far as i have heard, the apps aren't even signed O.O
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 30, 2010, 12:34:25 pm
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.
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 30, 2010, 05:16:41 pm
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?
Yes if we swap two bytes programs still run. Also at address 0x0020 there is a checksum of the program, but it excludes a few bytes which I have not found yet. There is also a checksum of just the first 32 bytes of the header, but i hav not found that either. So far though most of the header is cracked. Currently I'm writing documentation file for the entire app header which is $7000 bytes long. If we're lucky we could get a test NOP app running before the year ends.
That's awesome, really. I wish I had a prizm, because I would write the program to test the checksum for you, and have it automatically try and resent it. It shouldn't be too hard.

I'm eager to try and break the usb protocol. If anyone wants to give me a data logging for usb, and the file that they sent/received, I would be very happy, and would try and analyze it. (Simple USB Logger file is a free logger, or of you can log the bytes to a text file, that would be fine, too.)
Title: Re: Casio Prizm documentation
Post by: calc84maniac on December 30, 2010, 08:03:06 pm
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?
Yes if we swap two bytes programs still run. Also at address 0x0020 there is a checksum of the program, but it excludes a few bytes which I have not found yet. There is also a checksum of just the first 32 bytes of the header, but i hav not found that either. So far though most of the header is cracked. Currently I'm writing documentation file for the entire app header which is $7000 bytes long. If we're lucky we could get a test NOP app running before the year ends.
That's awesome, really. I wish I had a prizm, because I would write the program to test the checksum for you, and have it automatically try and resent it. It shouldn't be too hard.

I'm eager to try and break the usb protocol. If anyone wants to give me a data logging for usb, and the file that they sent/received, I would be very happy, and would try and analyze it. (Simple USB Logger file is a free logger, or of you can log the bytes to a text file, that would be fine, too.)
Doesn't the Prizm just pretend to be a mass storage device?
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 30, 2010, 08:27:51 pm
Well, it's so good at pretending that it will even give up its internal data like a USB device  ;D
Title: Re: Casio Prizm documentation
Post by: calc84maniac on December 30, 2010, 08:29:02 pm
Well, it's so good at pretending that it will even give up its internal data like a USB device  ;D
Sauce?
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 30, 2010, 08:35:40 pm
 Sauce? ???
Title: Re: Casio Prizm documentation
Post by: calc84maniac on December 30, 2010, 08:37:28 pm
Sauce? ???
Meaning, source. Where did you get that info? (I assume you meant accessing data in the Prizm that's not in the normal filesystem)
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 30, 2010, 08:39:26 pm
Oh, I figured out how to read the internal binaries of USB devices with certain software and FinaleTI used it to get a memory dump off of the Prizm.
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 30, 2010, 09:43:57 pm
Oh, then can you check if it's got any other configurations? or anything? A full readout of the descriptors and such. If it's only the mass storage class, and nothing else, then that's fine.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 30, 2010, 10:31:03 pm
Would you like the file? It's some 80 MB of hex codes  :P
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 30, 2010, 10:43:39 pm
I already have the disassembly, think.  I don't understand it all that much.  I was given a .7z and it gave me an .rtf file. It's got hex on the left and a bunch of characters on the right.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 30, 2010, 10:47:09 pm
Those characters are the ASCII characters represented by the hex. For example, if the byte was 0x41h, then you would see A. If it was 0x42h, then you would see B and so on. The hex characters are just the memory addresses represented by the first character on each line. The offset at the top describes how much you should add to the those base hex numbers to get the memory location of the character in that column.
Title: Re: Casio Prizm documentation
Post by: jnesselr on December 30, 2010, 11:04:38 pm
so wait, getting this is normal? Okay, I'm writing a converter for that later. ;-)
Code: [Select]
Offset(h)
00000000  ë<.MSDOS5.0.....
00000010  ...v€ø..........
00000020  ....€.)....NO NA
00000030  ME    FAT16   ..
00000040  ................
00000050  ................
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 30, 2010, 11:06:27 pm
Yep. That's exactly what you should be seeing. Once you erase the address markers and run it through hex editor, you can see the internal hex. It also allows you to disassemble the memory.
Title: Re: Casio Prizm documentation
Post by: z80man on December 31, 2010, 12:03:18 am
Oh, I figured out how to read the internal binaries of USB devices with certain software and FinaleTI used it to get a memory dump off of the Prizm.
What certain software is this for I've been dying to get a memory dump off my Prizm
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 31, 2010, 12:04:46 am
HxD (http://mh-nexus.de/en/hxd/)

The only problem is that you have to somehow remove the addresses. A disk copier would probably work better, but I can't recommend any.
Title: Re: Casio Prizm documentation
Post by: z80man on December 31, 2010, 12:10:52 am
Oh I've been using Hxd. I just forget opening up a disk was a feature I could use.
btw there are only 4 more bytes left in the 28,672 app header that I still need to solve. Latest find is what bytes are not counted in the checksum. First off is the 32 bit checksum at 20h and the other is a copy of that checksum at the very end of the code.
Title: Re: Casio Prizm documentation
Post by: Ashbad on December 31, 2010, 11:30:03 am
hey, what processor is it using?  Sorry, been inactive while that was discussed, i'm sure :P
Title: Re: Casio Prizm documentation
Post by: JosJuice on December 31, 2010, 11:35:50 am
hey, what processor is it using?  Sorry, been inactive while that was discussed, i'm sure :P
SuperH 3, or something like that. I'm sure that the acronym is SH3, though.
Title: Re: Casio Prizm documentation
Post by: Ashbad on December 31, 2010, 11:39:09 am
I read somewhere it's a reduced instruction 32 bit processor... I wonder just exactly what that means, and if it's just 32 bit but really simple.  Becuase from what I read so far, it's a Fx9860 with a color screen and some other cool widgets, and that type of stuff doesn't need much of a processor to handle.  Hell, you could make a z80 processor handle 65535 colors theoretically. ;)

Should I get this? 

Edit:  is this the wrong topic to ask that last line?
Title: Re: Casio Prizm documentation
Post by: JosJuice on December 31, 2010, 11:42:34 am
I read somewhere it's a reduced instruction 32 bit processor... I wonder just exactly what that means, and if it's just 32 bit but really simple.
It is 32-bit, but I don't know anything about reduced instructions... I haven't read a lot about the processor.
Should I get this?
Buy a Prizm? Well, you might want to wait until an SDK or hack is released... Or you can buy one now and start trying to hacking it :P
Title: Re: Casio Prizm documentation
Post by: Ashbad on December 31, 2010, 11:49:07 am
I'll wait :P

thanks for the tips.
/me starts researching on the processor
Title: Re: Casio Prizm documentation
Post by: Munchor on December 31, 2010, 11:50:52 am
I googled stuff about that processor, there's almost no information!

http://en.wikipedia.org/wiki/SH-3_(SuperH) (http://en.wikipedia.org/wiki/SH-3_(SuperH))

All I found was Wikipedia stuff.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 31, 2010, 12:54:33 pm
I read somewhere it's a reduced instruction 32 bit processor... I wonder just exactly what that means, and if it's just 32 bit but really simple.  Becuase from what I read so far, it's a Fx9860 with a color screen and some other cool widgets, and that type of stuff doesn't need much of a processor to handle.  Hell, you could make a z80 processor handle 65535 colors theoretically. ;)

Should I get this? 

Edit:  is this the wrong topic to ask that last line?

If you want some more information:

The SH3 is a RISC processor normally operating at 29 MHz (although it can be "overclocked" to 178 MHz). It runs off of SH3 Assembly (obviously :P), which is an odd assembly language with weird functions like error handling.

The term RISC just means that they reduced the number of instructions so that every instruction can operate in 1 cycle. In other words, you're getting more bang for your assembly buck.
Title: Re: Casio Prizm documentation
Post by: Munchor on December 31, 2010, 12:56:25 pm
Qwerty, so Assembly programming for the PRIZM will not be an easy option, it seems.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 31, 2010, 01:03:54 pm
Not if you're used to z80  :P

Otherwise it shouldn't be too difficult.
Title: Re: Casio Prizm documentation
Post by: Munchor on December 31, 2010, 01:10:28 pm
Not if you're used to z80  :P

Otherwise it shouldn't be too difficult.

You mean, it is similar to stuff like ld hl,10, I mean, similar to Z80 Assembly?
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 31, 2010, 01:29:19 pm
Well, it's slightly more complicated. You have to determine if 10 is a full word and adjust the instructions appropriately. The registers are also all messed up because you have a hardware floating point unit to "help" out.
Title: Re: Casio Prizm documentation
Post by: willrandship on December 31, 2010, 01:31:17 pm
If an SDK is released, I hope it at least supports true assembly. TI's ti-83+ SDK for making apps sucks compared to real ASM. It's actually worse than Axe, and still needs to be compiled on the computer :P
Title: Re: Casio Prizm documentation
Post by: z80man on December 31, 2010, 02:30:17 pm
Not if you're used to z80  :P

Otherwise it shouldn't be too difficult.

You mean, it is similar to stuff like ld hl,10, I mean, similar to Z80 Assembly?
If you are experienced with any sort of x86 assembly the SH3 instruction set should be familiar to you. Otherwise you will have to get used to new commands. Ld Hl,10 is now mov R8,10.
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 31, 2010, 02:35:05 pm
That would be mov.B R8, 10 ;)
Title: Re: Casio Prizm documentation
Post by: Builderboy on December 31, 2010, 02:44:48 pm
Well hardware floating point sure sounds like something that could be useful O.O
Title: Re: Casio Prizm documentation
Post by: AngelFish on December 31, 2010, 02:46:33 pm
I've had this for quite awhile, so I suppose I should just post it already  :P

http://lars.nocrew.org/computers/processors/SuperH/sh4cpu_sh1.pdf (http://lars.nocrew.org/computers/processors/SuperH/sh4cpu_sh1.pdf)
Title: Re: Casio Prizm documentation
Post by: z80man on December 31, 2010, 04:56:24 pm
I compiled the known app header into one file. There are still a few hole to be figured out though.
Title: Re: Casio Prizm documentation
Post by: JosJuice on December 31, 2010, 05:23:41 pm
Do you think you can add that to the wiki?
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on December 31, 2010, 05:24:13 pm
Nice z80man!
Title: Re: Casio Prizm documentation
Post by: z80man on December 31, 2010, 05:25:42 pm
Do you think you can add that to the wiki?
Yes I'll try and get that up.  ;D
Title: Re: Casio Prizm documentation
Post by: JosJuice on December 31, 2010, 05:26:56 pm
Excellent. The wiki will probably be useful. We just need to add what we've discovered (and we should also discover more stuff :P)
Title: Re: Casio Prizm documentation
Post by: z80man on December 31, 2010, 05:34:00 pm
I compiled the known app header into one file. There are still a few hole to be figured out though.
There was a small typo in the file. The new one is here.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 01, 2011, 08:31:50 pm
Anyone who uses ASM for this will never need to use RAM with all. There are 24 general purpose registers alone, even if you can only access 16 of them O.O
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 01, 2011, 08:38:47 pm
Nice, that's much better than the z80 at least. The 83+ had like 8, right?

Also, I hope that if Casio ever releases Prizm documentation that it won't be translated from Japanese to Zero Wing language...
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 01, 2011, 08:42:04 pm
 O.O
Title: Re: Casio Prizm documentation
Post by: z80man on January 02, 2011, 12:46:02 am
Anyone who uses ASM for this will never need to use RAM with all. There are 24 general purpose registers alone, even if you can only access 16 of them O.O
Nice, that's much better than the z80 at least. The 83+ had like 8, right?

Also, I hope that if Casio ever releases Prizm documentation that it won't be translated from Japanese to Zero Wing language...
And those 8 the 83+ had were 8 bit registers. The Prizm's 16 are all 32 bit.  ;D
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 02, 2011, 01:47:21 am
Well, the general purpose ones are. Many system registers are 16 bit, such as FRQCR and STBCR 1 & 2.

Anyway, where did you get 148 MHz from (on the other thread)? The FRQCR register can only handle integers 1-6.
Title: Re: Casio Prizm documentation
Post by: calcforth on January 02, 2011, 04:20:02 am
Well hardware floating point sure sounds like something that could be useful O.O
Well, it depends on what you are trying to do. Hardware FPU is obviously faster, but then 0.2+0.2+0.2+0.2+0.2 is not equal to 1.0 and this baffles people (even if absolutely correct if you go by IEEE specification).

Wild guess: Prizm uses it in assembly programs do draw graphs and such, but not in BASIC (to not confuse people).
Title: Re: Casio Prizm documentation
Post by: z80man on January 04, 2011, 01:48:02 am
Well hardware floating point sure sounds like something that could be useful O.O
Well, it depends on what you are trying to do. Hardware FPU is obviously faster, but then 0.2+0.2+0.2+0.2+0.2 is not equal to 1.0 and this baffles people (even if absolutely correct if you go by IEEE specification).

Wild guess: Prizm uses it in assembly programs do draw graphs and such, but not in BASIC (to not confuse people).
The Prizm may or may not have internal floating point support. The SH3E is the version of the SH3 that incorporates the FPU. Most likely though Casio just used the standard SH3 and did floating point claculations in software as they would would have no need for the added speed.
Title: Re: Casio Prizm documentation
Post by: Goplat on January 05, 2011, 03:47:27 pm
so wait, getting this is normal? Okay, I'm writing a converter for that later. ;-)
Code: [Select]
Offset(h)
00000000  ë<.MSDOS5.0.....
00000010  ...v€ø..........
00000020  ....€.)....NO NA
00000030  ME    FAT16   ..
00000040  ................
00000050  ................

Unfortunately, if all non-displayable bytes have been turned into '.', there's no way you can tell what bytes they were supposed to be originally.

Here's a little program I wrote to get a raw binary dump of a drive. Run it from the command line, with the drive letter and output file as parameters (e.g. If your Prizm is drive X and you want to call the dump prizmdump.bin, you would run "dumpdrive X prizmdump.bin")
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 05, 2011, 03:49:47 pm
Thanks, Goplat.
Title: Re: Casio Prizm documentation
Post by: FinaleTI on January 05, 2011, 03:59:48 pm
Nice. I'll have to give that a try with my Prizm later.
Title: Re: Casio Prizm documentation
Post by: JosJuice on January 05, 2011, 04:00:54 pm
(http://s465.photobucket.com/albums/rr16/DinnerLink/asd1.png)

/me becomes excited
Title: Re: Casio Prizm documentation
Post by: FinaleTI on January 05, 2011, 08:21:54 pm
Kay. I just dumped my Prizm using Goplat's program.  ;)
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 05, 2011, 08:23:09 pm
cool :D

By the way, FinaleTI did you mess around with Prizm BASIC a bit more?
Title: Re: Casio Prizm documentation
Post by: FinaleTI on January 05, 2011, 08:23:47 pm
Not really. I should, but I've been working on my 83/84 projects.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 05, 2011, 08:24:48 pm
ah ok. Let us know if you do. I am curious about the speed of various functions.

Hopefully maybe I might be able to check later, when my Prizm arrives via the mail.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 05, 2011, 08:48:49 pm
Kay. I just dumped my Prizm using Goplat's program.  ;)


PM?  :angel:
Title: Re: Casio Prizm documentation
Post by: z80man on January 05, 2011, 08:50:36 pm
I was a little dissapointed by Prizm Basic. Pure math wise it is a little faster than the 83/84, but any screen drawing is very slow. The locate command is actually slower than than output by about 25%. The f line and vertical/horizontal commands are also slow, but the worst is pixel drawing. Just to draw a pixel line across the screen took me over a minute. Its not all bad though. There are many advanced string manipulation commands avaible such as all caps/lowercase, but I'm not sure how useful they will be. Probally the best feature though is the Prizm's ability to convert programs into txt files and txt into programs.
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 05, 2011, 09:57:23 pm
Kay. I just dumped my Prizm using Goplat's program.  ;)


PM?  :angel:
Ditto? : devil : :angel:
Title: Re: Casio Prizm documentation
Post by: JosJuice on January 06, 2011, 03:05:56 am
Kay. I just dumped my Prizm using Goplat's program.  ;)


PM?  :angel:
Ditto? : devil : :angel:
I want one too :angel:
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 06, 2011, 03:45:23 am
I was a little dissapointed by Prizm Basic. Pure math wise it is a little faster than the 83/84, but any screen drawing is very slow. The locate command is actually slower than than output by about 25%. The f line and vertical/horizontal commands are also slow, but the worst is pixel drawing. Just to draw a pixel line across the screen took me over a minute. Its not all bad though. There are many advanced string manipulation commands avaible such as all caps/lowercase, but I'm not sure how useful they will be. Probally the best feature though is the Prizm's ability to convert programs into txt files and txt into programs.
Ouch. I hope when the calc is overclocked that it runs at decent speed. Maybe someone could write a custom interpreter, though, or port Axe or a similar language to the calc. Let's just hope Prizm BASIC isn't as slow as AFX BASIC, though. O.O (20 times slower than the 9860G and the 83+ and twice slower than the old CFX series and FX-9750G+) Otherwise, if we don't find out how to crack the calc, we'll be stuck with another Nspire (well, less limited in programming, but less efficient in it)

Kay. I just dumped my Prizm using Goplat's program.  ;)


PM?  :angel:
If it involves distributing OS/ROM dumps, I would ask that such material is shared outside the forum/PM system, though, because it would be against the board rules due to copyrighted material.
Title: Re: Casio Prizm documentation
Post by: JosJuice on January 06, 2011, 04:09:42 am
Kay. I just dumped my Prizm using Goplat's program.  ;)


PM?  :angel:
If it involves distributing OS/ROM dumps, I would ask that such material is shared outside the forum/PM system, though, because it would be against the board rules due to copyrighted material.
What we're mostly trying to read right now is (I think) the OS, which is probably going to be released in the form of an OS update by Casio later. However, this doesn't change the fact that it's copyrighted code that we may end up in trouble with.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 06, 2011, 04:16:03 am

PM?  :angel:
If it involves distributing OS/ROM dumps, I would ask that such material is shared outside the forum/PM system, though, because it would be against the board rules due to copyrighted material.
[/quote]

Sorry.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 06, 2011, 02:18:12 pm
No problem, just making sure in case.
Title: Re: Casio Prizm documentation
Post by: z80man on January 06, 2011, 09:13:31 pm
Quote
Dear cunstomer,

Thank you for sending e-mail.
Also we would appreciate for your interest in Casio new scientific calculators.
However we regret to say that Casio has no schedule for disclosing the details of file format and releasing Software Development Kit for Prism as for now.
Your understanding would be highly appreciated.

Best regards,
Well I thought it wouldn't hurt to send an email to Casio Japan asking if they could provide some help on the file formats, but they're not interested. I probaly send a reply to convince them to give up some information. Otherwise on the app format I have just one last part to figure out, the 16 bit checksum. Doing some further research it probaly uses an algorthim known as crc-16. The difficulty with this format is that if your just off by one byte you get a very different answer. I was going to write a C++ program to test every possibility, but it turns out it would take my computer about 20 years to calculate this  :banghead: :banghead: :banghead:
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 06, 2011, 09:21:01 pm
Wait, they're using a CRC check?

Mein gott, they really don't want us to be able to make these...

Anyway, this might help. It includes a method to reverse CRC-16.

http://www.woodmann.com/fravia/crctut1.htm (http://www.woodmann.com/fravia/crctut1.htm)
Title: Re: Casio Prizm documentation
Post by: JosJuice on January 07, 2011, 03:01:48 am
Let's just hope they won't try to stop us once we've managed to run code.
Title: Re: Casio Prizm documentation
Post by: JosJuice on January 07, 2011, 02:25:36 pm
Sorry for the double post...

There's something I've been wondering for a while. How does the OS sort add-ins?
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 07, 2011, 02:35:04 pm
If I had to guess, it's in First in order. Whatever you put in last goes at the end of the list.
Title: Re: Casio Prizm documentation
Post by: JosJuice on January 07, 2011, 02:46:19 pm
So, if (for example) the Geometry app is deleted and then loaded into the calc again, it'll be at the end of the list?
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 07, 2011, 02:48:46 pm
Possibly.
Title: Re: Casio Prizm documentation
Post by: JosJuice on January 07, 2011, 02:51:59 pm
I just realized... What if it's sorted by date? Conversion is the oldest add-in, and Geometry is the newest one. Newer ones show up earlier in the list...
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 08, 2011, 02:38:41 pm
Here's some executable [machine] code for the Prizm:

Code: [Select]
1101100000000000
11111111111111111111111110000000
1001100100000000
0000000100010001
1101101000000000
11111111111111111111111010000110
1001101100000000
1010010101100101
1101110000000000
11111111111111111111111010000100
1001110100000000
0101101000000000
0010101010110010
0010110011010010
0010010010010010

If you translate into Hex:

Code: [Select]
D800
FFFF FF80
9900
0111
DA00
FFFF FE86
9B00
A565
DC00
FFFF FE84
9D00
5A00
2AB2
2CD2
2492

This will set the processor to 58 MHz, wait ~4 Milliseconds, then restart the processor to complete the changes. I've also attached an add-in made from a modified version of the Geometry add-in. It just lacks the checksums. An add-in could also be written from scratch if anyone is willing to do it.
Title: Re: Casio Prizm documentation
Post by: FinaleTI on January 08, 2011, 02:45:31 pm
Does it run? Or does it require the checksum. I could maybe test it, but do I just need to change the file extension, or something more?
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 08, 2011, 02:48:42 pm
Err, changing the file extension to .g3a would probably be a good idea. It *should* run, because I used Kucalc's method to disable the checksums, but I'm not sure. It will also reset your calculator, guaranteed.
Title: Re: Casio Prizm documentation
Post by: FinaleTI on January 08, 2011, 03:01:59 pm
I just tried sending it to my calc, and it showed up in the memory menu, but not the main menu. I even reset my Add-In memory and tried it again.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 08, 2011, 03:03:48 pm
Hm, that's odd. What does the title look like in the memory menu?
Title: Re: Casio Prizm documentation
Post by: FinaleTI on January 08, 2011, 03:08:17 pm
App.g3a is what is says in the memory menu.
It's recognized as an add-in, but it doesn't show up in the main menu, so I can't run it.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 08, 2011, 03:10:46 pm
Okay, that means that the memory menu reads from the VAT, while the main menu reads from the application header. I don't know why it won't run, though. Can you try this one (with Checksums enabled)?

You can delete add-ins, right?
Title: Re: Casio Prizm documentation
Post by: FinaleTI on January 08, 2011, 03:11:28 pm
Yep you can delete them. I'll try it in just a sec.
Title: Re: Casio Prizm documentation
Post by: FinaleTI on January 08, 2011, 03:13:22 pm
It still doesn't want to show up in the main menu.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 08, 2011, 03:15:14 pm
Well, I guess I can ask z80man about it when he logs on.

EDIT: The processor can only overclock to 116 MHz.
Title: Re: Casio Prizm documentation
Post by: JosJuice on January 08, 2011, 03:29:19 pm
EDIT: The processor can only overclock to 116 MHz.
aww ;_;

Where did you read that?
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 08, 2011, 07:05:22 pm
Quote
Dear cunstomer,

Thank you for sending e-mail.
Also we would appreciate for your interest in Casio new scientific calculators.
However we regret to say that Casio has no schedule for disclosing the details of file format and releasing Software Development Kit for Prism as for now.
Your understanding would be highly appreciated.

Best regards,
Well I thought it wouldn't hurt to send an email to Casio Japan asking if they could provide some help on the file formats, but they're not interested. I probaly send a reply to convince them to give up some information.
Maybe they're asking info to figure out how to block our third party apps in the future. Be careful.

Anyway I do not know if this is still valid since Qwerty is still posting here, but he e-mailed me earlier saying he won't have internet access except e-mail for a few days and to relay you the following info:

Quote
I believe that I may have an executable add-in, with the exception of the fact that it requires the addition of the checksums found by z80. Since no one knows about peripheral interfaces on the Prizm, it operates entirely within the processor and should overclock it to twice its normal speed. I was wrong before about needing to reset the processor to change speeds... changing speeds resets the processor. Anyway, I wrote the code and it's in an app right now.

Disregard this if the posts above explains that, I do not know much about that low level stuff. It seemed promising, though.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 08, 2011, 07:33:03 pm

Where did you read that?

Kucalc clarified some details about the processor, which apparently can only overclock to 4x.

And thanks DJ.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 08, 2011, 07:38:56 pm
No problem. I didn't take any chance and posted it anyway, because I did not know exactly when you would lose forum access. I was a bit busy lately, though, so I only saw your e-mail a few hours ago.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 08, 2011, 07:46:08 pm
Well, frankly I thought I would be somewhere else for the remainder of the weekend.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 08, 2011, 07:54:29 pm
Oh ok, lol. That happens I guess. Kinda like when I met Juju2143 in person in Quebec city. I was supposed to be gone for like 4 days, but finally managed to find some free time to get online.
Title: Re: Casio Prizm documentation
Post by: z80man on January 08, 2011, 10:57:12 pm
(http://img.removedfromgame.com/imgs/system.bmp) I edited Qwerty's program to use the exact same checksum of the conversion app and sent that to my Prizm. As expected when running the program the calc crashed with this screen. Weird thing was when I plugged in the usb cable for file transfer the calc crashed again, but with target reading E500D42F and PC at 00000004.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 08, 2011, 11:03:51 pm
Yay, it worked! So executable code is indeed possible on the Prizm.

I hope I didn't brick your Prizm though  :'(
Title: Re: Casio Prizm documentation
Post by: z80man on January 08, 2011, 11:13:32 pm
The error my Prizm has now seems fixable because only usb file transfer doesn't work. Screen capture still works. That's how I got the screen shot. I'll post the source code here, but it's only for examination DO NOT RUN IT!!!
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 08, 2011, 11:16:37 pm
/me is worried for z80's Prizm and feels guilty

What's the extent of the damage? Can you reset the Prizm to the factory defaults? Would sending a new OS work?
Title: Re: Casio Prizm documentation
Post by: z80man on January 08, 2011, 11:28:42 pm
All is fine.  :angel: I reset the archive and usb transfer works again. I'm wondering though, was my Prizm ever overclocked, even if for a just a few miliseconds.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 08, 2011, 11:34:26 pm
It was overclocked for approximately 4.3 milliseconds. The problem is that 4.3 milliseconds is how long the code told the processor to wait before it started executing again. So basically, your Prizm only executed one command while overclocked.
Title: Re: Casio Prizm documentation
Post by: JosJuice on January 09, 2011, 02:20:54 am
Did you just manage to run code? O.O
Or is that just the "checksum is wrong" error screen? If you have actually managed to run code, then this is epic...
Title: Re: Casio Prizm documentation
Post by: z80man on January 09, 2011, 02:47:42 am
Did you just manage to run code? O.O
Or is that just the "checksum is wrong" error screen? If you have actually managed to run code, then this is epic...
Yes this was code. I used an existing app as my base and modified to run Qwerty's program without changing the checksum.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 09, 2011, 01:56:56 pm
Wait, so to get the checksums to run, you modified the rest of the app to fit the checksum? Great job :D

By the way, if anyone wants to start learning the machine code, here's the instruction manual (http://documentation.renesas.com/eng/products/mpumcu/rej09b0317_sh_3sm.pdf). The instruction code in each description is the binary.
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 09, 2011, 04:02:07 pm
Wait, so to get the checksums to run, you modified the rest of the app to fit the checksum? Great job :D

By the way, if anyone wants to start learning the machine code, here's the instruction manual (http://documentation.renesas.com/eng/products/mpumcu/rej09b0317_sh_3sm.pdf). The instruction code in each description is the binary.
Thanks for the link, I'll look over it.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 10, 2011, 01:01:02 am
This is awesome! O.O
Title: Re: Casio Prizm documentation
Post by: TIfanx1999 on January 10, 2011, 08:08:34 am
Wow, this is really sweet guys! =)
Title: Re: Casio Prizm documentation
Post by: z80man on January 11, 2011, 10:34:57 pm
Until we get the checksums cracked (I'm still working on those) we can still have limited app development.  It  turns out he crc checksum is only of a few bytes, I believe the modular checksum and a few other bytes. This means that apps can be created as long as they have the same checksum of a previous written app. This can be done by making edits to the menu icon section of the header to correspond to changes made to the code. Depending on how much free time I have this weekend (final exams next week) I might be able to write a program to convert machine code into an app with the proper checksum. I will also try to convert the code for the conversion app into asm because it is the shortest. It will take some time because the app still has over 200 lines of code that I wil need to write out. Hopefully disassembling it will reveal how apps are called by the OS allowing us to write programs that don't try to kill our calcs.  :-\
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 12, 2011, 01:32:31 pm
Er, causing a full system reboot wasn't intentional. I think there's a way to cause the system to wait for a manual reset by changing a bit in the FRQCR register write, but I'll wait until I get my own Prizm to test it. We also need to understand the Prizm's I/O before we can do much. It's not much use to have to crash the Prizm or write all of user RAM to find the driver RAM to do I/O.
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 12, 2011, 06:41:42 pm
And that's hoping it is ram-based.  I'll be extremely happy if I find that the lcd is ram-based.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 12, 2011, 11:44:47 pm
Nice z80man, I'm looking forward for this. :)

Title: Re: Casio Prizm documentation
Post by: AngelFish on January 14, 2011, 12:58:24 pm
I've attached the hex equates every Assembly command recognized by the Prizm. I also tested them by disassembling part of the Geometry add-in, which is set at 0000F600 in Prizm-OS. The first fourteen bytes work out to this:
Code: [Select]
MOV.L R14,@–R15
STS.L PR,@–R15
ADD $FC,R15
MOV.L R4,@R15
MOV.L @($07*4+PC),R3
JSR @R3
MOV R14, R5

A cursory glance through the hex also appears to reveal a Sleep instruction (0x001Bh) at offset 000A46C. If that is correct, then it means that add-ins operate in privileged mode, which basically means that any executable code in an add-in has system level control.
Title: Re: Casio Prizm documentation
Post by: JosJuice on January 14, 2011, 01:03:35 pm
Um, the txt file is just a bunch of garbage when opened in Notepad... (Except for some parts)
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 14, 2011, 01:05:05 pm
Try opening it in unicode format.  :)

Here's the ANSI format if you can't.
Title: Re: Casio Prizm documentation
Post by: JosJuice on January 14, 2011, 01:07:13 pm
Thanks! This will probably be useful... Now I just need to figure out what every command does :P
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 14, 2011, 01:08:57 pm
As you can see, I got through describing 17 of the arithmetic commands, then I went to work on my cage match entry  :P
Title: Re: Casio Prizm documentation
Post by: z80man on January 14, 2011, 08:58:22 pm
I was recently working on disassembling the conversion app and got almost the same code. Just a few different registers.
Code: [Select]
MOV.L    R15,@-R16      ;Seems to operate similar to the Push instruction 
STS.L    PR,@-R16       ;adress to return to after program is finised running might be stored here
ADD      $FC, R16
MOV.L    R4,@R16
MOV.L    @($07*4,PC),R4
JSR      @R3            ;delayed branch, execute next instruction then jump, stores PC in PR so it might work like a call.
MOV      R5,R15
I just wish I knew what was stored in the registers when execution began.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 14, 2011, 10:04:02 pm
Z80, there's no R16 and the registers are zero indexed  ;)

Also, JSR is short for Jump to SubRoutine. It's essentially the same as Call in z80, in terms of functionality at least.
Title: Re: Casio Prizm documentation
Post by: z80man on January 14, 2011, 10:16:59 pm
Z80, there's no R16 and the registers are zero indexed  ;)

Also, JSR is short for Jump to SubRoutine. It's essentially the same as Call in z80, in terms of functionality at least.
Whoops. I must have messed up on my hex conversion. I think I might of started counting 1 so just decrement everything.

Edit: Also do you think that STS.L PR,@-R15 is the instruction that stores the return adress
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 14, 2011, 10:27:09 pm
Yep. STS.L PR,@–R15 stores R15-4 -> R15 and stores PR->R15
Title: Re: Casio Prizm documentation
Post by: calc84maniac on January 14, 2011, 10:28:05 pm
PR holds the return address (minus 4) after a subroutine is called. That instruction saves it to the stack so more subroutines can be called.
Title: Re: Casio Prizm documentation
Post by: z80man on January 15, 2011, 12:29:33 am
PR holds the return address (minus 4) after a subroutine is called. That instruction saves it to the stack so more subroutines can be called.
So on the SH3 there is no actual SP, you just have to use one of the registers.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 16, 2011, 04:38:16 pm
Nice! Should make it easier for people to learn SH3 assembly :D
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 16, 2011, 04:39:54 pm
Nice! Should make it easier for people to learn SH3 assembly :D
Yeah, not at all.  The simple instruction set usually makes it a little bit harder.  Especially when people are used to pushing and popping stuff all over the place.

Just my $.02 though.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 16, 2011, 04:42:07 pm
Oh, well, I don't know, I thought letting people know about the instruction set would actually help them, especially that they don't have to code in machine/hex code. X.x
Title: Re: Casio Prizm documentation
Post by: z80man on January 17, 2011, 02:38:47 am
I'm really not sure how popular asm coding for the Prizm will be. z80 asm is considered complex by many and that is probaly the easiest of all assembly languages. SH3 assembly will have even fewer users than z80. Once some libraries are written for the Prizm most programming will be done in either C or some version of Axe.
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 17, 2011, 10:27:11 am
I'm really not sure how popular asm coding for the Prizm will be. z80 asm is considered complex by many and that is probaly the easiest of all assembly languages. SH3 assembly will have even fewer users than z80. Once some libraries are written for the Prizm most programming will be done in either C or some version of Axe.

But, for the few of us that know assembly pretty well in SH3, or have the ability to learn it we could write something like 83 asm in 28 days.  I'm thinking Casio Prizm asm in 9001 days?
Title: Re: Casio Prizm documentation
Post by: JosJuice on January 17, 2011, 10:29:46 am
I'm really not sure how popular asm coding for the Prizm will be. z80 asm is considered complex by many and that is probaly the easiest of all assembly languages. SH3 assembly will have even fewer users than z80. Once some libraries are written for the Prizm most programming will be done in either C or some version of Axe.

But, for the few of us that know assembly pretty well in SH3, or have the ability to learn it we could write something like 83 asm in 28 days.  I'm thinking Casio Prizm asm in 9001 days?
I wonder if it would take 9001 days to write, as well... Then it would almost take 25 years!
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 20, 2011, 12:16:56 am
I'm really not sure how popular asm coding for the Prizm will be. z80 asm is considered complex by many and that is probaly the easiest of all assembly languages. SH3 assembly will have even fewer users than z80. Once some libraries are written for the Prizm most programming will be done in either C or some version of Axe.
Yeah I think this is why we need such language. Notice how most 68K programs were made in C. After TIGCC came out almost everyone switched from BASIC and ASM. On the z80 series now most people program in Axe.
Title: Re: Casio Prizm documentation
Post by: z80man on January 20, 2011, 12:24:06 am
For me I could never really get used to Axe. There is something about asm that I really enjoy. But when it comes to large projects on the Prizm I will have no choice, but to move to another language.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 20, 2011, 12:28:08 am
Yeah it depends of people really. Some people prefer lower level stuff and its freedom. I myself couldn't stand looking at the cryptic code x.x

Anyway right now I didn't do a lot of Prizm stuff yet. As for now I was filming myself launching WabbitEmu.exe on my computer from my Casio Prizm storage memory.
Title: Re: Casio Prizm documentation
Post by: z80man on January 20, 2011, 12:34:07 am
I'm guessing that booting Wabbit from the Prizm is quite slow. I'm not sure if the Prizm has enough memory for this, but imagine coding a very simple PC OS and placing that on the Prizm and then set your computer to boot from the Prizm. That would be awesome.  ;D
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 20, 2011, 12:39:42 am
Booting it seemed not too slow. It usually took between 2.5 and 3.5 seconds. It's sending it to the calc that took a long while. I sent a few other files too, for a total of 5 ish MB and it took a few minutes to transfer.
Title: Re: Casio Prizm documentation
Post by: z80man on January 20, 2011, 12:42:46 am
I'm hoping though that later versions include an SD card slot as that would be faster and have more memory.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 20, 2011, 12:49:26 am
Yeah that would be cool. However, didn't the 9860SD only come out in Australia? I remember one model came out there only and if I remember it was the SD one. But yeah it would be funny if people used stuff like Firefox Portable on that.
Title: Re: Casio Prizm documentation
Post by: critor on January 20, 2011, 06:05:04 am
Yeah that would be cool. However, didn't the 9860SD only come out in Australia? I remember one model came out there only and if I remember it was the SD one. But yeah it would be funny if people used stuff like Firefox Portable on that.

The fx-9860G AU which only came out in Australia has a fx-9860G hardware (no SD card) but an OS which only uses 800Kb of storage memory instead of 1.5Mb.

The fx-9860G AU+ is the same thing with a fx-9860Gii hardware (no SD card).
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 20, 2011, 12:18:37 pm
Well, DJ kind of ninja'd my Wabbit discovery, which I also coincidentally made last night  :P

On the other hand, I cracked the .g3m program format as well, so I'll stick with that. It's 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

EDIT: I also wrote a program by hand to test it. Thus, I introduce the new Prizm programming language: Hex BASIC. All the complexity of Hex, all the power of BASIC  :P
Title: Re: Casio Prizm documentation
Post by: JosJuice on January 20, 2011, 03:04:05 pm
Great! Soon none of the file formats will be able to hide from us.

Actually, I don't fully understand what you just wrote... :P I guess it might take a little time for me. And as always, it would be good if this documentation is added to the wiki.
Title: Re: Casio Prizm documentation
Post by: z80man on January 20, 2011, 04:47:49 pm
Great, but doesn't the OS convert g3m to txt and txt to g3m for us.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 20, 2011, 06:01:53 pm
This is actually what I plan on using to get small physical dumps of the OS. We would have to create the files on-calc and knowing the file format is pretty important for that. Plus, it'd help if anyone ever decided to make something like Axe, where you have to read the files.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 21, 2011, 01:44:08 am
Sorry for the double post, but I think this update is worthy enough:
executable assembly code can run without crashing! I modified the conversion app to accept some looping code and the calc finally doesn't crash. Everything appears to still be working, so my calc isn't bricked.
/me is happy

I just have to figure out I/O now :P
/me thanks Z80 for clarifying how to defeat the 32 bit checksum.
Title: Re: Casio Prizm documentation
Post by: JosJuice on January 21, 2011, 01:46:07 am
executable assembly code can run without crashing! I modified the conversion app to accept some looping code and the calc finally doesn't crash. Everything appears to still be working, so my calc isn't bricked.
/me is happy
:w00t:
/me thanks Z80 for clarifying how to defeat the 32 bit checksum.
:w00t::w00t::w00t:

Maybe this checksum stuff should be added to the wiki? ;D (yeah, I know I always talk about the wiki)
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 21, 2011, 01:53:39 am
I'd add a lot of stuff to the wiki if I access to the Internet when I have free time (IE at home), but ironically it's my busy day schedule that prevents me from getting it installed...
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 21, 2011, 02:05:43 am
Yeah that would be cool. However, didn't the 9860SD only come out in Australia? I remember one model came out there only and if I remember it was the SD one. But yeah it would be funny if people used stuff like Firefox Portable on that.

The fx-9860G AU which only came out in Australia has a fx-9860G hardware (no SD card) but an OS which only uses 800Kb of storage memory instead of 1.5Mb.

The fx-9860G AU+ is the same thing with a fx-9860Gii hardware (no SD card).
Oh I see. Wow, so they actually got fewer memory in Australia. X.x

Well, DJ kind of ninja'd my Wabbit discovery, which I also coincidentally made last night  :P

On the other hand, I cracked the .g3m program format as well, so I'll stick with that. It's 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

EDIT: I also wrote a program by hand to test it. Thus, I introduce the new Prizm programming language: Hex BASIC. All the complexity of Hex, all the power of BASIC  :P
Nice, glad to see more stuff being discovered or documented! I seriously hope about updates regarding being able to run  machine code, though, with some example programs, even if just small stuff like lines moving around the screen.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 21, 2011, 03:25:53 am
You'll have to wait for z80's work before anyone can write screen stuff. Speaking of Z80, I came upon some evidence that the OS naturally runs in 58 MHz mode. It's either that or the program crashed before writing to FRQCR or the OS switches to normal speed every time it exits the application, both of which I think are unlikely.

Yes, I was trying to overclock my Prizm :P
Title: Re: Casio Prizm documentation
Post by: fxdev on January 21, 2011, 07:45:19 am
Quote
Oh I see. Wow, so they actually got fewer memory in Australia. X.x
This is only true for the fx-9860G AU - not the fx-9860G AU Plus.
However, by installing the fx-9860GII OS on the former you get 1.5m of flash, too! ;D
Title: Re: Casio Prizm documentation
Post by: z80man on January 21, 2011, 03:18:13 pm
You'll have to wait for z80's work before anyone can write screen stuff. Speaking of Z80, I came upon some evidence that the OS naturally runs in 58 MHz mode. It's either that or the program crashed before writing to FRQCR or the OS switches to normal speed every time it exits the application, both of which I think are unlikely.

Yes, I was trying to overclock my Prizm :P

I'm just finishing up the screen program right now. If all goes well it shouls draw a couple of blue lines on the screen. Also I would agree the OS runs at 58 MHz. When I ran a looping program I expected it to take about 30 seconds, but instead it finised in 15.
@Qwerty, The program that I ran didn't cause a ram reset, but it still sent me to the select language menu. Is that what happened to you.

Edit: Finished my display program. Programming in SH3 hex is hard  :P Anyway I did not get blue lines on the screen. This program tested from B4000000 to B5000000. I could test other ranges, but I need ideas. The source and g3a app are inclided Note: This program can only test 16 megabyte ranges at a time. Double note: There is a 4 gigabyte range the lcd ram could be in. Triple note: I could modify it to check larger ranges, but that would require effort  :P also I don't to mess up my memory.
Code: [Select]
00007000: MOV.L @($0B*4+PC),R15 = #B40000A0
00007002: MOV.L @($0D*4+PC),R14 = #00007777
00007004: MOV $-1, R13
00007006: MOV.L @($0D*4+PC),R12 = #0000FFFF
00007008: NOP
0000700A: NOP
0000700C: MOV.W R14,@-R15
0000700E: MOV.W R14,@-R15
00007010: MOV.W R14,@-R15
00007012: MOV.W R14,@-R15
00007014: MOV.W R14,@-R15
00007016: MOV.W R14,@-R15
00007018: MOV.W R14,@-R15
0000701A: MOV.W R14,@-R15
0000701C: MOV.W R14,@-R15
0000701E: MOV.W R14,@-R15
00007020: ADD R12,R15
00007022: DT R13
00007024: BF $700C
00007026: DT R15
00007028: BF $7026
0000702A: RTS
0000702C: 0000 ?
0000702E: 0000 ?
00007030: .data b40000a0 dword ref:7000
00007034: 0000 ?
00007036: 0000 ?
00007038: .data 00007777 dword ref:7002
0000703C: .data 0000ffff dword ref:7006
Double edit: This program is location independant, meaning it can be ran anywhere in ram with the jump statements still working.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 24, 2011, 03:14:40 pm
You'll have to wait for z80's work before anyone can write screen stuff. Speaking of Z80, I came upon some evidence that the OS naturally runs in 58 MHz mode. It's either that or the program crashed before writing to FRQCR or the OS switches to normal speed every time it exits the application, both of which I think are unlikely.

Yes, I was trying to overclock my Prizm :P

Yeah it seems that it runs at 58 MHz, according to stuff I read here and from other places. Even uberspire/kucalc mentions the calc runs at 58 MHz. It makes BASIC look even slower. X.x (It reminds me the AFX series, kinda)
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 24, 2011, 03:32:00 pm
I'm just finishing up the screen program right now. If all goes well it shouls draw a couple of blue lines on the screen. Also I would agree the OS runs at 58 MHz. When I ran a looping program I expected it to take about 30 seconds, but instead it finised in 15.
@Qwerty, The program that I ran didn't cause a ram reset, but it still sent me to the select language menu. Is that what happened to you.

Edit: Finished my display program. Programming in SH3 hex is hard  :P Anyway I did not get blue lines on the screen. This program tested from B4000000 to B5000000. I could test other ranges, but I need ideas.

...

My checksums were off by 0x0002h  <_<

Anyway, stay away from the 0xA000...  and 0x8000... ranges. Those are where the boot code and the OS are located respectively.
Title: Re: Casio Prizm documentation
Post by: bsl on January 24, 2011, 04:19:26 pm
Try putting NOP's after branch instructions so that the program runs as expected:

00007020: ADD R12,R15
00007022: DT R13
00007024: nop
00007026: BF $700C
00007028: nop
0000702a: DT R15
0000702c: nop
0000702e: BF $702A
00007030: nop
00007022: RTS
00007024: nop
00007026: 0000 ?
00007028: 0000 ?

The instruction right after rts, bf,... is typically executed first.
So recode and recalc the checksum.
Title: Re: Casio Prizm documentation
Post by: calc84maniac on January 24, 2011, 04:58:27 pm
Hmm, there are a couple of errors you made in your thinking though. DT is not a branch instruction, and conditional branches only execute the following instruction if the BF/S or BT/S variants are used. You are correct about needing something after the RTS, though.
Title: Re: Casio Prizm documentation
Post by: z80man on January 25, 2011, 01:18:39 am
Hmm, there are a couple of errors you made in your thinking though. DT is not a branch instruction, and conditional branches only execute the following instruction if the BF/S or BT/S variants are used. You are correct about needing something after the RTS, though.
I didn't know that nop was a delayed branch instruction. I'll edit the code and see if i get anthing different. The $B4000000 was where the lcd ram for the fx 9860 was located so I thought I would start there.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 25, 2011, 01:21:14 am
It isn't  ;)

NOP stands for no operation. When the branches are delayed, the next instruction in the pipeline is executed to avoid as many pipeline errors as possible. The NOP simply doesn't do anything. You could use any instruction in that slot except for another branch or PC dependent instruction and the results would be the same.
Title: Re: Casio Prizm documentation
Post by: z80man on January 25, 2011, 01:32:47 am
It isn't  ;)

NOP stands for no operation. When the branches are delayed, the next instruction in the pipeline is executed to avoid as many pipeline errors as possible. The NOP simply doesn't do anything. You could use any instruction in that slot except for another branch or PC dependent instruction and the results would be the same.
Oh, I meant to say I didn't know rts is a delayed branch instruction. Therefore I should probaly place a nop after it.
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 25, 2011, 07:35:01 am
If we know the format of the color in the screens, why not just search for a section of color, instead of writing over bytes and possibly screwing up your memory.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 25, 2011, 11:19:55 am
The memory is filled with a ton of "FF FF" words and that happens to be the very color the screen is changed to in order for apps to run. It'd be similar to looking for a needle in a pile of needles.
Title: Re: Casio Prizm documentation
Post by: calc84maniac on January 25, 2011, 12:16:17 pm
It'd be similar to looking for a needle in a pile of needles.

Found one!  :w00t:
Title: Re: Casio Prizm documentation
Post by: z80man on January 25, 2011, 10:06:04 pm
But it seems like there is an OS call that does a lot of that  app iniatilazation stuff such as menu bar and run indicator. If we have the call in the code then we could look for the proper memory contents.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 25, 2011, 10:21:55 pm
Remember that we don't have access to the physical memory and the call's code is probably located with the rest of the OS functions in physical memory.
Title: Re: Casio Prizm documentation
Post by: z80man on January 25, 2011, 10:25:56 pm
Remember that we don't have access to the physical memory and the call's code is probably located with the rest of the OS functions in physical memory.
We don't have access to physical memory? Does the proc through an exception or something if you try to access it in a program.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 25, 2011, 10:27:04 pm
No, from what I'm aware, nothing can access it aside from the OS. I'll have to check again though to be sure.
Title: Re: Casio Prizm documentation
Post by: z80man on January 25, 2011, 10:33:57 pm
Do you know if it causes your program to crash or if those instructions are just ignored.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 25, 2011, 10:34:50 pm
I was wrong. Give me a second to post some example code.

Okay, you can access physical memory if bit 1 of the MMUCR is reset. Use this:

Code: [Select]
D101
FFFFFFE0
D201
00000000
6123
0009

Code: [Select]
D101
FFFFFFE0
D201
00000000
2219
0009

Those *should* reset the register to eliminate virtual memory mapping.
Title: Re: Casio Prizm documentation
Post by: z80man on January 25, 2011, 10:50:47 pm
With all code you have to run just to get a simple program to work, Asm programing for the Prizm won't be very popular. We need to get some sort of C complier soon.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 25, 2011, 10:52:20 pm
Oh, I forgot to mention run one *OR* the other, not both. It's redundant. But we already have a C compiler  ;)
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 25, 2011, 10:54:11 pm
Well, I'm assuming that it will be easier once we get some program to set up the routines and such.
Title: Re: Casio Prizm documentation
Post by: z80man on January 25, 2011, 10:55:20 pm
Oh, I forgot to mention run one *OR* the other, not both. It's redundant. But we already have a C compiler  ;)
I mean more like a community made one. Perhaps one with libraries designed around the Prizm. Axe is a must also. It would nedd to compile programs designed for the Ti-83+ though.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 25, 2011, 10:58:27 pm
I'd settle for an Assembler right now, let alone a compiler, not that I would use anything objected oriented :P
Title: Re: Casio Prizm documentation
Post by: z80man on January 25, 2011, 11:51:53 pm
An assembler shouldn't be too hard. It would be just like Scout's disssasmbler, but in reverse.  ;)
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 25, 2011, 11:52:44 pm
Macros are difficult to handle. But a basic assembler should be simple.
Title: Re: Casio Prizm documentation
Post by: calc84maniac on January 26, 2011, 11:12:40 pm
GCC says hi. Seriously, I don't know why we'd consider writing a C compiler from scratch when we have a maintained open-source one already. (It also includes an assembler of course)
Title: Re: Casio Prizm documentation
Post by: z80man on January 27, 2011, 12:14:38 am
GCC says hi. Seriously, I don't know why we'd consider writing a C compiler from scratch when we have a maintained open-source one already. (It also includes an assembler of course)
Okay a probaly should of thought of that earlier, but writing extensive libraires for the Prizm involving, graphics routines, linking protocols, input and output, memory management and the file system will be required to boost development.

And sorry everyone about the delayed app signer. I have a lot of work I need to do first and I will try to get that out as soon as possible.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 27, 2011, 07:45:59 am
Whoever decided that one of the things they didn't need to include in the SH3 processor were LD commands deserves a lot of things that I won't mention. I'm almost done debugging the relative loads... an hour and a half later for six instructions.



Okay, here's the code. It should set the processor to 3x its normal speed, but my BASIC test program in unaffected. Any ideas why? Also, the memory areas close to 0x0000 0000h all appear to be write locked. They're not boot code though, because that's at 0xA000 0000h.

Spoiler For Spoiler:
Code: [Select]
0009
0009
0009
D806
D906
DA07
9B10
9C10
9D0D
2AC1
29B1
28D1
0009
0009
000B
0009
FFFF
FF80
FFFF
FF84
FFFF
FF86
0009
0300
5A7A
A565

Code: [Select]
00300000: NOP
00300002: NOP
00300004: NOP
00300006: MOV.L @($06*4+PC),R8 = #FFFFFF80
00300008: MOV.L @($06*4+PC),R9 = #FFFFFF84
0030000A: MOV.L @($07*4+PC),R10 = #FFFFFF86
0030000C: MOV.W @($10*2+PC),R11 = #FFFF5A7A
0030000E: MOV.W @($10*2+PC),R12 = #FFFFA565
00300010: MOV.W @($0D*2+PC),R13 = #FFFF0300
00300012: MOV.W R12,@R10 => A565 = [FFFFFF86]
00300014: MOV.W R11,@R9 => 5A7A = [FFFFFF84]
00300016: MOV.W R13,@R8 => 0300 = [FFFFFF80]
00300018: NOP
0030001A: NOP
0030001C: RTS
0030001E: NOP
00300020: .data ffffff80 dword ref:300006
00300024: .data ffffff84 dword ref:300008
00300028: .data ffffff86 dword ref:30000A
0030002C: NOP
0030002E: 0300
00300030: 5A7A
00300032: A565
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 27, 2011, 06:36:38 pm
Whoever decided that one of the things they didn't need to include in the SH3 processor were LD commands deserves a lot of things that I won't mention. I'm almost done debugging the relative loads... an hour and a half later for six instructions.



Okay, here's the code. It should set the processor to 3x its normal speed, but my BASIC test program in unaffected. Any ideas why? Also, the memory areas close to 0x0000 0000h all appear to be write locked. They're not boot code though, because that's at 0xA000 0000h.

Spoiler For Spoiler:
Code: [Select]
0009
0009
0009
D806
D906
DA07
9B10
9C10
9D0D
2AC1
29B1
28D1
0009
0009
000B
0009
FFFF
FF80
FFFF
FF84
FFFF
FF86
0009
0300
5A7A
A565

Code: [Select]
00300000: NOP
00300002: NOP
00300004: NOP
00300006: MOV.L @($06*4+PC),R8 = #FFFFFF80
00300008: MOV.L @($06*4+PC),R9 = #FFFFFF84
0030000A: MOV.L @($07*4+PC),R10 = #FFFFFF86
0030000C: MOV.W @($10*2+PC),R11 = #FFFF5A7A
0030000E: MOV.W @($10*2+PC),R12 = #FFFFA565
00300010: MOV.W @($0D*2+PC),R13 = #FFFF0300
00300012: MOV.W R12,@R10 => A565 = [FFFFFF86]
00300014: MOV.W R11,@R9 => 5A7A = [FFFFFF84]
00300016: MOV.W R13,@R8 => 0300 = [FFFFFF80]
00300018: NOP
0030001A: NOP
0030001C: RTS
0030001E: NOP
00300020: .data ffffff80 dword ref:300006
00300024: .data ffffff84 dword ref:300008
00300028: .data ffffff86 dword ref:30000A
0030002C: NOP
0030002E: 0300
00300030: 5A7A
00300032: A565
I would almost guarantee that the parser changes the calc speed before running it, especially if the OS changes the speed at any time in the OS.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 27, 2011, 06:38:13 pm
That sucks  :'(

Changing the speed is dangerous and slow, so they would be idiots to change it every time the parser is run.
Title: Re: Casio Prizm documentation
Post by: calc84maniac on January 27, 2011, 06:40:33 pm
Didn't I hear something about the apps being able to request a clock speed in the header? Might have been on an earlier casio calc, though.
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 27, 2011, 06:50:19 pm
That sucks  :'(

Changing the speed is dangerous and slow, so they would be idiots to change it every time the parser is run.
Not if it's safer than the routines we have.  It also might be faster that way.  Besides, they theoretically wouldn't change it unless it needed it to be.  Either that, or the speed difference is unnoticeable.  How did you test it?  Try timing it for counting from one to like 1000 or something.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 27, 2011, 06:52:30 pm
I guarantee that their routine isn't much faster than mine because it's the hardware's stability that determines most of the speed of the routine.

And the test program was this:

Code: [Select]
For 1->A To 1000
Locate 1,1,A
Next
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 27, 2011, 06:54:30 pm
I guarantee that their routine isn't much faster than mine because it's the hardware's stability that determines most of the speed of the routine.

And the test program was this:

Code: [Select]
For 1->A To 1000
Locate 1,1,A
Next
Did you time each one with a stop-watch?
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 27, 2011, 06:55:02 pm
Yep.
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 27, 2011, 06:56:16 pm
Yep.
And what were the times? Try 10,000.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 27, 2011, 06:58:03 pm
42.3 seconds, plus or minus .3 seconds.
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 27, 2011, 06:59:03 pm
42.3 seconds, plus or minus .3 seconds.
Wow, that's kinda slow.  Anyway, there might not be enough time or the OS might reset it itself if it detects a change.  If we knew where it was, we could try running a program directly.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 27, 2011, 07:01:58 pm
Time shouldn't be the issue. I'm resetting the processor to twice its normal speed (29*4, not 29*3 as I said earlier), so that should be pretty evident. And the calc doesn't crash. The code executes, then exits back to the main menu.
Title: Re: Casio Prizm documentation
Post by: z80man on January 27, 2011, 08:15:49 pm
Disn't we find that apps run at 58 Mhz while the OS was at 29Mhz. That would mean at the end of execution of an app the OS would automaticaly switch back to 29 Mhz. The easiest option for speeding up BASIC programs would be to use a hook to overclock at runtime.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 27, 2011, 08:54:01 pm
Er, I don't know anything about programming hooks and I presume no one else has the access points.
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 27, 2011, 09:05:26 pm
Er, I don't know anything about programming hooks and I presume no one else has the access points.
Assuming they even exist. Is there a disassembly of the OS anywhere?
Title: Re: Casio Prizm documentation
Post by: z80man on January 27, 2011, 09:16:50 pm
Problem is Casio hasn't even released a downloadable version of the OS yet.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 27, 2011, 09:19:14 pm
Perhaps they're too scared that we'll hack it  ::)
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 27, 2011, 10:02:50 pm
Perhaps they're too scared that we'll hack it  ::)
Probably fairly easily.  Qwerty.55: Have you gotten that usb stuff yet?
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 27, 2011, 11:37:53 pm
My computer absolutely refuses to let me install Linux of any kind or even allow VirtualBox to run  :P

I've asked FinaleTI to try it out, so expect a message from him.

EDIT: Z80man, did you ever find the location of the screen, because I can shotgun my RAM to find it if you haven't.
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 28, 2011, 06:58:38 am
My computer absolutely refuses to let me install Linux of any kind or even allow VirtualBox to run  :P

I've asked FinaleTI to try it out, so expect a message from him.

EDIT: Z80man, did you ever find the location of the screen, because I can shotgun my RAM to find it if you haven't.
Is this an official technical term, or did you just use it here.  I like the analogy either way.  Sorry to hear about linux.  This is why I have 2 computes. ;-) One to test fun stuff, and one to use normally.
Title: Re: Casio Prizm documentation
Post by: FinaleTI on January 28, 2011, 07:01:36 am
My computer absolutely refuses to let me install Linux of any kind or even allow VirtualBox to run  :P

I've asked FinaleTI to try it out, so expect a message from him.

EDIT: Z80man, did you ever find the location of the screen, because I can shotgun my RAM to find it if you haven't.
I'm downloading the iso for Ubuntu 10.10 as we speak so that I can set up Virtualbox.
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 28, 2011, 07:03:46 am
My computer absolutely refuses to let me install Linux of any kind or even allow VirtualBox to run  :P

I've asked FinaleTI to try it out, so expect a message from him.

EDIT: Z80man, did you ever find the location of the screen, because I can shotgun my RAM to find it if you haven't.
I'm downloading the iso for Ubuntu 10.10 as we speak so that I can set up Virtualbox.
Excellent, thank you!
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 28, 2011, 04:05:26 pm

Is this an official technical term, or did you just use it here.  I like the analogy either way.

Unofficial, but I think it makes the process sound appropriately destructive :P

Of course, I'm assuming that the FLASH is write locked in virtual memory, which is NOT something I want to be proven wrong on...
Title: Re: Casio Prizm documentation
Post by: FinaleTI on January 28, 2011, 04:45:32 pm
I've hit a slight roadblock in the USB protocol process...
(http://img.removedfromgame.com/imgs/Screenshot.png)

Edit: I found a program that read some info on the Prizm over usb, but I'm not sure if the data I've got is what you need.
Should I post it, or email it or what?
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 28, 2011, 07:34:10 pm
I sent you a PM. Ask if you have more questions, as I may have not been clear enough.
Title: Re: Casio Prizm documentation
Post by: FinaleTI on January 28, 2011, 08:45:19 pm
It was clear and I believe it worked out perfectly fine.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 30, 2011, 08:12:07 pm
Problem is Casio hasn't even released a downloadable version of the OS yet.
Which is a shame because right now several people are stuck with the first version of their OS, which is buggy.
Title: Re: Casio Prizm documentation
Post by: AngelFish on January 31, 2011, 02:37:43 am
Yeah.

Also, if anyone wants to program in ASM using add-ins and you're using absolute calls, check that the virtual memory bit of the MMU is reset. If you do not, you're probably going to generate TLB and/or page faults.
Title: Re: Casio Prizm documentation
Post by: jnesselr on January 31, 2011, 07:43:46 am
So are you going to shotgun your RAM? Be sure to take video of any weird anomaly.  Quick question, though, but do you think if you bricked it, CASO would replace it?
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on January 31, 2011, 11:31:09 pm
Is using add-ins to do ASM possible right now? You ran ASM code successfully before if I remember. Would it just be a matter of making sure the app remains the right size and to not overwrite the checksum?
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 01, 2011, 12:11:24 am
@graph, I've tried, but it generated page faults and I don't have time to fix the problem at the moment. And I doubt Casio would replace my Prizm. Good thing ROM is write locked.

@DJ, the apps are stored in ROM and copied to RAM to run, I think. I've tried overwriting them before with no success.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 01, 2011, 04:06:30 am
So this means your CPU speed changer add-in from a month ago actually never ran successfully and was pretty much a hoax? ???
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 01, 2011, 04:34:03 am
No it worked (as far as I know). This is different code. The CPU speed changer didn't throw TLB errors.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 01, 2011, 04:43:37 am
Oh ok, but couldn't you just replace your CPU speed changer with different code and it would work? If so, then someone would just have to write a temporary software to modify existing add-ins as a solution to the potential 2-3 years of wait (what it took for the Nspire, the TI-82 and TI-85) before Ndless/ASH/Zshell arrives on the Prizm. :P
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 01, 2011, 04:47:19 am
Well, it depends on the type of code. The section of virtual memory i used for the CPU changer is designed to be addressed the same. The code used for writing to the LCD was supposed to write to physical memory and I forgot to take it out of virtual memory, so it tried to write to invalid addresses. That's what the TLB error means. I made a simple mistake and I simply haven't had the time to fix it.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 01, 2011, 04:52:57 am
Ah ok. I see now X.x. Good luck figuring out. X.x
Title: Re: Casio Prizm documentation
Post by: JosJuice on February 01, 2011, 10:11:20 am
(http://i152.photobucket.com/albums/s183/JosJuice/random144.png)
These are some of the files that are placed in Temp by the OS installer. The eActivities aren't interesting, but OSupdateDLL.dll might be...
Title: Re: Casio Prizm documentation
Post by: jnesselr on February 01, 2011, 05:29:45 pm
Could you send the dll?
Title: Re: Casio Prizm documentation
Post by: z80man on February 02, 2011, 12:30:54 am
At 6 megabytes OSupdateDLL.dll seems a little large. What about fxASPI.dll, that is around the same size predictions I had for the update.
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 02, 2011, 12:45:19 am
The OS is secured with an MD5 hash. That means that we're not going to be breaking it anytime in the near future. At least it's not as bad as the Nspire RSA code.
Title: Re: Casio Prizm documentation
Post by: z80man on February 02, 2011, 12:59:02 am
The OS is secured with an MD5 hash. That means that we're not going to be breaking it anytime in the near future. At least it's not as bad as the Nspire RSA code.
I've been reading up on MD5 hash and sources say that a 128 bit key can be cracked in only a few seconds using a collision attack algorthim. Do you think this may be possible with the OS.
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 02, 2011, 01:08:56 am
I'm not sure a collision would help much. We need the signing keys, not the collision.


You're right. We just have to make sure whatever OS collides with the MD5 hash.
Title: Re: Casio Prizm documentation
Post by: JosJuice on February 02, 2011, 01:27:56 am
The OS is secured with an MD5 hash. That means that we're not going to be breaking it anytime in the near future. At least it's not as bad as the Nspire RSA code.
So you've found the OS file? Which one is it?
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 02, 2011, 01:31:40 am
I haven't found any files period. All I've found is code that checks the MD5 hash.
Title: Re: Casio Prizm documentation
Post by: JosJuice on February 02, 2011, 01:33:13 am
Oh, okay. You're disassembling the exe?
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 02, 2011, 01:40:04 am
Yes. That contains all of the requisite data to update the OS.
Title: Re: Casio Prizm documentation
Post by: z80man on February 02, 2011, 02:19:50 am
At $86800 in the exe it looks like there is maybe some C/C++ code. It does hava a lot of windows commands in it. I don't know if this will be useful or not, but it might unveal something.
Title: Re: Casio Prizm documentation
Post by: jnesselr on February 02, 2011, 04:08:50 pm
I'm personnally looking for the usb code. It has to talk to the device at some point.  Also, if someone who doesn't care about the bugs please download "simple usb logger", and log the OS transfer? Thanks!
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 03, 2011, 12:42:22 am
It sucks that it's encrypted. I hope you can manage to decrypt the OS without too much hassle. I hope no other encryption methods were used in it...
Title: Re: Casio Prizm documentation
Post by: JosJuice on February 03, 2011, 01:53:42 am
There's an 8.6 MB msi file that's extracted twice (or maybe even three times...) by the program. It seems to do the exact same thing as the exe itself... However, the only files extracted by the msi are the ones in this post (http://ourl.ca/8207/169951). Some of the other files that the exe extracts don't appear when running the msi.
Title: Re: Casio Prizm documentation
Post by: fxdev on February 03, 2011, 12:09:09 pm
Does the OS itself contain an MD5 key or is this just something from the installer?
Because on a GII calc the OS checksum is located at 0x8024FFF8 (unsigned int) and can be computed as follows:

Code: [Select]
for ( i = 0x80010000; i <= 0x8024FFF7; i++){ result += *(unsigned char*)i; };
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 03, 2011, 12:11:39 pm
I don't know, but it'd be kind of difficult to sign something with a hash if the output isn't recorded somewhere.
Title: Re: Casio Prizm documentation
Post by: Goplat on February 04, 2011, 02:02:57 pm
These are some of the files that are placed in Temp by the OS installer. The eActivities aren't interesting, but OSupdateDLL.dll might be...

I took a look at OSupdateDLL.dll. It contains two resources (type RCDATA, id 3063 and 3064) that are probably the compressed OS. It's the Microsoft LZ compression format, except most of the header isn't there, and just to be annoying they removed the single byte at offset 0x3000 :(

Anyway, here's a program to extract both of them:
Title: Re: Casio Prizm documentation
Post by: jnesselr on February 04, 2011, 02:40:23 pm
How do you know they removed the byte?
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 04, 2011, 04:02:59 pm
Here's a list of all of the normal OS errors that can be encountered.
Spoiler For Spoiler:
Break
Terminate  Application?
Condition ERROR
Time Out
System ERROR 
Memory ERROR
Syntax ERROR
Ma ERROR               //Math error.
Go ERROR
Nesting ERROR
Stack ERROR
Argument ERROR
Dimension ERROR
Com ERROR
Transmit ERROR
Receive ERROR
Memory Full
Undefined
Overflow ERROR
Domain ERROR
Non-Real ERROR
No Solution
Mismatch
No Variable
Not Found
Application ERROR
Already Exists
Complex Number
In List
Complex Number
In Matrix
Can't Solve!
Adjust initial value or bounds..Then try again
Range ERROR
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 05, 2011, 01:03:46 am
Are these all errors that can be triggered from the OS with no ASM program?
Title: Re: Casio Prizm documentation
Post by: JosJuice on February 05, 2011, 02:07:54 am
Are these all errors that can be triggered from the OS with no ASM program?
I think that's all of the errors that are coded into the OS, no matter how they are triggered.
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 05, 2011, 02:51:54 pm
Those are all of the errors that can be encountered in the OS. With Assembly programming, you can have a few other errors that are listed in a different table (which I haven't found yet).
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 06, 2011, 12:19:41 am
Ok, thanks for the info. This includes Invalid Code errors, I presume?
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 06, 2011, 12:35:27 am
Invalid code errors are among those that are elsewhere in the OS. I found some data concerning them a little while ago, but I'd have to find it again.

Anyway, it appears that the OS has some level of support for an SD card...

... and NOR ROM Flashing  >:D
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 06, 2011, 02:58:02 am
Lol nice. I wonder if they'll actually use it on certain calc models in the future, unlike TI? (The Nspire maintenance menu has SD card options, but the Nspire got no SD card slot...)

What does NOR ROM flashing do?

Also on an off-topic note, even after 3 weeks, my Prizm still smells like a burned factory. O.O Maybe I should remove all 4 batteries and the battery cover to let the smell get out by the small holes there. :P
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 06, 2011, 02:59:27 am
It erases all of ROM.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 06, 2011, 02:59:52 am
Mhmm, be careful with this, then. O.O
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 06, 2011, 03:08:15 am
It's in the Diagnostics data, not in normal User data.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 06, 2011, 03:29:29 am
Oh I meant more about the ROM erasing part. Try to not accidentally your entire Flash chip content including any boot code/certificate or the like. Not sure how that stuff works, really. X.x
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 06, 2011, 03:30:15 am
To be honest, neither do I  ;D
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 06, 2011, 03:31:09 am
Lol, but at least you manage to mess with some ASM stuff. I barely can understand how to create/read from an appvar in Axe. O.O
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 06, 2011, 03:31:36 am
I don't understand that either, lol.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 06, 2011, 04:23:42 am
Lol ok. I wish there was an easier way. Actually it's not too hard, but it's so confusing. There should be one command to create appvars and another to read data from them. X.x
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 06, 2011, 11:53:27 pm
I've confirmed the main boot code to be located at 0xA0020080h

If I have the correct code sequence identified in the OS, then Casio's boot code will be a nightmare to continue with. It jumps all over the place.

I also believe I've found some of the code detailing the mysterious ABS that seems so important in the OS. I have no idea what it does, but it appears to do a lot of work with arrays and syscalls.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 08, 2011, 01:33:25 am
Hmm darn, I hope this won't cause jailbreaking to be much more of a nightmare X.x. Good luck!
Title: Re: Casio Prizm documentation
Post by: JosJuice on February 08, 2011, 01:40:48 am
Hmm darn, I hope this won't cause jailbreaking to be much more of a nightmare X.x. Good luck!
We don't really need to jailbreak it... It will accept add-ins made by us as long as they have the correct checksums, so it's not really like the Nspire. It's more like an 84+ without the Asm( command but with apps. What we need to do in order to make it easier to run code is to figure out the CRC checksum that's used for add-ins.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 08, 2011, 01:47:55 am
Yeah but I meant in general. I never remember the right term for that stuff, so for me it's always hacking/jailbreaking, plus it's shorter than typing "getting third-party ASM/C code to run" :P
Title: Re: Casio Prizm documentation
Post by: JosJuice on February 08, 2011, 01:50:34 am
Lol yeah.

I don't think that what Qwerty is talking about will affect our ability to run code, but it might prevent us from doing certain things later on. I'm not too sure.
Title: Re: Casio Prizm documentation
Post by: z80man on February 08, 2011, 10:25:16 pm
The problem with writing add ins right now is size constraints. So you have to manipulate the program to fit one of three pre defined checksums. This can casue an issue for programs that are between the size of two apps causing you to try to decrease or increase the value of many bytes. Also the current method to affect the checksum of the app is to modify the image data, meaning it is difficult to import your own images.
Title: Re: Casio Prizm documentation
Post by: JosJuice on February 09, 2011, 01:37:40 am
Also the current method to affect the checksum of the app is to modify the image data, meaning it is difficult to import your own images.
There's a lot of unused empty data in the header. Can't we try to modify that instead of the icons?
Title: Re: Casio Prizm documentation
Post by: z80man on February 09, 2011, 01:42:44 am
Also the current method to affect the checksum of the app is to modify the image data, meaning it is difficult to import your own images.
There's a lot of unused empty data in the header. Can't we try to modify that instead of the icons?
Yes there is a lot of empty space in the header, but if you have an app with a larger code size than the base app you will have to subtract bytes and the only safe way to do this is in the image data.

And for the app signer I'm working on I'm just going to port it to java. There were too many issues with Visual C++ and java is more portable.
Title: Re: Casio Prizm documentation
Post by: JosJuice on February 09, 2011, 01:45:08 am
Also the current method to affect the checksum of the app is to modify the image data, meaning it is difficult to import your own images.
There's a lot of unused empty data in the header. Can't we try to modify that instead of the icons?
Yes there is a lot of empty space in the header, but if you have an app with a larger code size than the base app you will have to subtract bytes and the only safe way to do this is in the image data.

And for the app signer I'm working on I'm just going to port it to java. There were too many issues with Visual C++ and java is more portable.
Do you think it's going to be released soon?
Title: Re: Casio Prizm documentation
Post by: z80man on February 09, 2011, 11:01:20 pm
Hopefully by this weekend. At least porting in between C++ and java is simple to do. I just need to check my references for the different classes.
Title: Re: Casio Prizm documentation
Post by: calc84maniac on February 09, 2011, 11:03:34 pm
Do you have any idea of how to change the actual size of the application? If you have that info, you could probably generate an working add-in from scratch.
Title: Re: Casio Prizm documentation
Post by: z80man on February 09, 2011, 11:16:46 pm
Do you have any idea of how to change the actual size of the application? If you have that info, you could probably generate an working add-in from scratch.
I can change the size of the app by changing a few bytes in the header. and by generate a working add-in from scratch, qwerty and I have already done this, but the apps are very simple so far because we had to program in SH3 hex.
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 14, 2011, 03:48:04 am
Oh, if anyone's curious, the MD5 hash of the OS is probably the 16 byte sequence located at 0x00001854h in prizm3064. If it were executable code, it'd be an infinite loop.
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 14, 2011, 03:47:14 pm
I don't know about anyone else, but here's the data I've been wanting for quite some time:

Screen buffer address: 0xA8000000
Screen buffer size: 0x28800 (162 Kilobytes)

Enjoy  :)
Title: Re: Casio Prizm documentation
Post by: jnesselr on February 14, 2011, 06:21:24 pm
I don't know about anyone else, but here's the data I've been wanting for quite some time:

Screen buffer address: 0xA8000000
Screen buffer size: 0x28800 (162 Kilobytes)

Enjoy  :)
Woot! Way to go, how did you find it? Did you shotgun your ram? And is it auto-update? e.g, mapped to that piece of ram?
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 14, 2011, 07:04:46 pm
As much as I wish I had found that address, it was Simon Lothar who announced it. Apparently he's compiled quite a few bits of interesting information, some expected and others a complete surprise.
Title: Re: Casio Prizm documentation
Post by: jnesselr on February 14, 2011, 07:23:27 pm
As much as I wish I had found that address, it was Simon Lothar who announced it. Apparently he's compiled quite a few bits of interesting information, some expected and others a complete surprise.
Who is that?
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 14, 2011, 07:27:00 pm
A member of the Casio community who's been hacking the Prizm independently of us.
Title: Re: Casio Prizm documentation
Post by: jnesselr on February 14, 2011, 07:41:45 pm
A member of the Casio community who's been hacking the Prizm independently of us.
Oh no, you got a QR code. Now people are gonna get confused!  You should invite him to join us. Join us... WE WANT YOUR BRAINS.  ;-)
Title: Re: Casio Prizm documentation
Post by: fxdev on February 15, 2011, 01:13:48 pm
Quote
A member of the Casio community who's been hacking the Prizm independently of us.

Link to topic: http://casiokingdom.org/modules.php?name=Forums&file=viewtopic&t=1690
Title: Re: Casio Prizm documentation
Post by: jnesselr on February 15, 2011, 09:45:50 pm
Quote
A member of the Casio community who's been hacking the Prizm independently of us.

Link to topic: http://casiokingdom.org/modules.php?name=Forums&file=viewtopic&t=1690
Oh, okay, thanks.  He seems intelligent.

EDIT: Not that you all sound stupid, it's just that... Yeah, he has more experience compared to US. (I am failing at making intelligent posts tonight)
Title: Re: Casio Prizm documentation
Post by: SimonLothar on February 16, 2011, 01:43:52 am
Quote
He seems intelligent.
Oh, that's uncommonly kind of you.
I once scanned my databases for the term "intelligence" and found it to be the ability to fumble a fat maggot from out of a hollow treetrunk with none else than a stick and wearing a hairy costume with large flapping ears. I tried it, but never succeeded...leaving my emotional simulation circuits in a state, which you would call "sad". Now they switched over to "happy". THX. :)
Title: Re: Casio Prizm documentation
Post by: z80man on February 16, 2011, 02:12:15 am
A few days ago we had three maybe four Prizm hackers. Now we are at about 10 hackers.  we can get all our projects out in a timely manner now. Great to see you here. be sure to introduce yourself in the introduce yourself sub-forum.
Title: Re: Casio Prizm documentation
Post by: jnesselr on February 16, 2011, 07:15:51 am
Quote
He seems intelligent.
Oh, that's uncommonly kind of you.
I once scanned my databases for the term "intelligence" and found it to be the ability to fumble a fat maggot from out of a hollow treetrunk with none else than a stick and wearing a hairy costume with large flapping ears. I tried it, but never succeeded...leaving my emotional simulation circuits in a state, which you would call "sad". Now they switched over to "happy". THX. :)
Oh no, the sentient computer is here!  Excellent.  I do want to ask how you found out where the screen was, and is the screen mapped to it?  Also, do you have any knowledge on USB?  What about C++?
Title: Re: Casio Prizm documentation
Post by: SimonLothar on February 16, 2011, 12:27:29 pm
Quote
I do want to ask how you found out where the screen was, and is the screen mapped to it?
I read the OS with the usual tools. The last three years I read the fx-9860-OSes. The knowledge which I gathered during this period has been very helpful. 0xA8000000 ist the address of the VRAM (a part of the standard RAM) and its content is transferred to the display driver by a syscall. F. i. this syscall is called when the OS enters the GetKey-syscall, which waits for keyboard inputs.

Quote
Also, do you have any knowledge on USB?
I know the USB syscalls of the legacy systems (fx-9860). May be helpful, but USB on the fx-CG20 will be a special problem. I have the notion, that they expanded the customized part of the MPU. T. i. some ports they use, are not longer documented in Renesas documentations. This delays the meals. The first thing I want to know is how the keyboard is read. PORT A of the good old 7705 is not detectable any more. As far as I am concerned USB must wait.

Quote
What about C++?
This is one of the projects I'd like to finish quick. At present I use the CASIO SDK assembler to program testcode. But C/C++ objects should work as well. I'd prefer C++. The result should be a G3A, of course.
Title: Re: Casio Prizm documentation
Post by: Kristaba on February 16, 2011, 12:56:22 pm
I have the notion, that they expanded the customized part of the MPU. T. i. some ports they use, are not longer documented in Renesas documentations. This delays the meals. The first thing I want to know is how the keyboard is read. PORT A of the good old 7705 is not detectable any more.
Seriously?
What happened if you try to access to 0xA4000120? MMU error or you simply always read 0?
It would be annoying the Prizm processor isn't like a 7705, and I don't understand why Casio would do that :(
About the USB, I guess you speak about the USB protocol, but you probably can use the 7705 built-in USB features to send a ROM dump for instance, isn't it?

This is one of the projects I'd like to finish quick. At present I use the CASIO SDK assembler to program testcode. But C/C++ objects should work as well. I'd prefer C++. The result should be a G3A, of course.
Why did you use the old, buggy, and proprietary Renesas toolchain instead of GCC?
I think this is the moment to start an open SDK for the Prizm, as you wanted to do few years ago with fxsdk for fx9860...
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 16, 2011, 01:04:14 pm
By the way, does anyone have a quick bit of code to disable virtual memory for add-ins?
Title: Re: Casio Prizm documentation
Post by: Kristaba on February 16, 2011, 01:29:42 pm
By the way, does anyone have a quick bit of code to disable virtual memory for add-ins?

I never played with the MMU yet, but I guess you have just to disable the MMU (through MMURC.AT bit, the last bit of the 32bit register at 0xFFFFFFE0). Set it to 0 and the MMU is disabled.
However, the Renesas documentation specify "Any program that modifies MMUCR should reside in the P1 or P2
area." (P1 is 0x80000000 to 0x9FFFFFFF address range and P2 is 0xA0000000 to 0xBFFFFFFF), so I don't know if we can easily do that...

Also, I don't understand why you want to disable the MMU. Without it, you can't know where the OS mapped your program or which range of the RAM you can safely use. And I don't see a lot of disadvantages in it
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 16, 2011, 02:04:43 pm
I've already tried resetting the last bit at FFFF FFE0, but the virtual memory is mapped in such a way that it doesn't appear to do anything.

As for why, virtual memory makes programming absolutely horrible. It screws up the hardware addresses (FRQCR anyone?) and prevents direct system access. My memory footprint is extremely small, though, so I doubt I'll run out of usable space. I'm not particularly afraid of damaging the system either, so even if I do, it's not much of a problem.

Basically, I can see little reason why you *would* want VRAM over the physical hardware. A reasonably fast program should never be executing more than a few thousand commands at a time, so having a lot of contiguous free RAM is just excessive for anything more than data.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on February 16, 2011, 02:05:49 pm
Quote
What happened if you try to access to 0xA4000120? MMU error or you simply always read 0?
It would be annoying the Prizm processor isn't like a 7705, and I don't understand why Casio would do that.
No MMU error. I think the 7705 standard registers are still present, but 0xA4000120 is not used by the OS (at least couldn't find 0xA4000100 or 0xA4000120 in any pool of 7MB OS). The MPUs used in the fx-9860 have been customized, too (f. i. the BCD-ALU, an extra timer).  I will follow the GetKeyWait syscall to find the registers used for keyboard reading in the fx-CG20 OS.
Another hint for expanded customization is the presence of at least two new processor instructions 0x00AB and 0x0nE3 (n=register-no.), which are not documented.
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 16, 2011, 02:17:37 pm
Simon, if you'll look, many of the normal registers aren't directly addressed in the OS.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 16, 2011, 05:00:24 pm
be sure to introduce yourself in the introduce yourself sub-forum.
Although doing so can cause bad side effects to the person, such as his IQ either decreasing by 50 or being divided by 0, thanks to some of the content located in that forum section. In fact, for 99.9% of the forum members, their last post ever was in the intro section O.O

Anyway welcome on the forums. I unfortunately cannot help on the hacking scene but I own several Casio calculators including a Prizm (fx-CG10), so I could test softwares and the like when my time allows me to do so.
Title: Re: Casio Prizm documentation
Post by: bsl on February 17, 2011, 12:43:54 am
The syscall table of pointers starts at 0x805edca8:
Code: [Select]
C:\casio>sh3_disass.py -s 20070 -e 20080 -p 80020070 prizm3064
Dissassembly size: 0x10
80020070: d202 ..  MOV.L @($02*4+PC),R2 = #805EDCA8
80020072: 4008 @.  SHLL2 R0           ; R0 = syscall number
80020074: 002e ..  MOV.L @(R0+R2),R0  ; load from table of pointers
80020076: 402b @+  JMP @R0 
80020078: 0009 ..  NOP
8002007A: 0000 ..  0000 ?
8002007C: 805e .^  .data 805edca8 dword ref:80020070
The actual routines are in the range : 0x8002c3dc - 0x80309030
By dumping the fx9860g ROM and binary matching the entries with the prizm ROM, many prizm syscalls can be found.
Simon might already be ahead of me on this.
This table has several thousand entries of which only a few are needed for the time being.
I think I found the BASIC parsing table - more on that later ....
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 17, 2011, 12:59:42 am
Perhaps a ROM dumping tutorial might be in order...?  ;)
Title: Re: Casio Prizm documentation
Post by: z80man on February 17, 2011, 02:15:21 am
So if I get this right Prizm.inc can start being created. And I agree with Qwerty, how can we dump our own ram?
Title: Re: Casio Prizm documentation
Post by: bsl on February 17, 2011, 02:23:48 am
Actually , the way I am using the term here - its already dumped in prizm3064,  offset 0x2c3dc
Now get an fx9860g  OS upgrade file and decompress that - find the routines in that file and start binary
search and match between the files.
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 17, 2011, 02:25:17 am
So the physical address of location 0000 0000 in the file is 0002 C3DC?
Title: Re: Casio Prizm documentation
Post by: bsl on February 17, 2011, 10:11:19 am
Thats right , The routines are at offsets:
0x0002c3dc - 0x00309030
from the beginning of the file, if the beginning is 0x00000000
In prizm memory its:
0x8002c3dc - 0x80309030

Which means if you are disassembling prizm3064 from the beginning
of the file set the pc=0x80000000

I havent tried decompressing a fx9860g  OS upgrade file yet.


Title: Re: Casio Prizm documentation
Post by: SimonLothar on February 17, 2011, 10:54:02 am
This table has several thousand entries of which only a few are needed for the time being.
Yes, at least you need GetKey (0x0EAB; blocking keyboard read) and PrintXY(0x18F9). With ClearVRAM(0x0272), GetKeyWait(0x12bf; non-blocking keyboard read) and VRAMtoDD (0x025F) you can build quite reasonable applications.

http://casiokingdom.org/modules.php?name=Forums&file=viewtopic&p=14964#14964
Title: Re: Casio Prizm documentation
Post by: SimonLothar on February 17, 2011, 02:18:43 pm
The main memory starts at 0x880D35D0.
Better not write into this range without knowing exactly what you do. On the fx-9860s a corrupted main memory (once saved by a normal shutdown) could block the OS to start! If you accidently should write into this range, push the reset-button. Never switch the calc off in such a case.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 17, 2011, 11:30:09 pm
Is it easy to accidentally write to Flash on Casios and mess up the calc OS certificate/boot code or stuff like that? On TI calcs if you messed up your certificate you could no longer send any OS to your calc.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on February 18, 2011, 01:16:37 am
Is it easy to accidentally write to Flash on Casios and mess up the calc OS certificate/boot code or stuff like that?
No, writing to the flash is not easy, esp. accidentally. But the main memory resides in RAM and is automatically backed up to flash by the OS, when switching off. Perhaps on the fx-CG10/20 they check for integrity before performing the automatic backup.
Title: Re: Casio Prizm documentation
Post by: z80man on February 18, 2011, 02:03:16 am
I just sent 3 massive emails to Casio (1000 char limit per email) describing all of the development current plans, (only the ones they wouldn't really oppose) requests, and glitches. One thing I did not request was an SDK because every time you send an email they always say they have no plans to release one. I did though talk about expanding development and increasing BASIC speed. I also proposed cooperating with the developers to advance the Prizm and how Western markets are dominated by TI and what needs to be done to compete against them. I'm hoping that they will end up helping us even if it is in the smallest way such as some Glitch fixes.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 18, 2011, 03:06:29 am
Ok thanks for the info. On TI calcs I remember you needed to do some weird stuff to write to Flash.

Also z80man try to be careful what you ask them and what you reveal, because if you reveal that the calc is being hacked, they might just release an OS patch preventing our hacks from working.

Suggestions would be nice. One concern I have is that their calcs are so hard to find in stores. Over here until 2009 the only Casio calc available in stores was the FX-9750G, which costed $24.97 at Staples, then they disappeared from shelves. I remember back in 2002 they also had CFX calcs, a $49 calc and a few others.
Title: Re: Casio Prizm documentation
Post by: m1ac4 on February 18, 2011, 07:44:00 am
It might be hard to find the calculators in stores but everyone that has seen mine has liked it (at least one person I know is going to buy one now and several others really wan't to).
If Casio wants to work to improve their product to gain customers then I will definitely work harder to help get them customers to buy it. :)
Title: Re: Casio Prizm documentation
Post by: SimonLothar on February 18, 2011, 09:17:26 am
This table has several thousand entries...
I am a bit short of time, so I post my current progress with the syscalls as overview in shortform:
(MB means "multibyte" and MCS refers to the main memory)
Code: [Select]
else if ( iSyscall == 0x0031 ) name = "GetSystemSetting";
else if ( iSyscall == 0x0032 ) name = "SetSystemSetting";
else if ( iSyscall == 0x0033 ) name = "SetSystemSettingPtr";
else if ( iSyscall == 0x01E5 ) name = "GetVRAMBackgroundAddress";
else if ( iSyscall == 0x01E6 ) name = "GetVRAMAddress";
else if ( iSyscall == 0x025F ) name = "VRAMtoDD";
else if ( iSyscall == 0x0262 ) name = "PutNextYPixel";
else if ( iSyscall == 0x0263 ) name = "PutPixel";
else if ( iSyscall == 0x0266 ) name = "GetNextYPixel";
else if ( iSyscall == 0x0267 ) name = "GetPixel";
else if ( iSyscall == 0x0272 ) name = "ClearVRAM";
else if ( iSyscall == 0x02BB ) name = "DrawHeaderLine";
else if ( iSyscall == 0x0BD0 ) name = "Ly555_Table";
else if ( iSyscall == 0x0E96 ) name = "KeyMapper";
else if ( iSyscall == 0x0E97 ) name = "KeyMapper";
else if ( iSyscall == 0x0EA9 ) name = "Keyboard_PutKeycode";
else if ( iSyscall == 0x0EAA ) name = "GetKey_4";
else if ( iSyscall == 0x0EAB ) name = "GetKey";
else if ( iSyscall == 0x1161 ) name = "MB_IsLead";
else if ( iSyscall == 0x1163 ) name = "MB_ElementCount";
else if ( iSyscall == 0x1164 ) name = "MB_ByteCount";
else if ( iSyscall == 0x1166 ) name = "MB_strcat";
else if ( iSyscall == 0x1167 ) name = "MB_strncat";
else if ( iSyscall == 0x1168 ) name = "MB_strcpy";
else if ( iSyscall == 0x116C ) name = "MB_GetSecondElemPtr";
else if ( iSyscall == 0x116D ) name = "MB_GetElement";
else if ( iSyscall == 0x116E ) name = "memcmp";
else if ( iSyscall == 0x116F ) name = "Disp_strcpy";
else if ( iSyscall == 0x1171 ) name = "char_to_upper";
else if ( iSyscall == 0x1172 ) name = "char_to_lower";
else if ( iSyscall == 0x12bf ) name = "GetKeyWait";
else if ( iSyscall == 0x12c0 ) name = "GetKeyWait";
else if ( iSyscall == 0x12c6 ) name = "Keyboard_PutKeyCode";
else if ( iSyscall == 0x1514 ) name = "MCS_SearchDirectory";
else if ( iSyscall == 0x1519 ) name = "MCS_SearchDirectoryItem";
else if ( iSyscall == 0x1535 ) name = "str8cpy_with_upper_lower_mode";
else if ( iSyscall == 0x1536 ) name = "MCS_SearchItem";
else if ( iSyscall == 0x1545 ) name = "MCS_DirtypeToName";
else if ( iSyscall == 0x1561 ) name = "MCS_OpenInternalDirectoryItem";
else if ( iSyscall == 0x1633 ) name = "ItoA_10digit";
else if ( iSyscall == 0x1638 ) name = "Ly555_Table";
else if ( iSyscall == 0x18F9 ) name = "PrintXY";
else if ( iSyscall == 0x18FF ) name = "PrintPixXY";
else if ( iSyscall == 0x1a37 ) name = "GetShiftStatus";
else if ( iSyscall == 0x1a38 ) name = "ClrShiftStatus";
else if ( iSyscall == 0x1A2C ) name = "GetStackPtr";
else if ( iSyscall == 0x1A2E ) name = "SetSystemSetting";
else if ( iSyscall == 0x1A2F ) name = "GetSystemSetting";
else if ( iSyscall == 0x1d81 ) name = "DisplayStatusLine";
else if ( iSyscall == 0x1dd0 ) name = "memcpy";
else if ( iSyscall == 0x1dd1 ) name = "memcmp";
else if ( iSyscall == 0x1dd2 ) name = "Bfile_GetFilenameLength";
else if ( iSyscall == 0x1dd3 ) name = "Bfile_Name_cmp";
else if ( iSyscall == 0x1dd4 ) name = "Bfile_Name_cpy";
else if ( iSyscall == 0x1E62 ) name = "SaveVRAM_1";
else if ( iSyscall == 0x1E63 ) name = "LoadVRAM_1";
else if ( iSyscall == 0x1E82 ) name = "Ly555ptr";
else if ( iSyscall == 0x1E83 ) name = "Ly555ptr";
else if ( iSyscall == 0x1EF8 ) name = "SetBackGround";
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 18, 2011, 09:30:08 am
Quote
GetStackPtr

Um, MOV.L R15,Rn was too difficult?
Title: Re: Casio Prizm documentation
Post by: z80man on February 18, 2011, 03:04:45 pm
Quote
GetStackPtr

Um, MOV.L R15,Rn was too difficult?
I guess its just like bcall_HLplus5 and bcall_HLplus9 in terms of pointlessness
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 18, 2011, 03:25:07 pm
Well, I can see a potential use for it if you destroy R15 (IE as in returning from add-ins, where you don't know the state of of the stack). That said, if it does what I think it does, it'd be easier just to leave R15 alone.

Title: Re: Casio Prizm documentation
Post by: Goplat on February 18, 2011, 07:13:37 pm
   else if ( iSyscall == 0x1161 ) name = "MB_IsLead";
   else if ( iSyscall == 0x1163 ) name = "MB_ElementCount";
   else if ( iSyscall == 0x1164 ) name = "MB_ByteCount";
   else if ( iSyscall == 0x1166 ) name = "MB_strcat";
   else if ( iSyscall == 0x1167 ) name = "MB_strncat";
   else if ( iSyscall == 0x1168 ) name = "MB_strcpy";
   else if ( iSyscall == 0x116C ) name = "MB_GetSecondElemPtr";
   else if ( iSyscall == 0x116D ) name = "MB_GetElement";
   else if ( iSyscall == 0x116E ) name = "memcmp";
   else if ( iSyscall == 0x116F ) name = "Disp_strcpy";
   else if ( iSyscall == 0x1171 ) name = "char_to_upper";
   else if ( iSyscall == 0x1172 ) name = "char_to_lower";
   ...
   else if ( iSyscall == 0x1dd0 ) name = "memcpy";
   else if ( iSyscall == 0x1dd1 ) name = "memcmp";
Are you sure the first one isn't some kind of strcmp? :p
Title: Re: Casio Prizm documentation
Post by: SimonLothar on February 19, 2011, 03:45:58 am
   else if ( iSyscall == 0x116E ) name = "memcmp";
   ...
   else if ( iSyscall == 0x1dd1 ) name = "memcmp";
Are you sure the first one isn't some kind of strcmp? :p
Yes, you are right. 0x116E is strncmp.
Title: Re: Casio Prizm documentation
Post by: z80man on February 19, 2011, 03:51:36 am
   else if ( iSyscall == 0x116E ) name = "memcmp";
   ...
   else if ( iSyscall == 0x1dd1 ) name = "memcmp";
Are you sure the first one isn't some kind of strcmp? :p
Yes, you are right. 0x116E is strncmp.
Isn't there a string compare instruction for the SH3. I think how it worked was if there were any equivalent bytes between Rm and Rn the T bit was set.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on February 19, 2011, 06:38:57 am
   else if ( iSyscall == 0x116E ) name = "memcmp";
   ...
   else if ( iSyscall == 0x1dd1 ) name = "memcmp";
Are you sure the first one isn't some kind of strcmp? :p
Yes, you are right. 0x116E is strncmp.
I had a closer look. 0x116E is not some str...-function, because it does not quit, when it encounters the terminating zero of the first argument (strncmp does). It always compares the required count of bytes. It is not memcmp either. The result differs from that of memcmp(0/1) and is like the result of strncmp (-1/0/1).

Code: [Select]
teststr1
.SDATA "123"
.DATA.B 0
.SDATA "1"
.DATA.B 0
teststr2
.SDATA "123"
.DATA.B 0
.SDATA "2"
.DATA.B 0

strncmp( teststr1, teststr2, 6) yields "equal".
0x116E( teststr1, teststr2, 6) yields -1 ("lower").
Title: Re: Casio Prizm documentation
Post by: Kristaba on February 19, 2011, 08:06:49 am
Impresive, you're a pretty good hacker Simon :)
I still have some questions, if you have time to answer them.
Firstly, what do you know about the G3A header checksum at the offset 0x16? Some guys say it's a CRC, but I tried a lot of CRC polynomials algorithms with different state of the file (only binaries data, only the header, with and without the other checksum, etc...) and I have no matches. So, if as I guess you know anything about it, please explain how it's computed (it's the last information I need for my G3A wrapper, I think).

Then, do you progressed about the keyboard mapping comprehension?
I wrote a FastGetKey for fx9860 (beacause the Casio's IsKeyDown was shitty and the Kucalc one was bugged), and I think it's something needed to do any good add-in (even if the GetKeyWait work well now :D).

And finally, I don't understand what the syscall you call "GetVRAMBackgroundAddress" is. There are two VRAM? So what is copied to DD when "VRAMtoDD" is called?

Thank you in advance for taking time to answer my questions, and, once more, good job!
Title: Re: Casio Prizm documentation
Post by: SimonLothar on February 19, 2011, 09:08:28 am
Firstly, what do you know about the G3A header checksum...it's the last information I need for my G3A wrapper
It's the last information I do not know either. But I experienced, that it is not essential. I assembled a little memory-viewer-G3A and did not care about this field. The G3A works without any problems. But anyhow, I like to know how this value is computed, too.

Then, do you progressed about the keyboard mapping comprehension?
I wrote a FastGetKey for fx9860...
What I know is, that the keyboard-scanning is very similar to the legacy-systems, the matrix-codes are very similar, maybe identical. But I suspect, they do not use port A, B, M any more, but one of the customized (hence undocumented) ports. At present I'd rather rely on GetKeyWait as non-blocking keyboard reader. The KeyMapper syscalls 0x0E96 and 0x0E97 transfer matrixcodes to keycodes.

And finally, I don't understand what the syscall you call "GetVRAMBackgroundAddress" is. There are two VRAM? So what is copied to DD when "VRAMtoDD" is called?
The VRAMBackgroundAddress is an address inside of the VRAM. It is the address, where the background-image is copied to (immediately below the header-status-line). F. i. if you open the main menu item "Program" you see the green image of a laptop in the background. This image starts at VRAMBackgroundAddress.
VRAMtoDD transfers the whole 0x28800 VRAM to the display driver. I'll rename it to "Bdisp_PutDisp_DD".
Title: Re: Casio Prizm documentation
Post by: z80man on February 19, 2011, 10:40:53 am
Firstly, what do you know about the G3A header checksum...it's the last information I need for my G3A wrapper
It's the last information I do not know either. But I experienced, that it is not essential. I assembled a little memory-viewer-G3A and did not care about this field. The G3A works without any problems. But anyhow, I like to know how this value is computed, too.
Good thing you are speaking to the right person on cracking the g3a header. The 16 bit crc checksum (well I believe its a crc) only calculates the 32 bit modular checksum at address 0x0020. Now I have not yet cracked the crc yet, but I did crack the modular checksum. How that works is that every byte is added to a tally except for the four bytes at 0x20 and the last four bytes which are a copy of the checksum. But to get by the crc you can use one of the checksums previously written by Casio in one of the three apps. I would first like to apologize on slacking off on my app signer program, but I have been busy lately. How it works though is it compares the modular checksum between your app and a prewritten one. If your app has a lower checksum, then the app signer first divides the checksum of the prewritten app minus the checksum of your app by $FF. It then adds X number of $FF to safe areas in the header that were previously $00. The signer then finds the modulus between the prewritten app minus your app by $FF. It then adds the result to one byte that was $00 originally. If your app has a greater checksum, then the signer divides as usual, but then turns X number of $FF bytes to $00 and the modulus is is subtracted from a $FF byte. There is also full documentation for this on the Prizm wiki http://wiki.prizmwiki.co.cc/wiki/Main_Page (http://wiki.prizmwiki.co.cc/wiki/Main_Page)
Title: Re: Casio Prizm documentation
Post by: JosJuice on February 19, 2011, 01:55:17 pm
How that works is that every byte is added to a tally except for the four bytes at 0x20 and the last four bytes which are a copy of the checksum.
Isn't the CRC checksum ignored too when creating the 0x0020 checksum?
Title: Re: Casio Prizm documentation
Post by: Goplat on February 19, 2011, 04:05:05 pm
I notice that wiki claims that 0x0290-0x058F is garbage, but it's actually a small (64x24) black-and-white icon.
Title: Re: Casio Prizm documentation
Post by: JosJuice on February 19, 2011, 04:06:29 pm
Seems more like a grey-and-white icon to me. I wonder why it's missing in one app... Maybe this icon and the localized names that are before it are used for backward compatibility?
Title: Re: Casio Prizm documentation
Post by: bsl on February 19, 2011, 04:57:56 pm
Found the fx9860g ROM in the fx9860g OS upgrade, now finding prizm syscalls
should be easy (assuming they used the same compiler)
Code: [Select]
sh3_disass.py  -s 10070 -e 10080 -p 80010070 ISSetupFile.SetupFile3

80010070: d202 ..  MOV.L @($02*4+PC),R2 = #801B0130
80010072: 4008 @.  SHLL2 R0
80010074: 002e ..  MOV.L @(R0+R2),R0
80010076: 402b @+  JMP @R0
80010078: 0009 ..  NOP
8001007A: 0000 ..  0000 ?
8001007C: 801b ..  .data 801b0130 dword ref:80010070
Goplat: Yes it is a small icon - the Geometry and PictPlot add-ins have one , but not the conversion add-in
Here is that icon for the Geometry add-in:

000290:   wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
0002b0:   wwwwwwwwwp...wwwwww..wwwwwwwwwww
0002d0:   wwwwwwwwp.....wwwww..wwwwwwwwwww
0002f0:   wwwwwwww..ww..wwwwp..wwwwwwwwwww
000310:   wwwwwwwp.wwww..wwwp..wwwwwwwwwww
000330:   wwwwwwwp.wwwwp.www....wwwwwwwwww
000350:   wwwwwww..wwwwp.www.wp.wwwwwwwwww
000370:   wwwwwww.wwww........p.wwwwwwwwww
000390:   wwwwwww.wwww........w.wwwwwwwwww
0003b0:   wwwwwww.wwww.w.ww...w..wwwwwwwww
0003d0:   wwwwwww.wwww.w.ww.w.wp.wwwwwwwww
0003f0:   wwwwwww..www.p.wp.w.wp.wwwwwwwww
000410:   wwwwwwwp.www.p.wp.w.ww.wwwwwwwww
000430:   wwwwwwwp.www...w..w.ww..wwwwwwww
000450:   wwwwwwww..ww..ww.ww.wwp.wwwwwwww
000470:   wwwwwwwwp.....wp........wwwwwwww
000490:   wwwwwwwwwp...wwp........wwwwwwww
0004b0:   wwwwwwwwwwww.wwwwww.wwwwwwwwwwww
0004b0:   wwwwwwwwwwww.wwwwww.wwwwwwwwwwww
0004b0:   wwwwwwwwwwww.wwwwww.wwwwwwwwwwww
0004b0:   wwwwwwwwwwww.wwwwww.wwwwwwwwwwww
000530:   wwwwwwwwwwww........wwwwwwwwwwww
000550:   wwwwwwwwwwww........wwwwwwwwwwww
000570:   wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 19, 2011, 05:07:49 pm
I notice that wiki claims that 0x0290-0x058F is garbage, but it's actually a small (64x24) black-and-white icon.

Well, some of the information on the wiki is outdated.
Title: Re: Casio Prizm documentation
Post by: z80man on February 20, 2011, 01:38:43 am
How that works is that every byte is added to a tally except for the four bytes at 0x20 and the last four bytes which are a copy of the checksum.
Isn't the CRC checksum ignored too when creating the 0x0020 checksum?
Actually no which makes calculating the crc even harder.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on February 20, 2011, 04:48:58 am
Maybe the following ones are interesting.

But be careful with these syscalls! If you write large files, the calc seems to hang, if you do not implement progress indicators. One of my testcodes wrote a 1 MB file, which took a few minutes. Resetting the calc while writing the storage memory could lead to funny results, possibly leaving the calc or at least the storage memory in a world of hurt. Backup is recommended.

syscall 0x1DAE : int Bfile_CreateEntry_OS(  const unsigned short*filename, int mode, int*size  );
Creates either a file or a directory in storage memory.
To create a file call 0x1DAE with size pointing to the required file size and mode = 1.
To create a directory call 0x1DAE with size = nil and mode = 5.
The length of filename must be less than h'10A, else the function returns errorcode -3.
The filename has to start with "\\fls0\" or "\\crd0\". Else errorcode -5 is returned (wrong device).
On the fx-CG20 a new file seems to be filled with zeros instead of 0xFF.

syscall 0x1DA3 : int Bfile_OpenFile_OS( const unsigned short*filename, int mode );
Opens a file in storage memory and returns either a HANDLE or an errorcode. Errorcodes are < 0.
mode:
_OPENMODE_READ 0x01 (not yet verified on the fx-CG20)
_OPENMODE_READ_SHARE 0x80 (not yet verified on the fx-CG20)
_OPENMODE_WRITE 0x02    (verified on the fx-CG20)
_OPENMODE_READWRITE 0x03 (not yet verified on the fx-CG20)
_OPENMODE_READWRITE_SHARE 0x83 (not yet verified on the fx-CG20)

syscall 0x1DA4: int Bfile_CloseFile_OS( int HANDLE );
Closes an open file in storage memory.

syscall 0x1DAF: int Bfile_WriteFile_OS( int HANDLE, const void *buf, int size );
Writes to an open file in storage memory.
Title: Re: Casio Prizm documentation
Post by: JosJuice on February 20, 2011, 07:07:43 am
Interesting. This allows us to do stuff with file, right? I don't understand how you're supposed to read the data that's in files...
Title: Re: Casio Prizm documentation
Post by: SimonLothar on February 20, 2011, 08:11:44 am
I don't understand how you're supposed to read the data that's in files...
It is
syscall 0x1DAC: int Bfile_ReadFile_OS( int HANDLE, void *buf, int size, int readpos );

I omitted this, because I have not verified it, yet.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on February 20, 2011, 09:38:24 am
It would be annoying the Prizm processor isn't like a 7705, and I don't understand why Casio would do that :(
Alas, they did.
F. i. the RTC base-address h'FFFFFEC0 has been changed to h'A413FEDC.
BTW:
syscall 0x02C1 : int RTC_GetTicks(  void  );
Returns the RTC-basecount in units of 1/128 s.


Title: Re: Casio Prizm documentation
Post by: bsl on February 20, 2011, 11:14:51 am
I am nearly in a position to patch g1a files and convert to g3a files.
Does anyone have the source basic.c to sagarvaze's advanced basic add-in ?
The source would make patching easier.

Here is the link to the download:
http://casiokingdom.org/modules.php?name=Downloads&d_op=viewdownloaddetails&cid=29&lid=535&ttitle=Basic#dldetails
Title: Re: Casio Prizm documentation
Post by: Kristaba on February 20, 2011, 12:32:09 pm
F. i. the RTC base-address h'FFFFFEC0 has been changed to h'A413FEDC.

Ok, so it look like the 7720/7721 architecture, probably without the DSP capability : http://am.renesas.com/products/mpumcu/superh/sh7700/sh7721/sh7721_root.jsp (http://am.renesas.com/products/mpumcu/superh/sh7700/sh7721/sh7721_root.jsp)
However, I know the keyboard is connected to :
"input" (column selection I guess) from PTP0 to PTP6 (7 column, similar to the fx9860 keyboard)
"output" (row?) from PTM0 to PTM5 and from PTN0 to PTN5 (12 row, similar to the fx9860 keyboard too)
But the 7720 haven't port N, so it's probably customized by Casio.

See if you find something in the OS code using the informations in the 7720/7721 datasheet :
Ports are A, B, C, D, E, F, G, H, J, K, L, M, P, R, S, T, U, V (*no* port I and N)
Ports Control Registers start at H’A405 0100 (2 bytes per port, PMCR is H'A405 0116 and PPCR is H'A405 0118)
Ports Data Registers start at H'A405 0140 (2 bytes per port, PMDR is H'A405 0156 and PPCR is H'A405 0158)

Maybe in the Prizm CPU the port N is simply between M and P using the same starting addresses, something like :
PMDR : H'A405 0156
PNDR is H'A405 0158
PPDR is H'A405 015A

I'll try to test a code using that on the Prizm emulator if I have some time, and if I have a working IsKeyDown I'll post a new message here.
Title: Re: Casio Prizm documentation
Post by: JosJuice on February 20, 2011, 01:00:09 pm
I've updated the wiki and created a "Tools" page. It contains a list of useful programs.

I've also started on a Syscalls page, but I don't know a lot about syscalls... Hopefully someone else will add more info. Most of the article is just copypaste from SimonLothar's posts.

EDIT: I also added some more info about .g3a files.
Title: Re: Casio Prizm documentation
Post by: Kristaba on February 20, 2011, 06:46:26 pm
I wrote a little G3A to test the performances of the Prizm's screen :
http://www.2shared.com/file/AMshOlW5/fps.html
(@DJ_Omnimaga : this version works now ;D)

In a loop, my application fill the VRAM with a color, print the FPS, and call PutDisp_DD().
According to Light_Spirit, the FPS is about 21, I guess PutDisp_DD() is FPS-killer, but I don't know if we could write our own VRAMtoDD really faster.
Oh, and important detail : you need to reset your calc (soft reset, whithout data lost) to quit fps.g3a
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 20, 2011, 07:27:47 pm
Hey Kristaba, I just tried it and this one works well. I get 21 FPS btw.

Also I'm happy that screen won't blurs like the Nspire. At least we won't need to artificially reduce games FPS to like 10-12 to make them playable.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 21, 2011, 02:30:40 am
Ok here's how it looks like. I noticed it oscillates between 21 and 22 fps, though. ??? Looks cool, tho. It shows third party code can be ran even more :D
Title: Re: Casio Prizm documentation
Post by: z80man on February 21, 2011, 02:52:50 am
@Kristaba, how did you set up the icons so that they would not interfere with the checksum. Also i think we can get a faster fps if we write something similar to ionfastcopy for the Prizm.
Title: Re: Casio Prizm documentation
Post by: jnesselr on February 21, 2011, 07:38:48 am
Holy double post batman j/k It was like 7 hours and worthy of a post.  I presume it oscillates based on how he is reading the fps.  There is probably a small amount of fluctuation in either the timing part or the displaying part that affects it.  How are you doing this Kristaba?
Title: Re: Casio Prizm documentation
Post by: SimonLothar on February 21, 2011, 11:33:19 am
Oh! I just tried to upload my little memviewer G3A. But alas, I am below 100 posts.
So...
http://rapidshare.com/files/449129840/INSIGHT_FOR_PRIZM_1_00.zip

new version:
http://ourl.ca/9205/181529
Title: Re: Casio Prizm documentation
Post by: JosJuice on February 21, 2011, 11:41:14 am
I still don't understand why Rapidshare call themselves the anti-waiting company... They have the longest waiting times that I know of D:

Reupload (outdated - new version is here (http://ourl.ca/9205/181529)):
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 21, 2011, 02:39:30 pm
Yeah I prefer Mediafire. Not always super fast, but it has barely any waiting time. Megaupload is nice too, but it has a small waiting time.

And yeah the post count limit is 50. I might eventually decrease it to 50, though, once I get around to revamp the section and other stuff. Otherwise I guess there's the UCF or CK.
Title: Re: Casio Prizm documentation
Post by: JosJuice on February 21, 2011, 03:00:10 pm
Yeah I prefer Mediafire. Not always super fast, but it has barely any waiting time. Megaupload is nice too, but it has a small waiting time.
Yeah, Mediafire is pretty good. I don't really like Megaupload - I prefer short initial waiting times over fast download speed, since I can do the download in the background.
And yeah the post count limit is 50. I might eventually decrease it to 50, though, once I get around to revamp the section and other stuff. Otherwise I guess there's the UCF or CK.
You mean decrease it from 100, right? :P
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 21, 2011, 03:03:47 pm
It's the same thing. I am pretty sure we can say decrease it to 50, too. From 100 doesn't tell much, since it could mean 1, 5, 99, etc.
Title: Re: Casio Prizm documentation
Post by: JosJuice on February 21, 2011, 03:06:35 pm
It's the same thing. I am pretty sure we can say decrease it to 50, too. From 100 doesn't tell much, since it could mean 1, 5, 99, etc.
Well, it looked like you wrote that the current limit is 50...
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 23, 2011, 04:37:41 pm
Oh wait I see now, it's because of my previous sentence. That was a typo, my bad.
Title: Re: Casio Prizm documentation
Post by: z80man on February 23, 2011, 09:04:16 pm
Quote from: Casio
Thank you so much sending e-mail for your precious opinion and suggestion.

We have already transferred your message to our R&D section and asked them to consider seriously in this regard.
However, we regret to say that we have no schedule and no plan to release SDK for Prizm as we said previous reply as of now.

Regarding slow speed of the BASIC language and glitches in the OS, it seems there are some differences of recognition each other.
Therefore, we would highly appreciate it if you kindly point it out concretely with some examples and the we would like to look into it based your information.

Sincerely yours,

Well well. It looks like Casio really does care.  :angel: They will even let us talk to the dev team. I'm hoping with further email between us and Casio the bugs can get ironed out and maybe even some future dev tools could be added later.
Title: Re: Casio Prizm documentation
Post by: jnesselr on February 23, 2011, 10:24:46 pm
wow, you got an email. Impressive.  Can you ask them about low-level USB?  :devil:
Title: Re: Casio Prizm documentation
Post by: m1ac4 on February 24, 2011, 07:47:21 am
Maybe these screenshots can help enlighten us on the bugged OS problem?
What it says I have:                                                                 What I actually might have:
(http://img.removedfromgame.com/imgs/Official Version Number.png) (http://img.removedfromgame.com/imgs/Version Number from hex.png)     
Notice the difference here.                                                                                              
Title: Re: Casio Prizm documentation
Post by: fxdev on February 24, 2011, 02:03:00 pm
This is no bug: http://ourl.ca/9028/177703
Please be a bit more careful before declaring everything as a bug or glitch.
Title: Re: Casio Prizm documentation
Post by: z80man on February 24, 2011, 05:00:57 pm
This is no bug: http://ourl.ca/9028/177703
Please be a bit more careful before declaring everything as a bug or glitch.
I don't think m1ca4 even declared a bug. He was referring to an issue we have been having with OS versions. As far as we know, there are actually two versions of  OS 01.02.0200.  Make sure you fully read over posts first.
Title: Re: Casio Prizm documentation
Post by: m1ac4 on February 24, 2011, 07:49:50 pm
This whole multiple OSes problem is very confusing.  I figured since Casio wanted some concrete proof of these issues then I would provide some information that I had just discovered that may or may not help out.

While I'm at it, I found some more interesting information while browsing my calculator's memory.
Starting at 0x801091E0 there are what look like most, if not all, of the messages that you will see when using the calculator.  There are a lot of different things here but notice all of the references to SD cards.  It looks like the OS has built in SD card support based on what I see in this area.  (See also 0x8000F210.  This section deals with some OS error and has the user insert a SD card to update the OS, among other things)
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 24, 2011, 07:51:38 pm
If you'll notice, there's also NOR ROM flashing. That's a part of test mode, so I suspect that the SD card can be accessed in diagnostics mode. There are a few other things in the OS I'll let you find  ;)

However, the OS update is not a part of the SD card support. That section deals with the text that is displayed under certain circumstances. Nearby phrases don't necessarily have much relation.
Title: Re: Casio Prizm documentation
Post by: m1ac4 on February 24, 2011, 08:11:18 pm
If you'll notice, there's also NOR ROM flashing. That's a part of test mode, so I suspect that the SD card can be accessed in diagnostics mode. There are a few other things in the OS I'll let you find  ;)
Things like SD card formatting, key logging/playback and some tutorial that you can enable or disable at your pleasure?
Nearby phrases don't necessarily have much relation.
Yeah, I figured that out real quick.  Trying to follow that is a bit hard at first.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 24, 2011, 08:12:22 pm
Quote from: Casio
Thank you so much sending e-mail for your precious opinion and suggestion.

We have already transferred your message to our R&D section and asked them to consider seriously in this regard.
However, we regret to say that we have no schedule and no plan to release SDK for Prizm as we said previous reply as of now.

Regarding slow speed of the BASIC language and glitches in the OS, it seems there are some differences of recognition each other.
Therefore, we would highly appreciate it if you kindly point it out concretely with some examples and the we would like to look into it based your information.

Sincerely yours,

Well well. It looks like Casio really does care.  :angel: They will even let us talk to the dev team. I'm hoping with further email between us and Casio the bugs can get ironed out and maybe even some future dev tools could be added later.
Actually on my side I got a response saying they spotted the glitches and will tell the japan dev team to fix them, but they have no schedule on when the new OS will come out.

This is no bug: http://ourl.ca/9028/177703
Please be a bit more careful before declaring everything as a bug or glitch.
Try to not be rude to other people when calling them out, though. Everyone can do mistakes.
There are a few other things in the OS I'll let you find  ;)
pr0n? O.O
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 24, 2011, 08:13:40 pm
Maybe...

>_>
<_<
Title: Re: Casio Prizm documentation
Post by: jnesselr on February 24, 2011, 09:27:01 pm
Maybe...

>_>
<_<
Man, I knew CASIO was better than TI, but this is awesome! j/k
Title: Re: Casio Prizm documentation
Post by: AngelFish on February 24, 2011, 09:29:32 pm
</censored joke about the dev team enjoying bug fixes>
Title: Re: Casio Prizm documentation
Post by: SimonLothar on February 25, 2011, 01:08:38 am
Ok, so it look like the 7720/7721 architecture...
A very important and valuable hint, THX. Perhaps they changed to the 7720, because it contains a LCD-controller...

BTW a correction: of course, the RTC base-address is h'A413FEC0. I missed a little add #-h'1C....
Title: Re: Casio Prizm documentation
Post by: SimonLothar on February 25, 2011, 04:02:26 pm
However, I know the keyboard is connected to :
"input" (column selection I guess) from PTP0 to PTP6 (7 column, similar to the fx9860 keyboard)
"output" (row?) from PTM0 to PTM5 and from PTN0 to PTN5 (12 row, similar to the fx9860 keyboard too)
I could not verify this, sry.
What I found is the following:
the keyboard matrix is represented by the word-registers
h'A44B0000, h'A44B0002, h'A44B0004, h'A44B0006, h'A44B0008, h'A44B000A.
Every single bit seems to be directly connected to a key.
So there is no matrix-scanning any more.
Every byte represents a row (exception as always: AC/ON).
Another great benefit compared to the legacy systems: you can detect any key-combination at a time!
I will add a keyboard-port-view-option in the next version of insight.g3a to visualize the key-to-bit relation.

EDIT:
On th fx-9860 there are the contacts (P103) and (P104) (on the PCB), which are integrated in the keyboard matrix. They are used to invoke some diagnostic mode and the os update.

On the fxCG's PCB we have the contacts (1), (2) and (3). These are integrated in the keyboard as well.
F. i. (3) invokes the os update.

(1) = h'0800 (port h'A44B000A)
(2) = h'0400 (port h'A44B000A)
(3) = h'0200 (port h'A44B000A)

BTW: (P301) does not seem to be integrated in the keyboard.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on February 26, 2011, 03:34:29 am
Someone PMed and asked me to provide for a syscall tutorial.
I don't know, how detailed it has to be. So, the short form for a start.

F. i. GetKey, the blocking keyboard read function:

interface: int GetKey( int*keycode );
For details of GetKey refer to fx-9860G Libraries.pdf, which is included in the fx-9860G SDK.

On the fx-CG the underlying syscall is 0x0EAB.
Implementation as inline code for the use in assembler:
Code: [Select]
   add    #-4, r15    ; create local workspace
    mov.l #h'0EAB, r0    ; 0x0EAB waits, until a key is pressed (blocking)
    mov.l #h'80020070, r2
    jsr @r2
    mov    r15, r4    ; pass the parameter *keycode
    mov    @r15, r4     ; copy keycode* to r4 for further processing
    add    #4, r15    ; free local workspace
Implementation as assembler-function for the use in C/C++:
Code: [Select]
   .export _GetKey
_GetKey:
    mov.l #h'0EAB, r0
    mov.l #h'80020070, r2
    jmp @r2    ; mind the difference between jsr (see above) and jmp!
    nop          ; edited
Mind to precede the function name with an underscore. When calling from out of C/C++ the underscore must be omitted.
If you use a syscall inside of an assembler program, you have to setup the parameter-frame yourself.
The C/C++-compilers provide for that automatically.
The parameter passing in SuperH systems is documented in f. i. SHC Manual.PDF, which is included in the fx-9860G SDK.
If you want to build a syscall library, the following MACRO could be of help:
Code: [Select]
.MACRO BIOS_JUMP FUNO, SYSCALLNAME, TAIL=nop
    .export \SYSCALLNAME'
\SYSCALLNAME'
    mov.l #h'\FUNO, r0
    mov.l #H'80020070, r2
    jmp @r2
    \TAIL'
.ENDM

; so your minimum syscall library source needs one line per syscall only
BIOS_JUMP 0EAB, _GetKey
BIOS_JUMP 18F9, _PrintXY
BIOS_JUMP 0272, _Bdisp_AllCr_VRAM
BIOS_JUMP 025F, _Bdisp_PutDisp_DD
BIOS_JUMP 1348, _WordToHex
the interfaces:
void PrintXY( int x, int y, char*string, int mode, int color );
    x and y in text-cursor coordinates;
    the first two chars of *string are ignored (the reason of which will be unravelled later, hopefully)
    mode (bit-field) = 1: writes the string in reverse
    mode (bit-field) = 0x20: does not overwrite the background
    color=0: black; color=1: blue; color=2: green; color=3: cyan; color=4: red; color=5: magenta; color=6: yellow; color=7: none
void Bdisp_AllCr_VRAM( void );
void Bdisp_PutDisp_DD( void );
void WordToHex( unsigned short value, unsigned char*buffer );
    value: value to convert into a displayable 4-char hex-string
    buffer: buffer to receive the string (size 5)
The use of PrintXY inside of an assembler source is a bit complicated:
Code: [Select]
   mov.w #h'00, r5
    mov.l r5, @-r15 ; the 5th parameter has to be passed on the stack
    mov #4, r5 ; y
    mov.l #XTEST, r6    ; this would be the pointer to a string
    mov #5, r4 ; x
    mov.l #h'18F9, r0
    mov.l #h'80020070, r2
    jsr @r2
    mov #h'00, r7 ; deletes the background
    add #4, r15    ; readjust the stack due to the 5th parameter


; example source: this code has been assembled, linked and successfully run on a fxCG 20!

Code: [Select]
   .MACRO BIOS_JSR FUNO, TAIL=nop
    mov.w #h'\FUNO', r0
    mov.l #h'80020070, r2
    jsr @r2
    \TAIL'
    .ENDM

LOCAL_WORKSPACE .EQU h'1000

program_entry:
; start of a minimum syscall tutorial example
    mov.l r14, @-r15 ; the amount of registers to push onto the stack depends on the requirements of the function
; always be sure to push any of R8..R14, which the function uses.
    mov.l r13, @-r15
    mov.l r12, @-r15
    sts.l pr, @-r15
; pr should be pushed in every subroutine, even, if it does not bsr or jsr.
; the day will come, when you implement some bsr and jsr inside of the function and you forget to push pr
    mov.l #-LOCAL_WORKSPACE, r3
    add r3, r15

; at first clear the VRAM
    BIOS_JSR 0272
; transfer the VRAM to the display driver (though it is not necessary in this case, 0EAB provides for that, too)
    BIOS_JSR 025F

main_loop:
; now wait for key-input (blocking)
    add #-4, r15 ; create a local workspace
    mov r15, r4 ; setup the function's parameter: pointer to keycode
    BIOS_JSR 0EAB
    mov @r15, r13 ; save the keycode for later use
    add #4, r15 ; free the local workspace

; now you have to decide, what do do
; first we need a bit of workspace
    add #-h'10, r15
    mov r15, r12 ; save the pointer to that workspace for a rainy day
; initialize the workspace (don't care, skip it while reading)
    mov r12, r5
    mov.l #h'01010101, r0
    mov.l r0, @r5
    add #4, r5
    mov #0, r0
    mov.l r0, @r5
    add #4, r5
    mov.l r0, @r5
    add #4, r5
    mov.l r0, @r5
; now let's convert keycode to something displayable
    mov r12, r5
    add #2, r5 ; we have to skip two bytes because of a special feature of syscall 18F9
    mov r13, r4 ; fetch the previously saved keycode
    BIOS_JSR 1348 ; syscall WordToHex

; let's display the keycode
    mov.w #h'01, r5
    mov.l r5, @-r15 ; color
    mov #1, r5 ; y
    mov.l r12, r6
    mov #h'00, r7 ; deletes the background
    mov #1, r4 ; x
    BIOS_JSR 18F9
    add #4, r15 ; adjust the stack for the 5th parameter

    add #h'10, r15 ; free the workspace

    bra main_loop
    nop

; though this program won't ever quit, the proper finalization code is appended anyhow, as reference.
; BTW: h'0EAB is aware of the MENU-key, so it is not necessary to quit the program with the RESTART button
    mov.l #LOCAL_WORKSPACE, r3
    add r3, r15
    lds.l @r15+, pr
    mov.l @r15+, r12
    mov.l @r15+, r13
    rts
    mov.l @r15+, r14
; end of a minimum syscall tutorial example

Title: Re: Casio Prizm documentation
Post by: fxdev on March 03, 2011, 12:38:58 pm
The user RAM resides at:
0x882D4000..0x882E3000 (fx-CG 10/20)
0x88030A30..0x8803FC00 (fx-9860G/GII)
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on March 03, 2011, 11:53:48 pm
Btw I didn't read the topic in a while, but are add-ins made by the community still always appearing at the same place all the time in the menu? I think I remember something about add-ins being overwritten by third-party ones. Also I think when I installed the add-in for memory viewing it erased the one by Kristaba (I think) where the screen showed the FPS and faded in/out from black to red.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on March 04, 2011, 10:48:40 am
...but are add-ins made by the community still always appearing at the same place all the time in the menu?
No. I just loaded a second copy of insight.g3a to my Prizm, using the filename insigh2.g3a and it appeared as additional item in the menu. Different filenames give different menu items, as it is with the legacy systems.
Title: Re: Casio Prizm documentation
Post by: JosJuice on March 04, 2011, 10:54:40 am
Hmm... I don't know a lot about it, but I think that would likely happen when the programmer doesn't replace 0x0EBC in the header.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on March 11, 2011, 06:44:47 pm
Direct display access

syscall 0x026B (void Bdisp_SetPoint_DD( int x, int y, unsigned short color )) writes a point directly to the display.

BTW: syscall 0x025F Bdisp_PutDisp_DD() transfers the data from VRAM to display-RAM via DMA. The DMAC-address for this operation is 0xFE008020 (channel 0). The address of DMAOR is 0xFE008060. The DMAC functions seem to be similar, if not identical compared to those of the 7705's DMAC (0xA4000020) or the 7720's DMAC (0xA4010020). The base address of the displaydriver is 0xB4000000, which does not mean, that this address can be simply used to write directly to the display! The special (undocumented) processor instruction 0x00AB seems to be kind of ping, after something has been written to a DD-related register, perhaps to sync the MPU/DD-interaction. The correspnding DMA-source register (DMARSx) is difficult to identify. At least 0xA4050130 and 0xA405013C are involved.
Every single register-address involved in accessing the display does not occur in the 7705- or 7720-lists.

Title: Re: Casio Prizm documentation
Post by: AngelFish on March 11, 2011, 06:50:38 pm
You mean that they put hardware support in for the screen?  O.O

Seems like overkill to me.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on March 12, 2011, 12:57:40 am
You mean that they put hardware support in for the screen?  O.O
Seems like overkill to me.
The amount of data to transfer when copying the complete VRAM to the display is 162 times greater than on a fx-9860. DMA seems to be reasonable.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on March 12, 2011, 04:12:10 am
...but are add-ins made by the community still always appearing at the same place all the time in the menu?
No. I just loaded a second copy of insight.g3a to my Prizm, using the filename insigh2.g3a and it appeared as additional item in the menu. Different filenames give different menu items, as it is with the legacy systems.
Ah ok, good to hear. :D
You mean that they put hardware support in for the screen?  O.O

Seems like overkill to me.
What is hardware support in this context? I am a bit lost there. Is it some sort of hardware acceleration? I'M not tech-savy about that stuff, so sorry if my question sounds stupid. ???
Title: Re: Casio Prizm documentation
Post by: AngelFish on March 12, 2011, 04:53:55 am
You mean that they put hardware support in for the screen?  O.O
Seems like overkill to me.
The amount of data to transfer when copying the complete VRAM to the display is 162 times greater than on a fx-9860. DMA seems to be reasonable.

Had to look up the acronym :P

Yeah, it seems like a good idea, given how large the screen buffer is. How do you think the cache works with it, though?

@DJ, in this context it means that there's special hardware for directly transferring memory mapped RAM that doesn't rely on the processor. It's faster than doing it with something like IonFastCopy.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on March 12, 2011, 05:29:23 am
How do you think the cache works with it, though?
I think the cache has to be flushed before DMA (direct memory access) occurs. Perhaps it is done automatically by the DMA request or by setting/toggling certain bits of the registers involved. As these registers are undocumented, this is not easy to verify (at least for me).

EDIT: I forgot to mention. VRAM usually is accessed using base address 0xA8000000, which lies within area P2, a non-cacheable memory range. Caching could be a problem, if you access VRAM using base-address 0x88000000.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on March 13, 2011, 12:49:49 am
@DJ, in this context it means that there's special hardware for directly transferring memory mapped RAM that doesn't rely on the processor. It's faster than doing it with something like IonFastCopy.
Ah cool, thanks for clarifying. :D
Title: Re: Casio Prizm documentation
Post by: fxdev on March 18, 2011, 02:29:41 pm
The monochrome picture at 0x290 and those names starting at 0x0170 are used for eActivity strips.
Just in case, this is not known yet.
Title: Re: Casio Prizm documentation
Post by: JosJuice on March 18, 2011, 03:06:04 pm
Interesting. What does that mean, and how do eActivities work? I don't have a Prizm yet, so I'm clueless about some of the math/education related stuff.
Title: Re: Casio Prizm documentation
Post by: AngelFish on March 18, 2011, 03:37:57 pm
The monochrome picture at 0x290 and those names starting at 0x0170 are used for eActivity strips.


As well as the language packs, right?
Title: Re: Casio Prizm documentation
Post by: z80man on March 18, 2011, 08:45:03 pm
eActivity is a file format for the Prizm. Casio thinks of it as an education tool, but I see it as a potential pdf like viewer. It can hold customizable text, pictures, and a few gui elements. Maybe I will make an editor some time later.
Title: Re: Casio Prizm documentation
Post by: fxdev on March 18, 2011, 09:10:53 pm
As well as the language packs, right?
I don't understand your question... :)
Language add-ins have nothing to do with eActivity strips nor any .g3a header. They extend message and menu language only.
Title: Re: Casio Prizm documentation
Post by: AngelFish on March 18, 2011, 09:28:00 pm
The add-in names are used to determine the language title to be displayed, right? That would imply that if the language changes, then the offset that the name is read from is changed correspondingly.
Title: Re: Casio Prizm documentation
Post by: fxdev on March 18, 2011, 09:46:05 pm
Yep.
Title: Re: Casio Prizm documentation
Post by: JosJuice on March 19, 2011, 04:24:15 am
eActivity is a file format for the Prizm. Casio thinks of it as an education tool, but I see it as a potential pdf like viewer. It can hold customizable text, pictures, and a few gui elements. Maybe I will make an editor some time later.
Okay. In what way are add-ins and eActivities related? Can a "link" to an add-in be displayed in an eActivity, with the monochrome icon being displayed?
Title: Re: Casio Prizm documentation
Post by: z80man on March 19, 2011, 04:42:44 am
I'll need to start dissecting those eActivities. Need to go find some because I deleted all of them from my calc. Links to apps would be pretty cool. Maybe they even provide args to the apps to open them in a certain way.
Title: Re: Casio Prizm documentation
Post by: JosJuice on March 19, 2011, 04:46:28 am
Need to go find some because I deleted all of them from my calc.
There are a few in the 1.02 OS installer. You can find the eActivity files in Temp. I'm not sure if Casio published any on their website...
Title: Re: Casio Prizm documentation
Post by: JosJuice on March 22, 2011, 03:52:30 pm
There has been some discussion in the IRC channel about file formats that could be used for potential shells. Fishbot and I have been working on formats separately for a while. I've started writing down the details of mine on a wiki sub-userpage:

http://wiki.prizmwiki.co.cc/wiki/User:JosJuice/File_stuff (http://wiki.prizmwiki.co.cc/wiki/User:JosJuice/File_stuff)

If you're wondering how something is supposed to work, or why it is in a specific way, feel free to ask.
Title: Re: Casio Prizm documentation
Post by: Goplat on March 22, 2011, 11:18:50 pm
Why not just use .g3a format?
Title: Re: Casio Prizm documentation
Post by: z80man on March 23, 2011, 12:57:19 am
@Goplat, there are several issues with the current g3a format.
1. The header size is over 29kb
2. There are checksums included which can be difficult to calculate
3. g3a files are accessed from the main menu and are treated like apps.
4. There is extensive startup and exit code that must be included with every program
5. Running from the main menu does not support the use of additional libraries (MirageOS, DoorsCS7, Ion)

besides, the Prizm file system follows the standard folder system used on desktops. That is why it is so easy to transfer files. Unlike on the 83+ you can load any file extension into memory. For example I have a copy of my Prizm emulator on my Prizm. Of course it doesn't do anything because it is exe format, but it just seems funny to me ;)

And for the shell format. I did create my own last night, but some edits need to be done. In an irc conversation I had with Qwerty, we determined that variable sized icons were the best choice to have. Here is the current format. You may notice that in the beginning of the header there are several flags that can be set. We are currently not able to accommodate support for all of the flags yet, but we should be able to later. Other features are a null terminated string for the program description and a 64x64 8 bit icon to be replaced with one of variable size, but not yet sure if it will be 16 bit, 8 bit, or variable bit yet. I do believe that it is possible to create an extension icon in the OS for files. For example in the memory manager, g3a files always show up with the geometric shape icon. 
Code: [Select]
.org $30002000
data.l $xxxxxxxx   ;header for shell   
data.l $00000002   ;size of executable
data.b $01         ;true if MMU is to be reset
data.b $03         ;speed setting, 0-3
data.b $00         ;true if interrupts are to be disabled
data.b $01         ;true if fpu interpreter is to be enabled
data.b $01         ;true if all general purpose registers are to be cleared before execution
data.b $01         ;true if VRAM and screen are to be cleared
data.b $00         ;true if executable space is to be cleared
data.b $00         ;true if to begin execution in priveleged mode
;next 176 bytes are to be used for future expansion
data.l $00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000
;next 64 bytes are for program description. Null terminated
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
;256 color 64 * 64 icon
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
;executable begins at $30004100
RST
NOP
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on March 24, 2011, 03:48:24 am
Are you planning to try finding an exploit on the calc to run hacked files and launch ASM programs from there? I'm a bit lost here. ???
Title: Re: Casio Prizm documentation
Post by: calc84maniac on March 24, 2011, 04:05:33 am
Are you planning to try finding an exploit on the calc to run hacked files and launch ASM programs from there? I'm a bit lost here. ???
I think they're going to make a shell like Ion, which allows smaller, simpler files to be executed. Actually, I think Ion's original purpose was to allow compact asm programs to be run on the TI-83 (the Send(9 trick only worked on ASCII hex, which is twice as large)
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on March 24, 2011, 04:10:30 am
Ah ok I see. But I thought Ion was pretty much like a regular program but with mixed BASIC and ASM? If you open ION.83p in SourceCoder it starts with Asm(prgmZION or something.

Would they need to find some sort of exploit that allows ASM code to be ran directly from a program or maybe even from another section? And what if no exploit is found?
Title: Re: Casio Prizm documentation
Post by: calc84maniac on March 24, 2011, 04:12:43 am
Ah ok I see. But I thought Ion was pretty much like a regular program but with mixed BASIC and ASM? If you open ION.83p in SourceCoder it starts with Asm(prgmZION or something.

Would they need to find some sort of exploit that allows ASM code to be ran directly from a program or maybe even from another section? And what if no exploit is found?
They already have code running in add-ins, I think. So they'll probably make the shell as an add-in, which in turn will load other assembly programs directly from files.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on March 24, 2011, 04:13:45 am
But I think above they mention they don't want to use g3a format, which is basically an add-in.
Title: Re: Casio Prizm documentation
Post by: calc84maniac on March 24, 2011, 04:16:03 am
But I think above they mention they don't want to use g3a format, which is basically an add-in, to save 29 KB of space (the header).
Oh, well I thought they were just saying that g3a would be really clunky for shell-based programs (which there could be dozens of on the calculator). I think there wouldn't be a huge problem with one .g3a, the shell itself.
Title: Re: Casio Prizm documentation
Post by: z80man on March 24, 2011, 04:25:34 am
Yes the only way to get machine code to run is to use the g3a format. That is what the shell itself is going to be formatted in. Then when you select a program to run from the menu, that program is loaded into ram and the execution jumps to the start of the prog. The reason for the shell is kind of like for the 83+ where you don't want to make all your programs in app format/8xk. The shell will be an app just like MirageOS or DoorsCS7 and will function in almost the exact same way. What we are still working on is how should we design the header for the shell. Because once we release the format you can't make major changes to it or else it will break compatibility with older programs. So basically we have to get it perfect the first time because there is no going back. Thats also why in my format I included expansion space where new features could be added later.
Title: Re: Casio Prizm documentation
Post by: JosJuice on March 24, 2011, 01:59:00 pm
What we are still working on is how should we design the header for the shell. Because once we release the format you can't make major changes to it or else it will break compatibility with older programs. So basically we have to get it perfect the first time because there is no going back. Thats also why in my format I included expansion space where new features could be added later.
I tried to design mine so that old shells can run newer programs if the programs don't use non-supported features (but if they have stuff like an extra icon, they'll still work fine but the extra stuff won't show up). I added a note about it on the wiki page.
Title: Re: Casio Prizm documentation
Post by: z80man on March 24, 2011, 03:22:04 pm
What I still want to do is treat libraries as separate files from the shell. That way an older shell can upload the libraries from a newer shell and use that to run newer programs. Think of it like MirageOS uploading the DoorsCS7 libraries that way it can run programs that make use of those libraries.

Title: Re: Casio Prizm documentation
Post by: JosJuice on March 24, 2011, 03:25:13 pm
What I still want to do is treat libraries as separate files from the shell. That way an older shell can upload the libraries from a newer shell and use that to run newer programs. Think of it like MirageOS uploading the DoorsCS7 libraries that way it can run programs that make use of those libraries.


What do you mean by "uploading" libraries? It would be nice if libraries are included in the shell .g3a but can be exported by the user to a library file if necessary (or the library file could be included with the shell .zip).
Title: Re: Casio Prizm documentation
Post by: Ashbad on March 24, 2011, 03:26:17 pm
I think he means kind of like how C works -- where you only include the files you want to use in the program -- but instead these are loaded on calc, and are copied into the program/Ram or something before use.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on March 24, 2011, 09:34:23 pm
On an off-topic note, I noticed that when you pull a battery during a program, while the RAM is not cleared, it seems to restore it to a previous state than it was when you turned it ON. For example, I had Sjasogun1 RPG on my Prizm, then I started writing a test BASIC program. Afterward, when runnign Insight graphical demo, I removed a battery, then the calc turned back ON, asking me the language and battery settings. My program was gone, but all Sjasogun1 files were back. I assume the RAM is stored in another RAM area or maybe even the Flash when turning the calc OFF, right?
Title: Re: Casio Prizm documentation
Post by: AngelFish on March 24, 2011, 09:37:40 pm
Yes, files are backed up in Flash storage when you save them.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on March 24, 2011, 09:52:19 pm
By saving you mean turning OFF the calc, right? I never manually put them there.
Title: Re: Casio Prizm documentation
Post by: AngelFish on March 24, 2011, 10:02:52 pm
No, simply putting them on the calc appears to do it. I think the OS copies them to flash automatically.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on March 24, 2011, 10:52:44 pm
Ah maybe. That's good in some ways in case later we have ASM/C libs for BASIC coders and crashes can occur. We don't lose our entire progress then.
Title: Re: Casio Prizm documentation
Post by: fxdev on March 31, 2011, 03:09:09 pm
A bit offtopic, but is it Japanese that is preinstalled on the Prizm?
Title: Re: Casio Prizm documentation
Post by: JosJuice on March 31, 2011, 03:53:11 pm
A bit offtopic, but is it Japanese that is preinstalled on the Prizm?
I believe we've figured out that it's actually Chinese, but I'm not sure, and I can't remember when this was discovered.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on March 31, 2011, 05:37:46 pm
About the languages, anyone figured out what's the purpose of Language file deletion options in the System/reset menu? For me it didn't even seem to do anything.
Title: Re: Casio Prizm documentation
Post by: JosJuice on April 01, 2011, 11:55:25 am
About the languages, anyone figured out what's the purpose of Language file deletion options in the System/reset menu? For me it didn't even seem to do anything.
There are two kinds of languages - pre-installed languages and add-in languages. Only add-in languages can be deleted. (Of course, I might be wrong... As you know, I don't have a Prizm)
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on April 05, 2011, 02:57:24 pm
I see. I assume this would mostly apply to official add-ins, not the community ones, right (unless someone can make a bilingual utility)?
Title: Re: Casio Prizm documentation
Post by: JosJuice on April 05, 2011, 03:05:49 pm
I see. I assume this would mostly apply to official add-ins, not the community ones, right (unless someone can make a bilingual utility)?
It applies to add-ins that translate the system into other languages, kinda like the language apps on the 83+/84+.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on April 06, 2011, 08:47:20 pm
Oh ok, but what are the uses of them if the calc is already translated in the first place? ???
Title: Re: Casio Prizm documentation
Post by: SimonLothar on April 07, 2011, 04:07:20 am
...The DMAC-address for this operation is 0xFE008020 (channel 0). The address of DMAOR is 0xFE008060...Every single register-address involved in accessing the display does not occur in the 7705- or 7720-lists...
I just noticed that the DMAC-address of the Prizm belongs to the 7730. I would not be surprised, if it turnes out, that parts of the Cyberdyne Systems Model 101 Series 800 have been used, too.
Title: Re: Casio Prizm documentation
Post by: JosJuice on April 07, 2011, 08:29:20 am
Oh ok, but what are the uses of them if the calc is already translated in the first place? ???
The calc isn't translated into every language yet, so it's possible that Casio will release new translations using add-ins.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on April 07, 2011, 11:26:13 am
The processor version register 0xFF000030 of the Prizm returns 0x10300B00.
According to the 7450/7451 hardware manual, appendix D, a CHIP-version code "is always "H'10" in the SH-4A".
The major version byte (VER) is 0x30.
The minor version byte (CUT) is 0x0B.
The product version register 0xFF000044 of the Prizm returns 0x00002C00.
Hence the Prizm processor seems to be a member of the SH-4A family, at least basically.
Another interesting thing is, that the major version byte is higher than on a 7780,
which major version byte is 0x20, according to the manuals.
Title: Re: Casio Prizm documentation
Post by: fxdev on April 07, 2011, 01:48:24 pm
Wow, this is awesome!

Quote
IDA Pro 6.0 feature list
...
+ SuperH: added SH-4a instructions
...
So you need IDA 6.0 to fully disassemble the OS?
Unfortunately, the last cracked version seems to be 5.5 :(
Title: Re: Casio Prizm documentation
Post by: AngelFish on April 07, 2011, 01:59:22 pm
How could the processor have a SuperH 4A core? That would imply that the CPU is capable of several hundred MHz.
Title: Re: Casio Prizm documentation
Post by: z80man on April 07, 2011, 02:23:27 pm
Not only would it have several hundred mHz, but also support fpu and 3d graphic instructions.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on April 08, 2011, 04:17:01 am
Another hint for expanded customization is the presence of at least two new processor instructions 0x00AB and 0x0nE3 (n=register-no.), which are not documented.
0x00AB and 0x0nE3 are new indeed, but not customized. Since the Prizm processor revealed, that it is a member of the SH-4A family, I had a closer look at the 7780 manual.
0x00AB is SYNCO (new with the 7780)
0x0nE3 is ICBI @Rn (new with the 7780)

BTW.: the SH-4A members are specified to run between 160 MHz and 600 MHz, depending on the processor type.
The SH-4 members are specified to run up to 240 MHz.
The SH-3 members are specified to run up to 200 MHz.
(http://www.renesas.eu/products/mpumcu/superh/superh_landing.jsp)
Title: Re: Casio Prizm documentation
Post by: z80man on April 08, 2011, 04:26:48 am
So why would Casio need to clear the pipeline with synco and invalidate the cache block with ICBI. Where do they use these commands.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on April 08, 2011, 04:43:16 am
So why would Casio need to clear the pipeline with synco and invalidate the cache block with ICBI. Where do they use these commands.
According to the 7780 manual, p.68, SYNCO "Prevents the next instruction from being issued until instructions issued before this instruction have been completed". It is used every time the LCD-registers are accessed.
ICBI is used in the boot code several times. The corresponding register always loaded with 0xA0000000. If I remember well, it occurs a few times inside of the OS as well.
Title: Re: Casio Prizm documentation
Post by: fxdev on April 08, 2011, 12:44:19 pm
Well, at least Insight can be compiled with -cpu=sh4 and -fpu=single
But I did not notice any difference.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on April 08, 2011, 02:03:36 pm
Well, at least Insight can be compiled with -cpu=sh4 and -fpu=single
But I did not notice any difference.
Smart idea.
There will be differences, if you declare float-variables. The compiler uses fpu-commands, indeed. But, alas, the Prizm crashs with "Illegal Code Err", t. i. no fpu-support in the processor.
Title: Re: Casio Prizm documentation
Post by: z80man on April 08, 2011, 02:19:24 pm
This to me looks like Casio used a modified SH3. TI did the same thing with the z80 when they created the 83+. I would say the instruction set is the same as the SH3 with the added SYNCO and ICBI. I would also check into the commands related to ICBI as those may be included also. For the overall proc standard peripherals may or may not be included. For example I'm not sure if the peripherals for controlling cell phone communications are available. Addresses and the functionality of hardware may have been decided by Casio, so you can't rely on the addresses provided by Renesas for any of their procs.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on April 09, 2011, 04:22:53 am
So why would Casio need ... synco and ... ICBI.
Because the Prizm processor is SH-4A-based (of course heavily customized). I do not think, that the processor is able to lie, when it says "I am a member of the SH-4A family", which it does, when you read the PVR.
Title: Re: Casio Prizm documentation
Post by: fxdev on April 14, 2011, 06:40:23 pm
BIOS checksum (0x1FFFC):
0x00..0x02FF + 0x0340..0x01FFBF

OS checksum (0xB5FFF8):
0x020000..0xB5FEAF + 0xB5FEF0..0xB5FFF7
Title: Re: Casio Prizm documentation
Post by: JosJuice on April 16, 2011, 06:28:11 am
BIOS checksum (0x1FFFC):
0x00..0x02FF + 0x0340..0x01FFBF

OS checksum (0xB5FFF8):
0x020000..0xB5FEAF + 0xB5FEF0..0xB5FFF7

Are you talking about the memory locations of those checksums, or the checksums themselves? If it's the latter, which OS?
Title: Re: Casio Prizm documentation
Post by: fxdev on April 16, 2011, 07:14:13 am
Are you talking about the memory locations of those checksums, or the checksums themselves?

xyz checksum (0x??): <= Where the checksum is stored (4 bytes)
0x??..0x?? + 0x??..0x?? <= How it is calculated (simple sum)
Title: Re: Casio Prizm documentation
Post by: JosJuice on April 16, 2011, 08:52:24 am
Ah, okay. Thanks for telling us.
Title: Re: Casio Prizm documentation
Post by: jnesselr on April 16, 2011, 11:17:33 am
So it's not RSA encrypted? That's good, as it means we could possibly change the OS, correct?
Title: Re: Casio Prizm documentation
Post by: JosJuice on April 16, 2011, 11:37:39 am
So it's not RSA encrypted? That's good, as it means we could possibly change the OS, correct?
I don't think we can be sure yet... We know about one checksum that it has, but we don't know yet if it has more. If I recall correctly, Qwerty.55 (or was it z80man?) discovered that the OS sending program requires a valid MD5 hash.
Title: Re: Casio Prizm documentation
Post by: fxdev on April 16, 2011, 01:23:55 pm
Quote
I don't think we can be sure yet... We know about one checksum that it has, but we don't know yet if it has more.

Sure, but it's the same as seen in the diagnostics menu.
And 'ABS' seems to refer to the boot code checksum - so wherever you see 'ABS', then this means 'Simon only'. :D
Title: Re: Casio Prizm documentation
Post by: Munchor on April 17, 2011, 01:31:02 pm
I was talking about this with alberthrock and would like to know if the SDK is ready for C with GCC Compiler and everything setup :D
Title: Re: Casio Prizm documentation
Post by: JosJuice on April 17, 2011, 01:45:02 pm
I was talking about this with alberthrock and would like to know if the SDK is ready for C with GCC Compiler and everything setup :D
As far as I know: Everything isn't set up, but if you want to, you can gather the things that you need and put them together yourself.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on April 17, 2011, 08:47:13 pm
I hope they didn't go the same way as TI and use a 1024 or even 2048 bit RSA private key...

At least we can still run ASM/C code easily, though.
Title: Re: Casio Prizm documentation
Post by: JonimusPrime on April 17, 2011, 10:03:04 pm
I was able to build a correctly working GCC setup and was able to build something on windows no problem. I'll upload it to my web host asap The issue now is linking, the library that simon has packaged with his setup are not gcc friendly and I'll have to look into whether I can compile them sanely in a way that will work with GCC. I spent a few hours looking into it but the biggest hold up is that. We also need a g3awrapper program, but I though kristaba had one or at least a start on one.
Title: Re: Casio Prizm documentation
Post by: z80man on April 18, 2011, 12:17:21 am
I hope they didn't go the same way as TI and use a 1024 or even 2048 bit RSA private key...

At least we can still run ASM/C code easily, though.
Not really positive, but as a note the SH4 has a built-in hardware device that specializes in the fast calculation of RSA keys. It doesn't mean that Casio used an RSA key, but they could easily if they wanted to :P
Title: Re: Casio Prizm documentation
Post by: z80man on April 20, 2011, 01:30:07 am
I've been trying to find a purpose for the SYNCO instruction that Casio used in the DirectDraw routine and I found something interesting. Now I haven't had enough time to fully disassemble the routine to find the true purpose, but what I found is that SYNCO is good for self modifying code. Reason being is the separate instruction and data caches meaning that if you modify some code that is close to the PC, the changes may not result when the instruction is executed. What SYNCO will do though is ensure that the pipeline is reorganized ensuring that the changes will take place. Now it does seem strange for Casio to use something as advanced as self-modifying code, but they just might of for this routine.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on April 21, 2011, 12:12:22 am
Uhm I feel bad about your previous post. I seriously hope they won't eventually add a RSA key or something too...
Title: Re: Casio Prizm documentation
Post by: JosJuice on April 21, 2011, 04:51:16 am
Since the prizmosdecomp.exe attachment in Goplat's post (http://ourl.ca/8207/171040) seems to be dead, here's a reupload...
Title: Re: Casio Prizm documentation
Post by: fxdev on April 21, 2011, 10:53:58 am
Ah, thanks. I did not know there is such a program! :D
However, the OS image includes the fx-CG 20 boot code (which is not written) - I would be interested in the fx-CG 10 version.

So if you own an fx-CG 10, please do the following:
- start insight
- start the memory viewer
- go to offset 0x80000000
- press [F3]
- type 0x00020000 as file size
- upload the file memory.bkp somewhere
Title: Re: Casio Prizm documentation
Post by: SimonLothar on April 21, 2011, 11:04:58 am
The differences between a fxCG10 and a fxCG20 (first 7 MB) are (apart from the calc-ID and the checksum)

fx-CG10: 0x303[1] : 0x41
fx-CG10: 0x305[1] : 0x5A

fx-CG20: 0x303[1] : 0x44
fx-CG20: 0x305[1] : 0xAA

Or have a look at "fx_calculators_SuperH_based.chm".
Title: Re: Casio Prizm documentation
Post by: fxdev on April 21, 2011, 11:12:06 am
And how is the .gp3 difference handled?
Btw, the time stamp must be different, too! ;)
Title: Re: Casio Prizm documentation
Post by: SimonLothar on April 21, 2011, 11:29:05 am
And how is the .gp3 difference handled?
I'd say: calc-type dependent branches inside of the OS. The same procedure as every year...

Btw, the time stamp must be different, too! ;)
Yes, it is.
Title: Re: Casio Prizm documentation
Post by: fxdev on April 21, 2011, 11:36:54 am
Ah, okay. I thought maybe they were scared and put this into the boot code... ;D
Title: Re: Casio Prizm documentation
Post by: JosJuice on May 10, 2011, 02:31:01 pm
I discovered some new stuff about type 1 add-ins. The wiki has been updated.

The first set of names is displayed on the main menu, and the second set is displayed in eActivities only. The icon that we thought was monochrome actually supports colors (only eight, though... The same ones as in Casio-BASIC), and it's displayed in eActivites only.

For those of you who don't know how to include add-ins in eActivities: Create a new eActivity (or use an existing one), press F2 (STRIP) and select the add-in or pre-existing menu item that you want to include.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on May 12, 2011, 05:45:16 pm
Wait, so it's possible to display add-ins at different locations than the menu? I'll have to check the wiki for more info I think...
Title: Re: Casio Prizm documentation
Post by: JosJuice on May 13, 2011, 01:32:22 am
Wait, so it's possible to display add-ins at different locations than the menu? I'll have to check the wiki for more info I think...
Yeah, it's possible to make "links" to pretty much everything from eActivities. I don't think that you'll figure out more by looking at the wiki though, because it's mostly about technical details of the file formats and not what you can do with them :P
Title: Re: Casio Prizm documentation
Post by: z80man on May 13, 2011, 02:05:25 am
I just sent this email to Renesas based off some new found evidence
Quote
Hello I have an inquiry about a device that uses a Super H processor. This device is the Casio fx-cg10 graphing calculator which is believed to use a modified SH3. Based off a reading from the rom chip the identifier "RENESAS SH7305" and "RENESAS SH7355" are found. Now Renesas does not appear to be selling either a 7305 or 7355 brand Super H so I have reason to believe that this is a custom order. If it is at all possible would a full hardware documentation be available for this version of the Super H or at least could I know which processor it is most closely related to?

Thank you for your time,
[my name was here]
I found this identifier at the end of file produced from the spreadsheet app. In my case SHEET.g3m. There appears to be more written at this location too if anyone can decipher it.

Title: Re: Casio Prizm documentation
Post by: SimonLothar on May 13, 2011, 03:50:45 am
I just sent this email to Renesas based off some new found evidence
Quote
Hello I have an inquiry about a device that uses a Super H processor. This device is the Casio fx-cg10 graphing calculator which is believed to use a modified SH3. Based off a reading from the rom chip the identifier "RENESAS SH7305" and "RENESAS SH7355" are found. Now Renesas does not appear to be selling either a 7305 or 7355 brand Super H so I have reason to believe that this is a custom order. If it is at all possible would a full hardware documentation be available for this version of the Super H or at least could I know which processor it is most closely related to?

Thank you for your time,
[my name was here]
I found this identifier at the end of file produced from the spreadsheet app. In my case SHEET.g3m. There appears to be more written at this location too if anyone can decipher it.
Usually the documentation of the customized processors (7305, 7355 and 7337) is under nondisclosure agreement.
A lot of the 7305-registers are those of the 7730.

Perhaps this is interesting, too:
http://ourl.ca/9887/189504
http://ourl.ca/9887/189510



Title: Re: Casio Prizm documentation
Post by: z80man on May 14, 2011, 02:11:06 am
I did get a response and Renesas asked me to contact a sales rep for more information. I wonder what would happen if I asked to purchase a 7305. I also found this other file that listed about a hundred semiconductor, networking, ram, flash, etc... businesses including Renesas. I can't help but suspect that these businesses contributed in some way to the Prizm hardware. I'll get more info on that later
Title: Re: Casio Prizm documentation
Post by: z80man on May 18, 2011, 04:42:20 am
In the ongoing effort to get more ram available on the Prizm I came up with a solution that could ass several dozen kilobytes to the total available area. Already we have the 512 kb add-in stack and the 128 kb heap available. There is also the system stack of 512 kb but we must be careful with that because of the changes syscalls make to it. If you did write a program that used no syscalls then you could temporarily archive the system stack along with the 61 Kb of MCS. This would free up even more area as there are many empty holes in between data areas. My latest idea was treat the VRAM as a space to allocated. For example if a program wanted to only use the top half of the vram then the rest of it could be used as free ram. This would not pose any issues on drawing as the stripe draw syscall could be used which would also increase the frame rate. But because some programs will take the vram as granted then this option cannot be enabled by default in any malloc call but must be allowed through a flag.
Title: Re: Casio Prizm documentation
Post by: TIfanx1999 on May 18, 2011, 08:18:47 am
In the ongoing effort to get more ram available on the Prizm I came up with a solution that could ass several dozen kilobytes to the total available area.
Don't you mean add ? :P

It's always cool to have more space accessible if needed though. :)
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on May 23, 2011, 12:04:09 am
Hmm interesting, I hope this works out well z80man.
Title: Re: Casio Prizm documentation
Post by: z80man on June 03, 2011, 03:44:38 am
So it seems that the Prizm's cpu, the 7305, borrows hardware from several different Renesas SuperH procs. I've already determined that the 7305 uses the exact same interrupt controller as the 7730 which is an SH4A type. The BSC also appears to be the same, but is difficult to tell as Insight only does memory reads at the longword level. The mmu though does not appear to be the same address's. One thing to note is that the 7730 does not have a built in usb controller, but I'm still convinced that Casio used a built in Renesas one. We do already know that it is not the same usb controller as the 7705 or the 7720 so checking an SH4A with a usb controller would be a good idea such as the 7763.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on June 03, 2011, 08:41:41 pm
I wonder if USB stuff will be as hard to figure out as with the TI-Nspire. From what I remember, nobody has managed to operate the USB stuff on the Nspire via Ndless yet and TI did not want to give out any info. X.x
Title: Re: Casio Prizm documentation
Post by: JosJuice on June 04, 2011, 03:50:16 am
I wonder if USB stuff will be as hard to figure out as with the TI-Nspire. From what I remember, nobody has managed to operate the USB stuff on the Nspire via Ndless yet and TI did not want to give out any info. X.x
Yes, it's probably going to be tricky. Also, I can't see any purpose in using the USB port except for pretending to be a TI calc... The Prizm's port does not seem to support mini-A.
Title: Re: Casio Prizm documentation
Post by: m1ac4 on June 06, 2011, 08:23:24 am
It doesn't support mini-A.  I've been having 3-pin issues when trying to send files between my Prizm and a friend's and tried to use a usb cable only to discover that it only accepts mini-B.
Title: Re: Casio Prizm documentation
Post by: AngelFish on June 08, 2011, 04:02:44 am
Here are some of the errors that can be generated by the AUX_DisplayErrorMessage() syscall. It takes an integer argument and generates these messages for each value. Execution of the program continues normally after EXIT is pressed.

Code: [Select]
1: "Break
Press:[EXIT]"

2: "Syntax ERROR
Press:[EXIT]"

3: "Ma ERROR
Press:[EXIT]"

4: "Memory ERROR
Press:[EXIT]"

5: "Go ERROR
Press:[EXIT]"

6: "Nesting ERROR
Press:[EXIT]"

7: "Stack ERROR
Press:[EXIT]"

8: "Argument ERROR
Press:[EXIT]"

9: "Dimension ERROR
Press:[EXIT]"

10: "Com ERROR
Press:[EXIT]"

11: "Transmit ERROR
Press:[EXIT]"

12: "Receive ERROR
Press:[EXIT]"

13: "Memory Full
Press:[EXIT]"

14: "Undefined
Press:[EXIT]"

15: "Overflow ERROR
Press:[EXIT]"

16: "Out of Domain
Press:[EXIT]"

17: "Non-Real ERROR
Press:[EXIT]"

18: "No Solution
Press:[EXIT]"

19: "Mismatch
Press:[EXIT]"

20: "No Variable
Press:[EXIT]"

21: "Not Found
Press:[EXIT]"

22: "Application ERROR
Press:[EXIT]"

23: "System ERROR
Press:[EXIT]"

24: "Already Exists
Press:[EXIT]"

25: "Complex Number
In List
Press:[EXIT]"

26: "Complex Number
In Matrix
Press:[EXIT]"

27: "Can't Solve!
Adjust initial
value or bounds.
Then Try again.
Press:[EXIT]"

28: "Range ERROR
Press:[EXIT]"

29: "Time Out
Press:[EXIT]"

30: "Condition ERROR
Press:[EXIT]"

31: "Syntax ERROR
Press:[EXIT]"

32: "Range ERROR
Press:[EXIT]"

33: "Circulat ERROR
Press:[EXIT]"

34: "No Real Roots
Press:[EXIT]"

35: ----

36: "No Real Roots
Press:[EXIT]"

37: "Version ERROR
Press:[EXIT]"

38: "Card ERROR
Press:[EXIT]"

39: "Card is protected
Press:[EXIT]"

40: "Invalid Card
Press:[EXIT]"

41: "No Card
Press:[EXIT]"

42: "SD Card Full
Press:[EXIT]"

43: "Storage Memory
Full
Press:[EXIT]"

44: "Data ERROR
Press:[EXIT]"

45: "Invalid file name
or folder name
Press:[EXIT]"

46: "Data is protected
Press:[EXIT]"
Title: Re: Casio Prizm documentation
Post by: JosJuice on June 08, 2011, 09:01:24 am
So it doesn't just return to the OS? That's great. I wonder if the SD Card messages were just left over from the older calcs or if the Prizm will support it O.O
And what's up with 35?

EDIT: What number does this syscall have?
Title: Re: Casio Prizm documentation
Post by: z80man on June 08, 2011, 12:36:28 pm
Nice find there. Those could be handy for exception handling if anyone ever uses that in programs. Good thing that they return to the program after you press exit.


Edit: BTW has anyone found which version of the MMU does the Prizm use. I've tries several different Renesas procs, but one match up in Insight.
Title: Re: Casio Prizm documentation
Post by: AngelFish on June 08, 2011, 07:58:09 pm
C/ASM files can be a maximum of 1 MB of code and data, excluding the .g3a header.
Title: Re: Casio Prizm documentation
Post by: z80man on June 09, 2011, 10:57:09 am
Just to mention we are making some progress with MMU. It doesn't appear to be exactly the TBL I've been looking for, but at 0x8804CF0C there is an array of physical addresses for the currently running app which in my case was Insight. The reason why this is not the real TBL is that the virtual page number and the page flags are missing. Also as a note these pages are each 64 kb. This would suggest that the Prizm maps as many 64 kb pages as needed to run an app up to 1 Mb. 
Title: Re: Casio Prizm documentation
Post by: SimonLothar on June 10, 2011, 01:05:45 pm
BTW has anyone found which version of the MMU does the Prizm use.
As far as I saw, the Prizm's MMU register structure matches the one of the 7730.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on June 11, 2011, 03:31:55 am
C/ASM files can be a maximum of 1 MB of code and data, excluding the .g3a header.
I'm glad it's not 8 KB like on 8xp files on the 83+
Title: Re: Casio Prizm documentation
Post by: SimonLothar on July 22, 2011, 07:10:21 am
The following syscall may be interesting:

syscall 0x184D : unsigned char*OpCodeStrPtr( int hcode, int lcode );
Returns the pointer to an OpCode's literal ASCII-representation.
hcode 0: single-byte OpCode
hcode 1: 0x7F-two-byte OpCode
hcode 2: 0xF7-two-byte OpCode
hcode 3: 0xF9-two-byte OpCode
hcode 4: 0xE5-two-byte OpCode
hcode 5: 0xE6-two-byte OpCode
hcode 6: 0xE7-two-byte OpCode

lcode is the minor OpCode-ID

Example: OpCodeStrPtr( 0, 0x81 ) returns a pointer to "sin ".

I attached a textfile, which contains a list.
Title: Re: Casio Prizm documentation
Post by: fxdev on August 02, 2011, 02:09:41 pm
If you're using the file "keybios.h" from the fx-9860G SDK, you will notice that a few keys are missing. Well, no longer...
Code: [Select]
#define KEY_CHAR_0                  0x0030
#define KEY_CHAR_1                  0x0031
#define KEY_CHAR_2                  0x0032
#define KEY_CHAR_3                  0x0033
#define KEY_CHAR_4                  0x0034
#define KEY_CHAR_5                  0x0035
#define KEY_CHAR_6                  0x0036
#define KEY_CHAR_7                  0x0037
#define KEY_CHAR_8                  0x0038
#define KEY_CHAR_9                  0x0039
#define KEY_CHAR_DP                 0x002E
#define KEY_CHAR_EXP                0x000F
#define KEY_CHAR_PMINUS             0x0087
#define KEY_CHAR_PLUS               0x0089
#define KEY_CHAR_MINUS              0x0099
#define KEY_CHAR_MULT               0x00A9
#define KEY_CHAR_DIV                0x00B9
#define KEY_CHAR_FRAC               0x00BB
#define KEY_CHAR_LPAR               0x0028
#define KEY_CHAR_RPAR               0x0029
#define KEY_CHAR_COMMA              0x002C
#define KEY_CHAR_STORE              0x000E
#define KEY_CHAR_LOG                0x0095
#define KEY_CHAR_LN                 0x0085
#define KEY_CHAR_SIN                0x0081
#define KEY_CHAR_COS                0x0082
#define KEY_CHAR_TAN                0x0083
#define KEY_CHAR_SQUARE             0x008B
#define KEY_CHAR_POW                0x00A8
#define KEY_CHAR_IMGNRY             0x7F50
#define KEY_CHAR_LIST               0x7F51
#define KEY_CHAR_MAT                0x7F40
#define KEY_CHAR_EQUAL              0x003D
#define KEY_CHAR_PI                 0x00D0
#define KEY_CHAR_ANS                0x00C0
#define KEY_CHAR_LBRCKT             0x005B
#define KEY_CHAR_RBRCKT             0x005D
#define KEY_CHAR_LBRACE             0x007B
#define KEY_CHAR_RBRACE             0x007D
#define KEY_CHAR_CR                 0x000D
#define KEY_CHAR_CUBEROOT           0x0096
#define KEY_CHAR_RECIP              0x009B
#define KEY_CHAR_ANGLE              0x7F54
#define KEY_CHAR_EXPN10             0x00B5
#define KEY_CHAR_EXPN               0x00A5
#define KEY_CHAR_ASIN               0x0091
#define KEY_CHAR_ACOS               0x0092
#define KEY_CHAR_ATAN               0x0093
#define KEY_CHAR_ROOT               0x0086
#define KEY_CHAR_POWROOT            0x00B8
#define KEY_CHAR_SPACE              0x0020
#define KEY_CHAR_DQUOTE             0x0022
#define KEY_CHAR_VALR               0x00CD
#define KEY_CHAR_THETA              0x00CE
#define KEY_CHAR_A                  0x0041
#define KEY_CHAR_B                  0x0042
#define KEY_CHAR_C                  0x0043
#define KEY_CHAR_D                  0x0044
#define KEY_CHAR_E                  0x0045
#define KEY_CHAR_F                  0x0046
#define KEY_CHAR_G                  0x0047
#define KEY_CHAR_H                  0x0048
#define KEY_CHAR_I                  0x0049
#define KEY_CHAR_J                  0x004A
#define KEY_CHAR_K                  0x004B
#define KEY_CHAR_L                  0x004C
#define KEY_CHAR_M                  0x004D
#define KEY_CHAR_N                  0x004E
#define KEY_CHAR_O                  0x004F
#define KEY_CHAR_P                  0x0050
#define KEY_CHAR_Q                  0x0051
#define KEY_CHAR_R                  0x0052
#define KEY_CHAR_S                  0x0053
#define KEY_CHAR_T                  0x0054
#define KEY_CHAR_U                  0x0055
#define KEY_CHAR_V                  0x0056
#define KEY_CHAR_W                  0x0057
#define KEY_CHAR_X                  0x0058
#define KEY_CHAR_Y                  0x0059
#define KEY_CHAR_Z                  0x005A

#define KEY_CTRL_NOP                0x0000
#define KEY_CTRL_EXE                0x7534
#define KEY_CTRL_DEL                0x7549
#define KEY_CTRL_AC                 0x753F
#define KEY_CTRL_FD                 0x755E
#define KEY_CTRL_XTT                0x7531
#define KEY_CTRL_EXIT               0x7532
#define KEY_CTRL_SHIFT              0x7536
#define KEY_CTRL_ALPHA              0x7537
#define KEY_CTRL_OPTN               0x7538
#define KEY_CTRL_VARS               0x7540
#define KEY_CTRL_UP                 0x7542
#define KEY_CTRL_DOWN               0x7547
#define KEY_CTRL_LEFT               0x7544
#define KEY_CTRL_RIGHT              0x7545
#define KEY_CTRL_F1                 0x7539
#define KEY_CTRL_F2                 0x753A
#define KEY_CTRL_F3                 0x753B
#define KEY_CTRL_F4                 0x753C
#define KEY_CTRL_F5                 0x753D
#define KEY_CTRL_F6                 0x753E
#define KEY_CTRL_CATALOG            0x7594
#define KEY_CTRL_FORMAT             0x7595
#define KEY_CTRL_CAPTURE            0x7567
#define KEY_CTRL_CLIP               0x7562
#define KEY_CTRL_PASTE              0x7554
#define KEY_CTRL_SELUP              0x7559
#define KEY_CTRL_SELDOWN            0x755C
#define KEY_CTRL_SELLEFT            0x755A
#define KEY_CTRL_SELRIGHT           0x755B
#define KEY_CTRL_COPY               0x7553
#define KEY_CTRL_CUT                0x7563
#define KEY_CTRL_INS                0x7551
#define KEY_CTRL_UNDO               0x755D
#define KEY_CTRL_MIXEDFRAC          0x7566
#define KEY_CTRL_FRACCNVRT          0x754A
#define KEY_CTRL_QUIT               0x754D
#define KEY_CTRL_LIGHT              0x756B
#define KEY_CTRL_PRGM               0x754C
#define KEY_CTRL_SETUP              0x7555
#define KEY_CTRL_HOME               0x756E
#define KEY_CTRL_END                0x756F
#define KEY_CTRL_PAGEUP             0x7564
#define KEY_CTRL_PAGEDOWN           0x7565
#define KEY_CTRL_MENU               0x7533

Added keys:
Code: [Select]
#define KEY_CTRL_FORMAT             0x7595 // SHIFT+5
#define KEY_CTRL_LIGHT              0x756B // SHIFT+OPTN (Not used by the Prizm OS)
#define KEY_CTRL_UNDO               0x755D // ALPHA+DEL
#define KEY_CTRL_HOME               0x756E // SHIFT+CURSOR_LEFT
#define KEY_CTRL_END                0x756F // SHIFT+CURSOR_RIGHT
#define KEY_CTRL_SELUP              0x7559 // Cursor keys for...
#define KEY_CTRL_SELDOWN            0x755C // ...block selection...
#define KEY_CTRL_SELLEFT            0x755A // ...when clip mode...
#define KEY_CTRL_SELRIGHT           0x755B // ...is enabled.
#define KEY_CTRL_COPY               0x7553 // F1 (clip mode)
#define KEY_CTRL_CUT                0x7563 // F2 (clip mode)

Changed keys:
Code: [Select]
#define KEY_CHAR_DQUOTE             0x0022 // Before: KEY_CHAR_DQUATE
Btw, 0x756A starts the connection wizard and 0x7D00 the test menu. Both cannot be entered normally.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on August 03, 2011, 03:29:40 am
The Prizm's LCD controller:
the renesas R61509 register pattern is a subset of the Prizm LCD controller's register set. On receiving a "Device code read (R000h)", the controller identifies itself as "renesas R61524", a manual of which could not be found yet. Moreover the term "renesas R61524" not even gives any response on the web. I fear this one is customized again. Luckily the manual of the renesas R61509 is available and covers most aspects of the Prizm LCD controller. Though, the R61509 has no backlight support. Hence some registers (f. i. h'5A1 or h'5A2) are not covered in the R61509 documentation. The renesas R61517 is a type with backlight control and would fit better. The are a lot of responses on the web, when "renesas R61517" is queried. :D But I could not find a manual yet. :(
Title: Re: Casio Prizm documentation
Post by: z80man on August 04, 2011, 01:22:06 am
Here (http://www.datasheet.co.kr/download.php?id=640917) is the manual that I've found for the r61509. it is quite complex but a lot of the information does not pertain to the Prizm so we can narrow it down. Hopefully we can get write our own simple driver soon and then we can start working on a high speed one to replace the normal syscalls.
Title: Re: Casio Prizm documentation
Post by: fxdev on August 04, 2011, 10:38:43 am
A few more datasheets: http://www.trulydisplays.com/tft/index.html
Title: Re: Casio Prizm documentation
Post by: SimonLothar on August 04, 2011, 12:51:28 pm
A few more datasheets: http://www.trulydisplays.com/tft/index.html
The R61526 and R61580 have a backlight control unit.
These findings give additional clues to understand the LCD controller of the Prizm.
The R61526 and the R61581 are completely new developments (2010). Their register patterns do not fit.
Though, the manuals could help to understand the way of modern LCD controllers.
The R65180 and the R61505 are intermediate developments (2009).
Their register numbers are a bit different to these of the R61509 (R61524), but the register descriptions match
and "used bits patterns" match too (especially in case of the gamma-control registers).
Title: Re: Casio Prizm documentation
Post by: z80man on August 19, 2011, 02:09:52 am
I found what appears to be the backup display ram for when the Prizm is in the menu and an app is paused. That location is from 0x880a2ad6 to 0x880cbd26. If you check from insight there is a screen bitmap in that block that corresponds to the currently running app. Currently I can not find any OS references to those addresses so it is not yet safe to use that space as other OS versions may use a different address
Title: Re: Casio Prizm documentation
Post by: MPoupe on August 19, 2011, 04:29:26 am
I found what appears to be the backup display ram for when the Prizm is in the menu and an app is paused. That location is from 0x880a2ad6 to 0x880cbd26. If you check from insight there is a screen bitmap in that block that corresponds to the currently running app. Currently I can not find any OS references to those addresses so it is not yet safe to use that space as other OS versions may use a different address

Simon already documented this memory in his super manual (part of his mini SDK):
syscall 0x1E62 : void SaveVRAM_1( void );
saves the VRAM to 0x880A2AD5; the buffer seems to be used while process-switching with the MENU-key.

And I used it in my jpeg variant of video player (I need all RAM I could find:-) )
Title: Re: Casio Prizm documentation
Post by: z80man on August 19, 2011, 10:00:15 am
It seems odd that Casio would use an odd number for the address of the saved vram because that means memory transfers can only be done 1 byte at a time meaning it is x4 slower than transfers that use longwords
Title: Re: Casio Prizm documentation
Post by: SimonLothar on August 27, 2011, 06:39:54 am
It seems to be reasonable to publish "fx_calculators_SuperH_based.chm" here, separated from the "mini SDK".

Version 10 removed.
broken link to Version 11 removed.

new: http://ourl.ca/8207/311914
Title: Re: Casio Prizm documentation
Post by: z80man on August 27, 2011, 04:37:04 pm
Good idea. Even though I use the gcc SDK for my projects I always keep a copy of the documentation in the SDK folder for easy reference.
Title: Re: Casio Prizm documentation
Post by: Eiyeron on August 27, 2011, 04:40:04 pm
Doesn't work
Title: Re: Casio Prizm documentation
Post by: fb39ca4 on August 27, 2011, 04:40:49 pm
Same here, I get a "Navigation to webpage was cancelled" error.
Title: Re: Casio Prizm documentation
Post by: AngelFish on August 27, 2011, 04:42:46 pm
On windows, you need to unblock the help file. Right click>properties>unblock>save.
Title: Re: Casio Prizm documentation
Post by: fb39ca4 on August 27, 2011, 05:12:04 pm
I don't see an unblock button in properties.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on August 27, 2011, 06:08:09 pm
Same here, I get a "Navigation to webpage was cancelled" error.
Usually this is a security problem.
If the CHM-file resides on a local drive, move the chm-file from the download directory to a directory with sufficient access rights.
If the CHM-file resides on a network drive, the following registry value could be missing
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions
DWORD-value MaxAllowedZone = 1


Title: Re: Casio Prizm documentation
Post by: z80man on August 27, 2011, 06:14:16 pm
The way I normally do this is use 7 zip to extract the html files from the chm. That works best for me plus its easier to view in that format imho
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on September 05, 2011, 04:15:56 pm
Weird it works fine for me it seems ???
Title: Re: Casio Prizm documentation
Post by: Eiyeron on October 05, 2011, 02:43:36 pm
i prefer to decompile the cmh to have ALL the doc pages, even the masked! :p
Title: Re: Casio Prizm documentation
Post by: JonimusPrime on October 07, 2011, 05:30:44 pm
What would be nice is if we could get much of the documentation in that chm file onto the Prizm wiki. Maybe have a section for syscalls and organize them similarly to how they are in the headers.

I personally can never seem to find anything I need when working on the GCC SDK in it and a searchable wiki would help that situation greatly.
Title: Re: Casio Prizm documentation
Post by: Eiyeron on October 23, 2011, 11:46:40 am
Finally I found how to make some coding...
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on February 25, 2012, 10:34:28 pm
Question, in PRIZM ASM and C, is there something special preventing people to use or convincing them to not use the 2nd key (like with ON on the TI-84+)? I am asking this because I noticed that most PRIZM games use F1 as confirm key instead of the standard 2nd/Enter and it tends to be rather annoying when you are used a lot to pressing 2nd. ???
Title: Re: Casio Prizm documentation
Post by: JosJuice on February 26, 2012, 03:10:05 am
Question, in PRIZM ASM and C, is there something special preventing people to use or convincing them to not use the 2nd key (like with ON on the TI-84+)? I am asking this because I noticed that most PRIZM games use F1 as confirm key instead of the standard 2nd/Enter and it tends to be rather annoying when you are used a lot to pressing 2nd. ???
The syscall that checks which keys are pressed will make SHIFT have the function it normally has in the OS, along with other keys like ALPHA and MENU. Allowing the user to use MENU to go to the main menu is desirable in some cases, and since there are no other known ways to return to the main menu, this syscall has to be used. There are other routines that can be used if the program wants to be able to detect every key. Other cases of not using SHIFT are probably just due to the programmer's preference.
Title: Re: Casio Prizm documentation
Post by: Eiyeron on February 26, 2012, 02:42:19 pm
I use always shift alpha, like A and B Butons...
Title: Re: Casio Prizm documentation
Post by: SimonLothar on April 09, 2012, 02:48:23 am
I have to apply a correction to the last version of fx_calculators_SuperH_based.chm
(http://ourl.ca/8207/238670):

syscall 0x1DA6: int Bfile_GetFileSize_OS( int HANDLE );
Returns the filesize.
syscall 0x1DA9: int Bfile_SeekFile_OS( int HANDLE, int pos );
Moves the current filepos to pos.
syscall 0x1DAB: int Bfile_Filepos( int HANDLE );
Returns the current filepos.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on April 09, 2012, 03:28:17 am
Question, in PRIZM ASM and C, is there something special preventing people to use or convincing them to not use the 2nd key (like with ON on the TI-84+)? I am asking this because I noticed that most PRIZM games use F1 as confirm key instead of the standard 2nd/Enter and it tends to be rather annoying when you are used a lot to pressing 2nd. ???
The syscall that checks which keys are pressed will make SHIFT have the function it normally has in the OS, along with other keys like ALPHA and MENU. Allowing the user to use MENU to go to the main menu is desirable in some cases, and since there are no other known ways to return to the main menu, this syscall has to be used. There are other routines that can be used if the program wants to be able to detect every key. Other cases of not using SHIFT are probably just due to the programmer's preference.
Ok thanks for the info. Actually I noticed that the Zelda demo on Planète-Casio used EXIT to go back to menu and now Ashbad's MLP game uses SHIFT fine, unlike his contest demo that used F1. (I think the Cemetech entry used F1 too)
Title: Re: Casio Prizm documentation
Post by: MPoupe on April 09, 2012, 06:49:26 am
Question, in PRIZM ASM and C, is there something special preventing people to use or convincing them to not use the 2nd key (like with ON on the TI-84+)? I am asking this because I noticed that most PRIZM games use F1 as confirm key instead of the standard 2nd/Enter and it tends to be rather annoying when you are used a lot to pressing 2nd. ???
2nd/Enter is much more inconvenient than F1 or exe (because of 2 key presses :-) ) and also Casio uses F1 as confirm key very common (at least since fx7700GB)
Title: Re: Casio Prizm documentation
Post by: SimonLothar on April 14, 2012, 05:54:08 pm
As for the Prizm's MPU again:
the SH 7724 is the closest match to the SH 7305 which has been found up to now (reported by brijohn (http://cemetech.net/forum/viewtopic.php?t=5507&start=156)).
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on April 14, 2012, 07:43:10 pm
Question, in PRIZM ASM and C, is there something special preventing people to use or convincing them to not use the 2nd key (like with ON on the TI-84+)? I am asking this because I noticed that most PRIZM games use F1 as confirm key instead of the standard 2nd/Enter and it tends to be rather annoying when you are used a lot to pressing 2nd. ???
2nd/Enter is much more inconvenient than F1 or exe (because of 2 key presses :-) ) and also Casio uses F1 as confirm key very common (at least since fx7700GB)
I see. I guess it's because I'm just so used to using 2nd as confirm key and ALPHA or Clear as cancel. On the TI-83+ series, 2nd=confirm and ALPHA=cancel is pretty much the standard in gaming since the last decade or so, although some games still use ENTER (the equivalent of EXE), some use the number pad and others the F1 to F5 keys (annoying)
Title: Re: Casio Prizm documentation
Post by: SimonLothar on July 31, 2012, 01:29:17 am
Because of the broken link in
http://ourl.ca/8207/238670
I have to apply a correction:

"fx_calculators_SuperH_based.chm" version 12

New version 13
http://ourl.ca/8207/316980
Title: Re: Casio Prizm documentation
Post by: AHelper on August 03, 2012, 03:16:22 am
Question, in PRIZM ASM and C, is there something special preventing people to use or convincing them to not use the 2nd key (like with ON on the TI-84+)? I am asking this because I noticed that most PRIZM games use F1 as confirm key instead of the standard 2nd/Enter and it tends to be rather annoying when you are used a lot to pressing 2nd. ???
2nd/Enter is much more inconvenient than F1 or exe (because of 2 key presses :-) ) and also Casio uses F1 as confirm key very common (at least since fx7700GB)
I see. I guess it's because I'm just so used to using 2nd as confirm key and ALPHA or Clear as cancel. On the TI-83+ series, 2nd=confirm and ALPHA=cancel is pretty much the standard in gaming since the last decade or so, although some games still use ENTER (the equivalent of EXE), some use the number pad and others the F1 to F5 keys (annoying)

I can understand that.  I, sadly, don't have the same experience running many games on my ti84pse since I mainly use it for GlassOS ;-) .  Do not forget the the Casio calculator line isn't the same as the TI line.  Key conventions are different.  I already made a topic on cemetech (which is also on wikiprizm) about the key conventions that Casio uses.  The key usage is what Casio set the standard at in their OS.  I am not saying that one key usage should be used and not the other, as I am not trying to debate.  I am simply stating that the two companies have different visions for how their calcs are to be used and the key usage in addins are from observations of how Casio did it.

@MPoupe, I believe DJ_O was referring to 2nd/Enter as either 2nd or Enter, not 2nd+Enter.

@SimonLothar, tytyty.  I haven't looked at this for a while and was very happy to see many things that the PrizmSDK has have documentation (especially PrintMini, PrintMiniMini (not in the SDK), Bfile_TellPos, and Scrollbar). Keep up the great work!  (Also, I documented a parameter for DisplayMBString (http://prizm.cemetech.net/index.php?title=DisplayMBString) that the chm doesn't have.)
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on August 03, 2012, 09:47:51 am
Yeah I meant 2nd and Enter separately.
Title: Re: Casio Prizm documentation
Post by: AHelper on August 03, 2012, 05:36:50 pm
I was reading through the LCD documentation and am confused.  How do I read and write directly to the LCD hardware?  I can see the syscall to select the register, but don't know what address to use for read/writing.

<edit>

I now realize that the 0xB4000000 is where you read and write to.  Maybe explain that in the chm so others don't get confused?
Title: Re: Casio Prizm documentation
Post by: AHelper on August 11, 2012, 07:44:36 pm
(bump'd)

I am having an issue.  What causes the System ERROR exceptions to be triggered?  I need to find a way to prevent these as I am reading addresses.  I notice that Insight doesn't have this issue as it can read the address just fine, but I want to know how it does it.  I didn't find anything obvious in the source for insight. Any help?

<edit>

Fixed it.  Found out what ADDRESS(x) exceptions mean.  I also found out how to override exceptions.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on August 18, 2012, 11:12:20 am
Sorry, that I did not answer earlier. (Some reasons: holiday, fair weather a. s. o..)

It seems to be not too simple to write to the Prizm's LCD-driver-interface 0xB4000000.

First the LCD-driver-register has to be selected.

If the OS issues a LCD-driver-register-select (syscall 0x01a2), it first clears bit 4 of MPU-port 0xA405013C (it looks as if this bit controls the LCD-driver's RS-bit; refer to the R61509-manual).
Then the SH-4A instruction SYNCO is performed.
Then the register number is written to 0xB4000000
Then the SH-4A instruction SYNCO is performed.
Then bit 4 of port 0xA405013C is set again.
Then the SH-4A instruction SYNCO is performed.

After a LCD-driver-register has been selected, it can be written to (by writing to 0xB4000000 again)

Every time register 0xB4000000 as well as port 0xA405013C are written to, the SH-4A-specific instruction SYNCO is performed immediately.

It is doubtful that directly writing to the LCD-driver enhances display-performance.
I observed, that writing to VRAM and moving the RAM to the LCD by DMA (syscall 0x025F/syscall 0x0260) is significantly faster than direct LCD-driver access.


Title: Re: Casio Prizm documentation
Post by: Eiyeron on August 20, 2012, 01:03:53 pm
could be the last solution faster than the syscall? Could we get some more fps?
Title: Re: Casio Prizm documentation
Post by: AHelper on August 23, 2012, 08:01:20 pm
Simon,, here's a question for you that I don't understand.  Why is it that there is no noticeable GPS change when you use Bdisp_PutDisp_DD vs Bdisp_PutStrip_DD(1,2)?  That makes me think that the delay is not in the actual copying of data.  Any thoughts?
Title: Re: Casio Prizm documentation
Post by: SimonLothar on August 25, 2012, 12:53:14 pm
Simon,, here's a question for you that I don't understand.  Why is it that there is no noticeable GPS change when you use Bdisp_PutDisp_DD vs Bdisp_PutStrip_DD(1,2)?  That makes me think that the delay is not in the actual copying of data.  Any thoughts?
I measured the following times when using syscall 0x0260

args   time in microseconds
0,0   179
0,43   5734
0,86   11281
0,129   16835
0,172   22390
0,215   28593

syscall 0x025F() is identical to syscall 0x0260(0,215).

t. i. calling 0x025F() consumes about 100 times more time compared to calling 0x0260(1,2).

Most of the time syscall 0x0260 waits for the DMA-hardware, t. i. the speed-controlling part is the DMA-hardware.
Title: Re: Casio Prizm documentation
Post by: calc84maniac on August 25, 2012, 05:00:33 pm
But is it possible to have the DMA run while the program continues? The program may have to use double-buffering in that case, but it sounds possible.
Title: Re: Casio Prizm documentation
Post by: AHelper on August 25, 2012, 06:51:28 pm
But is it possible to have the DMA run while the program continues? The program may have to use double-buffering in that case, but it sounds possible.

*AHelper bumps this question.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on August 26, 2012, 07:20:12 am
But is it possible to have the DMA run while the program continues? The program may have to use double-buffering in that case, but it sounds possible.
In fact syscall 0x0260 runs a simple wait-for-DMA-ready-loop while the DMA takes place,
only checking DMA0_CHCR_0.TE (Transfer End Flag) and DMA0_DMAOR.AE (Address Error Flag).
During this wait-loop, you could possibly do anything, which does not disturb the running DMA-job.
But that would mean to replace Bdisp_PutDisp_DD by some assembler function. Bdisp_PutDisp_DD itself does not offer any hook.
Title: Re: Casio Prizm documentation
Post by: AHelper on August 26, 2012, 08:04:49 am
But is it possible to have the DMA run while the program continues? The program may have to use double-buffering in that case, but it sounds possible.
In fact syscall 0x0260 runs a simple wait-for-DMA-ready-loop while the DMA takes place,
only checking DMA0_CHCR_0.TE (Transfer End Flag) and DMA0_DMAOR.AE (Address Error Flag).
During this wait-loop, you could possibly do anything, which does not disturb the running DMA-job.
But that would mean to replace Bdisp_PutDisp_DD by some assembler function. Bdisp_PutDisp_DD itself does not offer any hook.


Ok, that sounds interesting.  I will have to try this some time.  What would disturb it? writing to the memory it is copying (or would it not mind this)?  Using a syscall that tries to use the DMA?
Title: Re: Casio Prizm documentation
Post by: SimonLothar on August 26, 2012, 08:31:15 am
What would disturb it? writing to the memory it is copying (or would it not mind this)?  Using a syscall that tries to use the DMA?
I think any access to the LCD-controller and any syscall which accesses the LCD-controller will disturb.
DMAC0 mustn't be touched, of course (except for polling the TE- and AE-flag).
I do not know if the source memory can be written to during the DMA-transfer. But I do not see why not.

Title: Re: Casio Prizm documentation
Post by: KermMartian on August 26, 2012, 12:22:41 pm
Based on my experiences with other SoCs, you can do anything you want during an LCD DMA, as the LCD DMA controller is separate from the rest of the memory subsystem and won't prevent any other memory accesses.
Title: Re: Casio Prizm documentation
Post by: Eiyeron on August 26, 2012, 12:23:43 pm
So, Rebooting when pressing OPTN+EXP+ON makes you jump to a "Please SD Card insert", and fiddling with Fkeys make your calc format the SMEM...
Title: Re: Casio Prizm documentation
Post by: AHelper on August 26, 2012, 12:24:03 pm
hmm... I will see about using the background VRAM as a second buffer.  I don't know of anywhere that documents the required writes and such to copy the VRAM to the LCD.  Do I need to play with the LCD at all before using the DMAC?
Title: Re: Casio Prizm documentation
Post by: SimonLothar on August 26, 2012, 12:48:37 pm
hmm... I will see about using the background VRAM as a second buffer.  I don't know of anywhere that documents the required writes and such to copy the VRAM to the LCD.  Do I need to play with the LCD at all before using the DMAC?
I am about to write some little assembler function, which will transfer any rectangular range from RAM to the LCD's GRAM via DMA. When it works well I will post the source.
Title: Re: Casio Prizm documentation
Post by: Eiyeron on August 26, 2012, 12:51:22 pm
Without waiting the lcd to refresh? Would be the end of the FPS "cap"?
Title: Re: Casio Prizm documentation
Post by: AHelper on August 26, 2012, 01:16:35 pm
hmm... I will see about using the background VRAM as a second buffer.  I don't know of anywhere that documents the required writes and such to copy the VRAM to the LCD.  Do I need to play with the LCD at all before using the DMAC?
I am about to write some little assembler function, which will transfer any rectangular range from RAM to the LCD's GRAM via DMA. When it works well I will post the source.

That sounds great! Thank you for doing this.  When you make the code public, would you like me to add it to http://prizm.cemetech.net/ (http://prizm.cemetech.net/)? Link to a post here?
Title: Re: Casio Prizm documentation
Post by: calc84maniac on August 26, 2012, 01:53:01 pm
Based on my experiences with other SoCs, you can do anything you want during an LCD DMA, as the LCD DMA controller is separate from the rest of the memory subsystem and won't prevent any other memory accesses.
The LCD doesn't have its own DMA on the Prizm though, I think it's set up with the processor's DMA.
Title: Re: Casio Prizm documentation
Post by: Eiyeron on August 26, 2012, 06:41:58 pm
I love the work that Simon does, but I prefer when I understand what happen! :p
So, will the future routine be speedier than the syscall? The loop that disp_Vram creates will be avoided?
Title: Re: Casio Prizm documentation
Post by: SimonLothar on September 16, 2012, 01:04:34 pm
I love the work that Simon does, but I prefer when I understand what happen! :p
I understand that. But I need your help, too. I am no teacher. It is difficult for me to develop a proper feeling for what is necessary to document. I try to do my best, but I think I need your questions.
So, will the future routine be speedier than the syscall? The loop that disp_Vram creates will be avoided?
The loop cannot be avoided. But one of the advantages of DMA is, that you can do other things simultaneously during the DMA-transfer takes place.

I attached fx_calculators_SuperH_based_13.chm. It contains an example. Look for "History" or "LCD-DMA-hook".

Attachment removed.
Updated: http://ourl.ca/8207/318834

Title: Re: Casio Prizm documentation
Post by: AHelper on September 16, 2012, 01:07:15 pm
Wow, I am going to have to look at that in a few days. Ty!
Title: Re: Casio Prizm documentation
Post by: SimonLothar on September 16, 2012, 01:09:12 pm
When you make the code public, would you like me to add it to http://prizm.cemetech.net/ (http://prizm.cemetech.net/)? Link to a post here?
Feel yourself free.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on September 16, 2012, 01:11:57 pm
The LCD doesn't have its own DMA on the Prizm though, I think it's set up with the processor's DMA.
Yes, that's right. The processor's DMA-controller manages the transfer from the Prizms RAM to the LCD's GRAM.
Title: Re: Casio Prizm documentation
Post by: calc84maniac on September 16, 2012, 01:18:33 pm
Might it be possible that instead of a hook routine executed within a loop, there could be a function call to start a transfer, then execute some amount of code (which runs under the same constraints as a hook routine but is not called repeatedly), and then a function call to end transfer (if DMA is not finished by that point, loop until it is). I'd imagine this would work very well for double-buffered rendering, where the previous buffer is being DMA'd and the next buffer is being drawn simultaneously.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on September 16, 2012, 01:29:04 pm
Might it be possible that instead of a hook routine executed within a loop, there could be a function call to start a transfer, then execute some amount of code (which runs under the same constraints as a hook routine but is not called repeatedly), and then a function call to end transfer (if DMA is not finished by that point, loop until it is). I'd imagine this would work very well for double-buffered rendering, where the previous buffer is being DMA'd and the next buffer is being drawn simultaneously.
I expected this question. The assembler routine is divided into three segments. Initializaition, wait-loop and finalization. Possibly these three functional segments could be implemented as three separate functions. Though, I feel a bit uneasy about the SYNCO-instruction.
Title: Re: Casio Prizm documentation
Post by: AHelper on September 17, 2012, 01:00:13 pm
Note: In the Protocol 7 page in the chm, I can confirm that you can indeed send commands over USB to and from the Prizm.  It says currently that only IO was used.

Also, info on the OS update:  According to the emergency OS updater, it reports a low OS version (0.02.0200).  It may instead use this as the base OS version and could be confirmed by sending an OS with a lower version number.  Also, the OS code version for the Get Device-Info doesn't report the OS version.  For a 1.04.3200 OS it reports 1.02.0200.

Also, there is a change for the EditMBString* and DisplayMBString* commands.  The unknown variable is int start, representing the first character drawn.  This number will be used as the start of the string drawn, but the OS also does bounds adjustment. Passing 0 and the cursor set past the edge of the screen with cause start to be ignored.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on September 19, 2012, 01:57:57 am
Thanks a lot for your hints.

Note: In the Protocol 7 page in the chm, I can confirm that you can indeed send commands over USB to and from the Prizm.  It says currently that only IO was used.
Actually, I did only use the serial interface because I have not yet managed to access the Prizm via USB from out of my programs. :'( I use windows. On the fx-9860-types I run a device-enumeration based on vendor-id "VID_07CF&PID_6101". I use the match as serial device and everything works well. With the Prizm I didn't find a way to communicate via USB from out of my programs, yet. To be honest: I abandoned this project. It would be splendid, if you could help.

Also, info on the OS update:  According to the emergency OS updater, it reports a low OS version (0.02.0200).  It may instead use this as the base OS version and could be confirmed by sending an OS with a lower version number.  Also, the OS code version for the Get Device-Info doesn't report the OS version.  For a 1.04.3200 OS it reports 1.02.0200.
In fact, Get Device-Info returns different results, depending on from where it is called. The emergency OS updater resides in the bootcode. It does not care for any data in the OS range. I will add some hints to my documentation.

Also, there is a change for the EditMBString* and DisplayMBString* commands.  The unknown variable is int start, representing the first character drawn.  This number will be used as the start of the string drawn, but the OS also does bounds adjustment. Passing 0 and the cursor set past the edge of the screen with cause start to be ignored.
I will update my documentation.

THX again.
Title: Re: Casio Prizm documentation
Post by: SimonLothar on October 06, 2012, 04:14:41 am
I have uploaded version 14 of my documentation here:
http://www.casiopeia.net/forum/downloads.php?view=detail&df_id=72

The changes apply to EACT-file-structures, mainly.
Title: Re: Casio Prizm documentation
Post by: fxdev on October 15, 2012, 08:59:20 am
Out of curiosity, I tried this today: SB-88(A) cable + FA-124 2.00 + fx-cg 20.
Surprisingly, it works... but slowly. :D
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on October 15, 2012, 02:47:39 pm
What is that cable? Is it a special Casio calc cable or a standard cable under a different name? On TI calcs we're used to call our cables serial, parralel, USB (the one with the other end fitting directly in the I/O link port and direct USB (with a mini-USB end).

Also thanks for the updates guys :)
Title: Re: Casio Prizm documentation
Post by: fxdev on October 15, 2012, 03:52:50 pm
Quote
What is that cable? Is it a special Casio calc cable or a standard cable under a different name?

SB-88 is a USB-to-3pin-cable from Casio included in FA-124 USB (http://edu.casio.com/products/peripheral/fa124usb/).
SB-87 is a RS232-to-3pin cable and SB-89 is a standard USB-A-to-USB-mini-B cable.

However, buy the SB-88 cable only if you need compatibility with FA-124. It is really really slow and does not come with a 64-bit driver. Better get a Digitus USB-to-RS232 adapter plus a RS232-to-3pin cable from the web.
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on October 15, 2012, 11:58:24 pm
Ok thanks for the info. It sucks that those Casio cables are so hard to find on Ebay. >.< (especially CFX-9850G cables)
Title: Re: Casio Prizm documentation
Post by: Juju on October 16, 2012, 12:17:56 am
Is the SB-88 cable RS232 compatible? As in, does it generate a COM port? Or if I plug it in a Linux computer, will I get a /dev/ttyUSB0 device or something (with the right driver, obviously)?
Title: Re: Casio Prizm documentation
Post by: fxdev on October 16, 2012, 03:19:13 am
Quote
Is the SB-88 cable RS232 compatible? As in, does it generate a COM port?
Communication takes place via a COM port number.
Title: Re: Casio Prizm documentation
Post by: fxdev on October 19, 2012, 05:14:25 pm
Based on the discovery that a Prizm can communicate with FA-124 via the 3-pin port, I looked in the Link menu code to see if this can be achieved via USB as well... and guess what: The Prizm still supports the legacy fx-9860G/GII USB communication! :D

In OS 1.04 you have to disable the two branches at 0x801B12E0 and 0x801B12EA. The first one seems to be related to the USB cable setting and the second one to the USB communication type.

Once done, pressing [F2] will cause Windows to look for the Casio CESG502 driver (comes with FA-124) to install the Prizm hardware. However, FA-124 is not going to recognize the Prizm - but Simon's tools do now!
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on October 20, 2012, 05:00:44 am
Good to hear :)
Title: Re: Casio Prizm documentation
Post by: totoyo on October 20, 2012, 03:58:35 pm
Nice :)
Title: Re: Re: Casio Prizm documentation
Post by: Juju on October 20, 2012, 05:32:01 pm
Nice :D
Title: Re: Casio Prizm documentation
Post by: fxdev on February 14, 2013, 01:03:41 pm
Some important links:

Simon's syscall documentation: http://www.casiopeia.net/forum/downloads.php?view=detail&df_id=72

SH7724 hardware manual: http://documentation.renesas.com/doc/products/mpumcu/doc/superh/r01uh0174ej0200_sh7724.pdf
SH-4A software manual: http://documentation.renesas.com/doc/products/mpumcu/r01us0060ej0200_sh_4a.pdf

SH7705 hardware manual: http://documentation.renesas.com/doc/products/mpumcu/rej09b0082_sh7705.pdf
SH-3 software manual: http://documentation.renesas.com/doc/products/mpumcu/rej09b0317_sh_3sm.pdf
Title: Re: Casio Prizm documentation
Post by: fxdev on March 12, 2013, 05:46:43 pm
I took a small look into the emulator MPU DLLs and have made a listing of modules not described in the SH7705 and SH7724 PDFs.

SH7291 (2003 - 2011)
- FLCTL NAND Flash Controller
- Cmod C-specification module
- 64k or 256k boot code ROM

SH7337 (2005 - 2009)
- FLCTL NAND Flash Controller
- AIF Audio Controller
- SD Card Controller for SDSC
- Cmod C-specification module

SH7355 (2009 - 2011)
- Similar to SH7337
- No further information is known

SH7305 (2011 - current)
- FLCTL NAND Flash Controller with ECC
- SPU2 Sound Processing Unit
- SD Card Controller for SDHC
- Cmod C-specification module
- Cmod2A C-specification module

FLCTL seems to be described in the SH7780 (http://documentation.renesas.com/doc/products/mpumcu/rej09b0158_sh7780hm.pdf) PDF and its technical update (http://documentation.renesas.com/doc/products/mpumcu/tu/tnsh7a778ae.pdf).
FLCTL with ECC could be the one described in the SH7786 (http://documentation.renesas.com/doc/products/mpumcu/doc/superh/rej09b0501_7786hm.pdf) PDF.
SD Card Controller is under NDA.
SPU2 is under NDA, so should the AIF Audio Controller.
Cmod contains the Casio-specific extensions and is under NDA.

The sound units might be a hint towards Casio's electronic dictionaries. Thus, the SH7355 (based on SH7705) may have components not relevant to calculators, and continues to function like an SH7337 on these machines.

Concerning the Casio modules themselves, here is a list of registers:

CPU7291.DLL -- from PV-S1600 SDK -- based on SH7705
Code: [Select]
0003B0E0   43 6D 6F 64 00 43 2D 73  70 65 63 69 66 69 63 61   Cmod C-specifica
0003B0F0   74 69 6F 6E 20 6D 6F 64  75 6C 65 00 44 44 43 4C   tion module DDCL
0003B100   4B 52 30 00 45 78 74 65  72 6E 61 6C 20 43 4C 4B   KR0 External CLK
0003B110   31 20 73 65 74 74 69 6E  67 00 44 44 43 4C 4B 52   1 setting DDCLKR
0003B120   31 00 45 78 74 65 72 6E  61 6C 20 43 4C 4B 32 20   1 External CLK2
0003B130   73 65 74 74 69 6E 67 00  44 44 43 4C 4B 52 32 00   setting DDCLKR2
0003B140   45 78 74 65 72 6E 61 6C  20 43 4C 4B 33 20 73 65   External CLK3 se
0003B150   74 74 69 6E 67 00 44 44  43 4B 5F 43 4E 54 52 00   tting DDCK_CNTR
0003B160   45 78 74 65 72 6E 61 6C  20 63 6C 6F 63 6B 20 63   External clock c
0003B170   6F 6E 74 72 6F 6C 00 44  44 43 53 5F 43 4E 54 52   ontrol DDCS_CNTR
0003B180   00 45 78 74 65 72 6E 61  6C 20 43 53 20 63 6F 6E    External CS con
0003B190   74 72 6F 6C 00 48 49 5A  5F 43 4E 54 52 00 49 6E   trol HIZ_CNTR In
0003B1A0   74 65 72 72 75 70 74 20  70 69 6E 20 6C 65 76 65   terrupt pin leve
0003B1B0   6C 20 63 6F 6E 74 72 6F  6C 00 46 41 53 43 52 00   l control FASCR
0003B1C0   42 43 44 20 43 61 6C 63  75 6C 61 74 69 6F 6E 20   BCD Calculation
0003B1D0   63 6F 6E 74 72 6F 6C 00  46 41 53 53 52 41 00 42   control FASSRA B
0003B1E0   43 44 20 43 61 6C 63 75  6C 61 74 69 6F 6E 20 73   CD Calculation s
0003B1F0   6F 75 72 63 65 20 41 00  46 41 53 53 52 42 00 42   ource A FASSRB B
0003B200   43 44 20 43 61 6C 63 75  6C 61 74 69 6F 6E 20 73   CD Calculation s
0003B210   6F 75 72 63 65 20 42 00  46 41 53 44 52 00 42 43   ource B FASDR BC
0003B220   44 20 43 61 6C 63 75 6C  61 74 69 6F 6E 20 72 65   D Calculation re
0003B230   73 75 6C 74 00 53 43 4F  4C 43 52 00 53 43 20 4F   sult SCOLCR SC O
0003B240   75 74 70 75 74 20 6C 65  76 65 6C 20 63 6F 6E 74   utput level cont
0003B250   72 6F 6C 00 52 54 43 53  54 52 00 52 54 43 20 43   rol RTCSTR RTC C
0003B260   6C 6F 63 6B 20 74 69 6D  65 72 20 73 74 61 72 74   lock timer start
0003B270   00 52 54 43 43 52 00 52  54 43 20 43 6C 6F 63 6B    RTCCR RTC Clock
0003B280   20 74 69 6D 65 72 20 63  6F 6E 74 72 6F 6C 00 52    timer control R
0003B290   54 43 43 4F 52 00 52 54  43 20 43 6C 6F 63 6B 20   TCCOR RTC Clock
0003B2A0   74 69 6D 65 72 20 63 6F  6E 73 74 61 6E 74 00 52   timer constant R
0003B2B0   54 43 43 4E 54 00 52 54  43 20 43 6C 6F 63 6B 20   TCCNT RTC Clock
0003B2C0   74 69 6D 65 72 20 63 6F  75 6E 74 65 72 00 00 00   timer counter

CPU7337.DLL -- from fx-9860G/GII emulator -- based on SH7705
Code: [Select]
Cmod functionality from CPU7291.DLL + OPCR Output pin control

CPU7305.DLL --  from fx-CG 10/20 emulator -- based on SH7724
Code: [Select]
0007E560   00 00 00 00 43 6D 6F 64  00 43 2D 73 70 65 63 69       Cmod C-speci
0007E570   66 69 63 61 74 69 6F 6E  20 6D 6F 64 75 6C 65 00   fication module
0007E580   44 44 43 4C 4B 52 30 00  45 78 74 65 72 6E 61 6C   DDCLKR0 External
0007E590   20 43 4C 4B 31 20 73 65  74 74 69 6E 67 00 44 44    CLK1 setting DD
0007E5A0   43 4C 4B 52 31 00 45 78  74 65 72 6E 61 6C 20 43   CLKR1 External C
0007E5B0   4C 4B 32 20 73 65 74 74  69 6E 67 00 44 44 43 4C   LK2 setting DDCL
0007E5C0   4B 52 32 00 45 78 74 65  72 6E 61 6C 20 43 4C 4B   KR2 External CLK
0007E5D0   33 20 73 65 74 74 69 6E  67 00 44 44 43 4B 5F 43   3 setting DDCK_C
0007E5E0   4E 54 52 00 45 78 74 65  72 6E 61 6C 20 63 6C 6F   NTR External clo
0007E5F0   63 6B 20 63 6F 6E 74 72  6F 6C 00 44 44 43 53 5F   ck control DDCS_
0007E600   43 4E 54 52 00 45 78 74  65 72 6E 61 6C 20 43 53   CNTR External CS
0007E610   20 63 6F 6E 74 72 6F 6C  00 48 49 5A 5F 43 4E 54    control HIZ_CNT
0007E620   52 00 49 6E 74 65 72 72  75 70 74 20 70 69 6E 20   R Interrupt pin
0007E630   6C 65 76 65 6C 20 63 6F  6E 74 72 6F 6C 00 46 41   level control FA
0007E640   53 43 52 00 42 43 44 20  43 61 6C 63 75 6C 61 74   SCR BCD Calculat
0007E650   69 6F 6E 20 63 6F 6E 74  72 6F 6C 00 46 41 53 53   ion control FASS
0007E660   52 41 00 42 43 44 20 43  61 6C 63 75 6C 61 74 69   RA BCD Calculati
0007E670   6F 6E 20 73 6F 75 72 63  65 20 41 00 46 41 53 53   on source A FASS
0007E680   52 42 00 42 43 44 20 43  61 6C 63 75 6C 61 74 69   RB BCD Calculati
0007E690   6F 6E 20 73 6F 75 72 63  65 20 42 00 46 41 53 44   on source B FASD
0007E6A0   52 00 42 43 44 20 43 61  6C 63 75 6C 61 74 69 6F   R BCD Calculatio
0007E6B0   6E 20 72 65 73 75 6C 74  00 52 54 53 54 52 30 00   n result RTSTR0
0007E6C0   52 54 43 20 43 6C 6F 63  6B 20 74 69 6D 65 72 20   RTC Clock timer
0007E6D0   30 20 73 74 61 72 74 00  52 54 43 52 30 00 52 54   0 start RTCR0 RT
0007E6E0   43 20 43 6C 6F 63 6B 20  74 69 6D 65 72 20 30 20   C Clock timer 0
0007E6F0   63 6F 6E 74 72 6F 6C 00  52 54 43 4F 52 30 00 52   control RTCOR0 R
0007E700   54 43 20 43 6C 6F 63 6B  20 74 69 6D 65 72 20 30   TC Clock timer 0
0007E710   20 63 6F 6E 73 74 61 6E  74 00 52 54 43 4E 54 30    constant RTCNT0
0007E720   00 52 54 43 20 43 6C 6F  63 6B 20 74 69 6D 65 72    RTC Clock timer
0007E730   20 30 20 63 6F 75 6E 74  65 72 00 52 54 53 54 52    0 counter RTSTR
0007E740   31 00 52 54 43 20 43 6C  6F 63 6B 20 74 69 6D 65   1 RTC Clock time
0007E750   72 20 31 20 73 74 61 72  74 00 52 54 43 52 31 00   r 1 start RTCR1
0007E760   52 54 43 20 43 6C 6F 63  6B 20 74 69 6D 65 72 20   RTC Clock timer
0007E770   31 20 63 6F 6E 74 72 6F  6C 00 52 54 43 4F 52 31   1 control RTCOR1
0007E780   00 52 54 43 20 43 6C 6F  63 6B 20 74 69 6D 65 72    RTC Clock timer
0007E790   20 31 20 63 6F 6E 73 74  61 6E 74 00 52 54 43 4E    1 constant RTCN
0007E7A0   54 31 00 52 54 43 20 43  6C 6F 63 6B 20 74 69 6D   T1 RTC Clock tim
0007E7B0   65 72 20 31 20 63 6F 75  6E 74 65 72 00 52 54 53   er 1 counter RTS
0007E7C0   54 52 32 00 52 54 43 20  43 6C 6F 63 6B 20 74 69   TR2 RTC Clock ti
0007E7D0   6D 65 72 20 32 20 73 74  61 72 74 00 52 54 43 52   mer 2 start RTCR
0007E7E0   32 00 52 54 43 20 43 6C  6F 63 6B 20 74 69 6D 65   2 RTC Clock time
0007E7F0   72 20 32 20 63 6F 6E 74  72 6F 6C 00 52 54 43 4F   r 2 control RTCO
0007E800   52 32 00 52 54 43 20 43  6C 6F 63 6B 20 74 69 6D   R2 RTC Clock tim
0007E810   65 72 20 32 20 63 6F 6E  73 74 61 6E 74 00 52 54   er 2 constant RT
0007E820   43 4E 54 32 00 52 54 43  20 43 6C 6F 63 6B 20 74   CNT2 RTC Clock t
0007E830   69 6D 65 72 20 32 20 63  6F 75 6E 74 65 72 00 52   imer 2 counter R
0007E840   54 53 54 52 33 00 52 54  43 20 43 6C 6F 63 6B 20   TSTR3 RTC Clock
0007E850   74 69 6D 65 72 20 33 20  73 74 61 72 74 00 52 54   timer 3 start RT
0007E860   43 52 33 00 52 54 43 20  43 6C 6F 63 6B 20 74 69   CR3 RTC Clock ti
0007E870   6D 65 72 20 33 20 63 6F  6E 74 72 6F 6C 00 52 54   mer 3 control RT
0007E880   43 4F 52 33 00 52 54 43  20 43 6C 6F 63 6B 20 74   COR3 RTC Clock t
0007E890   69 6D 65 72 20 33 20 63  6F 6E 73 74 61 6E 74 00   imer 3 constant
0007E8A0   52 54 43 4E 54 33 00 52  54 43 20 43 6C 6F 63 6B   RTCNT3 RTC Clock
0007E8B0   20 74 69 6D 65 72 20 33  20 63 6F 75 6E 74 65 72    timer 3 counter
0007E8C0   00 52 54 53 54 52 34 00  52 54 43 20 43 6C 6F 63    RTSTR4 RTC Cloc
0007E8D0   6B 20 74 69 6D 65 72 20  34 20 73 74 61 72 74 00   k timer 4 start
0007E8E0   52 54 43 52 34 00 52 54  43 20 43 6C 6F 63 6B 20   RTCR4 RTC Clock
0007E8F0   74 69 6D 65 72 20 34 20  63 6F 6E 74 72 6F 6C 00   timer 4 control
0007E900   52 54 43 4F 52 34 00 52  54 43 20 43 6C 6F 63 6B   RTCOR4 RTC Clock
0007E910   20 74 69 6D 65 72 20 34  20 63 6F 6E 73 74 61 6E    timer 4 constan
0007E920   74 00 52 54 43 4E 54 34  00 52 54 43 20 43 6C 6F   t RTCNT4 RTC Clo
0007E930   63 6B 20 74 69 6D 65 72  20 34 20 63 6F 75 6E 74   ck timer 4 count
0007E940   65 72 00 52 54 53 54 52  35 00 52 54 43 20 43 6C   er RTSTR5 RTC Cl
0007E950   6F 63 6B 20 74 69 6D 65  72 20 35 20 73 74 61 72   ock timer 5 star
0007E960   74 00 52 54 43 52 35 00  52 54 43 20 43 6C 6F 63   t RTCR5 RTC Cloc
0007E970   6B 20 74 69 6D 65 72 20  35 20 63 6F 6E 74 72 6F   k timer 5 contro
0007E980   6C 00 52 54 43 4F 52 35  00 52 54 43 20 43 6C 6F   l RTCOR5 RTC Clo
0007E990   63 6B 20 74 69 6D 65 72  20 35 20 63 6F 6E 73 74   ck timer 5 const
0007E9A0   61 6E 74 00 52 54 43 4E  54 35 00 52 54 43 20 43   ant RTCNT5 RTC C
0007E9B0   6C 6F 63 6B 20 74 69 6D  65 72 20 35 20 63 6F 75   lock timer 5 cou
0007E9C0   6E 74 65 72 00 00 00 00  80 09 08 10 88 09 08 10   nter    €   ˆ
Code: [Select]
0007FA40   43 6D 6F 64 32 41 00 43  2D 73 70 65 63 69 66 69   Cmod2A C-specifi
0007FA50   63 61 74 69 6F 6E 20 6D  6F 64 75 6C 65 20 32 41   cation module 2A
0007FA60   00 43 48 52 4D 43 54 52  4C 00 43 68 61 72 61 63    CHRMCTRL Charac
0007FA70   74 65 72 20 65 78 74 65  6E 73 69 6F 6E 20 6F 70   ter extension op
0007FA80   65 72 61 74 69 6F 6E 20  63 6F 6E 74 72 6F 6C 00   eration control
0007FA90   43 48 52 43 4F 4C 4F 52  00 43 68 61 72 61 63 74   CHRCOLOR Charact
0007FAA0   65 72 20 63 6F 6C 6F 72  20 73 70 65 63 69 66 69   er color specifi
0007FAB0   63 61 74 69 6F 6E 00 43  48 52 52 41 44 44 52 00   cation CHRRADDR
0007FAC0   43 68 61 72 61 63 74 65  72 20 64 61 74 61 20 72   Character data r
0007FAD0   65 61 64 20 73 74 61 72  74 20 61 64 64 72 65 73   ead start addres
0007FAE0   73 00 43 48 52 53 49 5A  45 00 43 68 61 72 61 63   s CHRSIZE Charac
0007FAF0   74 65 72 20 64 61 74 61  20 72 65 61 64 20 6C 65   ter data read le
0007FB00   6E 67 74 68 00 4D 53 4B  52 41 44 44 52 00 4D 61   ngth MSKRADDR Ma
0007FB10   73 6B 20 64 61 74 61 20  72 65 61 64 20 73 74 61   sk data read sta
0007FB20   72 74 20 61 64 64 72 65  73 73 00 56 52 4D 57 41   rt address VRMWA
0007FB30   44 44 52 00 56 52 41 4D  20 77 72 69 74 65 20 73   DDR VRAM write s
0007FB40   74 61 72 74 20 61 64 64  72 65 73 73 00 56 52 4D   tart address VRM
0007FB50   57 53 42 49 54 00 56 52  41 4D 20 77 72 69 74 65   WSBIT VRAM write
0007FB60   20 73 74 61 72 74 20 62  69 74 00 56 52 4D 41 52    start bit VRMAR
0007FB70   45 41 00 56 52 41 4D 20  61 72 65 61 00 44 45 53   EA VRAM area DES
0007FB80   57 41 44 44 52 00 44 65  73 74 69 6E 61 74 69 6F   WADDR Destinatio
0007FB90   6E 20 77 72 69 74 65 20  73 74 61 72 74 20 61 64   n write start ad
0007FBA0   64 72 65 73 73 00 44 45  53 41 52 45 41 00 44 65   dress DESAREA De
0007FBB0   73 74 69 6E 61 74 69 6F  6E 20 61 72 65 61 00 44   stination area D
0007FBC0   4D 41 4D 43 54 52 4C 00  44 4D 41 20 64 61 74 61   MAMCTRL DMA data
0007FBD0   20 74 72 61 6E 73 66 65  72 20 6F 70 65 72 61 74    transfer operat
0007FBE0   69 6F 6E 20 63 6F 6E 74  72 6F 6C 00 56 52 4D 52   ion control VRMR
0007FBF0   41 44 44 52 00 56 52 41  4D 20 64 61 74 61 20 72   ADDR VRAM data r
0007FC00   65 61 64 20 73 74 61 72  74 20 61 64 64 72 65 73   ead start addres
0007FC10   73 00 56 52 4D 52 53 49  5A 45 00 56 52 41 4D 20   s VRMRSIZE VRAM
0007FC20   64 61 74 61 20 72 65 61  64 20 6C 65 6E 67 74 68   data read length
0007FC30   00 44 44 57 50 4F 49 4E  54 31 00 44 2F 44 2D 52    DDWPOINT1 D/D-R
0007FC40   41 4D 20 77 72 69 74 65  20 73 74 61 72 74 20 70   AM write start p
0007FC50   6F 69 6E 74 65 72 20 31  00 44 44 57 50 4F 49 4E   ointer 1 DDWPOIN
0007FC60   54 32 00 44 2F 44 2D 52  41 4D 20 77 72 69 74 65   T2 D/D-RAM write
0007FC70   20 73 74 61 72 74 20 70  6F 69 6E 74 65 72 20 32    start pointer 2
0007FC80   00 44 44 57 50 4F 49 4E  54 33 00 44 2F 44 2D 52    DDWPOINT3 D/D-R
0007FC90   41 4D 20 77 72 69 74 65  20 73 74 61 72 74 20 70   AM write start p
0007FCA0   6F 69 6E 74 65 72 20 33  00 44 44 57 50 4F 49 4E   ointer 3 DDWPOIN
0007FCB0   54 34 00 44 2F 44 2D 52  41 4D 20 77 72 69 74 65   T4 D/D-RAM write
0007FCC0   20 73 74 61 72 74 20 70  6F 69 6E 74 65 72 20 34    start pointer 4
0007FCD0   00 44 44 57 53 49 5A 45  31 00 44 2F 44 2D 52 41    DDWSIZE1 D/D-RA
0007FCE0   4D 20 77 72 69 74 65 20  6C 65 6E 67 74 68 20 31   M write length 1
0007FCF0   00 44 44 57 53 49 5A 45  32 00 44 2F 44 2D 52 41    DDWSIZE2 D/D-RA
0007FD00   4D 20 77 72 69 74 65 20  6C 65 6E 67 74 68 20 32   M write length 2
0007FD10   00 44 44 57 53 49 5A 45  33 00 44 2F 44 2D 52 41    DDWSIZE3 D/D-RA
0007FD20   4D 20 77 72 69 74 65 20  6C 65 6E 67 74 68 20 33   M write length 3
0007FD30   00 44 44 57 53 49 5A 45  34 00 44 2F 44 2D 52 41    DDWSIZE4 D/D-RA
0007FD40   4D 20 77 72 69 74 65 20  6C 65 6E 67 74 68 20 34   M write length 4
0007FD50   00 44 44 41 52 45 41 31  00 44 2F 44 2D 52 41 4D    DDAREA1 D/D-RAM
0007FD60   20 61 72 65 61 20 31 00  44 44 41 52 45 41 32 00    area 1 DDAREA2
0007FD70   44 2F 44 2D 52 41 4D 20  61 72 65 61 20 32 00 44   D/D-RAM area 2 D
0007FD80   44 41 52 45 41 33 00 44  2F 44 2D 52 41 4D 20 61   DAREA3 D/D-RAM a
0007FD90   72 65 61 20 33 00 44 44  41 52 45 41 34 00 44 2F   rea 3 DDAREA4 D/
0007FDA0   44 2D 52 41 4D 20 61 72  65 61 20 34 00 4C 41 59   D-RAM area 4 LAY
0007FDB0   4D 43 54 52 4C 00 4C 61  79 65 72 20 6F 70 65 72   MCTRL Layer oper
0007FDC0   61 74 69 6F 6E 20 63 6F  6E 74 72 6F 6C 00 00 00   ation control
Title: Re: Casio Prizm documentation
Post by: DJ Omnimaga on March 13, 2013, 01:06:45 am
Interesting find Cfxm :)