DevTermを使ってみる!

f:id:PocketGriffon:20211202183830j:plain

DevTermが届いてから24時間以上が経過したワケだけど、さっそく色々と使いまくってる!

どんな感じに使ってるのかをレポートしてみたい!

使い方が偏りすぎてて、きっと他の人の参考にはならないかも!(^^;;

 

ちょっと困るユーザー名

まずデフォルトのユーザー名がcpiだったので、新しく自分のユーザーを追加した。

Macとのやりとりも考えて、いつも使ってるユーザー名にしたんだけど……画面のいたるところに表示されてしまう!(ToT)

ちょっとー!Twitterやブログに写真載せる時に面倒じゃんかー(T-T)

画面のあちゃこちゃにモザイク入ってますが、そういう事情ゆえ(^^;;

 

ウィンドウマネージャーの日本語化

f:id:PocketGriffon:20211202184139j:plain

正直どっちでも良いと思っていたんだけど、日本語化した。

私の使い方だと、DevTerm上で日本語を表示する機会なんぞ無い可能性もあって…(^^;

でも速度を見るためにx11perfを試したら、デフォルト状態でもちゃんと漢字が出た!

うーん、元から入ってるのならば…という事で日本語化した。

人に見せる時は助かるかもね(^^)

 

ネットワーク関連

私は「作業はMac上で完結させたい」という希望がある(^^)

やはり使い慣れた環境をそのまま使うのが一番効率が良いのだ。そのためには時間を掛けて環境を構築する事もいとわない。

しかし目的が達成できるのあれば、過度な環境は期待しない。

そんな感じで今回のDevTermも見ていた。

 

DevTermに関してはLinuxマシンなので、ネットワークに関する設定で困るというシチュエーションがほぼゼロ(^^;; ファイル共有もとても簡単だ。

 

でも……今回、ファイル共有の設定はしていない。

以前、キングジムポメラLinuxを動かしていた際、基本的な運用をsshプロトコルのみに頼って作業をしていたのだが、それで困る事がほぼ無かった。

 

具体的にはMacからsshでログイン、scpでファイルコピーだ。

極めつけはEmacsによるssh経由のfind-file。これでMacを使いながらポメラ内部のファイルを自由に編集する事が出来る!Mac内部のファイルなのか、ポメラ側のファイルなのか意識しなくても良いのだ!(^o^)/

 

今回のDevTermでも同じ環境で作業をするようにした(^^)

DevTerm本体のバックアップについては何か考えないとね!(^^;

ポメラではrsyncを利用していたけど、今はもっと良い方法があるのかも??

f:id:PocketGriffon:20211202205609j:plain

↑いきなり意味のない大きさ比較w

 

気になる問題

順調そうに使っているDevTermだけど、気づいた不具合もあった。

しばらく放置した状態で画面がスリープに入ると、復帰する方法がない!ssh経由では普通に使えているので、本体がサスペンドしたのではなく画面だけの問題みたい。

この状態でマウスをぐりぐりしてクリックとかしてると、変なコマンドを実行しちゃったりするので大変危険だ!(TOT)

 

これはclockwork社の掲示板でも何度か話題が出ている不具合らしい。今のところ回避方法が見つかってないので、仕方なく画面をOFFにしなくした。電池のもちに直結する不具合なので、早めに直ると良いのだけれども…orz

Latest DevTerm topics - clockworkpi

f:id:PocketGriffon:20211202225726j:plain

↑このサイズだったらポーチに出来そう…の図

あと問題というよりは気になる点。

DevTermを充電しながら使っていると気になるノイズが聞こえる。

高周波というんだろうか、チリチリとした音がずーっとしている。運用上というよりは、気持ち的に勘弁してーってなってる(T-T) 気になっちゃうんですよね…orz

 

それとね…本体下部がとても熱くなる!

温度センサーで測ってみたら63度にもなってた!

こんな熱くなってもファンが回る気配がない…壊れてるのかな(T-T)

膝に乗せてなにかしようと思わない方が良いかもしれない。

 

バッテリー事情

DevTermの電源は、18650というバッテリーを2つ使う。普段使わないし見かけない種類の電池なので「知らない」という人も多いと思う。

f:id:PocketGriffon:20211202210904j:plain

単三電池と比べてもこのサイズ感。しかも1つで3.7V。
このバッテリーを2つも使うわけだからさぞかし長持ちしそうな印象なのだが……。

 

実際どのくらい電池が持つんだろうか?

実験してみた!(^-^)

f:id:PocketGriffon:20211202211140j:plain

これがDevTermの出荷時の状態。

6コアのうち2つは休止、4つは稼働状態で408〜1008MHzの間で動作する。

バッテリーが100%の状態で、特に触らずに放置してみたところ、約4時間で電源が落ちた。

意外に持つのね…と思うか、え?!そんなもんなの?と思うか分かれるところだろう。

ただ、上にも書いた通り液晶が消えると復帰できない不具合があるため、液晶は常時つきっぱなしだ。それも考慮に入れてほしい。

 

f:id:PocketGriffon:20211202211910j:plain

次に省電力モードに設定をして、同じく放置してみた。

コアは1つだけ動かし、かつMAXで600MHz。こんなんでちゃんと動くのか?!と思うかも知れないけど、普通に使える(^^)

 

結果を言ってしまうと、デフォルト状態との違いが分からなかった(T-T)

ほぼ4時間で電源が落ちた。

まぁ途中、何度か触ってしまってるので、条件は違ってると思う(^^;;

または液晶が大量に電力を喰うから変化が少ないとか??

 

もう少し使い方がこなれてきた頃に、もう一度試してみたいと思う!

次は液晶を最低限にしてテストしてみたいね!

 

とりあえず動かしてみる!

さて、せっかくなのであれこれ動かしてみよう。

パフォーマンスも知りたいし、使い勝手も感じてみたい!

 

twitterLinux上で動くPC-8201エミュレータがある事を教えて頂いた!

Virtual T - Browse Files at SourceForge.net

配布物の中に権利的に大丈夫かな?と思うものも含まれているため、利用される方はご自身に権利があるかきちんと調べてから起動されるのが良い。

 

これを起動してみようと思ったが、先にFTLKライブラリをダウンロードしてビルドしろとか、何気に面倒くさい(^^;; aptコマンドでダウンロード出来ないかと思ったが、残念ながら含まれていなさそうだった。

 

仕方ないのでFLTKからインストールしてみることに。Virtual T自体がFLTK1.1.7以降に対応となってるんだけど、FLTKの最新バージョンは1.3.8…。あんまりバージョンが離れるのも怖いけど、やってみるしかないかー!

 

結局、FLTKのインストールも少し大変だったし、Virtual Tに至っては現在のコンパイラではエラーになっちゃう構文もあったりして、プログラムの知識がない人にはビルド自体が厳しいかもしれない(-_-;; 

 

f:id:PocketGriffon:20211202221134j:plain

あれこれあったけど無事に動いたVirtual T。画面サイズ的にもマッチしてて良いかも!

f:id:PocketGriffon:20211202221229j:plain←PC-8201

f:id:PocketGriffon:20211202221434p:plain←PC-8300

液晶の濃さが違ってるのは、途中で設定を変えてしまったから(^^;;

 

f:id:PocketGriffon:20211202221540p:plain

そしてこれがTANDY200。

実機を持ってる身としてはとても嬉しい!(^-^)

これでプログラム開発できちゃったりしたら便利だなー!

 

他にも自作プログラムを動かしてみる…

せっかくなので自作のプログラムもいくつか動かしてみた。

 

f:id:PocketGriffon:20211202222221j:plain

↑PC-8001mkIIエミュレータで動くホバーアタックというゲーム。

 

f:id:PocketGriffon:20211202222248j:plain

PC-8801エミュレータで動くアルフォス。

 

f:id:PocketGriffon:20211202222159j:plain

↑PC-1360エミュレータで動くRayForceというスクロールシューティングゲーム

 

ここまでは元々Mac上でSDLというライブラリを経由して表示を行っていたモノ。コアな部分は機種に依存していないので移植性は高かったのだが、表示にSDLを利用した事でLinux上でもソース無変更で動いてしまった…。

 

f:id:PocketGriffon:20211202222307j:plain

↑これはコンソール上で動くCP/M80エミュレータ

cursesというライブラリを用いることで画面へのエスケープシーケンスを解決しているんだけど、同じくLinuxでもcursesがあるので問題なく動いた。

 

結論

うん、いたってふつーのLinuxマシン!(^^;;

運用面において、困った!に直面する事がほぼない。DevTermという特殊な機械だけど、Linuxマシンとして見たら周りに教えてくれる人もいっぱいいると思う。

そういう意味ではとてつもない安心感がある(^-^)

 

DevTermのサイズを生かした「何か」をしてみたい気もするけど…(^^;

うーんうーん…(^-^;;;;

 

ではまた次回!(^-^)ノ

DevTermが届いた!

f:id:PocketGriffon:20211201194342j:plain

注文していたDevTermがようやく届いた!

今回は写真多めで行こうと思う(^-^)

 

開封の儀式とか組み立てとかは他のサイトでもたくさん出ていると思うので、私はそれぞれの時にどんな事を思いながら作業してたのかを、覚えてるうちに書いておこうと思う。

 

f:id:PocketGriffon:20211201195115j:plain

やっと届いたDevTerm。

ネットの記事で本体の写真を見た瞬間に惚れ込んで注文した……と書きたいところだけど、実を言うと注文したのはだいぶあとになってからだ。手元にある注文した時に届いたメールを確認すると、2021年5月14日に発注してる。

 

この手のものは最初から一番良い性能のモノを注文する事にしている。単純に、あとから拡張しようとしても難しいだろうと思ってるからだ。

 

私が注文したのはA06シリーズのメモリ4GBのスケルトンタイプ。

CPUコア数も6つあったりと結構豪華。

実を言うと、注文を入れた時はPC-8201と同サイズだと思いこんでいた(^^;;

 

f:id:PocketGriffon:20211201201123j:plain

箱を開けた瞬間がこちら。

コレを見て「うおおお!これは萌える!」と思うのか、「……えー……」と思うかの両極端な気がするけど、私は間違いなく後者(T-T)

 

このブログを読んでる方なら分かってくれると思うけど、組み立て系が苦手なんです!子供の頃からプラモデルも完成出来た試しが無かったし、パソコンだってバラせば必ずネジが余る!

そんな感じだったのでこれを見た瞬間に萎えた(TT)

組み立てたいから買おうと思ったわけじゃなくて、使いたいから手に入れたのだ!(^-^)

完成品があったのならば、間違いなくそっちを選択してた。

 

f:id:PocketGriffon:20211201201413j:plain

↑結構厚めの組み立てマニュアル

 

f:id:PocketGriffon:20211201201445j:plain

↑コレだけを見て「コンピュータだね!」と思う人がどのくらいいるんだろうか(^^;

 

f:id:PocketGriffon:20211201201532j:plain

↑ようやく部品っぽいものが出てきた。

 

f:id:PocketGriffon:20211201201716j:plainf:id:PocketGriffon:20211201201736j:plain

↑そういえばスケルトンモデルを選んだはずなんだけど、半透明な部品ってこのくらいに見えるんだけど…まさかこれでスケルトンですって言っちゃう??(-_-;;

だいぶ後からになって、裏面がスケルトンだと気がついた(^^;

 

f:id:PocketGriffon:20211201201913j:plain

↑最初は液晶パネルから取り付けていくらしい。

パネルと基板とはフラットケーブルで繋げるようだけど、ちょっとはめづらそうだ。

裏面の写真撮り忘れてた(T-T)

 

PC-8201よりは一回りくらい小さなサイズの液晶。でも解像度は段違い。

PC-8201が240x64ドットなのに対し、DevTermは1280x480。ドット数が20倍違う。

 

f:id:PocketGriffon:20211201202601j:plain

これが外部周辺機器と繋がる基板で、上にCPUモジュールを載せて使うもの。

 

f:id:PocketGriffon:20211201202743j:plain

f:id:PocketGriffon:20211201202805j:plain

↑そしてこれがCPUモジュール。

RockchipとかRKシリーズって、何かのマシンがそうだった気がする。めちゃくちゃ調べた覚えがある型番だ。韓国から出ていたGP2Xとかがそうだったかなぁ…記憶が曖昧。

 

f:id:PocketGriffon:20211201203219j:plain

こんな感じに、上に乗っけて固定するだけだ。

このCPUモジュールを固定するためだけにドライバーが必要だった。

 

f:id:PocketGriffon:20211201203347j:plain

↑これがWiFi用のアンテナ。

本体の横の方に両面テープでぺたっと貼り付けるだけ。

プラモデルのデカールもそうだけど、失敗したらやり直せない感じがすごく苦手(T-T)

 

f:id:PocketGriffon:20211201203455j:plain

↑これはアンテナ、ファンがついた基板、プリンタなどを載せた状態。

プリンタも簡単な固定をしているだけだ。

そういえば熱転写のプリンタロールなんて持ってたかな…。

 

f:id:PocketGriffon:20211201203626j:plain

電池ボックスも載せて、これでほぼ全実装。

電池は18650という単三電池を一回り大きくしたような電池を使う。

f:id:PocketGriffon:20211201203951j:plain

↑何かのバッテリーを作ろうとした際にサイズが18650と同じだった事があった。そのため、うちにはそれなりの数の在庫があったままだったのだ!

今回、ようやく日の目を見る(^-^)

 

f:id:PocketGriffon:20211201204127j:plain

↑表を向けるとこんな感じ。

 

f:id:PocketGriffon:20211201204425j:plain

↑キーボードを上に乗せる感じ。

一応、くぼみにはめ込む感じではあるけれども、固定されてるとは言い難い。

 

f:id:PocketGriffon:20211201204630j:plain

↑ちなみにキーボードのサイズはこんな感じなので、タッチタイプには向かない。

補助的なキーボードとして使うイメージだろう。

それでも無いよりはある方が圧倒的に良い(^^)

 

f:id:PocketGriffon:20211201204758j:plain

↑ふたをしてこんな感じ!

両側についてる丸いものが本体を固定しているモノ。

決してプリンタ用紙の先送り用のダイヤルではない!(^^;;

 

細かい部分は組み立てる必要がないので簡単といえば簡単だ。

プラモデルが苦手な人でもなんとかなった!(^^)

 

ところで……

f:id:PocketGriffon:20211201204933j:plain

部品が余ってしまったのだが……(-_-;;

 

最初は全く意識していなかったけど、あとから見直してみて部品っぽく見える。

組み立てマニュアルには出てこなかったし、部品リストにも存在はなかった。

裏がシールになってるんだけど、もしかしてCPUのヒートシンクだったりする?

だいぶ組み立てちゃったんだけど…(T-T)

 

さすがに1.8GHzにもなるCPUに冷却用具なしは危険か…

仕方がないので、一度分解するハメに(ToT)

f:id:PocketGriffon:20211201205233j:plain

↑こんな感じ??

…せっかくスケルトンモデルなのに、これじゃあヒートシンクしか見えない(T-T)

 

f:id:PocketGriffon:20211201205421j:plain

↑ほらー!!

ケルトンモデルなのに、見える部品の代表がヒートシンク!!

どーなのよこれ(^^;

とほほ…(-_-;

 

f:id:PocketGriffon:20211201205821j:plain

プリンタの用紙、HC-20用がサイズ的にぴったんこなんじゃないの??

この用紙だったら大量にあるので多分一生困らない!(^-^)/

 

f:id:PocketGriffon:20211201205919j:plain

ほらバッチリ!!!!

これは嬉しいね!

 

……と思ってたら、HC-20のプリンタロール紙は感熱タイプでは無かった…orz

残念…せっかく使いみちが見つかったと思っていたのに(TT)

 

仕方ないので、PASOPIA miniか何かに付いてきたロール紙を使うことに。

サイズはだいたいどれも入るんだね。規格品??

今でもとても簡単に手に入るみたいなので、手軽にプリントアウト出来ちゃうね(^o^)

 

さあ、緊張のスイッチオーン!!!!

f:id:PocketGriffon:20211201210220j:plain

最初の数秒間、何も表示されなかったので「しまった、組み立てに失敗した!」と思っていたが、どうやらLCDが認識されるまでは表示が出ないようだった。

これは焦る!!

 

f:id:PocketGriffon:20211201210350j:plain

よーし、問題なく起動しました!

キーも打てる、音も出た、USBも無線LANも使えた!

ちょっとだけ心配だったバッテリーも使えている模様!

 

ちょろっと使ってみて…これだけはいただけないかも…と思ったのが、ポイントデバイス

f:id:PocketGriffon:20211201210513j:plain

てっきりThinkPadのようなぐにぐにするタイプかと思いきや、このサイズでまさかのトラックボールだった!これは……こればっかりは使いにくい!!(TOT)

早々に無線マウスに切り替えてしまった!

 

f:id:PocketGriffon:20211201210700j:plain

Youtubeも視聴も問題なし!(^-^)

ただ全体的にもっさり動く感覚はあるけど。

こういうもんかなーと思う!

 

さあ、せっかく使えるようになったDevTerm、何に使おうか!(^-^)

このサイズ感、何か動かすか作りたいよね(^^)

まずは使う環境を整えていきまーす!

 

ではまた次回!(^-^)ノ

RaspberryPi PicoでBad Apple!!その2

f:id:PocketGriffon:20211201090120j:plain

前回に引き続き、今回もBad Apple!!の話題を書いてみる!

今回も文章多めだ!(^-^;;

 

前回作ったBad Apple!!は、いろいろと工夫をしたけれども、最終的には妥協をした部分もあった。

 

苦労はした、工夫もした、でも妥協もした、というのが前回。

今回は、あんま苦労しなかった、工夫もしなかった、でもフル画像で出来た!

この違いはなんだろう…(^^;;

その辺り、詳しく書いていってみようと思う。

 

SDカードからの読み込み速度改善

絵が240x180から320x240の大きさになるということは、すなわち画像サイズに直結するという事。圧縮しているので単純に1.7倍というわけではないが、平均して3割ほどデータが大きくなっている。

SDカードに載せたデータサイズは、前回が約7MBだったのに対し、今回は10MB弱だ。

 

データサイズが大きくなるということはSDカードからの読み込み速度も厳しくなる。しかし、実は前回のBad Apple!!よりもSDカードの読み込み速度が著しく向上しているのだ!

 

元のライブラリは200KB/秒くらいの速度だったが、それを375KB/秒に改善して挑んだのが前回のBad Apple!! 。そして今は900KB/秒くらいまで速度が上がっている!

あお氏(@hd61yukimizake)と共に、日夜ライブラリの最適化に勤しんだ結果だ(^^)

 

このおかげで、前回よりも読み込むデータ量が増えているにも関わらず、速度は速くなったという逆転現象が起きている!

 

表示速度向上のチャレンジと挫折

少し前にTwitterへ「表示をDMAで行うと速くなった」という旨の投稿をした。

 

LovyanGFXなどでもスプライトの描画は(条件があえば)DMA転送をしていると読んだ事がある。RaspberryPi PicoでもDMA機能はあるし、チャンネルもたくさんあることから、同じように表示で使えるのではないか?と思って実験を繰り返していた。

 

RaspberryPi Picoで画面表示にDMAを使用する例を探してみたが、ネット上ではどうしても見つけることが出来ず、RP2040のデータシートとにらめっこをしながら独自で作り上げた(^^;

f:id:PocketGriffon:20211201102130j:plain

画面いっぱいを表示するのに掛かる時間は21msと、それまでの50ms以上掛かっていた状態に比べると、だいぶ速くなる事が分かった(^-^)

 

しかし…いざ、Bad Apple!!に組み込もうとしたら、DMAの初期化不良なのかなんなのか、画像がズレていく現状が出て悩まされた。

f:id:PocketGriffon:20211201092936j:plain

これはデータが送りきれていないか、逆に送りすぎてしまうと起きる現象だ。

 

こういうおかしな現象は、表示系のライブラリを改造してる流れで何度も見たことがある(^^; 単純にデータの転送数を間違う場合とか、SPI側のFIFOがFULLの時に書き込みをしてデータを喪失した場合も起きる!(^^;;;

 

SDカードからの読み込みを止めるとピタっと現象が収まることから、同じSPIを利用した周辺機器との関連である事は間違いなさそうなのだが、今回はどうしても原因を突き止める事が出来なかった。

 

DMAに関しては完全玉砕だ!(TOT)

 

別アプローチで表示速度向上

これは…正直やって良い事はどうかわからないので詳しくは書けないのだけれども、一言で言えば「SPIの速度をあげた」。

 

このBad Apple!!のプログラムではgfx->drawなんとか系の関数は使わず、独自でSPI転送をして描画速度を上げる事をしている。

 

Picoの表示ライブラリ内では「SPIのFIFOに空きが出来るまで待つ」をしてからデータを書き込んでいる。これを「SPIのFIFOが全て空になった」状態から、何個のデータまでを突っ込んでも大丈夫なんだろう…とか、FIFOサイズを意識したプログラムに変更してみたりしてた。

表示の汎用ライブラリを作ってるワケではないのでやりたい放題だ(^^;;

 

そんな極端な実験をしている最中に、DMA側の設定をOFFにし忘れてSPI速度を上げたまま動かしてしまった(つまり間違いから発覚した)ところ、描画速度が上がる事に気がついた。

 

実は以前にも同じようなテストはしているのだが、その時は思ったような改善が見られなかったため、ハードへの負担も考えて禁忌としていた。

しかし…今回分かったことだが、これをするとDMA並の速度まで上がるのだ。画面全体を更新して21ms、ほぼ同じだ。うーん、DMAがうまく動かない現状でこれは捨てがたい……。

 

ハード側への負担を理解した上で、自分の元でのみ使う事にした(^^)

 

圧縮データの扱い

前回は圧縮されたデータを、モノクロデータ(1バイト8ドット)のデータとして展開をし、これを表示時にRGB565に展開しながらSPIへ送り込んでいた。

 

今回はDMAを使う意思があったため、全体をRGB565に展開したフレームバッファを用意する必要性が出てきていた。データの展開速度はどうあれ、320x240で150KBもあるメモリへの展開、時間がかかるだろうなぁ…と予測していた。

 

それが……実際にはものすごく軽かった!想像していたよりも1/5くらいの時間で終わってる!この手の処理で想定を外すことは滅多にないんだけど、なんか想像よりも速いぞPico!

 

そう、なんとなくだけどPicoは良い方向に期待が外れる事が多い。なんでこんな速いんだろう…ベアメタルがゆえにいろんなサービスが走ってないからだろうか…。

 

結局、データの展開とRGB565への変換処理が3.5msで処理が終わる事が分かった。

 

コアを分ける意味が…

SDカードからの読み込みに5ms以下

データ展開に3.5ms

フレームバッファを表示するのに21ms…。

 

前回はSDカードの読み込みと表示をコア0、データ展開をコア1に処理させていたのだけど、今は全ての処理時間を合わせても1/30秒(33.33ms)以下で終わってしまう事が判明。

むしろ時間を待つ処理をいれないとイケナイ!(^^;;

 

コアを2つに分けたとしても単純に処理量が2倍にならないというのは理解されてる事と思うけど、前回のBad Apple!!でもお互いのコアが終わるのを待つ処理がいくつか入ってた。SDカードを読み終わるまで展開処理に移らない、とか(^^)

 

そういうコードも全部外す事になったので、結果的に1つのコアが目一杯動けるようになった気がする。とてもエレガントなコードになったね!!(自画自賛

 

終わりに…

なんとなくBad Apple!!に注目してRaspberryPi Picoの最適化をしてきたけど、びっくりするのはPicoの潜在能力の高さ!

133MHz(Arduino IDE上では125MHzでビルド)でここまで動くとは!

ちょっと皆さん、Pico触りましょう、Pico!(^-^)/

 

まだまだ余裕がある状態なので、M5Stackの時に諦めたグレイスケールなBadも挑戦出来ちゃうほどだなぁ…とか思っちゃう(^^;

ぎりぎり動いてたFM-7も、きっと余裕で動く気がしてきた(^^;;

うーん、これだけ使っても夢が広がってくる…Picoの限界を見てみたいね!

 

ではまた次回!(^-^)ノ

RaspberryPi PicoでBad Apple!!

f:id:PocketGriffon:20211129195549j:plain

一体、何回作るんだ!?と思われてしまいそうなBad Apple!!

今回はRaspberryPi Picoで動かしてみた!(^-^)

検討から実験、実装までを書き記してみたい。

文章多めです!写真は適当w

 

実装の検討

今までも何度もやっているBad Apple!!を、何故またやってみようと思ったのか。

表示SDアクセスCPUの高負荷を同時にやろうと思うと、それなりの規模もモノを動かす必要がある。CPUと表示についてはゲームなどを動かしたら高負荷になりがちだけど、SDカードへの同時アクセスとなると、もはや動画くらいしか思いつかない。

 

mpegなどの表示もチャレンジしてみたいけれど、中でどんな計算をしているのかを把握していないので、正直それが重いのか軽いのか見当がつかない。

やはりここは全てを自前で書いてみたい衝動にかられる!かられた!(^^;

 

Picoでボトルネックとなるのはなんだろう?

M5Stackと比べて、表示も遅い、SD読み込みも速くない、CPUのクロックは半分だ!ボトルネック全部!といいたくなるが、そうも言ってられないのでひとつずつ調べてみる事にした。

 

画像関連

f:id:PocketGriffon:20211129214324j:plain

Bad Apple!!は秒間30フレームの映像で出来ている。この転送速度に間に合うのかは、見栄えも含めて大きなファクターとなっている。

SMART Response XEなどは表示が全く間に合わず、そうそうに諦めてしまった。

実機が目の前にあるので、これは実験をしてみるのが早い。

 

RGB565フォーマットで320x240の画面全体を描き変えてみると、約57.5ms掛かった。

秒間17.4回くらいの画面書き換えが出来る計算だ。

うーん、これではかなーりゆっくりとした映像となってしまう(-_-;;

 

そういえばGFXライブラリのソースを見ている時に、モノクロキャンバスがある事に気がついた。今まで意識したことも存在も知らなかった(^^;;

単純計算でフレームバッファが1/8になるので、試してみる価値は高いだろう!

 

モノクロデータに変更して画面全体を描き変える速度を測ってみたところ、約130ms掛かるようになってしまった!まさかの秒間7.7回にダウン。

ライブラリのソースを確認してみたところ、データを1バイトずつ取り出してビットがONかOFFかでカラーを変えつつデータ出力している。うむむ…単純にCPU処理が増えたせいか??

 

今回の取り組みでは画面全体を出力する機能しか使わないのだから、SPIを直叩きして高速化をしてみる事に! さらに1色ずつデータを出力するのはもったいないので、横8ドット分のデータを一気に描画する事にしてみたところ、56.5ms秒間17.7回の書き換えまで復活した!

 

しかし…これ以上がなかなか速くならない。いろいろ試してみたが、頑張った割に3%の速度アップとかそういう感じだったので、ここはもう!覚悟を決めて画像サイズを小さくする決断をした!(T^T)

 

画面全体は320x240ドットのサイズだけど、思い切って240x180ドットまで小さくしてみた。小さくなった分、フレームバッファのサイズも9600バイト→5400バイトとダウン。

その分、表示速度も速くなり約32msとなった!

これでなんとか秒間30回の書き換えが出来るメドがたった!(^-^)

 

SD読み込み関連

f:id:PocketGriffon:20211129214533j:plain

SDカードからの読み込みは、そのままデータ圧縮にも直結する。データを小さくすればするほどSDカードからの読み込みが速くなるからだ!

しかしあまりにも無茶な圧縮をしてしまうと、今度はデータを展開するのに時間がかかってしまい、本末転倒となる。この辺りのさじ加減がとても難しい。

 

SDカードからの読み込みは、前回のブログを書いた時には200KB/秒くらいが限界だったが、その後ライブラリの見直しをして375KB/秒くらいまで速度アップがなされた!

もちろんあお氏(@hd61yukimizake)の功績が大きい(^-^)

 

データの圧縮方式を説明すると長くなるので、可能な限り割愛しようと思う(^^;;

圧縮ツールは既存のものは使用せず、Bad Apple!!ごと独自で開発している。実を言えばこれもBad Apple!!に取り組む楽しみのひとつだ(^-^)

 

今回の方式を一言で言えば「ランレングス+無圧縮(マーキング方式)」とでも言うべきか…。バイト単位の圧縮で、圧縮率はそんなに良くないがデータ展開はすこぶる速い。PC-1600KのBad Apple!!でも似た方式を採用したが、おそらく今回の方が圧縮率が高い。

 

無圧縮で5400バイトのところ、今回の方式では一番サイズの大きなデータで2723バイト。最も小さいデータで87バイトだ。これらもろもろのデータが含まれて、全てのデータを合わせた合計サイズが約7MBとなっている。

 

もっとも条件の悪いタイミングであっても、データサイズは80KB/秒が上限。

SDカードからの読み込みとしてはかなり余裕があることが分かった(^-^)

動いてる速度を測ってみたが、1フレームの絵が5〜8msでデータを読めている。

 

CPUの負荷

f:id:PocketGriffon:20211129214631j:plain

PicoのCPUは133MHz動作だ。Arduino IDEではなぜか125MHzが標準となっていたため、この設定をそのまま使っている。

CPUコアが2つあるため、今回はコレを上手を使ってみる事を自分に課した(^^)

 

SDカードと画像(GFX)は、同じSPIを使っているためバラバラなタイミングで呼び出されると少々厄介だ。そのため、この2つの処理は1つのコアで実行させることとした。

具体的には、コア0にはSDカードの読み込みと、出来上がったフレームバッファのデータをLCDへ送る仕事を任せた。コア1はSDカードから読み込まれた圧縮データをフレームバッファに展開させている。

 

両方のコアを無駄なく動かすために、フレームバッファを2つ用意した。コア0で表示処理を行っている最中に、コア1でもうひとつのフレームバッファに展開する。おそらく、一番効率よくCPUが動く手法だろう。

 

出来上がってみて

ひとつずつ確実に積み重ねながら作っていったが、正直ここまでうまくいくとは思っていなかった。むしろまだ速度的に余裕があるくらいだ。

 

フレームバッファの格納方法を変更(RGB565→Mono)した事で、CPUの負荷がどどーんと下がったのかも知れない。8ビットのデータを展開するのではなく、16バイトのデータ列としてあらかじめ作っておき、それをそのままLCDへ転送したのだが、これもキャッシュなどの兼ね合いで良い結果を生んだのかも知れない。

 

ここまで動くようになると、やっぱりサウンドをなんとかしたいねぇ…。

でもPicoでこれ以上の負荷は…うーん(^^;;

 

ではまた次回!(^-^)ノ

RaspberryPi Picoと液晶パネルを有効活用!

f:id:PocketGriffon:20211128141717j:plain

何回か前のブログにて、RaspberryPi Picoに液晶パネルを取り付けたという話を書いた。

 

pocketgriffon.hatenablog.com

 

この液晶パネルは「Pico-ResTouch-LCD-2.8」という商品で、2.8インチの液晶に加えて、タッチパネル搭載、SDカードスロット付きという、だいぶ欲張った構成となっている。

Pico-ResTouch-LCD-2.8 - Waveshare Wiki

 

プログラムで使えるようになるサンプルが上記リンクにあったけれど、Pico用ということでCMake環境でビルドするようになっていた。

しかし最近の私はArduino IDEがお気に入りで、開発環境もこちらに移している。

 

このArduino環境で動くサンプルが無かったので、仕方なく元のサンプルを参考にしながら、液晶パネルのみ動かすように最低限のコードを書いた。

 

その上で動かしたのが前にブログに書いたFM-7エミュレータだ。

pocketgriffon.hatenablog.com

 

そんな限定的で汎用性のカケラもない目的で開発したものだったので、タッチパネルは使えない、SDカードも使えないという、ハタから見たら「さすがにもったいないのでは??」という状態だった(^^;;

 

単純に元のサンプルを移植してきたら?と言われそうだけど、SPIとかGPIOを根本から理解していない私にとって、その辺りのハードが絡むコードは呪文に見えてしまい、もう液晶だけでいいか…と思っていた(^^;;

 

ちょっとした事情があり、あお氏(@hd61yukimizake)に同じ液晶をお送りしていた。

その後、私はFM-7を動かりたり、micro:bitPC-8001動かしたりBad Apple!!を動かしたりして遊んでたりしてたワケだけれども…

その裏であお氏の超快進撃が始まっていた!!

 

Arduino環境で液晶パネルを動かすための作業が進んでいたのだ!

Arduino環境で画面が出ました」

「サンプルのグラフィックデモが動きました」

「ハードウェアSPIが対応出来ました」

と矢継早にメッセージが飛んでくる!!

 

やはり正しく理解してる人から見たら一瞬作業なんだな…と思いつつ、私はそのドライバを利用して、より過酷なテストをするべく画像を表示させたりと、なんとなく作業が分担されるカタチで進んでいく!

f:id:PocketGriffon:20211128154002j:plain

その後も
「SDカード動きました」

「タッチパネル動きました」

とガンガン作業を進められるあお氏!

より過酷なテストをするべくサンプルを組み上げる私。

結果的に2日間ほどで3つの機能が動いてしまった!おそるべし!!

 

その後も気になる箇所をちょこちょこ直したり調べたり(^-^)

おかげでPico関連のライブラリソースをだいぶ見ることが出来た!

f:id:PocketGriffon:20211128155115j:plain

ここまで動くと、何か耐久テストも含めて作ってみたくなる!(フラグ?)

 

プログラマブルI/Oの実験

f:id:PocketGriffon:20211128160408j:plain

おなじくあお氏から勧められて手に入れたインターフェース誌。

これにPico関連の事がものすごーく詳しく掲載されている。

その中でPicoの特徴といえば、プログラマブルI/Oという機能らしい!

 

私のつたない解釈を日本語で書けば「I/Oアクセスを専門に行ってくれる超小型のCPUっぽいものが載っていて、それをプログラミングして実行しておけば、メインのCPUから離れたところで処理される」…みたいな感じ??

 

動くとなれば動かしてみたくなるのがオトコノコってモン!

インターフェース誌と2、3のネットサイトを見ながら試してみるけど…全然うまく動かない(T-T) プログラムの内容を理解せず、適当にコードを切り貼りしてるだけなのに…!←多分ソレが原因

 

1時間半ほど悩んでいたが、結局コードを理解せずにやってたのがダメだった!

それぞれの関数の意味を調べ始めたら、ワリとすぐに原因判明(T-T)

f:id:PocketGriffon:20211128162316j:plain

無事にLEDを光らせる(点滅させる)ことが出来た!!

そういえばPicoでLEDを光らせるのって初めてかも!(^^;;

登竜門であろうLチカをやらずにPicoで遊んでるのって、やっぱりPico本来の目的と外れてる気がする…汗

 

このプログラマブルI/O、私レベルの人間で何に使えるのだろう…と考えてみたけど、全く思い浮かばない…。ホントはLCDへのデータ転送で使えたら良いんだろうけれども、CPUで転送しても待ちが入ってる状態なので、プログラマブルI/Oを使うまでも無い…って感じ。

 

結局、この機能は独自でハードウェアを繋げられる人が便利に使う機能なのかな…と自己解釈(^^;;
とりあえずビルド出来る環境は作れたので結果としてはおっけー!

 

-----

最近はソフト屋さんから見たハードよりの事をかじってる気がする!

根本からハードをやろうとすると学習することが多すぎる気がしてなかなか一歩が踏み込めないですね…。先に「これを作りたい!」があれば良いんでしょうけれども(^-^)

 

最近ではボードマイコンLCDを繋げる方法がおぼろげに理解できて来た気もするので、前にaitendoのセールで意味も分からず手に入れてしまった液晶パネルとか、有効活用できる日が来たのかも!!

そのうち頑張ってみる(^-^)

 

ではまた次回!(^-^)ノ

micro:bit v2でPC-8001エミュレータ!

micro:bitというシングルボードコンピュータをご存知だろうか?(^-^)

 

f:id:PocketGriffon:20211125184126j:plain

f:id:PocketGriffon:20211125184254j:plain

2種類が発売されていて、右→が初代、左←がv2と言われるモノ。

イギリスで開発された、主に教育用途のコンピュータのようだ。

日本でも何年か前から入ってきていて、micro:bitを扱った本もたくさん出てる。

 

micro:bitのv1の方(先に発売されていたタイプ)は何年か前に手に入れていたが、今まで使うチャンスが無く、この先も無いかも知れない…汗

 

プログラムはScratchで書ける。

というか、実はつい先日まで「Scratchでしか書けない」と思い込んでいた(^^;

秋葉原千石電商micro:bit用の液晶モニタを見た時、あれ?もしかしてScratch以外でもプログラム書けるの?…と調べてしまったのが運のツキ(^^)

何か動かしてみようって気持ちになった!

 

micro:bit 本体

f:id:PocketGriffon:20211125210338j:plain

こちらが今回の主役、micro:bit v2!

ARM系のCPUで動作クロックは64MHz。

メモリはFlashが512KB、RAMが128KB。

基板の真ん中がCPUかと思ったらスピーカーだった!

f:id:PocketGriffon:20211125212847j:plain

USBケーブルを挿し込むと、いきなり電源が入る。

あらかじめ入ってたプログラムが動くんだけど、LEDが光りまくるわ音が出まくるわで夜に開けない方が良いかも知れない(^^;;

 

まずは本体単体でちゃんと動くかのチェック。

実はこれも今回知ったのだが、Arduino IDEmicro:bitの開発が出来る。

Arduino IDEでmicro:bitの開発を行う準備 nRF5用ボードマネージャーの登録 | micro:bit Lab.【マイクロビット】

↑このページを参考にさせて頂いた。本当にありがとうございます!!(^^)

 

簡単なサンプルを作ってみたが、開発する時の感覚的にはM5Stackとほぼ同じだ。

ものすごく便利に感じる(^^)

最初の頃は「IDEって苦手なんだよねー」とか言ってたのが懐かしい(^-^;

 

液晶パネル

f:id:PocketGriffon:20211125215007j:plainf:id:PocketGriffon:20211125215022j:plain

そしてこちらが今回使う液晶パネル。

大きさ的にはmicro:bitよりも一回りくらい大きい程度。

1.8インチという小型サイズでありながら、解像度は160x128ドット。

液晶のパネル?コントローラー?はST7735Sというらしい。

今までまーったく意識した事が無かったけれど、こういうボードマシンにつなげる場合にはコントローラーの型番が重要になってくるらしい。

 

そして前回のRaspberryPi Picoで意識するようになった、どのピンがどこに接続されているのかを知る情報もあった。

1.8inch LCD for micro:bit - Waveshare Wiki

こういうのってホントに意識したことがなかった…。

すごく良い勉強になってる気がします(^^)

 

前回のPicoの時は、LCDへのアクセスを自前で書いてみた。私の利用方法といえば、フレームバッファからLCDへどどーんと一気書き!くらいしか使わないため、それでも十分だった。

 

今回はサンプルがあるので、それを素直に使ってみる流れにしてみる。

サンプルはCS、RST、DC、MOSI、SCLKのピン番号を合わせるだけで動いた!

f:id:PocketGriffon:20211125220812j:plainf:id:PocketGriffon:20211125220835j:plain

f:id:PocketGriffon:20211125220905j:plainf:id:PocketGriffon:20211125221139j:plain

ここんところ、サンプルが動く経験とか無かったから妙に嬉しい(^^)

何でも良いので動くプログラムが手元にある安心感は計り知れない!

 

よし、じゃあこのプログラムを利用しつつ、画面全体を更新するプログラムを書いてみよう!

そう思って試したのがコレ↓

 

これは……orz

1画面(というか、すでにこの時に160x100でテストしてたw)を描き替えるのに、0.6秒くらい掛かってる。

0.6秒はヤバいでしょ…。いくらCPUが64MHzとは言え遅すぎる(T-T)

 

ソースコードを追いかけるものの、C++のクラスは本当に追いづらい…(-_-;;

遅い原因まで絞り込めないまま、やっぱり1から書いた方がいいのかな…と思い始める。

 

そんな時、何気にコメントに目が行く。SoftwareSPI / HardwareSPIという単語。

そういえばSPIってソフトウェアとハードウェアがあるらしい。どういう設定をすると切り替わるのか、切り替えられるのか、切り替わっちゃうのかがわかってない。

わかってないけど、ハードウェアSPIの方が速いらしい。

半信半疑でハードウェアSPIを利用するというエントリに変更してみる。

 

うおおおお!!!これは!!!(@_@;;;

いきなり画面更新の速度が6倍以上速くなった!

 

うーん、結局のところ、どんな条件が揃えばハードウェアSPIが使えるのかがわかってない。

これは詳しく勉強しておきたいところだ!(^-^)

 

PC-8001エミュレータを移植する!

よーし、準備は整った!(気がする!)

これで勝つる!(気がする!)

 

液晶パネルを手にした瞬間から思っていた「PC-8001エミュレータを移植」してみる事にする!実際のところ、micro:bitのCPUとメモリから察するに、PC-8001エミュレータが限度だと思っていたので、今回は迷いなくターゲットを絞った。

 

先に128KBあるRAMの使い道について検討をしておく。

まずフレームバッファが160x100x2バイト構成で約32KB。

PC-8001のメインメモリが64KB、ROMが24KB、動かすゲームのデータが約8KB。

うん、ぴったり128KBになっちゃった!!(ToT)

このうち、どのデータがRAMに入り、どれがFlashに置かれるんだろう?

プログラムコードはFlashのまま?それともRAMに入る?

そもそもmicro:bitを触るのは今日が初めてなので、勝手がわからない!(^^;;

 

試してみたところ、どうやらconstデータはFlashに置いたままになるようだ。特別なアクセスもなく、そのままポインタ経由でデータが読めた!

逆に……なんとプログラムコードはRAMにコピーされるようだ!

そんな……エミュレータのプログラムってでっかいんだよ…(T-T)

 

何も考えずにフルセットを入れたところ、RAMが46KB足りないとエラーが出た!

46KB!よんじゅーろっきろばいと…!!

えー…これはちょっと……orz

 

ここから壮絶なメモリとの戦いが始まった!(^^;;;

まずはエミュレータ内部に入っていた逆アセンブラのコードを引っ剥がす。実際にコードを削るのではなく、プログラムから呼び出さなくすればリンク時に外される。依存しているところをコメントアウトしまくって、比較的大きな逆アセンブラ全体を削った。

それ以外にも、必要のなさそうなデータやバッファも削りまくり!

これらを減らしたところ、あと24KB足りないと表示された!

くそ、意外に減らないな…!!

 

次にPC-8001のメインメモリを削り始める。

RAMは64KBではなく、前半の24KBはROMが入るので40KBで良い。さらに6000h〜7FFFhの空間は何も無くても良いのでこの8KBもいらない。これで32KBと半分になった。その分、メモリをアクセスするプログラムが複雑になるが仕方ないだろう。

 

これでようやくPC-8001が起動するようになった!!

このあともちょっとコードを足すたびにビクビクしながら動かしていく事になった(^^;

 

終わりに

f:id:PocketGriffon:20211125224440j:plainf:id:PocketGriffon:20211125224405j:plain

micro:bitはシングルコアのマシンなので、CPUのエミュレーション処理と画面更新処理を分けることが出来ない。どちらも同じコアでタイミングを見ながら処理するしかないのだ!

 

64MHzで動くARMプロセッサでは、PC-8001を完全にエミュレーションするのは難しいみたいだ。まだまだ姑息な高速化手法はあるのだが、プログラムを追加するとRAMが溢れてしまうため、簡単ではなさそうだ。

 

CPUパワーも画面更新もちょっと足りないけれど、静止画を見る限りでは「PC-8001だねー」って言われる絵が出たと思う。

 

実際に遊べるようにはなってないけれど、Z80のエミュレーションくらいなら動くことがわかっただけで大満足でした!

 

今見るとラリーXの色がちょっと変だね…。もう面倒だから直さないけど!(^^;;

 

正直に言っちゃえば、micro:bitはもっとおもちゃおもちゃしてるマシンだと思ってた!

でも実際に使ってみると、ちゃんとしたコンピュータだった!

これこそ「こんなのでエミュレータ動かす??」ってマシンだと思う(^^)

人の道ならず、マシンの道を外れるって楽しいなぁw

 

ではまた次回!(^-^)ノ

 

RaspberryPi PicoでFM-7を動かす!

f:id:PocketGriffon:20211124165621j:plain

ブログのネタにならないのでは??と思うほど、あまりにあっさり移植出来てしまったFM-7エミュレータ(^^;;

今回も頑張ってRaspberryPi Picoの使い方を踏み外してみたい!(^^)

 

FM-7のソースファイルは、M5Stackで使ったものをほとんどそのまま持ってきた。

この時のブログがあるので、こちらも参照してもらいたい。

pocketgriffon.hatenablog.com

 

今回はPicoに持ってくる際に注意した点などを書いてみようと思う。

写真が少なくてテキスト多めになりそう(^^;;

 

Picoで何かを動かそうとした場合に気になるのは、メモリとCPUパワーだと思う。

 

メモリ事情

メモリ…この場合のメモリはRAMだけど、RAMは256KB+8KBの合計264KBある。多分、自由に使えるのは256KBなんだと思う。

自身が作ったプログラムは、Flashメモリに置かれたまま実行されるらしい。速度を要するところのみRAMにコピーするのだとか。

 

ライブラリのソースを見ていると「__not_in_flash_func(関数名)」という定義がある。

どうやらこれを関数名に付けると、リンク時にセクションが分けられてブート時にプログラムがRAMにコピーされるのではないかと推測。

 

ここぞという関数には積極的につけたいところだけど、今回のFM-7では有効活用出来なかった。モノは試し…とばかりに、フレームバッファを描画する関数につけてみたが、ほとんど速度向上が見られなかった。

 

気になって逆アセンブルしてみたところ、Flash上にあるプログラムはARMコードなのに対し、RAM上にあるプログラムはThumbコードとなっていた。あれ?なんとなくイメージ的に逆なのだが…汗 おそらくRAMを節約するためにそうなっているのだろう、うん。

#ビルドオプションも標準では「-Os」だからね…

 

FM-7の説明はいらないとは思いつつも、念のため。

FM-7は6809CPUが2つ載っていて、それぞれメイン/サブとして別の役割を持つ。

メモリ空間も64KBが2つある。

さらにメインCPUはバンク切り替えで32KBのROMも持つ。イコール96KB必要。

FM-7のエミュレーションをするためには最低でも160KBのメモリが必要となる。

256KBのうち62.5%がメモリのために使用される。

 

残りの96KBでは全画面のフレームバッファが持てないため、今回は画面を上下半分に分割し、上画面を生成→描画、下画面を生成→描画としている。フレームバッファは本来必要だったはずの125KB(320x200ドット)の半分である62.5KBで済んでいる。

 

残りはRAMに置かれるプログラムとグローバル変数で使い、最終的に256KBの93%が使用された状態!残りの18KB弱をローカル変数とスタック領域で使用する。

思った以上にギリギリだ!

 

CPU事情

PicoのCPUは、ARMコアが2つ載っている。
動作周波数は公式には133MHzらしいのだが、なぜかArduino IDEでの標準は125MHzになっていた。特に困ってなかったので、今回は125MHzの設定のまま利用した。

 

2つコアには、それぞれに別の処理をさせている。

 

Core0は2つある6809CPUのエミュレーションを担当。

現状では2つをエミュレーションするのに精一杯で、他のことは何も出来てない。動作を実機種と合わせるためのタイミング取りもしていない。

今の状態で実機よりもほんの少しだけ処理が速いようだが、まさに限界だ!(^^;;

 

Core1ではVRAMの情報からフレームバッファ情報に変換、その後LCDへ送り出している。上記のメモリ事情により画面全体を一気に処理できないので、上下半分に分けている。

こちらのコアもフルスピードで動かしっぱなしにしている。

 

両方のコアともフル稼働している状態だが、コアの温度は14℃(起動時)→22.5℃とちょっと上昇する程度で済んでいる。現にチップに触れてみてもアチチとはならない。

頼もしいぞRasberryPi Pico!!

 

f:id:PocketGriffon:20211124210350j:plain

 

まとまってないまとめ

PicoでのエミュレータFM-7が一番の鬼門だろうな…と感じていた。

これはCPU的にもメモリ的にも(手元にあるエミュレータの中では)一番厳しいからだ。

逆にPC-8801でのアルフォスは、動いて当然だろうと思っていたので検討すらしなかった(^^;;

 

とりあえず125MHzのARMであれば、FM-7エミュレータが実マシンよりも速く動く事が分かった!これはちょっとした挑戦ではあったけれども、素直に喜びたい(^-^)

 

ではまた次回!(^-^)ノ