PICで走るTiny-BASIC（続きの続きの続き）

実用的な観点からは、21世紀にもなってTiny-BASICを作ることにあまり意味があるとも思えません。

カンタンにソフトを作りたいならArduinoがあるし、PICでも開発環境が無償化されているので、PicKit2と参考書を買うだけで比較的簡単にスタートできます。なにもBASICを使う必要はありません。

それに、BASICには未来は無いですが（たぶん）Cはまだまだ現役です。ちょっと大変でもCから始めた方がいいのは明らかです。

でも、懐かしいですね。
僕は77年頃に8080のマイコンを作り、いずれはBASICを作ろうと思っていました。ところが数年で自作機の時代が終わって、MZ-80やPC-8001といったメーカ機が台頭してくると、僕も（就職して懐具合が改善したので）PC-8001に乗り換えてしまい、結局BASICは作らずじまいでした。
その雪辱戦と言ったところです。真空管のラジオを作る感じかな？　やってみると面白いです。

そんなわけで、当時の自作機の雰囲気に組上げてみました。ムカシの名前は忘れてしまいましたが、本機はHANACと命名しました。ENIAC,EDSAC,UNIVAC,TAC,NEAC,HITAC....懐かしい計算機にあやかってAutomatic Computerがつく名前にしました。

当時の僕の自作機は、おなじみのスイッチレジスタを使わずに、TTLで組んだROMにIPL（ブートローダー）を入れ、UART（Intersilの6402だったかな）からカセットテープに記録したプログラムを読み込むようになっていました。
本物の電子計算機（磁気テープがくるくる回ってるヤツ）に憧れてキースイッチや照光式ボタンを奢ったのも懐かしいです。今回、この辺も再現しました。おかげでシャーシだけで5K円以上もかかってしまいましたが。
もっとも寸法は大分小さくなっています。当時の基板は56Pのカードエッジのモノで、面積ではこれの４倍です。それが３枚アルミシャーシに立っているという体でした。取っ手は補強のつもりで付けてました。

本機はホストとの通信に、USBシリアル変換機とXBeeを選択できるようになっています。電源は単三電池を２本内蔵、USB接続の時にはUSBから給電します。

ccscのソースコード、回路図、BASICのサンプルプログラムを公開します。詳しい説明もありますので、興味がある方はダウンロードしてみてください。フォルダにまとめて入れてあります。

「HANA-BASIC04_PRJ.zip」をダウンロード

思いつきで3週間くらいで作ったインタープリタですから、出来はよくないです。あまり作り方の参考にはならないと思いますが、こんなものでも動くんだという見本と思ってください。
ccscを持っていない方でも、main.hexをPicKit2で書き込んでもらえば動かすことが出来ます。
カレントループインターフェイスを作ればお宅に眠っているASR-33（まさかね）も接続できますよ。「謎の円盤UFO」のオープニングごっこなんかはいかがですか？

＜後日追加＞
いくつかバグを取った20MHzクロック版のVer0.41がこちらにあります。

PICで走るTiny-BASIC（続きの続き）

動作の様子を動画に撮りました。
実行速度はボチボチで、昔使っていたPC-8001を思い出しました…

本機はXBeeでPCと無線接続しています。そのため通信速度は9600bps程度です。
3Vでの消費電流は待機時3mA、動作時（通信実行時）12mA程度と相変わらず省エネですね。PIC16F88XシリーズはいままでのPICと比べても消費電流が少ないようです。

動画最後の「ブラックジャック」は、ホントーにわかり難いんですが、トランプのブラックジャックをアレンジしたものです。
よく見ると、コンピュータのカード（２枚目以降は#表示でわからないようになっている）とプレイヤーのカードが表示され、ヒットするかステイするかを訊いているのがわかる、かもしれません。
このプログラムは230行くらいある「大作」です。

PICで走るTiny-BASIC（続き）

青春の想い出に頼ってばかりもいられないので、今回のBASICの仕様を作るのに、これらの古本を参考にしました。

I/Oは77年8月号でSC/MPのNIBLの記事が、トラ技はちょっと後の82年2月号で、Tiny-BASIC内蔵のSC/MPIIIの記事があります。
ちなみに、I/Oの広告によると8080が9800円、2102(1kbitRAM)が950円の時代でした。懐かしいですね。

僕は古いマイコンチップも持っていて、写真の上のがINS8073ことSC/MPIIIです。いずれは動かしてみようと思っています。下のヤツはRCAのCDP1802、COSMACのほうが通りがいいのでは？

HANA-BASIC 0.3のラフ仕様です。（インタープリタは大文字小文字の区別をしません）

●モニタ
ターミナルからのコマンドやプログラム入力を受け付ける。BSキーで入力文字の訂正も出来る。
■コマンドモード（プロンプトが"?"）
・入力したBASICコマンドをダイレクト実行
・RUN　入力モードで保存したプログラムを実行
・LOAD　プログラム入力モードに移行
・CTRL+C　システムリセット
■プログラム入力モード（プロンプトが">"）
・入力したプログラムを一行ずつ保存（一行最大80文字）
・EOF　コマンドモードに移行

●変数、定数、式
変数　A-Zの26個。符号付き16bit
定数　10進定数の他、0x8000のような16進定数、"...文字列..."はPRINT文でのみ使用可。
算術演算　左から順に実行。四則演算と、C同様の論理演算(&.|,~)
条件演算　左から順に実行。C同様(==,!=,<,>,=<,=>)
カッコは使えない。

●メモリ参照子@
@+定数または変数で配列（メモリ）などに16bitでアクセス
@0-@29　スクラッチパッドメモリ（１次元の配列のように使用できる）
@30-@34　AD変換チャネル読み込み(10bit)
@35　キーコード読み込み（シリアル入力１文字読み込み、1バイト）
@36　乱数読み込み（0-255）
@40　PORT Bへのデータ出力(1バイト）
@100-@1000　EEPへのデータ読み書き。電源を切っても消えないのでデータファイルとして利用可。

●PRINT
ターミナルに出力。
PRINT "ANSWER=" ;
PRINT A
行末が ; ならば改行しない。

●INPUT
ターミナルから数値を入力。
INPUT A
数値（10進のみ）を入力しリターンキーを押すと変数に取り込む。

●IF〜THEN
IF A>10 THEN PRINT "OVER!"
条件成立（式の値が1以上なら）THEN以降を実行

●GOTO,GOSUB,RETURN, :（ラベル識別子）
A=0
:L0
PRINT A
A=A+1
IF A<10 THEN GOTO L0
このように使う。ラベルは何文字でもよいが、最初の２文字のみで区別する。
GOSUBスタックは8レベル

●FOR〜NEXT
やはりBASICならこれがないと！
FOR I=1 TO 100
PRINT I
NEXT I
NEXTのあとの変数名は見ていないので省略可。また、入れ子は可能だがスタックはGOSUBと共用。

●DELAY
DELAY 100
のように使う。プログラムを指定時間待たせる。単位はms。
（なお、現在のBASICプログラムの実行速度は、8MHz内蔵クロックで１行平均10ms程度。遅いですね）

●END

こんなところです。続きは後ほど。

PICで走るTiny-BASIC

管理人のページ：

ここ何週かにわたってPICで走るTiny-BASICを作っています。ちょっと思うところあってですが、結果的にはナツカシ製作になったような…　とにかく名前はHANA-BASICです。

PICはいつもの16F886、さすがにRAM容量がありませんので、256(32KByte)のシリアルEEPをプログラム保存用に使っています。プログラムのロードや実行は、シリアルポートでTeraTermに接続して行います。モノはこんなにカンタンです。（もちろん、RS232Cへのレベルコンバータは別途必要です）

そもそもTiny-BASICの仕様を良く覚えていなかったので、大体こんなもんだろうという感じで作り始めました。16bit整数演算で式の評価は左側から、変数はA-Zの26個、@演算子でのメモリやI/Oアクセス、IF〜THEN、FOR〜NEXTループなどなど、基本機能は備えていると思います。

プログラムを実行した結果はこんな感じです。（クリックすると拡大します）
loadコマンドでプログラム入力モードになり、プロンプト>が表示されます。ここで、あらかじめテキストエディタで作っておいたBASICプログラムをペーストします。大文字でも小文字でもかまいません。内部で大文字に変換しています。
プログラムの最後のeofは入力モードを終わらせるコマンドです。あとはrunで実行します。そろばんでおなじみの総和の計算をやっています。

伝統的なBASICと大きく違うのは行番号が無いことです。行番号を付ければ、編集操作が可能になるので、ターミナルだけでプログラム開発ができます。ただ、EEP上のデータを移動する作業が頻発するので、書き込みに5msほどもかかるEEPでは、一行入力する度に何秒も待たされることになりそうです。
今回の仕様では、プログラムはテキストエディタで作ることとして、行番号による編集機能は省きました。行番号が無いので、GOTOなどはラベルを使って実装しています。

PICで走るTiny-Basicといえば、BASIC Stampが有名ですが、これはプログラムするのに、専用の開発環境が必要です。おそらく効率のいい中間コードに落とす作業を、このツールで行っているようです。

今回の開発の主眼点は、このような専用のツールを使わずに「ターミナルからテキストを送り込めばプログラムが実行できる」ことです。プラットフォームを選びませんし、HPから遠隔地にあるHANA-BASICをプログラムするなんてことも、カンタンに実現できそうです。

詳しい説明は次回投稿します。

XBeeでちょっと訂正

ちょっと訂正です。

いままで、XBeeのバッファサイズについて「37バイト」と書いてきましたが、これは間違いでした。
XBeeの仕様書には

「（XBeeを経由してのデータ送信の場合）バッファの残りが17バイトを切ると/CTSをHにして、外部機器にデータの停止を要求し、その後（バッファのデータが送信されて）バッファの空きが34バイトになると/CTSはLになる」

と、あります。バッファサイズ自体についての記述はありません。僕がどこから37バイトという数字を引っ張り出したかは不明ですが（すみません）、実際のバッファサイズはおそらくもっと大きいのではないでしょうか。具体的なサイズは仕様書から見つけられませんでしたが、メモリが2Kバイトありますからね。

前の投稿で、あるカメラのデータパケットサイズが64バイトと書きましたが、おそらくこのサイズはバッファサイズより小さいんだと思います。それなら、どんなボーレートでも、フロー制御なしで直接カメラとつなげて問題なく使えるでしょう。

LinkSpriteのシリアルカメラ！

「ウィークエンド」で使っているLinkSpriteのシリアルカメラですが、いろいろとトラブルの情報をいただいています。内容はこの投稿のコメントをご覧いただくとして、本家では何か問題が出てないのかなとsparkfunの商品紹介ページを見ていたら、コメント欄の一番下（2011年１月26日付け）の投稿に気になるモノがありました。このページの最後です。かいつまむとこんな内容です。（原文にはコマンドをどう間違えたかを具体的に書いているので、そちらも見た方がいいと思います。）

ツイてない質問主のtessarさん、『画像サイズ変更コマンドのパラメータを誤って送信し、再起動（このコマンドは再起動後に変更した画像サイズになるので）したところ、リセットシーケンス終了がこない、その後正しい画像サイズのコマンドを送ったものの、うんともすんとも言わなくなってしまった。EEPをクリアするかデフォルトリセットの方法は無いか』　という質問です。

しかもさらにツイてないことに、『これは２台目のカメラで、１台目はやっぱり間違ったコマンドで壊れたようだけれど、自分としては画像サイズを変えようとした覚えは無いんだけど』　と、ぼやいてます。

これには2日後に自己レスがあって…

『LinkSpriteのサポートに連絡したら、送り返してくれればファームウェアを復旧すると言われた。自分自身では復旧出来ないようだった』　という報告でした。しかし続けて、　『でも、思うにこのカメラは、通信や安定なパフォーマンスにおいて、4Dsystemsのヤツよりずっといい』　とも言っています。

最後にtessarさんは声を大にして（大文字で！）、画像サイズ変更コマンドでMESSするな！と、全ユーザに向けて叫んでます。MESSには散らかすとか言う意味があるからこれでいいのかな？　それとも力が入りすぎてMISSしちゃったのでしょうか？　欧米人ではないのでこの辺はわかりません。

これからわかるのは、パラメータを引き渡すコマンドには、マニュアルにある以外のパラメータを与えると、ひどいことになる可能性あり、と、いうことではないでしょうか。tessarさんの１台目のカメラが、問題のコマンドを送った覚えがないのに壊れたのは、そのせいなのかもです。
でも、そのためにはそれらのコマンドがEEPにデータを保存するものでなければなりません。たとえばボーレート変更コマンドは、確かに動作中のボーレートを変更しますが、リセットするとデフォルトの値に戻ります。だからEEPに保存されるわけではないと考えるのが普通ですが、本当にそういう設計になっているかどうかはわかりません。

僕は運良く失敗しなかっただけなのかもしれません。

基本的には、僕もtessarさんの意見には賛成で、このカメラはシンプルで使い易いので、アマチュアの電子工作の素材としては面白いものだと思います。4Dsystemsのカメラにもちょっと興味がありますが。

「壊れた」カメラは、こちらのshintaさんページを読めば、自分でも復旧できそうです。

XBeeの通信速度で(ちょっと)モヤモヤ

XBeeネットカメラの拾遺ということで…　　　　　

前の投稿にコメントをいただいてますが、今回使用したLinkSpriteのシリアルカメラは、ボーレートを変更すると故障する「前科」があったそうです。今回僕が使ったモノはそういう問題は起こりませんでした。バージョンが上がったのかも知れませんが、製品にシリアルナンバーなどが無いので何ともわかりません。詳しくはコメントを見てください。

同じく前の投稿で「XBeeの通信速度は40Kbpsくらい云々…」と言う記述があります。これは僕の書き方が悪くて、「115.2Kbpsにしても38.4Kbpsからちょっと早くなるだけだから40Kくらいの感じ」と言う意味です。実際の通信速度が40Kbpsもあるわけではありません。わかり難いですね。

では、実際のXBee間の通信速度はいかほどかというと、12Kバイトの画像（320X240のJPEG画像はこれくらいの大きさです）の実転送に13秒くらい（起動時間３秒は含まず）かかってますから、12/13で920バイト/秒と言うことになります。1バイトはスタート・ストップビットを入れて10bitなので、通信速度は9200bps、なじみのあるところでは9600bpsくらいということになります。無線LANなどの影響があるのかどうかわかりませんが、こんなものなのかなあ、と言う感じです。でも安定性は及第点で、有効範囲内ならデータ落ち、ビット化けなどは感じられません。

ただ本機の場合は、カメラから読んでXBeeに送るという操作をしていますので「２倍」のデータを転送しているわけですが…　カメラから12Kバイトの画像を吸い出す時間は38,4Kbpsで約3秒、115.2Kbpsならわずか1秒ほどですから、全体の転送時間に対して、そのウェイトはそれほどでもないですね。
前回の投稿で、「115.2Kbpsにしたら１〜２秒早くなった」のを確認しましたが、短縮した２秒はどうもカメラからの吸い出し時間のようですね。

（後日追加：下記のバッファサイズは間違いです。訂正はこちら）
それから、同様のカメラをXBeeに直接つないで無線化している方もいらっしゃるようです。フロー制御は？　と思いマニュアルをDLしてみたら特にフロー制御なし？　データ転送の方式は今回のカメラと似ているようですが…　データパケットのデフォルトがわずか64バイト！　これなら37バイトしかないXBeeの送信バッファでも、ボーレートの設定いかんでは何とかなるかも知れません。今回のカメラでもチャンク（パケット）サイズは可変出来るので、同様のテクニックが使えるのではないでしょうか。

なーるほど。京極堂に憑き物を落とされた感じです。僕はデータ転送というからには、せめて256バイトくらい送らないと申し訳ない。つまり、効率が悪いと思ってました。たしかに小さなパケットだとヘッダのオーバヘッドが大きくなるので転送時間はずっとかかりますが、今回作ったようなシリアルブリッジが必要なくなりますねえ。勉強になりました。