Last edited by sentaro21 on 16 Nov 2014 01:56:55 am; edited 1 time in total

Hello, everyone.
I bought Prizm recently.
I am interested in the overclock of calculator.
and made new overclock tool for Prizm.
Cemetech WikiPrizm and "Pover" was helpful very much. Many thanks!

This tool modify CPG(Clock Pulse Generator) and BSC(Bus State Controller).

features:
Your Calculator to the world of over 100MHz!!
memory speed test automatically.
freq/wait settings store and recall with the function key.
Save setting to file (main memory). load data automatically on the next run.

weak points:
As for this tool, test is insufficient.
Unexpected malfunction may happen.
Battery consumptions considerably increase at the over clock.

This tool can modify wait states,
if increment, improved more memory bus frequency.
and more calculator performance.

CPU Clock up to 265-300MHz (safty about 260MHz)
SHW Clock up to 175-200MHz (safty about 160MHz)
bus Clock up to 175-200MHz (safty about 120MHz)
I/O Clock up to - 40MHz (safty about 30MHz)
(The limits are different by individual difference.)

Core clock is effective in a small program.
Overall performance is influenced by bus clock.

This program was based on Pover(by Ashbad).
developed by PrizmSDK 0.3(Ptune2) & CASIO SDK(Ftune2).

Nice !
I'm glad that people are still around with this calc, and this tool looks to be useful, and well displayed !
I'm perheaps a bit fearful to subject my calc at such modifications... :-/
How do you determined the "safty" frequencies ?
By the way, do you plan to release any of your code, that would be great, but, that stay your choice ^^.

Yeah, I saw that, I wasn't on my computer, and I didn't saw any reference to some license or piece of code, I should have downloaded it before asking for that that's right... I'll have a look to that, but as ProgrammerNerd said, such an amount of option is vert attractive !

If not for anything else, this must have been a lot of work, for a platform which not many people seem to care about, anymore. So, congratulations.

I have not tested this on real hardware and I don't think I will. Yes, I think it's dangerous. Yes, I think this shortens the Prizm life time. Yes, it's possible this doesn't work the same way on all the devices. We probably have now found out why things kept crashing above 94.3 MHz: the other clocks were not being adjusted as the core speed went up, and some devices are more tolerant than others, but none can support a difference higher than the one a core speed of 94.3 MHz provides. For some reason though, some can go to 101.5 MHz when USB powered.

It would be nice to see a video of a Prizm working on the profile that's available on F5 by default. Bonus points if someone includes my image viewer decoding a big picture (which would be public so we could compare, pick some public domain thing), plus some storage memory benchmarks (is the bottleneck on the CPU, on the flash chip or on the filesystem?).

Finding a way to measure the temperature of the CPU would be interesting too. Not even talking about internal temperature sensors; any sensor attached to the surface of the CPU would already give interesting results, I think.

All the information contained in this add-in and its source code should definitely go on the wiki in a more digestible way... too bad I don't have the time (I couldn't even do everything I wanted in the wiki before I officially became yet another man-without-time).

Seeing there's a read-me in Japanese, I take that's your mother tongue? Did it help that SuperH is an architecture developed mostly by the Japanese (Hitachi/Renesas)?

Last edited by sentaro21 on 18 Nov 2014 03:49:31 am; edited 1 time in total

Thanks very much for all.
I am a Japanese, but am not so good at English.
I'm sorry if my grammar is wrong and you don't understand the meaning.

Nemhardy wrote:

How do you determined the "safty" frequencies ?

Yes,Some differences appear with individual difference, but I think whether it is all right if do not enter the red zone.
The model of the early SPANSION 100ns flash chip is set in a standard with this tool.
later MACRONIX 90ns chip model is 10%-20% faster than early model.
However, the speed of the RAM does not change very much,
The overall performance makes a little difference.

ProgrammerNerd wrote:

Wow this is very exciting. I am glad to have more control over clock speed. Nemhardy he did include the source code already. It is included in the zip file. The tool look very professional.

Thanks very much for your follow.

I am ashamed....my source code is unripe,
but I would be happy if serve as some kind of references.

gbl08ma wrote:

If not for anything else, this must have been a lot of work, for a platform which not many people seem to care about, anymore. So, congratulations.

Thanks very much.
The opportunity that I would make is to have been slower SH4A fx-9860GII-2 model than a former SH3 model.
There was Prizm in the point that intended to do something about it.

gbl08ma wrote:

I have not tested this on real hardware and I don't think I will. Yes, I think it's dangerous. Yes, I think this shortens the Prizm life time. Yes, it's possible this doesn't work the same way on all the devices. We probably have now found out why things kept crashing above 94.3 MHz: the other clocks were not being adjusted as the core speed went up, and some devices are more tolerant than others, but none can support a difference higher than the one a core speed of 94.3 MHz provides. For some reason though, some can go to 101.5 MHz when USB powered.

Yes,
Lack of the ROM memory access time became the bottleneck of only PLL multiplication over clock.
and the protection of the flash writing is so weak in Prizm.
I made two bricks in a process of making...by access time lack of the ROM.
As a result, this tool works well now.

gbl08ma wrote:

plus some storage memory benchmarks (is the bottleneck on the CPU, on the flash chip or on the filesystem?).

I want to beat the flash ROM if the method that can easily restore is found in the brick.
I cannot but use it now in the zone thought to be the safety.

gbl08ma wrote:

Finding a way to measure the temperature of the CPU would be interesting too. Not even talking about internal temperature sensors; any sensor attached to the surface of the CPU would already give interesting results, I think.

I think so too.
I had touched it during movement over 200MHz, but did not become hot.
Because the consumption battery current was around 80-90mA (add-in operation)
normaly current was around 30mA(add-in operation) 3mA(in idol backlight min) 7mA(in idol backlight 3) 13mA(in idol backlight max)
Even if clock is different, the idol current is about the same.

gbl08ma wrote:

Seeing there's a read-me in Japanese, I take that's your mother tongue? Did it help that SuperH is an architecture developed mostly by the Japanese (Hitachi/Renesas)?

Yes,I'm japanese and mother tongue is japanese.
There is no help of Casio & Renesas on making this tool.
I got all knowledge than WWW network.
Very Very thanks to everyone.

Last edited by sentaro21 on 18 Nov 2014 03:50:00 am; edited 1 time in total

gbl08ma wrote:

plus some storage memory benchmarks (is the bottleneck on the CPU, on the flash chip or on the filesystem?).

This is not a benchmark,
Flash file system write & read simple test.

Code:

For 1->A To 10
Text 1,1,A
StoPict 1
RclPict 1
Next

When an error is given by this program,
It is necessary to lower the I/O clock.
I think that OS area is not broken even if an error is given on this test.
but,in this state, never connected to the USB.
When transfer any file to Prizm, OS destruction may happen.

If errors seem to be frequent,
Possibly the I/O max default setting of 30MHz may not be safety in SPANSION 100ns chip model.

I think that it is the best to return to default clock automatically at the flash write operation.

I want to beat the flash ROM if the method that can easily restore is found in the brick.
I cannot but use it now in the zone thought to be the safety.

Sorry to hear about the bricked Prizms. If you find a way to fix them, please let us know. I think reflashing the flash memory as a clone of other Prizm may be enough, but for that you need access to a flash programmer and a way to connect it to the flash on the Prizm.

sentaro21 wrote:

When transfer any file to Prizm, OS destruction may happen.

What do you mean? Does this happen always or only when overclocking? We have long suspected the USB mode was the cause of some bricks, at least in OS versions before 02.00.

Oh, don't worry about that.
it is my careless mistake to have had bricks.
and I underestimated it when not easily broken.
The cause of the first unit brick, modifies "Pover" and makes over clock at x31, and had access to USB.
The second,did not reboot during experiment that cut down ROM wait.

gbl08ma wrote:

If you find a way to fix them, please let us know. I think reflashing the flash memory as a clone of other Prizm may be enough, but for that you need access to a flash programmer and a way to connect it to the flash on the Prizm.

My reflashing skill is not yet enough,it seems to be very difficult.
I hope that I can repair it only by USB connection.
but,I am thinking about trying to challenge myself to that.

gbl08ma wrote:

What do you mean? Does this happen always or only when overclocking?

I'm sorry that it is incomprehensible.
When an error occurs in BASIC by overclocking,
USB mode is dangerous by overclocking the same setting.
I think OS destruction is not always,if unlucky it may be broken.

gbl08ma wrote:

We have long suspected the USB mode was the cause of some bricks, at least in OS versions before 02.00.

I read in some topics before.
I feel that it is not good that all systems are flash.

Ptune2 is updated version 1.01
Due to the latest software update, following changes are made.

--To solve problems in memtest failure.
If the tolerance of the PLL circuit is bad, when PLL frequency is high (more than 800MHz) it becomes half frequency.
and the memory limit detection is not possible.
in Ptune2 (RAM read test at wait4)
in Ftune2 (RAM read test at wait3)
It was settled by raising it by one step.

--memory red zone ( dangerous range) 3% -> 5%

--default I/O frequency MAX 30MHz -> 24MHz. and default preset I/O frequency is adjusted.
Because there seemed to be the risk in the 30MHz neighborhood in the case of SPANSION 100ns flash, I changed default setting.
I recommend use by the I/O frequency that is near to default frequency.

--renewed some source codes. as a result, file size decreased.

Sorry,
As for this update, there is no change functionally.

If you encountered any problems during the using add-in,please report them.

Thanks for updating this and making sure that it won't damage users' calculators! Out of curiosity, do you have any information on what kinds of speeds this can provide, and how that compares to previous overclocking tools?

Thanks for updating this and making sure that it won't damage users' calculators! Out of curiosity, do you have any information on what kinds of speeds this can provide, and how that compares to previous overclocking tools?

Thanks Kerm

Sorry,there is little information that understood newly,

about the difference with the previous overclocking tools,
previous overclocking did overclock only by changing PLL multiplication.
The limit of the overclock frequency depended how long there was memory margin.
It is the biggest difference this tool widens memory access margin, and to enable further overclock.
As a result, the CPU core can perform over clock than 260MHz and the bus clock rises than 4 times of the default.
And more performance up was done by reviewing register setting about the memory access in reference to fx-9860G of SH3.

However, as a result of having made some bricks, I understood that the I/O clock was related to the flash writing.
for such a reason, it is safety that do not raise the I/O clock as much as possible.

The combination of speed setting can set the miscellaneousness, the frequency setting is possible in resolving power less than 1MHz in changing FLL.
an expedient, the preseted setting(F2-F5) becomes the reference level considered that either individual works.
The performance up in preseted from F4 by F5 realizes performance that is more than double speed than previous overclocking at 94.3MHz

additionally,
I got new fx-9860GII-2 (SH4A) recently.
This model is fast in flash memory access speed (70ns) and feels that it is hard to become the brick than the Prizm.
Because Prizm of the SPANSION 100ns flash model is highest-risk, please be careful enough.

Hi,
Has anyone tested this on a real prizm? If so would you mind sharing what happened?
I have been using Pover to overclock and it only really works up to 94.3 MHz (I think) without bad things happening, so would somebody mind explaining in simple terms how this works?
Thanks!

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.