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

68000 ARM Linux 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へ画像データを出力するように改造した。

目的は２つ。

 

ひとつは省メモリ化。

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

 

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

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

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

 

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

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

 

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

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

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

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

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

 

サウンド対応

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

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

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

 

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

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

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

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

 

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

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

 

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

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

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

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

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

 

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

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

 

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

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

 

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

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

 

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

 

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

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

 

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

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

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

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

 

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

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

 

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

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

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

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

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

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

 

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

 

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

 

おわりに

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

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

 

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

 

キーボードの対応　2022.09.06追記

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

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

 

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

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

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

 

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

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

 

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

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

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

 

ひとつめ。

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

 

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

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

 

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

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

 

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

 

ふたつめ。

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

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

 

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

ランキング参加中
プログラミング