Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
Hi!tswilliamson,
Thank you for email.
I am glad to be able to meet an interesting project to extend the possibility of Prizm. Very Happy

Prizm's overclock,
Only multiplier 20x works with the emulator,it is necessary to inspect it with the real Prizm.

Because it is thought that the structure of CPG is identical to SH7724, but part of divider is different,
In Ptune2, the set point of the CPG register fixes a value by a guess based on the actual survey.
I do not know whether it is correct, but I think that it is almost correct.

The CPG register acting effectively in Prizm seems to be eight of the next.

FLLFRQ
FRQCRA
CS0BCR
CS2BCR
CS0WCR
CS2WCR
CS5aBCR
CS5aWCR

I extract the program only for parts changing the clock here.
http://pm.matrix.jp/Ptune2_simple.zip


It is memory speed to influence the frame rate most.
It is effective to make a memory clock the same as a CPU clock.
The frame rate is increased approximately two times when memory clock 2x.
[F4] setting of Ptune2 is recommended to attain a maximum frame rate perfomance.
But electricity consumption increases,it may be sufficient in [F2]~[F3].
I think that all Prizm is safe if increase one phase of wait than the preset value.

If only memory overclock,
The change of these four registers is enough,
FLLFRQ
FRQCRA
CS0WCR
CS2WCR

but these two setting is necessary to the biggest frame rate perfomance.
CS0BCR
CS2BCR

As for these two, it is thought that there is not
CS5aBCR
CS5aWCR
Thanks for responding sentaro!

This is great, much better than what I put together last night. Will this library work in conjunction with someone who already has ptune installed? Or can just save and backup these register values and then restore them on quit?

Also: my emulator actually doesn't get much performance gain by just modifying the bus, about 2-3%. I think a "tight" cpu loop stays inside of the cache and doesn't benefit from improved memory performance as much.

For this reason I would like to have a 150% speed option. I will extract the appropriate register values by setting it to 87 Mhz in PTune first.
tswilliamson wrote:

This is great, much better than what I put together last night. Will this library work in conjunction with someone who already has ptune installed? Or can just save and backup these register values and then restore them on quit?


Thanks,
This library only sets the value of decided CPG register. There is no function except it. and it is not necessary to install Ptune2.
to back up a current clock, to use SaveDataF1().
http://pm.matrix.jp/Ptune2_simple2.zip ( updated )


tswilliamson wrote:

Also: my emulator actually doesn't get much performance gain by just modifying the bus, about 2-3%. I think a "tight" cpu loop stays inside of the cache and doesn't benefit from improved memory performance as much.


CPU speed does not seem to be enough to put up fps.
After trying prizoop.g3a, PLL seems to become x16 without over clock.
I was able to confirm that became 93fps when I carried it out by the next setting in Ptune2.
---------------------------
PLL x16
IFC 1/2 117.96MHz
SFC 1/4 58.98MHz
BFC 1/4 58.98MHz
PFC /16 14.75MHz
Memory Rom Read Wait 5
Memory Ram Read Wait 3
Memory Rom Write Wait 1
---------------------------
(This setting may be near to CG50?)


tswilliamson wrote:

For this reason I would like to have a 150% speed option. I will extract the appropriate register values by setting it to 87 Mhz in PTune first.


It is the best that only PLL makes x24 to attain just 150% of speed.
It is necessary to increase ROM wait by 1 (3->4) to operate stability by all Prizm.
Or put up only the CPU Clock to double become 77fps, too.
---------------------------
PLL x16
IFC 1/2 117.96MHz
SFC 1/4 58.98MHz
BFC 1/8 29.49MHz
PFC /16 14.75MHz
Memory Rom Read Wait 3
Memory Ram Read Wait 2
Memory Rom Write Wait =R
---------------------------
Fantastic, thank you! I really appreciate it Smile Hopefully not only me but the more of the community can put this to great use!
The technique of using the internal ram to achieve a higher framerate is very clever. This is very exciting.
Here's an imgur album of the progress to date:

http://imgur.com/a/P8Qtr

Emulator runs ~80% of games, most at full speed with only 1 frameskip, with a few major ones non-functional or causing complete emulator freezes. I've completed Mario Land 100% and it has 0 issues. On the third level of Final Fantasy Legend on my calculator with 0 issues. The first distro will probably include a list of "safe" games that can be played and others will be at your own risk until I've worked out their problems.

The project has been on github for a while. I've also written a Windows Simulator I'm using for a lot of iteration that implements a bunch of the Prizm SDK calls. It's all at

https://github.com/tswilliamson/prizoop/

I'm using a slightly modified Prizm SDK with the updated fxcg libs. Someone needs to take this over or create an updated distro with new features/Simon's last findings.

ProgrammerNerd - Yes, this method is working GREAT. With no overclock I can get to 60 FPS with full screen draws (if the game isn't using too much CPU, obviously) which isn't remotely possible with naive DMA. The only real caveat is you have to update the screen piecemeal. I'm doing 6 lines at a time, enough to fit in X memory when double buffering. The file of interest in the github is display_directlcd.cpp

Things I want to experiment with:
    * Caching ROM pages to BackgroundVRAM (will fix Zelda), understanding where this gets trashed by the OS
    * Reading ROM directly and avoiding Bfile calls other than for file listing.
    * A deeper dive into the LCD controllers. Still using some syscalls here naively, efficiency could be gained by understanding the direct interface
    * A more full featured Windows/OpenGL Simulator to distribute along with the SDK
    * Library for including data files for g3a's within the g3a themselves to improve app distribution
    * Gameboy Color support, obviously Smile
Announced by tswilliamson here https://www.cemetech.net/forum/viewtopic.php?t=13633 and available for downloads here https://www.cemetech.net/programs/index.php?mode=file&id=1569

I'm really excited how it will work on the new model as well
Thanks again for this work. Found an answer to your max g3a question
amazonka wrote:
turns out my linker was per makefile /common/prizm.ld and was limited to 512kb, so I changed it to 1024 and all works again - I will report back if I verify a higher limit to work.
Good luck
Just wanted to double check if you use windows environment for your prizm development please?
Hey amazonka. Yep I do. Though I've got more of a hybrid set up of the community SDK 0.3 and includes some of the latest libfxcg.

I've also modified it a bit locally (and this is reflected in the makefile in prizoop) to support C++ better for my purposes. The gcc flags in my default project add basic c++ while removing some of the constructs that result in larger, fluffier code like exception handling, thread safety (heh), and rtti.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 2
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement