楽屋裏 - 虫の軌跡 (Bug Trace)

楽 屋 裏 - Bug Trace
e-Gadget

更新 2015/08/14

虫の閉じ込め (Bug Trap) ゲーム - を作ったのですが、動く虫 (=点) を fx-9860GII の応答の遅いLCDではどうも視認性が悪く、もっと面白く遊べないかものかと、思いながらプログラムを色々と実行してみていました。⇒ 視認性向上したバージョンを追加しています。

虫を閉じ込めるには、たった3つのピクセルを以下のように並べるだけで良いこととも分かってきて、シンプルを追求する場合は、あまり発展性がない感じです。なお、視認性が向上したので、複雑で面白い形状を追求する楽しみが増えました。



BugTrap-Pict17 
⇒ ダウンロード: PICT17



一方で、以下のパターンで本当に繰り返しが無いのか、疑問に思えてきました。

BugTrap-Pict19 
⇒ ダウンロード: PICT19



そこで、プログラム BugTrap を改造して、虫の軌跡を残すように変更しました。軌跡を追跡するので プログラム名は Bug Trace です。

改造といっても、プログラム BUGTRAP の以下の赤文字で示した1行を消すだけです。あとはそのままなので、操作方法は全く同じです。捜査方法については 虫の閉じ込め (Bug Trap) を参照してください。

なお、BUGTRAP では外枠を F-Line で描いていたのを、HorizontalVertical に置き換えました。この方が初期描画が速くなります。
※ 実は、F-Line で描画していたのは、描画方向をコントロールしたくて、時計回りに外枠を描画していたのは、お気づきでしょうか?グラフィックスプログラムならではの小さなこだわりでした。


プログラム

ファイル名: BUGTRACE
'==Initialize==
ClrGraph
CoordOn
GridOff
AxesOff
LabelOff
ViewWindow 0,126,0,0,62,0

'==Draw frame==
S-L-Normal
Horizontal 0
Vertical 126
Horizontal 62
Vertical 0


'==Paint mode==
Text 7,3,"EXE/→/↑/←/↓: Draw Wall
Text 13,3,"DEL: Go!"
63→X:31→Y
While 1
While Getkey
WhileEnd
Do
Getkey→K
Text 13,3,"DEL: Go!"
LpWhile K=0 Or K=47
K=44⇒Break
If K=31 Or K=68
Then

Text 13,3,"    " '8 spaces
Plot X,Y◢
Line
IfEnd
WhileEnd
Text 7,3,"             " '25 spaces
Text 13,3,"    " '8 spaces
StoPict 15

'==Draw dot==
62→B:2→A:-1→D:1→C
PxlOn B,A

'==Move dot==
While 1

'✶Set direction
If B=1 Or B=63
Then (-1)D→D
Else If A=1 Or A=126
Then (-1)C→C
Else
PxlTest(B+D,A)⇒(-1)D→D
PxlTest(B,A+C)⇒(-1)D→C
IfEnd:IfEnd

'✶Plot dot
PxlOff B,A   ← 削 除
B+D→B:A+C→A
PxlOn B,A

Getkey=47⇒Break
WhileEnd

'==Normal end
StoPict 16
ClrText
Locate 9,5,"bye!"

⇒ ダウンロード:Casio Basic プログラム BugTrace  [最終 2015/08/14 12:00]

[2015/08/13 追記]
障害物を置いた時の画面コピーを PICT15 に、最終的な軌跡の画面コピーを PICT16 に自動的に保存するように修正しました。 そのために、プログラムコードで 茶色文字で示した2行を追加しています。

[2015/08/14 追記]
sentaro様が、同じ動作をするアドインプログラムを作ってくれました。これで、様々ななパターンの探索を高速に行えるようになるので、皆様も是非お使いください。このアドインプログラムでは、虫 (=点) の描画中に、[EXIT] [MENU] 以外の好きなキーを押せば大幅に描画を高速化します(ターボ機能)。
⇒ ダウンロード: Add-in プログラム Ver1.10 BugTrace.g1a
⇒ ダウンロード: Add-In プログラム Ver1.10 ソース付き BugTrace110.zip

さらに、このアドインプログラムには、これまで作った Drunk BugBug Trap、今回の Bug Trace の3つの Casio Basic プログラムと同等の機能が含まれていて、起動時のメニュー画面で選んで起動できます。それぞれの機能は [EXIT] で終了してメニュー画面に戻ります。

上の Casio Basic プログラムでは、[OPTN] キーで画面コピーの呼び出しや保存が出来ます。一方、アドインプログラムでは、保存していた障害物の画面コピーの呼び出し、軌跡の画面コピーの保存はできません。

なお、アドインでは、ペイントモードで、[EXE] を押した時のみ十字カーソルが表示されます。一方、Casio Basic プログラムでは [EXE] を押さずに矢印キーを押せば、十字カーソルが表示されました。今回、Casio Basic の仕様を変更して、アドインと同じになるように修正しました(この方が操作の統一性があるため)。この修正は、プログラムコードで 青文字で示した3行を追加しています。



さて、But Trap の時と同様に、以下のパターン (PICT19) を呼び出して、障害物パターンとします。

BugTrap-Pict19 
⇒ ダウンロード: PICT19

このパターンを呼び出して、Bug Trace による軌跡は、結局以下のようになって、あとは同じ軌跡を繰り返したどることが分かりました。これだけ動き回ったあげく元の軌跡に戻るので、閉じ込めに失敗しているのか失敗していないのか、判断に困るところです。ただ、思いの外広い範囲を通過していることが分かって、面白い結果です。

BugTrace_result1 

他にも、障害物パターンを色々と変えてみると、どれも一定の軌跡を繰り返すことが分かりました。

BugTrace_result2 

BugTrace_result3 

BugTrace_result4 

BugTrace_result5 

BugTrace_result6 

軌跡で画面全体を万遍なく塗りつぶすのは、意外に難しそうです。


障害物無しで、軌跡を調べて見ると、

BugTrace_result7 

結構、広く塗りつぶしていることが分かります。逆に言えば、まだ完全に塗りつぶせていません。



回答募集

そこで、Bug Trace プログラムを使って、軌跡で全て塗りつぶす条件を探してみることにしました。

虫の軌跡は、斜めの移動だけなので、理想的には以下のような千鳥格子になります。

BugTrace_result_Goal 
目 標

極端な話し、障害物を描画するとき、これだけで塗りつぶすこともできるので、障害物のピクセル数をどこまで少なくして、目標の軌跡が得られるでしょうか?

ちなみに、上の目標は プログラム Bug Trace で得たのではなく、以下のプログラムで描いています。

ClrGraph
CoordOff
GridOff
AxesOff
LabelOff
ViewWindow 0,126,0,0,62,0

For 0→Y To 62
SketchDot F-Line 0,Y,126-MOD(Y,2),Y
Next

Horizontal 0
Vertical 126
Horizontal 62
Vertical 0




問題)
目標の千鳥格子の結果に少しでも近い軌跡を得るために、最も少ないピクセルの障害物をどこに配置すれば良いでしょうk?
障害物の形と配置、それと併せて軌跡の結果を教えて下さい。


皆様からの回答をお待ちしています。



[2015/08/13 追記]
<ヒント>
上の問題について、色々と調べてみていますが、1ピクセルの抜けも無い完全な千鳥格子が得られる障害物とその置き方は、4通り見つかっていて、いずれの障害物も2ピクセルです。但し、この4通りは、完全な千鳥格子に加えて、格子の間が ON になるピクセル(障害物の一部)が1つあります。

1ピクセルの障害物を試していますが、今のところ完全な千鳥格子に最も近いのは、1ピクセルだけ抜けがあり、さらに格子の間に障害物の一部の1ピクセルがある結果になります。これが4通り見つかっています。

sentaro様が、2ピクセルの障害物のパターンを見つけられたとのことです(コメント参照)。


[2015/08/14 追記]
<描画の高速化>
Casio Basic では描画が遅いので、色々なパターンを探索するには、2つの方法があります;
 ・ オーバークロックツール Ftune2 を使って、高速化する
 ・ 同等機能を高速なアドインプログラムで作る
私は、オーバークロックツールで、高速描画させて探索しています。

この度 sentaro様が、同じ動作を行うアドインプログラムを作ってくれたので、極めて高速に描画が可能になりました。
PCリンクソフト FA-124 を使って、fx-9860GII へ導入できます。
⇒ ダウンロード: Add-in プログラム Ver1.10 BugTracb.g1a

ダウンロードした Add-in プログラムを fx-9860GII へ転送する方法は、FA-124 を起動し、メニューの [HELP] - [Manual] を選び、表示される取扱説明書の 64ページ 「10. アドインのインストール」にあるので、記述に従えば簡単です。アドインのインストールが済めば、fx-9860GII で [MENU] を押して、以下のアイコン (bug と描かれているアイコン) が追加されていればインストール成功です。

BugTrace_Menu 
このアイコンを選んで [EXE]BugTrace アドインが起動します。


ところで Add-in は、SDKを使って C  言語で記述して作成します。ご興味のある方は、ソースファイル一式を触ってみてください。
 ⇒ ダウンロード: Add-in プログラム Ver1.10 ソース付き BugTrace110.zip

※ ご参考までに、SDK の入手方法は、こちら を参考にしてください。

ちなみに、sentaro様は、この自作のアドインで、高速探索するうち、1ピクセルの障害物を見つけたとのことです(コメント 参照)。



[2015/08/14 追記2]
sentaro様が 作成した Add-in は、グラフィックスプログラムは アドインで作ると高速描画が可能になる良い例です。
なお、描画中に [MENU][EXIT] 以外の好きなキーを押せば、描画が劇的に高速化します(ターボ効果)。
⇒ ダウンロード: BugTrace.g1a (Ver 1.10)



以下の一連の Casio Basic が アドインプログラムになっていて、その一部に Drunk Bug があります

楽屋裏 - 酔っ払いの虫 (Drunk Bug)
楽屋裏 - 虫の閉じ込め (Bug Trap)
楽屋裏 - 虫の軌跡 (Bug Trace)


このアドインを再コンパイルや改造できるソース付き全ファイルのダウンロードは以下;
⇒ ダウンロード: BugTrace110.zip (Ver 1.10)





応援クリックをお願いします。励みになるので...

人気ブログランキングへ


FC2ブログランキングへ





keywords: fx-9860GII、CasioBasicプログラム関数電卓コメントアウトバグ

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

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

コメントの投稿

非公開コメント

やっと出来ました!(^^;

管理人様、こんにちは!

軌跡が残るのはこれはまた見た目が面白い結果になりますね(^^)

ってことで、
千鳥格子にちょこっと挑戦してみたらこれがなかなか上手くいかずにちょっとハマってしまいました。

最初は水平壁で試行錯誤して、途中からは壁設定したあと放置していたらいつのまにか出来てたのでもう一回と思ったらその時の設定の記憶があやふやでそれがなかなか再現できず…(^^;
結果的には縦2ドットの垂直壁で出来たのですが、かなり楽しませていただきました(^^)

こういう試行錯誤になるとオーバークロックでないとちょっとしんどいですね。
途中で電池切れになったのでその後はUSBパワーで継続しました(^^;

1ドットでいけますね(^^;

試行錯誤をもっと速くしたいってことで、アドイン化してみました。

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

速度調整目的でキー押しでターボが効くSDKのキー入力を使っています。

PICTのロード&セーブは未対応です(^^;

BugTrace のミソ

sentaro様

既にお気づきでしょうが、BugTrace で虫の進行方向を変えるロジックでは、右端の枠線と垂直なコーナーに虫が入ると、そのまま反転させるのではなく、軌跡をずらしています。

最初は単なるバグだったのですが、虫のトラップゲームでもこの方が面白いことに気づき、そのままにしています。軌跡を広げるゲームでは、これがないと千鳥格子は(恐らく)絶対にできません。

実際に軌跡が続かなくなるのは、左上と左下のコーナーに入り込む時です。

=====

本分にも書いたのですが、2ピクセルの障害物で千鳥格子ができるのは4通り見つかっています。また1ピクセルも見つかっていますが、完全な千鳥格子から1ピクセルだけ抜ける結果になるパターンが4通り見つかっています。

sentaro様が見つけた1ピクセルの障害物では、抜けのない千鳥格子になっているのでしょうか?そうだとすれば、私の探索がまだ足りないので、さらに面白くなりそうです。

=====

ところで、Add-in 化、ありがとうございます。それも、虫シリーズ全部を入れてもらって、感謝です。Casio Basic で見つけたパターンは Add-in でも問題なく再現しました。

本文には、アドインについて追記しました。

Add-in のご投稿の前に、Casio Basic では、障害物設置状態の画面コピーとプログラム終了時の軌跡の画面コピーをそれぞれ PICT15 と PICT16 に自動的に保存するように変更しました。

パターンの探索を行うのあたって、これが無いと不便だからです。

=====

ソースを拝見すると、関数の作り方や、文字列の初期化処理などから、コンパイラ作成のための小手調べのように見えるので、その視点で少々...釈迦に説法は重々承知の上ですが...

どこまで、Casio Basic を再現するかによりますが、Casio Basic の十字カーソルは中心の点が点滅しています。また十字カーソルは不透過で、カーソルの下の描画は見えないようになっています。

PxlOn / PxlOff/ PxlTest は、しっかり引数の x と y が逆になっていますね。将来的には、X, Y は自動的に論理座標系での値を返す仕様に変更することになりますよね。また座標系の構造体を3種類用意して、参照渡しにする必要がありそうですね。

あと、プログラムが走っている時に右上に表示される 4x4 pix の四角形のマーカーは、どうしますか?

実は、今回の BugTrace を走らせて分かったのですが、PxlTest は、この四角形の描画は無視します。なので、この四角形の下に隠れる外枠での虫 (=点) の反射は、外枠や障害物のピクセルパターンの影響のみを受けて、実行中マーカーの四角形の影響を受けないことが、分かりました。

当初、マーカー四角形の影響を受ける可能性を想定したのですが、実際は違っていました。


BugTrap の3連星は、9連星に変更ですね。これくらいしないと 280NHz では見えないです。

かなりハマってます(^^;

管理人様、こんにちは!

>既にお気づきでしょうが、BugTrace で虫の進行方向を変えるロジックでは、右端の枠線と垂直なコーナーに虫が入ると、そのまま反転させるのではなく、軌跡をずらしています。

右上の隅で反射の仕方がちょっと違ったところでわかりました。


>最初は単なるバグだったのですが、虫のトラップゲームでもこの方が面白いことに気づき、そのままにしています。軌跡を広げるゲームでは、これがないと千鳥格子は(恐らく)絶対にできません。

え?バグだったのですか?
ロジックは丸写しなのでバグも同様にということで全然気が付いてませんでした(^^;
千鳥格子はかなりハマってしまいましたし、虫(バグ)ゲームだけにバグもいい味出しましたね(^^)


>実際に軌跡が続かなくなるのは、左上と左下のコーナーに入り込む時です。

これは何度も詰まったので実感しまくりです(^^;


>本分にも書いたのですが、2ピクセルの障害物で千鳥格子ができるのは4通り見つかっています。また1ピクセルも見つかっていますが、完全な千鳥格子から1ピクセルだけ抜ける結果になるパターンが4通り見つかっています。

うわ、かなりあるんですね。


>sentaro様が見つけた1ピクセルの障害物では、抜けのない千鳥格子になっているのでしょうか?そうだとすれば、私の探索がまだ足りないので、さらに面白くなりそうです。

私の見つけた1ドットでできる千鳥格子は初期値から下に1ドットずらせてX=63 Y=30に点を打つだけですが、最初に見つけたのは、X=63 Y=31の初期値と下にずらしたX=63 Y=30の2ドットをCasioBasicで見つけました。
その後アドインを作成している最中に最初のドットは要らないことに気が付いて、というところでした。
中央に最初の壁が残るので完全無欠な千鳥格子ではないですがこれはOkということでしょうか?
私はそれをひとつだけ見つけてから次はアドインでという流れの最中であれこれプログラムいじるばかりで探索が二の次になってしまってるので二つ目を見つけるのはこれからという感じです(^^;


>Add-in のご投稿の前に、Casio Basic では、障害物設置状態の画面コピーとプログラム終了時の軌跡の画面コピーをそれぞれ PICT15 と PICT16 に自動的に保存するように変更しました。

自動保存はよいですね。これでうっかり忘れて、ということが無くなります。

アドインでもGetKey待ちの状態だと[SHIFT]+[7]CAPTUREで画面キャプチャできるのですが、PICTファイルも扱えないとというわけで試行錯誤中ですが、今の段階ではまだ使えないのでとりあえずSDKの画面セーブ機能を追加してみました。

http://pm.matrix.jp/BugTrace110.zip
メインメニューに戻ってからF6で結果画面を呼び出せます。
BugTraceとBugTrapでは[OPTN]を押すと前回の障害物設置状態に戻せます。


>ソースを拝見すると、関数の作り方や、文字列の初期化処理などから、コンパイラ作成のための小手調べのように見えるので、その視点で少々...釈迦に説法は重々承知の上ですが...

ありがとうございます。管理人様にはすべてお見通しですね(^^)
今ちょこちょこやってるのはコンパイラでのランタイムルーチンの元になる感じかと思いますが、管理人様の細かな視点でのチェックはすごく助かります。
今後もよろしくお願いいたします(^^)


>どこまで、Casio Basic を再現するかによりますが、Casio Basic の十字カーソルは中心の点が点滅しています。また十字カーソルは不透過で、カーソルの下の描画は見えないようになっています。

グラフィックカーソルの点滅は割り込み必須なので先送りとして(^^;重なりを修正しました。(右端での折り返しは未修正です。)
それからカーソルリピート速度がちょい遅かったのでBasicの速度に合わせました。


>PxlOn / PxlOff/ PxlTest は、しっかり引数の x と y が逆になっていますね。将来的には、X, Y は自動的に論理座標系での値を返す仕様に変更することになりますよね。また座標系の構造体を3種類用意して、参照渡しにする必要がありそうですね。

はい、最終的にはそのような感じになると思います。
論理座標系のコマンドが今回のようなView設定がドットで対応する場合はPxl系の絶対座標系のSDKライブラリで簡単なのですが、汎用的には実数で作成しないといけないので結構大変ですよね。
実数コンパイラとして形になってくればそこのあたりはなんとかなると思います(^^;


>あと、プログラムが走っている時に右上に表示される 4x4 pix の四角形のマーカーは、どうしますか?

今回のバージョンアップでBugTraceとBugTrapで再現してみましたけど、今のソースでは画面退避復帰が描画毎に必要になっているので速度的影響が少なからずあるのでここはちょっと最適化をしないといけない感じです。


>BugTrap の3連星は、9連星に変更ですね。これくらいしないと 280NHz では見えないです。

9連星でもターボすると見えなくなるので、一気に32連星まで増やしました。
もはやほとんどスネーク状態ですね(^^;

Re: かなりハマってます(^^;

sentaro様


> 私の見つけた1ドットでできる千鳥格子は初期値から下に1ドットずらせてX=63 Y=30に点を打つだけですが、最初に見つけたのは、X=63 Y=31の初期値と下にずらしたX=63 Y=30の2ドットをCasioBasicで見つけました。
> その後アドインを作成している最中に最初のドットは要らないことに気が付いて、というところでした。
> 中央に最初の壁が残るので完全無欠な千鳥格子ではないですがこれはOkということでしょうか?
> 私はそれをひとつだけ見つけてから次はアドインでという流れの最中であれこれプログラムいじるばかりで探索が二の次になってしまってるので二つ目を見つけるのはこれからという感じです(^^;

初期位置から下へ1ドットずらした位置に1ピクセルだけ、で確かに完全千鳥格子+1ドットになりました。

う~む、これは気付きませんでした。

さすがにアドインの高速描画でないと、なかなか見つからないです。何十箇所の1ピクセルで同様の結果になりそうです。


> え?バグだったのですか?
> ロジックは丸写しなのでバグも同様にということで全然気が付いてませんでした(^^;
> 千鳥格子はかなりハマってしまいましたし、虫(バグ)ゲームだけにバグもいい味出しましたね(^^)

これは、失礼しました。ただ、処理を非対称にする面白さは満喫できますね。

> >実際に軌跡が続かなくなるのは、左上と左下のコーナーに入り込む時です。
>
> これは何度も詰まったので実感しまくりです(^^;

外枠での非対称はケガの功名ですが、もう一カ所、非対称な処理を作り込んでいます(^_^)/
PxlTest() が2つ並んでいるところのおかげで、面白くなったと思っています。


> 自動保存はよいですね。これでうっかり忘れて、ということが無くなります。

sentaro様が、せっかくうまくいったのにパターンを忘れたと書かれていたので、追加しました。


> http://pm.matrix.jp/BugTrace110.zip

早速、これで遊んでみました。記事でも反映させました。


十字カーソルが速くなっていて良いです。これ結構気になっていました。


> メインメニューに戻ってからF6で結果画面を呼び出せます。
> BugTraceとBugTrapでは[OPTN]を押すと前回の障害物設置状態に戻せます。

画面コピーですが、SaveDisp は3ページしか保存できないのですね。


> 今ちょこちょこやってるのはコンパイラでのランタイムルーチンの元になる感じかと思いますが、管理人様の細かな視点でのチェックはすごく助かります。
> 今後もよろしくお願いいたします(^^)


では、お言葉に甘えて、十字カーソルについて、もう一つ気になる点があります...

> グラフィックカーソルの点滅は割り込み必須なので先送りとして(^^;重なりを修正しました。(右端での折り返しは未修正で

これは確認致しました。中心点の点滅はマイナーアップデートということですね。

ところで、Casio Basic の描画エリアは 127 x 63 pix で、上端と左端の1ラインが余っています。で、十字カーソルはこの余っているラインにも描画されています。
これだけで、見やすくなっています。
 すみません、これは実現されています。私の早とちりでした。失礼しました。

> 論理座標系のコマンドが今回のようなView設定がドットで対応する場合はPxl系の絶対座標系のSDKライブラリで簡単なのですが、汎用的には実数で作成しないといけないので結構大変ですよね。
> 実数コンパイラとして形になってくればそこのあたりはなんとかなると思います(^^;

このあたりは、やれば出来るということですね。


> >あと、プログラムが走っている時に右上に表示される 4x4 pix の四角形のマーカーは、どうしますか?
>
> 今回のバージョンアップでBugTraceとBugTrapで再現してみましたけど、今のソースでは画面退避復帰が描画毎に必要になっているので速度的影響が少なからずあるのでここはちょっと最適化をしないといけない感じです。

どうやっているのかと興味ありましたが、SaveDisp と RestoreDisp でうまく処理されていて、こういうのをチャッチャと実装されるあたり、さすがです。


> >BugTrap の3連星は、9連星に変更ですね。これくらいしないと 280NHz では見えないです。
>
> 9連星でもターボすると見えなくなるので、一気に32連星まで増やしました。
> もはやほとんどスネーク状態ですね(^^;

280MHz のターボモードだと、これでもさすがにキツイですね。BugTrap ではターボ効かせる必要もなさそうなので、wAryは 9 くらいで良さそうな気もします。


最後に余計なお世話かも知れませんが、Plot() の実装で、変数名に nowX と nowY がありますが、CurrentX, CurrentY、或いはチョット省略するのも有りかと...将来海外のネイティブがソースを見た時に??とならずに良いかなぁ...などと...now って形容詞的に使う例を殆ど見たことがなくて、副詞的な使い方オンリーな感じです。なので、形容詞的なもので、Current がピッタリ。私個人的には、Current の綴りは指が覚えているので、そのまま使ってもOKなんですけど...

今から海外進出を想定してしまってナンですが、完成したら結構反響あるのではないかと思いますので、後で変更するのも面倒でしょうから、今のうちということで如何でしょうか?


v1.20

管理人様、こんにちは!

>さすがにアドインの高速描画でないと、なかなか見つからないです。何十箇所の1ピクセルで同様の結果になりそうです。

最初はBasicでの放置プレイでいつのまにか出来ていたというので気が付いたわけですけど、リアルタイム観測だと途中で動かなくなって止まったようになるのでNGってことになりそうですね(^^;

この1ピクセルがどのように効いてくるのかと観察すると全方位からの方向転換になっている感じですから、縦横4ピクセルずつずらした位置では同様に千鳥格子が出来るところが多数ありますね。


>外枠での非対称はケガの功名ですが、もう一カ所、非対称な処理を作り込んでいます(^_^)/
>PxlTest() が2つ並んでいるところのおかげで、面白くなったと思っています。

この反射メカニズムが肝ですよね(^^)


>sentaro様が、せっかくうまくいったのにパターンを忘れたと書かれていたので、追加しました。

いまだにあれはどう設定したのかがあやふやなままです(^^;
結局のところ、Y=31のまま水平壁だけではどうにも上手くいかないので、千鳥格子の出来たX=63,Y=30から4ドット左にずれたところに点を打ったのだろうと思うことにしています(^^;


>早速、これで遊んでみました。記事でも反映させました。

いつもありがとうございます!


>十字カーソルが速くなっていて良いです。これ結構気になっていました。

ですよね(^^;
キーリピート速度を変更するだけなのでこれは最初に気が付くべきでした。


>画面コピーですが、SaveDisp は3ページしか保存できないのですね。

はい、SDKでは3ページしか設定されてないので、増やすには独自拡張するか、というかBasicコンパイラ目的なのでやはりPICTにアクセスできるようにしないとですね。


>これは確認致しました。中心点の点滅はマイナーアップデートということですね。

はい、ってことで、マイナーアップデートしてみました。
右端折り返しも対処したのでほぼCasioBasic同等になったかと思います(^^)


>どうやっているのかと興味ありましたが、SaveDisp と RestoreDisp でうまく処理されていて、こういうのをチャッチャと実装されるあたり、さすがです。

すでにグラフィックカーソルで退避復帰の処理を実装済みだったのでとりあえずは同様の方法でいけると思いました(^^;
CasioBasicではどう処理しているのかは分からないですけど、もし同様の画面退避復帰をしているとしたら結構処理負担は大きいですね。

今回のバージョンアップでオンオフ切り替えできるようにしてみました。
ノーマルだとキースキャンが遅いのでさほど影響ないですけど、ターボ時には影響が出てきますね。


>280MHz のターボモードだと、これでもさすがにキツイですね。BugTrap ではターボ効かせる必要もなさそうなので、wAryは 9 くらいで良さそうな気もします。

この際ですからinp.cの数値入力を使って9999まで設定できるようにしてみました。
最大値にするとBugTrapでもBugTraceとほとんど同じ感じで進んでいって、埋め尽くされた後からどんどん消えていくというまた違った面白さが出てきます(^^;
これはメインメニューから設定できます。


>最後に余計なお世話かも知れませんが、Plot() の実装で、変数名に nowX と nowY がありますが、CurrentX, CurrentY、或いはチョット省略するのも有りかと...将来海外のネイティブがソースを見た時に??とならずに良いかなぁ...などと...now って形容詞的に使う例を殆ど見たことがなくて、副詞的な使い方オンリーな感じです。なので、形容詞的なもので、Current がピッタリ。私個人的には、Current の綴りは指が覚えているので、そのまま使ってもOKなんですけど...
>今から海外進出を想定してしまってナンですが、完成したら結構反響あるのではないかと思いますので、後で変更するのも面倒でしょうから、今のうちということで如何でしょうか?

了解です!
コメントにはcurrentと書いてるのになぜに変数名はnowになるの?ですね(^^;
以前からの癖でよく独自の和製英語が出てきてしまうので(^^;管理人様のネイティブ視点からのご助言がすごくありがたいです(^^)
ってことで、早速に修正しておきました。
(ViewWindow系の変数になるので先頭にVWを加えました。)

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

v1.21

BugTrapで虫の長さが長くなるにつれて遅くなっていたので(^^;
速度低下が起きないようにしました。

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

Re: v1.20

sentaro様


> 最初はBasicでの放置プレイでいつのまにか出来ていたというので気が付いたわけですけど、リアルタイム観測だと途中で動かなくなって止まったようになるのでNGってことになりそうですね(^^;
>
> この1ピクセルがどのように効いてくるのかと観察すると全方位からの方向転換になっている感じですから、縦横4ピクセルずつずらした位置では同様に千鳥格子が出来るところが多数ありますね。

そうなんですね。
ところが、初期位置から1つ下へずらした(63, 30) から右へずらしてゆく場合、4つずらしと6つずらしでも共に千鳥格子になるので、4つ刻みとは限らないところがなんともです。


> >PxlTest() が2つ並んでいるところのおかげで、面白くなったと思っています。
>
> この反射メカニズムが肝ですよね(^^)

はい、面白くなりますね。



> 結局のところ、Y=31のまま水平壁だけではどうにも上手くいかないので、千鳥格子の出来たX=63,Y=30から4ドット左にずれたところに点を打ったのだろうと思うことにしています(^^;

(63, 30) から右と上下は、4つ刻みのようです。


> >十字カーソルが速くなっていて良いです。これ結構気になっていました。
>
> ですよね(^^;
> キーリピート速度を変更するだけなのでこれは最初に気が付くべきでした。

ターボ効果ですもんね。


> はい、SDKでは3ページしか設定されてないので、増やすには独自拡張するか、というかBasicコンパイラ目的なのでやはりPICTにアクセスできるようにしないとですね。

そうですね、3ページと20ページは差がありすぎですよね。


> >これは確認致しました。中心点の点滅はマイナーアップデートということですね。
>
> はい、ってことで、マイナーアップデートしてみました。
> 右端折り返しも対処したのでほぼCasioBasic同等になったかと思います(^^)

Casio Basic では、十字カーソル移動中でも中心点が描画されていて、さらに点滅しているように見えるんですが、今の Plot () のソースを拝見する限り 同じ動作のはずなのに、エミュや実機で確認しても中心点の描画が見えないです。

ソースを拝見すると、なかなか勉強になるので、ついつい細かいことまで突っ込んでしまってすみません(--;)


> すでにグラフィックカーソルで退避復帰の処理を実装済みだったのでとりあえずは同様の方法でいけると思いました(^^;
> CasioBasicではどう処理しているのかは分からないですけど、もし同様の画面退避復帰をしているとしたら結構処理負担は大きいですね。

このマーカーについては、コンパイラを考える場合、実行を一時停止する "" と ◢ コマンドの中で処理する必要がありそうですね。それ以外は基本 ビジーマーカーは点灯されるのが、Casio Basicの仕様ですから...但し、アドインだと描画が速いので、ある程度のウェイトをかける必要がありそうですけど...手加減でなんとかなりませんか?

特に、グラフィックスコマンドが ◢ で一旦停止されると、グラフィックス画面が表のまま、裏のテキスト画面には - DISP - が表示され、[EXE] で復帰すると、テキスト画面には done と表示されます。

ちなみに、done表示については、プログラムが終了する時必ずテキスト画面が表になって、そこで done表示されます。なので、プログラムが実行されてから終了されるまで、- DISP - の数+1個の done表示が実行されます。途中で ClrText をすれば - DISP - と done 表示は消えます。

またビジーマーカ-が影響を与えるコマンドとしては、今のところ PxlTest()しか見つかっていませんので、ビジーマーカーの影響は、PxlTest() でキャンセルするのがコンパイラ動作としてはふさわしいように思います。


> 今回のバージョンアップでオンオフ切り替えできるようにしてみました。
> ノーマルだとキースキャンが遅いのでさほど影響ないですけど、ターボ時には影響が出てきますね。

ターボ時の影響ってよく分からなかったのですが、どんな影響でしょうか?


> >280MHz のターボモードだと、これでもさすがにキツイですね。BugTrap ではターボ効かせる必要もなさそうなので、wAryは 9 くらいで良さそうな気もします。
>
> この際ですからinp.cの数値入力を使って9999まで設定できるようにしてみました。
> 最大値にするとBugTrapでもBugTraceとほとんど同じ感じで進んでいって、埋め尽くされた後からどんどん消えていくというまた違った面白さが出てきます(^^;
> これはメインメニューから設定できます。

おお、inp.c の登場ですね!

すみません、inp.c について、私の方で考えていた作業が全然進んでいません。
一応欄プルプログラムを用意して、簡単なマニュアル(基本 inp.h 読めですが...)を作ってパッケージ化しようと思ってhあいるんですが...

こうしてみると、inp.c はアドインでも使いでありそうですね(^_^)/

いずれ、パッケージ化と公開したいと思うのですが、なかなか時間がなくて...すみません。


> (ViewWindow系の変数になるので先頭にVWを加えました。)

はーい、それも良いですね。

Re: v1.21

sentaro様

早速、確認しました(^_^)/

ありがとうございます。

v1.22

管理人様、

>ところが、初期位置から1つ下へずらした(63, 30) から右へずらしてゆく場合、4つずらしと6つずらしでも共に千鳥格子になるので、4つ刻みとは限らないところがなんともです。

うわ、6つでもいけますね!(^^)
1ピクセル壁での千鳥格子は他にはなさそうでしょうかね?


>Casio Basic では、十字カーソル移動中でも中心点が描画されていて、さらに点滅しているように見えるんですが、今の Plot () のソースを拝見する限り 同じ動作のはずなのに、エミュや実機で確認しても中心点の描画が見えないです。

実機でBasicの動作をよく見てみると管理人様のおっしゃるとおり、移動時にも中心点が描画されてフラッシングしてますね。
ってことで、そこのところ修正してみました。
今のバージョンでは最初の割り込みのタイミングで描画していたところを、最初に中心点を強制的に描画してからフラッシングするようにしました。
http://pm.matrix.jp/BugTrace122.zip
これでBasic同様になったでしょうか?(^^)


>ソースを拝見すると、なかなか勉強になるので、ついつい細かいことまで突っ込んでしまってすみません(--;)

いえいえ、その細かな部分の違いを見つける眼力が管理人様ならではなのでとてもありがたいです。
互換性の微妙なコンパイラが出来るか、CasioBasicと完全互換に近いコンパイラが出来るか、違いは大きいですよね(^^)


>このマーカーについては、コンパイラを考える場合、実行を一時停止する "" と ◢ コマンドの中で処理する必要がありそうですね。それ以外は基本 ビジーマーカーは点灯されるのが、Casio Basicの仕様ですから...但し、アドインだと描画が速いので、ある程度のウェイトをかける必要がありそうですけど...手加減でなんとかなりませんか?

マーカーは入力待ち以外で点灯するので、実行中は常に表示でいいわけですよね。


>またビジーマーカ-が影響を与えるコマンドとしては、今のところ PxlTest()しか見つかっていませんので、ビジーマーカーの影響は、PxlTest() でキャンセルするのがコンパイラ動作としてはふさわしいように思います。

そうなんですよね。
ただ、マーカー描画前のグラフィック画面のオリジナルは常に確保しておかないといけないので、結局、描画するごとに画面退避ということは必須になるかと思われます。
ま、最適化すれば退避するのは右上4x4だけでいいので速度的な影響はほぼ無くなると思います。


>ターボ時の影響ってよく分からなかったのですが、どんな影響でしょうか?

v1.20で最大の9999にした時が一番よくわかるのですが、ターボにしてもターボにならないくらいループ内の負荷が上がっていたという感じです。今のバージョンでは影響なくなりましたが、先頭から最後までの座標を毎回全部転送していたのが原因です(^^;


>すみません、inp.c について、私の方で考えていた作業が全然進んでいません。

あ、そこはアドインのライブラリですから管理人様のペースでよろしくです(^^)


>こうしてみると、inp.c はアドインでも使いでありそうですね(^_^)/

はい、SDKではデフォルトで入力ライブラリが用意されてないですし、CasioBasic互換で考えても入力ライブラリは必須になってきますね(^^)

ターボ時の影響

>ターボ時の影響ってよく分からなかったのですが、どんな影響でしょうか?

マーカーでの影響でしたね(^^;

ターボ時はキースキャンが劇的に高速化されるので相対的に画面退避復帰の処理時間が無視できないほどに大きくなってくるということです。
ノーマル時でも影響は出ますが、その影響の度合いがターボ時の方がかなり大きいということですね。


v1.20より結果画面保存に失敗していたのを修正しました(^^;
バージョンは変わらずです。
http://pm.matrix.jp/BugTrace122.zip

v1.23

実行中のマーカー描画をLCDに直に描画するようにしてみました。
画面退避復帰が必要無くなった分、高速化したのですが、
ちょっと弊害もあって…ターボ時にマーカーがかなり薄くなります、というか消えます(^^;

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

Re: v1.22

sentaro様

> 1ピクセル壁での千鳥格子は他にはなさそうでしょうかね?

恐ろしいほど沢山ありそうですよ。何十個とありそう...


> 今のバージョンでは最初の割り込みのタイミングで描画していたところを、最初に中心点を強制的に描画してからフラッシングするようにしました。
> http://pm.matrix.jp/BugTrace122.zip
> これでBasic同様になったでしょうか?(^^)

はい、バッチリです(^_^)/


> いえいえ、その細かな部分の違いを見つける眼力が管理人様ならではなのでとてもありがたいです。
> 互換性の微妙なコンパイラが出来るか、CasioBasicと完全互換に近いコンパイラが出来るか、違いは大きいですよね(^^)

そう言って頂けるとありがたいです。

BugTrace add-in ver 1.22 でファイサイズが 32,500Byte ですので、サイズにはまだまだ余裕がありますね。
Add-in自体とヒープサイズがあまり大きくなるとコンパイラの実現が難しそうだと気にしていましたが、意外といけそうな感じがしてきました。

私の実機では、メインメモリのバックアップ、Casio Basic で遊ぶのに使ううキャプチャー画面、Casio が用意した GEOMETRY.g1a と PHYSIUM.g1a に加えて Add-in が10個インストールされて、それでも 620MB 程度残っています。1MB は結構余裕があります。


> マーカーは入力待ち以外で点灯するので、実行中は常に表示でいいわけですよね。

はい、それで良いと思います。

それに、オプションでBusy Marker のON/OFF もコンパイラの付加価値として面白いと思います。
基本は Casio Basicの完全再現ですが、Casio Basic で楽してプログラムを作って、Add-in 風に仕上げたいという需要はきっとあるでしょうから、このオプションは値打ちがあると思います。


> >またビジーマーカ-が影響を与えるコマンドとしては、今のところ PxlTest()しか見つかっていませんので、ビジーマーカーの影響は、PxlTest() でキャンセルするのがコンパイラ動作としてはふさわしいように思います。
>
> そうなんですよね。
> ただ、マーカー描画前のグラフィック画面のオリジナルは常に確保しておかないといけないので、結局、描画するごとに画面退避ということは必須になるかと思われます。
> ま、最適化すれば退避するのは右上4x4だけでいいので速度的な影響はほぼ無くなると思います。

右上 4x4 領域のみで処理できればそれでOKですよね。

ところで、画面待避という考え方の逆で、例えば BusyMarker(int sw)、sw=1 で表示、sw=0 で消去(積極的に消しに行く) というのはどうでしょうか?画面待避/復帰よりも軽い処理でできれば、それも有りのように思います。

Busy Marrker の影響を考えるべきコマンドとして、PxlTest() 以外にも StoPict があるのに気がつきました。StoPict すると busy Marker は無視されます。他にも出てくるかも知れないのですが、このタイプのコマンドを実装する際に、これらのコマンド内で busy Markerの ON/OFFの制御ができるとトータルで良い可能性ありませんか?


> あ、そこはアドインのライブラリですから管理人様のペースでよろしくです(^^)

助かります。Add-in や アプリで 電卓プログラミングに役立つもの1つのジャンルとして取り上げたいと前から思っています。
先ずは、Ftune シリーズ、そして inp.c に加えて コンパイラもそうです。



> はい、SDKではデフォルトで入力ライブラリが用意されてないですし、CasioBasic互換で考えても入力ライブラリは必須になってきますね(^^)

ええっと、入力命令 " " の動作を inp.c に取り込むか、兄弟バージョンにしようという計画ですか?そうだとしたら、思いつきませんでした。

"" と ◢、は 入力位置と出力入りが仕様として決まっていて、- DISP - 表示、done 表示もあり、これらは内部カーソル行の制御と絡みますので、これらを1括りにして cbio.c (casio basic i/o の略(^^;) という兄弟バージョンにするのは、どうでしょうか?



Re: v1.23

sentaro様

V 1.23 頂きました。
ありがとうございます。

> 実行中のマーカー描画をLCDに直に描画するようにしてみました。
> 画面退避復帰が必要無くなった分、高速化したのですが、
> ちょっと弊害もあって…ターボ時にマーカーがかなり薄くなります、というか消えます(^^;

busy markerは bdisp_DrawLineVRAM で描画していますよね。
これって、Ver 1.23 でないかも....

ターボでマーカーがバリバリ点灯しています...

> http://pm.matrix.jp/BugTrace123.zip


Re: v1.23

管理人様、

>busy markerは bdisp_DrawLineVRAM で描画していますよね。
>これって、Ver 1.23 でないかも....
>ターボでマーカーがバリバリ点灯しています...

1.22が1.23でアップされてた模様です。
大変失礼しました。

ってことで、再度、今度こそ1.23です。

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

とりあえあず、ファイルだけ先に(^^;

No title

管理人様、こんにちは!

>恐ろしいほど沢山ありそうですよ。何十個とありそう...

4刻み以外でもとなると…
千鳥格子の埋まらないところがすべて壁候補になりますけど、そうなるとかなりあるのでしょうか(^^;


>BugTrace add-in ver 1.22 でファイサイズが 32,500Byte ですので、サイズにはまだまだ余裕がありますね。
>Add-in自体とヒープサイズがあまり大きくなるとコンパイラの実現が難しそうだと気にしていましたが、意外といけそうな感じがしてきました。

今から完成段階のサイズは想像できないですけど、たぶん、コンパイラ本体は100KB以下程度で収まると思います。
思いのほかでかくなるのはコマンドのランタイムライブラリなので、これがどれだけのサイズになるかどうかというところですね。
ヒープサイズはコンパイル後のマシン語コードと変数等でそこそこ必要ですがと、SDKではヒープが48KBまでしか取れないので、その範囲でも大きなソースでなければいける範囲かと考えています。
いざとなれば、fx-9860GIIにはOSで使われていないメモリが256KBまるまる余ってるっぽいですから、そこのあたりを使ってというのも可能性としてはありますね(^^;


>ところで、画面待避という考え方の逆で、例えば BusyMarker(int sw)、sw=1 で表示、sw=0 で消去(積極的に消しに行く) というのはどうでしょうか?画面待避/復帰よりも軽い処理でできれば、それも有りのように思います。

消去するということはそれ以前の画面データを保持しておく必要があるので、結局画面退避は常に必要となりますよね。
v1.23のようにLCD画面上だけでマーカー表示する方法ならば、VRAMの実画面は影響受けないので面倒な処理が必要なくなります。
今回のアドインではターボ時にはループ内の処理がかなり軽いのでマーカー表示が消えてしまいますけど、内部処理時間がある程度あるとなればマーカー表示はLCD直接描画でいけそうな感じがします、
おそらくBasicでもその方法でマーカー表示をしているのかもしれません。


>助かります。Add-in や アプリで 電卓プログラミングに役立つもの1つのジャンルとして取り上げたいと前から思っています。
>先ずは、Ftune シリーズ、そして inp.c に加えて コンパイラもそうです。

よいですね(^^)
まずは、Ftuneシリーズというところが恐縮しまくりですけど、アドインや部品となるライブラリは多いほど便利になるのでそこのあたりの充実もとても重要ですね。


>ええっと、入力命令 " " の動作を inp.c に取り込むか、兄弟バージョンにしようという計画ですか?そうだとしたら、思いつきませんでした。

あ、そこは、inp.cはとりあえずSDK用として一段落させておいて、
CasioBasic互換用には別ファイルで再構築していかないとと考えています。


>"" と ◢、は 入力位置と出力入りが仕様として決まっていて、- DISP - 表示、done 表示もあり、これらは内部カーソル行の制御と絡みますので、これらを1括りにして cbio.c (casio basic i/o の略(^^;) という兄弟バージョンにするのは、どうでしょうか?

はい、その方向で、CasioBasic動作互換ライブラリという形で少しずつ部品固めですね。

v 1.23

sentaro様

Ver 1.23 の動作確認致しました。
ありがとうございます。

これで、ソースが却ってスッキリして、部品としては使いやすくなった感じです。


> >恐ろしいほど沢山ありそうですよ。何十個とありそう...
>
> 4刻み以外でもとなると…
> 千鳥格子の埋まらないところがすべて壁候補になりますけど、そうなるとかなりあるのでしょうか(^^;

そうだと思います。



> 今から完成段階のサイズは想像できないですけど、たぶん、コンパイラ本体は100KB以下程度で収まると思います。
> 思いのほかでかくなるのはコマンドのランタイムライブラリなので、これがどれだけのサイズになるかどうかというところですね。
> ヒープサイズはコンパイル後のマシン語コードと変数等でそこそこ必要ですがと、SDKではヒープが48KBまでしか取れないので、その範囲でも大きなソースでなければいける範囲かと考えています。

文字コード変換テーブルは外部参照にしておけば、汎用性とヒープ領域の節約になるかもですね。


> いざとなれば、fx-9860GIIにはOSで使われていないメモリが256KBまるまる余ってるっぽいですから、そこのあたりを使ってというのも可能性としてはありますね(^^;

わっ、そんなのが有るんですか...外部テーブルをここにロードして使うなんてのも有効かも...と簡単に言ってしまってすみません。



> >ところで、画面待避という考え方の逆で、例えば BusyMarker(int sw)、sw=1 で表示、sw=0 で消去(積極的に消しに行く) というのはどうでしょうか?画面待避/復帰よりも軽い処理でできれば、それも有りのように思います。
>
> 消去するということはそれ以前の画面データを保持しておく必要があるので、結局画面退避は常に必要となりますよね。
> v1.23のようにLCD画面上だけでマーカー表示する方法ならば、VRAMの実画面は影響受けないので面倒な処理が必要なくなります。

Bdisp_ClearLineVRAM が頭にあったので、Bdisp_WriteGraph_DD にも似たようなクリア機能があると、勘違いしてました。
無いですね。失礼しました。


> 今回のアドインではターボ時にはループ内の処理がかなり軽いのでマーカー表示が消えてしまいますけど、内部処理時間がある程度あるとなればマーカー表示はLCD直接描画でいけそうな感じがします、
> おそらくBasicでもその方法でマーカー表示をしているのかもしれません。

そうですね、VRAMでピクセルの ON/OFF を調べれば良いので、合理的です。


> >助かります。Add-in や アプリで 電卓プログラミングに役立つもの1つのジャンルとして取り上げたいと前から思っています。
> >先ずは、Ftune シリーズ、そして inp.c に加えて コンパイラもそうです。
>
> よいですね(^^)
> まずは、Ftuneシリーズというところが恐縮しまくりですけど、アドインや部品となるライブラリは多いほど便利になるのでそこのあたりの充実もとても重要ですね。

そうですよね。大きな目標です。



> >ええっと、入力命令 " " の動作を inp.c に取り込むか、兄弟バージョンにしようという計画ですか?そうだとしたら、思いつきませんでした。
>
> あ、そこは、inp.cはとりあえずSDK用として一段落させておいて、
> CasioBasic互換用には別ファイルで再構築していかないとと考えています。

はい、そうですね。

> >"" と ◢、は 入力位置と出力入りが仕様として決まっていて、- DISP - 表示、done 表示もあり、これらは内部カーソル行の制御と絡みますので、これらを1括りにして cbio.c (casio basic i/o の略(^^;) という兄弟バージョンにするのは、どうでしょうか?
>
> はい、その方向で、CasioBasic動作互換ライブラリという形で少しずつ部品固めですね。


先ほどアップした Casio Basic入門 G08 では、StoPict / RclPict の詳細仕様を盛り込んでいます。コンパイラを意識したものです。

Inside Casio Basic

sentaro様

コマンドリファレンス英語版、ゆっくりですが、始めてみました。

意図的に古い日付でアップして、新着に出ないようにしてます。

カテゴリー一覧から Inside Casio Basic を選べば見られます。

英語版が出来れば、和訳して日本語版はすぐ出来るので、英語先行です。

おかしなところが有れば是非ともご指摘下さい。

現在のコマンドリファレンスと、インサイドCasio Basic(日本語版)を統合するのかどうかは、未定です。

取り敢えずグラフィックスについては、英語版のフォーマットで日本語版も作ってみようかと思います。

コンパイラプロジェクトのちゃんとしたリファレンスにしたいな、と思ってます。

Re:Inside Casio Basic

管理人様、こんにちは!

Inside Casio Basic、なかなかによいです(^^)
分かりやすくすっきりまとまっていて、海外の方ににもマニュアルを見るよりもこっちでという感じで広まるといいですね。


>コンパイラプロジェクトのちゃんとしたリファレンスにしたいな、と思ってます。

今のところ、コンパイラ本体はまだ形になってない段階ですけど(^^;
今回のアドイン版作成の過程でグラフィックのCasioBasicライブラリを管理人様のグラフィック探索と並行して作成していった方がよさそうってことで、管理人様の正確なコマンドリファレンスはとても助かります。


>先ほどアップした Casio Basic入門 G08 では、StoPict / RclPict の詳細仕様を盛り込んでいます。コンパイラを意識したものです。

ViewWindowでPlotコマンドとPixlコマンドと座標をぴったり合わせられるのはなかなか奥深いですね。

Pictに関しては早いところ実装したいところなのですが、Pictのファイル仕様はどこにも公開されていないみたいなのでちょっと解析しないとダメっぽいですけど、fx-9860GIIは1画面で1KBのはずなのにファイルサイズが2KBあるのがちょっと謎ですね。
バイナリで見てみると後半はゼロばかりで…Caputreの方はほぼ1KBぴったりなのでどうなっているのかなというところです。

Re: Re:Inside Casio Basic

sentaro様

> Inside Casio Basic、なかなかによいです(^^)
> 分かりやすくすっきりまとまっていて、海外の方ににもマニュアルを見るよりもこっちでという感じで広まるといいですね。

できるだけ辞書的に簡潔にしてみましたが、これも良いかも知れないということですね。

従来の日本語のコマンドリファレンスは、ある程度分かっている人には書き過ぎかも知れないと感じていました。

入り口の目次は、トップページ(の下の方)にリンクを追加しておきました。

Clsを追加していますが、まだ書きかけで、内部カーソル行のリセット機能の説明を追加予定ですが、この内部カーソル行については、別に Undocumented Casio Basic のところで取り上げようと思ってます。

お気づきかも知れませんが、Inside Windows、Undocumented Windows のパクリだったりします(^^;)


> 今のところ、コンパイラ本体はまだ形になってない段階ですけど(^^;

形になりそうになったら、sentaro様の集中力で、あっと言う間に形になりそう...なので、まだ時間のある今のうちにしっかりと調べて、残したいものです。


> 今回のアドイン版作成の過程でグラフィックのCasioBasicライブラリを管理人様のグラフィック探索と並行して作成していった方がよさそうってことで、管理人様の正確なコマンドリファレンスはとても助かります。

実は、アドインを作って頂くと、検証になるので、私としても大変有り難いのです。ロボットを開発することで、人間の研究にフィードバックするのと、気持ちは同じです...


> ViewWindowでPlotコマンドとPixlコマンドと座標をぴったり合わせられるのはなかなか奥深いですね。

ViewWindow で物理座標系を設定し、プログラム内で間違いなく整数の座標値を指定すれば、或いは inp.c で整数に限定して入力させるシチュエーションがあれば、完全な物理座標系として使えて面白そうです。

Pxlコマンドは、変数 X と Y に論理座系の値を代入するので、ViewWindow と絡めると、全ての座標系を併せることも可能ですよね。


> Pictに関しては早いところ実装したいところなのですが、Pictのファイル仕様はどこにも公開されていないみたいなのでちょっと解析しないとダメっぽいですけど、fx-9860GIIは1画面で1KBのはずなのにファイルサイズが2KBあるのがちょっと謎ですね。
> バイナリで見てみると後半はゼロばかりで…Caputreの方はほぼ1KBぴったりなのでどうなっているのかなというところです。

そうなんです。CaptureとPictでファイルサイズが倍違うのは、私も不思議に思っていました。

Pict は RclPict を実行すると、既にある描画に重ね合わせとなります。
RclCaptが上書きなのか重ね合わせか、まだ調べていなかったので、実験しました。

DLINE1.6 で 破線 (Broken) を中央左から右へ描いて、[SHIFT] [7] (Capture) で Capt #1 に保存します。

次に、DLINE4.5 の一番最後に RclCapt 1 と追加してから、実行してみます。

すると、最終的な描画は、DLINE1.6 の破線と同じです。つまり、RclCapt は完全上書きする点で、RclPict と異なることが分かりました。


この仕様の違いのために、ファイルサイズが違うという線で推測できますか?
今、チョット考え中で、よくわかりません。

処理的には、ドットごとに Or とれば 重ね合わせになりますが、なぜファイルサイズが倍になるのか? 元画像データと Or するための作業領域か、結果画像領域かがイメージファイルに中に有るのでしょうか? ハードウェア上の制限からこの説を支持できますか?


No title

管理人様、こんにちは!

>従来の日本語のコマンドリファレンスは、ある程度分かっている人には書き過ぎかも知れないと感じていました。

詳しく知りたい場合と簡潔に確認したい場合があるので両方あると完璧です(^^)


>お気づきかも知れませんが、Inside Windows、Undocumented Windows のパクリだったりします(^^;)

そこのところは全然気が付いてませんでした(^^;


>実は、アドインを作って頂くと、検証になるので、私としても大変有り難いのです。ロボットを開発することで、人間の研究にフィードバックするのと、気持ちは同じです...

了解です(^^)
アドインを作成する過程でグラフィックのランタイムライブラリが出来上がっていきそうなので、コンパイラ本体が動き出す当初からグラフィックも実装できそうです(^^)


>Pxlコマンドは、変数 X と Y に論理座系の値を代入するので、ViewWindow と絡めると、全ての座標系を併せることも可能ですよね。

グラフを描かせるとかでなければ物理座標系で使うのが何かと都合がよいですね。


>すると、最終的な描画は、DLINE1.6 の破線と同じです。つまり、RclCapt は完全上書きする点で、RclPict と異なることが分かりました。

Pictは重ね合わせでCaptは上書きになるのを確認できました。


>この仕様の違いのために、ファイルサイズが違うという線で推測できますか?
>今、チョット考え中で、よくわかりません。

重ね合わせの処理の違いだけでファイルサイズが倍違っているというのはちょっと理解しがたい状況ですね。


>処理的には、ドットごとに Or とれば 重ね合わせになりますが、なぜファイルサイズが倍になるのか? 元画像データと Or するための作業領域か、結果画像領域かがイメージファイルに中に有るのでしょうか? ハードウェア上の制限からこの説を支持できますか?

メインメモリは64KBしかないので決して余裕があるとはいえず、Pictファイルのサイズは結構重要だと思うのですが、圧縮無しのベタ形式の上に画像データ以外の必要のないデータ?まで入ってるのはちょっと解せないですね。
もしかしたら、CFX-9850GC+がカラー4色で一画面あたりのデータ量が2KBになりますから、従来互換性のために?とかでしょうか。
がCFX-9850GC+にはCapture実装されてないことを考えると案外そのあたりかもしれません(^^;

PictファイルとCaptファイル

sentaro様


> アドインを作成する過程でグラフィックのランタイムライブラリが出来上がっていきそうなので、コンパイラ本体が動き出す当初からグラフィックも実装できそうです(^^)

あ、それは素晴らしいです。

テキスト画面とグラフィックス画面の2つを使い分ける Casio Basic の仕様を最初から作り込めるので、その方が良いかも知れません。

グラフィックスコマンドでプログラムが終わる場合、グラフィックス画面はそのまま残して、テキスト画面に一旦戻るのが Casio Basic です。このあたり、わざわざアドインに盛り込むべきかどうかと言うのも考えどころかも知れません。

BugTrace では、この仕様を利用して、描画結果を手動でPictファイルやCapt画面に取り込めます。sentaro様が作ってくださったアドインではこれができません。こう考えると、Casio Basicの仕様を忠実に実現するのも良いかも知れません。

一方で、電卓の各種機能を手動で使える状態をアドインで作る必要が出てきて、難易度が上がりそうでもあります。



> もしかしたら、CFX-9850GC+がカラー4色で一画面あたりのデータ量が2KBになりますから、従来互換性のために?とかでしょうか。
> がCFX-9850GC+にはCapture実装されてないことを考えると案外そのあたりかもしれません(^^;

なるほど、説得力あります。この推定に一票入れさせてもらます。

Pict と Capt

sentaro様

先週公開した Casio Basic入門 G08 に RclPict と RclCapt の違いについて追記しました。これは重要なので、きちんと残しておこうと思った次第。

チョット息切れ状態なので、今週の新しいエントリーは、Inside Casio Basic のみになっちゃいました。

ViewWindow対応 v2.0

管理人様、こんにちは!

ここのところ、Bug Traceアドイン内でCasioBasicのViewWindowを再現するべく作業してましたけどやっとこ動作するようになりました。

CasioBasicのグラフィックスはやはり一筋縄ではいかないですね。
完全に再現しようとするとなかなかに奥が深すぎます(^^;

ViewWindowの数値設定で右カーソル押しでなんと15桁まで数値が出てきて、それが横スクロールすることにびっくりしてしまいましたけど、そのせい、もとい、そのおかげでinp.cが0.9にバージョンアップになりました。

そして、ViewWindowからピクセル座標に変換するところでまた試行錯誤…、
ラインスタイル対応でまた試行錯誤、(ここはまだバグありです)
で、とりあえず、なんとか動くものができました。
管理人様のグラフィックス探索のおかげです(^^)

まだまだバグあり不完全状態なので詰めていかないといけない所多数ですが、とりあえずのアップです。

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

ベースはBug Traceなのでそこに追加という形でとりあえずは、というところです。

修正v2.0

グラフ関連(ズーム、トレース)で致命的なバグ(OS異常になる)があったので修正です(^^;
http://pm.matrix.jp/BugTraceVW200.zip
同じファイルの差し替えです。

Re: 修正v2.0

sentaro様

修正 Ver2.00 拝見しました。

cb.lib が出来ていて形が出来つつありますね。

ViewWindow設定画面まで出来たということは、大きな進歩!
一気にきましたね。ViewWindowがかなり重要なので、あとは細かな探索結果との整合性を併せる作業がメインになりそうに思います。

ところで、XminやXmaxなどのViewWindowで指定する専用変数6個の動作についてですが、これらを値を変更するとViewWindowコマンドを実行した時と同様に、グラフィックス画面が消去されるようです。Casio Basic入門G08では、消去しないと一旦書いたのですが勘違いのようなので、「調査する必要がある」と表現を修正しています。

これら変数の変更に伴う挙動の調査を進めようと思います。

いずれにせよ、これら変数は適宜モニタされていて、値変更のタイミングでの動作を記述する必要があります。予めそのつもりで準備されると良いと思います。


極座標については、sentaro様のライブラリでは実装済みですが、私としてはまだ調査が終わっていないので、これにも取りかかる必要があります。円や三角関数との絡みを調べる必要がありそうだと思います。

今分かっているのは、Circleを実行すると外接垂直線との接点の座標 (X, Y) が変数XとYに自動代入されることまでは分かっています(但し、条件によって円の左端か右端かが選択されます)。まだ十分に調査が終わっていないので、もう少し調査対象を広げて調べてからまとめる予定です(ネタバレですが...)。

v2.01

管理人様、こんにちは!

>cb.lib が出来ていて形が出来つつありますね。

まだ序の口の序の口ですが、今後の予定としては、コンパイラ本体がすぐにできるのならばそれが一番なのですが、まずはインタプリタから実装してみようかと思っています。
コンパイラでもInputの数値入力では数式を認識しないといけないので、数式評価はどうしても必要になりますし、そこができればインタプリタはすぐに出来そうかなと考えています。
そのためにはまずはinp.cを2バイト文字対応にして数式入力対応にしないとですね。


>ViewWindow設定画面まで出来たということは、大きな進歩!
>一気にきましたね。ViewWindowがかなり重要なので、あとは細かな探索結果との整合性を併せる作業がメインになりそうに思います。

ありがとうございます。
細かな部分の調整はまだこれからですが、グラフィックスはViewWindowsが肝なのでここが出来ないことには何も始まりませんね(^^;


>ところで、XminやXmaxなどのViewWindowで指定する専用変数6個の動作についてですが、これらを値を変更するとViewWindowコマンドを実行した時と同様に、グラフィックス画面が消去されるようです。Casio Basic入門G08では、消去しないと一旦書いたのですが勘違いのようなので、「調査する必要がある」と表現を修正しています。

そこのところは未確認でした。


>いずれにせよ、これら変数は適宜モニタされていて、値変更のタイミングでの動作を記述する必要があります。予めそのつもりで準備されると良いと思います。

専用変数は変数扱いだけじゃダメで関数扱いにする必要ありですね。


>極座標については、sentaro様のライブラリでは実装済みですが、私としてはまだ調査が終わっていないので、これにも取りかかる必要があります。円や三角関数との絡みを調べる必要がありそうだと思います。

んと、極座標はViewWindowで設定できるだけでまだ実体は実装しては無いです(^^;
XY座標でまだ詰めないといけない部分が多々あるので極座標対応はまだちょっと先になりそうです。


>今分かっているのは、Circleを実行すると外接垂直線との接点の座標 (X, Y) が変数XとYに自動代入されることまでは分かっています(但し、条件によって円の左端か右端かが選択されます)。まだ十分に調査が終わっていないので、もう少し調査対象を広げて調べてからまとめる予定です(ネタバレですが...)。

Circleは後回しになってましたけど、いろいろと細かな仕様がありそうですね。
そこのあたりは管理人様の探索力があればすぐに明らかになりそうです(^^)


細かなバグを修正したv2.01です。
http://pm.matrix.jp/BugTraceVW201.zip
- 変数入力でスクロールした場合一行目がおかしくなるのを修正しました。
- グラフトレース&ズーム処理を修正しました。

電卓本体で実行しても問題は起きないと思いますが、しばらくはSDKのエミュで実行する方が安全です(^^;

Re: v2.01

sentaro様

> 細かなバグを修正したv2.01です。
> http://pm.matrix.jp/BugTraceVW201.zip
> - 変数入力でスクロールした場合一行目がおかしくなるのを修正しました。
> - グラフトレース&ズーム処理を修正しました。
>
> 電卓本体で実行しても問題は起きないと思いますが、しばらくはSDKのエミュで実行する方が安全です(^^;

Ver2.1 をまだじっくりと確認中です。


Casio Basic入門G09を書きながら、ViewWindowの謎にハマってしまっています。なのでこの土日に公開できませんでした。

1つ言えることは、いわゆる Sketchコマンド(Plot, PlotOn, PlotOff, PlotChg, PxlOn, PxlOff, PxlChg, PxlTest()、Text, Circle、Line, F-Line, Vertical, Horizontal)は、内部で (Xmin==Xmax || Ymin==Ymax) をチェックして、真ならこれらの描画を行わずに Range ERROR を返して、そこでプログラム停止になることまで分かりました。
Casio Basicでは、Range ERROR 時には、これらコマンドの頭にカーソルが来ています(PxlTest は例外的に PxlTest(0,1) なら、0の後にカーソルが来て、Ymin==Ymaxでも同様)。


このエラーは保存されている Xmin, Xmax, Ymin, Ymax の値に依存するので、エラーが起こるプログラムを再起動しても、エラーは発生し続けます。これら変数の値を変更するか、ClrGraphを実行すると(デフォルトの論理座標が自動設定されるのて)このエラーの原因は解消します。ところが、ViewWindow コマンドで座標系の設定を行っても、エラーが解消されないことも分かってます。

これらコマンドの実装には必要な内部動作です。


で、XminとXmaxが等しいときに ViewWindowの座標設定を実行すると、実行直後に Range ERROR が発生する(エラー解消ができない)のですが、Ymin と Ymax が等しい時は、ViewWindowでエラーが発生しません。

ViewWindowの内部動作が、なかなか複雑そうで、尻尾を掴めきれていません。


じっくり追い詰める必要がありそうですが、上記 Sketchコマンドでのエラー処理は準備が必要です。


No title

管理人様、こんにちは!

今のところずっと数式評価とそれに関連してinp.cの変更作業ですがちょっと手間取ってます(^^;
sinとかcosとか内部表現では1バイト扱いでも表示上は複数バイトに展開されるのがちょっと面倒なところです。

ViewWindowsの、Xmin==XmaxとYmin==Ymaxの時はどうなる?と思ってもCasioBasic上での検証をせずに実装してたのですが、ここのあたりの仕様はなかなかに奥が深いですね。

>で、XminとXmaxが等しいときに ViewWindowの座標設定を実行すると、実行直後に Range ERROR が発生する(エラー解消ができない)のですが、Ymin と Ymax が等しい時は、ViewWindowでエラーが発生しません。

XdotはあるのにYdotが無いのと何か関係あるんでしょうかね。


>ViewWindowの内部動作が、なかなか複雑そうで、尻尾を掴めきれていません。
>じっくり追い詰める必要がありそうですが、上記 Sketchコマンドでのエラー処理は準備が必要です。

了解です。
まだCのライブラリで一応実装できたという初期段階なので細部の動作の詰めと実行時のエラー処理をどう実装するかというのがひとつの山ですね。

Re: No title

sentaro様

> 今のところずっと数式評価とそれに関連してinp.cの変更作業ですがちょっと手間取ってます(^^;
> sinとかcosとか内部表現では1バイト扱いでも表示上は複数バイトに展開されるのがちょっと面倒なところです。

一旦翻訳したCのソースに書き出すことを考えておられるのでしょうか?



> XdotはあるのにYdotが無いのと何か関係あるんでしょうかね。

何か関係ありそうですよね。アドインで用意されている各種機能を調べた方が近道かも知れないと感じています。


> 了解です。
> まだCのライブラリで一応実装できたという初期段階なので細部の動作の詰めと実行時のエラー処理をどう実装するかというのがひとつの山ですね。

エラー処理の内部処理のあぶり出しは色々なヒントを与えてくれると思って、取りあえず調べたら色々と出てきたので、エラーを出す条件を探しだすのが良さそうです。

数式対応 v2.20

管理人様、こんにちは!

>一旦翻訳したCのソースに書き出すことを考えておられるのでしょうか?

んと、今のアドインのままではライブラリの動作チェックや互換性の確認で毎回SDKでの作業になるので、電卓本体でもライブラリの互換テストができるようにCasioBasicのソースをそのまま実行できるインタプリタを実装しようと考えています。
そのための数式評価だったわけですけど、その要の数式評価に関しては一応動作するようにはなりました。
それに連動して入力部分のinp.cを数式入力に対応させてv0.9となりました。

まだ本体プログラムは虫プロのアドインのままですが、各変数の数値入力部分でライン入力準拠の数式入力が出来るようになったので簡易電卓っぽく使えます。
電卓本来の10進演算(内部15桁)に比べると、Cのdoubleでの倍精度浮動小数(有効桁数16桁弱)なので若干精度が上回る部分が出てきますが2進なので誤差がちょっとやっかいですね(^^;


ということで、数式入力をサポートしたv2.20です。
http://pm.matrix.jp/BugTraceVW220.zip
数式入力部分のバージョンアップなのでグラフ関連はバグ潰し以外は機能的には何も進化してないです(^^;

今後は管理人様のサンプルプログラムがそのまま実行できるようになるインタプリタ実装を進めていきたいと思っています(^^)

Re: 数式対応 v2.20

sentaro様

> まだ本体プログラムは虫プロのアドインのままですが、各変数の数値入力部分でライン入力準拠の数式入力が出来るようになったので簡易電卓っぽく使えます。

これで、?命令の実装の最大の難関をクリアしそうですね!
?命令を用いた、最も簡易なプログラムをアドイン化できるわけですね。


> 電卓本来の10進演算(内部15桁)に比べると、Cのdoubleでの倍精度浮動小数(有効桁数16桁弱)なので若干精度が上回る部分が出てきますが2進なので誤差がちょっとやっかいですね(^^;

ViewWindow座標系での ピクセル座標系への換算では四捨五入されていることが分かっているので、おそらく11桁目を四捨五入して10桁とするのが内部仕様ではないかと思われます。10桁の最下位の誤差1という仕様に合えば良いですね。

2進数の浮動小数点計算の誤差が4桁になることは無いのではありませんか?


ということで、数式入力をサポートしたv2.20です。
> http://pm.matrix.jp/BugTraceVW220.zip
> 数式入力部分のバージョンアップなのでグラフ関連はバグ潰し以外は機能的には何も進化してないです(^^;

了解です。


> 今後は管理人様のサンプルプログラムがそのまま実行できるようになるインタプリタ実装を進めていきたいと思っています(^^)

サンプルを沢山作っていて良かったです。

数値精度

管理人様、こんにちは!

>これで、?命令の実装の最大の難関をクリアしそうですね!
>?命令を用いた、最も簡易なプログラムをアドイン化できるわけですね。

はい、CasioBasicの?と同様の入力がアドインでも可能になりました(^^)

入力コマンドで数式での入力が出来るのは電卓ならではの特徴なのでコンパイラでもここは必須項目ですね。


>ViewWindow座標系での ピクセル座標系への換算では四捨五入されていることが分かっているので、おそらく11桁目を四捨五入して10桁とするのが内部仕様ではないかと思われます。10桁の最下位の誤差1という仕様に合えば良いですね。
>2進数の浮動小数点計算の誤差が4桁になることは無いのではありませんか?

はい、2進演算でも4桁も誤差が出ることはないですね。
CasioBasicの表示上は管理人様のおっしゃるとおり10桁に丸められるので11桁目四捨五入というところですが、ライブラリでは今のところは表示ルーチンで表示桁数で丸められるので内部演算での丸めはしてなくて、唯一、ゼロ判定で10^(-13)桁以下はゼロ判定にしています(^^;

CasioBasicのというか電卓での10進演算は前にちょっと調べた時は内部演算15桁で下2桁が四捨五入の判定に使われていて実質精度が13桁ぐらいだったと思います。

電卓のグラフアプリのViewWindowの設定画面で設定数値が15桁フルで出てくるので、あれは仕様上どうなのかというところですが、CasioBasicでも15桁精度で入力を受け付けるみたいなので表示は10桁だけど15桁入力可能という感じですね。

Re: 数値精度

sentarao様

今日やっとこさ、ViewWindow の変数に関する内容をアップしました。


> はい、CasioBasicの?と同様の入力がアドインでも可能になりました(^^)
> 入力コマンドで数式での入力が出来るのは電卓ならではの特徴なのでコンパイラでもここは必須項目ですね。

これこそ電卓を使う最大の利点ですよね。
お疲れ様です。



> 電卓のグラフアプリのViewWindowの設定画面で設定数値が15桁フルで出てくるので、あれは仕様上どうなのかというところですが、CasioBasicでも15桁精度で入力を受け付けるみたいなので表示は10桁だけど15桁入力可能という感じですね。

Xdot の値など、15桁は表示のみで、精度は10桁のままだと思っていますが、検証はまだだったりします。


今日アップした記事の最後に、各変数の関連を調べるプログラムを紹介しました。Xmin、Xmax、Xdot が互いに関連します。
プログラム上表示は10桁になってしますが...

No title

管理人様、こんにちは!

>今日やっとこさ、ViewWindow の変数に関する内容をアップしました。

おつかれさまです。
ViewWindowは要だけにかなり奥が深いですね(^^)


>これこそ電卓を使う最大の利点ですよね。
>お疲れ様です。

まだ内部的に1バイト扱いの一部の関数だけのサポートだけですけど、グラフ電卓だけに関数の数が半端ないですね。
全部の関数をサポートするまでにはまだまだバージョンアップする必要ありです(^^;


>Xdot の値など、15桁は表示のみで、精度は10桁のままだと思っていますが、検証はまだだったりします。

画面解像度が128ピクセルしかないですから、精度が10桁でもオーバースペックといえますが、一応計算は内部精度15桁で行われている感じですよね。


>今日アップした記事の最後に、各変数の関連を調べるプログラムを紹介しました。Xmin、Xmax、Xdot が互いに関連します。
>プログラム上表示は10桁になってしますが...

Xdotの仕様がちょっとひっかかるんですが、
Xmin>Xmaxの設定をするとXdotは負の数値になるので、
アドインのライブラリでは絶対値での計算ではなく、
Xdot=(Xmax-Xmin)/126
で計算してますけど、
CasioBasicではXdotに負の数値を設定するとエラーになるのはちょっと解せない仕様ですよね(^^;

というか、Xdotが正の数値という仕様とすれば、Xmin>Xmaxの設定でXdotが負の数値になるのがバグということに?

Xdotの仕様

sentaro様


> Xdotの仕様がちょっとひっかかるんですが、
> Xmin>Xmaxの設定をするとXdotは負の数値になるので、
> アドインのライブラリでは絶対値での計算ではなく、
> Xdot=(Xmax-Xmin)/126
> で計算してますけど、
> CasioBasicではXdotに負の数値を設定するとエラーになるのはちょっと解せない仕様ですよね(^^;


確かに Xmin=126、Xmax=0 と逆転させると、Xdot = -1 となります。Xmin = Xmax に設定すると Xdot = 0 になります。この時点では Range ERRORにならないのですが、何かSketchコマンドを実行すると、そこで Range ERROR になります。

一方、Xdot に 0以下の数を代入すると直ちにエラーになります。

従って、記事では Xdot を求めるのに絶対値計算にしたのは、エラーにならない条件ということなんです。

ですが、Xdotの自動更新直後は確かに 0 以下でもエラーにならないので、エラー発生の条件がよく分からないのが現状です。


> というか、Xdotが正の数値という仕様とすれば、Xmin>Xmaxの設定でXdotが負の数値になるのがバグということに?

ViewWindow の設定では、Xmin > Xmax が許容されます。Ymin > Ymax も同様で、座標方向の反転が可能です。なので、Xmin>Xmax でバグになってはマズイと思います。

例えば、

ClrGraph
CorrdOff
GridOff
AxesOff
LabelOff
ViewWindow 126,0,0,62,0,0
Text 1,1,Xdot
Text 7,1,Xmin
Text 13,1,Xmax
PlotOn 10,10

を実行すると、Xdot=-1、Xmin=126、Xmax=0 と表示され、画面右上を原点として (10, 10) にプロットされ、正常動作します。

Xmin, Xmax, Xdot は、おそらくですが、以前からある座標設定のための変数で、その時の仕様では Xdot が 0以下になっるとエラーになっていた。後から、座標設定の柔軟性を拡大するために ViewWindow で上のプログラムのようなことを可能にした。

だから、Xdot に直接アクセスしなければエラーにならないように内部仕様を少し変更した....そんなシナリオがあるかも知れないと、今は思っています。

但し ViewWindowは CFX-9850 では既に採用されているようなので、かなり昔のことです。それ以前に ViewWindow は実装されていなくて、座標系設定変数は既に有ったということなら、私の想像を裏付けるのでしょうが、そこはまだ調べていませんので、まだ思いつきの段階です。

ViewWindow は Goto のように互換性と機能拡張のためにかなり特殊なことをしている可能性があるかも知れません。

内部実装を想像する場合、Xdot 以外に内部管理している変数があって、この内部変数と Xdot がエラーの発生の条件を決めていると考えれば、かなりスッキリします。


ViewWindow は、かなり興味深いコマンドですね。

バグ修正v2.21

管理人様、こんにちは!

>確かに Xmin=126、Xmax=0 と逆転させると、Xdot = -1 となります。Xmin = Xmax に設定すると Xdot = 0 になります。この時点では Range ERRORにならないのですが、何かSketchコマンドを実行すると、そこで Range ERROR になります。
>一方、Xdot に 0以下の数を代入すると直ちにエラーになります。
>従って、記事では Xdot を求めるのに絶対値計算にしたのは、エラーにならない条件ということなんです。

了解です(^^)


>ViewWindow の設定では、Xmin > Xmax が許容されます。Ymin > Ymax も同様で、座標方向の反転が可能です。なので、Xmin>Xmax でバグになってはマズイと思います。

んと、Xdotが負数になってしまうのがバグ?という意味で、Xdotに正の数値しか認めないのであれば、Xmin>Xmaxの時でも絶対値計算で正の数で良いのではないかということなんです。

そもそもXdotは計算上は、
Xdot =(Xmax-Xmin)/126
なので、画面上の1ドットあたりのViewWindowにおける刻み幅の値ですから正数だけでもいいわけですよね。

実際、アドインのライブラリではXdotが絶対値のような使い方をしてしまったのでXmin<XmaxとXmin>Xmaxで分けて処理してしまってましたけど、Xdotが正負の値をとると考えれば場合分けしなくてもよいことに今気が付きました(^^;

Xdotは内部変数としての使い勝手で考えれば正負の値をとってくれないと都合が悪いので、変数として入力する場合に正の値しか認められないというのはやはりちょっと変に感じるところではありますね。


>但し ViewWindowは CFX-9850 では既に採用されているようなので、かなり昔のことです。それ以前に ViewWindow は実装されていなくて、座標系設定変数は既に有ったということなら、私の想像を裏付けるのでしょうが、そこはまだ調べていませんので、まだ思いつきの段階です。

そういえば、まだCFX-9850GC+が未チェックでした。
ってことでちょいと調べてみると、ViewWindowの項目にXdotがありませんしXdotという変数も無いです(^^;
他のXmin,Xmax,Xscl等は存在しています。
さらに桁数も内部桁フル15桁までは出なくて表示と同じ9桁までしか出ない仕様です。入力時の横スクロールも無いですし入力時の計算式もπと加減乗除程度でfx-9860GIIと比較すると必要最小限な感じですね。


>内部実装を想像する場合、Xdot 以外に内部管理している変数があって、この内部変数と Xdot がエラーの発生の条件を決めていると考えれば、かなりスッキリします。

いろいろと考えていると、Xdotはアドインのライブラリでもピクセル座標からViewWindow座標への変換の時くらいしか使い道がないので、内部計算上は意味があっても、変数として存在している意味がどうなのかというところですが、
CasioBasicでXdotに値を設定することの使い道としては、ViewWindowを使わずXminとXdotの設定でXmaxを自動的に計算するくらいしか思いつかないので、それだとYdotもあってもよさそうですし、何か一貫性がないように見えますね(^^;
ただ、この使い道だとXmin>XmaxではXdotは負数になる必要ありで負数設定がエラーになることの説明がつかないですね(^^;

Xdotが負数というのは、Xmin>Xmaxの場合ですが、X軸の左が大になるイレギュラーな設定はしてはダメということで、Xdotは正の数のみ限定にしたような感じがします。

Y軸の場合はピクセル座標と合わせるためにYmin>Ymaxが普通に使われると思うのでYdotがあれば負数も認めないとまずいと思うのですが、そもそもYdotが存在しないので真偽は謎ですね。


>ViewWindow は、かなり興味深いコマンドですね。

本当にここまで奥深いとは想像以上です(^^;


ということで、数式入力の細かなバグ潰しのv2.21です。
http://pm.matrix.jp/BugTraceVW221.zip
先頭が符号だとエラーになっていたのを修正しました。
機能的な変更はないです(^^;

Re: バグ修正v2.21

sentaro様

Casio Basic G09 での Xdot に関する記述を変更して、値を代入するときは絶対値を使った式、Xmin と Xmax から算出するときは絶対値無し、の場合分けにしました。

座標軸方向を逆転させた設定が可能な点は、、座標系設定の柔軟性があって重要ではないかと思います。従って Xdot が 0以下になることを許容すべきでしょうが、一方で Xdot に直接値を代入する機能は、お陰様で後から追加されたことを調べて頂いたので、これも活かす必要はありそうです。

そこで、

1) Xmin と Xmax に値を代入する関数
2) Xdotに値を代入する関数

の2つを用意して、

演算 1) では Xdot = (Xmax - Xmin) /126 を計算し、Xmin == Xmax で Range ERROR、但し Xdot が 負ではエラーにしない

演算 2) では Xdot = Xmin + Xdot を計算し、Xdot ==0 以下の場合に Range ERRORとする

といった感じの実装にしてはどうでしょうか?

Ymin と Ymax では、演算 1) と同等のものだけにして、内部的に Ydot を定義しておくの良いかも知れません。

ちなみに、Ymin == Ymax で Rnage ERROR になるのは、X座標設定と同じです。


> いろいろと考えていると、Xdotはアドインのライブラリでもピクセル座標からViewWindow座標への変換の時くらいしか使い道がないので、内部計算上は意味があっても、変数として存在している意味がどうなのかというところですが、
> CasioBasicでXdotに値を設定することの使い道としては、ViewWindowを使わずXminとXdotの設定でXmaxを自動的に計算するくらいしか思いつかないので、それだとYdotもあってもよさそうですし、何か一貫性がないように見えますね(^^;

なぜ Xdot を追加したのか、そこが推測できればすっきりするのですが...


> ということで、数式入力の細かなバグ潰しのv2.21です。
> http://pm.matrix.jp/BugTraceVW221.zip
> 先頭が符号だとエラーになっていたのを修正しました。
> 機能的な変更はないです(^^;

了解です!

No title

管理人様、こんにちは!

>座標軸方向を逆転させた設定が可能な点は、、座標系設定の柔軟性があって重要ではないかと思います。従って Xdot が 0以下になることを許容すべきでしょうが、一方で Xdot に直接値を代入する機能は、お陰様で後から追加されたことを調べて頂いたので、これも活かす必要はありそうです。

Xdotが正負の値をとるという仕様であれば何も悩まなくて済むところなのに、正の値以外は設定エラーというのが謎なんですよね。


>演算 1) では Xdot = (Xmax - Xmin) /126 を計算し、Xmin == Xmax で Range ERROR、但し Xdot が 負ではエラーにしない
>演算 2) では Xdot = Xmin + Xdot を計算し、Xdot ==0 以下の場合に Range ERRORとする
>といった感じの実装にしてはどうでしょうか?

はい、とりあえずそれで互換性は大丈夫そうですね(^^)

あ、2)の方はXdotの値だけの判断で負ならエラーとしてOkではないですか?


>Ymin と Ymax では、演算 1) と同等のものだけにして、内部的に Ydot を定義しておくの良いかも知れません。
>ちなみに、Ymin == Ymax で Rnage ERROR になるのは、X座標設定と同じです。

Ydotも同じ仕様ってことですね。
了解です(^^)


>なぜ Xdot を追加したのか、そこが推測できればすっきりするのですが...

そこなんですよね。
Xdotが無くて困ることがあるかといえば、たぶん無さそうですし、
この変数の存在意義がどこにあるかが鍵ですね。

Xdotに関わる計算

sentaro様


> Xdotが正負の値をとるという仕様であれば何も悩まなくて済むところなのに、正の値以外は設定エラーというのが謎なんですよね。

そこが、なんとも不思議な仕様ですよね。


> >演算 1) では Xdot = (Xmax - Xmin) /126 を計算し、Xmin == Xmax で Range ERROR、但し Xdot が 負ではエラーにしない
> >演算 2) では Xdot = Xmin + Xdot を計算し、Xdot ==0 以下の場合に Range ERRORとする
> >といった感じの実装にしてはどうでしょうか?
>
> はい、とりあえずそれで互換性は大丈夫そうですね(^^)
>
> あ、2)の方はXdotの値だけの判断で負ならエラーとしてOkではないですか?

そうでした、Xdot が0以下だとRange ERROR にする必要がありました。ただし Xdot に値が代入される時は、Xminの値に基づき Xmax を変更することが分かっていますので、これは追加する必要ありそうです。


> >Ymin と Ymax では、演算 1) と同等のものだけにして、内部的に Ydot を定義しておくの良いかも知れません。
> >ちなみに、Ymin == Ymax で Rnage ERROR になるのは、X座標設定と同じです。
>
> Ydotも同じ仕様ってことですね。
> 了解です(^^)

Ydotは内部管理変数ってことで...



> そこなんですよね。
> Xdotが無くて困ることがあるかといえば、たぶん無さそうですし、
> この変数の存在意義がどこにあるかが鍵ですね。

アドインでグラフ描画の機能がありますが、そこで使うために、後から増設した変数のような気がします。ただ Ydotが増設だれていないのが、依然として謎ですね。

どんな感じですか?

sentaro様

お久しぶりです。

Bugrace VW2.21 をじっくりと触ってみました。

各変数の確認や設定機能は良いですね。
F-Line, Horizontal, Vertical 以外の描画コマンドは、変数 X を必ず変更・更新し、Yの変更・更新をするものもあります。
それ以外の変更や更新が無いことを確認する必要もあるので、今後各コマンドを実装した時の確認には不可欠ですよね。

併せて、Xmin, Xmax, Xdot, Ymin, Ymax などの確認は、VW変数の確認 ([SHIFT] [F3] で出来ますね。


昨日、PxlOn について詳細をアップしたところです。PxlOff, PxlChg, PxlTest() については、追ってアップします。
PxlOnについては、物理座標系からデフォルト論理座標系への座標変換機能が実装のポイントになりそうですね。
併せて、とにかく X と Y をパラメータに設定したときには Argument ERROR を出すことも必要です。

直線を上端と左端に描画するとき、Thick と Broken 属性が設定されるときは、線の太さが変化する点、これもしっかりと実装されていることを確認しました。これについては、CG10/20 では異なるとのこと、併せて Thin 属性もありますので、ここだけは機種ごとに変える必要がありそうですね。

そろそろ、fx-CG20 の入手も真面目に考え中で、そこでの探索と動作確認も視野に入れようかと思っています。
以前、fx-CG10向けも同時に進めると言われていたのですが、如何でしょうか?


なお今後、ViewWindowによる極座標設定の探索、そしてグラフ描画機能の探索のための、下調べを始めようかと思いますが、これらのコンパイラプロジェクトへの実装を、後回しにするのか、まとめてやるのか、そのあたりはどうお考えでしょうか?

当方の Casio Basic探索プランをそれに併せるのも良いかと思っています。


コンパイラプロジェクト

インタプリタ実装中です。

管理人様、こんにちは!

ここのところずっとインタプリタ実装にかかりきりで、これが思いのほかかなり手間取ってしまってまして連日バグ潰しに追われてます(^^;
今のところ、実装コマンドはfx-5800P+グラフコマンド程度ですけど、なんとか動作する状況になってきました。
今週末には何かアップできる形になればと考えています。
細かい部分はまだ煮詰めないといけないのですが、各コマンドの細かい動作やエラー判定は管理人様の探索結果がとても役立っています。ありがとうございます(^^)

>昨日、PxlOn について詳細をアップしたところです。PxlOff, PxlChg, PxlTest() については、追ってアップします。
>PxlOnについては、物理座標系からデフォルト論理座標系への座標変換機能が実装のポイントになりそうですね。
>併せて、とにかく X と Y をパラメータに設定したときには Argument ERROR を出すことも必要です。

PxlOnの座標変換機能は全然気が付いてませんでした(^^;
グラフのトレースでは物理座標系からデフォルト論理座標系への座標変換があるので、CasioBasicではそういうところも考えているのかと考えるとなかなかに奥深い実装ですね。


>直線を上端と左端に描画するとき、Thick と Broken 属性が設定されるときは、線の太さが変化する点、これもしっかりと実装されていることを確認しました。これについては、CG10/20 では異なるとのこと、併せて Thin 属性もありますので、ここだけは機種ごとに変える必要がありそうですね。

ライン描画のスタイル属性はとりあえずの仮実装のレベルなので細かい点ではまだCasioBasicと違う部分があるので煮詰める必要ありです(^^;


>そろそろ、fx-CG20 の入手も真面目に考え中で、そこでの探索と動作確認も視野に入れようかと思っています。
>以前、fx-CG10向けも同時に進めると言われていたのですが、如何でしょうか?

公式SDKがあるfx-9860GII版が開発し易いのは間違いないので、まず基礎の部分をfx-9860GIIである程度完成させた後にCG10/20に一気に移植しようかと思っています。
管理人様がCG20をゲットされてCG20探索が始まると移植作業が先にということになるかもしれません(^^)

コンパイラに関してはインタプリタで苦労しているうちはまだまだ手を出すレベルにないので、もう少しインタプリタを煮詰めてからになりそうです。

Re: インタプリタ実装中です。

sentaro様


お疲れ様です。


> ここのところずっとインタプリタ実装にかかりきりで、これが思いのほかかなり手間取ってしまってまして連日バグ潰しに追われてます(^^;
> 今のところ、実装コマンドはfx-5800P+グラフコマンド程度ですけど、なんとか動作する状況になってきました。
> 今週末には何かアップできる形になればと考えています。


インタプリターだけでも、大変ですよね。お疲れ様です。

思った以上に早く進んでいるというのが、正直な感想です。

...とはいっても、これが出来ればコンパイラへグッと近づきそうですね(^^;)



> 細かい部分はまだ煮詰めないといけないのですが、各コマンドの細かい動作やエラー判定は管理人様の探索結果がとても役立っています。ありがとうございます(^^)

このくらいはお安い御用です。お役にたつのなら、とても嬉しいところです。

シンプルで敷居の低い Casio Basic で簡単プログラミング、そしてネイティブコードのスピードを達成するなんて、夢のプロジェクトですよね。

考えただけでワクワクします!!


> PxlOnの座標変換機能は全然気が付いてませんでした(^^;
> グラフのトレースでは物理座標系からデフォルト論理座標系への座標変換があるので、CasioBasicではそういうところも考えているのかと考えるとなかなかに奥深い実装ですね。

おそらく、グラフ機能で使われるものは Basic に実装しているということなのでしょう。
或いは逆に考えて、内部ルーチン Casio Basicで作られている可能性もありそうではないでしょうか?

すると、Plot コマンドで十字カーソルや CoordOn による XとYの座標値表示の機能が、とても納得ゆくわけです。


> ライン描画のスタイル属性はとりあえずの仮実装のレベルなので細かい点ではまだCasioBasicと違う部分があるので煮詰める必要ありです(^^;

S-L-Thick コマンドと SketxhThick F-Line などの違いの実装、そして前置コマンド SketchThick などの扱いが、インタープリタ実装では、考えどころではないかと思います。


> 公式SDKがあるfx-9860GII版が開発し易いのは間違いないので、まず基礎の部分をfx-9860GIIである程度完成させた後にCG10/20に一気に移植しようかと思っています。
> 管理人様がCG20をゲットされてCG20探索が始まると移植作業が先にということになるかもしれません(^^)

先ずは、fx-9860GII で進めて頂ければ、私としては有り難いです。CG20 を入試したとしても探索・検証には時間がかかると思いますので...


アドイン版CasioBasic ver.0.10 テスト版

管理人様、こんにちは!

週末どころか新しい週が始まってしまいましたけど、なんとかとりあえず遊べるレベルにはなったかなということで一応アップです(^^;
まだ実装しているコマンドが少ないので、管理人様のBasic講座のサンプルプログラムしか動作確認はとれてないですが、初期のBasic程度には使えるかなと思っています。

アドイン版とはいえ、使い方はCasioBasic準拠なので、すぐ分かると思います。
使い勝手部分ではfx-5800Pのいいとこ取りをちょこっと取り入れてみました。

まだバグがかなり潜んでいると思われるのでバグあぶり出しよろしくお願いいたします(^^;

あ、バグといえば、このエントリのCasioBasic版のBUGTRACEですが、本体Basicよりもかなり速いです(^^)


アドイン版CasioBasic ver.0.10 テスト版
http://pm.matrix.jp/CB/CBASIC010.zip

Re: アドイン版CasioBasic ver.0.10 テスト版

sentaro様

早速、頂きました。

かなり進みましたね! (^_^)/


で、コメント2つを削除して、改めてコメントします。

1.glm ファイルのストレージメモリへの転送方法
電卓本体での転送は出来ました。FA-124 での方法が分からないので、教えて頂けませんか?

2.幾つかのプログラムを試してみました。

(1) BUGTRACE.g1m
ブラフィックス描画が驚くほど早くなっていますね!
但し、Plot で[EXE]を押して十字カーソルが出るのですが、そこにプロットしてしまいます。[EXE]の2度打ちになっている感じです。十字カーソル表示の際は、少しウェイトを入れるのはどうでしょうか?


(2) HIT BLOW
アーカイブに収録している HIT & BLOW も正常動作するようです。
http://egadget2.web.fc2.com/archives/archives.html#fx9860GII_CasioBasic

Prog にも対応していて、プログラム呼び出しがうまくいっています。
ストレージメモリに転送する際、ファイル名にスペースやドットを使えないので、HITBLOW という名前にし、以下のサブルーチンファイルを転送しました。
S1HB345
S2HB345
S3HB345
S4HB345

(3) TEMPCONV
ダウンロード:http://egadget2.web.fc2.com/archives/TempConv.html

これは、入力ボックス IN Ver2.1G を使っていますが、正常動作しますが、1点気になることがあります。
摂氏温度で、[(-)] キーを使って、例えば -40 と入力すると、摂氏と華氏が共に -40 になるのですが、このマイナス記号が、[(-)] の符号ではなくて、減算記号(横線が少し長い)になってしまいます。
プログラム上は、符号は [(-)] で表示される短い横棒を表示するようになっているので、バグっている可能性が...

(4) 多桁円周率計算 PICALC5 + PIDISP
- PICALC5: http://egadget2.web.fc2.com/archives/picalc5.html
- PIDISP: http://egadget2.web.fc2.com/archives/pidisp.html
PICAL5 で計算が終わると、0 か 1 を入力させる画面が出てくるので、そこで 1 にすると PIDISP が呼び出され、10桁で成型した出力になります。

爆速になりました(^_^)/

(5) PYTHA.g1m
ピタゴラス数探索プログラム:http://egadget.blog.fc2.com/blog-entry-146.html
これも爆速です。キー長押し処理については、Do ループが回る回数で制御しているので、この回数を大きくすればOK。


つづく...

Re: アドイン版CasioBasic ver.0.10 テスト版

sentaro様

続きです...


(6) MCONTECAR.g1m
コンテカルロ法のシミュレーション
http://egadget.blog.fc2.com/blog-entry-181.html

これも爆速ですが、2点ばかり気になるところがあります。

・円の形が Casio Basic とアドインCBasic で異なります。おそらく計算精度の関係だと思います。

・πの値に表示桁数が違っていて、アドインCBasic は桁数が多すぎて、グラフィックスプロットエリアまで食い込んでしまいます。

これらは、既にご指摘の点だとは思いますが...

(7) VWLINE3
Casio Basic入門G07 で紹介した VW.LINE3
http://egadget2.web.fc2.com/archives/VW.LINE3.html

が、RclOict でエラーになります。

このプログラムを起動後、

Y-Value.V-Win Top?

で、63 を入力し、

Max Pict# '1 -20)?

で、例えば 10 を入力すると、破線が下から上へ描画され、

[{-}] キーで描画を停止。

下矢印を押してゆくと、Can't Open Code = -1 のエラー表示、

[EXIT] を押すと、さらにエラーで、RclPict の行にカーソルが表示された EDIT 画面になります。

StoPict と RclPict 関連だと思います。



3.EDIT画面
最上行の右に、88xxxxxx と8桁の数が表示されますが、これは何ですか?


以上、First Impression でした。

Re: アドイン版CasioBasic ver.0.10 テスト版

sentaro様

Plot コマンドで十字カーソルが表示される時ですが、Wait を入れるのではなくて、[EXE] キーが上がるまで次に進めない処理を入れる方が確実で良さそうですね。

Re: アドイン版CasioBasic ver.0.10 テスト版

sentaro様

Pict関係ですが、ストレージメモリへの書き込みが頻発して、ファイルの断片化⇒メモリ不足 になるようです。
Optimize すれは解決ですが...


ストレージメモリへの書き込みは、極力避けた方が良さそうですが、さてメインメモリへの書き込みは可能なのでしょうか?


早速のバグ出しありがとうございます(^^)

管理人様、こんにちは!

数値の表示がCの形式のままだったのは昨日アップした後に気が付いた所でしたけど、他は気が付いてなかったバグでした(^^;
すぐに直せるところは直してどんどんバージョンアップしていきたいと思います(^^)


>1.glm ファイルのストレージメモリへの転送方法

これはアドインのg1a形式ファイルの転送と全く同様にアップする感じになります。
一旦、右側にドロップした後にそのファイルを左側に持っていけばOkです。


>但し、Plot で[EXE]を押して十字カーソルが出るのですが、そこにプロットしてしまいます。[EXE]の2度打ちになっている感じです。十字カーソル表示の際は、少しウェイトを入れるのはどうでしょうか?

Plotの仕様がまだ把握できてなかったっぽいです。
最初のPlotでは点を打たずに次に実行した時にひとつ前のその点が打たれる仕様だったんですよね。
Lineの仕様を考えると合点がいきました。
現バージョンでは最初に点を打ってしまってましたので次回修正します(^^;


>・円の形が Casio Basic とアドインCBasic で異なります。おそらく計算精度の関係だと思います。

円をプロットする点の位置が微妙に違っているためだと思われます。Circleの描画仕様をもう少し詳しく調べないとです。


>Pict関係ですが、ストレージメモリへの書き込みが頻発して、ファイルの断片化⇒メモリ不足 になるようです。
Optimize すれは解決ですが...

Pictに関しては本体メモリにアクセスしたいところだったのですが、純正SDKのライブラリでは不可能なのでとりあえず勝手が分かってきたストレージメモリで実装したというところでした(^^;
CG10/20ではPictはストレージメモリ仕様なのでとりあえずのストレージでの動作というところでしたけど、やはりfx-9860GIIとしては本体メモリでの高速アクセスが肝ですよね。


>ストレージメモリへの書き込みは、極力避けた方が良さそうですが、さてメインメモリへの書き込みは可能なのでしょうか?

本体メモリへのアクセスが出来るはずの隠しシステムコールが自在に使えるようになればPictはもちろんメインメモリ上のプログラムファイルに直アクセスできるようになるはずです。

Plot の機能

sentaro様

Plot ですが、今回問題になっているのは、

Plot x,y◢

の動作です。

単に、Plot x,y とすれば、(x, y) に点を打ちます。

Plot x,y◢

とすると、(x, y) に十字カーソルが現れ、

この時

・矢印キーで、カーソルが移動
・ [EXE] を押せば、その座標に点を打つ

という動作になります。

Plot まとめ

sentaro様

Plot コマンドは、厄介だと思うので、その仕様の特徴を一通り網羅したプログラムを用意しました。

http://egadget2.web.fc2.com/archives/PLOT.html

一応ソースを書き出します。

ClrGraph
CoordOn
GridOff
AxesOn
LabelOn

ViewWindow -20,20,5,-5,15,5

Text 1,1,"Plot10,10"
Text 7,1,"EXE: Change ViewWindow"
Plot 10,10◢   
// [1] 点を打たず、十字カーソル出現

ViewWindow -10,30,5,-5,15,5
Text 1,1,"Plot 0,0 "
Plot 0,0,◢
// ViewWindow でグラフィックス消去
// [2] 但し、直前の Plot で打った点は消去されない

Text 1,1,"Plot -5.7,-2.4"
Plot -5.7,-2.4◢
// [3] 点を打たず、十字カーソル出現

Text 1,1,"plot      " // スペース11個
Plot ◢
// 座標指定無い時は、デフォルト論理座標の (0,0) へカーソル出すか点を打つ
// [4] 原点(0, 0) に十字カーソル出現(点を打たない)

Text 1,1,"Plot (0,0), (1,1) to (10,10)"
Text 7,1,"      " // スペース12個
For 0→X To 10
Plot X,X // ◢ 無いので、10個の点を打つ
Next

Text 1,1,"EXE: ClrGraph & AxesOff "
Text 7,1,"   Then Plot"◢

ClrGraph
AxesOff
Plot
// ClrGraph でデフォルトの論理座標系に戻る
// [5] プログラム最後に Plot があると Plot ◢と同じ動作になる
// つまり、点を打たずに十字カーソル出現


これを CBasic で実行して、オリジナルの Casio Basic と動作が異なる点のみを抜き出します。

[1] のコメントと動作が異なります。点を打ってしまっています。

[2] のコメントと動作が異なります。直前の Plot 10,10 の点が残っているべき。

[3] のコメントと動作が異なります。点を打ってしまっています。

[4] のコメントと動作が異なります。点を打ってしまっています。

[5] のコメントと動作が異なります。プログラム最後の Plot が Plot ◢と同じ動作になっていません。

特に、最後の [5] はくせ者ではないでしょうか?
EOFの検出などで判定できれば良いのですが...


Plot まとめ(2)

sentaro様

> 特に、最後の [5] はくせ者ではないでしょうか?
> EOFの検出などで判定できれば良いのですが...

これですが、Casio Basic の仕様として考える場合、テキスト画面とグラフィックス画面の2つを持っていて、グラフィックスコマンドが実行されるとグラフィックス画面が前に出てきて、テキストコマンドが実行されるとテキスト画面が前に出てきます。
そして、プログラム終了時には、必ずテキスト画面が前に出てきます。

ここで、Plot コマンドは、プログラムが順次動作して次にグラフィックスコマンドが実行されない時は、十字カーソルを表示し、次にグラフィックスコマンドが実行される時は点を打つと考えると、一貫性が出てきます。

◢ 命令の Wait の機能により、次に連続してグラフィックスコマンドが実行されないので、十字カーソルが現れます。
プログラム最後に Plot があると、グラフィックス画面は HLT の状態で、テキスト画面へ切り替わってからプログラム終了しようとします。つまり、待ちの応対なので同様に十字カーソルを表示します。

Plot と PlotOn では Plot の方が動作速度がかなり遅いのは、制御構造をモニターして Wait無しに次に実行されるグラフィックスコマンドがあるかどうか判定しているのではないかと、推測しています。

なので、Plot のデフォルトの動作は、次に Wait無しのグラフィックスコマンドが無ければ、十字カーソルを表示し、有れば点を打つという感じではないかと思います。

EOFを見るというのはテクニックとしてアリかも知れませんが、上のように考えると EOFチェックは本来の動作ではないかと思われるので、以上を併せてコメントしました。

CBasicでのPlot内部動作

sentaro様

結局、Plot をインタープリタ実装する際、

Plot の次に ◢ があるかどうか、および EOFがあるかどうかをチェックし、いずれかがあれば、十時カーソル表示して点を打たない、いずれも無ければ点を打つ、といった実装方法が現実的だろうなぁ、と思います。

あと、ViewWindow 実行時のグラフィックス画面消去で、直前に Plot で打った点は消去しないことも、実装する必要があります。

グローバル変数で、Plot用の構造体を設定し、メンバにPlot による点描画フラグと、点描画座標値 x と y を入れておき、

Plot で点描画するときにフラグをを立てて構造体メンバの点の座標値を更新、それ以外のグラフィックスコ描画コマンド実行時にフラグを降ろすようしておけば、

ViewWindow実行時に、フラグが立っていれば、グラフィックス画面消去後に構造体メンバに保存されている座標に点を描画する......

こんな感じもありかな、と思います。


如何でしょうか?

アドイン版CasioBasic ver.0.20 テスト版 その2

管理人様、こんにちは!

Plotの仕様の把握にちょっと手間取ってしまいましたけど、
管理人様のテストプログラムのおかげでなんとか把握できてきました。

今回実装したPlot仕様は、

Plotコマンド本体の処理は画面上の座標を選択するコマンドであるということで、
Plotコマンドが実行された時にグラフィック画面がPlotモードに入ります。
(予約されたピクセルがある場合は描画します)
他のグラフィックコマンドが実行されるまでPlotモードが継続です。

Plotモード継続中に ◢ コマンドが来た場合(Plot直後でなくても可)、
グラフィック画面に十字カーソルを出して手動での座標選択モードに入ります。
実行中画面がテキスト画面の場合はグラフィック画面に切り替える必要ありです。
[EXE]で座標選択、[EXIT]では未選択で終了ですがその時点での座標が次回描画用に予約されます。

Plotコマンドの後に ◢ がない場合は、座標をピクセル座標で決定&予約します。(その時点では描画はしません)
次回Plotコマンド実行時にそのピクセルを描画します。
ViewWindowが変更された場合は以前のViewWindowで確定されたピクセル座標での描画になります。

Plotコマンドの直後が[EOF]の場合は[EXE]ですぐにピクセル描画します。[EXIT]では終了しません。

これで管理人様のチェックプログラムは一応同じように動作するようになったと思います。
まだ隠された仕様があるかもしれないので、さらなる厳しいテストお願いします(^^)


アドイン版CasioBasic ver.0.20 テスト版
http://pm.matrix.jp/CB/CBASIC020.zip

Re: アドイン版CasioBasic ver.0.20 テスト版 その2

sentaro様

Cbasic Ver0.20 を頂きました。

テストプログラム PLOT.g1m は正常に動作することを確認しました。

併せて、以下のプログラム PLOT1.1 を実行した後、PLOT1.2 を実行して、動作確認してみました。


ファイル名: PLOT1.1
ClrGraph
CoordOff
GridOff
AxesOn
LabelOff

Plot2,2


ファイル名: PLOT1.2
Plot 1,1


(オリジナルの) Casio Basic では、PLOT1.1 実行後 [EXE] を押す、或いは [EXIT] を押すかして終了させます。その後 PLOT1.2 を実行すると、PLOT1.1 終了時のカーソル位置或いは プロットした位置にプロットされます。

実は、この仕様については、これまで気付いていませんでした。

で、CBasic 0.20 では、この動作が再現されていないようです。


=====

あと、[(-)] キーを押した時にマイナス記号になる動作も、正しく符号になるよう修正されていることを確認しました。

次に、VW.LINE3.g1m 実行に関するエラーですが、Pict # が 10 を超えるとエラーになるようです。1桁時のエラーは出なくなっているようです。

CBasic Ver 0.20 その他のテスト

sentaro様


1.コード入力
Ver0.20 で確認しましたが、一通り入力できるようになっているようですね。
コマンド入力は、[SHIFT]+[VARS]、[OPTN] と [VARS] そして、[SHIFT]+[4](CATALOG) まで対応していることが確認できました。さらに、大文字小文字の入力や記号入力もできした。コメントアウト記号もメニューから選べるのは有り難いです。
1つコマンドを入力したら、次の入力時にはメニュー位置が前に選んだところになって、頭に戻らないのも、使いやすくて良いと思います。
メニューでコード選択時に、←や→で、ページ切り替えができると、さらに良いと思います。

ほぼ完成に近い感じですね!


2.旧来の出力命令: " "
fx-5800P 準拠になっていて、この方が良いですね。

CBasic 上で、以下を入力して実行してみました。

Locate 17,1,"RIGHT"
"LEFT"

fx-9860GII のように " " 命令が1行を占拠することがなく、fx-5800P の仕様になっていますね。絶対これが良いと思います。

ところで、Locate コマンドですが、以下のように本来エラーが出るコードにしてみました。

Locate 18,1,"RIGHT"

エラーの実装はまだのようですね。右端の "T" が表示されず、RIGH と表示されました。


3.旧来の入力命令:?
CBasic上で、以下のように入力して実行してみました。

Locate 17,1,"RIGHT"
"INPUT"?A

fx-5800P 準拠で動作できますね。これも私は支持します。良いですね。

1つ気になったのは、オリジナルの Casio Basic では、カーソルの位置です。
既に変数Aに格納された値が表示されますが、カーソルが左端にあって、Aの値の表示の左に入力が繋がってしまいます。
この場合は、カーソルを1行下げて表示させたほうが良いと思います。


4.モンテカルロ法のシミュレーション
円描画と数値の表示桁数も修正されていることを確認しました。
キースキャンによる速度低下も無さそうで、逆にターボ機能が効かないことも確認しました。


あっという間の進歩ですね。相変わらず、仕事の速さには恐れ入ります。

Casio Basic では処理時間が長くなるプログラムが、CBasicでは高速になるのが、Cbasic インタプリタの最大の利点ですので、CBasic で以下のコードを入力して実行してみました。楽にコーディングして、高速描画を実感できました。

ClrGraph
CoordOff
GridOff
AxessOff
LabelOff
ViewWindow 0,126,0,0,62,0
For 0→B To 62
For 0→A To 126
MOD(A+B,2)⇒PlotOn A,B
Next
Next


これぞ、Cbasicインタプリタの醍醐味ですね! (^_^)/


Re: アドイン版CasioBasic ver.0.20 テスト版 その3

sentaro様

PlotOn と F-Line


同じ描画亜結果になる、以下の2つのコードの処理時間を比較してみました。

PlotOnによる千鳥格子
ClrGraph
CoordOff
GridOff
AxesOff
LabelOff
ViewWindow 0,126,0,0,62,0

For 0→B To 62
For 0→A To 126
Mod(A+B,2)⇒PlotOn A,B
Next
Next


F-Lineによる千鳥格子
ClrGraph
CoordOff
GridOff
AxesOff
LabelOff
ViewWindow 0,126,0,0,62,0

For 0→A To 126
SketchDot F-Line 0,A,126-Mod(A,2),A
Next


描画速度を比べてみると、F-Line を使う方が、かなり速くなります。
オリジナルの Casio Basic の速度差よりも顕著な感じがします。

逆に言えば、PlotOn が遅いということもできますが、このあたり何か原因がありますでしょうか?


CBasic Ver0.20 のテスト4

sentaro様

PYTHA.g1m が、Ver 0.20 では、◢ 実行ごとに、表にDone 表示が出てきてしまいます。

Done表示のタイミングの修正が必要のようです。


アドイン版CasioBasic ver.0.21 テスト版 その2’

管理人様、こんにちは!

詳細なテストどうもありがとうございます(^^)
仕様の違いは気が付いてないことばかりなのですごく助かります。

Plotコマンドは今回のバージョンアップでほぼ直ったと思われるのですが、

>Locate 18,1,"RIGHT"
>エラーの実装はまだのようですね。右端の "T" が表示されず、RIGH と表示されました。

これは純正CasioBasicでエラーにならないのですが…何かリストに違いはあるでしょうか?


>1つコマンドを入力したら、次の入力時にはメニュー位置が前に選んだところになって、頭に戻らないのも、使いやすくて良いと思います。
メニューでコード選択時に、←や→で、ページ切り替えができると、さらに良いと思います。

了解です。
この際、コマンド選択方法はfx-5800Pそっくりにしてしまうのもありでしょうか?(^^)


>既に変数Aに格納された値が表示されますが、カーソルが左端にあって、Aの値の表示の左に入力が繋がってしまいます。
>この場合は、カーソルを1行下げて表示させたほうが良いと思います。

変数値は右寄せでfx-5800Pそっくり仕様に変更しました。これはfx-FD10Proとも同じ仕様でもありますね(^^)


>キースキャンによる速度低下も無さそうで、逆にターボ機能が効かないことも確認しました。

ターボはターボで面白いのですが画面表示が無い場合はただ遅くなるだけのウエイトなので…(^^;
そもそもSDKのキースキャンは遅すぎなのでそれは使わずに最小限の高速スキャンルーチンに変更しました。GetKeyもそれで実装してあります。
そのせいか、一部キー入力が変になることがあります。
例えば、最初はCATALOG入力が出来るのに一回インタプリタを実行させるとその後は使えなくなってしまうとか…。
このあたりはキースキャン内部仕様の調査が必要なようです。


>逆に言えば、PlotOn が遅いということもできますが、このあたり何か原因がありますでしょうか?

F-LineはPlotOnを使ってのループ処理ではなく、DDAで整数演算を使って始点から終点まで一気に描いてからLCD転送なのでかなり速いです。
PlotOnはドット毎に座標変換入りますし、エラーチェックも毎回なのでその分は遅くなります。
とはいえ、LCD転送制御のおかげで座標変換の必要の無いPxlOnとの速度差は無いに等しいのですが…。

現在のグラフィック描画が比較的速いのはLCD転送を秒間30フレームというようにフレームレート処理しているので無駄なLCD転送が無いためです。
このために真面目に毎回LCD転送するSDKのCのアドインよりも数倍は速いということになっています。
つまりグラフィックに関してはコンパイラになっても速度向上はほとんどない可能性大です(^^;
コンパイラで速くなるのは純粋な演算部分がどれだけあるかにかかってますね。


ということで、以上、修正版です。

アドイン版CasioBasic ver.0.21 テスト版 その2’
http://pm.matrix.jp/CB/CBASIC021.zip

管理人様ご指摘のバグはほぼ直ったと思われるのですが、
まだまだ未確認修正箇所&バグはあるはずなのでバグ出しテストよろしくです(^^)

あ、エディタの時の右上の8桁はメモリ使用状況を確認するために内部バッファアドレスを表示してあります。
テスト版だけの仕様です。

数値表示はNormal1、Normal2実装で、CasioBasic互換に近づけましたけど、数値精度の問題で若干の差異はあるかもしれません。

No title

数値入力に不具合がありましたので
↑ver.0.21差し替え修正しました。

アドイン版CasioBasic ver.0.21 テスト版 その2’

sentaro様

バージョンアップ、ありがとうございます。

> Plot コマンドは今回のバージョンアップでほぼ直ったと思われるのですが、

はい、そのように思います。


> >Locate 18,1,"RIGHT"
> >エラーの実装はまだのようですね。右端の "T" が表示されず、RIGH と表示されました。
>
> これは純正CasioBasicでエラーにならないのですが…何かリストに違いはあるでしょうか?

すみません、私の勘違いだったようです。


> この際、コマンド選択方法はfx-5800Pそっくりにしてしまうのもありでしょうか?(^^)

はい、断然ありだと思います。


> 変数値は右寄せでfx-5800Pそっくり仕様に変更しました。これはfx-FD10 Proとも同じ仕様でもありますね(^^)

はい、値の出力は右端に統一されて、Casio Basic と同じになりましたね。


> そのせいか、一部キー入力が変になることがあります。
> 例えば、最初はCATALOG入力が出来るのに一回インタプリタを実行させるとその後は使えなくなってしまうとか…。
> このあたりはキースキャン内部仕様の調査が必要なようです。

あ、本当だ! 気がつきませんでした。


> F-LineはPlotOnを使ってのループ処理ではなく、DDAで整数演算を使って始点から終点まで一気に描いてからLCD転送なのでかなり速いです。
> PlotOnはドット毎に座標変換入りますし、エラーチェックも毎回なのでその分は遅くなります。
> とはいえ、LCD転送制御のおかげで座標変換の必要の無いPxlOnとの速度差は無いに等しいのですが…。
>
> 現在のグラフィック描画が比較的速いのはLCD転送を秒間30フレームというようにフレームレート処理しているので無駄なLCD転送が無いためです。

PlotOn の負荷が大きいということで、納得です。


> このために真面目に毎回LCD転送するSDKのCのアドインよりも数倍は速いということになっています。
> つまりグラフィックに関してはコンパイラになっても速度向上はほとんどない可能性大です(^^;
> コンパイラで速くなるのは純粋な演算部分がどれだけあるかにかかってますね。

インタープリター版では、サブルーチンを呼び出すプログラムが正常に動作しているので、コンパイルでは最終的に1つのファイルにできませんか?


> 管理人様ご指摘のバグはほぼ直ったと思われるのですが、
> まだまだ未確認修正箇所&バグはあるはずなのでバグ出しテストよろしくです(^^)

はい、引き続き調べてみます。


> あ、エディタの時の右上の8桁はメモリ使用状況を確認するために内部バッファアドレスを表示してあります。
> テスト版だけの仕様です。

了解です。


> 数値表示はNormal1、Normal2実装で、CasioBasic互換に近づけましたけど、数値精度の問題で若干の差異はあるかもしれません。

これも助かります。


ところで、エディタのファイル名入力で使える文字が増えたことを確認しました。

エディア関係での要望です。

1) ファイル名の Rename 機能は追加できませんか?

2) 1ファイル内、および複数ファイル間で、Cut & Past機能を実装できないでしょうか?これは、CBasic を使う大きな利点になると思うし、是非とも欲しい機能です。

3) Memory Manager で、g1mファイルを ROOTへコピーする際、ファイル名入力の際に元のファイル名をデフォルトで表示できると、資産の移行に大変便利だと思います。


注文ばかりですみませんが、ご検討頂けると幸いです。

アドイン版CasioBasic ver.0.30 テスト版 その3

管理人様、こんにちは!

fx-5800P準拠のコマンド選択画面を追加してみました。
エディタ画面で[F3]でコマンド選択になります。
これでfx-5800Pの使い勝手をかなり取り込めた感じになったでしょうか。

それからRenameとエディタでのCut & Past機能を実装しました。
管理人様がおっしゃるようにCut & Pastがあるとないとでは大違いですね。
次期fx-5800Pにもぜひ欲しい機能です。


>3) Memory Manager で、g1mファイルを ROOTへコピーする際、ファイル名入力の際に元のファイル名をデフォルトで表示できると、資産の移行に大変便利だと思います。

これに関しては本体側の機能なので、将来的に本体RAMにアクセスできるようになった時にアドイン側で実装してみたいと思います。
現状、Aとか一文字ファイルネームでコピーしておいてもアドインの方では本来の名前でファイル名を認識するのでアドイン上で簡単にRenameできます(^^)


アドイン版CasioBasic ver.0.30 テスト版 その3
http://pm.matrix.jp/CB/CBASIC030.zip

今回はBasic機能は変更は無いです(^^;


>インタープリター版では、サブルーチンを呼び出すプログラムが正常に動作しているので、コンパイルでは最終的に1つのファイルにできませんか?

コンパイルされたプログラム毎にそれぞれアドインを作成するということでしょうか?

ちょいバグ(^^;

アドイン版CasioBasic ver.0.30 テスト版 その3
差し替え再アップしました。

Re: アドイン版CasioBasic ver.0.30 テスト版 その3

sentaro様

Ver 0.30 を頂きました。ありがとうございます。


> これでfx-5800Pの使い勝手をかなり取り込めた感じになったでしょうか。

はい、使い勝手が格段に向上したと思います。


> それからRenameとエディタでのCut & Past機能を実装しました。

これの操作がよく分からないので、教えていただけませんか?


> 次期fx-5800Pにもぜひ欲しい機能です。

私からも御願いしたいです>カシオ殿


> 現状、Aとか一文字ファイルネームでコピーしておいてもアドインの方では本来の名前でファイル名を認識するのでアドイン上で簡単にRenameできます(^^)

そうか、g1mファイルの頭にファイル名が記録されているので、それを使っているのですね。
これ、良いです。便利です。


> 今回はBasic機能は変更は無いです(^^;

了解です。

Inside Casio Basic の拡充と同期して、改めて各コマンドのテストを進めようと思います。


> >インタープリター版では、サブルーチンを呼び出すプログラムが正常に動作しているので、コンパイルでは最終的に1つのファイルにできませんか?
>
> コンパイルされたプログラム毎にそれぞれアドインを作成するということでしょうか?

はい、その選択肢もあると良いと思いました。その場合は、メインプログラムからCallするサブルーチンも埋め込んで、アドインはファイル1つにしてしまうというアイディアです。

但し、各ファイルをコンパイルしたものを Prog List に表示させ、インタプリターと同じように使うという計画だと思っていて、
確かにこの方法の方が、メモリを無駄にしないで良いとは思います。


如何お考えでしょうか?

アドイン版CasioBasic ver.0.31 テスト版 その3.1

管理人様、こんにちは!

カーソル移動に若干違和感というか、バグがあったので修正しました。

アドイン版CasioBasic ver.0.31 テスト版 その3.1
http://pm.matrix.jp/CB/CBASIC031.zip



>はい、使い勝手が格段に向上したと思います。

fx-5800Pのいいところはどんどん取り入れたいですね。
fx-FD10Proのいいとこ取りもすれば、最速最強の互換CasioBasicになるかも?(^^;


>これの操作がよく分からないので、教えていただけませんか?

RenameはRenameしたいファイルを選択してから[F4]でファイル入力ポップアップが出るので名前変更して[EXE]で決定です。

Cut & Past機能はCasioBasic(マニュアル1-8)とほぼ同仕様にしたつもりですが、
エディタで始点になるところにカーソルを持っていってから、[SHIFT]+[8]CLIPでCut & Pastモードに入ってカーソルのマークが変わります。
その状態でカーソル移動すると選択範囲が反転表示されます。
反転表示されている状態で
[F1] COPY (バッファに選択範囲がコピーされます)
[F2] CUT  (バッファに選択範囲がコピーされた後、選択範囲が削除されます)
これでCut & Pastモードから抜けて通常モードになります。
(カーソルキー[F1]F2]キー以外のキーを押してもCut & Pastモードから抜けます。)

Pasteは[SHIFT]+[9]PASTEで現在のカーソル位置にバッファの内容が挿入されます。
バッファの内容はアドインを終了するまで有効です。


>そうか、g1mファイルの頭にファイル名が記録されているので、それを使っているのですね。

はい、g1mファイルの内部にファイル名があるのでコピーする時のファイル名はどうでもよいのですね。
そのせいで、リネームはファイルの書き直しになってしまいます(^^;

>Inside Casio Basic の拡充と同期して、改めて各コマンドのテストを進めようと思います。

まだ互換度は50%程度だと思いますが、よろしくお願いいたします(^^)



>その場合は、メインプログラムからCallするサブルーチンも埋め込んで、アドインはファイル1つにしてしまうというアイディアです。

パソコン上だとそれが普通なのですが、メモリ制限もきついので(^^;


>但し、各ファイルをコンパイルしたものを Prog List に表示させ、インタプリターと同じように使うという計画だと思っていて、

やはり、現状ではこっちの方法がベストかなと思っています。
コンパイル速度にもよりますが、実行前コンパイルでもいけるかもしれません。

完全バイナリのコンパイラまではまだ時間かかりそうですし、その前段階ということでまずはバイトコードコンパイルを試してみようと思います。

Re: アドイン版CasioBasic ver.0.31 テスト版 その3.1

sentaro様

Ver 0.31 をいただきました。
ありがとうございます。

Edit画面で、[ALPHA] あるいは [SHIFT]+[ALPHA] としたとき、カーソルが変化しません。ここは入力モードを示すようにしたほうが良いように思いますが、、如何でしょうか?


一方、ファイル名入力時は、[ALPHA] あるいは [SHIFT]+[ALPHA] とすると、カーソルが ALPHAモードであることを示し、[SHIFT] で カーソルが SHIFTモードであることを示します。

コード入力とファイル名入力では SHIFT モードや ALPHAモードの取扱を変えているようですが、何か意図がありますか?



NEW で新しいファイルを作る際、ファイル名入力では、デフォルトで ALPHAモード Off になっています。これには何か意図がありますか? どちらが良いのか、私にはハッキリしないのですが、特に意図がありますか?
Casio Basic の Prog Edit の仕様に揃えるなら、デフォルトで ALPHAモードですよね?


さて、[F2] (NEW)でファイル名入力時に ALPHAモードにすると、空の EDIT画面でも ALPHAモードのままになりますが、これは解除した方が良いように思います。


また、EDIT画面でALPHAモードになっている時、[F3] (CMD) でコマンドリストを表示する時は、ALPHAモードが解除される方が良いと思います。さらに、EDIT画面に戻った時には、[F3] を押す前の 入力モードに戻してくれるとさらに良いと思います。


ところで、[F3] (NEW) で EDIT画面を表示し、[SHIFT]+[ALPHA] にして、ここで [F3](CMD)でコマンドリストをポップアップさせ、テンキーを押すと、当然受け付けません(ALPHAモードになっているため)。この時、[ALPHA] を押してテンキーが入力できるようにし、例えば [1] キーを押して 1:? を選ぶと、コードの最初に ? が表示されます。

何度かこの操作を行っている時、たまに ? wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww ..... と表示されることがあります。 wwwww は複数行に表示されます。

再現条件が見つかっていません(すみません)が、何かありそうです。

=====

> >その場合は、メインプログラムからCallするサブルーチンも埋め込んで、アドインはファイル1つにしてしまうというアイディアです。
>
> パソコン上だとそれが普通なのですが、メモリ制限もきついので(^^;

了解です。


> >但し、各ファイルをコンパイルしたものを Prog List に表示させ、インタプリターと同じように使うという計画だと思っていて、
>
> やはり、現状ではこっちの方法がベストかなと思っています。
> コンパイル速度にもよりますが、実行前コンパイルでもいけるかもしれません。

実行前コンパイルも良いかも知れませんね。

> 完全バイナリのコンパイラまではまだ時間かかりそうですし、その前段階ということでまずはバイトコードコンパイルを試してみようと思います。

ステップバイステップですね!

最終的には、バイナリファイル作成⇒CBasicのリストから実行、というオプションとアドイン作成のオプションも有るほうが良いように思います。

電卓プログラミング普及という視点が私の頭から離れないのが、その理由です。


=====

ところで、RclCapt コマンドの実装はお考えですか?



アドイン版CasioBasic ver.0.32 テスト版 その3.2

管理人様、こんにちは!

>Edit画面で、[ALPHA] あるいは [SHIFT]+[ALPHA] としたとき、カーソルが変化しません。ここは入力モードを示すようにしたほうが良いように思いますが、、如何でしょうか?

Cut & Pastを追加した時にエンバグったようです(^^;


>コード入力とファイル名入力では SHIFT モードや ALPHAモードの取扱を変えているようですが、何か意図がありますか?
>NEW で新しいファイルを作る際、ファイル名入力では、デフォルトで ALPHAモード Off になっています。これには何か意図がありますか? どちらが良いのか、私にはハッキリしないのですが、特に意図がありますか?>Casio Basic の Prog Edit の仕様に揃えるなら、デフォルトで ALPHAモードですよね?

これは意図的にというか、ALPHAモードに設定する方法が見つけられていないので、CasioBasic同仕様にしたくても出来ないでいるというのが本当のところです。
ということなので、その方法が見つかるまでは今の仕様のままです(^^;


>ところで、[F3] (NEW) で EDIT画面を表示し、[SHIFT]+[ALPHA] にして、ここで [F3](CMD)でコマンドリストをポップアップさせ、テンキーを押すと、当然受け付けません(ALPHAモードになっているため)。この時、[ALPHA] を押してテンキーが入力できるようにし、例えば [1] キーを押して 1:? を選ぶと、コードの最初に ? が表示されます。

うわ、これは気が付いてませんでした。
[ALPHA]モードでもそのまま入力可能なように修正しました。


>何度かこの操作を行っている時、たまに ? wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww ..... と表示されることがあります。 wwwww は複数行に表示されます。

たぶん、まだエディタは実装途中なのでバグありですね(^^;
今回の修正で直っているか新たなバグが発生したのか、まだ怪しげなことになる恐れありです(^^;


>ステップバイステップですね!

はい!
ある程度の土台が出来上がれば、後は機能追加していくだけなので少しずつ積み上げたいと思います(^^)


>最終的には、バイナリファイル作成⇒CBasicのリストから実行、というオプションとアドイン作成のオプションも有るほうが良いように思います。

アドインによるアドイン作成はかなり内部仕様に迫る必要ありですね。
バイナリコンパイラが出来上がる頃にはそれも可能になればと思います(^^)


>電卓プログラミング普及という視点が私の頭から離れないのが、その理由です。

今回のコンパイラプロジェクトでCasioBasicが超高速になることで守備範囲が広がることを期待したいです。


>ところで、RclCapt コマンドの実装はお考えですか?

メインメモリアクセスが出来るようになればメインメモリ仕様のPictと併せて実装予定です。


ってことで、修正版です。

アドイン版CasioBasic ver.0.32 テスト版 その3.2
http://pm.matrix.jp/CB/CBASIC032.zip

今回よりエディタを[CR]で区切られた論理行単位表示からCasioBasic同様の物理行単位の表示に変更しました。
上下のカーソル移動が物理行単位になります。

Re: アドイン版CasioBasic ver.0.32 テスト版 その3.2

sentaro様

Ver 0.32 を頂きました。ありがとうございます。


> これは意図的にというか、ALPHAモードに設定する方法が見つけられていないので、CasioBasic同仕様にしたくても出来ないでいるというのが本当のところです。
> ということなので、その方法が見つかるまでは今の仕様のままです(^^;

ALPHAモードへの切り替えの件については、了解です


> [ALPHA]モードでもそのまま入力可能なように修正しました。

EDIT画面での ALPHAモード表示については、修正を確認しました。


> 今回の修正で直っているか新たなバグが発生したのか、まだ怪しげなことになる恐れありです(^^;

何か期待しない動作の時の再現条件を見つけるように頑張ってみます。


> ある程度の土台が出来上がれば、後は機能追加していくだけなので少しずつ積み上げたいと思います(^^)

デバッグも、積み上げてゆきますね....(^^;) ビミョー


> アドインによるアドイン作成はかなり内部仕様に迫る必要ありですね。
> バイナリコンパイラが出来上がる頃にはそれも可能になればと思います(^^)

> >ところで、RclCapt コマンドの実装はお考えですか?
>
> メインメモリアクセスが出来るようになればメインメモリ仕様のPictと併せて実装予定です。

内部動作あぶり出し次第ということですね。


> 今回よりエディタを[CR]で区切られた論理行単位表示からCasioBasic同様の物理行単位の表示に変更しました。
> 上下のカーソル移動が物理行単位になります。

以前のバージョンでは、カーソル移動に違和感があって、行きたいところへカーソルを移動するのに、行きすぎてから戻るという操作が必要でしたが、これで使いやすくなりました。

ありがとうございます。


> 今回のコンパイラプロジェクトでCasioBasicが超高速になることで守備範囲が広がることを期待したいです。

はい、超高速になる一例として、PICALC4 を 1050桁まで計算させてみましたが、爆速になっています。
特に FTune2 と併用したら、とんでもなく速いです。


ところで、NEW でファイル名入力時、[X,θ,T] キーを押すと"1"が入力されることを発見!
これはバグと思われます。

一方、CBasic でBUGTRACEを実行させるとき、起動画面で [EXE] を押して十字カーソルが表示される時、[EXE] の代わりに [SHIFT] + [OPTN] を押しても十字カーソルが表示されます。面白いことに、オリジナルの Casio Basic でも同じ結果になります。
...これは Casio Basic の仕様なんですね。これまで気付きませんでした。


さて、コメントアウト記号 ' で、コメントアウト行に : が含まれている時の動作は、CBasic では改善されていますね!

このような改善は、CBasic の利点の一つになりますね(^_^)/





No title

管理人様、こんにちは!

毎度のテストありがとうございます!(^^)

>何か期待しない動作の時の再現条件を見つけるように頑張ってみます。

期待しない動作がないことが一番ですけど、現状たぶん何か不具合潜んでる可能性が大です(^^;


>デバッグも、積み上げてゆきますね....(^^;) ビミョー

はい、良くできたSDKのおかげでデバッグも何とかなっています。
CG10/20にはそれがないので移植には難航するかもしれません(^^;


>内部動作あぶり出し次第ということですね。

SDK純正ライブラリだけを使っていては出来ないことばかりなので、その都度調査しないとです。


>以前のバージョンでは、カーソル移動に違和感があって、行きたいところへカーソルを移動するのに、行きすぎてから戻るという操作が必要でしたが、これで使いやすくなりました。

エディタもやっと本体並みに近づいてきたでしょうか。
物理行単位での移動が出来ないと改行無しのプログラムだとめちゃ不便になりますね(^^;


>はい、超高速になる一例として、PICALC4 を 1050桁まで計算させてみましたが、爆速になっています。
>特に FTune2 と併用したら、とんでもなく速いです。

インタプリタでも10倍速は出ているので結構速いですよね(^^)
現状サポートコマンド数が最小限というところなので公平な比較ではないですけど、それでも10倍の速度が出ているのはまずまずかなと思っています。
FTune2を併用した場合の速度はおそらくコンパイラになった時の速度に近いかもしれません(^^)


>ところで、NEW でファイル名入力時、[X,θ,T] キーを押すと"1"が入力されることを発見!
>これはバグと思われます。

確認しました。これはバグですね(^^;
致命的ではないので次回バージョンアップで直しておきます。


>一方、CBasic でBUGTRACEを実行させるとき、起動画面で [EXE] を押して十字カーソルが表示される時、[EXE] の代わりに [SHIFT] + [OPTN] を押しても十字カーソルが表示されます。面白いことに、オリジナルの Casio Basic でも同じ結果になります。
>...これは Casio Basic の仕様なんですね。これまで気付きませんでした。

[SHIFT]を押した時点で十字カーソルが表示されますね(^^;


>さて、コメントアウト記号 ' で、コメントアウト行に : が含まれている時の動作は、CBasic では改善されていますね!

CasioBasicの仕様とは違ってしまいましたけど、これはこれでいいのでしょうか(^^;

数値表示とFor文の Step

sentaro様

期待しない動作を見つけてしまったので、報告します。


1. Textコマンドでの数値表示
http://egadget2.web.fc2.com/archives/PlotOff3.html
Y の値の表示が オリジナルと異なり指数表示になる。


2. For 文の Step がひょっとしておかしい?
http://egadget2.web.fc2.com/archives/PlotChg3.html
千鳥格子の描画が、画面全体になるところ、上半分になってしまう。


チェックを御願い致します。

EngOn, EngOff, Eng の実装

sentaro様

今気付いたのですが、EngOn、EngOff、Eng がまだ実装されていません。

もし、今後実装する場合は、Locate での表示との整合性をご確認の上、御願いします。

EngモードとLocate の表示については、下記をご参照ください。

http://egadget.blog.fc2.com/blog-entry-63.html

なお、EngOn と EngOff は fx-5800P と fx-9860GII に実装されていますが、Eng は fx-5800P に実装されていません。

アドイン版CasioBasic ver.0.33 テスト版 その3.3

管理人様、こんにちは!

毎度の細かいテストありがとうございます(^^)
なかなか気づかないことが多いのですごく助かります。


>Y の値の表示が オリジナルと異なり指数表示になる。

これは少数に誤差が出る2進演算のため現状ではCBASICの仕様ということになってます(^^;

指数表示にならないようにするためには、
RndFixを使って、
RndFix(X,2)とかで丸める必要ありです。


>千鳥格子の描画が、画面全体になるところ、上半分になってしまう。

これはMOD関数の実装ミスが原因でした(^^;


>今気付いたのですが、EngOn、EngOff、Eng がまだ実装されていません。

後回しになってましたので、サクッと実装しました(^^)


アドイン版CasioBasic ver.0.33 テスト版 その3.3
http://pm.matrix.jp/CB/CBASIC033.zip

Re: アドイン版CasioBasic ver.0.33 テスト版 その3.3

sentaro様

Ver 0.33 を頂きました。ありがとうございます。

MOD( ) の修正を確認しました。

あと、小数表示については、RadFix(N,2) で回避できることも確認しました。

ところで、EDIT 画面で [F3] (CMD)選択時のメニューの下に、?、◢、: のソフトメニューが現れるように、変更しました?
Ver 0.33 で気付きました。これ、とても良いです!!

いつも、これらを入力するとき手数が多くて面倒でした。? がある分 fx-5800P よりも便利になりましたね。

できれば、コメントアウト記号も追加して頂ければ、さらに有り難いと思うのですが、如何でしょうか?


ところで、[X,θT] キーで 1 が入力される異常は解消されたことも確認しました。


> >今気付いたのですが、EngOn、EngOff、Eng がまだ実装されていません。
>
> 後回しになってましたので、サクッと実装しました(^^)

私の Casio Basicコマンドリファレンスに記載ミスを発見しました。
EngOn で、0.99 を表示したら 99m になるのに 0.99 と表示されるような記述があったので、修正しました。

書いた時は確認したつもりだったのですが、どうしてこうなったのか、今となっては不明です。何か他の設定との組み合わせがあったのかどうか、今は謎です。


ところで、ちょっと深刻なエラーを発見してしまいました。原因が不明なのですが再現性100%です。

以下から、Hit & Blow をダウンロードして、CBasicで実行してみてください。
http://egadget2.web.fc2.com/archives/archives.html#fx9860GII_CasioBasic
メインルーチンの他にサブルーチンが4つあります。

普通に遊べていたので今まで気がつかなかったのですが、以下の操作をすると100%フリーズして、電卓本体のリセットしか復帰の方法がなくなります。

先ず、Hit&Blowを起動します。
次に [EXE] で Start します。
3 Digits?
と表示されている時に、[AC] キーで強制終了しようとすると、

Break
Press:[EXIT]

のポップアップが表示されます。ここまでは正常です。

ここで、[EXIT] を1回押しても反応なし。もう一度押すとポップアップが消えます。そしてハングアップします。
どのキーを押しても反応なしとなってしまいます。

なお、[AC] で強制終了するとき、[EXIT]を複数回押さないと終了しないこともありますが、サブルーチンに無限ループがあると、サブルーチンのネストと無限ループのネストに関係ありそうな感じがしています。

例えば、

ファイル名:A
Lbl 0
Prog "B"
Goto 0


ファイル名:B
While 1
Lbl 0
?A
Goto 0
WhileEnd

ファイル名:A を実行し、? の画面表示の際、[AC]を押すと、[EXIT] を2回押して ファイルBの EDIT 画面に戻ります。
一方、ファイルBを実行し、? の画面表示の際に [AC] を押すと [EXIT] 1回で EDIT画面に戻ります。

この現象と、Hit & Blow のエラーと関係ある可能性は想像したのですが、追い込めずにいます。

なお、この Hit & Blow はオリジナルの Casio Basic では正常に強制終了できています。スミマセンm(_ _)m



強制終了

sentaro様


強制終了の件ですが、Hit & Blow のサブルーチン S3HB345 を起動する場合でハングアップすることが分かりました。これは、サブルーチン S4HB345をCallしています。

S3HB345 を起動、
[AC] キーで強制終了しようとすると、

Break
Press:[EXIT]

のポップアップが表示され、[EXIT] を押すと、ポップアップが消え、ハングアップします。


次に、S3HB345 の後半にある
Prog "S4HB345"
をコメントアウトすると、強制終了でハングアップせず、正しく終了します。

では、コールしている S4HB345 をc直接起動すると、[AC] で正常に強制終了されます。


なお、ここでコールされる S4HB345 では、行列領域を確保して使っていますが、どこにも ClrMat をしていないお行儀の悪いプログラムでした。

で、Prog "S4HB345" の後に ClrMat Z を追加してもハングアップします。



取り急ぎ、ここまで...

アドイン版CasioBasic ver.0.34 テスト版 その3.4

管理人様、こんにちは!

サブルーチンバグ出しテストありがとうございます!
これは全然気が付いてなかったので冷や汗ものです(^^;
フリーズの原因はブレーク&エラーで止まった時に違うソースに戻っていたためでした。
ってことで、修正版です。

アドイン版CasioBasic ver.0.34 テスト版 その3.4
http://pm.matrix.jp/CB/CBASIC034.zip

その他、ファイル名入力でのデフォルトALPHA対応しました。



>ところで、EDIT 画面で [F3] (CMD)選択時のメニューの下に、?、◢、: のソフトメニューが現れるように、変更しました?
>Ver 0.33 で気付きました。これ、とても良いです!!
>いつも、これらを入力するとき手数が多くて面倒でした。? がある分 fx-5800P よりも便利になりましたね。

Ver.0.32より追加変更したのですが、一番下の行が空いていたので何かに使えないかと…(^^)


>できれば、コメントアウト記号も追加して頂ければ、さらに有り難いと思うのですが、如何でしょうか?

[F4]に追加しました。
後二つ空きがあるので何かご希望あれば追加します(^^)

Re: アドイン版CasioBasic ver.0.34 テスト版 その3.4

sentaro様

Ver0.34 頂きました。ありがとうございます。

サブルーチンの異常は修正されたことを確認しました。


> その他、ファイル名入力でのデフォルトALPHA対応しました。

方法を見つけたのですね。素早いです。やはりこのほうが統一性があって良いと思います。


> Ver.0.32より追加変更したのですが、一番下の行が空いていたので何かに使えないかと…(^^)

> >できれば、コメントアウト記号も追加して頂ければ、さらに有り難いと思うのですが、如何でしょうか?
>
> [F4]に追加しました。
> 後二つ空きがあるので何かご希望あれば追加します(^^)


コメントアウト記号は、デバッグ時に素早く入力できるので助かります。
あと2つ追加するとして、私は個人的には、= と≠ の入力が多いので、これらが追加されるとうれしいです。

ところで、CBasic のデフォルトの Norm が Norm 1 になっていませんか?
気のせいかも知れませんが、100n とだけコードに書いて実行したら、1.E-7 と表示されました。
改めて、Norm 2 としたら 0.0000001 となりました。このことから、デフォルト設定に疑問を持ちました。
間違っていたら、すみません。



アドイン版CasioBasic ver.0.35 テスト版 その3.5

管理人様、こんにちは!

>方法を見つけたのですね。素早いです。やはりこのほうが統一性があって良いと思います。

はい、方法というか、隠しSYSCALLにGetKeyの逆機能?のPutKeyというのがあって、キーの先行入力バッファに[SHIFT]+[ALPHA]を入れておくという原始的な方法でなんとかなりました(^^;
手入力で[SHIFT]+[ALPHA]を押すのを先に押しておく感じですね。

>あと2つ追加するとして、私は個人的には、= と≠ の入力が多いので、これらが追加されるとうれしいです。

早速に追加してみました(^^)

アドイン版CasioBasic ver.0.35 テスト版 その3.5
http://pm.matrix.jp/CB/CBASIC035.zip


>ところで、CBasic のデフォルトの Norm が Norm 1 になっていませんか?

はい、デフォルトはNorm 1です。

これはどっちがデフォルトか分からなくなったので、(^^;
マニュアルの1-4をみたら初期設定はNorm 1ということでNorm 1にしてあります。

Re: アドイン版CasioBasic ver.0.35 テスト版 その3.5

sentaro様

早々に、Ver 0.35 をありがとうございます。

> >方法を見つけたのですね。素早いです。やはりこのほうが統一性があって良いと思います。
>
> はい、方法というか、隠しSYSCALLにGetKeyの逆機能?のPutKeyというのがあって、キーの先行入力バッファに[SHIFT]+[ALPHA]を入れておくという原始的な方法でなんとかなりました(^^;
> 手入力で[SHIFT]+[ALPHA]を押すのを先に押しておく感じですね。

なるほど、PC用ライブラリでも同じようなことが出来るので、隠し SysCall はPCで出来ることは出来そうですね。


> >あと2つ追加するとして、私は個人的には、= と≠ の入力が多いので、これらが追加されるとうれしいです。
>
> 早速に追加してみました(^^)

一番右の ≠を選ぶと Eng が入力されてしまいます(/_;)
0011 のところ 00DD になっているようです。

> >ところで、CBasic のデフォルトの Norm が Norm 1 になっていませんか?
>
> はい、デフォルトはNorm 1です。
>
> これはどっちがデフォルトか分からなくなったので、(^^;
> マニュアルの1-4をみたら初期設定はNorm 1ということでNorm 1にしてあります。

了解です。デフォルトで Norm 2 だと思い込んでいました。

0.35差し替えです(^^;

管理人様、こんにちは!

>なるほど、PC用ライブラリでも同じようなことが出来るので、隠し SysCall はPCで出来ることは出来そうですね。

はい、かなりの隠し機能がありそうなのですが、
使い方がよく分からないものが多いので使えるようになるまでが一苦労です(^^;


>一番右の ≠を選ぶと Eng が入力されてしまいます(/_;)
>0011 のところ 00DD になっているようです。

うわ、何か勘違いで間違えてしまったようです(^^;

ってことで、0.35差し替えました。

アドイン版CasioBasic ver.0.35 テスト版 その3.5
http://pm.matrix.jp/CB/CBASIC035.zip

まだまだバグが潜んでそうなので、徹底的にあぶり出しよろしくお願いします(^^)

Re: 0.35差し替えです(^^;

sentaro様

差し替え版、Ver0.35 頂きました。


> >なるほど、PC用ライブラリでも同じようなことが出来るので、隠し SysCall はPCで出来ることは出来そうですね。
>
> はい、かなりの隠し機能がありそうなのですが、
> 使い方がよく分からないものが多いので使えるようになるまでが一苦労です(^^;

お疲れ様です。

> >一番右の ≠を選ぶと Eng が入力されてしまいます(/_;)
> >0011 のところ 00DD になっているようです。
>
> うわ、何か勘違いで間違えてしまったようです(^^;
>
> ってことで、0.35差し替えました。

はい、修正を確認致しました。


ところで、BugTrace.g1m を CBasicで実行する時の、右上のビジーマーカーの表示について質問です。

起動したばかりの画面では、とても忙しく点滅しています。
一方、ドットを入力して [DEL]キーで描画を始めると、殆ど点滅しません。

とても忙しく点滅するのが、チョット気になりますが、この違いの原因はお分かりでしょうか?

ビジーマーカーとLCD転送

管理人様、こんにちは!

>とても忙しく点滅するのが、チョット気になりますが、この違いの原因はお分かりでしょうか?

キー待ちループの中にTextコマンドがあってそれが繰り返されるので点滅の原因になっています。
ループ外に出せば点滅は無くなります。

画面表示は一旦VRAMに書き込んだ後、LCD転送で表示されますが、
このLCD転送の直後にビジーマーカーをLCDに直接書き込むことでビジーマーカーを表示させています。
そのビジーマーカーが表示された後、すぐにまた次のLCD転送が起きるとビジーマーカーは消えてしまうので
これが繰り返されるとビジーマーカーが激しく点滅して薄く表示されることになってしまいます。

ほとんどのグラフィックコマンドでは、
ビジーマーカー表示時間が十分とれるようにLCD転送回数を約1/40秒単位で制限しているので点滅はほぼ起きないのですが、
TextとLocateコマンドに関しては毎回LCD転送をしているのでコマンドが連続すると点滅してしまいます。

CBasicでの裏技として表示コマンドの直後が「:」の場合はLCD転送をしないで次のコマンドに移るので
ビジーマーカーの点滅をプログラム的に抑制することが出来ます。
またLCD転送を制御することで表示のちらつきの抑制&高速化にもなります(^^)

今のところ表示関係はこういう仕様になっているわけなのですが、
これでいいのかどうなのかはしばらく検証してみる必要ありです。

Re: ビジーマーカーとLCD転送

sentaro様

解説ありがとうございます。


> 画面表示は一旦VRAMに書き込んだ後、LCD転送で表示されますが、
> このLCD転送の直後にビジーマーカーをLCDに直接書き込むことでビジーマーカーを表示させています。
>
> ほとんどのグラフィックコマンドでは、
> ビジーマーカー表示時間が十分とれるようにLCD転送回数を約1/40秒単位で制限しているので点滅はほぼ起きないのですが、
> TextとLocateコマンドに関しては毎回LCD転送をしているのでコマンドが連続すると点滅してしまいます。

理屈がわかりました。

通常のCasio Basic で

While 1
Text 1,1,1
WhileEnd

と実行すると、ビジーマーカーが点滅するので、理屈は同じなのだと思います。

但し、LCD転送の頻度が CBasic よりは少ないのでしょうか? 点滅がそれほど激しくありません。
CBaic はそもそもの処理が速いから、Whileループの回りも速いことも点滅が激しくなる原因になるのだと理解しました。


While 1
Locate 1,1,1
WhileEnd

だと、ビジーマーカーの点滅が見られないので、これも CBasicの処理速度の速さが違いとなっていると理解しました。


> CBasicでの裏技として表示コマンドの直後が「:」の場合はLCD転送をしないで次のコマンドに移るので
> ビジーマーカーの点滅をプログラム的に抑制することが出来ます。
> またLCD転送を制御することで表示のちらつきの抑制&高速化にもなります(^^)

確かに確認できました。

Cbasic では : はLCD転送せずに、次のコマンドを実行する内部実装になっているのですね。


> 今のところ表示関係はこういう仕様になっているわけなのですが、
> これでいいのかどうなのかはしばらく検証してみる必要ありです。

: 記号による裏技と、先日の RadFix()関数による数値表示の件、裏技ネタ帳に書き留めておきました。

CBasicのFAQとして将来の利用価値がありそうです。


No title

管理人様、こんにちは!

>但し、LCD転送の頻度が CBasic よりは少ないのでしょうか? 点滅がそれほど激しくありません。
>CBaic はそもそもの処理が速いから、Whileループの回りも速いことも点滅が激しくなる原因になるのだと理解しました。

本体CasioBasicでは、
For 1→I To 100
Text 1,1,I
Next
の実行時間が8秒ちょっとかかります。

フレームレートでは12フレーム程度なのですが、
CBasicでは10倍以上の速度が出るので120フレーム以上ということでかなり差が出ますね。


>Cbasic では : はLCD転送せずに、次のコマンドを実行する内部実装になっているのですね。

はい。
LCD転送しない手段があると何かと便利なこともあるかなという感じですね。
画面更新を制御できるので描き終わってから一気に表示するというダブルバッファがBasicで実現できます。
TextやLocateで直前に消去してから新たに描くというので使うと画面表示のちらつきが無くせるのも利点でしょうか。


>: 記号による裏技と、先日の RadFix()関数による数値表示の件、裏技ネタ帳に書き留めておきました。
>CBasicのFAQとして将来の利用価値がありそうです。

こんな機能があったらというのがありましたらどんどんお願いします。

欲しい機能が自由に追加出来るのもアドイン版の特徴ですね(^^)
最新記事
最新コメント
カテゴリ
C# (3)
検索フォーム
Visitors
Online Counter
現在の閲覧者数:
プロフィール

やす (Krtyski)

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


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

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

おもしろい・役に立つならクリックしてください。励みになります。
にほんブログ村 IT技術ブログ 開発言語へ
にほんブログ村


人気ブログランキングへ


FC2ブログランキングへ


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

リンク
月別アーカイブ
Sitemap

全ての記事を表示する

RSSリンクの表示
最新トラックバック
ブロとも申請フォーム

この人とブロともになる

QRコード
QR