この手のハードの解析について、みんなの興味があるところなのは
ほかのゲームのエミュとかROMを入れられるとかそういうところなんだと思いますが、
それははっきり言って最終的には「できる」んですよ。
でも、それをすること自体には、いろいろな問題、
情報発信の責任がついてきてしまいます。
「ネタ」としてその手のことに近いことをやることはあると思いますが、
例えば簡単な入れ替えツールや明確なROMの引っこ抜き方はこのブログには出てきませんのであしからず。
さて、このハード、Linuxとしてデバイスが抽象化されていますので、その辺のハンドルを試してみます。
内蔵LCDはST7789VWというわりとハイスペックな240x240の液晶が搭載されています。
Linuxから画面に表示させるには、フレームバッファというデバイスに何かしらのデータを書き込むと、割り当てられたディスプレイに何かが表示されます。
普通のマシンでは、 cat /dev/urandom > /dev/fb0 として、画面にごみが表示されることを確認することが多いです。
ゲームギアミクロでも同様に、/dev/fb0が存在していますのでこれを試してみます…
ゲームのUIをストップさせてこのコマンドを実行させてみますが…何も表示されません。
あれれ？どういうことだろう。
ゲームのUIを動かしたまま、上記コマンドを実行すると一瞬画面にごみが表示されました。
おやおや。どうやらこのマシンでは、fbに書き込んだデータは別の仕組みでlcdに転送されているようです。
いろいろ調べてみると、"/sys/kernel/screen_update/update” というファイルが見つかりました。このファイルに"1"を書き込むと、ドライバがfb0からlcdに転送してくれる仕組みになっているようです。
では改めて、urandomからfbに書き込み。
さらに、クロスコンパイルしたfb-testを実行してみます。
コマンドだけ打ち込んでもLCDが変わりません。
ここは手動で/sys/kernel/screen_update/updateを更新します
実行している動画です。
ゲームギアミクロのlcdになんか出すテスト pic.twitter.com/MgyedXrmpM
— ひろみつ(honeylab) (@bakueikozo) 2020年10月7日
このように、一応fb0に連動してlcdを更新させることができました。
fbを使用するアプリケーションはlcdへの転送を組み込むか、別途バックグラウンドで転送するアプリを動作させれば(syncの問題は出ますが)
普通のLinuxのアプリのように動作させることが可能です。
もしくは、このdispドライバが非同期更新の仕組みを持っていると助かるのですが…
ところで、公式スペックによると画面サイズは1.15インチということになっています。
発売前、液晶の解像度とこの1.15インチという値から、内蔵されるLCDを探していたのですが見つかりませんでした。
こんな中途半端(160x144)の値の液晶をカスタムで作るわけはないため、オーバーサイズの液晶をマスクして使うことは想定していました。
上記の動画を見るとわかるように、左上の点が下にオフセットされています。
つまり、こんな感じでゲームギアミクロでは正方形の液晶の上下をマスクして長方形に見せています。
ドライバのパラメータを見てみると、以下のように設定されていました。
内部fbは256x238として使用されていて、エミュレータでは160x144に描画、
これをLCDの[0-240,38-180]の範囲に拡大表示する、という動作です。
つまり横方向1.5倍、縦方向…ちょっと合わない…？
まぁ、最終的に整数倍にならないのはたぶんそれをやるとゴリゴリの表示になっちゃう、とかいう理由で調整したんじゃないですかね。たぶん。
（計算でぴったり合わせてドヤ顔するつもりだったんだけどなぁ…）
ところで、このLCD、スペック的には1.3インチということになっています。
では、公式スペックの1.15インチはどこから来たのでしょう。
…出た！！！1.15インチ！！！ この中途半端な値はここから来たのね！
ふぅ、すっきりした…三平方の定理ってこうやって使うのよ。
