z80man
Casio Traitor
LV8 Addict (Next: 1000)
 Offline
Gender: 
Last Login: 04 September, 2012, 19:42:33
Date Registered: 26 December, 2010, 10:02:50
Location: City 17
Posts: 966
Topic starter
Total Post Ratings: +83
|
 |
« Reply #60 on: 26 October, 2011, 19:47:07 » |
0
|
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. |
|
|
|
|
Logged
|
 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) |
|
|
|
Eiyeron
|
|
« Reply #61 on: 26 October, 2011, 20:29:00 » |
0
|
So, doy you think that will be easily?
|
|
|
|
|
Logged
|
|
|
|
AngelFish
This is my custom title
Administrator
LV12 Extreme Poster (Next: 5000)
Offline
Gender:
Last Login: Yesterday at 08:17:37
Date Registered: 15 August, 2010, 09:18:54
Posts: 3190
Total Post Ratings: +220
|
|
« Reply #62 on: 26 October, 2011, 20:57:35 » |
0
|
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. |
|
|
|
|
Logged
|
∂²Ψ -(2m(V(x)-E)Ψ
--- = -------------
∂x² ℏ²Ψ
|
|
|
DJ Omnimaga
Retired Omnimaga founder (Site issues must be PM'ed to Netham45, Eeems, Shmibs, Deep Thought and AngelFish, not me.)
Editor
LV15 Omnimagician (Next: --)
Offline
Gender:
Last Login: Today at 19:10:11
Date Registered: 25 August, 2008, 07:00:21
Location: Québec (Canada)
Posts: 50232
Total Post Ratings: +2615
|
|
« Reply #63 on: 26 October, 2011, 22:57:10 » |
0
|
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. |
|
|
|
|
Logged
|
|
|
|
|
Powered by SMF 1.1.18 |
SMF © 2013, Simple Machines
