Hi!tswilliamson,
Thank you for email.
I am glad to be able to meet an interesting project to extend the possibility of Prizm.

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.

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 )




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?)




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 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

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 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.