【狂気・再】2026年、PSPの性能を倍にする。ソニーが隠してた2つ目のCPUの謎を暴く【デュアルコア！？】

訂正（2026-04-05）： 初版で「MEを実用的に活用したホームブリューは20年間現れなかった」と記載しましたが、Snes9xTYL等にMEを活用したビルドが存在した先行事例がありました。お詫びして訂正します。また、LightMP3（MP3デコード）等の先行事例がありました。お詫びして訂正します。

前書き

PSPにはCPUが2つ入ってる。そしてその片方は、20年間開発者が直接触ることは許されていなかった

……いきなり何言ってんだと思うだろう。でも事実だ。ソニーが2004年に設計したTachyon SoCには、メインCPU「Allegrex」（333MHz）のほかに、もう1つ同等性能のCPU「Media Engine」（333MHz）が載っている。合計666MHz。デュアルコアじゃない。物理的に独立した2つのCPUだ。

そしてソニーは、この2つ目のCPUを20年間、公式には開放しなかった。

公式SDKでは直接アクセスできない。公式ゲーム開発者すら触れない。sceMpegやsceAtracといった高レベルAPIの裏で、動画デコードや音声処理のためにこっそり動いていた。「メディアデコード専用プロセッサ」——それがソニーの公式見解だった。

だが実際には、Media EngineはメインCPUとほぼ同一の汎用プロセッサで、任意のコードを実行できる。なぜソニーはこれを開放しなかったのか？ 本当に「メディア専用」だったのか？ それとも、開放できない事情があったのか？

この記事は、その謎を追いながら、実際にMedia Engineを解放してPSPの実効性能を倍にした記録だ。

まだ再生時ノイズがあった時点のXの投稿

第1章：なぜソニーは2つ目のCPUを開放しなかったのか

まず、2つのCPUを比較してみる

謎を追う前に、メインCPUとMedia Engineのスペックを並べてみよう。

【メインCPU（Allegrex）】 ・CPUコア: MIPS R4000 @ 333MHz ・FPU: あり ・VFPU: あり（128bit SIMD） ・専用eDRAM: 2MB（GE用、帯域5.3GB/s） ・メインRAM: 直接アクセス ・動作モード: ユーザー/カーネル

【Media Engine】 ・CPUコア: MIPS R4000 @ 333MHz ・FPU: あり（COP1、32bit単精度） ・VFPU: なし ・専用eDRAM: 2MB（ME用、帯域2.6GB/s） ・メインRAM: 直接アクセス（KSEG0経由） ・動作モード: カーネルのみ

CPUコアは同一。クロックも同一。FPUも搭載。違いは2つ。

1つ目：VFPUがない。 メインCPUにはベクトル演算用のVFPU（128bit SIMD、4×4行列演算を1命令で実行）が載っているが、MEにはない。3Dゲームの座標変換やスキニングには向かないが、スカラー演算中心の処理——たとえばオーディオ合成——には影響しない。

2つ目：カーネルモードでしか動かない。 メインCPUはユーザーモードでアプリケーションを動かせるが、MEはカーネル権限が必須。ここが最大の壁になる。

つまりMedia EngineはメインCPUの完全なコピーではない。VFPUがない分、ベクトル演算では劣る。だがスカラー演算（整数・浮動小数点とも）は完全に同等の333MHzで、さらに専用eDRAM 2MBという武器を持つ。用途を絞れば、メインCPUと同等に戦える。ソニーの「メディアデコード専用」という説明は、ハードウェア設計としては正直だったとも言える。ただし「専用」と「しか使えない」は別の話だ。

では、なぜ開放しなかったのか。いくつかの仮説を立ててみる。

仮説1：セガサターンの亡霊

1994年、セガはサターンにデュアルCPU（SH-2を2基）を搭載した。理論上は倍の性能。しかし現実は違った。サードパーティのほとんどが2つ目のCPUを使いこなせず、片方だけで動くゲームが大量に出た。2つのCPUの同期、メモリの排他制御、デバッグの困難さ——デュアルCPUプログラミングは当時の開発者にとって悪夢だった。

ソニーがこの教訓を知らなかったはずがない。PSPのMedia Engineを汎用開放すれば、同じことが起きかねない。サードパーティが使いこなせない。バグだらけのゲームが出る。サポートコストが爆発する。封印は合理的な判断だったかもしれない。

…もっとも、この教訓をソニー自身がどこまで本気で受け止めていたのかは怪しい。PSPをリリースした翌年、PS3ではSPU 6基を搭載したCell Broadband Engineを世に送り出している。サードパーティは案の定これを使いこなせず、マルチプラットフォームタイトルでは開発効率の高いXbox 360版が優位に立つケースも多かった。
サターンの亡霊は、PS3にも現れたのだ。
※筆者はサターン未経験のため、この仮説は公開情報に基づく推測である。

仮説2：カーネルモードの壁

もう1つ考えられる理由がある。Media Engineはカーネルモードでしか動かない。

PSPのユーザーモードアプリケーションからは直接触れない設計になっている。MEにコードを送るにはカーネル権限が必要で、使い方を間違えるとシステムごとフリーズする。品質管理の観点から考えると、開放しないのは妥当だ。

では、なぜMedia Engineの活用は広がらなかったのか

2005年以降、PSPのカスタムファームウェア（CFW）が登場し、カーネルモードの壁は崩壊した。Snes9xTYL（サウンドエミュレーション）やLightMP3（MP3デコード）など、MEをオーディオ処理にオフロードした先行事例は存在する。しかしME活用はこれらの少数の例に留まり、広がりを見せなかった。

・2005年：crazycがMEのカウンターサンプルを公開。「動いた」と報告。
・2006年：Snes9xTYLがMEでサウンドエミュレーションをオフロード。
・2012年：VitaフォーラムでME活用の議論。新規実装には至らず。
・2025年：mcidclanがTiny-MEライブラリを公開。サンプルコードのみ。

俺はこの系譜に、FM音源リアルタイム合成という新しい用途を加えた。

第2章：なぜMedia Engineが必要になったか

PC → PS3 → PSP

話は少し遡る。

最初はPC上で、東方旧作のMML（テキスト楽譜）を再生したかっただけだった。WSLでpmdminiというCライブラリをビルドし、ZUNの28年前の.MファイルからFM音源の音を鳴らした。その顛末は前の記事に書いた。

次に「これPS3で鳴らせるんじゃないか」と思った。pmdminiはCライブラリだ。PS3のPSL1GHTツールチェーンでクロスコンパイルできる。実際にやったら動いた。PPU（3.2GHz）の10-13%程度のCPU負荷で余裕だった。cellGcmで1080pビジュアライザも載せて、46曲のPMDファイルとMIDI 58曲とSoundFont（TimGM6mb）を全部埋め込んで、PKGサイズ6.7MBに収めた。

あっさり動きすぎて記事にならなかった。地雷もない、最適化の苦労もない、ドラマがない。3.2GHzの暴力で全部解決した。

そして3段目。「PSPでも動くんじゃないか」。

そう思った。pmdminiはCライブラリだ。PSPのツールチェーンでクロスコンパイルできる。cellAudioの代わりにsceAudioを使えばいい。構造はシンプル——のはずだった。

333MHzの壁

PSPのメインCPU（Allegrex）は333MHz。PS3のPPUは3.2GHz。約10倍の差。

pmdminiの中核であるfmgenは、FM合成にfloat演算を多用する。4オペレータ×6チャンネル＋SSG3チャンネル＋リズム6パート、これをサンプルレート44100Hzで毎秒合成する。PS3のPPUなら鼻歌まじりだが、PSPの333MHzでは全く間に合わない。

実際にビルドして動かしたら、スロー再生になった。再生速度の半分以下。FM合成がリアルタイムに追いつかない。

選択肢は3つ：

1. 諦める

2. 合成品質を落とす

3. 2つ目のCPUを動かす

俺は3を選んだ。

第3章：Media Engine起動——壁と突破

障壁1：カーネルPRXロード拒否

Media Engineにコードを送るには、カーネルモジュール（PRX）が必要だ。mcidclanのTiny-MEライブラリに含まれるkcall.prx（2.2KB）がそのブリッジ役になる。

問題は、PSP-1000（6.60 PRO-B10）でカーネルPRXのロードが拒否されることだった。

sceKernelLoadModule("kcall.prx") → 0x800200D9（ロード拒否） pspSdkLoadStartModule("kcall.prx") → 同じく拒否

自前のカーネルPRXも、Tiny-MEのkcall.prxも、すべて弾かれる。CFWのセキュリティポリシーがカーネルモジュールの動的ロードを制限しているのだ。

突破：seplugin方式

解法はシンプルだった。動的にロードするのではなく、PSP起動時にCFWに事前ロードさせる。

ms0:/seplugins/kcall.prx ← Tiny-MEのカーネルブリッジPRX ms0:/seplugins/game.txt ← "ms0:/seplugins/kcall.prx 1"

PSPの電源を入れた瞬間、CFWがsepluginとしてkcall.prxをカーネルモードで読み込む。アプリ側のPRXロード処理は完全にスキップ。アプリケーションからは、既にメモリ上にあるkcallの関数を呼ぶだけ。

これでMedia Engineへの扉が開いた。

障壁2：MEが動いてるか確認できない

Media Engineにコードを送っても、動いているかどうかがわからない。printf? MEからは標準出力に書けない。画面？ MEからはsceGuにアクセスできない。

解法： ・メモリースティックにデバッグログを出力（sceIoOpen/Write/Close） ・HUDに「ME:ON」「eDRAM:ON」をリアルタイム表示

地味だが、これがないとMEのデバッグは不可能だった。

第4章：地雷原——6つの罠と6つの解法

Media Engineは動いた。だが、ここからが本当の地獄だった。

地雷1：pspaudiolibのコールバックスレッドがCPU独占

最初に使ったpspaudiolibのオーディオコールバックは、デフォルトで最高優先度で動く。FM合成をコールバック内で回すと、メインスレッドが一切CPUを貰えなくなる。画面が固まる。ホームボタンすら効かない。

解法：pspaudiolibを捨て、自前のオーディオスレッドを低優先度で作成。メイン描画スレッドが常にCPUを確保できるようにした。

地雷2：1オクターブ上がる

22050Hzで生成したPCMをsceAudioに流したら、全曲が1オクターブ高く再生された。東方のBGMがキンキンのチップチューンになった。

原因：PSPのsceAudioは44100Hz固定出力。22050Hzで生成したPCMをそのまま流すと、DACが倍速で読み出す。サンプルレートの不一致。

解法：各サンプルを2回複製してアップサンプル。out[i2] = out[i2+1] = src[i]。原始的だがこれで正しいピッチに戻った。

地雷3：音のプツプツ——原因は1つじゃなかった

MEとメインCPUはメインRAMを共有している。MEがレンダリングしたPCMデータをメインCPUが読むには、MEのデータキャッシュ（dcache）をフラッシュしてメインRAMに書き戻す必要がある。

最初は毎レンダリングごとにmeLibDcacheWritebackInvalidateAll()を呼んでいた。dcache全フラッシュ。これがプツプツの原因の1つだった。全フラッシュはコストが高く、スパイクが発生する。

解法：通常レンダリング時は出力バッファのみ部分フラッシュ。曲切替時のみ全フラッシュ。ME_CMD_FLUSHコマンドを追加して処理を分離した。

ただし、プチプチの根本原因はこれだけではなかった。本当の構造的原因が判明するのは、もっと後の話だ（第5章で詳述する）。

地雷4：曲切替で音が崩壊する

曲を切り替えると、前の曲の残骸が混ざって音が崩壊する。

原因：MEのL1データキャッシュにpmdminiの内部ステートがdirty（書き戻し前）で残留。メインCPU側で新曲をロードした後、MEがdirtyキャッシュを書き戻し、新しいステートを上書きしてしまう。

解法：曲切替時の手順を厳密に制御。①MEのdcache全書き戻し→②新曲ロード→③キャッシュ無効化。順序を間違えると崩壊する。マルチプロセッサのキャッシュコヒーレンシ問題そのものだ。

地雷5：OPN_FIDELITY_MAXがデフォルトで重すぎる

ymfm（FM合成エンジン）のデフォルト設定はOPN_FIDELITY_MAX。これはchip_rateをclock/8 = 998,400Hzに設定する。1出力サンプルあたり約90回のgenerate()呼び出し。333MHzのCPUには重すぎる。

解法：OPN_FIDELITY_MINに変更。chip_rate = clock/48 = 166,400Hz。1出力サンプルあたり約15回。設定1行変更で6倍速。これが最大の最適化だった。音質の劣化は実用上許容範囲。

地雷6：メインCPUだけではそもそも間に合わない

上の最適化を全部やっても、メインCPU単体ではリアルタイム合成に届かない。描画とパッド入力とオーディオ出力を同時に回すと、CPU時間が足りない。

解法：Media Engineにオフロード。これが本丸。FM合成の全処理をMEに移し、メインCPUは描画とオーディオ出力に専念する。

第5章：デュアルCPU協調運転——8段階の最適化

PS3のPPU 3.2GHzでは一切必要なかった最適化を、PSPでは8つ重ねてようやく完全なリアルタイムを達成した。