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

ポメラDM250で動かすエミュレータ、第3弾!(^-^)

今回はMSXを動かしてみたのでレポートしてみたい。

 

 

今回は2つのMSXエミュレータを試してみた。

  fMSX

  openMSX

どちらもとても有名なエミュレータなので、今さら説明は必要ないだろう…と思う(^^;

気になったら検索してみてくれ!(ブログの意味…

 

fMSX

私は比較的早い時期からfMSXに触れていた。多分、1994年くらい?

当時、68030CPUのワークステーションで動かしたのが最初だったと思うが、もしかしたらMIPSワークステーションだったかも…?記憶が曖昧だけど、そのくらいの時期だ。

 

その頃からエミュレータに興味があって作ってた私にとっては、ソースが公開されて目の前で動くというのは重要な資料だった(^^)

 

同じ会社のハード屋さんが、MSXのカートリッジからデータを読み出す機器を作ってくれたので、手元にあったザナック(コンパイル)を読み出して遊んだ記憶がある。

よくこのマシンでちゃんと動くなーって感心した(^^)

 

そしてそのfMSXは今でも動かすことが出来る。

 

画面上の方にある「Download」のページへ行き、

 fMSX 6.0 source code and related files (core + Unix/X port) 

からソースコードをダウンロードする。

 

適当な場所(ここで~/src以下)に展開をしてビルド。

 cd ~/src/fMSX60/fMSX/Unix

 make clean

 make

環境によってはライブラリが足りない場合があるので、適宜apt installして欲しい。

 

fMSXを起動する際にはBASICのROMファイルなどが必要となる。

手持ちのMSXから、なんらかの方法でポメラへ持ってくるべし。

 

↑起動するとこんな感じ。懐かしい画面だ!

この状態でBASICもちゃんと動く(^^)

 

せっかくなのでゲームカートリッジを動かしてみよう!

 ./fmsx カートリッジファイル

これでカートリッジ1にカートリッジファイルが入った状態で起動する。

……画面はちゃんとしてるんだけど、USBに繋がったサウンドアダプタから出力されている音楽がひどい(T-T)

ノイズというよりも……ゲームによってはちゃんとしたデータが反映されていないんじゃないかと思うような動作をする。

これはなんだ???

 

試しにウィンドウサイズを小さくしてみる。

 ./fmsx -scale 1 カートリッジファイル

 

あれ?これでもサウンドがダメだ…。

うーん…これは現象の説明がつかないな…。

とりあえずfMSXは保留!!(T-T)

 

openMSX

fMSXであれーっとなったので、今度はopenMSXに挑戦してみる事に。

openMSXにちょっとだけ躊躇していたのは、過去にDevTermで動かした際、ビルドにめちゃくちゃ掛かった記憶があるのだ。

ブログ↓を探してみたところ、ビルドに3時間掛かってる!

 これをポメラでビルドしたら、果たして何時間掛かっちゃうんだろうか…。

 

 

上のページの左側にあるDownloadから18.0 / Source codeをクリックしてソースを得る。

これを展開したのちに、そのフォルダへ移動して

 ./configure

とすれば、必要なライブラリのチェックが行われる。

ここでnoとなってるものをapt installしまくる(^^)

私の環境ではtcl-devが入ってなかった。

…Tcl/Tkって久しぶりに聞いた…(^^;;

 ビルドに230分……orz

…カンベンしてください(T-T)

 

これは何度かビルド失敗した続きで測ってるので、実際には300分くらい掛かってるかも知れない。

もう一度やり直す気力がないので正確な時間はご勘弁(T^T)

 

ビルドが通ったら、おもむろにインストール。

 sudo make install

※インストールする場所によってはsudoはいらないかも知れない。

 

さっそく起動してみよう!

sshからログインしている端末から起動する場合は、環境変数DISPLAYの設定をお忘れなく。

 export DISPLAY=:0

ポメラ本体でX-Windowを起動していれば、そちら側の画面に出る。

 openmsx カートリッジファイル

とすれば、カートリッジ1にROMファイルを挿した状態で起動する。

 

 

マウスを繋げていれば、openMSXウィンドウの左上辺りにマウスを持っていくと小さくmenuと表示されるので、それをクリック。

ここで細かい設定が出来る。

表示画面を2倍にしていると、やはりサウンドがノイズだらけだ(T-T)

ポメラは画面描画系が強くない印象(ToT)

Video Settings... → Scale Factor: にマウスを合わせ、カーソルキーの左を押すと等倍角画面になる。

……小さいよね(T-T)

でもこのサイズだったらゲームによってはサウンドが途切れず鳴るようだ。

画面の高速化が進んだらきっと解決される問題だろうから、今は我慢する!(しようw

 

catapult(カタパルト)

この小さい画面のメニューであれこれ操作するのが面倒だなぁ…と思っていたら、便利なツールがあることが分かった。

catapult(カタパルト)というツールで、外部からオプションを設定出来るらしい。

これは試してみたい!(沼開始w

 

ここから先はオプション…というか、無くても良いものなので、もしもインストールしてみようと思う方は、まず先に最後まで読んで欲しい。

結構な手間と時間が掛かる!(T-T)

 

先ほどopenMSXをダウンロードした同じページにある、

 Catapult

 18.0 / Source code ← ここ

からソースファイルをダウンロードする。

適当な場所で展開をし(ここでは~/src)、ビルド。

 cd ~/src/openmsx-catapult-18.0

 make

すると、openMSXでconfigureした時のように環境をチェックしてくれる。

私の環境では2つのライブラリが無いと出た。

そのうち、wxWidgetsというライブラリが問題(T-T)

apt install で持ってくることが出来ないようなのだ(方法があるのかも)。

仕方ないので、ソースからビルドする道を選ぶ!

 

www.wxwidgets.org

ここで表示される「Download now」をクリック、Source for Linux, macOS, etc をクリックしてソースファイルをダウンロードする。

 

www.kkaneko.jp

インストールはこちら↑のサイトを参考にさせていただいた!

無事にsample/minimalが動くことを確認!(^-^)

 

ようやくcatapultに戻って再度makeを始める。

 cd ~/src/openmsx-catapult-18.0

 make

 sudo make install

これまた数時間掛かるビルドになるので、他の作業しながらやった方がいいよ!(T-T)

 

ちなみにビルドをしている最中であってもポメラが熱くなるような事がない。

裏面を触っても温かいかな?こんなもんかな?って感じだ!(^^)

無音で、かつ健気にビルドを続けるポメラはなんとなく可愛いぞ!w

 

make installが終了したら、catapult とすれば実行できる。

ウチの環境では起動するとエラーが出てしまう。

でもこれはOKすれば先に進めるようだ(典型的なエラーを読まないヤツ)。

これはデフォルトのままで良いと思うが、openmsxの置いてある場所をセットする。

OKをするとマシンのチェック?が入るが、Cancelしても起動はするようだ。

あとはカートリッジに差し込むROMファイルを選択し、右下にあるStartをクリック。

openMSXが起動している状態になると、CatapultウィンドウのVideo Contorolsタブが触れるようになる。そこで設定を変更すれば、リアルタイムにopenMSXに反映される。

これで試しながらゲームをするのに最適な設定を調整すれば良さそうだ!

やっぱり画面は小さい方が安定して動くみたいだぞ!

 

おわりに

2つのエミュレータを試してみたけれど、どちらもちゃんと動かすには調整が必要。

MSXのゲームで遊ぼうぜーって人は、素直にWindowsマシンを使うのが良い(^^;;

 

ポメラエミュレータを動かして見るのが楽しいのであって、実用を求めてるわけじゃない。でも将来的にちゃんと実用的に動くようになるんだったら、それはそれで大歓迎だ!

そのために今日も頑張って動かしてみるよ!

 

ところで…MZ-2500でも動かしてみるかーって思って探してみたのだけれども、もしかしてLinuxで動くMZ-2500エミュレータって存在しなかったりします??

探し方が悪いのかも…汗

 

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

ポメラで動かしてる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で仕事できたらいいのに(ムリ

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

 

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