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.
Anyone know the processor speed?More importantly, how about the processor architecture?
Anyone know the processor speed?More importantly, how about the processor architecture?
C support?!!
/me is now officially buying a prism.
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.
You are kidding? :PWhoa! 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!
(More curious about if you actually made a 3rd-party OS already before the calc even comes out :P)
I HAVE ported WFRNG to the Prizm, though...Sure.... I look forward to the day when we actually do. Hopefully there is no 2048 bit key.
http://ourl.ca/8029 (http://ourl.ca/8029)
Next thing we know:I actually thought of porting Runescape to the TI calc at one point. A far less detailed one, obviously.
-Jan 1st: Casio Prizm comes out
-Late Feb: Casio SDK comes out
-One day later: Starcraft Prizm arrives. ;D
-One day later: Starcraft Prizm arrives. ;D
Seriously, color on a calc is an amazing idea that should have been done already. What are the dimensions of the screen, though?
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.
Seriously, color on a calc is an amazing idea that should have been done already. What are the dimensions of the screen, though?
wait whatSeriously, 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 whatSeriously, 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 :)
You're using calculators for math? ;_;
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.
wait whatSeriously, 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 :)
You're using calculators for math? ;_;
Indeed I am :/
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 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.
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!
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?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).
Even if it is only 29 MHZ that still isn't terrible. Processor speed isn't everything.
It's pretty good. For a calc processor, at least.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?
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?
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.
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?
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?
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.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.
What happens if the first byte of an unmodified app is changed to 0xAC?I tried changing the first byte from $AA to $AC, but the app is still not running.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.
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.What happens if the first byte of an unmodified app is changed to 0xAC?I tried changing the first byte from $AA to $AC, but the app is still not running.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.
Excellent news there!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.What happens if the first byte of an unmodified app is changed to 0xAC?I tried changing the first byte from $AA to $AC, but the app is still not running.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.
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 $70And 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?
There needs to be a site like wikiti.brandonw.net/ (http://wikiti.brandonw.net/) but for casio calcsI know how to host one on wikidot. Not a wiki per se, though. Just a place to hold info for the time being.
...
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
...
...
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 ................
...
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.
Thank you for sending e-mail.I guess they really don't have plans for a SDK. This came directly from their headquarters in Japan.
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
That's basically what I was saying :POops, 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.
|
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
@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.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.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:QuoteThank you for sending e-mail.I guess they really don't have plans for a SDK. This came directly from their headquarters in Japan.
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
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.
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.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
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.
Looks like we're already working on the hacking :PYeah 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).
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.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.
Doesn't the Prizm just pretend to be a mass storage device?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.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.
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.)
Well, it's so good at pretending that it will even give up its internal data like a USB device ;DSauce?
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)
Offset(h)
00000000 ë<.MSDOS5.0.....
00000010 ...v€ø..........
00000020 ....€.)....NO NA
00000030 ME FAT16 ..
00000040 ................
00000050 ................
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
hey, what processor is it using? Sorry, been inactive while that was discussed, i'm sure :PSuperH 3, or something like that. I'm sure that the acronym is SH3, though.
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
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?
Not if you're used to z80 :P
Otherwise it shouldn't be too difficult.
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.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?
Do you think you can add that to the wiki?Yes I'll try and get that up. ;D
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.
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?And those 8 the 83+ had were 8 bit registers. The Prizm's 16 are all 32 bit. ;D
Also, I hope that if Casio ever releases Prizm documentation that it won't be translated from Japanese to Zero Wing language...
Well hardware floating point sure sounds like something that could be useful O.OWell, 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).
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.Well hardware floating point sure sounds like something that could be useful O.OWell, 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).
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 ................
Kay. I just dumped my Prizm using Goplat's program. ;)
Ditto?Kay. I just dumped my Prizm using Goplat's program. ;)
PM? :angel:
I want one too :angel:Ditto?Kay. I just dumped my Prizm using Goplat's program. ;)
PM? :angel:: devil ::angel:
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)
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.Kay. I just dumped my Prizm using Goplat's program. ;)
PM? :angel:
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.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.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.
PM? :angel:
Dear cunstomer,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:
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,
1101100000000000
11111111111111111111111110000000
1001100100000000
0000000100010001
1101101000000000
11111111111111111111111010000110
1001101100000000
1010010101100101
1101110000000000
11111111111111111111111010000100
1001110100000000
0101101000000000
0010101010110010
0010110011010010
0010010010010010
D800
FFFF FF80
9900
0111
DA00
FFFF FE86
9B00
A565
DC00
FFFF FE84
9D00
5A00
2AB2
2CD2
2492
EDIT: The processor can only overclock to 116 MHz.aww ;_;
Maybe they're asking info to figure out how to block our third party apps in the future. Be careful.QuoteDear cunstomer,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.
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,
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.
Where did you read that?
Did you just manage to run code? O.OYes this was code. I used an existing app as my base and modified to run Qwerty's program without changing the checksum.
Or is that just the "checksum is wrong" error screen? If you have actually managed to run code, then this is epic...
Wait, so to get the checksums to run, you modified the rest of the app to fit the checksum? Great job :DThanks for the link, I'll look over it.
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.
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
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.
Z80, there's no R16 and the registers are zero indexed ;)Whoops. I must have messed up on my hex conversion. I think I might of started counting 1 so just decrement everything.
Also, JSR is short for Jump to SubRoutine. It's essentially the same as Call in z80, in terms of functionality at least.
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.
Nice! Should make it easier for people to learn SH3 assembly :DYeah, 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.
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.
I wonder if it would take 9001 days to write, as well... Then it would almost take 25 years!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'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.
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.
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.:w00t:
/me is happy
/me thanks Z80 for clarifying how to defeat the 32 bit checksum.:w00t::w00t::w00t:
Oh I see. Wow, so they actually got fewer memory in Australia. X.xYeah 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).
Well, DJ kind of ninja'd my Wabbit discovery, which I also coincidentally made last night :PNice, 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.
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
Oh I see. Wow, so they actually got fewer memory in Australia. X.xThis is only true for the fx-9860G AU - not the fx-9860G AU Plus.
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.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.
Yes, I was trying to overclock my Prizm :P
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.
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.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)
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.
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.
It isn't ;)Oh, I meant to say I didn't know rts is a delayed branch instruction. Therefore I should probaly place a nop after it.
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.
It'd be similar to looking for a needle in a pile of needles.
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.
D101
FFFFFFE0
D201
00000000
6123
0009
D101
FFFFFFE0
D201
00000000
2219
0009
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.
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.
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.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:
That sucks :'(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.
Changing the speed is dangerous and slow, so they would be idiots to change it every time the parser is run.
For 1->A To 1000
Locate 1,1,A
Next
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.Did you time each one with a stop-watch?
And the test program was this:Code: [Select]For 1->A To 1000
Locate 1,1,A
Next
Yep.And what were the times? Try 10,000.
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.
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?
Perhaps they're too scared that we'll hack it ::)Probably fairly easily. Qwerty.55: Have you gotten that usb stuff yet?
My computer absolutely refuses to let me install Linux of any kind or even allow VirtualBox to run :PIs 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.
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.
My computer absolutely refuses to let me install Linux of any kind or even allow VirtualBox to run :PI'm downloading the iso for Ubuntu 10.10 as we speak so that I can set up Virtualbox.
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.
Excellent, thank you!My computer absolutely refuses to let me install Linux of any kind or even allow VirtualBox to run :PI'm downloading the iso for Ubuntu 10.10 as we speak so that I can set up Virtualbox.
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.
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.
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.
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?
for ( i = 0x80010000; i <= 0x8024FFF7; i++){ result += *(unsigned char*)i; };
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...
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.
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.
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.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?
Do you think it's going to be released soon?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.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?
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 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.
I don't know about anyone else, but here's the data I've been wanting for quite some time: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?
Screen buffer address: 0xA8000000
Screen buffer size: 0x28800 (162 Kilobytes)
Enjoy :)
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?
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. ;-)
A member of the Casio community who's been hacking the Prizm independently of us.
Oh, okay, thanks. He seems intelligent.QuoteA 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
He seems intelligent.Oh, that's uncommonly kind of you.
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++?QuoteHe 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. :)
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.
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.
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.
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?
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?
By the way, does anyone have a quick bit of code to disable virtual memory for add-ins?
What happened if you try to access to 0xA4000120? MMU error or you simply always read 0?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.
It would be annoying the Prizm processor isn't like a 7705, and I don't understand why Casio would do that.
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
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 - 0x80309030This 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.
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.
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:
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";
GetStackPtr
I guess its just like bcall_HLplus5 and bcall_HLplus9 in terms of pointlessnessQuoteGetStackPtr
Um, MOV.L R15,Rn was too difficult?
else if ( iSyscall == 0x1161 ) name = "MB_IsLead";Are you sure the first one isn't some kind of strcmp? :p
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";
Yes, you are right. 0x116E is strncmp.else if ( iSyscall == 0x116E ) name = "memcmp";Are you sure the first one isn't some kind of strcmp? :p
...
else if ( iSyscall == 0x1dd1 ) name = "memcmp";
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.Yes, you are right. 0x116E is strncmp.else if ( iSyscall == 0x116E ) name = "memcmp";Are you sure the first one isn't some kind of strcmp? :p
...
else if ( iSyscall == 0x1dd1 ) name = "memcmp";
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).Yes, you are right. 0x116E is strncmp.else if ( iSyscall == 0x116E ) name = "memcmp";Are you sure the first one isn't some kind of strcmp? :p
...
else if ( iSyscall == 0x1dd1 ) name = "memcmp";
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").
Firstly, what do you know about the G3A header checksum...it's the last information I need for my G3A wrapperIt'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?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.
I wrote a FastGetKey for fx9860...
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.
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)Firstly, what do you know about the G3A header checksum...it's the last information I need for my G3A wrapperIt'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.
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?
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-in000290: 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
I notice that wiki claims that 0x0290-0x058F is garbage, but it's actually a small (64x24) black-and-white icon.
Actually no which makes calculating the crc even harder.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?
I don't understand how you're supposed to read the data that's in files...It is
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.
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
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...
Thank you so much sending e-mail for your precious opinion and suggestion.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.
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,
This is no bug: http://ourl.ca/9028/177703I 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.
Please be a bit more careful before declaring everything as a bug or glitch.
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.
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.Quote from: CasioThank you so much sending e-mail for your precious opinion and suggestion.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.
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,
This is no bug: http://ourl.ca/9028/177703Try to not be rude to other people when calling them out, though. Everyone can do mistakes.
Please be a bit more careful before declaring everything as a bug or glitch.
There are a few other things in the OS I'll let you find ;)pr0n? O.O
Maybe...Man, I knew CASIO was better than TI, but this is awesome! j/k
>_>
<_<
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...
However, I know the keyboard is connected to :I could not verify this, sry.
"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)
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++: .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..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: 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
.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
...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.
You mean that they put hardware support in for the screen? O.OThe 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.
Seems like overkill to me.
Ah ok, good to hear. :D...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.
You mean that they put hardware support in for the screen? O.OWhat 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. ???
Seems like overkill to me.
You mean that they put hardware support in for the screen? O.OThe 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.
Seems like overkill to me.
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).
@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
The monochrome picture at 0x290 and those names starting at 0x0170 are used for eActivity strips.
As well as the language packs, right?I don't understand your question... :)
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?
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...
.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
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)
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.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.
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?
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.
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.
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).
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.
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)
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+.
...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.
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.
IDA Pro 6.0 feature listSo you need IDA 6.0 to fully disassemble the OS?
...
+ SuperH: added SH-4a instructions
...
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.
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.
Well, at least Insight can be compiled with -cpu=sh4 and -fpu=singleSmart idea.
But I did not notice any difference.
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.
BIOS checksum (0x1FFFC):Are you talking about the memory locations of those checksums, or the checksums themselves? If it's the latter, which OS?
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?
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.
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.
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 :DAs 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.
I hope they didn't go the same way as TI and use a 1024 or even 2048 bit RSA private key...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
At least we can still run ASM/C code easily, though.
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.
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
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?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.
Thank you for your time,
[my name was here]
I just sent this email to Renesas based off some new found evidenceUsually the documentation of the customized processors (7305, 7355 and 7337) is under nondisclosure agreement.QuoteHello 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?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.
Thank you for your time,
[my name was here]
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
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.xYes, 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.
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]"
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.
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+
#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
#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)
#define KEY_CHAR_DQUOTE 0x0022 // Before: KEY_CHAR_DQUATE
A few more datasheets: http://www.trulydisplays.com/tft/index.htmlThese findings give additional clues to understand the LCD controller of the Prizm.
The R61526 and R61580 have a backlight control unit.
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
Same here, I get a "Navigation to webpage was cancelled" error.Usually this is a security problem.
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)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.
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)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)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)
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
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.
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,
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.
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.
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.
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.
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.
I love the work that Simon does, but I prefer when I understand what happen! :pI 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.
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.
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.
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.
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.
What is that cable? Is it a special Casio calc cable or a standard cable under a different name?
Is the SB-88 cable RS232 compatible? As in, does it generate a COM port?Communication takes place via a COM port number.
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
Cmod functionality from CPU7291.DLL + OPCR Output pin control
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 € ˆ
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