Omnimaga
Calculator Community => Casio Calculators => Topic started by: z80man on January 04, 2011, 02:23:03 am
-
The Casio Prizm is going to bring a new era to calc development. Its biggest feature being the 216x384 16 bit color screen. This as many know will expand the possibilities of what was previously thought possible on a calc. No longer will we be restricted to low resolution monochrome screens. As a result a list of what the community wants to accomplish throughout the next few years will help serve as a guide to developers. :)
TI 83+/nspire emulator: There are many great games currently on ticalc. Porting them to the the Prizm will take a long time and will be impossible for some games in which the original source code has been lost. An emulator will be a difficult project to achieve though. All the ports and hardware would have to be emulated properly to allow games that use grayscale and acsess the archive and usb port to run properly.
Overclocking: Hopefully the Prizm can be clocked far past 29mhz in software. If overclocking requires physical alteration of the calc many people will not be able to enjoy games that utilize that ability. If overclocking is done care must be taken to ensure that other people's calcs are not damaged by malicious code.
Axe: After running several tests Prizm basic seems quite slow. This is most visible in any form of drawing operation. Therefore Axe will need to be ported to the Prizm allowing great games to be written much faster (both actual time to write code and speed)
Archive: The current restraints of 16mb of archive put a limit on future development. External archive additions will need to be created to open up more possibilities. Doing this though will require great knowlege on the Prizm's ports and usb protocols.
Video: This could be the first time we see real looking video on a calc. The proc seems fast enough to support it and the screen has a high resolution with 16 bits of color. The only modification needed will probaly be more archive space.
Wifi: Using this could open up many paths for development. Users will be able to connect from much farther than 3 feet away on a cord. Imagine playing a 2 person version of Phoenix on your calc with someone thousands of miles away. We could even make omnimaga accsessible from your calc.
-
Yeah I would like to see stuff like Axe for this calc so it's not just limited to ASM and C programmers when it successfully gets cracked.
As for video I forsee porn sharing in school, though. :P
Also does the calc have built-in wifi?
-
Also does the calc have built-in wifi?
No. It just has USB and a link port, like the 84+(SE).
-
Ah ok, I thought it did since he mentionned Wifi.
-
Ah ok, I thought it did since he mentionned Wifi.
I just mean wifi could be added through the usb port. I think someone else was close to adding that onto the 84.
-
KermMartian is working on Global CALCnet, but I can never remember how far he is into wi-fi stuff. It requires some additional hardware and currently works via link port, though. But again, we have little documentation on the 84+ USB protocol.
-
Wi-Fi would require a Wi-Fi dongle, and possibly an external power supply as well as a lot of processing power. It would probably be possible to use Wi-Fi in some way, but it might not be very fast or efficient.
-
Wi-Fi would require a Wi-Fi dongle, and possibly an external power supply as well as a lot of processing power. It would probably be possible to use Wi-Fi in some way, but it might not be very fast or efficient.
Fixed. Unless you can get one to work in under 100 mA, then you could do wifi.
-
Archive: The current restraints of 16mb of archive put a limit on future development. External archive additions will need to be created to open up more possibilities. Doing this though will require great knowlege on the Prizm's ports and usb protocols.
Video: This could be the first time we see real looking video on a calc. The proc seems fast enough to support it and the screen has a high resolution with 16 bits of color. The only modification needed will probaly be more archive space.
The Prizm has 32 MB of archive, 16 MB of which is probably OS. Also, video is already available on the Prizm. It's in .g3b format, which has a header almost identical to the .g3p header I already cracked.
Thanks for making this thread, though. I have a few things I might want to add later.
-
Archive: The current restraints of 16mb of archive put a limit on future development. External archive additions will need to be created to open up more possibilities. Doing this though will require great knowlege on the Prizm's ports and usb protocols.
Video: This could be the first time we see real looking video on a calc. The proc seems fast enough to support it and the screen has a high resolution with 16 bits of color. The only modification needed will probaly be more archive space.
The Prizm has 32 MB of archive, 16 MB of which is probably OS. Also, video is already available on the Prizm. It's in .g3b format, which has a header almost identical to the .g3p header I already cracked.
Aren't .g3b files limited to 20 frames or something?
-
I don't know. Given that the format is very similar to .flv files, I'd be surprised at that, though.
-
Hey, once you guys crack it enough, I'll sign up to make an axe variant for the prizm. I will obviously need a few more people to help (someone who knows SuperH3 asm a bit better, as I know none (yet)), but I'm interested. Just PM through omni z80Man or anyone else who is in charge of prizm cracking.
-
I don't know. Given that the format is very similar to .flv files, I'd be surprised at that, though.
I found it! Page 15-8 in the manual, under "Plotting Points in a g3b File".
"A g3b file is a special Picture Plot file that can contain up to 30 images in one file."
-
Ah, okay.
Overclocking: Hopefully the Prizm can be clocked far past 29mhz in software. If overclocking requires physical alteration of the calc many people will not be able to enjoy games that utilize that ability. If overclocking is done care must be taken to ensure that other people's calcs are not damaged by malicious code.
This code will overclock the processor to 6x it's normal speed ;D
#include "iodefine.h"
void pll3(void) ;
void pll3(void) {
CPG.WTCNT = 0x5a00 ;
CPG.WTCSR = 0xa502 ;
CPG.FRQCR.WORD = 0x8210 ;
}
-
nice discovery, but where di you find this? Just wondering lol
-
I wrote it :P
The manufacturer, Renesas, made a lot of documentation available and I modified one of their programs to overclock the processor instead of underclock it. I've documented much of the CPU timer stuff here (http://wiki.prizmwiki.co.cc/wiki/CPU_clocks#Changing_clock_frequencies). There's still a bit more I need to add about the Bus clock, the WDTCR register, and the STBCR/STBCR2 registers.
EDIT: Corrected the register names
-
cool, sounds like you're already getting far into cracking already. Good luck! :)
-
Additional goals:
High level markup language: Let's face it, graphic design in Axe sucks. It'll be even worse on the Prizm where you're forced to use two byte color codes instead of simple B/W bitmaps.
Basic Web Browser: Who wouldn't want to visit OmnimIRC on a Prizm? It's not like anyone puts SuperH assembly Virii on the Internet either :P
Calculator shell: This is a necessity since the Prizm apparently includes no way to execute Assembly programs within the OS.
3rd party OS: If Prizm-OS is really 16MB, then I'm sure we can make something better. This might be a bit ambitious though,
-
Well graphics in Axe aren't too bad considering it's just a 83+. In ASM it's a major PITA to make grayscale compared to Axe and in TI-BASIC you're limited like crazy, unlike in Axe, where you can do more and in ASM, where you can do everything, although harder. It would be nice to have spriting libraries and stuff, though.
As for a shell, I wonder if it will work like on the TI-73, 82 and 85, where a hacked backup file of the RAM is sent to the calc?
As for overclocking, IMHO it shouldn't require hardware mods. We need to make it available for as many people as possible.
-
As for a shell, I wonder if it will work like on the TI-73, 82 and 85, where a hacked backup file of the RAM is sent to the calc?
It seems like an add-in is the best choice right now.
-
We need an Assembler. Writing that frequency change routine in Machine code was a PITA :P
-
I imagine. That said, maybe if Xeda ever gets interested in Prizm hex... :P
-
I imagine. That said, maybe if Xeda ever gets interested in Prizm hex... :P
I could write a compiler, but I don't have a prizm and actually testing would be a pain to make sure everything worked correctly.
-
I imagine. That said, maybe if Xeda ever gets interested in Prizm hex... :P
I could write a compiler, but I don't have a prizm and actually testing would be a pain to make sure everything worked correctly.
It will be tough to write a compiler considering that SH3 asm has many more commands than the z80.
-
I imagine. That said, maybe if Xeda ever gets interested in Prizm hex... :P
DJ, I wrote the entire program in Binary, then translated it to Hex :P
-
I imagine. That said, maybe if Xeda ever gets interested in Prizm hex... :P
DJ, I wrote the entire program in Binary, then translated it to Hex :P
O.O
How? O.O
Next thing I know, Qwerty.55 will have ported Starcraft 64 to the Casio Prizm.
-
I imagine. That said, maybe if Xeda ever gets interested in Prizm hex... :P
DJ, I wrote the entire program in Binary, then translated it to Hex :P
O.O
How? O.O
Next thing I know, Qwerty.55 will have ported Starcraft 64 to the Casio Prizm.
Yeah, he used the data-sheet, basically wrote a program and compiled it himself. (As in, not by a program, but by hand)
-
So, wait, you can already run code on the prizm? cool!
Nspire emulation is most likely a no-go, unless you can get that overclocking to around 800 mhz-1Ghz, which would be insane. It takes a lot of power to emulate stuff, compared to the actual power of what you're emulating. However, color Snes emulation....drool
-
Not sure yet, if I remember he still couldn't get third-party apps to install or something. It's promising, though. Hopefully we can soon manage to successfully run them.
-
Next thing I know, Qwerty.55 will have ported Starcraft 64 to the Casio Prizm.
Done :P
Also, Necro...
-
No, not a necro. It has been over 2 months :P
btw, it is quite fun to read these old posts and to see how far we've come.
-
No, not a necro. It has been over 2 months :P
btw, it is quite fun to read these old posts and to see how far we've come.
We have come pretty far since I started lurking for about 2 years and doing nothing at all. We cracked the freaking nSpire, and as if that wasn't enough of a breakthrough, we can run Doom, GB(C) ROMs, and NES ROMs on it. on it.
-
No, not a necro. It has been over 2 months :P
btw, it is quite fun to read these old posts and to see how far we've come.
We have come pretty far since I started lurking for about 2 years and doing nothing at all. We cracked the freaking nSpire, and as if that wasn't enough of a breakthrough, we can run Doom, GB(C) ROMs, and NES ROMs on it. on it.
Well were actually talking about the Prizm here not the nspire :P
but Doom, GB, and NES does sound interesting.
/me goes off to make Doom, a GB emulator, and an NES emulator and will not return till all 3 are finished
or his demands are met...
-
I have no knowledge of PRIZM, except that it has a huge color display. Does it allow any kind of assembly? I'm going to go check that out, too.
EDIT: Oh wow, ASM and C. I'd have to say the potential is tied with ndless.
-
Yes, it allows Assembly as well as C and in the future, Java.
-
Java
Yes, it allows Assembly as well as C and in the future, Java.
Java? Holy crud! Does it allow fast execution and use of the full display? Also does it openly allow the programs as part of the official OS?
-
"In the future" :P
We're still porting it, so no one knows how fast it will be. However, programs are not supported in the OS. The formats were simply reverse engineered and are similar to the apps from TI-8x calcs.
-
Sounds easier than ndless. Do the programs have the permission to use the entire screen? Also how fast are they, like I said.
-
You can use the entire screen, just like the OS. Actually, our executables have essentially the same privileges as the OS, so they can do whatever is possible with the hardware. The processor is also rather faster than the TI-8x calcs, being [down-]clocked to 58 MHz. If the clock supports it, the processor might be able to reach significantly higher than that.
-
And yet TI hates us for cracking open a way to use their 90Mhz processor? <_<
-
There are reasons to underclock processors. Heat dissipation and power consumption are sometimes more important then raw cycles per second.
-
More important, I think, is being able to cut down on hardware costs by not having to buy peripherals that can handle high clock speeds.
-
That too ;)
-
Yeah, we still need to document which peripherals Casio did include with the proc. After some analysis many hardware ports seem to be either missing or placed somewhere else in ram. Most notably is the usb and the dmac.
-
Note that Prizm games would most likely be slower than TI-Nspire ones, though. The TI-Nspire has about 16 MB of user RAM and the Prizm 61 KB, and the Nspire clock speed can be up to 150 MHz while the Prizm max clock speed is 118 MHz.
I bet we could have nDoom, but the framerate would be about twice lower.
-
DJ, the max Prizm clock speed was based on the processor core being the normal SH3 7705 core used in previous calcs. We have evidence to suggest that it's a SH4A 7780/7781 core, which can handle much higher clock speeds (200 MHz). It's really a matter of how high the frequency multiplier will go if that's indeed the case.
-
Really? I didn't know that. It would be nice if it could.
By the way is it confirmed that it's the same processor as in the FX-9860G?
-
The current processor seems to have been developed exclusively for Casio and is most likely a SH4A without the fpu and many of the peripherals. Also the total amount of ram is 2 MB and for the most part is free. Archive totals as 32 MB, but the OS currently claims 16 MB of that. Because the OS is only 6 MB long, there is the possibility of expanding more archive space in the future. Based off what I have found we can only overclock the proc in software so far until we reach a limit. After that the pll 2 circuit will have to change values, which is set via hardware. My guess is that maybe the careful use of a pencil could change that multiplier.
-
So, basically, what we have is a max of 200Mhz? And in the 84+SE the max is 15Mhz? Freaking fast!
-
So, basically, what we have is a max of 200Mhz? And in the 84+SE the max is 15Mhz? Freaking fast!
don't forget clock cycles. The average z80 instruction is about 7 cycles while most Super H instructions are only 1.
-
The worst exception is division, because that can take something like 96 cycles to do.
-
Does this means that certain things might actually be slower than on a 84+?
-
It's probably faster than on the 84+, because the worst case is the 32 bit division I was referring to, which would be even slower with a z80. Also, the processor runs quite a bit faster than the 84+, so 96 cycles isn't as bad as it sounds.
-
Ah ok good to hear. I was worried that we got our hopes up too much for hardcore gaming X.x
-
The worst exception is division, because that can take something like 96 cycles to do.
Well in that case you need to be careful. Of course speed optimizations can be done by rolling out the for loop. But even better is try to avoid division it in the first place. The best thing to do is bit shifts for the cases of when you are dividing by powers of 2. And the SH4 is just brilliant at bit shifts ;D
-
Ey! What just axe for Prizm, there is Fx-9860GII too! :p
-
Ey! What just axe for Prizm, there is Fx-9860GII too! :p
Well the problem is that most Casio developers are either Prizm or 9860g exclusive. Added to that is the difficulty of porting the compiler over as both calculators have extensive technical differences that would need to be addressed. I for one do not own a 9860g and have no intention of porting any axe like language to it as that is not my area of development.
-
So, do you have already tested some overclocking?
-
From what I remember, they could overclock the calc fine, but the problem is that when we do so, it gets reset, so it's pretty much useless until they figure out how to get around that.
-
Do you know why accesong the vram is so slow? A friend tried to make his own PutDD, and that was very slow (about 25 fps with, and 33 wihtout)
-
Do you know why accesong the vram is so slow? A friend tried to make his own PutDD, and that was very slow (about 25 fps with, and 33 wihtout)
Yes Casio's PutDD uses the DMAC to transfer data from the VRAM to the display ram. The advantage of the DMAC is that is fully autonomous because it is hardware based instead of being repeated cpu instructions. It also can access ram contents in 64 bit chunks while the cpu can only do 32 bits at a time. Also make sure the VRAM is being accessed from the 0xaxxxxxxx space and not the 0x8xxxxxxx space because the latter will result in slowdowns due to continuous cache misses while the former reads directly from memory and ignores the cache.
From what I remember, they could overclock the calc fine, but the problem is that when we do so, it gets reset, so it's pretty much useless until they figure out how to get around that.
Problem with what we did a long time ago was that the function to overclock is very cpu specific. The code we used was for the SH3 while we need to use code designed for the SH4A. Also because apps execute from virtual memory which cannot access hardware addresses, the function has to be written to physical ram and then executed. Based off what Ive seen this can all surprisingly be done from C so overclocking will not require asm. Do note that the required features for compiling this C code can only be done on gcc while the mini-sdk requires asm to be written to overclock.
-
So, doy you think that will be easily?
-
From what I remember, they could overclock the calc fine, but the problem is that when we do so, it gets reset, so it's pretty much useless until they figure out how to get around that.
Yes, the code is very CPU specific because the registers required move around in all of the different CPU models and must be accessed from physical memory. Also, we know how to avoid resets. It's just a matter of setting a flag differently.
-
Do you know why accesong the vram is so slow? A friend tried to make his own PutDD, and that was very slow (about 25 fps with, and 33 wihtout)
Yes Casio's PutDD uses the DMAC to transfer data from the VRAM to the display ram. The advantage of the DMAC is that is fully autonomous because it is hardware based instead of being repeated cpu instructions. It also can access ram contents in 64 bit chunks while the cpu can only do 32 bits at a time. Also make sure the VRAM is being accessed from the 0xaxxxxxxx space and not the 0x8xxxxxxx space because the latter will result in slowdowns due to continuous cache misses while the former reads directly from memory and ignores the cache.
From what I remember, they could overclock the calc fine, but the problem is that when we do so, it gets reset, so it's pretty much useless until they figure out how to get around that.
Problem with what we did a long time ago was that the function to overclock is very cpu specific. The code we used was for the SH3 while we need to use code designed for the SH4A. Also because apps execute from virtual memory which cannot access hardware addresses, the function has to be written to physical ram and then executed. Based off what Ive seen this can all surprisingly be done from C so overclocking will not require asm. Do note that the required features for compiling this C code can only be done on gcc while the mini-sdk requires asm to be written to overclock.
Ah I see then, good news I guess.