2000年頃のPlayStation(以下PS)1エミュレータは高速化のためにデバイスの時間的な挙動の変化を全く再現しない構造を採っていた．そのままではジリ貧になることが明らかだったが筆者自身は一介の材料屋に過ぎない上に自由時間もあまり取れない年齢となっていたため若い優秀な開発者に時間的な再現の重要性を啓蒙しようと考えた．しかし筆者の実績は乏しく説得力に欠けたため時間的な再現の重要性を具体的な事例で示す必要があると考えた．そのための実証試験プログラムとして，このエミゅってしまうま(以下XEBRA)は誕生した．残念ながら時間的な再現の全てを厳密に処理するには現在のPCであっても能力不足であるため一部は概算による再現(シミュレーション)に留まらざるを得なくなっている．そのため概算の設定を最適化しないとフリーズしてしまうゲームが存在するが，その代り設定を最適化してもフリーズを回避できないゲームはほぼ存在しない．全てのゲームを検証出来ないから断言しないだけで，そのようなゲームは存在しないと思っている．もしそのようなゲームが存在する場合は是非とも報告してもらいたいのだが，これまでにあった報告のほとんどは設定を最適化していないだけだったという苦い経験があるため動画投稿サイトに検証動画を上げる形でお願いする．
大容量の内蔵ストレージやフラッシュメモリストレージの普及により既に光学ドライブを常設した環境の方が少数派になっている様に思う．XEBRAにはゲームディスク(CD-ROM)を直接扱う機能もあるが，ここではイメージファイル化したもののみを扱うこととする．CD-ROMイメージファイルの形式は事実上 (1)img+sub+ccd(+cue)ファイル (2)bin+cueファイル (3)isoファイル の3つに集約される．無圧縮で不分割であればメインチャネルデータである (1)のimgファイル (2)のbinファイル (3)のisoファイル はいずれも同じもの(拡張子を変えただけ)となり，いずれもXEBRAで扱えるのだが，ほとんど使われないとは言え(2)(3)はサブチャネルデータの多くを捨てており(3)に至っては複数トラックにも対応出来ないためXEBRAでの扱い如何を問わず(1)を推奨する．特にcueファイル付きの(1)は最も潰しが効く．
以降の説明の中ではXEBRA.EXEが存在するフォルダ内に特定のファイルを置くと言った話が出てくる予定である．そのようなフォルダをここではベースフォルダと呼ぶことにする．
本文における現在とは，後書きに記載された日とする．
XEBRA.EXEをダブルクリックする．
XEBRAを起動せず直接アイコンにドロップしても良い．ドロップするのはimg,bin,isoファイルなどのメインチャネルデータのファイル(要は一番大きなファイルと思えば良い)である．ccd,cueファイルなどのサブチャネルデータのファイルはメインチャネルデータのファイル名から拡張子のみを変えたファイル名である場合に自動で読み込むようになっている．自動でMode 1での実行状態になるから後はそのまま待てば良いが当然ながら実機と同程度の起動時間が掛かるから適宜F4キーを押して同期／非同期を切り替えると良い．
初期状態においてキーとPS1コントローラの入力は以下のように関連付けられている．
PS1エミュレータ界隈の方言でBIOSと呼ばれることが多いが例えばPSPのシステムソフトウェアをBIOSとは呼ばないようにBIOSよりも上位層のプログラムが多く含まれているためSony Computer Entertainment社(以下SCE，現社名はSony Interactive Entertainment Inc.)自身はネットやろうぜのドキュメントの中でOSと呼び，それが格納されたROMをOS ROMと呼んでいる．現在ならばファームウェアという便利な呼称が普及しているがXEBRAでは当時の呼称を使用する．公式のOS ROMイメージはSCEの著作物でありSCEが配布しているわけではないからゲームディスク同様に(団体名義だから)公開後50年(で2045.01.01のはずだったんだが，おそらくTPP11により70年まで延長で2065.01.01)まで待つかユーザ自身が実機から抽出しなければならない．そのための機器の入手は現在では困難なものとなっている．XEBRAには独自のOS ROMイメージが内蔵されているから現時点で抽出していない場合は諦めた方が賢明であり，ここで抽出方法の解説はしない．しかし内蔵と公式に100%の互換性は無いから既に抽出しているのであれば積極的にそちらを使うべきである．
OS ROMイメージファイルを使用するには，メニューの File / Open / OS ROM Image… をクリックし
抽出したOS ROMイメージファイルを選択すれば良い．XEBRA終了時にはベースフォルダ内にOSROMというファイル名で保存され次回起動時には自動で読み込まれる．つまりXEBRA起動前であれば抽出したOS ROMイメージファイルのファイル名をOSROMにして直接ベースフォルダ内に置いても良い．
軸の精度が高いゲームパッドでは変換係数の変更も必要になる．良く分からない人には宝の持ち腐れなので安価なゲームパッドに買い替えた方が幸せである．
ちなみに2017年に日本で急増したと言われるXBOX 360互換(要はスイッチ用)コントローラの有線設定だと以下の様になるはずである．
改造コードを使うにはCD-ROMイメージのファイル名から拡張子だけarに変えたテキストファイルを用意し，そこにコードを書き込んでおけば良い．そうするとCD-ROMイメージファイルを読み込む時に自動で読み込まれる．なお特殊過ぎるコードやcaetlaコードには対応していない．もちろん全角文字にも対応していない．
ゲーム毎にシミュレーション設定を変えるにはCD-ROMイメージのファイル名から拡張子だけsimに変えたシミュレーションモデルイメージファイルを用意すれば良い．そうするとCD-ROMイメージファイルを読み込む時に自動で読み込まれる．
ゲーム毎に初期設定を変えるにはCD-ROMイメージのファイル名から拡張子だけiniに変えた初期設定ファイルを用意すれば良い．そうするとCD-ROMイメージファイルを読み込む時に自動で読み込まれる．
多言語化するにはベースフォルダ内に対応したXEBRA.LNGファイルを置けば良い．単純なテキストファイルなので各自で好きな言語に書き換えれば良い．
冒頭で述べている様に全ての時間的な再現を厳密にやると現在のPCでも重過ぎるから一部をシミュレーションで再現している．前面に出していないだけで他のエミュレータも分解能の異なるシミュレーションや何もしないという究極のシミュレーションをしている．だから各種パーツの処理にかかる時間が現実と異なっており，本来パーツAよりもパーツBの方が先に終了しているはずなのにパーツAの方が先になることがある．そうするとパーツBの方が先であることが前提のプログラムがあった場合に破綻してフリーズする．経験的にパーツのどちらかがCPUであるケースが殆どである．だからCPUを速く動かしたり遅く動かしたりすることでフリーズを回避できるケースが殆どである．その設定項目がXEBRAではI Cache Rateであり，他ではCPU Overclockingと呼ばれたりするものである．
そもそも電子デバイスであるパーツの動作速度が変化することに疑問を持つかもしれないが実際にそうなのだから仕方がない．主要因はメインメモリで発生する渋滞である．各パーツは独立して動く様に見えるが，結局メインメモリには一度に1パーツしかアクセスできないので，タイミングが悪いと渋滞する．というかCPUのキャッシュ容量が少なく一般的なデータキャッシュも無いから頻繁にアクセスするので結構な頻度でタイミングが悪い．本来ならば瞬間瞬間での渋滞状況を正確に再現したいところだが計算量が多すぎるから，「平均的にこの程度の渋滞をするから，この程度まで遅くなるだろう」って感じの想定をして再現することになる．苦労して渋滞を回避するよう調整したゲームにとって，その想定は遅すぎるだろうし，逆に頻繁な渋滞を前提にしたゲームにとって，その想定でも速すぎるだろう．CPUとGPUの場合はそれに加えてローカルキャッシュの影響も著しい．既にキャッシュに取り込まれている場合とそうでない場合との速度差が激しいのだが，取り込まれているかどうかを厳密に判定すると計算量が多すぎるから，「平均的にはこの程度の確率で取り込まれているから，この程度まで遅くなるだろう」って感じの想定をして再現することになる．苦労してキャッシュ内に収まるよう設計したゲームにとって，その想定は遅すぎるだろうし，逆にそういった設計をしていないゲームにとって，その想定は速すぎるだろう．
このページを必要とする人にシミュレーション設定の各項目の意味を説明しても理解できるとは思えないので，ここでは具体的な操作手順を説明する．
①フリーズする直前で実行を停止する
②F1キーを押してどこでもセーブをする
③メニューの File / Save / Simulation Image... をクリックしベースとなるシミュレーション設定を保存する
④メニューの Run / Power(1) をクリックして実行を再開する
①メニューの Run / Simulate / I Cache Rate / から適当な値を選択する
②F7キーを押してどこでもロードしフリーズ前の状態に戻す
③フリーズを回避できなかったら①に戻って選択したことの無い値を選択する
以後繰り返し
要はI Cache Rateの値を全て(少なくとも10,20,24を)試す訳だが必ずフリーズ前の状態に戻して実行し直す．
第1段階でどうにもならなかった場合
①メニューの File / Open / Simulation Image... をクリックし準備段階で保存したシミュレーション設定を指定する
②メニューの Run / Simulate / I Cache Size / から適当な値を選択する
③F7キーを押してどこでもロードしフリーズ前の状態に戻す
④フリーズを回避できなかったら②に戻って選択したことの無い値を選択する
以後繰り返し
要はI Cache Sizeの値を全て(少なくとも0を)試す訳だが必ずフリーズ前の状態に戻して実行し直す．
第2段階でどうにもならなかった場合
①メニューの File / Open / Simulation Image... をクリックし準備段階で保存したシミュレーション設定を指定する
②メニューの Run / Simulate / Paint Rate / から適当な値を選択する
③F7キーを押してどこでもロードしフリーズ前の状態に戻す
④フリーズを回避できなかったら②に戻って選択したことの無い値を選択する
以後繰り返し
要はPaint Rateの値を全て(少なくとも20,40を)試す訳だが必ずフリーズ前の状態に戻して実行し直す．
ここまで説明すれば後は分かると思うがXXXX=Image Rate,Seek Mode,Seek Rateとしたとき
①メニューの File / Open / Simulation Image... をクリックし準備段階で保存したシミュレーション設定を指定する
②メニューの Run / Simulate / XXXX / から適当な値を選択する
③F7キーを押してどこでもロードしフリーズ前の状態に戻す
④フリーズを回避できなかったら②に戻って選択したことの無い値を選択する
以後繰り返し
要はXXXXの値を全て試す訳だが必ずフリーズ前の状態に戻して実行し直す．
①SIM.EXEを用いて各項目から適当な値を選択しシミュレーション設定を保存する
②メニューの File / Open / Simlation Image... をクリックし①で保存したファイルを選択する
③F7キーを押してどこでもロードしフリーズ前の状態に戻す
④フリーズを回避できなかったら①に戻って選択したことの無い値を選択しシミュレーション設定を保存する
以後繰り返し
必ずフリーズ前の状態に戻して実行し直す．
現在のXEBRAには5つの実行モードが存在する．メニューの Run / Run / Mode ? で実行モードを変更出来る．頻繁に使うであろうMode 1,Mode 2についてはそれぞれ Run / Power(1) , Run / Power(2) という浅い階層のメニューも用意している.
各モードの特徴を述べるに当たり事前に説明を要すると思われるのでしておく．CPUエミュレーションを大別するものとして，インタプリタか動的なコンパイラかの違いがある(バイナリ変換の方が正確かもしれないが，インタプリタの対としての通り良さからコンパイラとする)．インタプリタは命令を逐次解読し，実行する．そして結果的に命令は直ぐに忘れる．コンパイラはある程度の命令をまとめて解読し，母国語に変換して貯蔵し，実行する．そして貯蔵したものは，ある程度忘れない．一回のみの実行だと手間が多い分コンパイラの方が遅いのだが，貯蔵したものが再利用されるに従ってコンパイラの方が速くなる．一般論としてコンパイラの方が結構速いという評価だし，XEBRAの実績でもそう思う．
問題になるのはメインメモリとの一貫性が無い命令キャッシュシステムの再現である．具体的には命令を書き換えても直ぐには反映されず，書き換える前の命令が実行される「場合がある」という現象の再現である．「常に」ではなく「場合がある」というのが非常に厄介なところで，コンパイラではその辺の再現が難しい．XEBRAでは仮想的なキャッシュサイズというかブロック長を設定することで，どうにか疑似的に再現しているが，他のエミュレータは結局重いインタプリタにするか再現を諦めている．少なくとも筆者の目からはSONY自身が諦めているように見える．
コンパイラだから速いが一貫性が無いことの再現に不安がある．手抜きをする分速いが当然ながら再現性は多少劣る．
インタプリタだから遅いが一貫性が無いことの再現は正確である．
インタプリタで遅いくせに一貫性が無いことの再現もしていない．裏を返せば常に一貫性があるわけで，一貫性がないことの再現に万が一誤りがあった場合の検証のために存在する．
インタプリタだから遅いが一貫性が無いことの再現は正確である．CPU単独で見れば最も実機に近いのだが，他の部分の精度が不十分な中で一部の精度だけ上げても逆効果である事が多く，調整も難しくなっている様に思う．
特に拘りが無い場合はMode 1(メニューの Run / Power(1) )で実行すれば良い．
「非力なPCなので，再現性には多少目を瞑っても良いから，もう少し軽い方が良い」という場合はMode 2(メニューの Run / Power(2) ) で実行すれば良い．ちなみにAndroid版は初期値がMode 2になっている．
「パワーに余裕があるから，もっと重くても大丈夫」という場合はMode 5(メニューの Run / Run / Mode 5 )で実行すれば良い．
そのうち詳細を書くだろう．
内蔵機能だけで高画質化する場合はメニューの View / Video Output をクリックして設定ダイアログを出し，Use OpenGLとDraw with OpenGLの両方にチェックを入れる．起動時や実行中に一度でも外部のGPUプラグインを使用した場合は念のためXEBRAを再起動する．不具合が多く見えるだろうが，PS1のGPUの特殊性をOpenGL v1.1の純粋なハードウェア描画だけで表現すると，この辺りが限界である．外部のGPUプラグインの様にソフトウェアで補完してまで深入りする予定は無い．
PSEmuPro 1.0仕様のGPUプラグインを使う場合，プラグインをVIDEO.DLLにリネームしてベースフォルダにおいて置く．メニューの View / Video Output をクリックして設定ダイアログを出し，Use OpenGLのチェックを外し，Use VIDEO.DLLのチェックを入れる．プラグインの設定はプラグイン次第なのでConfigボタンを押して適当に行う．起動時や実行中に一度でもUse OpenGLにチェックが入っていた場合は念のためXEBRAを再起動する．
2015年までだったと思うがXEBRAはUPXというEXE Packerで圧縮を行っていた．当時のマルウェアが頻繁にUPXを利用したため，その煽りを受けUPX圧縮したものは一律でアンチウィルスからトロイ感染を警告されるようになってしまった．甚だ迷惑な話ではあるが，リアルタイムスキャンを更に遅くしてまで対応を求めるほどのことでも無かったため，世界中のフリーウェアがこれを境にUPX圧縮をやめていった．そういった世界的に知られた事情を説明せずに，悪意を持って書かれた糞みたいなWikiが海外に多いので注意されたい．まぁそういったWikiは明らかに特定のソフトに肩入れしており，XEBRA意外の内容も糞なんだが．
2018.07.09 独田地獄斎(Dr.Hell)