またしても自分のフラグを自分で回収する！(^^;;
前回のブログの最後で「libretro構成をやめてフレームバッファに直接書き込むようにしたら爆速になるのでは」という趣旨の事を書いた。
これの真意は、
実行速度が極端に遅い理由は、おそらくメモリ不足によるスワップアウト
使用メモリを減らせば、その分速くなるのではないか？
という意味だ。
RetroArchが悪いわけでもX-Windowが悪いわけでもない。
単に動作時のメモリが足りないんだろうな…という予測で書いた。
今回はその仮説が正しいのか検証するためにPX68kを改造してみるよ！(^-^)
どうやって改造する？
まず手元にはRetroArchに対応したlibretro版のPX68kがある。
間違いなく、実際に動いてるプログラムを改造していくのが簡単だろう。
px68k_libretro.soはRetroArchに依存していて、RetroArchはX-Windowに依存している。
px68k単体で動かそうとするのであれば、それぞれの依存を断ち切らないといけない。
しかしpx68kをRetroArchから引っ剥がすのは簡単なのだろうか？？？
未知数が多すぎる……(@_@;
よし、なんとなくな方針を決めた！
まずはRetroArchから引っ剥がし、SDL2版に改造する(X-Windowに依存)
さらにフレームバッファ対応に改造してポメラで動かす(依存無し)
最終的にBrainに持って行き動かす
最初の１つ目の難易度が高そうだけど、それさえ出来ればあとはそうでもない？？
……能書きは良いから手を動かしてみる！(^^)
RetroArchから引っ剥がす
px68k_libretro.so(PX68kの実態)は、RetroArchから動的にリンクされる事で使えるようになる。RetroArchのメニューでいうところの「コアのロード」だ。
これを通常のmain関数を入り口とした、単体のコマンドとして動くようにする。
じっくりとlibretro対応のプログラムを見ていると、なんとなく構造が見えてきた。
なるほど、こういう対応をするとlibretroとして機能できるのね。
中身はコールバックによる抽象化っぽい構造となっていて、初期化時にいくつかのコールバック関数を登録している。
retro_set_environmentという関数で、いわゆる環境変数のような情報をセット／ゲット出来るようになっている。戻り値をRetroArchっぽく真似してやれば良さそう？
これらのコールバックを自前で用意してやれば、なんとなくRetroArchの構造を借りたまま、単体でのコマンドとして作れそうな気がしてきた。
自前のコードは、RetroArchほど豪華ではないけれど、RetroArchの構造を借りたままPX68kを騙しつつ動くようなラッパーを書く事にした！ザ・手抜き！(^^;;
まずは動かすのが先よ！(^_^)b
ガチャガチャと触りだして１時間ほど経過した頃、なんとかPX68kの初期化→エミュレーションをする上で、エラーなく動作するようになってきた。
ここまでは画面表示は一切なしで、あくまでも動作確認はprintfという感じで進めた。
ここまでの作業＆動作確認はMac上でしていて、コンパイラのオプティマイズオプションも-O0という、開発速度重視(^^;;
無事にエミュレータのループが回るようになると、おそらくVRAMには表示用のデータが乗って来ているはずだ。
retro_set_video_refreshというコールバックに渡されるvoid *dataに、エミュレータ側が作った画像データが入っている。
このデータをSDL2を利用して表示する。
何度かチャレンジした後、よーやくMac上で画面が出るようになった！
スクリーンの解像度もパレットも変な状態だけど、とにかく画面に変化がおきた！
起動ディスクにHuman68kを指定しているはずなのに、なぜかディスクが認識されていないようだ。こういう不具合を１つずつ潰していく地道な作業…。
そしてようやくHuman68kが立ち上がった！
テキストVRAMが1024 x 1024のサイズあったので、ウィンドウサイズもそうしていた。表示部分のみ更新されるので、画面で見ると約半分が表示されてるのね(^^)
ゲームを起動すると、こんな感じの画面になっちゃう(^^;
SDL2版は、あくまでも単体で動かすのが目的なので、表示される画面についてこだわりはない。拡大表示とかもする予定ないよ！(^^)
ここまでの作業で、px68kはX-Window(というかSDL2ライブラリ)にのみ依存していて、すでにRetroArchからは引き離された状態！
コマンドラインから実行できる単体のソフトとなっている！
X-Windowから引っ剥がす
次の段階は、SDL2対応を辞めてフレームバッファ直描きに改造をする！
Macではフレームバッファ(/dev/fb0)へ書き出す事が出来ないので、実行はCPUパワーのあるポメラDM200で行う事にした。
過去に何度かフレームバッファ直描き→SDL2対応をした事があったので、ここはもうひょひょーいって感じで作業完了(^^)
表示を画面中央には配置したけれど、拡大処理などは行わず(^^) そのおかげもあってか、実行速度はX68000実機と遜色ない速度で動いてくれた！
この状態で、ついにX-Windowへの依存も無くなった！
Brainで動くように改造する
さあついに本ブログの本丸である、Brainで動くように改造していくよ！(^-^)
実はポメラのプログラムがそのまま利用できると思っていたのだが、フレームバッファのサイズ(深度)が違っていて、そのままでは動かなかった。ポメラは32bit、Brainは16bitだ。
むしろカラー変換無しで表示が可能になったので、プログラムもただ単にフレームバッファへ書き込むだけの数行で済んでしまった！(^^;;
ビルドに２時間弱掛かるので、出来る限り間違いは少なくしたいｗ
この頃になると不安が広がっていた…。
実はメモリ不足が遅い原因ではなく、BrainのCPU自体が遅くてあの速度になっていたとしたら…単体で起動するようにしても実行速度は変わらないのかも…とか思い始めてた(T_T)
もしもそうだった場合、残念ながら今回の作業での速度改善は一切されない…。
そして表示された単体プログラムのPX68k！
遅いかも？という不安を払拭するほどの速度で動いてくれた！
前回のX-Window + RetroArchで動かした時の速度と比較してみると…
実行開始からロード画面が出るまでの時間
24分30秒 → 43秒
ロードが終了してタイトル画面が表示されるまでの時間
60分 → 2分47秒
ラスタースクロールが終了してタイトル画面完成
86分 → 3分14秒
約26倍以上になった！！！
実際の動画を撮影したので、以下参照。
SHARP電子辞書BrainでX68000改良版！
— PocketGriffon (@GriffonPocket) 2022年3月3日
表示画面は小さくなっちゃったけど、アニメーションしてるって分かるくらいの速度で動くようになった！(^O^)#電子辞書 #X68000 #Brain pic.twitter.com/2a7NoN6oCr
動画を見てもらえれば分かるけれど、それっぽい速度では動くようになった！
やっぱり速度が遅かったのはメモリが不足していたからみたいだった！
いや嬉しいねコレは！(^-^)
最後に
Brainでは、自分でフラグを立てて自分で回収するという事を2度ほどやった。
今回のフラグ回収は結構時間が掛かると思っていたが、実際にやってみると半日ほどで終わってしまった。Brainでビルドしてる時間がなければ、もっと速く終わってたかも(^^;;
Brainで、もうひとつだけ試してみたいと思ってる事があるｗ
Releases · brain-hackers/buildbrain · GitHub
まだunreleased版ではあるものの、新しいOSイメージがダウンロード出来るようになってるんだよね…。
もしもmmapが正しい値を返すように直っていたら、今の描画よりも2倍くらい速くなる可能性がある…。これは出来るかどうか試してみたい気がする！(^-^)
実務もあるので、時間がある時にやってみるよ、ええ、時間がある時に！(^^)
ではまた次回！(^-^)ノ
