ゆるプロ準備室

43日目と言いつつ１ヶ月近く経過しているのですが… (^ω^;)
BASICプログラムのサンプルのアイディアをChat-GPTに挙げてもらったらSNAKE GAMEを提案してきました。
リアルタイムキー入力が必要ですね…と言う訳でINKEY$を実装。

ついで(?)にSNAME GAME本体もChat-GPTに作ってもらったら…こんなサブルーチンを作ってきました。

6000 '================================
6010 ' エサをランダム配置
6020 '================================
6030 FX=INT(RND(1)*20)
6040 FY=INT(RND(1)*20)
6050 ' ヘビと重なっていないか確認
6060 FOR I=1 TO SNL
6070 IF FX=X(I) AND FY=Y(I) THEN 6030
6080 NEXT I
6090 RETURN

コレを実行すると場合によっては6070行目でFORループの外にジャンプを繰り返し、ループ処理用のスタックがオーバーフローします。
※ヘビが短いうちは起きにくいですが、蛇が長くなると確実に発生します。

まっとう(?)な手段としてはループ外にジャンプしないようにBASICプログラムの方を修正するのですが、そうは言っても作りがちなコードではあるので、この構造でもスタックオーバーフローを起こさなくする修正を行いました。
合わせてループからの脱出を容易にするためにBREAK文を追加しました。
BREAK文の実装に立ちはだかったのがマルチステートメントとNEXT I,J,K とか書けてしまうNEXT文
いやコレどうしろと … めんどくせー … で時間掛かりました。

キーボードに使用しているCardKBはキーが押されたことは取得できますが、キーが離された事は取得できないので、ゲームに使うには無理があります。
次のサンプルプログラムを実現できない可能性が高いので、GAME用にWiiクラッシックコントローラかスーパーファミコンのコントローラを使用できるようにしました。※前回の記事
スーパーファミコンのコントローラは動作が若干怪しい気がしないでもない…300円で買ったジャンク品だからか？
Wiiクラッシックコントローラの方が反応が良い気がします。

M5Stackにゲームパッドをつないでみました。
Wiiのクラシックコントローラを繋ぐのは以前にやったことがあるのですが
AITENDOでWiiクラシックコントローラのコネクタとハウジングが売ってたので。
 
I2C接続なせいか、普通に組み込むとディレイが酷くてゲーム速度全体が低下する＆画面描画に割り込みを使ってる(?)のかI2C読み込みでフリーズするので、組み込みにチョット工夫(I2C読み込みのスレッド化)が必要でした。

手持ちのWiiクラシイクコントローラは以前、Arduinoに繋いでみるテストの時にコネクタを壊してしまったので、壊れていないのをハードオフで探してきたのですが…モノがない上に1980円と割とお高かったです。
 
折角なので (;^ω^)
ハードオフの青箱にゴロゴロ入っているスーパーファミコンのパッドも試してみました。

SFCのゲームパッドは一般的(？)なシフトレジスタでボタンオ状態を送っています。
扱いは単純でWiiクラシイクコントローラより使い易いです、お値段も安いですし。

コチラはハウジングが売ってない(物はあったけど現在では品切れ)で手に入らず、コネクタとハウジングを普通のHXコネクタとハウ刃部に付け替えています。
M5Stackは使えるGPIOピンが以外に少なくてピン割り当てに悩みました。
(G2、G5ピンはブート信号を兼ねているので、ココに外部機器をつなぐとスケッチの書き込みが出来なくなったりする。
　DACは入力に使えないしADCは出力に使えない。
　普通のGPIOピンG25、G26のうちG25は内蔵スピーカーにつながっている)

Ver 0.4でライフゲームを動かしたら思いのほか遅かったので改良していました。
遅い原因
1) 実行時にソーステキストをトークン分割と評価を行っている。
2) 配列変数の参照時の添え字評価にカリキュレータを使用している
で、1)の解決の為にVer 0.5では評価済トークの状態でソースコードを保持しましたが、メモリー使用量が多くなり過ぎました。
Ver0.6ではソース入力時にキーワードを中間コードに変換して保持する方式に変更。
VisualStudioで開発してArduinoIDEで書き込みしているので、M5Stackに書き込んで動作確認する段になって
ESP32はワード境界を跨げない
事を知りました (;^ω^)
int a[2];
char *b = a;
*(int *)&b[1] = 10 ;
とかやるとカーネルパニックを起こします。
中間コードを uint8_t の配列で構成していたので運悪く(?)ワード境界を跨ぐとカーネルパニックでリセットがかかります。
ワード境界を跨ぐと落ちる問題の回避の為に無駄な処理を入れる羽目になりチョット納得いっていませんが画期的な解決策も思いつかないので取り合えずコレで進めます。
現状でVer0.4比で約3倍の速度向上になっています。

▼ Youtubeショート動画

コード自体はAIに書かせてません、自力で書いてます。
で、AIはエラー原因の調査に使っています。
エラーで止まった時、意図しない動作になった時に原因の特定に使うとデバックがめっちゃ捗ります。

中間コード化が一段落ついて変更前と同じ機能まで回復しました。
※まだVisualStudio(Windows)上だけでM5Stackでは動いてません。

月末が近くてGitHUB Copilotの無料トークンが余っているのでコードレビューに掛けました。
未使用変数とデッドコードの調査を行う心算でプロンプトは
「プログラムの実行に影響を与えない冗長な箇所、参照されない変数、実行されないループなど、実行時に不要なコードを教えてください。」です。

で、
・if条件の中で代入
・配列引数の指定ミス
・制限条件の指定ミス
・ローカル変数での上書き
・実行条件の欠落
・変数の上書き
とバグの指摘がボロボロ… (;^ω^)

中間コードかたトークンに変換して実行までできました。
最も実行の方は未だLET文しかできていませんが (;^ω^)
変数の管理も変更しているの演算と代入の確認だけで一苦労。
中間コード化する時に変数も中間コード化してしまったので、初期化(NEWコマンド、CLEARコマンド相当の)動作が面倒になっています。
プログラムではない(行番号を付けない)直接実行で新規変数をドカドカ使ったら変数のガベージコレクションが必要になるかも…と言うか必要ですね。
BASICインタプリタの方がちょっとづつしか進まないので息抜き(?)に、プロトペディア用のアイキャッチを作ってみました。

実は5日経過していたりしますが39日目です。
実行速度を上げるためにプログラムをトークン化した状態で保持しようとましたが、メモリー使用量が増大して保持できるプログラムサイズ自体が少なくなってしまう状態になってしまいました。
文字列で保持すれば１Byteしか取らない+ｰ=とかのオペレータやA,B,Cなどの１文字の変数もトークンにすると16Byte必要なので当然です (;^ω^)
これでは無理があるのでトークンの圧縮を考えた結果、中間コードに変換して保持すれば毎回字句解析を行うよりは高速にトークンに変換できる…と思い至り再度作り直しています。
変数名も中間コードに変換してしまえば変数の参照が高速化できるのでは？…と言う訳で変数管理も作り直しです。

プログラムコード入力 ⇒ 中間コードに変換　⇒　プログラムコードに復元
まで、つまり、入力とLISTが出来る所まで再構築できました。
※まだ削除もリネームも出来ないです。

LIFE GAMEを実行してみて実行速度の遅さが気になりました。
２次元配列を繰り返し操作するLIFE GAMEとは相性が悪いのだと思う。

遅い要因として考えられるのは2点

• １行毎にトークン解析を行っている
  プログラムソースコードではなく解析済みのトークンを記録しておけば繰り返し処理でトークン解析の時間が短縮できる。
  この解析済みトークンにより多くの情報を詰め込めれば、それだけ実行速度の向上につながると思う。
• 配列変数の評価に時間が掛かる
  定数の事前評価が難しいのと同じ理由で添え字を毎回評価しないといけない。
  配列の添え字、関数の引数、コマンドパラメタの評価を同じメソッドで処理できるように統合した副作用で遅くなっている気がする。

この点を踏まえて、プログラムリスト管理を作り直しました。
作り直し４回目？かな？

トークンに分割した状態でプログラムリストを記憶する方式に変更。
実行速度が1.4倍になりました。

しかし、トークンのデータサイズが大きくてメモリーを圧迫しています。
最大4500トークンまでしか使えない。※多分800～1000行分
もう一歩、トークンデータの圧縮が必要みたいです。

秋月電子で購入したレギュレータ付きのSDカードユニットに交換しました。
取り合えず実験用ベースに組み込んで動作確認…問題なく一発で動作しました。
ファイル操作関係　FILES、LOAD、SAVE、REMOVEも問題なく動作。

SDユニットの外形が違うので筐体の再設計…は兎も角…３Ｄプリントやり直しは避けたいので、何とかSDユニットの土台部分は変えずに形状変更。

右に1mm幅を広げた方がバランスがよさそうな気がしますが…筐体作り直すの面倒くさい (;´Д｀)
3Dプリンタのフィラメントを使い切ってしまっているので、フィラメントが届くまで筐体の改造は休止です。

SAVE/LOADを実装すべくまる二日試行錯誤しましたが…
どうも外部接続したＳＤカードユニットがハズレ(?)だったっぽい。
M5Stackとは相性が悪い？ そんな感じ。
ちなみにAmazomで購入、5個セット680円だったかな。

電源投入時の起動シーケンスが途中でコケルっぽい。
SDカードを抜き差しすると動くようになる事があって、一度動けば電源を切って暫く放置しない限り大丈夫。
なので「あー動いた ( ^ω^ )」と思って安心すると動かなくなる。
配線が間違えてる訳でもスケッチが悪い訳でもないのに動かない。
完全に動かないなら未だしも時々動く… (;´Д｀)
最終的に「こんな不安定なSDカードユニットは使ってらんね!!」って訳で別のユニット(秋月で購入、1個480円)に変更することにしました。
サイズ的にレトロPCっぽい筐体が作り直しになるんだが…
フィラメントを使い切ってしまってオレンジ色のフィラメントしか残ってないし…

▼使用を諦めたSDカードユニットがこちら
電源が正しく切れない ⇒ SDカードを抜き差しするとリセットが掛かる ⇒ 正常化してアクセセスできるようになる
って事らしい (Chat-GPTの解説によると)
電源をGPIOから操作できるようにしてON/OFF操作を自前でやれば解決すんじゃね？
って意見を出されたけど、そんな面倒な事やってらんねー

筐体をCardKB用に作り直し
BASICインタプリタも変数管理方法を変更して作り直しました。
いくらメモリー節約にはなりましたが、配列へのアクセス手順が増えて配列使うと遅くなる気が…

コンソールはキャラクタ表示、スクロール、CardKBからの入力が出来るようになりました。
DEL/BSが未実装なので削除は出来ないのですが (;^ω^)
まずは、万年カレンダー表示プログラムが動かせる所までは出来ました。

コンソール周りはVisualStudioでのデバックが出来ないので面倒です。
しばらくはコンソール周り、入力編集機能の拡張ですかね。

ここまでの成果

• M5Stackの画面にテキスト表示が出来るようになった。
• 16進数を扱えるようになった。