楽屋裏 - fx-CG50 のチューンアップ - Ptune3

楽 屋 裏
e-Gadget


2017/07/20
更新 2019/08/31

Ptune3 Ver 0.22 が差替えアップデート [2019/08/31]



fx-CG50 を入手したので、早速チューンアップに挑戦!

これまで、fx-CG20 で愛用してきた Ptune2 (sentaro様の作品) の fx-CG50 対応版 Ptune3 を導入しました。Ptune2 はかなりの安全設計なので、引き続き fx-CG50 専用の Ptune3 を試しています。

fx-CG20 はRAMにSRAMを使っていますが、fx-CG50 は SDRAM に変わっています。従って新たに Ptune3 が登場したわけです。


使用例
  • Ptune3 を起動
  • メモリチェック: [OPTN] - [F5] (RAM) と [OPTN] - [F6] (ROM) 実行
  • SDRAM: と Write: の数値 (SDRAM最大クロック と Write 最大クロック) をメモ
  • 最大値設定画面:[SHIFT] - [MENU] でBus CLK をメモしておいたSDRAM最大 か Write が最大付近に設定
  • 最大値設定画面を抜けて設定を保存:[EXIT] でメイン画面に戻り、[SHIFT] - [F1] (SAVE) で設定を保存
  • 設定をストレージメモリにバックアップ保存:[SHIFT] - [AC] (OFF) で一旦電源オフ
  • 電源オン [AC] して、Ptune3 起動
  • PLL を保護された範囲内で最大値に設定
  • [F5] のプリセットを選び、上で設定した値以下で、BFC と PFC を大きめに設定
  • [SHIFT] - [▲] で FLL を変更すると、各クロックを小刻みに調整できる
  • PLL や CPU クロックだけでなく、BFC (メモリバスクロック) や SFC (I/Oクロック) を安全圏内で最大化した方が、全体の動作が最速化できる。場合によっては、PLL を1段落とし、BFC / SFC を大きめに設定し、さらに FLL を上げて BFC / SFC を安全圏内で小刻みに最大化する方法も有効
※ メモリチェックを行った直後は SDRAMアクセスが不安定になる傾向があるので、一旦リスタート (背面ボタン) すると良い。
  • 最大値設定画面は、できるだけ安全を確保する Ptune3 の最大の特徴。値は安全サイドに慎重に設定する必要がある。
  •  [F4] のプリセットはCPUクロックを優先して大きめに設定する。CPUが早くても必ずしも全体の動作が速くならない。全体の動作の高速化には、メモリバスクロック (BFC) や I/O クロック (PFC) の寄与が極めて大きい。これらを大きめに設定する方が良い反面、メモリアクセスの異常は、特にROMアクセスの異常はファームウェアの修復不能なダメージに繋がるので、"メモリチェック" と "最大値設定" を活用して、慎重に設定するのが良い。




Ver 0.22 ベータ版 [2019/08/31 更新]

同じ電池を使った時に fx-9860G シリーズや fx-CG20 と同じ値を示すように、電圧表示値が実際よりも小さめであったのを修正。sその後 電池電圧表示値について C.Basicでの値との誤差を最小にする修正を行い、差替えアップデート。

Ptune3 Ver 0.22 ダウンロード
マニュアル



Ver 0.21 ベータ版 [2019/02/20 更新]

実際のクロックが表示よりも微妙に遅くなっていたが、スペクトラム拡散に原因があることが判明。デフォルトでスペクトラム拡散がONになっているが、これをOFFに切り替えられるようになった。OFFにすると1.6%程度速くなる。
スペクトラム拡散ONで、FLLを1.6%上げても同じ効果なので、顕著なスピードアップにはならなそう。

Prune3 Ver 0.21 ダウンロード

[X2] または [^] キーでスペクトラム拡散を On/Off できます。



Ver 0.20 ベータ版 [2018/08/19 更新]

実際の周波数とのズレを考慮して表示するように修正(セットアップで設定できる)
(暫定補正値 = PLLより算出される内部周波数 * 900 / 914)
Ptune3  Ver 0.20 ダウンロード

sentaro様によるコメント
CG50だけお持ちの場合はさして問題になることも無いのですが、
SH4AのFX機やCG10/20をお持ちの場合は
Ftune2/Ptune2とPtune3で同じクロックにした場合、
CPUベンチマーク結果が違うことに気が付かれた方もいるかもしれません。
(参考リンク)
http://www.casiopeia.net/forum/viewtopic.php?f=25&t=7327

これはCG50のCPUが何かしらの内部仕様の変更があったか、SDRAMアクセスでの何かで、
実際の動作周波数が計算で求められる周波数よりも低い周波数で動作していると思われます。

CG50デフォルトの計算上の動作周波数は
117.96MHz
ですが、
実際にはC
-1.6%ほど低いところの、
116.15MHz(正確ではありません)
くらいで動作しています。

これはFtune2/Ptune2とPtune3でCPUベンチ値を比較すると
FX機/CG20よりも-1.6%ほど低くなるのが分かるかと思います。

今回のアップデートはその周波数誤差を補正して表示できるようにするものです。





Ver 0.10 ベータ版 [2017/09/30 更新]
sentaro様によるコメント

fx-CG50国内発売前に一応、ってことで、0.10にバージョンアップしました。
アイコンをCG50スタイルに変更したのとSDRAMチェックの仕様を少し変更したのみで機能的には0.05と変わるところはありません。(^^;

ということで、現状Ptune3では2倍以上の大幅なオーバークロックは出来ないですが、CG50は基本ベースで高速化されているのであまりPtune3の必要性はないかもしれませんね。

Ptune3 Ver 0.10 ダウンロード


バグや疑問点、何かお気づきの点がありましたらよろしくお願いします。


=== コメントここまで ===

なお管理人の私が所有している個体で、[F5] で設定される CPU コアクロック 210.11Mhz で 2ヶ月使っている限りでは問題ありません。Ver 0.10 も機能面で変わりないので [F5] で問題ないと思います。



Ver 0.05 アルファ版 [2017/07/20 公開]
sentaro様によるコメント

αテスト版ですが、Ptune3 ver0.05です。(^^;
Ptune3 Ver 0.05 ダウンロード


一番の注意点としては、SDRAMのメモリチェックはチェック後にシステムエラーを起こすことが少々あるので、SDRAMのメモリチェックをした後はリセット推奨です。
それ以外は以前のPtune2と同様にUSB接続で使用しないこと、ぐらいでしょうか。

現状ではCG20のようにメモリクロックがどんどん上げられないので、デフォルトからPLL倍率を上げていくクロックアップが全体の速度向上には効果的です。
この場合はSDRAMのメモリ動作限界で全体の動作限界が決まってしまうのでCG20よりCPUクロックを高くすることが出来ません。
CPUクロックだけを上げるには[F4]を押してPLLをx32にして[SHIFT]+[UP]を押して最上段のFLLで上げていくことになります。(PLLは32倍で制限されているため)
この場合はメモリ限界よりもCPUクロック限界が先にくるので、これでCPUの動作限界が分かります。
私の個体では280MHz前後までいきましたが、速度的にはメモリクロックがあまり上がらないためにPLLを上げていく方が全体パフォーマンス的にはかなり有利になります。
現バージョンの0.05ではデフォルトからPLLを28倍くらいまで上げて1.8倍速ぐらいが安定限界というところです。

fx-CG20はPtune3で約3倍速まで引き上げられますが、fx-CG50はデフォルトで1.5倍~2倍、それがさらに1.8倍まで上がるとすればCG20の最高速度並にはなりそうです。
そしてその状態でも消費電力がCG20比で約半分というところなのでなかなか良いですね。(^^)

=====





αバージョンなので、なんと言っても完全に自分の責任で使うもので、今はこわごわ触っています。Ptune3 に関する話題をこのエントリーにまとめるため、楽屋裏ネタとしてこの記事を投稿しています。

早速、作者のsentaro様への質問をコメント欄にアップしました。

[2019/01/31 追記] 
fx-CG50 を2台持っていますが、いずれも 300MHz までチューンアップできました。単に CPUクロックが 300MHzといっても、他の設定に応じて実際のプログラム処理速度は大きく変わりますので、CPUクロックのみで話をするのはあまり意味はありません。
以下のコメント欄にあるように sentaro様のアドバイスを頂きながら、2018年8月末に 自分なりの安全かつ最速設定を見つけ、その後ほぼ5ヶ月使用使って問題ないので、運が良ければここまでチューンアップできます。ちなみにsentaro様所有のfx-CG50では300MHzには至らないようです。無理はしないでください。






応援クリックをお願いします。励みになるので...
にほんブログ村 IT技術ブログ 開発言語へ


 


keywords: プログラム関数電卓、fx-CG50、クロックアップ、Ptune3

リンク集 | ブログ内マップ
関連記事

テーマ : プログラム関数電卓
ジャンル : コンピュータ

コメントの投稿

非公開コメント

No title

管理人様、FX/CGオーバークロッカーの皆様、こんにちは!

>fx-9860G はSlim も含めて GII よりはサクサク動くので、心地よいです。

SH3とOSが上手く合っているかという感じでしょうか。(^^)


>新品はやはり気持ち良いですね!
>ますます普段使いしたくなっています...というか既に普段使いです。
>で、過去のプログラム資産をそのまま使える OS2.00 にしています。

Slimのように外装がポイントになる電卓はやはり新品の価値は高いですね。(^^)
OSは周りとの互換性を考えればOS2.00の方が便利でしょうか。


>G336-71
>A120489
>7Q0510 R/H
>ここから、どうやって製造月を割り出すのでしたっけ?

https://bible.planet-casio.com/teamfx/product.txt
teamfx氏のプロダクトコード解析文書によれば、
最後が製造年月日のようで、
2007年5月10日製というところでしょうか。

ちなみに私のSlimでは
G366-71
A128147
7Q0528 R/H
なので、
管理人様のと同じ製造月ですね。(^^)

Re: Re^12: Ftune/Ptuneシリーズ一挙更新です。

sentaro様、FX/CGオーバークロッカーの皆様、

管理人のやすです。


> ホッと一安心です。(^^)
> 1.10から1.20への違いはバージョン表記だけなので油断してました。(^^;

fx-9860G はSlim も含めて GII よりはサクサク動くので、心地よいです。


> おお!新品Slimの無事到着おめでとうございます!
> キズひとつ無いというのはなかなか良いですね。(^^)

新品はやはり気持ち良いですね!
ますます普段使いしたくなっています...というか既に普段使いです。
で、過去のプログラム資産をそのまま使える OS2.00 にしています。

OS1.10 ~ OS1.11 だと MOD とか RanInt# が無いので書き換えなければならず、まぁ書換できますが、スピードよりも機能重視を選択しました。


> 今ではSlimの発売当時から10年以上経ってる計算ですが、シリアルNoからいつの製造かわかりますでしょうか?

そうそう、これをお聞きしたかったのです。どう見るのか忘れてしまっています。
筐体裏には、3箇所の刻印があります。

G336-71
A120489
7Q0510 R/H

ここから、どうやって製造月を割り出すのでしたっけ?

Re^12: Ftune/Ptuneシリーズ一挙更新です。

管理人様、FX/CGオーバークロッカーの皆様、こんにちは!

>無事 1.20 になっておりました。

ホッと一安心です。(^^)
1.10から1.20への違いはバージョン表記だけなので油断してました。(^^;


>ところで、未開封(古い)新品のSlimが届きましたが、当然ながらキズひとつない...あったら問題ですけど。

おお!新品Slimの無事到着おめでとうございます!
キズひとつ無いというのはなかなか良いですね。(^^)
今ではSlimの発売当時から10年以上経ってる計算ですが、シリアルNoからいつの製造かわかりますでしょうか?


>fx-9860GII SD はセミハードケースに入れて持ち歩いていて、ひっかっききず1つ付かないので、Slim用のケースを探したら良さそうなのがあったので入手したら、ピッタリサイズでした。普段使いにするには必須です。

>Slimの勧めを大幅改訂して、ケースの紹介も追加しました。
https://egadget.blog.fc2.com/blog-entry-708.html

お!これまたピッタリで良い感じですね。(^^)

Re^12: Ftune/Ptuneシリーズ一挙更新です。

sentaro様、FX/CGオーバークロッカーの皆様、

管理人のやすです。

> あ゛…思いっきり1.10のままでした。(^^;
> ありがとうございます!
>
> ってことで、再アップしております。
>
> for fx-9860G/GII/Slim (SH3)
> https://pm.matrix.jp/Ftune_120.zip

無事 1.20 になっておりました。

ありがとうございまず。

ところで、未開封(古い)新品のSlimが届きましたが、当然ながらキズひとつない...あったら問題ですけど。

fx-9860GII SD はセミハードケースに入れて持ち歩いていて、ひっかっききず1つ付かないので、Slim用のケースを探したら良さそうなのがあったので入手したら、ピッタリサイズでした。普段使いにするには必須です。

Slimの勧めを大幅改訂して、ケースの紹介も追加しました。
https://egadget.blog.fc2.com/blog-entry-708.html


Re^11: Ftune/Ptuneシリーズ一挙更新です。

管理人様、FX/CGオーバークロッカーの皆様、こんにちは!

>Ftune (SH3) Ver 1.20 ですが、System の Verion でバージョン表示が 1.10 のままになっています。
>ご確認ください。

あ゛…思いっきり1.10のままでした。(^^;
ありがとうございます!

ってことで、再アップしております。

for fx-9860G/GII/Slim (SH3)
https://pm.matrix.jp/Ftune_120.zip

Re^10: Ftune/Ptuneシリーズ一挙更新です。

sentaro様、FX/CGオーバークロッカーの皆様、

管理人のやすです。

Ftune (SH3) Ver 1.20 ですが、System の Verion でバージョン表示が 1.10 のままになっています。

ご確認ください。

Re^9: Ftune/Ptuneシリーズ一挙更新です。

管理人様、FX/CGオーバークロッカーの皆様、こんにちは!

>あ、そうでした。
>間違いです。

実際に、9860Gは補正無しだと0.5Vくらい低く出るので、
ひょっとして更新ミスかと焦ってたので一安心です。(^^)

Re: Re^7: Ftune/Ptuneシリーズ一挙更新です。

sentaro様、FX/CGオーバークロッカーの皆様、

管理人のやすです。

> もしかして、0.5Vの違いじゃなく0.05Vだったのでしょうか?(^^;

あ、そうでした。
間違いです。

Re^7: Ftune/Ptuneシリーズ一挙更新です。

管理人様、FX/CGオーバークロッカーの皆様、こんにちは!

>・Ftune2 の電圧値:4.78v
>・C.Basic Ver の電圧値:4.8v
>・BattryStatus:4.83v

>5回ほど調べて、絶対値は0.5v の範囲で変動、しかし上の3つの順序の傾向は同じです。
>9860GII SD のOSは 2.09 です。

もしかして、0.5Vの違いじゃなく0.05Vだったのでしょうか?(^^;

電圧を測る時点での消費電流の大きさで多少の変動が起きるので、
誤差約1%ということで、そういう感じの差ではないかと思われます。(^^;

オーバークロックすると電圧が若干下がるのも同じ原因ですね。

Re: Re^5: Ftune/Ptuneシリーズ一挙更新です。

sentaro様、FX/CGオーバークロッカーの皆様、

管理人のやすです。


> あとは、実際の電池電圧と合ってるかどうかですね。

あとで調べておきます。


> >電圧は、どこか別のところに表示されるのでしょうか?
>
> Ftune2ではセットアップ(一番下)でバージョン表示と電圧表示が選択できるようになっています。(^^)

なるほど...ということて電圧確認できました。


で、
・Ftune2 の電圧値:4.78v
・C.Basic Ver の電圧値:4.8v
・BattryStatus:4.83v

5回ほど調べて、絶対値は0.5v の範囲で変動、しかし上の3つの順序の傾向は同じです。
9860GII SD のOSは 2.09 です。


Re^5: Ftune/Ptuneシリーズ一挙更新です。

管理人様、FX/CGオーバークロッカーの皆様、こんにちは!

>一気にやろうと思わないと、とても厄介でやる気にならないですよね。
>お疲れ様です。

機種によってはバネが強くて電池の出し入れが大変でした。
CG10/20とか結構きついですね。(^^;


>ドンピシャ一致しました!

ありがとうございます!
あとは、実際の電池電圧と合ってるかどうかですね。


>電圧は、どこか別のところに表示されるのでしょうか?

Ftune2ではセットアップ(一番下)でバージョン表示と電圧表示が選択できるようになっています。(^^)


>x-9860G でもテストしてみたところ、Ftune v1.20 が C.Basic よりも0.4 ~ 0.5V 程度低く表示されます。

こちらでのテストでは、
v1.05とv2.01で違いは無かったのですが、あり???

OSバージョンはどうなってますでしょうか?

Re^4: Ftune/Ptuneシリーズ一挙更新です。

sentaro様、FX/CGオーバークロッカーの皆様、

管理人のやすです。

fx-9860G でもテストしてみたところ、Ftune v1.20 が C.Basic よりも0.4 ~ 0.5V 程度低く表示されます。

Re: Re:Re: Ftune/Ptuneシリーズ一挙更新です。

sentaro様、FX/CGオーバークロッカーの皆様、

管理人のやすです。


> 今回、
> 新品のアルカリ電池と充電後半分くらい使ったあとのエネループで計測したのですが、
>
> 9860G
> Slim
> 9860GII(SH3)
> 9860GII-SD(SH3)
> 9860GII(SH4A)
> 9860GII-SD(SH4A)
> 35+E(SH4A)
> 35+E II(SH4A)
> CG10
> CG20
> CG50
> Graph 90+E
>
> 全部で15台くらいの電卓の電池の入れ替えはかなり大変でした。(^^;

一気にやろうと思わないと、とても厄介でやる気にならないですよね。
お疲れ様です。


Slim ですが、完璧です。
- Ftune 1.20: 2.42v
- C.Basic Ver: 2.42v
- C.Basic BatteryStatus: 2.42v

ドンピシャ一致しました!


なお、Ftune2 Ver 1.20 を fx-9860GII SD にインストールしたところ、電圧表示でなくてバージョン表示されています。[SHIFT][MENU]のバージョン表示にも電圧表示がありません。

電圧は、どこか別のところに表示されるのでしょうか?

Re:Re: Ftune/Ptuneシリーズ一挙更新です。

管理人様、FX/CGオーバークロッカーの皆様、こんにちは!

>お疲れ様です、記事に反映させました。

早速にありがとうございます!(^^)


>今日、CG20, CG50 で C.Basic との誤差が±5% 以上あったので、アマループをフル充電して再度テストしたのですが、誤差が縮まりませんでした....と報告しようと思ったら、既に調整バージョンがアップされていました。
>いつもながら仕事が速いですね!

どもです!(^^;

今回、
新品のアルカリ電池と充電後半分くらい使ったあとのエネループで計測したのですが、

9860G
Slim
9860GII(SH3)
9860GII-SD(SH3)
9860GII(SH4A)
9860GII-SD(SH4A)
35+E(SH4A)
35+E II(SH4A)
CG10
CG20
CG50
Graph 90+E

全部で15台くらいの電卓の電池の入れ替えはかなり大変でした。(^^;

FXのSH4A機とCG20の電圧値が比較的正確だったのでそれが基準になっています。
元祖9860GとCG50では約10%ほど低かったので補正しました。
Ftune2での読み出し値がC.Basicと2%ほどずれていたのも修正しました。

Slimに関しては補正値が結構大きいので、
誤差の範囲に収まっているかどうかは管理人様頼みです。(^^;

Re: Ftune/Ptuneシリーズ一挙更新です。

sentaro様、FX/CGオーバークロッカーの皆様、


管理人のやすです。


> C.Basicの電圧表示アップデートに伴い、表示値が微妙にずれたので、
> すべてC.Basicと同じ電圧値となるべく合わせるために更新です。(^^)
>
> for fx-9860G/GII/Slim (SH3)
> https://pm.matrix.jp/Ftune_120.zip
>
> for fx-9860GII (SH4A)
> https://pm.matrix.jp/Ftune2_120.zip
>
> for Graph 35+E II (SH4A)
> https://pm.matrix.jp/Ftune3_220.zip
>
> for fx-CG50 / Graph 90+E
> https://pm.matrix.jp/Ptune3_022.zip
>
> Ptune2は変更なしです。

お疲れ様です、記事に反映させました。



> 全機種で誤差±3%を目指していますが、個体差でずれる場合もあります。(^^;

今日、CG20, CG50 で C.Basic との誤差が±5% 以上あったので、アマループをフル充電して再度テストしたのですが、誤差が縮まりませんでした....と報告しようと思ったら、既に調整バージョンがアップされていました。

いつもながら仕事が速いですね!

Ftune/Ptuneシリーズ一挙更新です。

管理人様、FX/CGオーバークロッカーの皆様、こんにちは!

C.Basicの電圧表示アップデートに伴い、表示値が微妙にずれたので、
すべてC.Basicと同じ電圧値となるべく合わせるために更新です。(^^)

for fx-9860G/GII/Slim (SH3)
https://pm.matrix.jp/Ftune_120.zip

for fx-9860GII (SH4A)
https://pm.matrix.jp/Ftune2_120.zip

for Graph 35+E II (SH4A)
https://pm.matrix.jp/Ftune3_220.zip

for fx-CG50 / Graph 90+E
https://pm.matrix.jp/Ptune3_022.zip

Ptune2は変更なしです。


全機種で誤差±3%を目指していますが、個体差でずれる場合もあります。(^^;

Ptune3 ver0.22 (電圧表示値修正版)

管理人様、fx-CG50オーバークロッカーの皆様、こんにちは!

C.Basic for FXで電圧表示が出来るようになったことで、
電卓間の表示値の相違を出来るだけ無くすために
若干低めの表示だったCG50の値を修正しました。

Ptune3 ver0.22 (電圧表示値修正版)
http://pm.matrix.jp/Ptune3_022.zip
電圧表示値を10%上方修正しました。

Re:Re: Re:Re: Ptune3 ver0.21 (CG50のスペクトラム拡散に対応しました。)

管理人様、fx-CG50オーバークロッカーの皆様、こんにちは!

管理人様、
>CG50を検索キーワードで来られる方は、第二位です。
>なので、CG50ユーザーの閲覧は確実に増えていることになります。
>そして、Ptune3とC.Basic記事の閲覧も増加傾向です。

今の所、米AmazonのCG50は在庫切れで価格が急上昇してますが、
国内ではひと頃よりは入手しやすい価格になって
CG50ユーザーが増えていることは嬉しい傾向ですね。(^^)


>ちなみに第一位は fx-5800P で、CcLinker記事への閲覧が増えています。
>一方で、当ブログのメインテーマである純正Casio Basicの記事へのアクセスが圧倒的に多いわけですが、CcLinkerで転送できるファイルをダウンロードできるように徐々に拡充しています。もっと増やさないとダメだな、と思っています。

fx-5800P、強いですね!
fx-5800Pのプログラムがダウンロードできるとかちょっと前まではあり得ない話だったのに、CcLinkerの存在はすごく大きいと思います。(^^)
後継機種がいつ出るのか出ないのかとヤキモキする状態が続いていますが、
CcLinkerがあれば、fx-5800Pが続いてくれたらそのままでも構わないんじゃないかって思ったりもします。(^^;


>このあたりは、記事本文に追加したほうが良いかも知れませんね!

そうですね。
スペクトラム拡散はあまりいじくるものではないと思うので、
CG50では有効がデフォルトという方向でいいと思います。(^^)


>ま、無理せずにゆるゆると試してみようと思います。

管理人様の個体は従来の周波数表示でどちらも最大310MHzで動作しているということですから、
305MHzで安定していたならスペクトラム拡散状態でも300MHz動作が大丈夫そうですね。
とはいえ、ぎりぎりの状態に近づくのでここはあまり無理をしない方が良さそうです。(^^)

Re: Re:Re: Ptune3 ver0.21 (CG50のスペクトラム拡散に対応しました。)

sentaro様、fx-CG50オーバークロッカーの皆様


> これは最近新しくCG50ユーザーになられた方が増えたという感じでしょうか。(^^)

CG50を検索キーワードで来られる方は、第二位です。
なので、CG50ユーザーの閲覧は確実に増えていることになります。
そして、Ptune3とC.Basic記事の閲覧も増加傾向です。

ちなみに第一位は fx-5800P で、CcLinker記事への閲覧が増えています。
一方で、当ブログのメインテーマである純正Casio Basicの記事へのアクセスが圧倒的に多いわけですが、CcLinkerで転送できるファイルをダウンロードできるように徐々に拡充しています。もっと増やさないとダメだな、と思っています。


> 電卓は動作周波数も低く省電力なのでそのあたりはあまり影響は無かったとはいえ、
> CG50で100MHz超えになったので、各国のEMI規格を通過するには無視できないレベルになってきたのかもしれません。

電卓動作を確実にするためよりもEMI対策というのは、現実的ですね。


> >300MHz ギリギリのところで、実動作への影響として注意点は何かありますでしょうか?
>
> 従来の表示(Actual FreqがOffの場合)で300MHzだった場合、
> CG50のデフォルト(スペクトラム拡散有効)での実際の動作周波数は-1.6%で295.4MHzになります。
> 逆に実動周波数が300MHzの場合は従来のPLL表示値では304.67MHzになります。
>
> ということで、300MHz近辺では5MHzほど変化することになりますので、
> スペクトラム拡散を有効から無効にした場合は5MHzほど動作周波数が上がってしまい、
> 300MHzぎりぎりで動作していた場合は、305MHzに上がってしまうことで
> フリーズや異常動作が引き起こされる可能性があります。
>
> これを回避するには、
> CG50ではスペクトラム拡散の有効/無効をいじらないことですが、
> デフォルトで有効なので、ここは有効固定でいじらない方が良さそうです。

ジックリと確認しようと思います。


> ということで、
> CG50での正しいオーバークロック方法としては、
> スペクトラム拡散は有効のまま、
> Actual FreqをOnにして、
> 実働周波数でオーバークロックしていくのが正攻法かと考えます。

このあたりは、記事本文に追加したほうが良いかも知れませんね!


> 実働周波数で300MHz超えたら名実ともに300MHz超えとなります。(^^)

ま、無理せずにゆるゆると試してみようと思います。


Re:Re: Ptune3 ver0.21 (CG50のスペクトラム拡散に対応しました。)

管理人様、fx-CG50オーバークロッカーの皆様、こんにちは!

管理人様、
>ここ一ヶ月の傾向で、FtuneやPtuneの記事へのアクセスがいつもよりも多い傾向です。

ぉお!?
これは最近新しくCG50ユーザーになられた方が増えたという感じでしょうか。(^^)


>記事での対応は済ませておりますが、手元でのファイルの差し替えをしておきます。

いつも素早い対応してくださって感謝です。m(_ _)m


>スペクトラム拡散は、PLLの周波数関連ですよね?

はい!
電卓は動作周波数も低く省電力なのでそのあたりはあまり影響は無かったとはいえ、
CG50で100MHz超えになったので、各国のEMI規格を通過するには無視できないレベルになってきたのかもしれません。


>私の2台のCG50 は幸運にも 300MHz 超えが可能ですが、今回のスペクトラム拡散対応は、表示だけの変更ですか?

FX時代は300MHzの壁が結構高かったですけど、
CG50になって2台ともというのがすごいですよね!(^^)

で、今回のスペクトラム拡散対応は、
それが有効になっているかどうかの表示はもちろん、
有効/無効の切り替えもできます。
切り替えた場合、セットアップでActual FreqがOnの場合は実働周波数を表示しますので周波数が変化します。

スペクトラム拡散が有効の場合、緑色で
Spread Spectrum Freq
と表示されます。


>300MHz ギリギリのところで、実動作への影響として注意点は何かありますでしょうか?

従来の表示(Actual FreqがOffの場合)で300MHzだった場合、
CG50のデフォルト(スペクトラム拡散有効)での実際の動作周波数は-1.6%で295.4MHzになります。
逆に実動周波数が300MHzの場合は従来のPLL表示値では304.67MHzになります。

ということで、300MHz近辺では5MHzほど変化することになりますので、
スペクトラム拡散を有効から無効にした場合は5MHzほど動作周波数が上がってしまい、
300MHzぎりぎりで動作していた場合は、305MHzに上がってしまうことで
フリーズや異常動作が引き起こされる可能性があります。

これを回避するには、
CG50ではスペクトラム拡散の有効/無効をいじらないことですが、
デフォルトで有効なので、ここは有効固定でいじらない方が良さそうです。

ということで、
CG50での正しいオーバークロック方法としては、
スペクトラム拡散は有効のまま、
Actual FreqをOnにして、
実働周波数でオーバークロックしていくのが正攻法かと考えます。

実働周波数で300MHz超えたら名実ともに300MHz超えとなります。(^^)

Re: Ptune3 ver0.21 (CG50のスペクトラム拡散に対応しました。)

sentaro様、fx-CG50オーバークロッカーの皆様

管理人のやすです。

ここ一ヶ月の傾向で、FtuneやPtuneの記事へのアクセスがいつもよりも多い傾向です。


> (2019.2.21追記)
> 起動時のスペクトラム拡散のチェックに一部不具合がありましたので、
> 修正後、再アップしております。(^^;

記事での対応は済ませておりますが、手元でのファイルの差し替えをしておきます。

スペクトラム拡散は、PLLの周波数関連ですよね?

私の2台のCG50 は幸運にも 300MHz 超えが可能ですが、今回のスペクトラム拡散対応は、表示だけの変更ですか?

300MHz ギリギリのところで、実動作への影響として注意点は何かありますでしょうか?

Ptune3 ver0.21 (CG50のスペクトラム拡散に対応しました。)

管理人様、fx-CG50オーバークロッカーの皆様、こんにちは!

fx-CG50で表示クロックよりも実際のクロックが微妙に遅くなっていた原因が、
スペクトラム拡散ということで、はっきりしましたので、
そのオンオフが出来るバージョンをアップデートしました。(^^)
CG50ではデフォルトではオンですが、オフにすることによりわずかですが1.6%スピードアップします。
スペクトラム拡散がオンのまま、FLLを1.6%上げても同じ効果なので、あまり意味がない機能とも言えます。(^^;

Ptune3 ver0.21 (CG50のスペクトラム拡散に対応しました。)
http://pm.matrix.jp/Ptune3_021.zip
スペクトラム拡散機能のOn/Off機能を追加しました。
[X^2]もしくは[^]キーでOn/Offが切り替わります。

(2019.2.21追記)
起動時のスペクトラム拡散のチェックに一部不具合がありましたので、
修正後、再アップしております。(^^;

Re^15: 310 MHz いきましたが...+ 補足です

管理人様、Ptune3ユーザーの皆様、こんにちは!

>少し前のコメントで、あり得ないFRQCR値と言われていたその意味がやっと分かりました。また、私の実験内容に不正確さがあったかもしれず、それで話が見えないところもあったようです。それも全部吸収してのコメント、大変ありがとうございます。

あ、いえいえ、こちらこそです。
C.Basic開発ではCG50はノーマルクロック固定運用だったので、
しばらくPtune3のオーバークロックから遠ざかっていたこともあって、
今回、各設定値の意味を改めて確認することが出来ました。
ありがとうございます。(^^)


>[追記]
>さらに、メイン画面での設定変更の結果、同じ設定に見えても、クロックを上げた時と下げたときで、ROMやSDRAMアクセスのウェイトの(自動)最適化の結果が異なることがあり、そのため実際に実行動作が変わるという補足、大変ありがとうございます。スッキリと理解できました。おかげで、さらに安心感が増しました。

ウエイトの自動増減というのは便利な反面、混乱のもとになってしまうことも今回分かりました。(^^;
基本的には安全な範囲に各設定値が自動で設定されるのがPtune2/3の特徴なので、
普通に使う分には自動増減で問題ないと思います。(^^)


>以前sentaro様がお書きになっていたように、複数のプログラムへの Ptune3適用事例を紹介できるようになったと思います。

最高パフォーマンスを引き出すには、
CG20のときは最高周波数に上げるだけだったのが、
CG50ではCPU優先、バス優先と上手く使い分ける必要が出てきましたね。(^^)



>・[F5] 設定: [F5]プリセットから PutDisp優先で、
> - 1号機は CPU 210.53 MHz (PutDisp 167.18fps)、
> - 2号機は CPU 196MHz (PutDisp 156.03fps)

ハード的にはこのメモリクロックを上げた設定が一番ぎりぎりな感じがするので、一瞬でも不安定さを感じたら一段下げてください。


>さて、チョット欲を出して、もうチョット速くすることも考えてみたいわけですが、今回その実態を教えて頂いた BC02やCB34でウェイトを変更するのは、チョット怖い感じがしています。しかし、現在の値を変更したらどうなるのか興味はあります。

ベンチマークに効いてくる操作としては、
一番上のIWWの値を小さくするとすべての動作に効果があります。


>特に、CPU優先 300MHz 設定の BC02でROMアクセスのウェイトを現在の 2 から 1 に下げると、文鎮化の危険性を感じます

BC0はROMアクセスのウエイト減なので
管理人様が心配されている文鎮化の可能性が出てきますが、
ここは危険領域になる前でストッパーがかかってますので
どんだけいじくっても大丈夫です。(^^)

ちなみに300MHzのときはバスクロック75MHz付近なのでウエイト1にまで下げられますが、
[F5]オーバークロックでは75MHzを超えるので2に自動的に上がります。
CG50におけるバス75MHzというのはかなり安全な周波数で余裕の動作範囲です。


>また当方の1号機は、SDRAMクロック上限が205MHz程度、一方2号機は 99MHzとかなり低くなっています。特に2号機では BC34でウェイトを1にして最悪リスタートするだけで終われば良いのですが...

BC34の左側
RAM:CS3
でSDRAMのウエイトが減らせますが、ここはすべて0まで下げられます。
今の所、不具合が起きたことは無いですが、1程度なら余裕と思います。(^^)
IWW以外は効果がほぼ出ないので、IWWのみ下げるだけでもいいと思います。


>これらウェイト値の変更のリスクは、どういう感じで考えると良いのでしょうか?

BC3に関しては実際に限界まで下げても動作異常が起きる可能性は低いです。

SDRAMウエイト設定は、
[F6]WC34のCS3WCRの方もありますが、
ここの数値を下げすぎると目に見える異常現象が出てきます。(^^;
ここのパラメータ操作は制限が何もありませんので完全な自己責任部分です。(^^;

TRP:2(下げても速度アップ効果ほとんど無し)
TRCD:2(1にすると効果ある場合もあり。)
A3CL:2(いわゆるCL値 3に増やしてもメモリ限界は上がらない、)
TRWL:2(下げても速度アップ効果ほとんど無し)
TRC:4(下げても速度アップ効果ほとんど無し。)

すべてのパラメータを同時に減らしていくと画面アクセス異常が起きます。(^^;
ここのCS3WCRで効果的といえるのはTRCDを1にすることぐらいなのですが、
CS3BCRの方でウエイト削減しているとほとんど効果が出ないので、
ここは基本的にすべてデフォルト値でいいと思います。(^^)

Re^14: 310 MHz いきましたが...+ 補足です

sentaro様、Ptune3ユーザーの皆様

管理人のやすです。

[追記あり]

sentaro様、

少し前のコメントで、あり得ないFRQCR値と言われていたその意味がやっと分かりました。また、私の実験内容に不正確さがあったかもしれず、それで話が見えないところもあったようです。それも全部吸収してのコメント、大変ありがとうございます。

[追記]
さらに、メイン画面での設定変更の結果、同じ設定に見えても、クロックを上げた時と下げたときで、ROMやSDRAMアクセスのウェイトの(自動)最適化の結果が異なることがあり、そのため実際に実行動作が変わるという補足、大変ありがとうございます。スッキリと理解できました。おかげで、さらに安心感が増しました。


当方の2台のfx-CG50で、速めの動作速度の設定ができていて、それが安全園と分かり、一安心です。

sentaro様のサポートのおかげで、1号機、2号機ともに最大310MHz動作、300MHzの安全設定ができるようになりました。ありがとうございます。

そして、[F4] のCPUクロック優先設定、[F5]のPutDisp優先設定どちらがプログラム実行速度を速くするのは、プログラムに応じて変わるということも、実際に経験できました。ライフゲームのようにグラフィックス描画よりも計算負担の方が大きいものは、CPUクロックが上げられる場合は、CPUクロック優先設定が有利になることもよく分かりました。

以前sentaro様がお書きになっていたように、複数のプログラムへの Ptune3適用事例を紹介できるようになったと思います。

なお、当方の Ptune3の適用状況は以下のようになりました。、

・Setup - Bus CLKは、98.46Hz (デフォルト)
 - 1号機は SDRAM 105MHz なので余裕
 - 2号機は SDRAM 99MHzなので、ギリギリ?

・Setup - Shw CLKは 160Mhz (200MHzくらいまでは安全圏)

・Setup それ以外の設定は全てデフォルト

・[F4] 設定:1号機、2号機ともに、[F4]プリセットからCPUクロック優先で 幸運なことに 300MHz の安全設定

・[F5] 設定: [F5]プリセットから PutDisp優先で、
 - 1号機は CPU 210.53 MHz (PutDisp 167.18fps)、
 - 2号機は CPU 196MHz (PutDisp 156.03fps)



さて、チョット欲を出して、もうチョット速くすることも考えてみたいわけですが、今回その実態を教えて頂いた BC02やCB34でウェイトを変更するのは、チョット怖い感じがしています。しかし、現在の値を変更したらどうなるのか興味はあります。

特に、CPU優先 300MHz 設定の BC02でROMアクセスのウェイトを現在の 2 から 1 に下げると、文鎮化の危険性を感じます

また当方の1号機は、SDRAMクロック上限が205MHz程度、一方2号機は 99MHzとかなり低くなっています。特に2号機では BC34でウェイトを1にして最悪リスタートするだけで終われば良いのですが...

これらウェイト値の変更のリスクは、どういう感じで考えると良いのでしょうか?

補足です。

管理人様、Ptune3ユーザーの皆様、こんにちは!

Ptune2/3のPLL/FLL操作で、メモリアクセスタイミングは自動で変化しますが、
セットアップ項目のうち、
Wait Auto - : on
RAM WW Auto : off
ROM IWW At- : on
この項目がメモリアクセスタイミングに効いてきます。

Wait Auto -
ROM IWW At-
はPLLやFLLを下げた時、メモリアクセスのウエイトを自動で減らすかどうかの設定です。
どちらもOnになっているのでPLL/FLLを減らす操作をした場合はメモリウエイトが変化する可能性があります。
PLLやFLLを上げるときのウエイト増加はデフォルトで自動調整になります。

RAM WW Auto
は従来Ptune2ではデフォルトでonでしたがPtune3ではoffになっています。
これはCG20で設定している箇所がCG50とは互換性がないのでonにしても効果はありません。(^^;


ということで、
該当周波数付近でPLLまたはFLLを一旦下げて上げるという操作をすることで
メモリアクセスが最適化されることになりますが、
Ptune2よりは若干甘めの設定になっております。(^^)

Re^13: 310 MHz いきましたが...

管理人様、Ptune3ユーザーの皆様、こんにちは!

管理人様、
>そこで、以下の方法だと私の1号機と2号機両方でFRQCR:1F001203になったので、お試し頂けませんか?

はい。
[F3]から始めると
FRQCR:1F001203
になります。(^^)

Ptune3における、
[F1]から[F5]におけるデフォルトのFRQCR設定値は次のとおりです。
-----------------
[F1]:0F011112
[F2]:0F102202
[F3]:19102202
[F4]:1F001203
[F5]:19001102
-----------------


CG50のデフォルト[F1]では
右から2桁目と5桁目が1になりますが。
ここが[F2]-[F5]との大きな違いです。
ただ、ここが違っていても動作上は何も変わりません。(^^;
[F1]:0F001102
でも全く同じです。

つまりPtune2/3で変化するFRQCRの範囲は16進8桁のうち、
xxx0xx0x
のxの部分だけなので、右から2桁目と5桁目は変化しません。
ってことで、そこが0になるか1になるかは最初の設定値に左右されます。

[F1]から始めた場合は
xxx1xx1x
で値が変化していきます。
[F2]-[F5]から始めると、
xxx0xx0x
で変化します。


管理人様の[F4]でスタートした時に
>私のところでは、1号機、2号機ともに、この手順では遅い方の FRQCR:1F011213 になります。

FRQCR:1F011213
は[F1]から始めないと到達できない値なので、
[F4]のプリセット値が書き換わっている可能性はないでしょうか?
上記の[F1]-[F5]のデフォルトのFRQCR設定値を確認してみてくださいませ。


>FRQCR値を BC34 IWW から変更できるかどうか試すために、BC34 IWW:4 を 2 に変更しても、FRQCR値は変化しませんでした。これはそういう仕様なのでしょうか?

FRQCRは倍率の設定のみですので、
上記のことから、
FRQCR:1F011213
FRQCR:1F001203
この2つの設定値は実質同じことなので、
ベンチマーク結果に関わるメモリアクセスタイミングはBCR/WCRの方で設定されます。
総じてメモリウエイトの設定なので少ない方が速いということになります。
クロック設定が同じでベンチマーク結果が違う場合は、
ここの値の違いが効いてますね。(^^)

Re: Re^11: 310 MHz いきましたが...

sentaro様、Ptune3ユーザーの皆様

管理人のやすです。


> 管理人様の1F001203になるところが再現できません。(^^;

FRQCR:1F001203 にする方法ですが、


> この部分ですが、最初に[F1]デフォルトからBFCを1/8に落としてPLLをx27まで上げると、
> FRQCR :1A011212
> になります。
> そこからFLLをx910に上げて、198.41MHz
> FRQCR :1A011212
> さらにPLLをx32に上げると235.15MHz
> FRQCR :1F011213
> となります。
> これがうちのCG50での結果です。

この手順だと、私の個体でも同じ結果になりました。

そこで、以下の方法だと私の1号機と2号機両方でFRQCR:1F001203になったので、お試し頂けませんか?

1)デフォルトプリセット[F3]を選ぶ ⇒ FRQCR:19102202
2)IFC: 1/2 とする ⇒ FRQCR:19001202
3)FLL: x910 まで上げる ⇒ FRQCR:19001202 ←変化なし
4)PPL: x32 まで上げる ⇒ FRQCR:1F001203 ←ここで 1F001203 になる
5)FLL: x1201 まで上げる⇒ FRQCR:1F001203 ← 1F001203 が維持



> で、ベンチマーク結果が違っている場合はこの値が違っているはずです。
> CS0BCR(ROM領域)
> CS3BCR(SDRAM領域)
> は
> [F3](BC02)
> [F5](BC34)
> で変更することが出来ますが、デフォルトの初期値はすべて4です。

A) 300MHzで、FRQCR:1F011213 の時、
  [F3](BC02) IWW:2
  [F5](BC34) IWW:4

B) 300MHzで、FRQCR:1F001203 の時、
  [F3](BC02) IWW:2
  [F5](BC34) IWW:2

となっています。

B) のケースで、BC34 IWW:2 の時、LIFE074P ベンチマークが速くなるということで、値が異なれば速度が変わることが確認できました。


> で、この2になった場合の安定性はどうかといえば、
> メモリクロックが100MHz以下なので余裕でOkと思われます。(^^)

安心しました。

ならば、FRQCR:1F001203 の方が実行速度は速くなるので、こちらが良いですね!


> つまり、300MHzオーバークロックは
> [F1]のデフォルトクロックから上げるのではなく、
> [F4]の232.31MHzから上げていくのが効率的かつ間違いがないといえます。(^^)

私のところでは、1号機、2号機ともに、この手順では遅い方の FRQCR:1F011213 になります。
なので、上の事例のように FRQCR:1F001203、或いは "BC02 IWW:2 & BC34 IWW:2" とする方が安全かつ速いということになると思うのですが、

FRQCR値を BC34 IWW から変更できるかどうか試すために、BC34 IWW:4 を 2 に変更しても、FRQCR値は変化しませんでした。これはそういう仕様なのでしょうか?

Re^11: 310 MHz いきましたが...

管理人様、Ptune3ユーザーの皆様、こんにちは!

管理人様、再度の検証ありがとうございます!
何か一気に結論が出たような気がしますね。(^^)

>...ということで、2号機異常説或いは1号機異常説のどちらが有力でしょうか?

1号機と2号機に違いが出ず同じ変化具合、同じベンチマーク結果ということは
どちらも正常というしかありません。(^^)

今までの相違は、Ptune3の本体に記憶された設定ファイルが違っていたので、
オーバークロックで設定値が2号機のみ切り替わって、ベンチマーク結果も違っていたということになります。

1号機、2号機ともに310MHzでの動作に不具合が出なければ、
若干下げたところの300MHzでの常用が可能と思われます。(^^)



>の設定を起点にして、
>先に FLL を少し上げて (例えば x910に)、
>その次に PLLを x32 に上げると、FRQCR が 1F001203 になり

この部分ですが、最初に[F1]デフォルトからBFCを1/8に落としてPLLをx27まで上げると、
FRQCR :1A011212
になります。
そこからFLLをx910に上げて、198.41MHz
FRQCR :1A011212
さらにPLLをx32に上げると235.15MHz
FRQCR :1F011213
となります。
これがうちのCG50での結果です。
管理人様の1F001203になるところが再現できません。(^^;


FRQCRの値についてですが、これはPLL乗数やIFC/SFC/BFC/PFCの乗数を設定している値です。

>FRQCR :1F011112

これはCG50のデフォルト値です。
右から2番目が1になっています。

>FRQCR :1F001203

これは[F4]プリセットの初期値ですが、
[F2]-[F5]すべてで
右から2番めが0になるのが特徴です。

で、この0か1の違いは速度的な影響は何もなくて、
[BCR]値の違いが速度性能に効いてきます。
[BCR]は[VARS]-[F2]で見られますが、
CG50で有効なのは、
CS0BCR(ROM領域)
CS2BCR(SRAM領域)
CS3BCR(SDRAM領域)
のうち、
CS0BCR(ROM領域)
CS3BCR(SDRAM領域)
となります。

で、ベンチマーク結果が違っている場合はこの値が違っているはずです。
CS0BCR(ROM領域)
CS3BCR(SDRAM領域)

[F3](BC02)
[F5](BC34)
で変更することが出来ますが、デフォルトの初期値はすべて4です。

FRQCR :1F001203
になっている場合は、
ここがすべて2になっていると思います。
これはPtune3での[F2]-[F5]におけるデフォルト設定値です。

この違いがベンチマーク結果に現れています。

で、この2になった場合の安定性はどうかといえば、
メモリクロックが100MHz以下なので余裕でOkと思われます。(^^)

つまり、300MHzオーバークロックは
[F1]のデフォルトクロックから上げるのではなく、
[F4]の232.31MHzから上げていくのが効率的かつ間違いがないといえます。(^^)

Re^10: 310 MHz いきましたが...

sentaro様、Ptune3ユーザーの皆様

[11:30 追記1、末尾]
[11:50 追記2、冒頭]
[12:00 追記3、末尾]


管理人のやすです。

sentaro様のお考えを正しく理解していなかった恐れがあるので、改めて以下のような実験をしてみました。

[追記2]
詳細は以下をご覧頂くとして、面白いことが分かりました。
1. クロック設定の道筋が異なると FRQCR の値が異なる
2. FRQCR の値と LIFE074Pベンチマーク結果に強い相関性がある
3. 上の2つの項目は、1号機でも2号機でも確認される



先ず、1号機、2号機ともPtune3の設定ファイルを削除して初期化します。

次に、メモリチェックなしで、SETUP設定のみ変更し、CPU CLK Max を 310.17 MHz、Sh1 CLK Max を 160.50 MHz に変更し、他はデフォルトのままにしておきます。

※注:管理人のfx-CG50 2台は運が良いことに高いCPUクロックが出せる個体なので、ここをお読みの他の方は、いきなりこのような設定にはしないでください。慎重に設定を変更する必要があり、最悪電卓のCPUを壊したり、ROMの内容が破壊される可能性があります。

[F5]プリセットを選択後
ノーマルクロックでの[VARS] - [F1] (FRQ) での表示

1号機         2号機
FRQCR  :1F011112  :0F011112 ←1/2号機同じ
FCLKACR :00000057  :00000057
SPUCLKCR :00000003  :00000003
PLLCR  :00005000  :00005000
FLLFRQ  :00004384  :00004384

[F2] (BQG) での表示
CS0BCR  :36DA0400   :36DA0400 ←1/2号機同じ
CS2BCR  :36DA3400   :36DA3400 ←1/2号機同じ
CS3BCR  :36DB4400   :36DB4400 ←1/2号機同じ
CS4BCR  :36DB0400   :36DB0400
CS5ABCR  :17DF0400   :17DF0400
CS6ABCR  :34D30200   :34D30200
SDCR   :00000A08   :00000A08


PLL を上げて x27 (CPU 196.02MHz) にした時は、

1号機         2号機
FRQCR  :1A011112  :1A011112 ←ここだけ変化、1/2号機同じ
FCLKACR :00000057  :00000057
SPUCLKCR :00000003  :00000003
PLLCR  :00005000  :00005000
FLLFRQ  :00004384  :00004384

[F2] (BQG) での表示
CS0BCR  :36DA0400   :36DA0400 ←変化無し、1/2号機同じ
CS2BCR  :36DA3400   :36DA3400 ←変化無し、1/2号機同じ
CS3BCR  :36DB4400   :36DB4400 ←変化無し、1/2号機同じ
CS4BCR  :36DB0400   :36DB0400
CS5ABCR  :17DF0400   :17DF0400
CS6ABCR  :34D30200   :34D30200
SDCR   :00000A08   :00000A08


BFCを一段落として 1/8 にし、PLL を x32 (CPU 232.31MHz)にすると、
PFCが自動変更され、1/16になって、

1号機         2号機
FRQCR  :1F011213  :1F011213 ←ここだけ変化、1/2号機同じ
FCLKACR :00000057  :00000057
SPUCLKCR :00000003  :00000003
PLLCR  :00005000  :00005000
FLLFRQ  :00004384  :00004384

[F2] (BQG) での表示
CS0BCR  :26DA0400   :26DA0400 ←変化、1/2号機同じ
CS2BCR  :36DA3400   :36DA3400 ←変化なし、1/2号機同じ
CS3BCR  :36DB4400   :36DB4400 ←変化なし、1/2号機同じ
CS4BCR  :36DB0400   :36DB0400
CS5ABCR  :17DF0400   :17DF0400
CS6ABCR  :34D30200   :34D30200
SDCR   :00000A08   :00000A08

> 1F001203
> が[F5]プリセットでの元々の設定値なので、
と書かれていますが、これまでのところ1号機2号機ともに元々の設定値と異なっています。



FLL を x959 に上げて CPU 247.54MHzになると、

1号機         2号機
FRQCR  :1F011213  :1F011213 ←変化なし、1/2号機同じ
FCLKACR :00000057  :00000057
SPUCLKCR :00000003  :00000003
PLLCR  :00005000  :00005000
FLLFRQ  :00004384  :00004384

[F2] (BQG) での表示
CS0BCR  :26DA0400   :26DA0400 ←変化なし、1/2号機同じ
CS2BCR  :36DA3400   :36DA3400 ←変化なし、1/2号機同じ
CS3BCR  :36DB4400   :36DB4400 ←変化なし、1/2号機同じ
CS4BCR  :36DB0400   :36DB0400
CS5ABCR  :17DF0400   :17DF0400
CS6ABCR  :34D30200   :34D30200
SDCR   :00000A08   :00000A08


FLLを x1046 に上げて CPU 270MHzになると、

1号機         2号機
FRQCR  :1F011213  :1F011213 ←変化なし、1/2号機同じ
FCLKACR :00000057  :00000057
SPUCLKCR :00000003  :00000003
PLLCR  :00005000  :00005000
FLLFRQ  :00004416  :00004416

[F2] (BQG) での表示
CS0BCR  :26DA0400   :26DA0400 ←変化なし、1/2号機同じ
CS2BCR  :36DA3400   :36DA3400 ←変化なし、1/2号機同じ
CS3BCR  :36DB4400   :36DB4400 ←変化なし、1/2号機同じ
CS4BCR  :36DB0400   :36DB0400
CS5ABCR  :17DF0400   :17DF0400
CS6ABCR  :34D30200   :34D30200
SDCR   :00000A08   :00000A08

ここでも変化無し、1/2号機で同じ値。


前の実験で、2号機が速くなった 300MHz当たりで変化があるかどうか?

そこで、FLL x1085 にして CPU 280,07MHz になると、

1号機         2号機
FRQCR  :1F011213  :1F011213 ←変化なし、1/2号機同じ
FCLKACR :00000057  :00000057
SPUCLKCR :00000003  :00000003
PLLCR  :00005000  :00005000
FLLFRQ  :0000443D  :0000443D ←変化、1/2号機同じ

[F2] (BQG) での表示
CS0BCR  :26DA0400   :26DA0400 ←変化なし、1/2号機同じ
CS2BCR  :36DA3400   :36DA3400 ←変化なし、1/2号機同じ
CS3BCR  :36DB4400   :36DB4400 ←変化なし、1/2号機同じ
CS4BCR  :36DB0400   :36DB0400
CS5ABCR  :17DF0400   :17DF0400
CS6ABCR  :34D30200   :34D30200
SDCR   :00000A08   :00000A08

FLLFRQ に変化が出たが、1/2号機は同じ値。


さらに FLL x1125 にして CPU 290.13NHz になると

1号機         2号機
FRQCR  :1F011213  :1F011213 ←変化なし、1/2号機同じ
FCLKACR :00000057  :00000057
SPUCLKCR :00000003  :00000003
PLLCR  :00005000  :00005000
FLLFRQ  :00004464  :00004464 ←変化、1/2号機同じ

[F2] (BQG) での表示
CS0BCR  :26DA0400   :26DA0400 ←変化なし、1/2号機同じ
CS2BCR  :36DA3400   :36DA3400 ←変化なし、1/2号機同じ
CS3BCR  :36DB4400   :36DB4400 ←変化なし、1/2号機同じ
CS4BCR  :36DB0400   :36DB0400
CS5ABCR  :17DF0400   :17DF0400
CS6ABCR  :34D30200   :34D30200
SDCR   :00000A08   :00000A08

FLLFRQ に変化が出たが、1/2号機は同じ値。

いよいよ FLL x1163 にして CPU 300.20MHz になると、

1号機         2号機
FRQCR  :1F011213  :1F011213 ←変化なし、1/2号機同じ
FCLKACR :00000057  :00000057
SPUCLKCR :00000003  :00000003
PLLCR  :00005000  :00005000
FLLFRQ  :0000448B  :0000448B ←変化、1/2号機同じ

[F2] (BQG) での表示
CS0BCR  :26DA0400   :26DA0400 ←変化なし、1/2号機同じ
CS2BCR  :36DA3400   :36DA3400 ←変化なし、1/2号機同じ
CS3BCR  :36DB4400   :36DB4400 ←変化なし、1/2号機同じ
CS4BCR  :36DB0400   :36DB0400
CS5ABCR  :17DF0400   :17DF0400
CS6ABCR  :34D30200   :34D30200
SDCR   :00000A08   :00000A08

FLLFRQ に変化が出たが、1/2号機は同じ値。

では、310 MHzでどうなるのか?

FLL を x2101 にし、CPU 310.00MHz になると、

1号機         2号機
FRQCR  :1F011213  :1F011213 ←変化なし、1/2号機同じ
FCLKACR :00000057  :00000057
SPUCLKCR :00000003  :00000003
PLLCR  :00005000  :00005000
FLLFRQ  :000044B1  :000044B1 ←変化、1/2号機同じ

[F2] (BQG) での表示
CS0BCR  :26DA0400   :26DA0400 ←変化なし、1/2号機同じ
CS2BCR  :36DA3400   :36DA3400 ←変化なし、1/2号機同じ
CS3BCR  :36DB4400   :36DB4400 ←変化なし、1/2号機同じ
CS4BCR  :36DB0400   :36DB0400
CS5ABCR  :17DF0400   :17DF0400
CS6ABCR  :34D30200   :34D30200
SDCR   :00000A08   :00000A08

ナント、FLLFRQ に変化が出たが、1/2号機は同じ値。

前回の実行時間測定の時との違いは、メモリチェックを事前に行っているかどうか、そしして FLL を上げてゆく速さ 程度しか思いつかない。

この状態で、LIFE074P を実行してプリセットパターン#3 の517世代までに時間を計る。

1号機は 82.71秒、2号機は 82.65秒、な、なんと ほぼ同じ時間になった。
2号機の高速化現象が観られません??

=====

FLL を上げる速度による影響は考えにくいが、一応やってみる。
FLLを上げるとき、キーを押しっぱなしにして迅速に変化させてみる。

結果は、上のものと全く同じになった。


...ということで、2号機異常説或いは1号機異常説のどちらが有力でしょうか?


[11:30 追記]
クロックの上げ方によっては、FRQCR が 1F011213 ではなくて、1F001203 になることが分かりました。

例えば、

FLL: x900
PLL: x27
IFC: 1/2
BFC: 1/8
PFC: 1/8

の設定を起点にして、
先に FLL を少し上げて (例えば x910に)、
その次に PLLを x32 に上げると、FRQCR が 1F001203 になり
さらに FLL を x1085 (CPU 280.07MHz) にすると、FRQCR は 1F001203 で維持、
さらに、FLL を x1163 (CPU 300.20MHz) や x1201 (CPU 310.00MHz)で、FRQCR は 1F001203 のままです。
但し、FRQCR以外の設定値は上と同じです。

この状態で、LIFE074P を実行すると、高速化して、
300 MHz で 77.69秒、310 MHz で75.23秒になります。

この現象は、1号機でも2号機でも確認できました。
1号機が高速化しないのは、偶然クロック設定の道筋が1通りで、FRQCR = 1F011213 の状態しか再現していなかったと言うことになります。

これまでのところ、
・クロック設定の道筋が変わると、FRQCR の値が変わること。
・LIFE074Pベンチマークの結果は、300.20 Mhzで、
 FRQCR = 1F011213 の時 82.7秒、1F001203 の時 77.7秒となる。
・1号機でも2号機でも同様に、高速化することがある。

となると、クロック設定の道筋が違えば、FRQCR の値が異なることがあるのは、それで良いのか?
...ということに問題が絞られてきたように思えますが、如何でしょうか?


[追記3]
より高速になる時の、FRQCR値の安全性が気になります。


Re:Re: Re:Re: Re: Re^4: 310 MHz いきましたが...

管理人様、Ptune3ユーザーの皆様、こんにちは!

>2号機の値のTypoでした。失礼しました。正しくは、

> 1号機          2号機
> FRQCR:  1F011213   FRQCR:  1F001203 ←異なる

>となります。


了解しました。

ってことは、
1F001203
が[F5]プリセットでの元々の設定値なので、
2号機は正常値で1号機が異常値となりますが、
1号機のノーマルから290MHz以下の部分で、どうなっているかお知らせいただけるでしょうか?
もしかしたら、1号機も300MHz設定で何かしらの異常が起きてる可能性があります。(^^;


>2号機は、1号機の内容のバックアップをそのままコピーして使い始めたので、その影響があるのかも知れません。
>一応、RAMとROMのテストをしてから、上限値の設定を確認し、それから個別の設定を行ってはいるのですが...
>そこで、2号機で、Ptune3の設定ファイルを削除して初期化してから、再度確認してみます。

メモリ速度差の影響を排除するために、
設定ファイル削除後はRAM/ROMテストはしない状態で上限値設定だけでお願いします。(^^)



>なお、Skip異常も関連の可能性有りということで、2号機のレジストに異常値が設定されていることが根本にありそうってことは、一連の不思議な現象を理解し易くなりますね。

はい、
異常値になって誤動作していたということであれば原因はそこにありますね。(^^)

Re: Re:Re: Re: Re^4: 310 MHz いきましたが...

sentaro様、Ptune3ユーザーの皆様

[追記 19:50]

管理人のやすです。

ご指摘ありがとうございます。

> >FRQCR:  1F011213   FRQCR:  1F011203 ←異なる
>
> ここですが、もしかして、1号機と2号機は逆ではないでしょうか?
> 1F011213は、設定データとしてはあり得ない数値なので、
> 正常動作の1号機の数値としてあっているかどうかというところです。

[19:50 追記]
1F011213は、設定データとしてはあり得ない数値とのことですが、1号機で300MHzにすると間違い無くこの数値になっています。

2号機の値のTypoでした。失礼しました。正しくは、

 1号機          2号機
 FRQCR:  1F011213   FRQCR:  1F001203 ←異なる

となります。


2号機は、1号機の内容のバックアップをそのままコピーして使い始めたので、その影響があるのかも知れません。
一応、RAMとROMのテストをしてから、上限値の設定を確認し、それから個別の設定を行ってはいるのですが...
そこで、2号機で、Ptune3の設定ファイルを削除して初期化してから、再度確認してみます。

なお、Skip異常も関連の可能性有りということで、2号機のレジストに異常値が設定されていることが根本にありそうってことは、一連の不思議な現象を理解し易くなりますね。


Re:アイコンサンプルです

管理人様、Colon様、Ptune2/3ユーザーの皆様、こんにちは!

Colon様、
>1ヶ月前からすっかり存在を忘れていたのですが、(^^;
>Ptune用のファンクションメニューのデザインのサンプルで、一応これでよいかの確認です。

ありがとうございます!
で、アイコン画像拝見させていただいた限りでは、文句なく良いです。(^^)

アイコンをビットマップデータとして表示するだけならこのままいけそうですね。(^^)

Re:Re: Re: Re^4: 310 MHz いきましたが...

管理人様、Ptune3ユーザーの皆様、こんにちは!

管理人様、
Ptune3のレジスタデータありがとうございます!(^^)

>一番上のFRQCRが異なっていました。
>1番上から3番目まで異なっていました。

この結果を見ると、オーバークロックでレジスタの値が書き換わったことは間違いなさそうです。
値の変わった2号機の数値は[F5]のデフォルト値に近いですが、
全く同じでもないのでCPUの異常動作で引き起こされているものと思われます。


>FRQCR:  1F011213   FRQCR:  1F011203 ←異なる

ここですが、もしかして、1号機と2号機は逆ではないでしょうか?
1F011213は、設定データとしてはあり得ない数値なので、
正常動作の1号機の数値としてあっているかどうかというところです。


結果的に速度差が出ているのは、
CS0BCR
CS2BCR
CS3BCR
の値が変わってアクセスタイミングを詰めた設定になってることなので、
300MHzに至るオーバークロックを、
初期設定値から詰めている[F5]プリセットを開始値としてFLLを上げていくと、
1号機と2号機とでさほど差が出ないかもしれません。(^^)

ただ、2号機は300MHzで内部値が書き換わってしまう異常動作が起きるので、
同じになる保証はありません。(^^;

もしかしたら1号機も書き換わってる可能性もありますので、
最初の[F5]プリセットの値がどこの段階で変化したかどうかをを確認してくだされば幸いです。(^^)


ちなみに、うちの3号機をぎりぎり動作の300MHzにすると、
Skipが動作したりしなかったりの異常動作が出てきました。(^^;
ただ、ノーマルクロックや300MHz未満では異常動作は起きないので、
この異常動作はオーバークロックでの誤動作と断定できます。

アイコンサンプルです

管理人様、sentaro様、Ptune2/3ユーザーの皆様、こんにちは!

色々と大変なところ恐れ入ります。
関係ない話題です。


1ヶ月前からすっかり存在を忘れていたのですが、(^^;
Ptune用のファンクションメニューのデザインのサンプルで、一応これでよいかの確認です。

C.Basicを使って表示しただけのキャプチャーです。

http://pm.matrix.jp/upload/upload.cgi?get=00040

アイコンテーブルと表示ルーチンまではまだ行けていません。
途中経過として報告します。

C.Basicエディタ異常について

sentaro様、Colon様、Ptune3ユーザーの皆様

管理人のやすです。


C.Basic for CG のエディタ異常については、C.Basic のエントリーに移動してコメントが続きましたが、以下のコメントで一応の結論がでました。

https://egadget.blog.fc2.com/blog-entry-664.html#comment3789

Re: Re: Re^4: 310 MHz いきましたが...

sentaro様、Ptune3ユーザーの皆様

管理人のやすです。


今回の不思議な挙動、2台のfx-CG50でPtune3を使って、同じ条件で同じプログラムを走らせると、動作速度が異なるという不思議な現象、について C.Basicとの関連性が考えられたので、C.Basic for CG のエントリーへのコメント欄へ一旦移動していましたが、C.Basic よりは Ptune3 が関係していそうなことが分かってきたので、またこちらへ戻ります。

そこで、以下のコメントに対して、今後はここでコメントを継続します。
https://egadget.blog.fc2.com/blog-entry-664.html#comment3789


> ノーマルに戻したときはリセットされた感じですね。
> Ptune3でリセットできるパラメータは限られているので、
> 300MHzにしたときに何かが書き換わった可能性もあります。
> Ptune3でいじれる範囲のパラメータであれば、
> 300MHzで速くなった時の、
> [VARS]-[F1](FRQ)の各レジスタの値、
> [VARS]-[F2](BCR)の各レジスタの値、再度[F2](WCR)の値、
> が1号機と2号機で差異はないか確認していただけるでしょうか?

1号機 @300.20 MHz    2号機 @300.20 MHz
[FQR]          [FQR]
FRQCR:  1F011213   FRQCR:  1F011203 ←異なる
FCLKACR: 00000057   FCLKACR: 00000057
SPUCLKCR: 00000003   SPUCLKCR: 00000003
PLLCR:  00005000   PLLCR:  00005000
FLLFRQ:  0000448B   FLLFRQ:  0000448B
CCR:   00000103   CCR:   00000103

一番上のFRQCRが異なっていました。


[BCR]          [BCR]
CS0BCR: 16DA0400   CS0BCR: 14920400 ←異なる
CS2BCR: 36DA3400   CS2BCR: 24923400 ←異なる
CS3BCR: 36DB4400   CS3BCR: 24924400 ←異なる
CS4BCR: 36DB0400   CS4BCR: 36DB0400
CS5ABCR: 17DF0400   CS5ABCR: 17DF0400
CS6ABCR: 34D30200   CS6ABCR: 34D30200
SDCR:  00000A08   SDCR:  00000A08

1番上から3番目まで異なっていました。


[WCR]          [WCR]
CS0WCR: 00000340   CS0WCR: 00000340
CS2WCR: 000003C0   CS2WCR: 000003C0
CS3WCR: 000024D1   CS3WCR: 000024D1
CS4WCR: 00000540   CS4WCR: 00000540
CS5AWCR: 000203C1   CS5AWCR: 000203C1
CS6AWCR: 000302C0   CS6AWCR: 000302C0
SDCR:  00000A08   SDCR:  00000A08

[VARS]-[F2]は[WCR] なので、それも合わせて調べたところ、これは相違なしでした。

ご参考になりましたか?

Re: Re^4: 310 MHz いきましたが...

sentaro様、Ptune3ユーザーの皆様

管理人のやすです。


書き忘れたのですが、今回の動作速度の件では、C.Basicのアドインファイルに異常は無かった模様です。

というのも、最初にsentaro様に言われた通り、USB接続で アドインファイルをコピーし直しましたが、Editorでの異常と1号機と2号機での実行速度が異なるという症状が再現されました。

2号機のエディタ異常は、設定ファイルクリア&電源ON/OFFで解消。
1号機の実行速度が遅い件は、1号機にある設定ファイルのクリア&電源ON/OFF で解消。

前のコメントでは、ここのところが曖昧な表現でした。すみません。

Re: バージョン間のSET UPの非互換性について

Colon様、sentaro様、

管理人のやすです。


> 多分、v0.54とv0.55のところで問題が発生しています。

今回の C.BasicのEditor動作異常ですが、実行速度の異常も関連しているかも知れないといった状況なのです。
SET UP 非互換性と動作スピードは、関連あるのか?が、目下の興味の的です。

実行時に、頻繁にSET UP情報のファイルを読み込んだり、一旦実行領域に書き出したものを参照しているならば、セットアップ情報の非互換性の影響を受けそうですね。


バージョン間のSET UPの非互換性について

管理人様、sentaro様、

>皆さんのところではこの問題が発生しなのか?
>私との唯一の違いは、私は Ver 0.47αから一気に 0.56αに上書きしたことです。

多分、v0.54とv0.55のところで問題が発生しています。

v0.48以降、アドイン名がバージョン番号を含むようになっているので、異なるバージョンを混在させてチェックできるようになっていますが、

私のところではv0.54以前とv0.55以降の間で不具合が発生することがあります。
一度sentaro様に対策していただいて発生することは減りましたが、それ以降もまだ発生する場合があるようなので、それかもしれません。

@CBASICフォルダ内のファイルの構造を開示していただけると、今後のバージョンでの対策がとりやすいと思います。>sentaro様

Re^4: 310 MHz いきましたが...

sentaro様、Ptune3ユーザーの皆様

管理人のやすです。


結論から言えば、C.Basic を正常に戻せたら、1号機と2号機でのLIFE074P の動作速度が同じになりました。

さて、メインメモリの@CBASIC フォルダを消去し、C.Basicを起動。これだけではエディタの異常動作は収まらず、一旦電源を切って再起動したら、Editorの動作が正常になりました。

皆さんのところではこの問題が発生しなのか?
私との唯一の違いは、私は Ver 0.47αから一気に 0.56αに上書きしたことです。

ご確認頂けますか?

Re:Re: Re:310 MHz いきましたが...

管理人様、Ptune3ユーザーの皆様、こんにちは!

>2号機が来るまで、壊れて使えなくなるのが怖くて、最高クロックに挑戦していませんでした。

なるほどです。
結果的にはどちらも300MHz超えの当り機だったわけで、管理人様のCG50運最強でしたね。
管理人様のCG50が2台とも300超え、私のは3台のうち2台目だけですが、3台目も300MHz手前なので、CG50の300MHz到達率は案外高いかもしれませんね。
CPUが変更になって平均的に高クロック耐性が上がっている可能性が高そうです。(^^)


>内部計算の負荷が高いライフゲームだとCPUクロックを上げれば高速化し、描画の負荷が高い場合はバスクロックを上げる効果が高いことも確認できたので、[F4] と [F5] の位置づけが実感としてよく分かりました。

[F4][F5]オーバークロックのプログラムごとのベンチマーク比較がまた記事のネタになりそうですね。(^^)


>これなんですが、300MHz、290MHzに設定しても、2号機の方が速い結果になりました。C.Basic自体が関係している感じです。

ありゃりゃ…(^^;


>えっと、これまで2号機でプログラムの編集をしていませんてした。昨日初めてプログラムを編集しようと覆ったら、エディタの異常が見つかりました。
>で、文字を入力するとカーソルが入力した文字の前に来ます。
>Jump で指定行ごとの上ジャンプと下ジャンプが全く効きません。
>メニュー表示で、次のメニューを表示するための [F6] を押すと、1番上の行にジャンプしてしまうことがあります。
>C.Basic に異常が起きています。1号機と2号機の違いはOSバージョンくらいです。

うちのCG50もOS3.10と3.11で同じバージョンのC.Basicを試験中ですが、
片方だけ異常動作になったことがないので、
2号機のC.Basicが何かの原因で異常になっている可能性が高そうです。

もしかして、

>3Pinケーブルで、ストレージにある C.Basic 最新版を2号機にコピーしています。

このケーブル接続でのコピーでファイル破損が起きた可能性もあるので、
もう一度転送してみるか、PCからのコピーを試してみてください。
転送時は転送エラーの可能性を出来るだけ避けるためにノーマルクロックでお願いします。(^^)


>メインメモリの設定ファイルを消して C.Basicを初期化するのはまだ試していないことに、今気がつきました。あとでやってみます。

あ゛…その可能性もありそうです。(^^;

Re: Re:310 MHz いきましたが...

sentaro様、Ptune3ユーザーの皆様


> 管理人様のCG50は大当たり連発だったのですね。(^^)

2号機が来るまで、壊れて使えなくなるのが怖くて、最高クロックに挑戦していませんでした。
SDRAM最高クロックが遅いので、ハズレかと思っていたのですが、結果的に 2台ともCPU のオーバークロック耐性が高かったようですね。ラッキーです。

内部計算の負荷が高いライフゲームだとCPUクロックを上げれば高速化し、描画の負荷が高い場合はバスクロックを上げる効果が高いことも確認できたので、[F4] と [F5] の位置づけが実感としてよく分かりました。



> 分周比、メモリウエイト等、パラメータの設定値、C.Basicのバージョン、動作プログラムが全く同じとするとちょっと奇妙な話ですが、
> これはCPUが限界周波数付近で異常動作を起こしているという可能性があるでしょうか。
> 310MHz動作でもSDRAMクロックは80MHz以下なので、メモリの耐性はどちらも全く問題が無いと思われますので、
> CPUが310MHz付近でいろいろと限界動作(キャッシュアクセスエラー等)になっていると考えられます。

これなんですが、300MHz、290MHzに設定しても、2号機の方が速い結果になりました。C.Basic自体が関係している感じです。

というのも、2号機 OS 3.11 でのC.Basicのエディタ動作がおかしいようです。
えっと、これまで2号機でプログラムの編集をしていませんてした。昨日初めてプログラムを編集しようと覆ったら、エディタの異常が見つかりました。

OS 3.10 の1号機でC.Baisc 0.56αの最新版を入れていて、エディタの問題は感じられません。
3Pinケーブルで、ストレージにある C.Basic 最新版を2号機にコピーしています。

で、文字を入力するとカーソルが入力した文字の前に来ます。
Jump で指定行ごとの上ジャンプと下ジャンプが全く効きません。
メニュー表示で、次のメニューを表示するための [F6] を押すと、1番上の行にジャンプしてしまうことがあります。

[SHIFT] - [MENU] (setup) での設定を1号機と全く同じにしてみたのですが、やはり問題は再現されます。

C.Basic に異常が起きています。1号機と2号機の違いはOSバージョンくらいです。

一旦[SHIFT] - [AC] で電源を切ってから再起動しても状況は変わりません。リスタートしても状況が変わりません。

妙なことになっています。この事と、同じオーバークロック設定でも2号機の方が速いこととの関連性があるとすれば、Ptune3 も絡んでいるのかも...


...ということで、ここに以上を報告致します。


メインメモリの設定ファイルを消して C.Basicを初期化するのはまだ試していないことに、今気がつきました。あとでやってみます。

Re:310 MHz いきましたが...

管理人様、Ptune3ユーザーの皆様、こんにちは!

>2号機で 310MHz動作、特に問題なさそうでした。

おおお!310MHz!!!
うちのCG50で300MHz超えは2号機だけなのですが、最高306MHzですからCG50の最高記録ですね!(^^)

>LIFE047 でプリセットパターン#3の517世代までの時間は、74.26秒でした。

各種プログラムでベンチマークを取るとはっきり分かると思いますが、2号機ではSDRAM限界が低めなので、
[F5]でバスクロックを上げるオーバークロックよりも[F4]でCPU最高周波数を狙う方がいいのかもしれませんね。(^^)


>次に1号機で同様にCPUクロックを上げてみると、結論は上と全く同じ設定の 310MHz あたりが上限でした。

うわうわ!
なんと!1号機も300MHz超え、それも揃って310MHz!
管理人様のCG50は大当たり連発だったのですね。(^^)


>これを超えると、2号機と同様にキーの反応が悪くなります。さらに2号機では観られなかったエラー(リセット要求)が現れます。

うちの個体でも限界付近ではキー反応が悪くなって表示系に異常が出てきたりします。
おそらく1号機の方が若干CPU限界が低いものと考えられます。
どちらにしても310MHz付近まで上げられるとなると、
300MHzは問題なく安定動作するはずです。(^^)


>1号機はSDRAM最大クロックは 105MHzで、2号機よりも5%程度高いのですが、SDRAM耐性、あるいは I/Oの耐性 が低いのかな、と感じられます。
>同様に、LIFE074 で同じベンチマークをすると、80.73秒と明らかに2号機より遅い結果でした。

あり?(^^;
分周比、メモリウエイト等、パラメータの設定値、C.Basicのバージョン、動作プログラムが全く同じとするとちょっと奇妙な話ですが、
これはCPUが限界周波数付近で異常動作を起こしているという可能性があるでしょうか。
310MHz動作でもSDRAMクロックは80MHz以下なので、メモリの耐性はどちらも全く問題が無いと思われますので、
CPUが310MHz付近でいろいろと限界動作(キャッシュアクセスエラー等)になっていると考えられます。

両機とも確実に安定動作する300MHzにして再度ベンチマーク比較をしてみてください。

Re: 310 MHz いきましたが...

sentaro様、Ptune3ユーザーの皆様

管理人のやすです。

1号機、2号機ともに 310 MHz設定は Ptune3 Ver 0.20 を使っています。

310 MHz いきましたが...

sentaro様、Ptune3ユーザーの皆様

管理人のやすです。

2号機で 310MHz動作、特に問題なさそうでした。

FLL: x1201 19.37 MHz
PLL: x32 620.02 <Hz
IFC: 1/2 CPU 310.00 MHz
SFC: 1/4 roR 8 155.10 MHz
BFC: 1/8 CL 2  77.50 MHz
PFC: /16     38.74 MHz

SDRAM: 99.64 MHz
Write: 94.86 MHz

FLL をこれより数段階上げると、キーの反応が悪くなるので、このあたりが限界のように思います。

LIFE047 でプリセットパターン#3の517世代までの時間は、74.26秒でした。


次に1号機で同様にCPUクロックを上げてみると、結論は上と全く同じ設定の 310MHz あたりが上限でした。
なお、SDRAMと書き込みは
SDRAM: 105.34 MHz
Write: 99.17 MHz


これを超えると、2号機と同様にキーの反応が悪くなります。さらに2号機では観られなかったエラー(リセット要求)が現れます。
1号機はSDRAM最大クロックは 105MHzで、2号機よりも5%程度高いのですが、SDRAM耐性、あるいは I/Oの耐性 が低いのかな、と感じられます。

同様に、LIFE074 で同じベンチマークをすると、80.73秒と明らかに2号機より遅い結果でした。


ところで、1号機は OS 3.10 で、2号機は OS 3.11 です。

実際のプログラウ実行速度の明らかな違いは、OSの違いなのか、他に要因があるのか?
チョット面白い結果になりました。

Re:300 MHz 達成!

管理人様、Ptune3ユーザーの皆様、こんにちは!

>FLL: x1163 18.75 MHz
>PLL: x32 600.40 <Hz
>IFC: 1/2 CPU 300.20 MHz
>SFC: 1/4 roR 6 150.10 MHz
>BFC: 1/8 CL 2  75.05 MHz
>PFC: /16     37.52 MHz
>となりました。

ぉお!300MHz超、おめでとうございます!(^^)


>ライフゲームでは、この個体では最速になりますね。

円周率とかだとバスクロックが支配的ですけど、ライフゲームはCPUクロックを上げたほうが速くなりますね。(^^)


>Super Hyway クロックのvROMvへの影響は どの程度注意すれば良いのでしょうか?

200MHzくらいまでは大丈夫と思われるので、300MHzの1/2の150MHz~160MHzは余裕です。(^^)


>なお、1号機の SDRAM Max = 105 MHz なので、SFC の心配さえ抑えておけば、300 MHzでもまだ余裕がありそうです。

ん?もしかして300MHz達成は1号機でしょうか?

現在のPtune3では-1.6%低い周波数表示なので、
300MHzは以前の表示では305MHzとなるので、完全に300MHzオーバー達成ですね。(^^)

300 MHz 達成!

sentaro様、Ptune3ユーザーの皆様

管理人のやすです。


FLL: x1163 18.75 MHz
PLL: x32 600.40 <Hz
IFC: 1/2 CPU 300.20 MHz
SFC: 1/4 roR 6 150.10 MHz
BFC: 1/8 CL 2  75.05 MHz
PFC: /16     37.52 MHz

となりました。

ライフゲームでは、この個体では最速になりますね。

さて今度は、SFC が心配になってきました。メモリチェック直後は、Shw CLK が147.70 MHz になってますが、これを150.65 MHzまで上限を上げて SFC 150.10 MHz で止まります。

Super Hyway クロックのvROMvへの影響は どの程度注意すれば良いのでしょうか?


なお、1号機の SDRAM Max = 105 MHz なので、SFC の心配さえ抑えておけば、300 MHzでもまだ余裕がありそうです。

Re^7: Ptune3 ver0.20 (CG50の動作周波数補正対応しました。)

管理人様、Ptune3ユーザーの皆様、こんにちは!

>これ以上、上げてゆく場合、留意点があれば、教えてください。

メモリ速度は97MHzぐらいが限界とわかっているので、CPU以外は全然余裕です。(^^)

FLLはx1024で赤文字にはなりますが、最高値の2047まで普通にいけてしまうので1200程度なら余裕で大丈夫です。(^^)
メモリクロックは上げすぎるとROM破損の可能性も出てきますが、
[F4]プリセットの場合、メモリ限界よりもFLL限界よりも先にCPUが限界に達しますから、リセット覚悟で試してみてください。(^^;
セットアップの限界クロック設定をデフォルトの270MHzから段階的に引き上げていくのが安全ですね。
メモリの耐性とCPUは別物ですから、ひょっとしたら300MHzいけるかもしれません。

ただひとつ気をつけるべき注意点としては、実験中は決してUSB接続をしないこと、これだけです。


>以上を追記しました。

ありがとうございます!

Re: Re^5: Ptune3 ver0.20 (CG50の動作周波数補正対応しました。)

sentaro様、Ptune3ユーザーの皆様

管理人のやすです。


> はい!
> PFCは1/8を保たないとストレージアクセスや画面転送処理で足を引っ張る原因となります。(^^;

これポイントですね!


> あと、ROMのウエイトも結構効いてきますので、
> ウエイト値が変わる境目ではウエイト値が少なくなるように若干クロックを下げたほうがいい場合もあります。

変わり目スグの時は、プログラム実行速度が大きく変わるのは経験しています。




> ところで、管理人様の2台目はCPUの最高クロックはどれくらいまで上げられるでしょうか?

さて、これですが危険ポイントがチョット心配です。

先ず[F4]プリセットを選ぶと、PLL x32、CPU 232.31 MHz となります。
これ以上 PLL は上がりません。

そこで、FLL を増やしてゆきます。すると、FLL x958 の時、CPU 247.28MHz で、表示が赤く変化します。
さらに増やしてゆくと、FLL x1024 になると、x1024 が赤文字に変化します。

この時、
FLL: x1024 16.52 MHz
PLL: x32 528.64 <Hz
IFC: 1/2 CPU 264.32 MHz
SFC: 1/4 roR 5 132.16 MHz
BFC: 1/8 CL 2 66.08 MHz
PFC: /16 33.03 MHz

となっています。

これ以上、上げてゆく場合、留意点があれば、教えてください。

心配なので、ここで止めています。



> メモリチェック: [OPTN] - [F5] (RAM)
> の項目に[F6](ROM)も加えて、
> メモリ設定をしたら一旦[SHIFT]+[F1]でセーブしておく。
> さらに一旦[AC]OFFにしてメインメモリに保存されたPtune3の設定をストレージに自動バックアップ保存しておく。
> というのを追加していただければいいかと思います。(^^)

以上を追記しました。

Re^5: Ptune3 ver0.20 (CG50の動作周波数補正対応しました。)

管理人様、Ptune3ユーザーの皆様、こんにちは!

>RAMチェック後のリスタートは、確かに安定化に寄与しました。

最新の0.20で少しは不安定化が抑制できてるかと思いますが、
それでもCG50では不安定化するのが普通のことになってしまってますね。(^^;


>PLL x26 (194.00 MHz)、FLL x925 で、SFC / BFC 1/4 (97 MHz)、PFC 1/8 を維持 (48.49 MHz) に設定すると、全体的には結構速さが維持されます。おっしゃるように PFC 1/8 維持がポイントのようですね。

はい!
PFCは1/8を保たないとストレージアクセスや画面転送処理で足を引っ張る原因となります。(^^;

あと、ROMのウエイトも結構効いてきますので、
ウエイト値が変わる境目ではウエイト値が少なくなるように若干クロックを下げたほうがいい場合もあります。


>ライフゲーム LIFE074P で プリセットパターン#3で517世代までの時間は79秒だったので、Ftune2 を使った fx-9860GII と同等の速さが得られています。プリセット[F4]で CPUクロックは 235MHz と速く見えますが、上の194MHz の方がプログラム実行はかなり速くなっています。

プリセット[F4]は最高クロックを狙う設定なので実際のパフォーマンスは微妙ですね。
管理人様の194MHzのライブゲームベンチでは286MHzくらいまで上げないと同等にはなりません。(^^;

ところで、管理人様の2台目はCPUの最高クロックはどれくらいまで上げられるでしょうか?


>なお、記事本文に、使用例を追加しましたが、問題や修正した方が良い点があれば、教えて頂けませんか?

メモリチェック: [OPTN] - [F5] (RAM)
の項目に[F6](ROM)も加えて、
メモリ設定をしたら一旦[SHIFT]+[F1]でセーブしておく。
さらに一旦[AC]OFFにしてメインメモリに保存されたPtune3の設定をストレージに自動バックアップ保存しておく。
というのを追加していただければいいかと思います。(^^)

ストレージに自動バックアップ保存された設定は、リセットすることで復活するので、
クロック上げすぎて暴走しても再設定の手間が省けます。(^^)

Re: Re:Re: Re: Ptune3 ver0.20 (CG50の動作周波数補正対応しました。)

sentaro様、Ptune3ユーザーの皆様

管理人のやすです。


> >設定を保存するために [SHIFT]-[F1] でのエラーが発生しにくくなりました。
>
> 発生しなく…ではなく、発生しにくく、なんですね。(^^;

そうなんです。ギリギリどこまで設定するかに応じて、話が変わってしまうのを経験したもので...


> うちの個体でもSDRAMメモリテストを行うとその後で動作が不安定になったりというのは何度も発生しているので、
> SDRAMテスト後はリセット推奨というのは相変わらずで、Ptune3の安定度はまだまだPtune2には及ばないですね。(^^;

SDRAMの振る舞いに把握しきれていないところがあるので、まぁ仕方無いですよね。

RAMチェック後のリスタートは、確かに安定化に寄与しました。


> おそらく、というか、間違いなくSDRAMのアクセスに失敗している状況です。(^^;
> SDRAMの読み込みよりも書き込みで失敗している可能性が大なので、
> Writeのテスト結果から少し余裕をみて、上限設定を96~97MHzに落とすしかなさそうです。
> となると、PLLx26が一応安定限界という感じになるかと思いますが、
> x26に落とすとROMのウエイトが8に減らせるのでアプリによってはx27とあまり変わらない可能性もありますね。(^^)

PLL x26 (194.00 MHz)、FLL x925 で、SFC / BFC 1/4 (97 MHz)、PFC 1/8 を維持 (48.49 MHz) に設定すると、全体的には結構速さが維持されます。おっしゃるように PFC 1/8 維持がポイントのようですね。

ライフゲーム LIFE074P で プリセットパターン#3で517世代までの時間は79秒だったので、Ftune2 を使った fx-9860GII と同等の速さが得られています。プリセット[F4]で CPUクロックは 235MHz と速く見えますが、上の194MHz の方がプログラム実行はかなり速くなっています。

そして、この設定で結構安定しています。


> 今後メモリクロックが上げられる裏技が発見される可能性もあるので、
> それまでは出来るだけ安全運転で使用されることを推奨します。(^^)

はい、安全第一ですね!


なお、記事本文に、使用例を追加しましたが、問題や修正した方が良い点があれば、教えて頂けませんか?


Re:Re: Re: Ptune3 ver0.20 (CG50の動作周波数補正対応しました。)

管理人様、Ptune3ユーザーの皆様、こんにちは!

>設定を保存するために [SHIFT]-[F1] でのエラーが発生しにくくなりました。

発生しなく…ではなく、発生しにくく、なんですね。(^^;
うちの個体でもSDRAMメモリテストを行うとその後で動作が不安定になったりというのは何度も発生しているので、
SDRAMテスト後はリセット推奨というのは相変わらずで、Ptune3の安定度はまだまだPtune2には及ばないですね。(^^;


>その後、[SHIFT]-[MENU] の上限値設定で、Bus CLK を 99.64MHz に設定し、以下のように設定しました。
>LIFE074 を起動し、以前からベンチマークに使ってきた初期パターン([↓]を2回押した 3番目のパターン)で実行すると、ドット描画の上版分が描画されないという異常がかなりの確率で発生します。>この問題は、ノーマルクロックでは発生しません。
>そこで、FLL を少しづつされると、この異常が起こらなくなるようです。
>SDRAM の応答が間に合わなくなるための現象ではにかと思われますが、どのように思われますか?

おそらく、というか、間違いなくSDRAMのアクセスに失敗している状況です。(^^;
SDRAMの読み込みよりも書き込みで失敗している可能性が大なので、
Writeのテスト結果から少し余裕をみて、上限設定を96~97MHzに落とすしかなさそうです。
となると、PLLx26が一応安定限界という感じになるかと思いますが、
x26に落とすとROMのウエイトが8に減らせるのでアプリによってはx27とあまり変わらない可能性もありますね。(^^)

今後メモリクロックが上げられる裏技が発見される可能性もあるので、
それまでは出来るだけ安全運転で使用されることを推奨します。(^^)

Re: Re: Ptune3 ver0.20 (CG50の動作周波数補正対応しました。)

sentaro様、Ptune3ユーザーの皆様

管理人のやすです。


> おそらく、SDRAMが100MHz付近で限界になってそうなので、
> それがROMのメモリチェックに影響を与えていると思われます。
>
> ってことで、そこのところをちょこっと修正してみましたのでお試しくださいませ。
>
> Ptune3 ver.0.20(差し替えです)
> http://pm.matrix.jp/Ptune3_020.zip


Ptune3 Ver 0.20 差し替え版を頂きました。ありがとうございます。

設定を保存するために [SHIFT]-[F1] でのエラーが発生しにくくなりました。

[OPTN]で行うメモリチェックで、[F5] (RAM) を実行し、SDRAMの最大周波数が 99.92 (差し替え前と同じ)が得られました。
その後、[SHIFT]-[MENU] の上限値設定で、Bus CLK を 99.64MHz に設定し、以下のように設定しました。

FLL:x900
PLL:x27 392.03 MHz
IFC:1/2 CPU 196.02MHz
SFC:1/4 roR 10 98.00 MHz
BFC:1/4 CL 2 98.00 MH
PFC:1/8 49.00 MHz

さて、LIFE074 から呼び出す LMAP1 内で使っていた DotP( を DotPut( に書き換え、LIFE074 の冒頭の '#CBint の下に以下を追加し、LIFE074 を走らせて見ました。

'== Execute Mode
'#CBint
'#G1M
Pot/Linr-Clor Black

LIFE074 を起動し、以前からベンチマークに使ってきた初期パターン([↓]を2回押した 3番目のパターン)で実行すると、ドット描画の上版分が描画されないという異常がかなりの確率で発生します。

この問題は、ノーマルクロックでは発生しません。
そこで、FLL を少しづつされると、この異常が起こらなくなるようです。

SDRAM の応答が間に合わなくなるための現象ではにかと思われますが、どのように思われますか?

Re: Ptune3 ver0.20 (CG50の動作周波数補正対応しました。)

管理人様、Ptune3ユーザーの皆様、こんにちは!

>roRw10 と 12 で異常な値になります。
>ひょっとして、何かバグが潜んでいるかも知れないと思っての報告です。

おそらく、SDRAMが100MHz付近で限界になってそうなので、
それがROMのメモリチェックに影響を与えていると思われます。

ってことで、そこのところをちょこっと修正してみましたのでお試しくださいませ。

Ptune3 ver.0.20(差し替えです)
http://pm.matrix.jp/Ptune3_020.zip


管理人様の2台目のROMメモリチェックの値は、ちょうど、うちの1台目と2台目の間にあります。(^^)
SDRAMテストは3台目に近いです。

1台目(最高278MHz)
SDRAM:115.25MHz
Write:102.95MHz

2台目(最高305MHz)
SDRAM:112.25MHz
Write:103.14MHz

3台目(最高298MHz)
SDRAM:101.92MHz
Write: 96.35MHz

(※周波数は-1.6%補正後の数値です)

管理人様の2台目の結果と併せると、昨年の個体に比較してSDRAMの耐性は落ちている傾向ですね。(^^;
実周波数が1.6%低くなったので3台目は300MHzオーバーならずになってしまいました。(^^;


>さて、このような個体ですが、安全性や誤動作しない範囲で、これ以上の高速化の可能性はありますでしょうか?

FLL設定を少しずつ上げるともう少し限界値が上る可能性はありますが、200MHzは難しいかもしれません。
以前はPLLがx27だと199.07MHzなので200MHzまではほんの少しだったのですが、
-1.6%になったことが結構効いてきますね。(^^;

Re: Ptune3 ver0.20 (CG50の動作周波数補正対応しました。)

sentaro様

管理人のやすです。

Ver 00.20 になって、改めて高速化のために設定を変更してみました。

2台目のfx-CG50 は、SDRAMの最大クロックが低いものでした。

何度かメモリチェックを行うと、SDRAM が 殆ど99.92MHz ですが、たまに 100.03MHzとなります。


メモリチェック
roRw0: 15.20MHz
roRw1: 25.87MHz
roRw2: 36.05MHz
roRw3: 46.00MHz
roRw4: 56.37MHz
roRw5: 66.47MHz
roRw6: 76.45MHz
roRw8: 97.06MHz
roRw10: 116.48MHz
roRw12: 133.19MHz

SDRAM: 99.92
Erite: 94.68MHz


ところが、以下のようになることが1度ありました。
roRw0: 15.20MHz
roRw1: 25.87MHz
roRw2: 36.05MHz
roRw3: 46.00MHz
roRw4: 56.37MHz
roRw5: 66.47MHz
roRw6: 76.45MHz
roRw8: 97.06MHz
roRw10: 21631.18MHz
roRw12: -10906.0-

SDRAM: 100.03
Erite: 87.03MHz

roRw10 と 12 で異常な値になります。

ひょっとして、何かバグが潜んでいるかも知れないと思っての報告です。


さて、SDRAM の値を超えないようにするのが安全性のポイントだろうと思い、
[SHIFT]-[MENU] (setup) で、Bus CLK を 99.64MHz としておき、

FLL: x900
PPL: x27 392.03MHz
IFC: 1/2 CPU 196.02MHz
SFC: 1/4 roR 10 98,00 MHz
BFC: 1/4 CL 2 98.00 MHz
PFC: 1/8 49.00 MHz

BFC / SFC がこれを超えると、設定を [SHIFT]-[F1]で保存すると強制リセットされてしまいます。

つまり、残念ながら 200MHz 超えの一歩手前が妥当な感じがしています。

ここで、Setup のBus CLK の上限設定を上げて、

SFC / BFC を上げると、C.basic 実行時に エラーになり、エラー発生箇所に元のソースになり妙な記号 a が大きくなったような妙な文字 が入り込んでいます。

これは、LIFE074P (UCFでランダムパターンから開始するルーチンを取り込んだものを G1Mモードで実行) で確認しています。
https://egadget2.web.fc2.com/archives/fx-9860GII/Conways_Life/Conways_Life_piu58_version.html


さて、このような個体ですが、安全性や誤動作しない範囲で、これ以上の高速化の可能性はありますでしょうか?

Ptune3 ver0.20 (CG50の動作周波数補正対応しました。)

管理人様、Ptune3ユーザーの皆様、こんにちは!

CG50だけお持ちの場合はさして問題になることも無いのですが、
SH4AのFX機やCG10/20をお持ちの場合は
Ftune2/Ptune2とPtune3で同じクロックにした場合、
CPUベンチマーク結果が違うことに気が付かれた方もいるかもしれません。
(参考リンク)
http://www.casiopeia.net/forum/viewtopic.php?f=25&t=7327

これはCG50のCPUが何かしらの内部仕様の変更があったか、SDRAMアクセスでの何かで、
実際の動作周波数が計算で求められる周波数よりも低い周波数で動作していると思われます。

CG50デフォルトの計算上の動作周波数は
117.96MHz
ですが、
実際にはC
-1.6%ほど低いところの、
116.15MHz(正確ではありません)
くらいで動作しています。

これはFtune2/Ptune2とPtune3でCPUベンチ値を比較すると
FX機/CG20よりも-1.6%ほど低くなるのが分かるかと思います。

今回のアップデートはその周波数誤差を補正して表示できるようにするものです。


Ptune3 ver.0.20
http://pm.matrix.jp/Ptune3_020.zip
実際の周波数とのズレを考慮して表示するようにしました。(セットアップで設定できます。)
(暫定補正値 = PLLより算出される内部周波数 * 900 / 914)

Re: fx-cg20で整数版シダ描画

iron2様

管理人のやすです。


> わたしのような新人さんにレスを返していただき
> たいへんありがとうごいます。


とんでもありません。一応管理人の気持ちとしては、ここに来られる方はお客様、コメント頂く方は同好の士、お友達といった気分でやっております。

これからもお気楽にコメント下されば嬉しいです。


> クロックが測れる関数が用意されているので
> マニュアル参照してくださいとの事


コマンドの使い方はマニュアルをご覧頂くのが良いと思ったのですが、プログラム開始後終了までの簡単な時間測定の方法をご紹介します。

C.Basic を起動し [SHIFT][MENU] (SET UP) として、"EXEC TIMEDSP" の項目があるので、設定を on にしてください。こうするとプログラム終了時に実行から終了までの時間が表示されます。


コマンドについては、C.Basic for FX Ver 1.64β に含まれている Manual_J_txt をご覧頂くと、Ticks コマンドの説明があります。
http://pm.matrix.jp/CB/CBASIC164beta.zip

これはタイマー変数で、1/128秒刻みでクロックを刻むので、時間を知りたい時に Ticksを参照すると値が得られます。
0→Ticks で初期化した後の時間経過を知るには、Ticksを参照するのみ。或いは特定の時刻を変数で保存しておき、Ticksとの差を見れば任意の時間を計測&表示できる...といった感じです。

Ticksが実装される前には、タイマー変数として % があり、今でも有効です。私は1文字の % を好んで用いています。


> 2倍どころではないです。恐るべし整数演算。
> 実験報告でした。


整数演算は、C.Basic の初期バージョンの目玉でした。さらにバイト数の少ない変数型を設定できるのも目玉の1つで、各種変数型を要素に指定できる行列を使えることになったことで、画面全体をBMPのように行列に格納したり、文字列も内部的には行列に格納して使うような方向で、実装が進んできました。C言語での文字列の扱いを行列で扱うといった感じと申し上げた方が分かり易いかも知れません。


> 仕事以外
> はお気楽に脳トレぎみに使えるグラフプログラミング
> 関数電卓に興味がわき、数年前からここを
> 覗いています。


管理人が抱いている感覚に近いです。閲覧頂いてありがとうございます。

よろしくお願い致します。

fx-cg20で整数版シダ描画

こんにちは、管理人様、 sentaro 様

わたしのような新人さんにレスを返していただき
たいへんありがとうごいます。

管理人さまのご指導
クロックが測れる関数が用意されているので
マニュアル参照してくださいとの事
あー、これでiphoneのストップウォッチからおさらば!

>hp-primeが
>小文字使えるのと
>エディターが広いのが

というのは、たぶんわかってらっしゃると
思いますが、小フォントが使えるが正しいです。

その結果、エディタが広い
もう私は老眼で乱視で眼鏡がないと小さい文字は
見えないんですが、とは言え少しでも行数が
多く見えるとコーディング時の想像部分が減るので
ワザと小フォントで使ってます。⇒hp-prime

茶店でポチポチとするのには向いているような感じです。
最もパソコンで編集してできたソフトを持ち歩くのも当然
の選択肢ですけど。

電卓の通常利用ではでかいフォントのほうが使いやすいです。
難点は電卓全般いえるのですが横にはみ出した分の
横スクロールが遅めかなと感じています。

sentaro様のミニフォントまだ未体験ですが
ぜひトライさせていただきます。

本題の整数版シダ1のfx-cg20での実行結果ですが
Ptune2 v1.11
PLLx32 ,
IFC 1/2 235.93MHz,
SFC1/4 roR10 117.96MHz,
BFC 1/4 raR 6 117.96MHz
PFC 1/32 raW3 14.75MHz

Bench Cpu 58892 ,PutDisp 99.29fps
この設定が一番PutDisp値が高いのでこれで実行しました。

C.Basic for CG アルファ版環境より実行。
iphoneのストップウォッチで測定。
1回目11.57秒、2回目11.56秒、3回目11.49秒
うーんすでに超えている!(hp-primie)
fx-cg50はこれの倍速ですか(^_^)

通常のシダCGは同じ設定で40秒ほどこれでも
腰を抜かしたのですが・・・
2倍どころではないです。恐るべし整数演算。
実験報告でした。

いまのパソコンは昔できなかった事がサクッと
できてしまい。便利なんですがアップデートが
(大すぎ、遅すぎ、容量取りすぎ)で仕事以外
はお気楽に脳トレぎみに使えるグラフプログラミング
関数電卓に興味がわき、数年前からここを
覗いています。

今回のC.Basic for CGを体験したことで
自分的には「〇〇〇はあと10年は戦える!」
です。いろいろ試してみます。

11月も後1週間ちょい今年も残りわずかになりました。

管理人様、sentaro様、他ここに集う皆様の
活躍、ご健康をお祈りします。

これからもよろしくお願いします。


Re:fx-cg20でシダ描画

iron2様、はじめまして!

C.Basic for CGをお試しいただきましてありがとうございます!
初期よりCG20では動作してなかったのですが、おかげさまで、なんとかCG20でも動作するようになりました。
今のところはg1mモードの互換動作メインになっていますが、g3mモードでもPICTを除けばなんとか動作するところまで来ました。

>hp-primeが
>ノーマルで速いのと
>小文字使えるのと
>時間計測できるのと
>エディターが広いのが
>気に入ってますが
>CASは癖強い印象です。

Primeは私も所持していますが、ハードを直にいじれる自由度がないのが難点とはいえ、プロ電としてみれば他を寄せ付けない爆速ぶりが良いですね。
C.BasicはとりあえずPrimeの速度を目標にバージョンアップしていきます。

エディタの広さに関してはせっかくの高解像度なのでなんとかしたいところです。
C.Basicではミニフォントモードが実用的になってきたのでぜひお試しください。

シダグラフィックスに関してはC.Basicでは整数モードが使えるので、整数バージョンを作成してみました。
http://pm.matrix.jp/CB/SHIDACGI.g3m
2倍以上高速化するので、オーバークロックしたCG20ならPrimeにも負けないかもしれません。(^^)

まだCG50は出たばっかしですし、CG20ユーザーの方がずっと多いのでCG20対応はしっかりやっていきたいと思います。(^^)
これからもよろしくお願いいたします。

Re: fx-cg20でシダ描画

iron2 様

コメントありがとうございます。

> ほんとうに感動しました。
>
> ただの電卓がハンドヘルド
> コンピュータとして実用の
> 速さに達した感が強いです。


私も全く同感です!


> fx-5800p
> fx-jp900
> fx-cg20
> hp-prime
> を所持しています


fx-CG20 も C.Basic for CG で使える機種に昇格ってことですよね。


> hp-primeが
> ノーマルで速いのと
> 小文字使えるのと
> 時間計測できるのと
> エディターが広いのが
> 気に入ってますが
> CASは癖強い印象です。


C.Basic for CG (従来の for FX も含めて) は、
・ノーマルで速いのと
・小文字使えるのと
・時間計測できるのと

を満足します。

従来の fx-9860Gシリーズ向けの C.Basic のマニュアル類をご覧ください。for CG は順次この従来版の機能が実相されてゆく予定です。
http://egadget.blog.fc2.com/blog-entry-495.html


> e-Gadgetの一読者として
> これからも応援します。


よろしくお願い致します。


fx-cg20でシダ描画

こんばんわ、iron2というHNで
はじめて投稿します。
fx-cg20を235.93MHzにクロックアップし
C.Basic for CG アルファ版
でshidacgを実行したところ
39.23秒で終わりました。

ほんとうに感動しました。

ただの電卓がハンドヘルド
コンピュータとして実用の
速さに達した感が強いです。

fx-5800p
fx-jp900
fx-cg20
hp-prime

を所持しています

hp-primeが
ノーマルで速いのと
小文字使えるのと
時間計測できるのと
エディターが広いのが
気に入ってますが
CASは癖強い印象です。

fx-cg20完全対応版
C.Basic for CG を心待ちに
しています。

乾電池4個でこれだけ
できればウハウハです。

乱筆失礼しました。

e-Gadgetの一読者として
これからも応援します。

以上

Re:Re: Re:Re: Re:Re: Ptune3 ver0.10

管理人様、こんにちは!

>これの効果がどの程度かみてみました。素因数分解と Bugrace (PlotOnで点を打ってゆく) で比較していましたが、処理速度の差が殆どみられませんでした。デフォルトの [F5]の設定です。

す、すみません、比較する時にROMのウエイトが違っていたようです。それでちょこっと速くなっていたと勘違いです。(^^;
OS3.00とOS3.10でCasioBasicで比較すると3.10が速いですが、3.00側のROMのウエイトを減らすと速度差が逆転します。ROMの速度はてきめんに効いてきますね。
(WC34)の設定を詰めるとメモリ速度を測定するとそれなりに有意な差が出てくるんですが、CasioBasicではほとんど差が出ないですね。(^^;

Re: Re:Re: Re:Re: Ptune3 ver0.10

sentaro様

管理人のやすです。


> 3D Graphは最初おおお!って思うんですけど、今は速度比較にしか使ってないかもです。(^^;

そうですか、今度触ってみようと思います。


> [VARS]-[F6](WC34)の設定でTRPの数値を1にすると一段高速化します。

これの効果がどの程度かみてみました。素因数分解と Bugrace (PlotOnで点を打ってゆく) で比較していましたが、処理速度の差が殆どみられませんでした。デフォルトの [F5]の設定です。


Re:Re: Re:Re: Ptune3 ver0.10

管理人様、こんにちは!

>Casio Basic ばかりに興味があって、色々な計算アドインや3D Graphなどまだ一度も触っていません。これらもチョット触ってみようかと思うのですけど...

3D Graphは最初おおお!って思うんですけど、今は速度比較にしか使ってないかもです。(^^;


>なかなか難しそうで、何か情報が出てくると良いですね。

SDRAMのチップ自体はDDRでもないSDRなのでPCでは3世代以上古い時代のものなので、探せば何か出てきそうな気がします。(^^)


>デフォルトのマージンを減らしてみたところ、画面が乱れるので簡単にゆきませんでした。

[VARS]-[F5](BC34)の設定で左側の設定値をすべて2に変更して、(F2~F5の設定ではすでに2に設定済みです。)
[VARS]-[F6](WC34)の設定でTRPの数値を1にすると一段高速化します。
このようにSDRAMのパラメータを削れば若干高速化出来るポイントがありますが、動作安定性の確保が難しくなるので、難しいところです。
かといって、タイミングを緩めたらより速く動作するかというとそれもCG20のSRAMのようにはなかなか上手くいかないので、ちょっと煮詰まっているところです。(^^;


>これは、まだ試していませんでした。チョットやってみます。
>fx-CG50 を2台持っていると比較がしやすいですよよね。

はい、米amazonからの2台目は各種比較用にとゲットしたところでしたし、速度比較は2台あると一目瞭然なので便利ですね。(^^)

ちなみに、さっき、米amazonのCG50を見たら、$109.5に値上がってました。(^^;
そこそこ売れているということでしょうかね。

Re: Re:Re: Ptune3 ver0.10

sentaro様

> あ゛、1.00ではなくてまだ0.10です。(^^;

わ、すみません。修正しました。


> 純正の関数計算だとCPUクロックが速いほうが有利になることもありますが、CasioBasic等、ほとんどの処理においてはメモリ速度が効いてきますね。

Casio Basic ばかりに興味があって、色々な計算アドインや3D Graphなどまだ一度も触っていません。これらもチョット触ってみようかと思うのですけど...


> そうなんです。
> ROMはCG20と同じなので同様に安定するのですが、SDRAMになったCG50ではSRAMだったCG20のようにはいかないです。
> これはSDRAMのメモリテストの方式を変える必要がありますが、まだいい方法が見つけられてないので今後の課題です。(^^;


なかなか難しそうで、何か情報が出てくると良いですね。


> メモリテストではWriteの方が低く出るはずなのでそこが限界周波数と考えて良いです。
> メモリテスト後のバスクロックの自動設定ではWriteの結果から限界周波数がセットされますので、それを超えない範囲が今のところ安定限界かなと考えています。
> 管理人様の個体ではWriteの結果からすると長期安定を考えてメモリクロックは105MHzくらいまでとするのが良さそうです。
> FLLがデフォルトの場合、PLLではx29の106MHzが安定限界付近で、一段落としたx28がベスト値ということになります。(^^)


ありがとうございます。さっそく設定を変えました。


> はい、現状のPtune3ではSDRAMの動作限界を大きく伸ばす設定が出来ないので、デフォルトのマージンを減らす高速化しか出来ません。
> SDRAMを高クロック化することが出来れば、安定して2倍を超えることができそうですが、これはちょっと難しいかもしれません。


デフォルトのマージンを減らしてみたところ、画面が乱れるので簡単にゆきませんでした。


> ところで、3.10にアップデートしたCG50とCG20は、CasioBasicのプログラムで比較すると以前のバージョンよりも若干数%程速くなってるようですね。(^^)

これは、まだ試していませんでした。チョットやってみます。
fx-CG50 を2台持っていると比較がしやすいですよよね。

Re:Re: Ptune3 ver0.10

管理人様、こんにちは!

>角の丸い fx-CG50 風のアイコン良いです!
>記事も変更しました。

早速にありがとうございます!
あ゛、1.00ではなくてまだ0.10です。(^^;


>私の個体は、PLL: x29、CPU 217.61MHz、バスクロック BFC:1/4 ((CL 2) 108.81MHz が限界のようです。
>BFC: 1/8 にすれば、CPUコアクロックを増せますが、表示が遅くなり、却って全体が遅くなってしまいます。

純正の関数計算だとCPUクロックが速いほうが有利になることもありますが、CasioBasic等、ほとんどの処理においてはメモリ速度が効いてきますね。


>何故だか、値が大きく変動しています。一方、ROMテストでは、ほぼ同じ値を示します。

そうなんです。
ROMはCG20と同じなので同様に安定するのですが、SDRAMになったCG50ではSRAMだったCG20のようにはいかないです。
これはSDRAMのメモリテストの方式を変える必要がありますが、まだいい方法が見つけられてないので今後の課題です。(^^;


>従って、[SHIFT] [MENU] (SET UP) では、Bus CLK Max を 110MHz に設定し、その上で上限の1段下の [F5]設定の状態で使うようにしています。

メモリテストではWriteの方が低く出るはずなのでそこが限界周波数と考えて良いです。
メモリテスト後のバスクロックの自動設定ではWriteの結果から限界周波数がセットされますので、それを超えない範囲が今のところ安定限界かなと考えています。
管理人様の個体ではWriteの結果からすると長期安定を考えてメモリクロックは105MHzくらいまでとするのが良さそうです。
FLLがデフォルトの場合、PLLではx29の106MHzが安定限界付近で、一段落としたx28がベスト値ということになります。(^^)


>恐らく、これ以上触っても大きな高速化は無理な感じですが、如何でしょうか?

はい、現状のPtune3ではSDRAMの動作限界を大きく伸ばす設定が出来ないので、デフォルトのマージンを減らす高速化しか出来ません。
SDRAMを高クロック化することが出来れば、安定して2倍を超えることができそうですが、これはちょっと難しいかもしれません。


ところで、3.10にアップデートしたCG50とCG20は、CasioBasicのプログラムで比較すると以前のバージョンよりも若干数%程速くなってるようですね。(^^)

Re: Ptune3 ver0.10

sentaro様

管理人のやすです。

> fx-CG50国内発売前に一応、ってことで、0.10にバージョンアップしました。

お疲れ様です。早速 Ver 1.00 を使っています。


> アイコンをCG50スタイルに変更したのとSDRAMチェックの仕様を少し変更したのみで機能的には0.05と変わるところはありません。(^^;

角の丸い fx-CG50 風のアイコン良いです!


記事も変更しました。


> ということで、現状Ptune3では2倍以上の大幅なオーバークロックは出来ないですが、CG50は基本ベースで高速化されているのであまりPtune3の必要性はないかもしれませんね。

私の個体は、PLL: x29、CPU 217.61MHz、バスクロック BFC:1/4 ((CL 2) 108.81MHz が限界のようです。
BFC: 1/8 にすれば、CPUコアクロックを増せますが、表示が遅くなり、却って全体が遅くなってしまいます。


BFC: 1/4 (CL 2) のまま、PLL: x30 にすると、CPU 225.12MHz になりますが、BFC: 112.56MHz となり、以下のエラー表示と共に、固まってしまいます。幸い筐体裏面のリスタートボタンで復帰できています。

TARGET = 00000300
PC = FD8017CB

おそらく ROM 異常は回避できていても、SDRAM異常が発生している感じです。

RAMテストの結果は、

SDRAM: 106.88MHz、Write: 100.72MHz となりました。

以前は、SDRAM::142.50MHz、Write: 95.00MHz となったこともあり、

Prune3 を初めて導入した時は、SDRAM: 111.68MHz、Write: 104.36MHz でした。

何故だか、値が大きく変動しています。一方、ROMテストでは、ほぼ同じ値を示します。

 
従って、[SHIFT] [MENU] (SET UP) では、Bus CLK Max を 110MHz に設定し、その上で上限の1段下の [F5]設定の状態で使うようにしています。

スピードが欲しい時だけ、安全上限の 217.61MHz (PLL: x29、BFC: 1/4) を使っています。

以上は、Ver 0.05 からそうで、Ver 1.00 で試しても同じ結果になっています。


恐らく、これ以上触っても大きな高速化は無理な感じですが、如何でしょうか?


Ptune3 ver0.10

管理人様、Ptune3ユーザーの皆様、こんにちは!

fx-CG50国内発売前に一応、ってことで、0.10にバージョンアップしました。
アイコンをCG50スタイルに変更したのとSDRAMチェックの仕様を少し変更したのみで機能的には0.05と変わるところはありません。(^^;

ということで、現状Ptune3では2倍以上の大幅なオーバークロックは出来ないですが、CG50は基本ベースで高速化されているのであまりPtune3の必要性はないかもしれませんね。

http://pm.matrix.jp/Ptune3_010.zip

バグや疑問点、何かお気づきの点がありましたらよろしくお願いします。

Re:Re: キーを押す位置

管理人様、こんにちは!

>接点パッドをキーが押す機構設計にそもそも問題があるのか、組み付け時工程の問題なのか、その両方の問題ということになりそうです。

おそらくキーが大きくなったので真ん中を真っ直ぐ押し込まないと、キーが斜めに押されてきちんと下部パッドが押されないことがある感じですね。


>そうですね、現時点は FLLを1段下げておくことにします。

あ゛、、、FLL一段だとかなり微細な下げになるので、PLLですね。(^^;


>試しに BugTrace (点を1ドット打っておくと画面を埋め尽くす、例のプログラム)を実行しましたが、嫌になるくらい時間がかかりました。埋め尽くす点の位置は、fx-CG9860GII とは違っていましたよ!

点の位置は、Pixelコマンドに互換性がないので致し方ないところですけど、グラフィックスの速度はCG20の頃より激遅なので、それが3倍に速くなったとしてもどうしようもないですね。(^^;


>いずれにせよ、C.Basic の fx-CG50 への移植が待たれるところです(^^;

純正CasioBasicの速度改善も期待したかったところですけど、ここはやはりPrizm版C.Basicでというところですね。(^^)
fx版C.Basicの課題が続々出てきててそれの更新&修正作業でちょっと詰まってしまってるので、もうしばらくお待ち下さいませ。m(_ _)m

Re: キーを押す位置

sentaro様

テンキー [7[ [8] [9] の列以下のキーの取りこぼしについて、右よりを押すと反応しない傾向は、私のところでも確実にあります。

そちらと同じだと分かり、ハズレを引いた訳ではなく、ハードウェアの個性あるいは欠陥のようですね。

接点パッドをキーが押す機構設計にそもそも問題があるのか、組み付け時工程の問題なのか、その両方の問題ということになりそうです。

オーバークロック時にキースキャン時間が短くなる影響も私の感覚と合います。



> >ver 0.05 時点では、このあたりが安全な最大速度といった感じですか?
>
> はい!
> たぶん、安定性はだいじょうぶだと思います。
> より安全性をあげるにはそこから一段下げておけば万全ですね。

そうですね、現時点は FLLを1段下げておくことにします。

試しに BugTrace (点を1ドット打っておくと画面を埋め尽くす、例のプログラム)を実行しましたが、嫌になるくらい時間がかかりました。埋め尽くす点の位置は、fx-CG9860GII とは違っていましたよ!

バスクロックをできるだけあげた状態で、せめて 250 MHz くらいまでは出せるといいかな、などと思います。

いずれにせよ、C.Basic の fx-CG50 への移植が待たれるところです(^^;


キーを押す位置

管理人様、こんにちは!

>ver 0.05 時点では、このあたりが安全な最大速度といった感じですか?

はい!
たぶん、安定性はだいじょうぶだと思います。
より安全性をあげるにはそこから一段下げておけば万全ですね。


>チョット気付いたのですが、たまにキーを軽くチョンと叩いた時に、取りこぼしがあるようです。

これは私の個体でも似た感じが発生しています。
キーを押した時にキーの左側に重心がいったときと右側で反応が違っていて、左側は反応がいいですが右側は若干取りこぼし感があります。
これは[EXE]キーだけでなくテンキー部分がほぼそのような感じなので、CG50のハード的個性?欠陥?かもしれないですね。(^^;


>ひょとして、私の個体で、たまたまキーの接点に問題があるということもありそうです。オーバークロック時にジッタの影響が大きくなろとか、理屈上ありえますか?

オーバークロックしている場合にはキースキャンの時間が短くなるので反応が鈍くなることは考えられますが、
私の個体では全般的に上記のような感じなので右側に偏った軽い押し方だとノーマルでも取りこぼしが頻発する感じがありますね。
CG20ではそのような感じはないので、CG50になってからの新たな問題と言えますが、キー直下のキーパッドの位置が若干ずれて付けられているのかもしれません。(^^;

Re: Ptune3専用エントリ早速にありがとうございます!(^^)

sentaro様

私の個体では、

※ メモリチェックの結果、SDRAM が 106.98 MHz になっています。

※ アドバイス通り、[F5]の設定から、PLL をあげる

※ さらに FLL をあげてゆくと BFC が 105.51 MHz まであげられました。

※ CPU 211.02 MHz になりました。

バスクロックをあげると、実行速度が確かに向上しました。

ver 0.05 時点では、このあたりが安全な最大速度といった感じですか?


チョット気付いたのですが、たまにキーを軽くチョンと叩いた時に、取りこぼしがあるようです。
再現性が掴めていませんが、ノーマルクロックよりもオーバークロック時に頻度が多くなるようです。
特に [EXE]キーの応答が他のキーに比べて悪い感じです。

ひょとして、私の個体で、たまたまキーの接点に問題があるということもありそうです。オーバークロック時にジッタの影響が大きくなろとか、理屈上ありえますか?

Ptune3専用エントリ早速にありがとうございます!(^^)

管理人様、こんにちは!

早速のPtune3のエントリ新設ありがとうございます!(^^)
Ptune3はPtune2の時と違って、まだ未完成の現在進行系ツールなので専用エントリはとてもありがたいです。

>この赤バックの表示は、何を教えてくれているのでしょうか?

一応危険かも?領域に入ったという注意喚起という感じです。
実際にはおそらく270MHz以上まで上げられると思いますが、CG50のCPUクロックが安全的にどこまで上げられるのかまだ把握出来ていないので、CG20のPtune2の260MHzよりも少し下げた251MHzにしてありますが260MHz以上の安定動作が期待できるならば先のバージョンでは少し上げるかもしれません。(^^)
私の感覚ではCG20同等以上という感じがしますので、Ptune2同様にどんどん上げていってエラーの出た周波数から1段PLLを落とした周波数が安定限界というところでしょう。

ちなみに、現状CG50では[F4]からCPUクロックを上げるのはあまり高速化に寄与しないので、[F5]でぎりぎりまで上げるのが一番速くなります。
メモリテスト後にバス速度の限界が自動的にセットされるので、
(セットアップのBus CLK Max値)
安全な範囲でオーバークロックが出来ます。
管理人様の個体ではPLLで28倍まで、CPU周波数で206MHzまで上げられると思います。(^^)


>※ RAMとROM いずれのメモリチェックでも見かけ上エラーや問題は起きませんでした。

いきなりエラーが出てしまうと結構焦るところですけど、無事完了できて良かったです。
ただ、現在のメモリチェックは若干不安定になることがあって、
どこかシステム領域(RAM)に変な書き換えが発生している可能性があるので、
メモリテスト使用後、Ptune3を抜けた後に一度リセットして再起動しておいた方が安全確実です。


で、メモリテストはうちの個体の結果は以下のとおりです。
ROMの方はほぼ同じ結果ですね。
SDRAMが5%ほど結果が違っていますがこのあたりはSDRAMチップの個体差というところでしょうか。
------------------------------
roRw0: 15.44MHz
roRw1: 26.12MHz
roRw2: 36.28MHz
roRw3: 46.61MHz
roRw4: 56.60MHz
roRw5: 67.05MHz
roRw6: 77.64MHz
roRw8: 98.57MHz
roR10: 118.30MHz
roR12: 135.27MHz

SDRAM: 111.68MHz
Write: 104.36MHz
------------------------------

SDRAMが120MHz以上に上げられるとデフォルトからちょうど2倍にオーバークロックできるところなのですが、ここが今後の課題ですね。

Ptune3 v0.05 取り敢えず 250.87MHz はOK

sentaro様

早速、Ptune3 v 0.05 を入れてみました。

チョットこわごわ触っています。

※ RAMとROM いずれのメモリチェックでも見かけ上エラーや問題は起きませんでした。

※ [F4] で235 MHzにした後、[SHIFT] [↑] で FLL を選び、250.87 MHz にし、[F5]に保存。

※ 続いて FLL を1ステップ増やすと、CPU クロック表示が青バックから赤に変わりました。

※ 1つ戻して [F5]に保存した 250.87 MHz で使っています。

この赤バックの表示は、何を教えてくれているのでしょうか?

ちなみにメモリチェック結果は以下のようになっています。

roRw0: 15.44MHz
roRw1: 25.58MHz
roRw2: 36.45MHz
roRw3: 45.99MHz
roRw4: 56.21MHz
roRw5: 66.21MHz
roRw6: 76.94MHz
roRw8: 97.90MHz
roR10: 117.67MHz
roR12: 134.69MHz

SDRAM: 105.99MHz
Write: 99.99MHz
最新記事
検索フォーム
最新コメント
カテゴリ
C# (3)
Visitors
Online Counter
現在の閲覧者数:
プロフィール

やす (Krtyski)

Author:やす (Krtyski)
since Oct 30, 2013


プログラム電卓は、プログラムを作って、使ってナンボ!

実際に触って気づいたこと、自作プログラム、電卓プログラミングについて書いています。

なお管理人はカシオ計算機の関係者ではなく、Casio Basicが面白いと感じる1ユーザーです。


写真: 「4駆で泥んこ遊び@オックスフォード郊外」

リンク
月別アーカイブ
Sitemap

全ての記事を表示する

ブロとも申請フォーム

この人とブロともになる

QRコード
QR