ポメラで動かしてるPC-8801について

前回のX68000に引き続き、PC-8801エミュレータを動かしてみた!

前回のブログと同じようなタイトルにして、ブログを活性化させようって魂胆がミエミエだ!(^^)

 

XM8

動かしているエミュレータはPI氏作のXM8だ。

XM8

ありがたい事にソース含めて公開してくださっている。

 

SDL対応が中心となっているおかげで、WindowsでもAndroidでもSDLを入れたら動くっぽい。

もしかしてMacでもSDL入れたら動くかも??(試してないけど)。

 

Source/README-BUILD.txtに基づき、Linux on DM250でビルドをする。

コンパイラのバージョン違いで、許されない表記箇所がいくつかあるので、そこは修正が必要。unsignedの配列に負の数が入ってるとか、些細な表記だ。

さくっと直してしまおう(^^)

 

動かしてみた感じ

↓動いてる状態はこんな感じ。

 

実は、前に一度実験してて、XM8がうまく動かないという報告をしていた。

この時には「おそらく表示系が遅いんだろう」と勝手な想像して、特に原因究明もしないままで終わっていた。

 

その後に拙作FM-7エミュレータを動かしてみた。

表示が遅いとは言ってもそれなりに動いてるところを見て「アレ?」と思ったが、先にX68000を動かしてみたい希望があったので、PC-8801は後回しにしてた!(^^;;

 

調査とか実験とか

ポメラX68000を動かす事に満足したので、ようやくXM8の作業に着手。

もうこの時は遅い原因が表示系なんだろうと信じて疑わなかったので、ロクな調査もせずに表示系の高速化を始めた(-_-; ← フラグ

 

X68000の時に少し残念だったのが、プログラムをSDL管理下から外してしまったため、入力系をすべて自前で作らないといけなくなった事だ。

やってみて思ったが、これは思いのほか面倒ナリ!(TT)

 

XM8では、できれば入力系はSDLを利用しつつ、表示系だけフレームバッファ直描きが出来ないか…と考えた。

ここでひとつ、自分の勘違いに気がつく。

 

X-Windowから/dev/fb0はアクセス出来ないと思っていたが、そういえばポメラのX serverはフレームバッファの活用が出来ていない状態なので、今であれば/dev/fb0にアクセス出来る事に気がついた!

 

さっそく表示のみをフレームバッファに横取りする実験を始める。

↑これがフレームバッファに直描きしたPC-8801の画像。

速度はSDLを利用した場合よりも10倍以上になっている!

 

だけど……表示をフレームバッファに切り替えても、音が途切れる事に気がつく。

あれれ……表示系を直しただけではダメなのか??

 

ようやく詳しい原因調査

ここにきてようやく詳しい原因を調査し始めた(^^;;

本来ならば一番先にやるべき作業…ごめんよ…orz

 

フレームバッファ対応する際にソースをある程度読み込んでいたので、Source/UI/video.{cpp,h}に表示系のプログラムがある事は分かっていた。

 

次に調べるはメインループだ。

これはSource/UI/app.cppにあるApp::Runにあった。

この作者さま、かなりソース書き慣れていますね…(@_@)

お手本のような読みやすいソースだったので解析もやりやすい。

さすが!(^^)

 

動作速度を4MHz(または8MHz)に保つようなコードがいくつか目に入る。

それらを見ていくが特に変なところは見当たらない。

仕方ないので古典的ではあるけれど、プログラムにprintfを挟み込んでいく。

SDLにはSDL_GetTicks()という便利な関数があり、起動してからの時間(ms単位)を知ることが出来る。これの値を見ながら、どこで時間がかかっていくのかを調べていくのだ。

 

そしたら…想像の斜め上の部分に遅くなる箇所を発見!

PowerMng()という関数を呼び出すと、10回に1度くらい300msほど時間が掛かる事が分かった!

これはバッテリーの残り容量を管理しつつ、残りが少なくなったら警告を出すものらしい。

しかし…ポメラは電源を接続している状態であり、プログラム実行時はフルパワーのハズなのだが……。

もしかしたら一瞬でも動作クロックが下がったらバッテリー駆動と解釈してるとか??

 

詳しい理由は分からないけれど、原因となる現象は特定出来た。

しかもソースを読む限り、これはオプションで切り替えられそうだ!(^^)

System Options → Watch Battery LevelをOFFにしてみる。

おおおおおお!

音が途切れなくなった!!!(^^)

 

これならば無理にフレームバッファ対応にしなくてもいいか…。

せっかく書いたけどコードを削除(無効)にした。

うん、これで十分速度間に合ってるよ!!(^o^)

 

動かしてみた感じ

手持ちのいくつかのソフトを動かしてみたが、ちゃんと動いているようだ!

FM音源でしゃべる宇宙の帝王もちゃんと動いた!(^^)

ジョイパッドでPC-8801のゲームを遊ぶということを初めてやってみたが、違和感バリバリで新鮮味があって面白いw

たまにFM音源にノイズが入る(処理が間に合ってない)感じがするけれど、パラメータの調整とかしたら直りそうな感じもするし、そもそも気にしなければ良い(をぃ

 

来たるべき秋に向けて、こりゃまた夜が長くなっちゃいそうだ!(^-^)

 

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

ポメラで動かしてるX68000について

2022.09.06: 一部追記しました!

2022.09.07: ソース、バイナリの公開について、を追記しました!

 

 

最近、ポメラDM250で動かしているX68000の画像や動画をtwitterに載せまくっている。

そのおかげか、ダイレクトメッセージをたくさん頂いてます!(^^)

 

中でも一番多かったのは「自分で作ったの?バイナリは?ソースは?」って話。

詳細な情報を出しているつもりでいたけれども、Twitterに書いていたりブログに複数回に分けて書いていたりと、情報が分散してて分かりにくかったかも。

一旦情報をまとめようと思って、このブログ書いてる!(^^;;

過去に書いたこと+αの情報しかないのでご了承くださいませ…汗

 

先に要点をまとめると…

Debian Linuxをインストール ← 2022.09.06追記

・ソースは公開されているpx68k-libretroを利用

・これをフレームバッファ直描き版に改造

サウンドはPulseAudioで出力

・マウスとジョイパッド対応

・内部の処理を一部スレッド化

・キーボード対応 ← 2022.09.06追記

という感じ!

以下、もう少し詳しく。

 

Debian Linux 2022.09.06追記

そもそもポメラDM250単体にはこのようなプログラムを実行する機能がない。

これは@ichinomoto氏が公開してくれているDebian on Pomera DM250を使ってる。

こちらも↓合わせて読んでみると良いかも!

「コレはなんですか??」となった方は、やらない方が良いです(^^;;

最悪は大切なポメラが文鎮化する恐れがあるので、ちゃんと理解した上で大人の遊びをするべき(^^)

トラブルシューティングも含めて楽しめる方限定の遊び方だと思う。

 

ソースはpx68k-libretroを利用

まず超大前提だけれども、このX68000エミュレータは私作ではないです!

X68000エミュレータはとても開発が難しく、私が数日頑張ってなんとかなるモノでもない(^^;;

RetroArchで動くX68000エミュレータのソース(px68k-libretro)を利用させてもらってます。

px68k-libretro

 RetroArchの説明までは出来ないので各自調べてもらえたら…と思うけれど、一言でいうならば総合エミュレータ環境…だろうか…。

 

RetroArchは(Linux版の場合は)X-Window上で動く事が前提となっている。X-Windowの2D描画速度がダイレクトに反映される構造だ。

Brain(SHARP電子辞書)でコレを動かそうとした時は、メモリ不足が懸念された。

そしてポメラDM250の場合は描画速度が問題となった。

このソースを利用して、各種目的を達成するための改造を行っている。

 

フレームバッファ版に改造

RetroArch対応px68k-libretroのソースをオリジナルとして、/dev/fb0へ画像データを出力するように改造した。

目的は2つ。

 

ひとつは省メモリ化。

電子辞書Brainはメインメモリが128MBしかないため、px68kを動かすためにはどうしても省メモリ化が必要だった!Brainにとっては比較的大きなシステムであるX-Windowをパス出来る事は大きなメリットに繋がった!(^^)

 

ふたつめは描画の高速化だけど、これは機種による!

ポメラDM250では顕著に効果が出た。

高速化される代わりにX-Windowが持つさまざまな描画サービスが使えなくなるし、RetroArchのフィルターなども使えない。正直、究極の選択?とも感じてる(^^;;

 

具体的な方法は、/dev/fb0をmmapすることでフレームバッファをメモリアクセスしてる。

px68k-libretroが用意する画像データが16bit bpp(1ドット2バイト)なので、これをDM250の32bit bpp(1ドット4バイト)に合わせて拡張しつつコピーしている。

 

X68000は画面のモードによって解像度が変わる。

ゲームは256x256ドットモードが使われる事が多いようで、これをそのままポメラDM250上に表示すると、とても小さな画面になっちゃうw

さすがにこれでは寂しかったので、画面サイズを縦横2倍にしてもスクリーンに収まる場合には、無条件に2倍して表示するようにしてみた。

だいぶ印象が変わる上に、これならばゲームで遊べそうだw

画面最大までマッチさせてみるとか、ドットがキレイに見えるようにアンチエイリアスを入れるとか、そういう面倒な処理は一切入れていない。あくまでも整数値だ!(^^;;

 

サウンド対応

今まで、エミュレータを作りつつもサウンドについてまともに対応した事がなかった。

これはサウンドが分からないとか苦手とかそういうのではなく仕事以外でサウンドドライバ作る気がしない!というだけの話(^^;;

大丈夫、音が鳴る仕組みはちゃんと理解しているw

 

今回はpx68k-libretroの力を借りられる事もあるので、ちゃちゃっと対応してみた。

Linuxで音を鳴らす方法はいくつかあるけれど、今回はpx68k-libretro側で作られたPCMデータをそのまま出力する方法を取った。

X68000ADPCMを鳴らす仕組みになっているので、送られてくるデータもADPCMなのかなぁ…PCMに変換せねば…とか思っていたが、すでに変換されていた(^^)

framesに4を掛けているのは、pa_simple_writeがサンプリングフレーム数ではなく、バイト数を要求する仕様のためだ(16bitPCM * 左右2チャンネル分)。

 

スピーカーはダイソーにあった300円のものを利用している。

最近はbluetooth対応のものが増えているが、ポメラに関しては有線の方がよさそうだ(^^)

 

ついでにUSB周りもご紹介しとく!

OTG対応のUSBハブにくっつく周辺機器!

左からゲームパッドサウンドアダプタ、マウス。

今どきすべてが有線で繋がってるってのも面白い(^^)

白い端子の先にポメラDM250が繋がるんだから、どう頑張っても机の上は片付かない。

 

マウスとジョイパッド対応

本当はキレイな実装方法があるんだろうけれども、特にソースを公開する予定もないので、やっつけ仕事でえいやっと対応してしまった(^^;

 

マウスは/dev/input/mouse0からデータを取得している。データの取り出し方を丁寧にやっていないせいか、X68000のマウスが不自然に動く(-_-;;

ちゃんと調整をしたら直るんだと思うけれど、動けば良いの精神で微調整なし(^^;;

 

ジョイパッドは/dev/input/js0からのデータをpx68k-libretro側に渡している。

こちらはある程度px68k-libretroの構造を利用した形で実装をした。そのおかげ?か、特に遜色なくX68000のゲームでも遊べるくらいの状態となった。

 

なお、ジョイパッドにしてもマウスにしてもUSB-Cのハブに繋げて使っているが、このハブがたまに認識されなくなる時がある。少し不安定であるが、コレは慣れていくしかないかなーと思うので、過去に1度でもちゃんと認識された周辺機器が繋がらなくなった場合は、根気よくDM250を再起動して試してみると良い。

 

当初、ジョイパッドを繋げても/dev/inputにjs0が出てこなかったが、@ichinomoto氏のご厚意により対応されたカーネルを提供していただいた!

こんな誰得?とも思えるような実験を見つけ、さらにご対応くださる優しさには、本当に頭が上がらない!ありがとうございました!!

 

内部の処理を一部スレッド化

以上の対応をした上でゲームを動かしてみると、サウンドが途切れる事が多々あった。

CPUの占有率を見てみると、px68k-libretroが動いているプロセスは120%程度の使用率…。うん、ふつーに処理落ち(T-T)

とは言っても、巨大なシングルタスクとして動いているpx68k-libretroの速度を上げるのは簡単じゃない。

 

M5StackやRaspberryPi Picoでプログラミングをしている時は、画像表示系を別スレッド化して全体のパフォーマンスを上げていた。

しかしラスタースクロールを頻繁に使うX68000のようなハードの場合、CPUコアの実行と画面データ生成が密接に絡み合う事が多く、これらを分離するのは簡単じゃない(T-T)

 

今回は妥協と諦めを1つずつ。

妥協案として、/dev/fb0へ書き出す処理を別スレッドにしてみた。

この処理自体はそこまで重くないのだけど、他にスレッド化できそうな部分がないw

サウンドはどうだろうと思ったが、すでにPulseAudio自体がプロセス化されているため、効果は高くないと判断。

画像は大量のメモリを扱うプログラムでもあるので、別にしたら少しは効果ある。

これで15%くらいの処理が減った!

 

諦めの部分としては1/60秒での画像データ生成をやめ、1/30秒とした。これならば重かったシングルタスク部分の処理がどーんと減るため、効果は高いはず!

 

この2つを入れたところで、無事CPUの占有率が100%以下となった。いくつかのゲームを動かしてみたけど、サウンドが途切れる事もなく良い感じだ!(^-^)

 

おわりに

キーボードについてはまだ対応が出来ていないため、これを軽くやって終わりにしようかと思ってる。

X68000(px68k-libretro)の動作はあくまでも実験であり、何かをもって発表という形にはしないつもりだ(ごめん)。

 

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

 

キーボードの対応 2022.09.06追記

その後の作業でキーボードの対応を行った!

今まで、Linuxのconsole上でリアルタイムキー入力といえばtermをrawモードに切り替えてioctlで読み取るくらいしかやったことがなかった!

 

今回は/dev/input/event0からデータを入力してみる事に挑戦してみた。

↑実際のプログラムとは少し違うんだけど、概ねこんな感じでキー入力を行った!

/dev/input/event0で読み取れるキーコードはx68k_libretroで使うモノとは違っているので、それをコード変換しつつ、キーの押す/離すの処理をエミュレータ側に渡している。

 

処理的には足りないところがあるようなのだが(CapsLockとか)、アルファベットを打ち込む分には概ね困らなくなった!(^^;;

Human68kでDIRってするくらいなら十分だよw ←

 

ソース、バイナリの公開について 2022.09.07追記

お問い合わせの多いソースやバイナリの公開についてです。

思ってることが2つほどあります。

 

ひとつめ。

現状の話ですが、ポメラDM200/DM250用が利用しているX-Windowドライバは、GPUアクセラレーションが効いていない状態のようです。X-Windowでの動作が全体的にもっさりする感じなのはコレかも。この影響はRetroArchにも及んでるハズ。

 

今回のpx68k_libretroへの改造内容については、X-WindowのドライバがGPUアクセラレーションを利用するようになったら解消される可能性が高いです。改造自体にあんまり意味をなさなくなっちゃう(^^;

表示系のスレッド化についてもRetroArchのオプションで指定出来るものであり、こちらも解消されると予想しています。

 

という大前提がありますので、ソースの公開には消極的です…汗

動作するバイナリについては公開しても良いかも…と考えてますが、広く公開する事はなく、希望者へお送りする形を取ろうと思っています(twitterからDMください^^)。

 

※動かすためにはX68000本体を所有している事、Linuxコマンドラインで操作出来る事、shared libraryと聞いて「?」にならないくらいの知識は必要です!(要は簡単には動きませんって事ですTT)

 

ふたつめ。

人様のソースコードを改造していますので、たとえバイナリの公開であっても著作権その他について気を使う必要がありそうです。この辺り、何も調査していないため少し時間がかかりそうです。

長年、ソフトウェアを生業として生活している人なので、ちゃんと気をつけたい(^^)

 

こんな感じです!(^-^)

ポメラDM250でレトロパソコン!

キングジムポメラDM250で遊びまくってる!(^-^)

前回はDebian Linuxを動かすところまでやってみた。

今回は手元にあるいくつかのエミュレータを動かしてみたよ!(^^)

 

RetroArch

RetroArch、過去にDM200でも動かしてみた事がある!

 

無茶かな……無茶かもね…と思いつつも再挑戦してみた!

DM250でもメニューを表示するだけで激重状態!(T-T)

オプションを調整しつつ動かしてみると、まぁ表示はそれなりに動くようになった。

 

サウンドはUSBサウンドアダプタからの出力だけど、ノイズ乗りまくり(T-T)

明らかにサウンドが間に合ってない感じだけど、CPUパワー的にはまだ余裕がある。

うーん、この謎をいつか解明してみたい…(-_-;;

 

XM8(PC-8801エミュレータ)

RetroArchが全体的に重たいので、PC-8801エミュレータはRetroArchから独立したものを動かしてみた。

XM8

↑のURLからソースが含まれたアーカイブをダウンロードしてビルド!

エミュレータ画面の右下を見ると、そこにはフレームレート2.0fpsと…orz

いやいや…さすがに遅いでしょ(T-T)

CPUの動作クロックが216MHzのままなのかな……?

調べてみると、XM8が動くと同時にCPUが816MHz動作になる事が確認出来た。

むしろCPUの処理自体は余裕がある事が分かった。

ここにきて表示系が遅いと理解し始めた。

 

FM-7エミュレータ

具体的に何がどのくらい遅いのかを確認してみたくて、拙作FM-7エミュレータを動かしてみることに。これは表示にSDL2を用いているので、表示の仕組みはXM8と同じだ。

自分で作ったものであればソースの改造も楽ちんだ(^^)

動かしてみたところ……うーん、びっくりするくらい遅い(^^;;

最初、動いてないのかと思っちゃうほどの反応悪さ(T-T)

 

さっそく調べてみたところ、SDL_RenderPresent(..)という関数が100msくらい掛かっていた。ということは、どんな頑張っても秒間10回書き換えが限度だ。

 

↑このページの一番最後に書かれいるGPU利用を読むと、どうやらアクセラーションが効いていないらしい。なるほど。

 

xf86-video-armsocで対応するという事らしいので、ちょいとソースを手元に持ってきてあれこれやってみたが、さすがに一筋縄ではいかなかった(^^;;

 

X68000再び!

過去にSHARPの電子辞書Brainで、X68000を動かした事がある。

この時は、RetroArch上で動くpx68k_libretroを改造してチャレンジしていた。

ぜひ「その1」から読んでみてほしい(^0^)

最後までまともな速度は出なかったものの、3段階で高速化に挑戦した!

最後に作ったのがフレームバッファ直描き版。

 

これ、途中でポメラDM200で動作確認をしていたんだけど、この時はあくまでも動作確認だけであったので、ポメラに特化した何かをしたわけでもなかった。

なんか、気持ち的にやり残した感が強かったので、今回DM250で動かす事にした!

 

前回の作業で、Brainで動かすためにRetroArch対応のpx68kを改造した。

具体的には

  RetroArch対応だったのを、X-Window + SDL2対応に改造

  X-Window + SDL2対応だったのを、フレームバッファ直描きに改造

という2段階を経て、Brainで動くようにしていった。

このSDL2対応→フレームバッファ対応の改造はポメラDM200上で行っていた!

 

今回、ポメラDM250では以下の事にチャレンジしてみた!

  フレームバッファ直描きはmmapにて対応

  サウンドはPulseAudioで出力

  ゲーム画面を縦横2倍表示

 

フレームバッファへの書き込みは、/dev/fb0をmmapする事で高速に行っている。

プログラムはmemcpyするだけという単純なものだ(^^)

※実際には16bit→32bitの変換をしたのちにmemcpy

 

サウンドについては、今回初めてLinuxで音を出してみた!

今までチャレンジした事がなかったので、少し勉強するハメにはなったが…汗

px68k側からステレオ44.1KHzの16bit PCMデータが送られてくるので、これをPulseAudioに出力するだけの簡単なコードだ。

近々、それっぽいスピーカーを手に入れてみようと思う(^^)

 

ゲーム画面はそのままだと256x256ドットの小さい画面になってしまうので、縦横を2倍で表示している。

ゲーム起動時に一瞬表示されるHuman68kは倍角無し、その後で表示されるゲーム画面は2倍で描画してる。

 

かなりそれっぽく動くようになったよ!(^-^)

 

最後に

この改造版PX68k、いまのところはジョイパッドの入力もマウスにも対応が出来ていない。

あくまでもX68000を立ち上げるだけの機能しかないのだ(^^;;

せっかくなのでゲームが遊べるところまで動かしてみようかなーという気になってる!

 

ポメラじゃなくてもいいじゃん…と言われそうだが、実はその通りだ(^^;

でもせっかくなので、力の限りポメラDM250の使い方を踏み外してみたい!

 

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

ポメラDM250でDebian Linux!

ほぼ正味2ヶ月ぶりのブログ更新!

ちょいといろいろとありまして、ブログに書けるような活動が出来てませんでした!

また少しずつ書いていきますので、よろしくお願いします(^^)

 

というわけで、復帰第1弾はポメラDM250!

 

まずはDM200!

私は前の機種であるDM200も所有しているが、こちらもLinuxを入れて使っていた。

ちょうど身体を壊して仕事を半リタイアしていたタイミングで、とにかく何かに集中して気を紛らわせたかった。

長らく離れていたプログラミングを再開するか…と思ったが、普通にMacWindowsでプログラムするのではひねりが無い。せっかくなので変わったマシンを使ってみたいな…と。

それでポメラに目が行った!(動機が不純w

 

DM200を手に入れて正規の使い方もままならない状態でDebian Linuxをインストールし、MC6809アセンブラや逆アセンブラFM-7エミュレータなどを作った。

プログラムに集中することで正気を保つ事ができ脳みそも活性化された!

私としてはとても思い入れの強いマシンなのだ!

 

そんな並々ならぬ思い入れがあったので、DM250の噂が出て来たら気になって仕方ないw

スペックその他は全く意識せず、発売と同時に手に入れてしまった!

 

そこからのDM250!

DM200の発売から6年後の新製品なので、それなりにパワーアップしているんだろうなーと勝手に想像!前情報からRK3326、メモリ2GBくらいを想像していたけれど、実際のDM250のハードスペックはDM200と大きな変更は無かった(^^;;

 

DM200でLinux使っててメモリに不満が無いのであれば買い替えの必要はないのかも(POMERA本来の機能は大幅にパワーアップしてる…はず)。

 

そして、さっそく@ichinomoto氏がDebian Linuxを動くようにしてくれた!!

もはや自分でLinux移植とかする力量も根性も無いので、@ichinomoto氏には本当に頭が下がります!(^^)

昔はもっと頑張れたのになー(過去の栄光w

 

uname、lscpu、df、freeした結果。

よーし、ここまで動いたら後は使うのみ!

 

というわけで、てっとり早く拙作CP/M80のソースを転送して動かしてみた!

標準ではmakeやgcccursesが入ってないので自分で入れる必要がある。

  sudo apt install make gcc libncurses5-dev libncursesw5-dev

 

このアップデートをしている時に気がついたが、無線LANがどどーん速くなってる気がする…。単にDM200が遅かっただけかも知れないけど、これは嬉しい!

 

他は特に苦労することもなく、あっさりとCP/Mが動いた!(^-^)

 

せっかくなのでビルドの時間を測ってみた。
  DM200: 24.394秒(1core)、10.520秒(4core)
  DM250: 25.980秒(1core)、11.284秒(4core)

 

何度計測してもDM250の方が少し遅いが、これは使ってるSDカードやgccのバージョンなどが関係してそうだ。

この数字を鵜呑みにするのは良くない!(^^)

こんなん誤差よ、誤差!(^0^)

 

気になってるところ

私の手元で起きている問題がいくつかあるので、参考までに記しておきたい。

 

・電源が不安定

一度、全く電源が入らない状態にまでなってしまった。

SHIFT+ALT+電源で何度か電源を入れたりしていたが、特に怪しいメニューには触っていなかった。

うちのDM250だけかも知れないが、USBを繋げたままでSHIFT+ALT+電源でDebianを起動する事が出来ない。

これは故障???かと思ったが、なんとなくコントロールする方法が分かってきたので、このまま使おうかなーとは思ってる。

 

・USBハブを認識しない

ハブには外部電源を繋げているが、それはDM250側が分かっている模様。

繋げたマウスにも電源が供給されているが、なぜかデバイスとして認識しない。

これはハブの問題かと思っているので、別途ハブを手に入れている。

また状態が変わったらレポートしてみたい!

 

追記:2022/08/31 12:35記す

DM200で動作実績のあったUSBハブ(OTG対応)にTYPE-C変換アダプタを取り付けて繋げてみたところ、無事に動くようになりました!

 

おわりに

とりあえず動かせたよーって報告で今回はおしまい(^^)

DM200も死ぬほど使ったので、このDM250もたくさん使っていきたい。

なにせ手元にある貴重な32bit Linuxでもあるので、今の私にはとても助かる(^^)/

 

きっと続きますw

 

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

GPi CASEにRaspberryPi Zero 2 W!

きっと誰かが試して情報流してくれるだろ…と思っていたけれども、

思ったよりも話が出てこないRaspberryPi Zero 2。

じゃあ…ということで、GPi CASEにZero 2を入れた話を書いてみるよ!(^^)

 

RaspberryPi Zero 2 W

2022年2月くらいに「そろそろ発売するかも?」な発表があって以来、ずーっと発売されてなかったRaspberryPi Zero 2 W。

これがようやく発売となった。

私もなんとか1つ手に入れる事が出来たよ!(TOT)/

 

もはや説明はいらないとは思うけれども…シングルコアだった初代(初代!?)のRaspberry Pi Zeroに比べて、Zero 2はクアッドコアな構成となっている。

他にも違いはあるけれども、一番影響の大きそうなのはコア数だ。

 

2が特別すげー!ってならないのは、すでにこのサイズでクアッドコアを実現していたBananaPieなどがあるからだろう。RaspberryPi Picoですらデュアルコアだし。

 

それでもこのサイズにこの機能を盛り込んだのはホントに凄いと思う!(^^)

RaspberryPi 4を使うまでもないんだけど…と思うような処理の多くはZero 2で賄えそう。

 

RETROFLAG GPi CASE

以前、ブログでGPi CASEというものをご紹介した事があった。

見た目は初代ゲームボーイそっくりな形をしているけれど、中身にはRaspberryPi Zeroを入れて必要なソフトをインストールして使う。

オススメ?はRecalBoxという総合エミュレータらしい。

私はこのGPi CASEでしかRecalBoxを使ったことがないが、個人的にはワリと使いやすい環境だと感じてる。

 

以前はRaspberryPi ZeroでX68000を動かす事に挑戦してみたが、完全なるパワー不足でまともな速度では動かなかった。

 

じゃあ…って事でBananaPi(コレは4コアでもあるのでZeroよりも結構パワフル)を手に入れた時、これをGPi CASEへ入れることを考えたのだが、どうやらGPIOのピン配置がRaspberryPiにしかないモード(DPI?)が有るようで、BananaPiでは動かなかった。

 

そんな事情があってGPi CASEを有効活用出来てなかったんだけど、中身をZero 2に入れ替えてみたらどうなるんだろう…と興味津々だったのだ!

 

RecalBox

実は前回のGPi CASEにチャレンジした時にも気がついていたのだが、RecalBox(エミュレータランチャ)にはRaspberryPi Zero 2 Wに対応したイメージが存在していた。

多分、Zero 2が普通に販売されていた海外で利用されていたのだと思う。

今見てみたら、Rapberry Pi Imagerのメニューにもイメージがあった!

「RecalBox - GPi Case + Raspberry Pi Zero 2」というイメージを選択して、SDカードへ書き込む。びっくりするくらい簡単な作業だ!

 

使ってみた感じは…

RaspberryPi Zero 2 Wに入れ替えたあとのGPi CASEは一皮むけたような感覚で、通常の動作もかなり軽くなってる!

メニューを立ち上げた状態での負荷状態はこんな感じ。

Zero 1の時はEmulationStationが起動しただけで40%くらいのパワーを持っていかれてたけれど、Zero 2だと合計で20%にも満たない。イメージもZero 2専用を使っているので、もしかしたら何か効率化されていたりする??

 

前回チャレンジして残念な結果に終わったX68000を動かしてみる!

おお……さすが4コアのZero 2!

たまーにサウンドが遅れる時があるけれども、概ね良い感じに動くようになった!

CPU稼働率はほぼ50%。えー??なんかすごく少なくない??

Zero 1であれだけ苦労してたのに、まさかの余裕。

 

これだけ動くんだったら、他のエミュレータもかなり余裕で動くんじゃない??

試しにNITENDO64を動かしてみた。

すごい!!

見た目がゲームボーイなのにNINTENDO64のゲームが動いちゃうなんて!(^^;

これは……20年前の自分に教えてやりたいw

でもアナログスティックが無いから起動するだけしか出来ないのかも??←要注意!

 

重そうなエミュレータ(SFC+SuperFX)もちゃんと動いた!

けど、スターフォックスに限っては音がちょっとずれてる(^^;;

 

他にも処理が重そうなエミュレータを試してみたいけれど、残念ながら私はゲームそのものは持っていてもイメージ化出来ていないものが多い。サターンとか遊べたら楽しいのになぁ(T-T)

 

そうだ!バッテリー事情も書いておきたい。

Zero 1の時はあんまり感じていなかったけれど、Zero 2に載せ替えて以降、バッテリーでの駆動が少し不安定になった気がする。これは私が1.2Vの充電池を使っていたせいかも知れない。

きちんと1.5Vの乾電池を使うか、または付属のUSBケーブルを使うのが良いかも。

 

あと、Zero 2自身の発熱に関して言えば気になったことはない。カートリッジ部分(ここにRaspberry Pi 2 Wが入ってる)を触ると、ほんのり温かいな…と思う程度だ。

私の使い方では全コアがフル稼働する事はないので参考程度にお願いしたい(^^)

 

おわりに

ぱぱっといくつかのモノを触ってみたけれど、Zero 1 → Zero 2への変更は、全く別物を触ってるんじゃないかと思うほど劇的な変化を感じられる!

GPi CASEを持っている方は、ぜひZero 2に載せ替えてみると良い(^^)

 

でも……これから新規でGPi CASEを買おうと思ってる方がいたら少し待って欲しい。

プラスαの金額を出せばMiyoo miniが買えてしまうからだ!

投資する価値があるかどうか、今一度考えてから購入をした方が良さそうだ!(^^)

 

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

 

GPi Case + Rasp

ANBERNIC RG353Pを入手した!

今回はANBERNIC社のRG353Pを入手した話!(^-^)

 

ここんところ実務が忙しすぎてクリエイティブが何も出来てない!

ブログの更新もほぼ1ヶ月ぶりという体たらくだ(T-T)

なにかきっかけがあれば……と思ってたタイミングで、注文してたRG353Pが届いた!

よーし、これでブログネタげっと! ← いろいろ間違ってるw

 

エミュレータの使い勝手等はYoutube等で見ると沢山ヒットするので、ここではゲーム機をゲーム機として扱わない、私なりのレポートをしてみようと思うw

…と言っても手に入れたばかりで何も分かっていないけれど!(T^T)

 

適当すぎる本体概要

まず手に取った瞬間、想像していたよりも大きくてビックリした。

もう1.5周りくらい小さなサイズを想像していたので、あれ?RG351MPよりもでかい?と気づいた時はワリと衝撃だった(^^;;

 

これでいて重さは…

RG351MPの272gに比べても218gとかなり軽い。

まぁこの場合はRG351MPが重たすぎる…とも言えるんだけど。

 

JELOSに入れ替え

手に入れてから一度も起動していないRG353Pだけど、最初からOSを入れ替えようと思う。

まずは本体を充電!

…と思ったら、USBに繋げて10分くらいで充電が終わった!(^^)

 

過去にRG351MPを入手した際、なぜか元から入っていたSDカードから起動しなかった。それもあり、私はANBERNIC社の純正OSを使ったことがない。

今回もどうしようかと悩んだが、出来るだけ慣れてるOSを使いたい!

 

ArkOSがあったらコレ一択だったんだけど、今のところは対応していないらしい。

先日発売されたRG503には対応されたようなので、同じRK3566を積んだRG353Pにもいつか対応されるんじゃないかと淡い期待!(^^)

 

ちなみにRG503のArkOSイメージをSDカードに焼いたら動いちゃうんじゃ??と思って試してみたけど、まーったく起動せず。まぁそりゃそうだ(T-T)

 

という流れで、今回はJELOSを利用する事にした!

このJELOS、ウチではRG552に入っている。

 

SDカードはちゃんとしたメーカー品を使う事にする!

過去に、やっすいSDカードを使っていたら読み書き速度が1/3くらいになっていた事があり、システムを入れるのは必ずメーカー品を使うようにしている。

元から入ってたSDカード(16GB)は大切に保管しておこう!

 

OSのインストールは難しいことはない。

MacLinuxならば dd if=イメージファイル of=/dev/デバイス名 bs=1m などで良い。

カードスロット1にJELOSを書き込んだSDカードを入れて電源入れれば、あとは全自動でパーティションのサイズ変更からSDカードへのインストールまで終わる。

 

X68000を動かしてみる!

やっぱり私の興味はレトロパソコンにある!

最近ではレトロコンシューマー機(ゲームボーイとかワンダースワンとか)もお気に入りで遊んでいるけれど、やっぱりパソコンを動かしてみたい!(^^)

 

まずはX68000を動かしてみたので、その流れを書いてみる!

他のエミュレータ機を使ってる方であれば設定は同じなので読み飛ばして大丈夫(^^)

 

まずはデータを入れるSDカードを用意する。

SanDiskが好き…というより、まとめて購入するのに都合が良かったのでコレを使ってる(^^;

ウチにはまとめ買いしたSDカードがいくつかあるんだけど、こういうことをしちゃうと気がついた時に価格が1/3以下とかになっててショック受けるんだよなー……

 

この買ってきたばかりのSDカード(おそらくFAT32でフォーマット済)をカードスロット2に入れてJELOSを起動する。

こうする事でSDカード内にデータを入れるフォルダがたくさん作られる。

このSDカードはWindowsなどの使い慣れたマシンで中身を変更する事ができる!

 

まずはbiosフォルダにkeropiというフォルダを作り、そこにX68000を起動するのに必要なファイルをコピーする。

cgrom.datは実機が手元にないと作れないので、X68000を所有していない方は、まずは実機を手に入れよう(^^)

 

次にx68000というフォルダにゲームなどのデータファイルをコピーしよう。

ゲームをイメージファイル化する方法は、別途ネットで調べて欲しい。私自身もだいぶ前(EX68が流行った頃…1999年辺り?)にやったっきりで、当時の方法も失念してるし環境も失われている(手元にゲームは残してある)。

 

x68000フォルダにファイルを入れてRG353Pを起動すれば、メニューにX68000が現れる。

私が頑張ってX68000エミュレータを動かすようにしてるわけではなく、元から動くモノを設定しているに過ぎない(^^;;

そこはお間違えの無いように…汗

 

あとは好きなゲームを起動してみれば良い!(^^)

 

JELOS

RG353PはWiFiが備わっていて、JELOS側で設定すればsshでログインすることが出来る!

ログインすれば素のLinuxマシンとして使ってみる事も!

でも開発中…というかJELOSの方針なのか、開発に必要そうなコマンド類(gccemacsなど)が入っていない上にアップデート(apt installなど)も出来ない。

今の時代に手作業であれこれコピーしてくるのは避けたい(T-T)

この辺りが遊べると(ワタシ的には)使い勝手が爆上がりなのですが…。

 

X68000エミュレータを動かした状態であっても4つあるCPUは余裕の状態。

これでサウンドが途切れるので、原因は別にありそう(前にチャレンジしたな、これ…)。

 

おわりに

あくまでも…用途がゲームではなくLinuxにある場合に限るけれど、RG351MPを所有していれば買い換える必要は無いと思う。この先、とてもおもしろい使い方が出来るような活路があれば話は別だけど、今のところはコレ!と言った違いは見当たらない。

 

もう少し本格的に使ってみたいけど、最近は別件が忙しくてどっしりと腰を据えることが出来ない(T-T) うーん、むしろRG353Pで仕事できたらいいのに(ムリ

もう少しだけ何かに使えないか検討してみたいと思う!

 

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

PX-15cを組み立てる!

Twitterでもつぶやきまくってたけれど、PX-15cを手に入れた!

 

実際にはPX-16cを買ったつもりだったけど、箱はPX-16cだけど中身はPX-15cというものが届く事故にあった(^^;; 

↑箱の表記と中身の表記を参照↑

通常であれば返品返金となるところだが、ここで紆余曲折あり手元に残ることとなった。

 

事故後、どうしてもPX-16cが欲しかったので直接販売しているところから購入する事にした。

ここで私が注文を間違えてしまい、担当者から確認のメールが届いた。

そこで「いやー実はひどい目にあってさー」的な話をしていたら、なんと!メールの主(担当者と思ってた人)がeBayの出品者だった!!!!(@_@;;

出品者本人とは知らず、愚痴ってたよ。すみません…orz

 

メールで何度かやりとりしただけだけど、人柄の良さと作るものの本気度を気に入ってしまい、この人が作ったものを手元に置いておきたいと思って、そのまま残す事にした!

という流れがあり、PX-15cはウチの仲間に!(^-^)

 

そもそもPX-15cとは??

…で、PX-15cってなんなの??電卓???と思われてる方もいるかなーと思うけれど、これはヒューレット・パッカードが販売していたプログラム電卓HP-15Cの互換機だ(^^)

うちにはHP-12cがある。もちろん動作品!(^^)

 

Wikipediaによると、HP-15Cが上級向け関数電卓、HP-16Cがプログラマ向け関数電卓となっていて、私はHP-16Cの互換機であるPX-16cがほしかったのだ(^^)

でも結果的にPX-15cも気に入ってしまったので手に入れちゃったけどw

 

この電卓、普通に使おうとすると面食らう。

「1 + 1 ENTER」とやっても計算が出来ないからだ(^^;;

この電卓は逆ポーランド方式という、ちょっと変わった操作方法を必要とする。

上記の「1+1」は、「1 ENTER 1 +」と打ち込む。

私の脳内では「いち たす いち は」と考えるのではなく「いち と いちを たす」と考えるようにしている。

慣れたらどってことはない(^-^)

 

組み立て準備

さて、今回は「ハードウェアの知識がゼロの人が組み立てるとこうなる」を書いていく!

面白おかしくするつもりはないんだけど、結果的にそうなる箇所があったらごめん!(^^;

実は組み立てながらブログ書いてる!ライブだぞ!(特に意味はない…w

 

まずは内容物を確認。

部品はこんな感じ。結構な部品数があるね…

でも部品ごとに袋に入っていて、かつ何が入ってるのかラベルが貼ってある。

これはすごく丁寧で助かる(^^)

こちとら部品名や略称で書かれてしまうと判別がつかない素人なので、こうやって分けられていると理解は出来なくとも判別は出来る(^^)

 

どうやらこれが部品表と作り方らしい。

パーツリストと部品を照らし合わせていったが、わからないものと余ったものがいくつか。

U1というパーツ番号が書かれた部品は無かったものの、説明にMicrocontrollerと書かれている事から、これだと思われる↓

この型番(ATMEGA32なんとか)は、V20-MBCを組み立てた時に見たことがある!(^-^)

多分、プログラムは書き込まれている状態なんだろうな……きっと!(^^;

 

あとPCBというパーツなのだが、これがなんなのか分からん…。消去法からいけば基板の事を指すのかな…(その後、作業リストを読んだらそうらしい事を理解)。

 

次に説明を読んでみる。

難しい言葉は使われていないので大変ではないけど、念のため翻訳しとく。

 

・すべての部品が基板に対して完全に平らになるようにする。
・部品のリード線を少し曲げて、所定の位置に保つとよい。

・抵抗、コンデンサ、プログラム用ヘッダ、水晶振動子など、背の低い部品からはんだ付けしていく。
 コンデンサが高すぎると、ディスプレイがマイクロコントローラの上に平行にならない可能性があるので少し曲げる。

・マイクロコントローラ、リセットスイッチ、電池ホルダをはんだ付けする。

 マイコンの切り欠きが、プリント基板のマークと一致していることを確認!

・39個のタクトボタンを全てはんだ付けする。
 すべてのスイッチを一度に基板に実装してから、基板を反転して平らな面に置くと簡単。
 PCBの背面を押して、すべてのスイッチを均等にする。
 各スイッチのピンを1本だけハンダ付けし、それらが基板と完全に同一平面上にあることを確認し、残りのピンをハンダ付けする。

・次にはんだ付けするのはスピーカー。極性に注意すること。

・最後にはんだ付けするのはディスプレイ。
 9ピンのオス型ヘッダをディスプレイにはんだ付けする。ヘッダは短辺がディスプレイと平行になるように、そして直角になるようにはんだ付けする事。
 ディスプレイをプリント基板にはんだ付けする前に、マイコンの上に両面テープで帯状に貼り付ける。
 ディスプレイがマイクロコントローラーの上にしっかりと均等に収まるように注意。

 

これを読みながら作業開始!(^-^)

 

はんだ付けしていくよ!

はんだ付けする準備をしていたけれども…基板を見て思ったこと。

ものすごくキレイな基板なんですけど…(^^)

これ、私の汚いはんだ付けで汚したくないなー(T-T)

基板単体で売ってないかしらん(^^;;

 

さて、はじめよう!!

まずは抵抗と水晶発振器をはんだ付けした!

すごい緊張するなー(T-T)

次は……と思ったんだけど、説明にあった「プログラム用ヘッダ」ってなんだ??

部品を見渡してみると、ひょっとしてコレかも…というのがあった。名前から考えても、マイコンにプログラムを書き込むヘッダだもんね、そうだきっとコレだ!

基板の裏をみて確信する(^0^)

めちゃくちゃ見覚えのある信号線が印刷されてるw

んー、でもマニュアルの中で名前が統一されていないのが微妙に分かりづらい(T-T)

はい、無事に付けられた(^^)

 

さて、コンデンサを付ける前に、気になる注意事項が書かれたのを思い出した。

コンデンサの背が高いから傾けないと液晶とぶつかる…みたいな記述があった。

うーん、どのくらい傾けるんだろ…適当でいいのかな…。

そもそもさ、液晶ってどの高さになるん???

液晶を繋げるピンは、短い方を下(←)にするのか、長い方を下(→)にするのか……。

過去にデジタル時計のキットを作ったとき、当然短いほうが下だろうと思いこんではんだ付けした後、実は逆だったことが判明して泣きながら20近くあったピンを抜いた事がある(^^;;

 

今回はどっちなんだろう…ぐぬぬ

ケースになるであろうネジ?の高さを調べたりあれこれ検討して、短い方を下にして(つまりおそらく標準的な付け方?)はんだ付けするんだろうと推測。

 

気になっているコンデンサの曲げ方について、とても有効な動画があった。

 ↑この動画の0:45辺りに、基板を横から見た状態が映ってた!

なるほど、↑コレを見るとC2は干渉しないけどC3は少し傾けてる。

よし、これの真似してはんだ付けしてみよう!

我ながら検討が長いぞwww

プログラムと違って、間違った時のリスクが高いのでどーしても慎重になる…orz

 

これでコンデンサもついた!

 

次はマイクロコントローラ(ATMEGA328P)をはんだ付けする!

ホントに久しぶりに登場のICピンそろった

V20-MBCの組み立て以来なんじゃないの???これがあるとICの足が簡単に揃えられるから、私みたいな脚折り名人さんは手に入れておいた方が安全(T^T)

無事に取り付け完了!(^-^)

 

バッテリーホルダとリセットスイッチも取り付けた!

このボタンの名前は覚えたよ、タクトスイッチだね!(^-^)

 

さて、次は鬼門なキースイッチをはんだ付け!

これは…数が多いのでだいぶ大変かも(T-T)

手順書に書かれていた通り、ボタンに4つある足の1箇所だけではんだ付けして、まずは全体の高さ調整。

良い感じ?(^-^)

ひっくり返してみても違和感はない!

よーし、これで全部はんだ付けするぜぃ!!

ぜぃぜぃ……これは……キツイ(T-T)

慣れてない人が一度に大量にはんだ付けすると、最初の頃と最後の頃でムラがありすぎw

いやまぁこれはこれで味があるといえばそうだけど(ムリな前向きw

 

最後にスピーカーをはんだ付け。

スピーカーには極性があるので、スピーカー上部のプラスマークを確認しつつ取り付ける。

今までスピーカーの極性を気にしたことが無かったので、ちょっと新鮮(^^;;

よし、これで主要な部品は取り付けた!

 

……じゃなかった!まだ表示系が載ってない(^^;;;

液晶は、最終的にはアルミパネルにキレイに収まらないといけないので、場所を慎重に調整しつつ決めていった!パネルはめながらここかなーこうかなーと(^^)

 

さぁ……電池を入れて起動テストじゃ!!

動いた!!!!

部品を取り付けるだけだから動いて当然と言われたらそーなんだけど、それだけでもハードわかんない人には本当に嬉しいのだ!(^-^)

 

よし、アルミパネルをはめてみよう!

ぐは!!

……この満足感はヤバいんですけど!!(^o^)/

 

どこのご家庭にもありそうなワンダースワンと比較してみるとこんな感じのサイズ感。

名刺サイズを一回り半くらい大きくしたような感じ。

何よりもすごいカッコいい!(^-^)

 

よし、じゃあ設定をしてみよう!

……と思って付属のマニュアルを見ながら操作してみると、なぜか設定画面が出ない。

マニュアルには「数字の0を押して電源を入れると設定画面が出る」となってるんだけど、これが出なくて結構悩んだ(T-T)

正解は「数字の0を押しながらONボタンを押し、先にONボタンを離す」だった(^^;;

和訳がヘタなのがダメなんだろうけど、これで1時間くらい悩んだw

 

できたよーーーー!(^o^)

これめちゃくちゃカッコいいな…ものすごく気に入った!!(^-^)

 

おわりに

とりあえずハード素人でも半日くらいあれば組み立てられる事が分かった!(^-^)

終わってみれば難関だったのはタクトスイッチのはんだ付けだけかも。他は書いてある通りにやれば大丈夫だった!

 

説明も丁寧だし、本来だったら悩むところはないんだと思う(^^)

今、PX-16cも注文してるので、また届いたら2つ並べて悦に浸ろうと思う!

いやー楽しみだなー(^o^)

 

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

 

2022.05.26追記

作者さまより「ここのページ見た?」と連絡がありました!

paxer.net

ぎゃー!作り方マニュアルがちゃんと整備されてました!!(^^;

こちらを参照していただければーー!