管理人様、Colon様、iron2様、CGオーバークロッカーの皆様、こんにちは！
Colon様、
＞C.Basic はアイコンの数が多く電卓だけで作るのは無理がありそうなので、
＞効率的にアイコンを製作すべく Excel を組み合わせて作業中です。
Ptuneに比較すると大変かと思いますが、よろしくお願いします。(^^)
＞メッセージは各言語ごとにまとめて導入する必要がありそうなので、ファンクションメニューが一段落してからになるでしょうか。
はい、
メッセージの言語対応はもう少し先になるかと思いますので、そのときまでにお願いできましたら幸いです。(^^)
＞ただ、[F6] (MENU) を押すとメニュー言語の切り替えが出来るようになります。
うわ、この右端のはそういう機能だったんですね、って今はじめて知ったかもしれません。(^^；
ってことで、
Ptune2/3、ともに潜水モードでこっそりと差し替えしております。(^^；
管理人様、sentaro様、iron2様、CGオーバークロッカーの皆様、こんにちは！
sentaro様、
＞ 了解です！
＞ アイコンデータさえあればいいので、そっくり流用します。(^^；
はい！
C.Basic はアイコンの数が多く電卓だけで作るのは無理がありそうなので、
効率的にアイコンを製作すべく Excel を組み合わせて作業中です。
＞ と同時にメッセージ関連の多言語対応もしていきたいですね。
そうですね。
メッセージは各言語ごとにまとめて導入する必要がありそうなので、ファンクションメニューが一段落してからになるでしょうか。
＞ あ゛…メッセージとメニューって個別に設定が出来たんですね。(^^；
＞ メッセージとメニューの言語を別々に設定することが純正機能で出来るのかどうかがちょっと分かってなかったりしてます。(^^；
＞ 言語設定では両方同時に切り替わりますよね？
メッセージ言語設定で中国語以外を選択すると自動でメニュー言語が英語になります。また、中国語を選択すると自動でメニュー言語が中国語になります。
ただ、[F6] (MENU) を押すとメニュー言語の切り替えが出来るようになります。
従って、例えばメッセージは中国語、メニュー言語は英語、などということができます。
管理人様、
＞
内部動作については触れずに、さらっとアップデートのアナウンスをするに留めました。
＞ システムコール絡みなので、敢えて触れなかったという次第。
＞ 但し、SysCallを使わなくても、C.Basic にある SysFunc( 関数でアイコンを使えるので、それに絡めてファンクションメニューのアイコンデータを使えるという内部動作の説明に触れた方が良いでしょうか？
アイコンのデザイン変更だけで操作方法自体に大きな影響はないので、詳しいアナウンスは無くても構わないと思います。
・ OS にないファンクションキーメニューのアイコンを純正同様のデザインにした。
・ C.Basic for CG でも将来的に対応する予定。
と説明するぐらいであれば SysCall に触れずにすむと思いますが、後は管理人様にお任せします。(^^)
管理人様、Colon様、iron2様、CGオーバークロッカーの皆様、こんにちは！
管理人様、
＞そんな中、高速化と安全性を両立したオーバークロックツールで、SH4搭載機では軽く１０倍速を実現するのですから、本当に素晴らしいです。fx-9860G / 9860GII シリーズでＯＳアップデートを重ねるごとに、どんどん遅きなる中で、一番ダメな子 9860GII -2 (SH4)が、Ftune2 により一番出来る子に早変わりです。
SH3では最速でも2倍速までなので、さすがに10倍速となると、驚異のオーバークロック性能ですね。(^^；
Ptune2/Ftune2が出来あがるまでにはそこまで上げられるというのは予想もしてなかったですが、
危険度100％の危ないツールから、安定性もある程度確保できるツールとして出来上がったのはとても良かったと思います。(^^)
ただ、CG50用のPtune3ではその限界安定性が若干確保しづらい状況なのでなんとかしていかねばなりません。
iron2様、
＞私のfx-cg50nはリセットかからず310MHzまでオーバークロックできました。
管理人様に続いて300MHzオーバーですね！
これでサンプル数6台のうち4台まで300MHz超えですから、かなり高確度で300MHzいけちゃいそうですね。
＞しかし、みなさまのご指摘通り、bfc1/4のcpu２１２MHｚのほうが
＞高速でした。ｂｆｃｂｆｃ106MHz,pfc1/16 26.52MHzです。
やはり、そうですよね。
300MHz超えてもそれが宝の持ち腐れになっているのが現在のCG50ですが、なんとかバスクロックを150MHz程度まで引き上げてみたいものです。
＞お騒がせしました。すみませんでした。
いえいえ、
300MHzオーバーの検証も出来ましたし、結果オーライですね。(^^)
Colon様、
メッセージとメニューの言語を別々に設定することが純正機能で出来るのかどうかがちょっと分かってなかったりしてます。(^^；
言語設定では両方同時に切り替わりますよね？
管理人様、sentarou様、colon様、読者様、ユーザー有志の皆様へ
私のfx-cg50nはリセットかからず310MHzまでオーバークロック
できました。
しかし、みなさまのご指摘通り、bfc1/4のcpu２１２MHｚのほうが
高速でした。ｂｆｃｂｆｃ106MHz,pfc1/16 26.52MHzです。
お騒がせしました。すみませんでした。
sentaro様、Colon様、iron2様、CGオーバークロッカーの皆様、
管理人のやすです。
sentaro様
アップデート対応しました。
https://egadget.blog.fc2.com/blog-entry-593.htmlhttps://egadget.blog.fc2.com/blog-entry-153.html> オーバークロッカーというと、PC業界用語だと思うんですけど、今どきのPCだとせいぜい10％程度しか上がらないのですが、
> SH4A電卓のオーバークロックは200％以上が当たり前の世界ですからとんでもないレベルですね。(^^；
かなり昔おことですが、MS-DOS時代のC言語用のグラフィックライブラリを自作して、自分で使ったことがありますが、余計な処理を出来るだけ減らして描画に必要な要素に特化した、チョット危ないライブラリでした。高速化にはリスクがあるというのを、そのとき自分で体感したものです。
その後、Windowsプログラム用にシリアル通信ライブラリを自作して使ったことがありますが、その際は高速化と絶対に止まらないことの両立を目指しました。エラーは潔く認めてエラー発生ステイタスを送信しつつ、自動でリセットして通信は切れないというコンセプトでした。汎用ライブラリには怖くてできませんが、自分専用なら使えるレベルでした。速度とエラーのシーソーゲームをここでも体感したものです。
そんな中、高速化と安全性を両立したオーバークロックツールで、SH4搭載機では軽く１０倍速を実現するのですから、本当に素晴らしいです。fx-9860G / 9860GII シリーズでＯＳアップデートを重ねるごとに、どんどん遅きなる中で、一番ダメな子 9860GII -2 (SH4)が、Ftune2 により一番出来る子に早変わりです。
新しいおもちゃを買って貰った子供の頃の気持ちを思いだしたものです。
Colon様
内部動作については触れずに、さらっとアップデートのアナウンスをするに留めました。
システムコール絡みなので、敢えて触れなかったという次第。
但し、SysCallを使わなくても、C.Basic にある SysFunc( 関数でアイコンを使えるので、それに絡めてファンクションメニューのアイコンデータを使えるという内部動作の説明に触れた方が良いでしょうか？
iron2様、
sentaro様がお書きになっていますが、メモリバスクロックを高速化するのが一番効果が出るので、BFC 1/4 を維持したまま高速化を検討するのが、実際の処理速度に最も効果が得られるようです。内部演算がボトルネックとなるような場合にのみ、PLLの高速化が支配的に効果が出ることがあるのも経験しています。
管理人様、Colon様、iron2様、CGオーバークロッカーの皆様、こんにちは！
Colon様、
＞「オーバークロッカー」ってかっこいい!!
オーバークロッカーというと、PC業界用語だと思うんですけど、今どきのPCだとせいぜい10％程度しか上がらないのですが、
SH4A電卓のオーバークロックは200％以上が当たり前の世界ですからとんでもないレベルですね。(^^；
＞まず、違和感なく表示できており、安心しました。
＞大丈夫そうであれば、同じアルゴリズムを C.Basic に流用する方向でいかがでしょうか？
了解です！
アイコンデータさえあればいいので、そっくり流用します。(^^；
と同時にメッセージ関連の多言語対応もしていきたいですね。
＞それから、"Ptune2_fkeyicon.c" の "Is_Chinese()" の部分ですが、現状はメッセージ言語の確認になっており、
＞・ メッセージ英語 / メニュー中国語
＞・ メッセージ中国語 / メニュー英語
＞のような場合に対応できておりません。
あ゛…メッセージとメニューって個別に設定が出来たんですね。(^^；
＞ファンクションメニューの言語の確認には、SysCall 0x12F1 が利用できます。
＞これはメニュー言語の番号を返す SysCall で、引数はありません。
＞C.Basic 風に書くと、
＞・ SysCall(0x12F1)=0 → 英語
＞・ SysCall(0x12F1)=1 → 中国語
＞・ SysCall(0x12F1)≧2 → アドイン言語
＞となっています。
＞一応 CG50 でも動作確認を行った上で使用していただければと思います。
ありがとうございます！
Ptune系ではとりあえずファンクションキーの対応だけでいいと思いますが、
メッセージも多言語対応するとなれば両方必要になるわけですね。(^^)
iron2様、
＞私のｆｘ－ｃｇ５０ｎではｐｌｌが３２倍でそれ以上上がりません
CPUが省電力化されたのは良かったんですが、何やらPLLに制限が入りました。(^^；
＞そのためｂｆｃを1/8にしてもfllが上がりきらずcpuクロックが247MHz
＞までしかあがらずcpuクロック２１２MHｚ、sfc,bfcともに1/4のときの
＞ほうがテキストの描画やシダcgの描画が早いです。
＞ftune323での結果です。
CG50でCPUクロックを上げるには、セットアップでCPU CLOCKの制限値を300MHz以上に上げてから、
プリセットの[F4]を押してから[SHIFT]+[↑]、PLLより一行上のFLLで周波数を上げていきます。
290MHz前後までは問題なく動作すると思いますが、そこから先は運次第です。(^^；
BFCが1/4で212MHzまで上げられるなら、おそらくその設定が一番速いです。
ほとんどの場合は、BFCが速い方が良い結果が得られますね。(^^)
管理人様、sentarou様、ユーザー有志の皆様へ
私のｆｘ－ｃｇ５０ｎではｐｌｌが３２倍でそれ以上上がりません
そのためｂｆｃを1/8にしてもfllが上がりきらずcpuクロックが247MHz
までしかあがらずcpuクロック２１２MHｚ、sfc,bfcともに1/4のときの
ほうがテキストの描画やシダcgの描画が早いです。
ftune323での結果です。
管理人様、sentaro様、CGオーバークロッカーの皆様、こんにちは！
「オーバークロッカー」ってかっこいい!!
ということはさておき、(^^;
sentaro様、
アイコン対応ありがとうございます！ (^^)
まず、違和感なく表示できており、安心しました。
大丈夫そうであれば、同じアルゴリズムを C.Basic に流用する方向でいかがでしょうか？
それから、"Ptune2_fkeyicon.c" の "Is_Chinese()" の部分ですが、現状はメッセージ言語の確認になっており、
・ メッセージ英語 / メニュー中国語
・ メッセージ中国語 / メニュー英語
のような場合に対応できておりません。
ファンクションメニューの言語の確認には、SysCall 0x12F1 が利用できます。
これはメニュー言語の番号を返す SysCall で、引数はありません。
C.Basic 風に書くと、
・ SysCall(0x12F1)=0 → 英語
・ SysCall(0x12F1)=1 → 中国語
・ SysCall(0x12F1)≧2 → アドイン言語
となっています。
一応 CG50 でも動作確認を行った上で使用していただければと思います。
管理人様、CGオーバークロッカーの皆様、こんにちは！
ファンクション表示のアイコンを、
Colon様より提供していただいたアイコンに差し替えました。(^^)
それ以外の変更ありません。
for fx-CG10/20
https://pm.matrix.jp/Ptune2_123.zipfor fx-CG50 / Graph 90+E
https://pm.matrix.jp/Ptune3_023.zip.Colon様提供のアイコンデータによりファンクションキーの表示を改善しました。
管理人様、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.txtteamfx氏のプロダクトコード解析文書によれば、
最後が製造年月日のようで、
2007年5月10日製というところでしょうか。
ちなみに私のSlimでは
G366-71
A128147
7Q0528 R/H
なので、
管理人様のと同じ製造月ですね。(^^)
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
ここから、どうやって製造月を割り出すのでしたっけ？
管理人様、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お！これまたピッタリで良い感じですね。(^^)
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管理人様、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.zipsentaro様、FX/CGオーバークロッカーの皆様、
管理人のやすです。
Ftune (SH3) Ver 1.20 ですが、System の Verion でバージョン表示が 1.10 のままになっています。
ご確認ください。
管理人様、FX/CGオーバークロッカーの皆様、こんにちは！
＞あ、そうでした。
＞間違いです。
実際に、9860Gは補正無しだと0.5Vくらい低く出るので、
ひょっとして更新ミスかと焦ってたので一安心です。(^^)
sentaro様、FX/CGオーバークロッカーの皆様、
管理人のやすです。
> もしかして、0.5Vの違いじゃなく0.05Vだったのでしょうか？(^^；
あ、そうでした。
間違いです。
管理人様、FX/CGオーバークロッカーの皆様、こんにちは！
＞・Ftune2 の電圧値：4.78v
＞・C.Basic Ver の電圧値：4.8v
＞・BattryStatus：4.83v
＞５回ほど調べて、絶対値は0.5v の範囲で変動、しかし上の３つの順序の傾向は同じです。
＞9860GII SD のOSは 2.09 です。
もしかして、0.5Vの違いじゃなく0.05Vだったのでしょうか？(^^；
電圧を測る時点での消費電流の大きさで多少の変動が起きるので、
誤差約1％ということで、そういう感じの差ではないかと思われます。(^^；
オーバークロックすると電圧が若干下がるのも同じ原因ですね。
sentaro様、FX/CGオーバークロッカーの皆様、
管理人のやすです。
> あとは、実際の電池電圧と合ってるかどうかですね。
あとで調べておきます。
> ＞電圧は、どこか別のところに表示されるのでしょうか？
>
> Ftune2ではセットアップ（一番下）でバージョン表示と電圧表示が選択できるようになっています。(^^)
なるほど．．．ということて電圧確認できました。
で、
・Ftune2 の電圧値：4.78v
・C.Basic Ver の電圧値：4.8v
・BattryStatus：4.83v
５回ほど調べて、絶対値は0.5v の範囲で変動、しかし上の３つの順序の傾向は同じです。
9860GII SD のOSは 2.09 です。
管理人様、FX/CGオーバークロッカーの皆様、こんにちは！
＞一気にやろうと思わないと、とても厄介でやる気にならないですよね。
＞お疲れ様です。
機種によってはバネが強くて電池の出し入れが大変でした。
CG10/20とか結構きついですね。(^^；
＞ドンピシャ一致しました！
ありがとうございます！
あとは、実際の電池電圧と合ってるかどうかですね。
＞電圧は、どこか別のところに表示されるのでしょうか？
Ftune2ではセットアップ（一番下）でバージョン表示と電圧表示が選択できるようになっています。(^^)
＞x-9860G でもテストしてみたところ、Ftune v1.20 が C.Basic よりも0.4 ～ 0.5V 程度低く表示されます。
こちらでのテストでは、
v1.05とv2.01で違いは無かったのですが、あり？？？
OSバージョンはどうなってますでしょうか？
sentaro様、FX/CGオーバークロッカーの皆様、
管理人のやすです。
fx-9860G でもテストしてみたところ、Ftune v1.20 が C.Basic よりも0.4 ～ 0.5V 程度低く表示されます。
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]のバージョン表示にも電圧表示がありません。
電圧は、どこか別のところに表示されるのでしょうか？
管理人様、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に関しては補正値が結構大きいので、
誤差の範囲に収まっているかどうかは管理人様頼みです。(^^；
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は変更なしです。
お疲れ様です、記事に反映させました。
> 全機種で誤差±３％を目指していますが、個体差でずれる場合もあります。(^^；
今日、CG20, CG50 で C.Basic との誤差が±5% 以上あったので、アマループをフル充電して再度テストしたのですが、誤差が縮まりませんでした．．．．と報告しようと思ったら、既に調整バージョンがアップされていました。
いつもながら仕事が速いですね！
管理人様、FX/CGオーバークロッカーの皆様、こんにちは！
C.Basicの電圧表示アップデートに伴い、表示値が微妙にずれたので、
すべてC.Basicと同じ電圧値となるべく合わせるために更新です。(^^)
for fx-9860G/GII/Slim (SH3)
https://pm.matrix.jp/Ftune_120.zipfor fx-9860GII (SH4A)
https://pm.matrix.jp/Ftune2_120.zipfor Graph 35+E II (SH4A)
https://pm.matrix.jp/Ftune3_220.zipfor fx-CG50 / Graph 90+E
https://pm.matrix.jp/Ptune3_022.zipPtune2は変更なしです。
全機種で誤差±３％を目指していますが、個体差でずれる場合もあります。(^^；
管理人様、fx-CG50オーバークロッカーの皆様、こんにちは！
C.Basic for FXで電圧表示が出来るようになったことで、
電卓間の表示値の相違を出来るだけ無くすために
若干低めの表示だったCG50の値を修正しました。
Ptune3 ver0.22 (電圧表示値修正版)
http://pm.matrix.jp/Ptune3_022.zip
電圧表示値を10％上方修正しました。
管理人様、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動作が大丈夫そうですね。
とはいえ、ぎりぎりの状態に近づくのでここはあまり無理をしない方が良さそうです。(^^)
sentaro様、fx-CG50オーバークロッカーの皆様
> これは最近新しくCG50ユーザーになられた方が増えたという感じでしょうか。(^^)
CG50を検索キーワードで来られる方は、第二位です。
なので、CG50ユーザーの閲覧は確実に増えていることになります。
そして、Ptune3とC.Basic記事の閲覧も増加傾向です。
ちなみに第一位は fx-5800P で、CcLinker記事への閲覧が増えています。
一方で、当ブログのメインテーマである純正Casio Basicの記事へのアクセスが圧倒的に多いわけですが、CcLinkerで転送できるファイルをダウンロードできるように徐々に拡充しています。もっと増やさないとダメだな、と思っています。
> 電卓は動作周波数も低く省電力なのでそのあたりはあまり影響は無かったとはいえ、
> CG50で100MHz超えになったので、各国の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超えとなります。(^^)
ま、無理せずにゆるゆると試してみようと思います。
管理人様、fx-CG50オーバークロッカーの皆様、こんにちは！
管理人様、
＞ここ一ヶ月の傾向で、FtuneやPtuneの記事へのアクセスがいつもよりも多い傾向です。
ぉお！？
これは最近新しくCG50ユーザーになられた方が増えたという感じでしょうか。(^^)
＞記事での対応は済ませておりますが、手元でのファイルの差し替えをしておきます。
いつも素早い対応してくださって感謝です。m(_ _)m
＞スペクトラム拡散は、PLLの周波数関連ですよね？
はい！
電卓は動作周波数も低く省電力なのでそのあたりはあまり影響は無かったとはいえ、
CG50で100MHz超えになったので、各国のEMI規格を通過するには無視できないレベルになってきたのかもしれません。
＞私の２台の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超えとなります。(^^)
sentaro様、fx-CG50オーバークロッカーの皆様
管理人のやすです。
ここ一ヶ月の傾向で、FtuneやPtuneの記事へのアクセスがいつもよりも多い傾向です。
> (2019.2.21追記）
> 起動時のスペクトラム拡散のチェックに一部不具合がありましたので、
> 修正後、再アップしております。(^^；
記事での対応は済ませておりますが、手元でのファイルの差し替えをしておきます。
スペクトラム拡散は、PLLの周波数関連ですよね？
私の２台のCG50 は幸運にも 300MHz 超えが可能ですが、今回のスペクトラム拡散対応は、表示だけの変更ですか？
300MHz ギリギリのところで、実動作への影響として注意点は何かありますでしょうか？
管理人様、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追記）
起動時のスペクトラム拡散のチェックに一部不具合がありましたので、
修正後、再アップしております。(^^；
管理人様、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の方でウエイト削減しているとほとんど効果が出ないので、
ここは基本的にすべてデフォルト値でいいと思います。(^^)
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よりは若干甘めの設定になっております。(^^)
管理人様、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の方で設定されます。
総じてメモリウエイトの設定なので少ない方が速いということになります。
クロック設定が同じでベンチマーク結果が違う場合は、
ここの値の違いが効いてますね。(^^)
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値は変化しませんでした。これはそういう仕様なのでしょうか？
管理人様、Ptune3ユーザーの皆様、こんにちは！
管理人様、再度の検証ありがとうございます！
何か一気に結論が出たような気がしますね。(^^)
＞．．．ということで、2号機異常説或いは1号機異常説のどちらが有力でしょうか？
１号機と２号機に違いが出ず同じ変化具合、同じベンチマーク結果ということは
どちらも正常というしかありません。(^^)
今までの相違は、Ptune3の本体に記憶された設定ファイルが違っていたので、
オーバークロックで設定値が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から上げていくのが効率的かつ間違いがないといえます。(^^)
sentaro様、Ptune3ユーザーの皆様
[11:30 追記1、末尾]
[11:50 追記2、冒頭]
[12:00 追記3、末尾]
管理人のやすです。
sentaro様のお考えを正しく理解していなかった恐れがあるので、改めて以下のような実験をしてみました。
[追記2]
詳細は以下をご覧頂くとして、面白いことが分かりました。
1. クロック設定の道筋が異なると FRQCR の値が異なる
2. FRQCR の値と LIFE074Pベンチマーク結果に強い相関性がある
3. 上の2つの項目は、1号機でも2号機でも確認される
先ず、１号機、２号機ともPtune3の設定ファイルを削除して初期化します。
次に、メモリチェックなしで、SETUP設定のみ変更し、CPU CLK Max を 310.17 MHz、Sh1 CLK Max を 160.50 MHz に変更し、他はデフォルトのままにしておきます。
※注：管理人のfx-CG50 ２台は運が良いことに高いCPUクロックが出せる個体なので、ここをお読みの他の方は、いきなりこのような設定にはしないでください。慎重に設定を変更する必要があり、最悪電卓のCPUを壊したり、ROMの内容が破壊される可能性があります。
[F5]プリセットを選択後
ノーマルクロックでの[VARS] - [F1] (FRQ) での表示
１号機 ２号機
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) にした時は、
１号機 ２号機
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になって、
１号機 ２号機
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になると、
１号機 ２号機
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になると、
１号機 ２号機
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 になると、
１号機 ２号機
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 になると
１号機 ２号機
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 になると、
１号機 ２号機
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 になると、
１号機 ２号機
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値の安全性が気になります。
管理人様、Ptune3ユーザーの皆様、こんにちは！
＞２号機の値のTypoでした。失礼しました。正しくは、
＞ １号機 ２号機
＞ FRQCR： 1F011213 FRQCR： 1F001203 ←異なる
＞となります。
了解しました。
ってことは、
1F001203
が[F5]プリセットでの元々の設定値なので、
2号機は正常値で1号機が異常値となりますが、
1号機のノーマルから290MHz以下の部分で、どうなっているかお知らせいただけるでしょうか？
もしかしたら、1号機も300MHz設定で何かしらの異常が起きてる可能性があります。(^^；
＞２号機は、１号機の内容のバックアップをそのままコピーして使い始めたので、その影響があるのかも知れません。
＞一応、RAMとROMのテストをしてから、上限値の設定を確認し、それから個別の設定を行ってはいるのですが．．．
＞そこで、２号機で、Ptune3の設定ファイルを削除して初期化してから、再度確認してみます。
メモリ速度差の影響を排除するために、
設定ファイル削除後はRAM/ROMテストはしない状態で上限値設定だけでお願いします。(^^)
＞なお、Skip異常も関連の可能性有りということで、２号機のレジストに異常値が設定されていることが根本にありそうってことは、一連の不思議な現象を理解し易くなりますね。
はい、
異常値になって誤動作していたということであれば原因はそこにありますね。(^^)
sentaro様、Ptune3ユーザーの皆様
[追記 19:50]
管理人のやすです。
ご指摘ありがとうございます。
> ＞FRQCR： 1F011213 FRQCR： 1F011203 ←異なる
>
> ここですが、もしかして、1号機と2号機は逆ではないでしょうか？
> 1F011213は、設定データとしてはあり得ない数値なので、
> 正常動作の1号機の数値としてあっているかどうかというところです。
[19:50 追記]
1F011213は、設定データとしてはあり得ない数値とのことですが、１号機で300MHzにすると間違い無くこの数値になっています。
２号機の値のTypoでした。失礼しました。正しくは、
１号機 ２号機
FRQCR： 1F011213 FRQCR： 1F001203 ←異なる
となります。
２号機は、１号機の内容のバックアップをそのままコピーして使い始めたので、その影響があるのかも知れません。
一応、RAMとROMのテストをしてから、上限値の設定を確認し、それから個別の設定を行ってはいるのですが．．．
そこで、２号機で、Ptune3の設定ファイルを削除して初期化してから、再度確認してみます。
なお、Skip異常も関連の可能性有りということで、２号機のレジストに異常値が設定されていることが根本にありそうってことは、一連の不思議な現象を理解し易くなりますね。
管理人様、Colon様、Ptune2/3ユーザーの皆様、こんにちは！
Colon様、
＞1ヶ月前からすっかり存在を忘れていたのですが、(^^;
＞Ptune用のファンクションメニューのデザインのサンプルで、一応これでよいかの確認です。
ありがとうございます！
で、アイコン画像拝見させていただいた限りでは、文句なく良いです。(^^)
アイコンをビットマップデータとして表示するだけならこのままいけそうですね。(^^)
管理人様、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アイコンテーブルと表示ルーチンまではまだ行けていません。
途中経過として報告します。
sentaro様、Colon様、Ptune3ユーザーの皆様
管理人のやすです。
C.Basic for CG のエディタ異常については、C.Basic のエントリーに移動してコメントが続きましたが、以下のコメントで一応の結論がでました。
https://egadget.blog.fc2.com/blog-entry-664.html#comment3789sentaro様、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] なので、それも合わせて調べたところ、これは相違なしでした。
ご参考になりましたか？
sentaro様、Ptune3ユーザーの皆様
管理人のやすです。
書き忘れたのですが、今回の動作速度の件では、C.Basicのアドインファイルに異常は無かった模様です。
というのも、最初にsentaro様に言われた通り、USB接続で アドインファイルをコピーし直しましたが、Editorでの異常と1号機と2号機での実行速度が異なるという症状が再現されました。
2号機のエディタ異常は、設定ファイルクリア＆電源ON/OFFで解消。
1号機の実行速度が遅い件は、1号機にある設定ファイルのクリア＆電源ON/OFF で解消。
前のコメントでは、ここのところが曖昧な表現でした。すみません。
Colon様、sentaro様、
管理人のやすです。
> 多分、v0.54とv0.55のところで問題が発生しています。
今回の C.BasicのEditor動作異常ですが、実行速度の異常も関連しているかも知れないといった状況なのです。
SET UP 非互換性と動作スピードは、関連あるのか？が、目下の興味の的です。
実行時に、頻繁にSET UP情報のファイルを読み込んだり、一旦実行領域に書き出したものを参照しているならば、セットアップ情報の非互換性の影響を受けそうですね。
管理人様、sentaro様、
＞皆さんのところではこの問題が発生しなのか？
＞私との唯一の違いは、私は Ver 0.47αから一気に 0.56αに上書きしたことです。
多分、v0.54とv0.55のところで問題が発生しています。
v0.48以降、アドイン名がバージョン番号を含むようになっているので、異なるバージョンを混在させてチェックできるようになっていますが、
私のところではv0.54以前とv0.55以降の間で不具合が発生することがあります。
一度sentaro様に対策していただいて発生することは減りましたが、それ以降もまだ発生する場合があるようなので、それかもしれません。
@CBASICフォルダ内のファイルの構造を開示していただけると、今後のバージョンでの対策がとりやすいと思います。＞sentaro様
sentaro様、Ptune3ユーザーの皆様
管理人のやすです。
結論から言えば、C.Basic を正常に戻せたら、1号機と2号機でのLIFE074P の動作速度が同じになりました。
さて、メインメモリの@CBASIC フォルダを消去し、C.Basicを起動。これだけではエディタの異常動作は収まらず、一旦電源を切って再起動したら、Editorの動作が正常になりました。
皆さんのところではこの問題が発生しなのか？
私との唯一の違いは、私は Ver 0.47αから一気に 0.56αに上書きしたことです。
ご確認頂けますか？
管理人様、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を初期化するのはまだ試していないことに、今気がつきました。あとでやってみます。
あ゛…その可能性もありそうです。(^^；
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を初期化するのはまだ試していないことに、今気がつきました。あとでやってみます。
管理人様、Ptune3ユーザーの皆様、こんにちは！
＞2号機で 310MHz動作、特に問題なさそうでした。
おおお！310MHz！！！
うちのCG50で300MHz超えは2号機だけなのですが、最高306MHzですからCG50の最高記録ですね！(^^)
＞LIFE047 でプリセットパターン＃3の517世代までの時間は、74.26秒でした。
各種プログラムでベンチマークを取るとはっきり分かると思いますが、2号機ではSDRAM限界が低めなので、
[F5]でバスクロックを上げるオーバークロックよりも[F4]でCPU最高周波数を狙う方がいいのかもしれませんね。(^^)
＞次に1号機で同様にCPUクロックを上げてみると、結論は上と全く同じ設定の 310MHz あたりが上限でした。
うわうわ！
なんと！１号機も300MHz超え、それも揃って310MHz！
管理人様のCG50は大当たり連発だったのですね。(^^)
＞これを超えると、2号機と同様にキーの反応が悪くなります。さらに2号機では観られなかったエラー(リセット要求)が現れます。
うちの個体でも限界付近ではキー反応が悪くなって表示系に異常が出てきたりします。
おそらく１号機の方が若干CPU限界が低いものと考えられます。
どちらにしても310MHz付近まで上げられるとなると、
300MHzは問題なく安定動作するはずです。(^^)
＞1号機はSDRAM最大クロックは 105MHzで、2号機よりも5％程度高いのですが、SDRAM耐性、あるいは I/Oの耐性 が低いのかな、と感じられます。
＞同様に、LIFE074 で同じベンチマークをすると、80.73秒と明らかに2号機より遅い結果でした。
あり？(^^；
分周比、メモリウエイト等、パラメータの設定値、C.Basicのバージョン、動作プログラムが全く同じとするとちょっと奇妙な話ですが、
これはCPUが限界周波数付近で異常動作を起こしているという可能性があるでしょうか。
310MHz動作でもSDRAMクロックは80MHz以下なので、メモリの耐性はどちらも全く問題が無いと思われますので、
CPUが310MHz付近でいろいろと限界動作（キャッシュアクセスエラー等）になっていると考えられます。
両機とも確実に安定動作する300MHzにして再度ベンチマーク比較をしてみてください。
sentaro様、Ptune3ユーザーの皆様
管理人のやすです。
1号機、2号機ともに 310 MHz設定は Ptune3 Ver 0.20 を使っています。
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の違いなのか、他に要因があるのか？
チョット面白い結果になりました。
管理人様、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オーバー達成ですね。(^^)
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でもまだ余裕がありそうです。
管理人様、Ptune3ユーザーの皆様、こんにちは！
＞これ以上、上げてゆく場合、留意点があれば、教えてください。
メモリ速度は97MHzぐらいが限界とわかっているので、CPU以外は全然余裕です。(^^)
FLLはx1024で赤文字にはなりますが、最高値の2047まで普通にいけてしまうので1200程度なら余裕で大丈夫です。(^^)
メモリクロックは上げすぎるとROM破損の可能性も出てきますが、
[F4]プリセットの場合、メモリ限界よりもFLL限界よりも先にCPUが限界に達しますから、リセット覚悟で試してみてください。(^^；
セットアップの限界クロック設定をデフォルトの270MHzから段階的に引き上げていくのが安全ですね。
メモリの耐性とCPUは別物ですから、ひょっとしたら300MHzいけるかもしれません。
ただひとつ気をつけるべき注意点としては、実験中は決してUSB接続をしないこと、これだけです。
＞以上を追記しました。
ありがとうございます！
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の設定をストレージに自動バックアップ保存しておく。
> というのを追加していただければいいかと思います。(^^)
以上を追記しました。
管理人様、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の設定をストレージに自動バックアップ保存しておく。
というのを追加していただければいいかと思います。(^^)
ストレージに自動バックアップ保存された設定は、リセットすることで復活するので、
クロック上げすぎて暴走しても再設定の手間が省けます。(^^)
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 の方がプログラム実行はかなり速くなっています。
そして、この設定で結構安定しています。
> 今後メモリクロックが上げられる裏技が発見される可能性もあるので、
> それまでは出来るだけ安全運転で使用されることを推奨します。(^^)
はい、安全第一ですね！
なお、記事本文に、使用例を追加しましたが、問題や修正した方が良い点があれば、教えて頂けませんか？
管理人様、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とあまり変わらない可能性もありますね。(^^)
今後メモリクロックが上げられる裏技が発見される可能性もあるので、
それまでは出来るだけ安全運転で使用されることを推奨します。(^^)
sentaro様、Ptune3ユーザーの皆様
管理人のやすです。
> おそらく、SDRAMが100MHz付近で限界になってそうなので、
> それがROMのメモリチェックに影響を与えていると思われます。
>
> ってことで、そこのところをちょこっと修正してみましたのでお試しくださいませ。
>
> Ptune3 ver.0.20（差し替えです）
>
http://pm.matrix.jp/Ptune3_020.zipPtune3 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 の応答が間に合わなくなるための現象ではにかと思われますが、どのように思われますか？
管理人様、Ptune3ユーザーの皆様、こんにちは！
＞roRw10 と 12 で異常な値になります。
＞ひょっとして、何かバグが潜んでいるかも知れないと思っての報告です。
おそらく、SDRAMが100MHz付近で限界になってそうなので、
それがROMのメモリチェックに影響を与えていると思われます。
ってことで、そこのところをちょこっと修正してみましたのでお試しくださいませ。
Ptune3 ver.0.20（差し替えです）
http://pm.matrix.jp/Ptune3_020.zip管理人様の２台目のROMメモリチェックの値は、ちょうど、うちの１台目と２台目の間にあります。(^^)
SDRAMテストは３台目に近いです。
１台目（最高278MHz）
SDRAM:115.25MHz
Write:102.95MHz
２台目（最高305MHz）
SDRAM:112.25MHz
Write:103.14MHz
３台目（最高298MHz)
SDRAM:101.92MHz
Write: 96.35MHz
（※周波数は-1.6％補正後の数値です）
管理人様の２台目の結果と併せると、昨年の個体に比較してSDRAMの耐性は落ちている傾向ですね。(^^；
実周波数が1.6％低くなったので3台目は300MHzオーバーならずになってしまいました。(^^；
＞さて、このような個体ですが、安全性や誤動作しない範囲で、これ以上の高速化の可能性はありますでしょうか？
FLL設定を少しずつ上げるともう少し限界値が上る可能性はありますが、200MHzは難しいかもしれません。
以前はPLLがｘ27だと199.07MHzなので200MHzまではほんの少しだったのですが、
-1.6％になったことが結構効いてきますね。(^^；
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ユーザーの皆様、こんにちは！
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)
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が実装される前には、タイマー変数として % があり、今でも有効です。私は１文字の % を好んで用いています。
> 2倍どころではないです。恐るべし整数演算。
> 実験報告でした。
整数演算は、C.Basic の初期バージョンの目玉でした。さらにバイト数の少ない変数型を設定できるのも目玉の１つで、各種変数型を要素に指定できる行列を使えることになったことで、画面全体をBMPのように行列に格納したり、文字列も内部的には行列に格納して使うような方向で、実装が進んできました。Ｃ言語での文字列の扱いを行列で扱うといった感じと申し上げた方が分かり易いかも知れません。
> 仕事以外
> はお気楽に脳トレぎみに使えるグラフプログラミング
> 関数電卓に興味がわき、数年前からここを
> 覗いています。
管理人が抱いている感覚に近いです。閲覧頂いてありがとうございます。
よろしくお願い致します。
こんにちは、管理人様、 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は同じ設定で４０秒ほどこれでも
腰を抜かしたのですが・・・
2倍どころではないです。恐るべし整数演算。
実験報告でした。
いまのパソコンは昔できなかった事がサクッと
できてしまい。便利なんですがアップデートが
（大すぎ、遅すぎ、容量取りすぎ）で仕事以外
はお気楽に脳トレぎみに使えるグラフプログラミング
関数電卓に興味がわき、数年前からここを
覗いています。
今回のC.Basic for CGを体験したことで
自分的には「〇〇〇はあと１０年は戦える！」
です。いろいろ試してみます。
11月も後１週間ちょい今年も残りわずかになりました。
管理人様、sentaro様、他ここに集う皆様の
活躍、ご健康をお祈りします。
これからもよろしくお願いします。
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.g3m2倍以上高速化するので、オーバークロックしたCG20ならPrimeにも負けないかもしれません。(^^)
まだCG50は出たばっかしですし、CG20ユーザーの方がずっと多いのでCG20対応はしっかりやっていきたいと思います。(^^)
これからもよろしくお願いいたします。
iron2 様
コメントありがとうございます。
> ほんとうに感動しました。
>
> ただの電卓がハンドヘルド
> コンピュータとして実用の
> 速さに達した感が強いです。私も全く同感です！
> ｆｘ-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の一読者として
> これからも応援します。よろしくお願い致します。
こんばんわ、iron2というHNで
はじめて投稿します。
fx-cg20を２３５．９３MHｚにクロックアップし
C.Basic for CG アルファ版
でshidacgを実行したところ
39.23秒で終わりました。
ほんとうに感動しました。
ただの電卓がハンドヘルド
コンピュータとして実用の
速さに達した感が強いです。
ｆｘ-5800p
fx-jp900
fx-cg20
hp-prime
を所持しています
hp-primeが
ノーマルで速いのと
小文字使えるのと
時間計測できるのと
エディターが広いのが
気に入ってますが
CASは癖強い印象です。
ｆｘ-cg20完全対応版
C.Basic for CG を心待ちに
しています。
乾電池４個でこれだけ
できればウハウハです。
乱筆失礼しました。
e-Gadgetの一読者として
これからも応援します。
以上
管理人様、こんにちは！
＞これの効果がどの程度かみてみました。素因数分解と Bugrace (PlotOnで点を打ってゆく) で比較していましたが、処理速度の差が殆どみられませんでした。デフォルトの [F5]の設定です。
す、すみません、比較する時にROMのウエイトが違っていたようです。それでちょこっと速くなっていたと勘違いです。(^^；
OS3.00とOS3.10でCasioBasicで比較すると3.10が速いですが、3.00側のROMのウエイトを減らすと速度差が逆転します。ROMの速度はてきめんに効いてきますね。
(WC34)の設定を詰めるとメモリ速度を測定するとそれなりに有意な差が出てくるんですが、CasioBasicではほとんど差が出ないですね。(^^；
sentaro様
管理人のやすです。
> 3D Graphは最初おおお！って思うんですけど、今は速度比較にしか使ってないかもです。(^^；
そうですか、今度触ってみようと思います。
> [VARS]-[F6](WC34)の設定でTRPの数値を1にすると一段高速化します。
これの効果がどの程度かみてみました。素因数分解と Bugrace (PlotOnで点を打ってゆく) で比較していましたが、処理速度の差が殆どみられませんでした。デフォルトの [F5]の設定です。
管理人様、こんにちは！
＞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に値上がってました。(^^；
そこそこ売れているということでしょうかね。
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台持っていると比較がしやすいですよよね。
管理人様、こんにちは！
＞角の丸い 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のプログラムで比較すると以前のバージョンよりも若干数％程速くなってるようですね。(^^)
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ユーザーの皆様、こんにちは！
fx-CG50国内発売前に一応、ってことで、0.10にバージョンアップしました。
アイコンをCG50スタイルに変更したのとSDRAMチェックの仕様を少し変更したのみで機能的には0.05と変わるところはありません。(^^；
ということで、現状Ptune3では2倍以上の大幅なオーバークロックは出来ないですが、CG50は基本ベースで高速化されているのであまりPtune3の必要性はないかもしれませんね。
http://pm.matrix.jp/Ptune3_010.zipバグや疑問点、何かお気づきの点がありましたらよろしくお願いします。
管理人様、こんにちは！
＞接点パッドをキーが押す機構設計にそもそも問題があるのか、組み付け時工程の問題なのか、その両方の問題ということになりそうです。
おそらくキーが大きくなったので真ん中を真っ直ぐ押し込まないと、キーが斜めに押されてきちんと下部パッドが押されないことがある感じですね。
＞そうですね、現時点は FLLを１段下げておくことにします。
あ゛、、、FLL一段だとかなり微細な下げになるので、PLLですね。(^^；
＞試しに BugTrace (点を１ドット打っておくと画面を埋め尽くす、例のプログラム)を実行しましたが、嫌になるくらい時間がかかりました。埋め尽くす点の位置は、fx-CG9860GII とは違っていましたよ！
点の位置は、Pixelコマンドに互換性がないので致し方ないところですけど、グラフィックスの速度はCG20の頃より激遅なので、それが3倍に速くなったとしてもどうしようもないですね。(^^；
＞いずれにせよ、C.Basic の fx-CG50 への移植が待たれるところです(^^;
純正CasioBasicの速度改善も期待したかったところですけど、ここはやはりPrizm版C.Basicでというところですね。(^^)
fx版C.Basicの課題が続々出てきててそれの更新＆修正作業でちょっと詰まってしまってるので、もうしばらくお待ち下さいませ。m(_ _)m
sentaro様
テンキー [7[ [8] [9] の列以下のキーの取りこぼしについて、右よりを押すと反応しない傾向は、私のところでも確実にあります。
そちらと同じだと分かり、ハズレを引いた訳ではなく、ハードウェアの個性あるいは欠陥のようですね。
接点パッドをキーが押す機構設計にそもそも問題があるのか、組み付け時工程の問題なのか、その両方の問題ということになりそうです。
オーバークロック時にキースキャン時間が短くなる影響も私の感覚と合います。
> ＞ver 0.05 時点では、このあたりが安全な最大速度といった感じですか？
>
> はい！
> たぶん、安定性はだいじょうぶだと思います。
> より安全性をあげるにはそこから一段下げておけば万全ですね。
そうですね、現時点は FLLを１段下げておくことにします。
試しに BugTrace (点を１ドット打っておくと画面を埋め尽くす、例のプログラム)を実行しましたが、嫌になるくらい時間がかかりました。埋め尽くす点の位置は、fx-CG9860GII とは違っていましたよ！
バスクロックをできるだけあげた状態で、せめて 250 MHz くらいまでは出せるといいかな、などと思います。
いずれにせよ、C.Basic の fx-CG50 への移植が待たれるところです(^^;
管理人様、こんにちは！
＞ver 0.05 時点では、このあたりが安全な最大速度といった感じですか？
はい！
たぶん、安定性はだいじょうぶだと思います。
より安全性をあげるにはそこから一段下げておけば万全ですね。
＞チョット気付いたのですが、たまにキーを軽くチョンと叩いた時に、取りこぼしがあるようです。
これは私の個体でも似た感じが発生しています。
キーを押した時にキーの左側に重心がいったときと右側で反応が違っていて、左側は反応がいいですが右側は若干取りこぼし感があります。
これは[EXE]キーだけでなくテンキー部分がほぼそのような感じなので、CG50のハード的個性？欠陥？かもしれないですね。(^^；
＞ひょとして、私の個体で、たまたまキーの接点に問題があるということもありそうです。オーバークロック時にジッタの影響が大きくなろとか、理屈上ありえますか？
オーバークロックしている場合にはキースキャンの時間が短くなるので反応が鈍くなることは考えられますが、
私の個体では全般的に上記のような感じなので右側に偏った軽い押し方だとノーマルでも取りこぼしが頻発する感じがありますね。
CG20ではそのような感じはないので、CG50になってからの新たな問題と言えますが、キー直下のキーパッドの位置が若干ずれて付けられているのかもしれません。(^^；
sentaro様
私の個体では、
※ メモリチェックの結果、SDRAM が 106.98 MHz になっています。
※ アドバイス通り、[F5]の設定から、PLL をあげる
※ さらに FLL をあげてゆくと BFC が 105.51 MHz まであげられました。
※ CPU 211.02 MHz になりました。
バスクロックをあげると、実行速度が確かに向上しました。
ver 0.05 時点では、このあたりが安全な最大速度といった感じですか？
チョット気付いたのですが、たまにキーを軽くチョンと叩いた時に、取りこぼしがあるようです。
再現性が掴めていませんが、ノーマルクロックよりもオーバークロック時に頻度が多くなるようです。
特に [EXE]キーの応答が他のキーに比べて悪い感じです。
ひょとして、私の個体で、たまたまキーの接点に問題があるということもありそうです。オーバークロック時にジッタの影響が大きくなろとか、理屈上ありえますか？
管理人様、こんにちは！
早速の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倍にオーバークロックできるところなのですが、ここが今後の課題ですね。
sentaro様
早速、Ptune3 v 0.05 を入れてみました。
チョットこわごわ触っています。
※ RAMとROM いずれのメモリチェックでも見かけ上エラーや問題は起きませんでした。
※ [F4] で235 MHzにした後、[SHIFT] [↑] で FLL を選び、250.87 MHz にし、[F5]に保存。
※ 続いて FLL を１ステップ増やすと、CPU クロック表示が青バックから赤に変わりました。
※ １つ戻して [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
1984年の折りたたみソーラー電卓 - SL-100
2022/02/11
楽屋裏 - fx-CG50 のチューンアップ - Ptune3
2020/03/28
2018年、プログラミング機能追加の最新動向
2019/06/21
