Author Topic: Prizm goals  (Read 25054 times)

0 Members and 3 Guests are viewing this topic.

Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Re: Prizm goals
« Reply #60 on: October 26, 2011, 01:47:07 pm »
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.

List of stuff I need to do before September:
1. Finish the Emulator of the Casio Prizm (in active development)
2. Finish the the SH3 asm IDE/assembler/linker program (in active development)
3. Create a partial Java virtual machine  for the Prizm (not started)
4. Create Axe for the Prizm with an Axe legacy mode (in planning phase)
5. Develop a large set of C and asm libraries for the Prizm (some progress)
6. Create an emulator of the 83+ for the Prizm (not started)
7. Create a well polished game that showcases the ability of the Casio Prizm (not started)

Offline Eiyeron

  • Urist McEiyolobster
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1430
  • Rating: +130/-10
  • (-_(//));
    • View Profile
    • Rétro-Actif : Rétro/Prog/Blog
Re: Prizm goals
« Reply #61 on: October 26, 2011, 02:29:00 pm »
So, doy you think that will be easily?

Offline AngelFish

  • Is this my custom title?
  • Administrator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3242
  • Rating: +270/-27
  • I'm a Fishbot
    • View Profile
Re: Prizm goals
« Reply #62 on: October 26, 2011, 02:57:35 pm »

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.
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Prizm goals
« Reply #63 on: October 26, 2011, 04:57:10 pm »
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.