RaspberryPi Picoと大型液晶で遊ぶ！

以前、RaspberryPi Picoに320x240ドットの液晶を取り付けてさんざん遊びまくった！

pocketgriffon.hatenablog.com

今回はソレを超えるサイズの液晶をRaspberryPi Picoに取り付けてみた。

サイズ的には480x320ドットと、前回よりも一回り大きい。

多分、Pico専用として売られているものでは最大サイズなんじゃない？？

２つを比べてみると、↑こんな感じ！

ひっくり返すとこんな感じにPicoがついてる。

Picoの大きさから、なんとなくなサイズ感が分かるだろうか(^^;
Picoに取り付けてると言うよりは、もはやPicoがついてる感じ。

前回はあお氏(@hd61yukimizake)と一緒にドライバの解析改良に勤しんで、最終的にはかなりの速度が出るようになっていた。しかし毎回巻き込むわけにはいかないので、今回はひとりで踏ん張ってみる！(^^;;

表示、SDカード、タッチパネル

Waveshare社から用意されているサンプルは、CMakeを基本とした開発環境用のモノとなっている。これをArduinoIDE環境で使えるように変更していかないといけない。

今回はきちんとサンプルコードを探したので、比較的簡単に画像を表示させる事が出来た！

表示させるだけだったらそこまで難しくない。

プログラムの移植を始めて、30分後には絵が出た感じだ！

だけど……恐ろしく表示が遅い(T-T)

画像データは(まだこの段階でSDカードが使えないので)Flashメモリに入れてある。アクセス速度はそこまで遅いはずがないんだけど、サンプルコードを実行すると表示し終わるまでに約１秒掛かる。

画像をメモリに置いてあるのに１秒って…orz

さすがにこのままではちょっとアレなので高速化する事に(^^)

転送するビット幅を8bit→16bitに変更、2バイトずつ転送していたのをまとめて転送するように変更、そしてSPIの周波数を60MHzまで上げてみた。

この変更で、全画面表示に掛かる時間が0.1秒(100ms)ほどとなった。

さらなる高速化をするためにはDMAを利用するなどの工夫が必要かも？

全画面描き替え速くなったよ！
958ms → 90msと10倍以上速くなったので、これなら何か作れるかな(^-^)#RaspberryPi #Pico pic.twitter.com/GgfhDG2Qng

— PocketGriffon (@GriffonPocket) 2022年3月18日

前回使っていた液晶(320x240ドット)と、今回の液晶(480x320ドット)で、実はピンの配置が全く同じだと気がついた。ということは、SDカードとタッチパネルのプログラムがそのまま使えるのでは？？？

そう思って移植したのだが、どうやらSPIの競合？が起こるらしくて、動作コアを別にした瞬間に問題出まくりとなった(T-T) うーん、回避するコードを入れてみるが、もう少し素直な(ちゃんとした)方法がある気がしてならない。

それでもSDとLCDで同時アクセスしないようにしたらすこぶる安定した！

そしてタッチパネルについてはキャリブレーションしないといけないのか、まーったく安定しない…。全体的に不安定になってしまうため、今回は使用を諦めた(T-T)

何かを動かしてみたいけれども…

一通りの機能を確認出来たので、せっかくだから何か作ってみたい！

いろいろと検討してみたけれど…画面サイズの480x320というのが意外に難しい！(@_@;

例えばPC-8801やPC-9801を動かしてみたいと思えば、横640ドットのサイズを480ドットに縮める必要がある。それって横4ドットを3ドッドに縮めないといけない。

さらに縦については5ドットを4ドットに縮めないといけない。

これは……どう考えても簡単じゃないのでは？？(T-T)

他にもPC-6001とかMSXとかレトロマシンを検討してみても、やっぱり画面サイズがしっくり来ない。大きな画面も良し悪しだと思い知らされた(ToT)

CP/M-80を動かしてみた！

もはやワンパターンすぎて飽きてきてる思うけれども…今回もCP/M80を動かしてみた！

せっかくの大きな液晶なので、PC-9801フォントを使ってお気に入り画面にしたい。

ただ…98のANKフォントは8x16ドットサイズと素直に表示すれば60x20キャラクタとなり、480x320ドット液晶とは相性がよろしくない。

まず画面に25行を表示させるためには、縦12ドットのフォントを用意する必要がある。キレイに表示させるために、小文字のgやyなどを少し修正した。これで縦方向はキレイに12ドットに収まった！

横方向については横6ドットの80桁表示と、8ドットの60桁表示をサポートした。

こんな感じでどうだろうか？(^-^)

CP/Mということで、キー入力は絶対にやってみたいと思い検討してたのだが…PicoのUSBホスト機能を使おうとすると、標準のUSB端子以外から電源を入れないといけないらしい。

……どうやって？(^-^;;;

GPIOのピンから電源入れるとかするらしいんだけど、よくわからん(T-T)

そんな事を検討している流れから、そういえばArduinoIDEのシリアルモニタから文字を入力出来る事を思い出した！

これでリアルタイムではないにしてもキーが入力出来れば…目的は果たせそうだ。

Serial.read()という関数を使えば文字取得が出来る。

これを利用してCP/Mへ文字を入れる事が出来るようになった！

ちなみにここに漢字を入力してみると、プログラム側にutf-8コードが渡る。

何かに楽しいことに使えないかなぁ…とワクワクしちゃう！(^-^)

おわりに

もはや……何度めのCP/M80移植？？(^-^;;

何度も移植はしているけれども、移植するたびに対象マシンの制限などを考えて実装していくのが楽しい。メモリ、画像、ストレージその他考えないといけないことはたくさんある(^^)

私的には大好きなスタートレックが動くマシンが増えていくのが楽しくて仕方ない(^-^)

RaspberryPi Picoと大型液晶で遊ぶCP/M80エミュレータ。

キー入力はシリアルモニタから打ち込んでます。BASICを起動したりゲームを動かしたり。途中でフォントサイズを切り替えてます。

安定して動くようになってきた！(^_^)#RaspberryPi pic.twitter.com/HS2hKrLRgs

— PocketGriffon (@GriffonPocket) 2022年3月19日

液晶は単純に大きければいいってワケじゃないんだな…と思いしった！

メモリ、速度、そもそものドット数とやはりバランスは大事だ。

また何か良さげな活用方法が見つかったら試したいと思う。

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

Waveshare RP2040-LCD-0.96で遊んでみた！

今回は、つい先日スイッチサイエンスから発売になったWaveshare RP2040-LCD-0.96を入手したので、これを使ってプログラミングしてみた！

www.waveshare.com

見た感じはRaspberryPi Picoに小型の液晶が載った感じで、メーカーとしては「Pico-like」ということでPicoっぽいモノ(つまり互換品)となっている。

チップにRP2040が使われている事から、使う側からしたらPicoそのものな感じで、違いを見つける方が大変かもしれない…？

LCDが載ってる分、少しだけ重要があるが、誤差の範囲だ(^^)

いや、そんな違いはどーでも良くて(^^;;

使い方はRaspberryPi Picoと全く同じで、bootボタンを押しながらUSBを挿せばホストマシンにドライブとして見えてプログラムを送り込める。

ちなみにUSBポートはTYPE-Cだ。

Waveshare機にはリセットボタンがついており、これがとても便利！

RESET押す→BOOTを押す→RESETを離す、とすればプログラムを送り込む状態になる。いちいちUSBを引っこ抜いたり、USBの電源を操作したりしなくても済むので、私は毎回活用している！(^-^)

LCDに表示させてみたいんだ！

さて、普通に使う分にはRaspberryPi Picoと同じだけど、せっかく液晶が取り付けられているのだから、これを積極的に使っていきたい！　

そうしないと単なるお荷物LCDだ(ToT)

この液晶パネル、Sitronnix社のST7735Sというらしい。

www.switch-science.com

↑リンクの資料にST7735SのPDFへのリンクが貼られていた。

これを参考にしながらLCD制御プログラムを書いていくんだが…パワーオンシーケンスがまとまって書かれてなくて、とても苦労する！(TOT)

しかも初期化の順番なども分からず、こりはどーしたら良いのか…またしても枕を涙で塗らすのか…orz

何時間か格闘したのちに「サンプルがあったらいいのになぁ…」とふと思う。

あれ…そういえばサンプルあるはずだよね…無いなんてことある？

そう思って探してみたところ………

あああああぁぁぁ…(断末魔

www.waveshare.com

↑上リンクのResourcesタブにDemo Codesというのがあった(T-T)

またしても気が付かなかったよ！！(ToT)

この中に含まれているLCD_0in96ほにゃららというファイルを見ていけば、LCDの制御方法が書かれている。ファイルはLCD以外のハードも扱おうとしているため少し大きいけれど、液晶部分だけを抜き出して自分用に書き直した。

そういえばArduino系のLCDはSPI0に繋がってる事が多い気がするけれど、RaspberryPi PicoではSPI1に接続されているケースが多いような気がする。SPIのポートなんて意識しないと気が付けないYo！(ToT)

元のサンプルがすでにハードウェアSPIを使うようになっていたが、もう少しだけ最適化して速度を出せるように改良。

イッパツでこの絵が出たときは本当に嬉しかった！(^-^)

速度的には160x80xRGB565=25KBを転送するのに3.8msと結構速い。理論的には秒間250回以上も書き換えが出来る！

スクロールさせてみる

無事に静止画は表示出来たので、次は大きなマップをスクロールさせてみる実験をしてみる。

実験の目的としては、常時フレームバッファを書き換えつつLCDへ転送を繰り返すのに、どのくらいの時間が掛かるのか…という、まぁ良くやる感じの事をしてみたいだけだ(^^;;

手元にXevi○usのマップデータがあったので、これを活用してみる。面倒だったので無圧縮で全データをFlashROMに入れておこうと思ったら、4MBもあって入らなかった…汗

仕方ないので、横160ドットの範囲のみ切り出してROMに載せる。

これだけでも640KBの容量があった！

Waveshare RP2040-LCD-0.96 で見慣れたマップをスクロールさせてみた！

これでウェイト無しのフルスピード。秒間100回以上描き替えできてるよ！

マップ表示の縦横を間違えた感があるけどまぁ良いか(^_^; pic.twitter.com/4aQ38dUfzj

— PocketGriffon (@GriffonPocket) 2022年3月17日

最適化も何もしていない状態だけど、かなり速く動く事が分かった。

フレームバッファ自体が小さい事(25KB)などもあるんだろうけど、毎回表示用のマップデータをFlashROMから引っ張ってきてるのに、この速度で動くんだ…と関心(^-^)

ポリゴンぐりぐり

前にSMART Response XEでポリゴンを動かそうと頑張った事があった。

pocketgriffon.hatenablog.com

このプログラムの元は、1992年に某アセンブラで書かれたもので、それを2003年頃にC言語で書き直していた。

これをSMART Response XEへ移植しようとしたのだが、CPUのアーキテクチャが違ってて簡単には移植できず諦めていた。

今回のPicoは32bit ARMだし、きっとうまくいくはず…と思い、頑張って移植してみた。

1992年当時のプログラミングレベルで書かれているので、とっても素直な3Dエンジンとなっている。久しぶりに見たらクォータニオンでなくて回転行列で書かれてた！(^^;; そんな時代か！！

PicoでOpenGLなどが使えたら超簡単なのに…と思いながらも頑張って移植ｗ

とっても基本に忠実に書かれていたプログラムなので、移植もその流れで直線描画→三角形描画→多角形描画→3D2D変換みたいな感じで進めていった。

上の写真はポリゴンを描画出来るようになった時に撮影したものだが、速度が速すぎてシャッター速度がついていけてない？？

こちらが3D→2D変換処理を入れる前の三角形描画処理。速すぎて何やってるのか分からないレベル(･_･;

RaspberryPi Pico、私の中ですごく速いイメージができつつある…(^^; pic.twitter.com/RaHagsWZhX

— PocketGriffon (@GriffonPocket) 2022年3月18日

クリッピングしつつ描画してこれだけの速度が出ると、いろいろと期待してしまう(^^;

Waveshare RP2040-LCD-0.96 でポリゴン描画してみた！
最適化してないけど結構速い(^^)

こういうちまちまとした実験が楽しいなぁ！＼(^o^)／ pic.twitter.com/1aHXHxEq5R

— PocketGriffon (@GriffonPocket) 2022年3月17日

最終的に出来上がったのがコレ。

めちゃ速い三角形描画処理からみたら、だいぶ遅くなってる…。3D演算を最適化していないので、多分処理が重いんだと思われる(T-T)

最適化してみようとソースを見たら、当時の苦労が忍ばれて涙が頬をつたっちゃいそうだったので、今回は辞めておいた(^^;;

夢が広がるけど…

そういえばDMAを使った最適化をまだやってなかったな…と思い、フレームバッファの消去をDMA化してみたところ、速度が2倍になった！

こんな感じに、Picoでの最適化はまだまだ道が残されていそう。

究極を言えばCPUコアが１つ空いたままになってる(^^;;

液晶がついたPicoということで、本来の用途はべつのところにあるんだろうけれども、これはこれで本当に面白いマシンだと思う(^^)

使ってみた感じ、Picoとの違いは分からなかった。世にたくさんあるPico用プログラムがそのまま動かせる魅力も大きい！

個人的な欲を言えば、LCDのドット数が160x100あればPC-8001が動かせたのになぁ…とは思う。もっともPicoのパワーだったらラクに実機同等の速度で動いちゃいそうだけど(^^)

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

RaspberryPi PicoでPC-1360エミュレータ！

今回はRaspberryPi Picoの小型液晶に挑戦してみた！(^-^)

ついでにPC-1360エミュレータも動かしてみたのでご紹介したい。

ちなみに今回もひどーく苦労した(T-T)

今回使ったのは、スイッチサイエンス社から販売されている小型の液晶。

一連のPicoで小型液晶を使うにハマっていた時に、一緒に購入していた。

www.switch-science.com

↑これ！(^-^)

裏にひっくり返せば、RaspberryPi Picoが張り付いている。

斜めから見ると下にPicoがついてるのが分かる(^^)

このボードのLCDにはAQM1248Aというものが使われているらしい。

ポピュラーな液晶なんだろか？？

久しぶりすぎて液晶の制御なんて覚えてないなー(T-T)

不安があるとすればソコだけかも…？

画面に何も出ない！

せっかく手に入れたからには使ってみないともったいない！

プログラムを組んでみようじゃないの(^^)

そう思って、開発資料が欲しくて↑スイッチサイエンスのページを見に行ったけれど…基板仕様、接続ポート一覧という情報のみがあるだけで、サンプルプログラムとか載ってない…。

世の中のプログラマさんは、これらの情報だけでプログラム出来るんだろうか…(-_-;

私も１年前だったら「面倒だからやーめた」になっていたかも知れない(^^;;

でも今だったらチャレンジしてみちゃうぜ！！！

…と思ってやりはじめたけど、まぁ当初の予想通りうまくいかない(T-T)

相変わらずGPIO、SPIなどの言葉が、概念的にもすっきり頭に入っていないので、何をどうしたら画面が表示されるのか突破口が見えない。

スイッチサイエンスのページからAQM1248Aの資料ページに飛べる。

https://akizukidenshi.com/download/ds/xiamen/AQM1248.pdf

これを見ながら、データの出力方法や初期化などを拾っていく。

そう、これを見ればコマンドやデータの送信方法や、LCD自体の初期化方法は書かれてる。問題はSPIの初期設定をどうすれば良いのかがさっぱり分からないのだ(T-T)

Arduinoの資料を見つつ、LCDの資料とにらめっこをしながらプログラムを組み立てていくが、全然うまくいかず改良してるのか改悪してるのかすらもわからない。

画面を見てもピカとも反応せず、挙句の果てにはこの液晶、壊れてるんじゃないかな…と疑い出す始末…(^^;;

結局、その晩は何も進展が無く、枕を涙で濡らしつつ寝る事に(T-T)

布団に入りながら考えてみたが、そういえばArduinoの資料を見ていたけれど、コントローラはRaspberryPi PicoなんだからRaspberryPiの資料を見ないといけないのでは…と気がついた(^^;

それが突破口となり、翌日には無事に画面に絵を表示させる事が出来た！！

ひー！苦労した！！！(T^T)

やっぱりGPIOとかSPIとか苦手かもなぁ…。苦手というか理解が及ばないというか。

数こなせばもう少し分かるようになるんですかね…？(-_-;;

分からない事を少しだけ書いてみると…

例えばSPIの初期化にはSPI.beginとspi_initがあり、どちらもエラー無く呼べてしまう。

同じようにdigitalWriteとgpio_putというのがあり、これらは何が違うのか…。

こういう似て異なりそうなものがさっぱり理解出来てない(T-T)

なかなかハードルは高そうだ！！

さて、出来上がったのはハードウェアSPIによるデータ転送プログラム。

全画面を書き換える時間は、約1msとかなりの高速。

データ量が768バイトしかないからそんなモンかも…？？

よっし、これで表示に関する不安は無くなった！ヽ(=´▽`=)ﾉ

PC-1360を載せてみる！

せっかくの横長のモノクロ液晶なんだから、ポケコンを動かしてみたいよね！

PC-1360のRAY FORCEが動いたら面白そうじゃん！と、ワリと気軽に検討を始める。

移植し終わってから気がついたが、Picoの小ささよ(^-^;;

ROM

まず最初に気になったのがROMサイズ。PC-1360はシステムが大きくなった分、ROMもでかいサイズを積んでる。16KB * 8バンクで128KBものサイズがある。

これをそのままPicoのRAMに載せる事も出来なくはなさそうだけど…ここはFlashメモリに置いたままにしてアクセスした方が良さそうだ！

Flashは2MBもあるので、今回はどう頑張っても埋められない(^-^)

RAM

RaspberryPi PicoのRAMは256KB以上あり、PC-1360の実装では余裕だった！

標準構成のPC-1360は8KBの拡張メモリが添付されているが、今回のエミュレータでは32KBの拡張メモリを(仮想的に)載せている。

それに加えて、$2000からの8KBにウソっ子メモリ(本来ならばPC-1360には存在しないRAM)も載せている。

これらを積んでもメモリ的にはかなり余裕のPico！

いいね！(^-^)

表示

PC-1360を動かしてみよう！……って考えてた時、なぜ横幅のドット数が足りないと気が付かなかったのか…(^^;;　なんか完全に思考の外にあって「大丈夫！」と思っちゃってたんですよね…汗

この液晶、横が128ドット縦が48ドットの構成となっている。PC-1360は150x32ドット。横方向に22ドットも足りなくなってしまった！

仕方ないので、画面の右側は映らない仕様としてしまった…。

こんな重要な部分、割り切って良いところなんだっけ？(T-T)

画面を目一杯使ったプログラムを動かすと、残念ながら右端は見る事が出来ない(T-T)

内部的には256x64ドットの表示バッファを確保してある。横方向を256にした意味は正直あんまりない！乗算が出来るCPUなので素直に150にしとけば良かったじゃん…と思う(^^;

LCDのドットフォーマットとPC-1360のソレが同じなため、複雑なドット変換せずそのまま素直に書き込めばドットが表示される。

キーボード

今回は完全にノーケアとした。
いつかUSBキーボードに繋げてみたい野望は持ち続ける！(^^)

PC-1360の実装！

過去にM5Stackへ移植したプログラムを、ほぼそのまま持ってきた！

M5Stackに比べてPicoはSDカードが無い、RAMが大きくないなど細かな違いはあったけれど、むしろプログラムは楽になる方向だった。

SDカードにアクセスしていたものは全てプログラムに内包し、ビルドする事でFlashメモリに配置されるようになった。楽ちんその１。

全てのメモリアクセスは１つの関数にまとまっていたので、FlashROMに置かれているPC-1360のROMをアクセスする部分も、この１箇所(しかも１行！)を書き換えるだけで対応出来てしまった！楽ちんその２(^^)

PicoはCPUのコアが２つあるので、CPUエミュレーションと画像表示を別コアに割り振った！

……んだけど……速度が速すぎて…なんだこれは？？？(@_@;;

CPUエミュレーションも画像表示コアも、大体90%が休むという異例の状態に……汗

あれ？Picoってこんな早かったっけ？？？

PC-1360が遅いのかな…そうかも？？

おわりに

結局、夜に液晶を取り出して一晩悩み、翌日の夕方にはPC-1360が動いてしまった！

この手のエミュレータは移植がとてもしやすい(^^)

まぁサウンドもキー入力も実装していない時点で、人に見せられるものでは本来ないのですが(^^;; 自己満足ということで許してほしい！

Picoに関して言えば、まだ他にも周辺ハードをいくつか手に入れてあって、この先も楽しめそうだ！

それぞれのハードにPicoがつくため、取り外しが面倒で１ハード１Picoにしてしまってる！このご時世で珍しくPicoは手に入りやすいので、ちょっと贅沢だけどこの先もそうするよ！

あと4Picoもすでに手元にある！(^-^)

やっぱPico楽しいなぁ！

プログラムしやすいハードだと思う！(^^)

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

Wio TerminalでCP/M80を動かしてみた！

Wio Terminalで遊んでみた第２弾！(^-^)

今回はCP/M80を動かしてみたよ！

先日、Wio Terminalで何かを作ろうと思いつつ情報を探していたら、USBキーボードが繋がるっぽい記述を見つけた。

Keyboard - Seeed Wiki

へ？？キーボードが繋がるの？？USBの？？

……どうやって？？(@_@;;

Wio Terminalはバッテリーを積んでいないので、USB TYPE-Cを引っこ抜いた瞬間に電源が落ちてしまう。電源を確保したままキーボードを繋げようとしたら、電源供給のついたUSBハブとか使うんだろうか…？？　…謎だ(-_-;;

そんな事を思ってスイッチサイエンスのページをみたら、バッテリーが発売されていた。そうか、そういう事なのか…と、ひとり納得(^^)

それで前回のブログでバッテリーが…みたいな事を書いていたのだ！

www.switch-science.com

急ぎバッテリーベースを入手したので、キーボードを使った何かを作ってみようと検討した結果、CP/M80を移植してみる事にした！(^^)

ええ、ワンパターンですよ、はい(T-T)

移植検討

移植に関してはM5Stackで動かしていたものをベースにしようかと考えていたが、メモリの都合で構造が大きく変わりそうだったので、オリジナルのMac版を移植する流れとした。

↑Macのオリジナル版はこんな感じ。今回の移植をやりやすくするために、cursesベースで動いていたものをSDL2で動くように改造した。

メモリ

CP/M80を移植する場合、メモリ的に大きいのはZ80のメインメモリ64KBくらいだ。エミュレーションでもたいしたメモリは使わないので、この点は問題なさそう(^-^)

ディスク

サイズの大きな仮想ディスクをどうするか。

オリジナルのMac版では、ディスク全体を大きなメモリにどーんとロードしていていたが、Wio Terminalのメモリ事情でそれは無理だ(T-T)

そこでWio Terminal版ではディスクのファイルはSDカードへ置いたままにしておき、メモリ中には１セクタ分(128バイト)のバッファを持つ事にした。

同じセクタをアクセスしている間はSDカードの読み込みは無く高速に処理される。

書き込みがあった場合にも、別のセクタをアクセスされた際にSDカードへ書き戻すようにした。

読み込み速度がだいぶ遅くなるのでは…と思ったが、エミュレータの速度も速くないので気になるレベルではなかった(^^)

表示

Mac版では内部に仮想スクリーンを保持していて、VT100サブセットの機能を自前で書いていた。これをそのまま移植する事で、内部的には80x24の画面を扱う事が出来る。

Wio Terminalは画面サイズが320x240ドットと、縦方向が30行確保できそうだったので、少し拡張をした。#define定義を変更するだけね(^^)

この仮想スクリーンはZ80のメモリ上に置かれていて、CP/M80からもバンク切り替えをしてアクセスする事が出来る。何か面白い使い道があれば…と思って実装してあるんだけど、今のところは宝の持ち腐れだ(^^;;

液晶への表示はLavyanGFXのスプライト機能を用いている。320x8ドットの大きさを持つスプライトに文字フォントを書き込んで表示。文字が書き換わったラインのみを描画対象にすれば、表示も最小限で済むはずだ(^^)

↑開発中はこんな感じに色つけたりして分かりやすくしてたｗ

実装していくよ！

まずはCP/M80本体を移植していく。今回のWio Terminalで動かすためだけにオリジナル版をSDL2対応したのだが、その時に移植しやすい構造にしておいた。

基本的には「あるものは消さず、呼び出さないだけ」という感じにしていく。どこからも呼ばれていない関数はリンクされないので、メモリ的な無駄になることはない(^^) 消しちゃった後に必要だって分かったら復活させる(コピーして持ってくる)の面倒だし(T-T)

Z80のエミュレータが動き出せば、CP/M80起動にともなって仮想スクリーンに文字情報が出力される。それをメモリダンプで目視したのち、表示系を実装していく。

……が、その前にそろそろ肝心のUSBキーボードを動作確認した方が良さそうだ！

USBキーボードの実装

この手のハードを何度となく扱ってみて理解したのは、対象となるハードのみを使ってる場合はちゃんと動いても、それとあわせて別のもの(例えばSDカードなど)を触ろうとすると、うまく動かない可能性があるって事だ(T-T)

今回の場合、SDカードがそれに該当するかも知れない。ハード屋さんから見たら「え？ぶつかってないから大丈夫だよ」で済む話なのかも知れないけど、その辺りの事情を理解できてない人から見たら疑うべきところが山程ある(^^;;

今回はハードの競合でハマるところは無かったのだが、以下ハマり道的なお話(^^;

サンプルにあったこの一連の初期化処理、一気にコピーしてもってくれば良かったものを、動作確認を１つずつ進めていた関係で、delayの上、delayの下とコピーしていた。

で、どうやらこのdelay(20)に大きな意味があるとも気が付かず、USBキーボードの初期化が進まなくてとてもハマった！(T-T)

きっと何かハードの準備を待つとか、USBキーボードからの返事を待つとか、そういう意味で重要なdelayだったんだろうけど、理屈とセットになってないので理解が及びにくい(T-T)

delay(20)を入れたところで、ようやく安定してUSBキーボードが動くようになった！

USBキーボードのテストには以下のような手順で行っている。

コツというよりは手順？が必要なんだと思われる。

↑バッテリーベースを取り付けたWio Terminalを用意。

この状態で、バッテリーベースの底面にあるスイッチを押して通電スタート。この底面にあるスイッチ、ものすごーく押しづらくないですか？？(T-T)

この(↑電源が入った)状態で、開発のホストマシン(私の場合はMac)に繋がっているUSB TYPE-Cケーブルを繋げつつ、本体左のスライドスイッチを２回下にスライド(ブートローダー)。

ホストマシンからプログラムを書き込むと自動的に実行が始まる。
↑の写真では、CP/M80が起動してるけれどキーボードの初期化で停止してる。

この状態でおもむろにホストマシンと繋がってるTYPE-Cを外し、キーボードを繋げる。

電源はバッテリーベースから供給されているので、電源はついたまま。

キーボードを繋げたら、本体左にあるスライドスイッチを下へ動かしてリセット。

これでキーボードが認識されて打ち込めるようになる。

開発中は毎回これをやるのが面倒なので、キーボード有り版とナシ版をビルドで切り替えている。キーボードなしの場合は、プログラムで生成した文字列を自動的に入力して動作確認を行うようにした(例えばmbasic asciiart[RET]と入力された風に振る舞うなど)。

USBハブを取り付けた状態でのテストもしてみたかったが、今回はチャンスもなく出来ていない。この先、取り組む機会があればぜひ試しておきたい！

表示系

今表示されているのはPC-8001のフォントを拝借した(ごめん)。

8x8ドットフォントなので、320x240ドット = 40x30キャラクタの表示が出来る。

だがCP/M80は横が80キャラクタあることが望ましいと思えるようなプログラムがたくさんある。特にゲーム系では画面が崩れる(T-T) 大好きなスタートレックをちゃんと表示させるためには、どうしても横80文字が必要だ！

というわけで、横を4ドットに縮める表示も行うようにしてみた。

このCP/M80は内部的に横80キャラクタの仮想スクリーンを持っているので、表示さえ工夫すれば実現出来る。

横４ドットフォントについては、元フォントを機械的に縮めてみた。横２ドットを１ドットに変換するのだが、カラーが使えるので両方ドットがあれば白、片方だけなら灰色、ドットがなければ黒という感じで変換した。

元からこういう文字が書かれている…と知っていれば、なんとなく読めるレベルかなｗｗ

本体上部にある３つのボタンでスクロールさせてみようかと思っていたけど、これだけ読めればいいやってなった(^^;;

DMで「フォントの切り替え速度はどんな感じですか？」と質問をいただいたので、動画を撮ってみた！

フォント描画の最適化を頑張ったので、それなりに速い…と思う(^^) pic.twitter.com/xQt5tbJHAx

— PocketGriffon (@GriffonPocket) 2022年3月15日

フォント描画は結構頑張ったので、切替速度は速いと思う！

気になってるところ

ここはもう自分の備忘録なんだけど…いくつか気になったことがありまして(-_-;

USBキーボードは英語配列が基本らしい。私は普段遣いが英語キーボードだが、外付けの英語配列キーボードを持ってなかった。

日本語配列に切り替えられるかな…と思ってあれこれ探してみたけれど、見つけられず。

今後のことも考えて手に入れておきたい。

無線で繋がるキーボードも試してみたい。Bluetoothじゃなくて(^^)

電流的？電気的？に繋がるのかわからないけれど、無線で繋がったら相当ラクな気がする(^^)

あと……ここんとこずーっと気になってる事が……

それは……Z80のエミュレーションコアが遅い！(T-T)

FM-7(6809)は２つのコアを動かしても実機よりも速く動くくらいなのに、Z80１コアで速度が出ないのはどー考えてもエミュレータの実装が良くない気がする…。

今使ってるZ80コアは私が1990年代前半に作ったもので、当時の環境にあわせられている。最新の環境でパフォーマンスが出る道理もないので、今にあわせて作り直そうかなぁ…。

うーん、今年のどっかで頑張る(^^;;

終わりに

CP/M80は何度と無く移植したり開発したりしているけど、環境が出来上がるたびに「コレは使えるかも！遊べるかも！」という感覚がある(^^)

自身が初めて触れたOSということもあるんだろうけれど、思い入れがある分、どんなマシンで動いても嬉しいものは嬉しいね！

なんとなくCP/MとFM-7とX68000は移植ベンチマーク的な役割になりつつあるけど！(-_-;

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

reTerminalを使ってみる！

またしても新しいマシンの登場！(^^;;

今回はseeed社のreTerminal！

これも昨年の12月に手に入れていたのだが、なかなか使うチャンスが巡ってこなかった。一応、昨年末に書いていたブログには「来年は使うよリスト」として入れていた(^^;

実は、結構なヨコシマな考えで手に入れたreTerminal。

世界的にRaspberryPiが不足している中、ちょいとCM4(Compute Module 4)を使ったコンピュータを使ってみたかった。しかし肝心のCM4が全く手に入らない…。

で………reTerminalの中身はCM4が入っている……(^^;;

多くは語らないが、今度どうするかわからないけど…ええ、はい(-_-;;

とりあえず今回は元気なreTerminalをご紹介！←言い方…

大きな画面が魅力的！

reTerminalを選んだ理由は他にもある！あるったらある！！(^^)

画面の解像度が1280x720と結構大きいのだ！

以前、DevTermやポメラでX68000やPC-9801を動かした時の、ドットバイドットで表示される画面が美しくて！その時の衝撃が大きかったので、最近は画面解像度を意識してマシン選定をしている。

写真がボケてるうえに縦方向が512→720に拡大されているので、ドットバイドットではないけれども、文字が崩れずにキレイに表示されるのが嬉しいのだ！(^-^)

開封してからの写真を並べようと思っていたのだけど……

↑なんと次に撮った写真がコレ！

開封したのは昨年の12月15日らしいのだが(写真の日付から分かる)、そこからずっと開けっ放しの置きっぱなしだった…汗　ごめん(T-T)

ここんところRaspberryPiばかり使っていたので、設定で困るところがなかったｗ

いったん、RetroArchとX68000コアを動かしてみたところまで進めた上で、せっかくなので気になっている事をあえてやってみることにした。

アップデートすると画面が表示されなくなるらしい

これはreTerminalで検索していて見つけたモノで、どうやらアップデート(おそらくapt upgrade)すると画面が見えなくなってしまうという症状があるらしい。

この症状は……Raspberry Pi 400の外部モニタでさんざんやった！(^^)

標準のHDMI出力に切り替わっちゃうので、そうでないモニタはたとえ繋がっていたとしても映らなくなるヤツですね！

しかし！！

reTerminalのCompute Module 4を入れ替える - Seeed K.K. エンジニアブログ

↑リンクにある「ドライバーをインストールする」で回避方法まで書いてくれている。

そうとなれば！！！

やってみたくなるじゃないのさ(^-^)

　sudo apt update

　sudo pat upgrade

　sudo reboot

はい、表示されなくなったー！(^^;;;

ずっと有線LANで作業していた＆ルーターを管理するアプリを参照すればDHCPから割り振られたIPアドレスも簡単に分かる。

sshでさえ繋がっていれば怖いものはないぜー(^^)

ちなみに上記リンクでは「ドライバーを更新したらreboot」となっていたが、ウチではrebootでは映らず、一度shutdownした後に起動させたら表示された。

よし、これで一通りのトラブルシューティングは楽しめたｗｗ

インストールされてるのが32bit版Linux

reTerminalに元からインストールされているのは、32bit版のLinuxとなっている。本体に積まれているCPUモジュールがRaspberryPi CM4、つまりパズパイ４なので、本来であれば64bit版を動かす事が出来るはずだ。

特に不具合や問題がなければ32bit版のままでも構わないと思うけれど、せっかく４を使ってるのならば64bit版を使いたい。

というわけで、本体にインストールされているOSをアップデートしてみる事にした。

reTerminalは本体内部にSDカードが入っているわけではなくて、CM4の基板上にあるeMMCにインストールされているみたい。そこのファイルを書きかえてやれば良い…らしい(^^;

手順としては以下な感じ。

　reTerminalの裏フタを開けてeMMCへの書き込みスイッチをONにする

　ホスト側(私の場合はMac)に、reTerminal用のツールをインストール

　reTerminalを繋げてOSの書き込み

　reTerminalを再起動

　モニタを表示出来るようにする

フタを開けるのがちょっと面倒だったけど、あとは慣れてる作業だったので簡単！

初めてやる人には少しむずかしいかもしれないので、いくつかのサイトを良く読んだ上でチャレンジしてみてほしい。

↑赤で囲んだ部分についているゴムを外す。なくさないように…。

↑４つのゴムを外した部分に＋ネジがあるので、精密ドライバーで外す。

ここがちょっとだけ難関。

ネジを外すと、あとはカバー裏にある爪が掛かっている状態なので、慎重に外していく。

ヒートシンクの裏が固くなっているので、↑写真のようなこじ開けツールをつかって、ヒートシンクの横に刃先を入れ、刃先を入れたまま赤矢印のような感じで動かすと簡単に外れる。

反対側にも爪があるので、同じ要領で外してやる。

↑カバーを外すとヒートシンクが露出する。ネジ２本で止まってるので外す。

これでCM4基板が見える状態になった。

CM4基板の左側にスライドスイッチがある。これを下に移動させるとeMMCが書き換えられるようになるらしい(boot modeスイッチというらしいので、本来の意味はちょっと違いそう)。

この状態でTYPE-Cケーブルを用いてMacとreTerminalを繋げ、reTerminalの電源をON。

reTerminalは起動しない状態だけどそれでOK。

次にMac上で↓のリンクにある「FOR MAC/LINUX」と書かれている事を行う。

Getting Started with reTerminal - Seeed Wiki

私はここで少しハマってしまった！

このコマンド、reTerminal上で行うんだとばかり思い込んで、起動しない状態のreTerminalを見てはてさてどうしたもんか…と困ってしまった(^^;;

この作業をすると、MacからreTerminalがUSBドライブのように見えるようになる！あくまでもreTerminalは受け側であり、攻めるのはMacだった！！(TT)

普段からMacのコマンドラインでgccなどのコンパイラを利用している方であれば、何も困らずmakeが通ると思うが、そうでない人はXCodeのインストールなどとても大変な作業になるかもしれない。面倒がやな場合は、素直にWindowsマシンを使うのが良い。

Mac上でrpibootを実行すると、少し待つとreTerminalのeMMCがMacにマウントされる。こうなればあとは普通にRaspberryPiのイメージを書き込む手順で、最新OSを書き込んでやれば良い。書き込み速度はだいーぶ遅く感じる。

書き込む際、↑のリンクにあるCTRL + SHIFT + Xを押して詳細設定をするのを忘れないように。特にsshが無い状態で起動してしまったら、画面が見えないので手に負えない(T-T)

Operating system images – Raspberry Pi

↑私はRaspberry Pi OS (64-bit)のRaspberry Pi OS with desktopを書き込んだ。

eMMCへイメージを書き込んだ後、reTerminalの電源を落とす。

裏面にあるスライドスイッチを元の状態に戻し、本体を組み立てる。ちゃんと起動するのを確認出来るまでは仮組みで動かした方が良いと思う(^^;

仮組み終了後、reTerminalの電源をON。

画面は見えてない状態だけど５分くらい待っていればsshで反応が返ってくるはずだ。

ログインが出来たら、あとは上の方で頑張っていた画面が見えない場合のトラブルシューティングと同様の作業をすれば良い(^^)

画面が表示されると、ちょっとだけ新鮮な状態になる！

これを見て分かるのは、本来のLCDは縦使用なんでしょうね…。フレームバッファへデータを直描きすると、縦長方向にアクセスされる仕様なんだろうなと思う(^^;

reTerminalのディスプレイ向きを直す - Seeed K.K. エンジニアブログ

↑ここに書かれている方法で画面の向きを90度回転させる。GUIでのやり方が書かれていたので、私はそちらで回転させてみた。

タッチパネルは手動で回転させた(^-^)

横長画面のデバイスが手に入ったら…当然やるよね！ドラゴンスピリットの縦表示を！！(￣∇￣)

これは…たまらん！！(〃ω〃)#reTerminal #X68000 pic.twitter.com/HU4WVQ5Wj3

— PocketGriffon (@GriffonPocket) 2022年3月12日

ついでだったので縦画面を堪能したりもした！(^-^)

これで無事に64bit版OSが入った！(^o^)

終わりなのか始まりなのか…

ここまででreTerminalの設定が出来て使えるようになった！

すでに開発環境などは入っているので、何かを持ってくるのは簡単だろう。

こうなると…素のLinuxマシンはやることがなくなってしまう(^^;;

せっかく広い解像度の液晶マシンを使えているので、もう少しだけ何かやってみるよ！

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

Wio TerminalでFM-7エミュレータを動かしてみた！

今回のお題はWio Terminal。

何年前のハードなんだよ！とか突っ込んでくださるな(T-T)

知り合いにオススメされるカタチで、2020年のクリスマスにネットで購入していた。

それから１年半くらいの間、一度も開けること無く保管していた事になる(^^;;

Wio Terminalを手に入れた当初は、この手のものは(自分の中では)用途不明で、開発環境揃えるだけでも面倒じゃん…くらいの感覚でしかなかった。

でも箱を見る限り、本体の半分はLCDみたいだし、pythonのプロンプトっぽいモノも出ているので、もしかしたらLinuxが動いてコマンドラインで何か出来るのかも…くらいのイメージだった(^^;;

その後、M5Stackにドハマリをし、M5Stick、RaspberryPi Picoなどを経由していくうちに、そういえばWio Terminalを手に入れたままだった…と思い出した。

そこでようやくスペックを確認する私ｗ

ARM CPU 120MHz、320x240ドットカラー液晶、RAM192KB…。

あれ？？思っていたよりもコッチ側なスペックじゃないの(^^)

というか、むしろ箱に印刷されてるような(Linuxっぽい)使い方は出来るんかな？？？

今さらWio Terminalの開封儀式を見ても仕方ないと思うのでサラっとｗ
マジメに開けてなかったので、今回はじめて本体を見る事に。あれ…てっきり箱にあるように、本体の半分が画面だと思っていたら、全体が画面だったのね(^^;;

M5Stackと比べてみるとこんな感じ。

画面サイズ的にはWio Terminalの方が少し横長に見える(同じ？？)

ちょっと横長ってことは、レトロパソコンの画面が映えそうな気がするじゃないのさ(^^)

というわけで、何かエミュレータを動かしてみようって気になった！

検討

とりあえず何を動かすにしてもメドを立てておかないといけないワケで(^^)

スペック的にRaspberryPi Picoと似てそうな感じするので、そこから比較検討開始。

自分的には「こんなの余裕で動いちゃって当然！」なスペックよりは「どうにか工夫してメモリに収めて速度を出す」くらいの余裕の無さが好き！そういった意味でWio Terminalは手頃なスペックをお持ちな気がする！(^^;;

Wio Terminalのスペックは上にちょろっと書いたけれど、CPUパワーが120MHzとそこまで高くない。クロック数的にはPico(133MHz)と同等だけど、Wioはシングルコアだ。半分とまではいかないにしても4割減くらい？

あ、でもスペック見ると200MHzまでクロックアップ？可能となっている。ということは、やっぱりPico同等くらいでは動く可能性があるって事か…。

それからメモリ(RAM)は192KB。これはPicoの264KBに比べても少ない。

最近お気に入りで良く動かしてたX68000エミュレータは、もはや検討するまでもなく無理な気がする。一瞬、X68000のメインメモリやVRAMをSDカードに置いておいてRAMのように使えば…とか思ったけど、全く現実的じゃないので却下(^^;;

おそらくPC-8001エミュレータだと余裕、PC-8801のようにメモリがたくさん載ってると厳しめ、ということは、なんとなく中間をとってFM-7かな…と(^^;;

メインCPU(64KB RAM + 32KB ROM)、サブCPU(48KB RAM + 8KB ROM)だったら動かせそうかな…。正確に数えるとアレだけど、大雑把に96KB + 64KBで160KBのメモリ。なんとなく行けそうな気もする！(^^)

移植作業

Wio Terminalの開発環境はArduinoIDEが使える。

そしてLovyanGFXも使えそう、SDカードライブラリなども揃ってる…という事で、感覚的にはM5Stackと良く似てる。というかそっくり？？

そんな考えから、今回は相当なレベルで舐めた態度で移植を始めた！←言い方…

おそらく構成的にM5Stackで作ったものを移植するのが簡単そうだ！

そう思ってあれこれファイルをコピーしてみるが…うん、全然うまく行かなかった！(^^;

１つずつデバイスの動作確認を取りながら進めた方が良さそうだｗ

シリアルへの出力、画面への出力、SDカードへのアクセスその他諸々…をとりあえず動作確認しながらWio Terminalの操作方法を覚えていく。

何度か書き込み→実行を試していると、書き込みが出来なくなってしまう現象が頻繁に出て困り果てた(T-T)　そういえば過去にM5Stackでも似た現象出たなぁ…。

Wio Terminalをはじめよう - Seeedウィキ（日本語版）

↑ここに書かれていた「ブートローダーを投入するには」を試してみたところ、安定して読み込めるようになった。ロードが不安定だとストレス溜まって仕方ないので、こういう方法がちゃんと用意されてるのはとても助かる(^^)

困った現象発生！

基本的な動作確認を終えたので、再度FM-7のプログラムを移植していく。

基本はinoファイルを触るのみで、他のソースは無変更で行けるはずだ…はずだ…(-_-;;

無事にメインメモリ、サブメモリの確保もでき、よしよしコレであとはエミュレータを動かすのみ…となった頃、不可解な現象が起こり始めた(T-T)

触った覚えのないソース部分で停止が起きるようになってしまった。

これは…なんだ？(@_@;

こういう時は下手にあれこれ触らない方が良い。ちゃんと原因を見極めてから対処をした方が良い……と思いつつも、効率の良いデバッグ方法が思い浮かばない(^^;;

しかもデバッグ用のコードを追加すると停止する場所が変わるのだ！

これは……とっても経験がある！！(T-T)

スタック破壊が起きると出る現象とそっくりだ！

デバッガで見ているわけではないので確定は難しいが、おそらくスタック領域は192KBのRAMの後方から取られているはず…。そしてFM-7のプログラムでは96KB+64KB、そしてカセットテープから読み込む時のバッファなどでメモリを消費しているが、192KBよりはだいぶ少ないはずだ…でもスタック破壊が起きてる可能性がある…。

これは…決定的な証拠を掴まない限りコードは替えられない！大体こういう時に適当に目星をつけて後回しにすると、最後にひどい目にあう(^^;;

ArduinoIDEはビルドが終わるとmapファイルを出力してくれる。mapファイルとは「どのアドレスにどんなデータを起きました」という、メモリ配置図みたいなモンだ(説明ざっくりしすぎ)。

このファイルを確認すれば、固定RAMの使われ方が分かる。テキストの見方にはちょっとだけコツがいるが、慣れてしまえばなんてことはない。.bssの項目が固定ワークの情報だ。

ここにallocしているサイズを足し算すれば…メモリ消費量が分かるって寸法だ(^-^)

さっそくmapファイルを見てみたところ、システムや細々としたワークが確保されて、約20KBのRAMが使われている事が判明。想定していたよりも大きい。

これにエミュレータ側でallocするサイズを加算してみる。

　20KB + 96KB + 64KB = 180KB

おわ……結構キてる！！(^-^;

FM-7エミュレータでは再帰呼び出ししている箇所はないが、各関数でのauto変数、コンパイラが最適化の段階で作り出すスタック上のワークなどを考えると、ギリギリか足りないか…。

ちなみにプログラムコードはフラッシュメモリ上に置かれるらしいので、コードサイズが増える分には大丈夫だ。

こういう場合、小さなワークをちまちまと削っても不安が残る。

…というわけで、書き換え不能なROMデータについてはRAMに置く必要性がないので、フラッシュメモリに置いたまま参照するようにした。

実はROMの一部を動的に変更していたため(カセットテープからの読み込み処理など)、RAMに置かざるを得ない状況だったが、仕方ないでオリジナルデータを変更する。

これで32KB以上のサイズが空くことになった！

動かしてみた感想

FM-7実機と同じか少し速く動いてるみたい！仕組み上、パレット切り替えが入ると画面全体を書き換えなくてはならないため、デモは結構キツい部類に入るかも。

スクロールゲームなどは実機より速く動いてる！(^^)

何周遅れかのWio Terminalだけど楽しいよ！(^^)/ pic.twitter.com/t4EIKH7tGS

— PocketGriffon (@GriffonPocket) 2022年3月11日

シングルコアの120MHzでどこまで動くんだろう…と思いながら移植作業をしていたけれど、結果的には120MHzのままでも十分な速度が出てしまった！(^^)

ワークメモリのサイズは意識する必要があるけれど、フラッシュメモリに乗ったまま実行されるプログラムの方は全くの無意識。デフォルトで-Os(サイズ重視)の最適化が指定されるけれど、-O3(目一杯最適化)にしてもサイズ的な問題なし。速度もだいぶ速くなった(^o^)/

表示はLovyanGFXに一任しているけど、VRAMの書き換えがあったラインのみ更新するなど80年代に大活躍した処理はもれなく入れている(^^) パレット変更があると全画面書き換えだけど(T-T)

Wio Terminal自体はとても素直な作りとなっていて、プログラムする上で悩む事がほぼない。メモリサイズさえ気をつけていれば、CPUパワーやフラッシュメモリサイズは余裕がある印象(^^)

ただ１つだけ気になったのが、バッテリー駆動が出来ない事。写真を撮ろうとUSBケーブルを抜いたら電源が落ちちゃった！そうか、バッテリーないのか…とその時気がついた(^^;

オプションで販売されているようなので、１つ手に入れて置くのもありかなー。

www.switch-science.com

もうひとつだけ移植してみたいものがあるので、その２に続くよ！

時期はわかんないけど(^^;

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

祝！100,000PV達成！

今回はレトロネタというよりは、ブログネタ？(^^;;

そして↑の写真は、お気に入りのパソコンを写メしただけｗ

今日でこのブログの回覧数が10万アクセス超えました！

いやはやびっくりです！！

これも見に来てくださってる皆さんのおかげです！

こんな拙い文章を見てくれて本当にありがとうございます！(^^)

ブログを書き始めたのが2020年5月7日なので、ちょうど1年と10ヶ月での達成！

22ヶ月間で277投稿してた！月に平均12.6回更新！(^^;

レトロパソコンのブログとしてアクセス数10万が多いのか少ないのかわからないけれど、私の中では大きな区切りとなりました(^-^)

,

ブログを書いてない人は見ることのないデータだと思うけど、こんな感じでアクセス数を知る事が出来るのだ！

普段からアクセス数ってほとんど意識したことがなくて…(^^;

自分の備忘録代わりに書いてるので、アクセス数を稼ぐつもりがそもそも無い。

自由気ままに書いてるブログだけど、読んでくれてる人がいて本当に嬉しいです！

-----

せっかくなので、過去ブログで人気のありそうな記事をご紹介！

ちゃんとしたデータを取ってないので、アクセス解析ページからの予測だけど…ｗ

一番人気がありそうなのはこちら！↓

pocketgriffon.hatenablog.com

内容は、PC-G850Vの液晶ライン抜けを修理したものだ。タイトルに「液晶修理」ってなってるけど、ライン抜けの方が良かったのかも…と今でも思うｗ

Googleからの検索が多いようなので、おそらく世の中で液晶のライン抜けを調べてる方が見てくれてるんだろう。参考になってると良いのだけれども…(^^;;

pocketgriffon.hatenablog.com

お次はこちら↑

確か２日間くらい集中して作ったエミュレータだった気がするけど、最後のオチまでキレイについてしまったいわくつき(^^;; エミュレータの作り方だと思って見に来たら、単なるドキュメンタリーだったと、読む人をがっかりさせていないか心配ｗ

pocketgriffon.hatenablog.com

↑あとこの記事も結構読まれているっぽいです。まだPC-8201の流通量が多いからなのか、修理に関する情報がアクセスされやすい気がする！

そういえばこのためだけにROMライタを手に入れたけど、あれから使うチャンスがなくてそのままだな…またやってみようかな！(^^)

Googleアナリティクスと連動させておくと、どのページがどのくらいアクセス出来たのかを知る事が出来るらしいので、この先は意識して見ていこうかなーと思う！

でもまぁアクセス数よりも、何を書きたいか…かな(^-^)

M5Stack関連を触りだして以来、読者層が変わってきている風にも感じるけれど、この先もレトロ中心にあれこれ書いていきますので、ぜひ今後ともよろしくお願いします！

この機種触ってみて！的なリクエストもあったらぜひ(^-^)

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

↑実は書き始めた頃からずーっと変わってない最後の挨拶でした♪