NEOGEO Arcade Stick Proシステム詳細

for jumped from youtube link people, read these articles.

honeylab.hatenablog.jp

前の記事で、シリアルが出力されない、と記述しましたが、

honeylab.hatenablog.jp

ハック対策なのか部品点数削減なのかはわかりませんが
一部の部品が実装されていないだけでした。

基板裏面、シールドを外してR44がSoCのTXと4ピンのTXピンの間に直列に挿入される回路になっていますが、これが実装されていませんでした。
この部分に適当な抵抗をはんだ付けするか、保護を気にしなければジャンパするだけでTX出力が有効化されました。

R38がRXに直列接続かと思ったのですが、こちらは片側がVCCに接続される（プルアップ）だけだったので、ここは空のままでOKです。電圧レベルは3.3V系(TXは3Vスイングでした)です。

この方法で起動ログが取得できました。全体は以下のリンクにあります。

https://bitbucket.org/snippets/hiromitu/GrgMz6

ところで、この起動ログの後、ログインプロンプトが…と思ったら

普通にシェルのコンソールでした…

ぇぇぇぇぇ…

さて、使用しているLinuxのバージョンは…？

root@snk:/ # uname -a
/system/bin/sh: uname: not found

あれ、unameコマンドが無いぞ…？
すごいシュリンクしたrootfsなのかな…？

127|root@snk:/ # cat /proc/version
Linux version 3.4.0+ (frank@ubuntu) (gcc version 4.6.3 (Sourcery CodeBench Lite 2012.03-57) ) #57 SMP PREEMPT Sat Oct 12 02:02:05 PDT 2019

/proc/versionから見えました。

ちゃんと、Linuxですね。
ところで、Linuxを使用しているからにはGPLに基づいた権利表記とソースコードの公開が必要なはずですが、

権利表記が適当…っていうか、これよく見たら使ってるよ、しか言ってないな…

ソースコードも今のところ公開されておらず…

取り合えず、サポートにソースコード頂戴ね、ってメールしておきました。

もしかすると、今後のシステムアップデートで更新されるかもね！！！

さて、なんでunameすらないのかな…といろいろ調べてみると、どうやらKernelの起動後、Androidシステム(という言い方が正しいのかがわからない)が起動されているようです。

Processor : ARMv7 Processor rev 1 (v7l)
processor : 0
BogoMIPS : 1022.18

processor : 3
BogoMIPS : 1022.18

Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0

Hardware : gs702c
Revision : 0000
Serial : b6db2d7d18a7c7a7

cpuinfoはこんな感じ。普通にARMでした。

NEOGEO miniのATM7013HがMIPSだったので、こいつもMIPSなのでは…と思っていたのですが、さすがにそうではなかったようです。
ARMであれば、追加で何かのプログラム・エミュレータを入れたりするのも簡単です。

Android Kernelで動いてはいますが、メニューやエミュレータは普通のELF executableでした。
なんでわざわざAndroid…と思ったのですが、

/system/build.propを覗いてみたところ

root@snk:/system # cat build.prop
ro.build.id=KOT49H
ro.build.display.id=Demo_7051H-user 4.4.2 KOT49H eng.songzhining.20161121.190628 test-keys
ro.build.version.incremental=eng.songzhining.20161121.190628
ro.build.version.sdk=19
ro.build.version.codename=REL
ro.build.version.release=4.4.2
ro.build.date=Mon Nov 21 19:10:55 CST 2016
ro.build.date.utc=1479726655
ro.build.type=user
ro.build.user=songzhining
ro.build.host=srv-pad-compile5
ro.build.tags=test-keys
ro.product.model=GS705B
ro.product.brand= Android
ro.product.name= Demo_7051H
ro.product.device=snk
ro.product.board=atm7051H_demo_q88_hd
ro.product.cpu.abi=armeabi-v7a
ro.product.cpu.abi2=armeabi
ro.product.manufacturer=Actions
ro.wifi.channels=
ro.board.platform=ATM702X
ro.build.product= Demo_7051H
ro.build.description=Demo_7051H-user 4.4.2 KOT49H eng.songzhining.20161121.190628 test-keys
ro.build.fingerprint=Android/Demo_7051H/q88_hd:4.4.2/KOT49H/eng.songzhining.20161121.190628:user/test-keys
ro.build.characteristics=tablet 

のように、GS705Bというタブレット用の開発環境がそのまま流用されているようです。うわぁ。

要するに、これはジョイスティックのついたAndroidタブレットです。
（悪口ではないですよ。）

bootlogを見ると、どうもブートローダはu-bootではないようです。
vfatフォーマットの/miscパーティション内に置いたboot.imgからkernelを起動出来たり、結構便利な感じですね。

起動ロゴっぽいbinとかもあるので、ファームウェア自体にあまり手を触れず、
結構遊べそうな感じです。

そして、肝心のエミュレータですが…

 「mvsnjemu」ですね。NEOGEO miniと一緒だね。
…GPLだね。よろしくね。

何かしらのグラフィックのアクセラレーションが効いてるんじゃないかと思うんですが、まだその辺は確認していません。
mvsnjemu内にSDL_INITがいたので、その辺を使えば普通に効くのかしら。

なんかしら適当なのを適当に持ってくればなんでも動きそうな気がします。
デバイス周りは絞ってると思うのでできればカーネルを再コンパイルしたいところではありますが…

そして、気になってる人も多いと思う隠しゲーム。
順次アンロックになるので外部からゲームファイルを供給するのか、フラグ解除方式なのかという話でしたが

とりあえず、内部に全ゲームROMは収められていることはわかりました。
また、私レベルのユーザであれば自分でアンロックもできることはわかりました。
それ以上は、記録に残すことはやめておきます。（うざい）

とりあえず、カーネルのソースお願いね！

NEOGEO Arcade Stick Proを開封レビュー

開封とは…

裏ブタを外すと、思ったより小さいメイン基板が現れます。

基板下側の４ピンにRX/TXって書いてあってバレバレじゃんププーとか思ったんですが、今のところここから出力は出ていません。
なので、何のOSが入ってるかとかそういうのも今のとこ不明。
左上にも４ピンがあって、ここの役割はまだわかっていません。
B1を押しながらUSBを挿すとファーム更新モードに入ってるっぽいですが、
デフォルトのUSBケーブルで反応してません。あ、ケーブルが違うのかな？

CPUはActions SemiconductorのATM7051H。

NEOGEO MiniにはATM7013っていうのだったので、たぶん同系統。
NEOGEO Miniのはカスタムファームが出てたので、こいつもいけないことはないと思うんだけど、まだそこまでは手付かず。

ストレージはEMMC。本気ならはがして読めるんじゃない？俺はやらない。

基板裏。 NEOGEO G1 V4.4 なんでもうV4なの？

とりあえず蓋を戻した。ちゃんと動いた。

これからもうすこし頑張って解析してみます。

解析して、手に負えないようなら手放します。

メガドライブミニに一般的なUSBアーケードスティックを直接接続して使えるようにする

メガドライブミニが発売されて２週間。

いろいろなハックをしてきましたが、やっておきたかったこの改造が成功したので記録しておきます。

（※この記事の内容は技術的検証であり、完全に再現可能な手順を記したものではありません。この手順で行ったことをもとに、平均的なユーザが利用可能なツールがリリースされる可能性はゼロではありません。平均的なユーザが、現在できることではそのリリースを待つことです。）

※検索でたどり着いた方へ※

このページには技術的情報がまとめてあります。

 市販のゲームコントローラをメガドライブミニで使用するには
こちらのコンバータを使用するのが最もかんたんで確実です。 

【MDミニ用】スーパーコンバーター（PS4/PS3用コントローラ対応） - メガドライブミニ

過去の記事にも書きましたが、メガドライブミニではいわゆるファームウェア（Linux）の設定で、特定の公式サポートゲームパッドしか接続・認識できないことがわかっています。

honeylab.hatenablog.jp

また、偶然USBのVIDやPIDが一致したパッドでも、上下左右のキーが正しく入力できなかったり、ボタンのマップがめちゃくちゃで、ろくにゲームができない、という状態のようです。

そんな中、

www.4gamer.net

このような製品もサードパーティから発売されるようで、一般的なユーザはこの変換アダプタを購入して使用するのがいいのではないか、と思われます。

しかし、これ一本 5,480 円するようで…
処理内容を考えると、全く妥当ではあるんです。しかし、じゃぁこれを使ってアケコンで対戦する、となったらｘ２本で一万円かかってしまうわけで。

もちろん、それも一つのやり方ですが、ここはメガドラミニのほうを書き換えて
一般的なアケコンを使えるようにしてしまえ、というハックが成功しました。

使用したアーケードスティック

ボタントランスレートの目処が立ったので買ったんだけど...なんでこれボタン青いんだ
軽量ボタンに変えてるとかなのかな
だからジャンクコーナーにあったのか..
ボタンは全部反応した pic.twitter.com/qZnVDZokq3

— ひろみつ(honeylab) 技術書典７け36D (@bakueikozo) October 9, 2019

 今回使用したアーケードスティックは、iBUFFALOの「ARCADE STICK 13Ⅱ」

（BSGPAC02BKBC）というものです。
近所のハードオフのジャンクコーナーにありました。

ジャンクコーナーにあったので、動作が不安だったのですが、どうやらボタンやスティックが前オーナーによってマルっと交換されているだけで、動作には問題はありませんでした。
ボタンの交換がジャンクコーナー行きの理由だったようです。

どうやってつくったか

メガドラミニの内蔵謹製エミュレータがどのようにしてコントローラ入力を読み取っているのかをまず観測してみます。

Linuxのシステムコールの呼び出しを観測できる「strace」ツールをメガドライブミニに入れて動かしてみます。

# /rootfs_data/strace -e trace=open -ff /usr/game/m2engage

すると、

[pid 29051] open("/dev/input/event4", O_RDONLY|O_LARGEFILE) = 8

という部分が見つかりました。
どうやら、/dev/input/event4を読んでいるようです。

今のカーネルだと、刺さってるHUBのポートみて本体1,2はevent4,5、本体1に刺さったHUBのポート順に6,7,8,9,本体2のHUBでは10,11,12,13に割り当てられる
話を簡単にするために、一旦裏のOTG経由でつないだやつをフィルタ出来るようにしてみるかな pic.twitter.com/RhQx1Nd5PY

— ひろみつ(honeylab) 技術書典７け36D (@bakueikozo) October 8, 2019

 このデバイスは、Linuxのソースコード evdev.c　をHUBのポート番号によって番号が固定されるようにオリジナルのソースから改変することで実現されていました。

純正のメガドライブパッドを接続したとき、event4がどのようなイベントを受け取っているのか、「evtest」ツールで確認します。

 Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0xca3 product 0x24 version 0x111
Input device name: "6B controller"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 288 (BTN_TRIGGER)
Event code 289 (BTN_THUMB)
Event code 290 (BTN_THUMB2)
Event code 291 (BTN_TOP)
Event code 292 (BTN_TOP2)
Event code 293 (BTN_PINKIE)
Event code 294 (BTN_BASE)
Event code 295 (BTN_BASE2)
Event code 296 (BTN_BASE3)
Event code 297 (BTN_BASE4)
Event type 3 (EV_ABS)
Event code 0 (ABS_X)
Value 127
Min 0
Max 255
Flat 15
Event code 1 (ABS_Y)
Value 127
Min 0
Max 255
Flat 15
Event type 4 (EV_MSC)
Event code 4 (MSC_SCAN)

出力は上のようになりました。
ボタンは、288-297がレポートでき、方向キーは、X軸、Y軸それぞれ0-127-255の絶対座標で受け取れるようです。 

では、この買ってきたアーケードスティックを接続した場合はどうなるでしょうか。

……　なんと、当然認識しません。カーネルにIDが記録されていないからです。
この辺の制限を外したカーネルを使って試す必要があります。

制限を外して再コンパイルしたカーネルを使うと以下のように認識させることができます。

Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x1dd8 product 0xe version 0x110
Input device name: "BSGPAC02 Series"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 304 (BTN_A)
Event code 305 (BTN_B)
Event code 306 (BTN_C)
Event code 307 (BTN_X)
Event code 308 (BTN_Y)
Event code 309 (BTN_Z)
Event code 310 (BTN_TL)
Event code 311 (BTN_TR)
Event code 312 (BTN_TL2)
Event code 313 (BTN_TR2)
Event code 314 (BTN_SELECT)
Event code 315 (BTN_START)
Event code 316 (BTN_MODE)
Event type 3 (EV_ABS)
Event code 0 (ABS_X)
Value 128
Min 0
Max 255
Flat 15
Event code 1 (ABS_Y)
Value 128
Min 0
Max 255
Flat 15
Event code 2 (ABS_Z)
Value 128
Min 0
Max 255
Flat 15
Event code 5 (ABS_RZ)
Value 128
Min 0
Max 255
Flat 15
Event code 16 (ABS_HAT0X)
Value 0
Min -1
Max 1
Event code 17 (ABS_HAT0Y)
Value 0
Min -1
Max 1
Event type 4 (EV_MSC)
Event code 4 (MSC_SCAN) 

試してみると、ボタンは304～316、で、X-Y-ZとHATが使えるようです。
詳しく調べてみると、このコントローラ、「mode」ボタンで x-yモード、zモード、HATモードが切り替えられるようです。今回は、x-yモードを使います。

アーケードスティックの「１」～「１０」を順に押していき、割り当てを確認します。

すると、「BTN_B,BTN_C,BTN_TR,BTN_TL,BTN_A,BTN_X,BTN_Z,BTN_Y,BTN_SELECT,BTN_START」のように割り当てられていることがわかりました。

これをメガドライブ純正パッドと同じようになるように変換してやればいい、ということです。

では、それをどうやって実現するか。

まず、標準のカーネルでは/dev/input/event4～event13に割り振られる部分のソースコードを変更し、+10して event14～event23に割り当てられるようにします（退避させる）

今のカーネルだと、刺さってるHUBのポートみて本体1,2はevent4,5、本体1に刺さったHUBのポート順に6,7,8,9,本体2のHUBでは10,11,12,13に割り当てられる
話を簡単にするために、一旦裏のOTG経由でつないだやつをフィルタ出来るようにしてみるかな pic.twitter.com/RhQx1Nd5PY

— ひろみつ(honeylab) 技術書典７け36D (@bakueikozo) October 8, 2019

そこで、LinuxのUsermode Input Deviceという機能を使い、イベントコードを変換するプログラムを書きます。

具体的には、以下のようなソースコードです。

bitbucket.org

 このへん

qiita.com

を参考にしています。

このソースコードを、ホスト上でメガドライブミニ用にコンパイルし、メガドライブ上にコピーします。

iBuffaloのアーケードスティックをメガドライブに接続すると

[50270.421860] generic-usb 0003:1DD8:000E.0007: usb_submit_urb(ctrl) failed: -1
[50270.429714] generic-usb 0003:1DD8:000E.0007: timeout initializing reports
[50270.437645] input: BSGPAC02 Series as /devices/platform/sunxi-ehci.1/usb1/1-1/1-1.2/1-1.2:1.0/input/input14
[50270.449359] generic-usb 0003:1DD8:000E.0007: input,hidraw0: USB HID v1.10 Gamepad [BSGPAC02 Series] on usb-sunxi-ehci-1.2/input0

という表示が現れ、

# ./evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: axp22-supplyer
/dev/input/event1: sunxi-keyboard
/dev/input/event2: gpio-keys
/dev/input/event3: sunxi-ths
/dev/input/event14: BSGPAC02 Series

event14(本体のコントローラポート１に挿したため)が割り当てられました。

先ほどのプログラム(uinput)にこれを引数として渡します。

# ./uinput /dev/input/event14 &
# argv[0]=./uinput
[43017.030912] input: evfrom23 as /devices/virtual/input/input36
argv[1]=/dev/input/event14 

 すると、/devices/virtual/input/input36という仮想inputデバイスが作成され、プログラムで変換した値が送信されるようになります。

この時作成された仮想inputデバイスは、たまたまうまいことevent4に再マップされました。（udevルールを書くことで確実になるはずです）

# ./evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: axp22-supplyer
/dev/input/event1: sunxi-keyboard
/dev/input/event2: gpio-keys
/dev/input/event3: sunxi-ths
/dev/input/event4: evfrom23

 この状態で、内蔵謹製エミュレータを起動すると、見事iBuffaloのアケコンを認識し、操作ができるようになりました！！！！

ここまで、手作業で実行して確認しているので、この一連の流れをスタートアップスクリプトとしてrootfsに書いてやれば、自動的にアーケードスティックを認識できるようになるはずです。

また、今回変換テーブルを作らず直接変換してしまっています。
そうではなく、接続されたコントローラのVIDなどを見て、適切なマップを追加することで別のコントローラも使用できるようになります。
専用の設定ファイルでも作ってやると後々追加出来て便利なんですかね。

加えて、現在のところ、本体にはんだ付けしたシリアルコンソールを利用しないで、
カーネルを書き換える仕組みがまだ整備されていません。
おそらく海外のproject LUNARやhakchiチームがそのあたりを実装したら、
そのコードを利用することで、本体を（物理的に）無改造でこのような動作をさせられるようになるはずです。しかし、保証は外れそうなので、その辺気になる方は、最初に出てきた変換アダプタを使うのがいいんでしょうね…

さて、この方法でメガドライブミニをプレイしている証拠映像がこちらです。

メガドラミニにアーケードスティックをつなぐデモ

デモ撮影中とはいえゲームへたくそすぎんだろ…
まぁ、波動拳出てるんで、ちゃんと動いてるんだと思いますよ。

見た目ではわかりませんが、基板乗っ取りやArduinoなどの変換アダプタは使用していません。
メガドライブミニに直接コントローラのケーブルを挿しているだけです。

遅延など、測定はしていないのですが、本当に必要になったらどうにか測定してみたいと思います。
外付けUSBデバイスで変換するよりは理論上早いはずなんですがね…

メガドライブミニ(Genesis Mini)の前面イヤホン端子とボリュームつまみを使えるようにしました！

メガドライブミニ、精巧なモデリングが評判でしたが、
どうしても再現できなかったと思われる前面イヤホン端子。

それを恒例の魔改造で使えるようにしました！

メガドライブオリジナルには3.5mmのイヤホンジャックがついていましたが、
同じものをつけると明らかにでかすぎたので、ちゃんとミニ化して2.5mmのをつけてます。

なので、普通のヘッドホンを繋ぐには変換ケーブルが必要です。

また、技術的な都合もあり、なんと元のメガドライブに使用されていたのと
同じアナログオーディオICを使うというひとネタもあり。

もっと詳細な作成技術情報はこちら

https://www.slideshare.net/ssuserb6da59/ss-179366684

簡単に言うと、CPUからHDMIに送られる途中のデジタル音声信号を分岐し、
アナログ変換して、

メガドラミニのボリューム機構、可変抵抗とツマミの加工取り付けができた！
上は回路でどうにでもなるんだけど、下がきっちりゼロまで下がるように付けられるか不安だったがどうにかなったぞ

あとはアンプ基板とジャック加工！ pic.twitter.com/zrXJz1NThW

— ひろみつ(honeylab) 技術書典７け36D (@bakueikozo) October 3, 2019

ボリュームつまみの信号で音量も調節して、

ヘッドホン端子のところに穴を開けて
めちゃ配線して

こうじゃ！！

youtu.be

どや。

「３日でできたメガドライブミニ 徹底解析・ハック 最速本」をBOOTHに出品しました。

技術書典当日の深夜まで原稿を書いてコンビニで印刷してみたものの、
一人じゃせいぜい５０部つくるのが限界でした。
大変ありがたいことに技術書典に持ち込んだ分は完売いたしました…

現地でお届けできなかった方・遠方の方に向けてデジタル版をBOOTHに出品しました。

honeylab.booth.pm

もし現地で物理本をお買い上げいただいた方には別途URLをご案内出来ますので、

hiromitu2120@gmail.com もしくは Twitter @bakueikozo　へDMいただければと思います。（現地でほかの頒布物をお買い上げいただいている方は、そちらに記載されているURLと同一です。）

尚、この本を増補する形で「完全版」を今後執筆する予定です。
今のところこちらをお買い上げいただいた方でも、差額での提供などは難しいです。

本誌のお買い上げは、今後の「完全版」への応援として受け止めさせていただきます。
そのほかの頒布物も順次BOOTH,通販委託などを行っていきますので随時お知らせいたします。

メガドライブミニ (Genesis Mini) をハックする（２）特定のUSBデバイスしか使えない縛り

※検索でたどり着いた方へ※

このページには技術的情報がまとめてあります。

 市販のゲームコントローラをメガドライブミニで使用するには
こちらのコンバータを使用するのが最もかんたんで確実です。 

【MDミニ用】スーパーコンバーター（PS4/PS3用コントローラ対応） - メガドライブミニ

あと数時間でメガドラミニが到着するはずですが、その前に昨日セガから公開されたOSSソースコードをもとにハックの準備をしていきます。

https://sega.jp/mdmini/doc/mdmini-oss/

前情報で、どうやら付属の純正パッド以外のコントローラが認識しないという話が聞こえていました。また、マルチタップ代わりのUSBハブも専用品番でないと使えない、とのことです。

https://game.watch.impress.co.jp/docs/news/1185012.html

おそらく動作保証とかいろいろ理由はあるのでしょうが、既存のハードウェアリソースが使えないのはちょっともったいないですよね。

では、公開されたLinuxのソースコードをあさっていきます。

USBドライバ周りのはずですので drivers/usbあたりを探してみます。

すると、hub/core.cに不思議な文字列を発見しました。

 

#ifdef CONFIG_USB_SPECIAL_DEVICE

#define SPECIAL_USB_DEVICE(ven, prod) \

    .idVendor = (ven), \

    .idProduct = (prod)

struct device_id {

    __le16 idVendor;

    __le16 idProduct;

};

static const struct device_id special_id_list[] = {

    { SPECIAL_USB_DEVICE(0x14cd, 0x8601) },

    { SPECIAL_USB_DEVICE(0x0ca3, 0x24) },

    { SPECIAL_USB_DEVICE(0x0ca3, 0x25) },

    { SPECIAL_USB_DEVICE(0x0bda, 0x5411) },

    { SPECIAL_USB_DEVICE(0x05e3, 0x0608) },

    { SPECIAL_USB_DEVICE(0x2109, 0x2817) },

    { SPECIAL_USB_DEVICE(0x1a40, 0x0101) },

    { SPECIAL_USB_DEVICE(0x1dd8, 0x000f) },

    { SPECIAL_USB_DEVICE(0x1dd8, 0x000b) },

    { SPECIAL_USB_DEVICE(0x0079, 0x0011) },

    {}

};

#endif

また、関連するKConfigには

config USB_SPECIAL_DEVICE bool

"Only Support special devices" depends on USB

default n help if you say Y here,then only support special device!!!

という項目と、hub.cに以下のような定義がありました。

#ifdef CONFIG_USB_SPECIAL_DEVICE

    if(special_match_id(udev, special_id_list)) {

        if (retval >= 0)

            retval = -EINVAL;

        goto fail;

    }

#endif

どうやらここに指定していないUSBデバイスは

認識時に振り落とされるようです。

では、ここで指定されているVID/PIDが何の製品なのか確認してみましょう。

VID	Vendor Name	PID	Product Name
14CD	Super Top	8601	4-Port hub
0CA3	Sega Corp.	0024	同梱Pad ?
0C3A	Sega Corp.	0025	同梱Pad ?
0BDA	Realtek Semiconductor Corp.	5411	おそらくUSBHUB
05E3	Genesys Logic, Inc	0608	USB HUB
2109	VIA Labs, Inc.	2817	おそらくUSBHUB
1A40	Terminus Technology Inc.	0101	USB HUB
1DD8	BUFFALO	000f	BSGP1204
1DD8	BUFFALO	000b	BSGP1601
0079	DragonRise Inc	0011	GamePad

 

というリストができました。

公開されている情報と同じ…ように見えますが、見慣れない「DragonRise」というゲームパッドが見えています。
drivers/hid/inputあたりを確認すると、なぜか0C3A:0024や0025の製品が、このDragonRiseというゲームパッドのドライバ内でハンドルされています。

また、configでDragonRiseを有効にした時に同梱Padも認識されるようになっています。もしかすると、これが実質標準のゲームパッドハンドラで、そこに挿入する形で同梱のドライバをハンドルさせるようにしたのかもしれません。

 

さて、このあたりが事前に情報の出ていた「特定のHUBやゲームパッドしか認識できない」という挙動の原理のようです。

この辺を修正するか、デバイス側で調整してやれば認識するようになるかもしれませんね。

（カーネル再コンパイル＆書き込みが必要なのでまだまだ先の話になると思います）

 

メガドライブミニ (Genesis Mini) をハックする（１）

動画とか、discordとかに流れてきたゲーム機レビュアー？の人の画像を見てハックの準備を進めています。っていうかずいぶんわかったぞ。

もう準備、っていうよりハックの実作業といっても過言じゃないだろ。

メガドライブミニの基板を見ると、ファミコンミニとかのR16が乗ってる基板のレイアウトと部品の並びは同じで、引き出されてるペリフェラルの並びが同じようにしか見えない。発振子の出てる位置も、USBの引き出し位置も一緒。
メーカが同じで、シリーズが近ければ大体似たようなピン配置になることから考えて、R16/A33系統、もしかしたらちょっと上位ぐらいのSoCが乗っていて、ピンアサインはほぼ互換っていうか一緒なんじゃないか。

リセット＋USB挿入でFELモードに入るところまでは確認されてるらしいけど、本体を手元に持っている人はそれ以上詳しくなくてわからないらしい。

sunxi-toolsで soc idがなんて出るかが気になる。

もしも違うidが出たとしたら、

https://github.com/linux-sunxi/sunxi-tools/blob/master/soc_info.c

ここに適当に互換しそうなやつを追加して試してみればいいんだよね？
コンパイルの準備をしておこう。

 そして、ファミコンミニのu-boot/kernelでは、UART0がPortFに割り当てられてたんだけど、これはコンパイルオプションでPortBにも割り当てられる。っていうか、そうじゃないとSDカードポートと競合する。今回SDカードポートは出てないようで、
基板をひっくり返してみたところ、仮にR16と同じピンアサインだったらまさにジャストの位置からPB0/PB1(UART0 TX/RX)がテストパッドに引き出されてる。

メガドラミニ、UART出てる確信。ファミコンミニと同じレベルのAllWinnerだとして、ピン配置も大体同じだと思う。USB0,USB1,NAND,RAMみんな同じ方向。

ファミコンミニのSoCR16(A33)のピンアサイン。
囲んだところがPB0,PB1でUART pic.twitter.com/C7lEQJT5VW

— ひろみつ(honeylab) (@bakueikozo) September 5, 2019

もう間違いなくこれがUARTピンだと思う。

SoC周りにあと２本パッドがあるけど、まだそこはわかってない。もしかしたらデバッグトリガがあったりなかったりして。

というわけで、届いて速攻でNANDを引っぺがす前に、UARTを探すっていう作業はたぶん済んだ状態まで来た。

あと２週間も待つの…？？？？

I saw this movie and get some pictures from friends.

www.youtube.com

A snapshot from the Movie tell me many many information to prepare hacking.

SoC(System On chip) like as a CPU is Z7213 from "ZUIKI" but is is seems to be having Allwinner's core.

http://www.zuiki.co.jp/products/z7213/

 

This PCB's artwork is close to NESC/SNESC 's PCB layout.
I think Z7213 has upper compatible to R16/A33 Soc from AllWinner.

Because .....

This table is pinout of R16.

 Right Bottom has X'tal in/out,Right Top has USB0/USB1 Pattern.
Bottom Center has RAM's wire,and Left Side has NAND wires.
There is no contradiction.

I believe each SoC has compatiblilty core but not only pin-out.

And this picture is of other side of Genesis Mini's pcb around SoC.

https://linux-sunxi.org/Nintendo_NES_Classic_Edition

PB0/PB1 is UART for the "mainline u-boot" default UART0 pins.
Or "legacy u-boot" can use this pins for UART0 with configuration.

I see PB0 and PB1 wires are taken out to TEST PAD.
I can use UART console without doubt with soldering when the console will arrived.
If the stock kernel will not accept console login or hack,but SEGA must be show the source-code of u-boot and Linux Kernel.
I can compile them with enabling UART access and run new u-boot from USB FEL mode.