まず、このページは攻略記事ではありません。
　ブレス２にはまだ未解明、解明不十分な「謎」・「仕様」があります。それらについて調査された経過・結果をまとめたページです。
　こちらは「解決編」。「提起編」で挙げた謎について分かったことを記載するページです。副産物的な調査結果が出てきたら、それもまとめて記載しています。当ページの攻略記事に関する事柄で、記事を修正すべき点が見つかった場合は該当記事も修正・追記します。調査の途中でも、進展があれば順次記載・追記されていきます。目標は、いつか全ての項目に「解決済み」マークを付けること！
　・・・なんか調査経過文がめちゃ長くなっているので、解決した謎の答えだけまとめた「解答編」ページを用意しました・・・

注意！！
　以下の記事の内容は、ＳＦＣ版ブレス２の仕様という前提の元に記載しています。主に内部データを含む非公開仕様を調査した結果のまとめとなっており、その性格上、文中には改造および解析ツール・エミュレーター・チートコードに関する記述、およびこれらのツールを使用した上での記述がものすごく多くなっています。これらについて良い感情を持っていない方、苦手意識がある方はこれ以降の文を読むのをやめることをお勧めします。
　主な使用ツール：SNES9X、LSNES、SNES 65816逆アセンブラ、FavBinEdit（バイナリエディタ）

情報提供者に感謝！！：匿名希望ＴＴさん
 

「乱数」について・・・ほぼ解決済み！
　ブレス２の乱数の仕様について分かったことを記す欄です。
　ただ、もし乱数ジェネレータが間違っているとしたら、現在の結果表はすべて無駄になる。新たに作り直すしかない。計算式が簡単に推測できるとは思えないので、乱数の実数を１０万フレームほど集めてテキスト出力してしまう力業が一番早いのではなかろうか。１０万フレーム＝乱数１０万個以上もあればさすがに乱数周期は１周しているだろう。
　１０万フレーム分もの乱数を手作業で回収なんてできないので、出力のためにはエミュレータとlua言語の精通が必要になりそう。誰か作ってくれないかｏｒ教えてくれないか・・・

（2020.5.12追記）
　電源投入時から数字がバラバラに動くアドレスは２バイト分見つけた。こちらはタイトルロゴの前の「カプコン」ロゴ表示中、始める旅の記録を選択する画面、およびゲーム内各所で暗転してキー入力を受け付けないところ（マップ切り替え、戦闘突入＆終了などなど）で動きが止まる。
　さらに０〜２５５まで１フレームごとに１カウント進む場所も１バイト分見つけた。これは上記の変化ストップ箇所でも変わらず動き続け、２５５の次は０に戻る。
　ここらが乱数の肝だとしたら、何か分かるかも・・・と思ったのだが、現在挙げられている計算式に代入しても期待した結果は返ってこない。おそらく乱数ジェネレータが間違っているのだろう。逆アセンブルできる人が行なって、ルーチンが分かればいいのだが・・・　とりあえず怪しい箇所をチートコードで一定値（０とか１とか６５５３５［２５５・２５５］とか）に固定した上でプレイしたら何か分かるだろうか？

（2020.6.25追記）
　乱数かもしれないアドレスは２つ・・・７Ｅ００Ｄ６・７Ｅ００Ｄ７（２バイトとすると０７側が上位、０６が下位になる）。タイマーっぽい何か・・・７Ｅ００９１（周期は０〜２５５：フレーム）
　初期値？　乱数かもしれないアドレス・・・７Ｅ００Ｄ６・７Ｅ００Ｄ７：ともに１５（１６進数で０Ｆ）、おそらくタイマー・・・７Ｅ００９１：０。タイマー変数は、乱数変数よりも回っている期間は長いが常に回っているわけではない（暗転部分：ラグ時間では動かない）。詳しく書くと、エミュレータでラグカウンタ（キー入力を受け付けないタイミング）が増えるシーンだと進まない。また、乱数変化にタイマーが絡んでいる様子は見受けられない・・・ような感じ。
　で、乱数っぽい２つに０・０を入れて軽く敵を殴ってみた。ランドリザード２体（賢さ０）・ダイナファング（賢さ２）の組にランド［陣形パラレル・３番手］のガダブレダを使ったところ、敵３体は必ず防御し、魔法は必ず必殺になり、ダイナに必ず９４、リザードに１０１ダメージが入った。敵よりランドを先行させると防御は通らず、必ず１２０・１１２（防御による魔法ダメージ減少は２０％：敵の防御は防御コマンドが実行されてから有効になる）。通常攻撃だとランドは必殺を必ず出さず、リザードに対して防御されないで１３４、されて６６となった（防御による物理ダメージ減少は５０％：計算タイミングはダメージ決定後ではないようだ・・・基礎ダメージ決定後５０％、そこから低中高ダメージ帯による４乱数？　これを調べきるならウォーカバウト１番手に置かないと意味ないけど）。敵行動の固定はほぼ間違いないけど、ランドの必殺魔法についてはより詳しい調査を要す。

　では７Ｅ００Ｄ７だけ固定から開放したらどうなるか。７Ｅ００Ｄ７は動き出してある程度適当な数字を吐き出した。敵行動はランダム、ダメージもばらばらとなった。ただ「ある程度」と書いたように、乱数の動きに何か変なものを感じた。特にダメージアニメ中に下４ビットが２・Ｅとなったり一定幅でしか動かなかったり。もっと書くと００になった瞬間動かなくなった。動かなくなった乱数は７Ｅ００Ｄ６を開放したらまた動くようになった。 また、逆に７Ｅ００Ｄ６を開放して７Ｅ００Ｄ７を０に固定したら、１６進数で３３以下になったら動かなくなった。３４〜１ずつ（７Ｅ００Ｄ７も開放すると０→１に）、６７〜で２ずつ（７Ｅ００Ｄ７も０→２に）、９Ａ〜３ずつ（７Ｅ００Ｄ７も０→３に）、ＣＤ〜４ずつ（７Ｅ００Ｄ７も０→４に）上がるようになった。もう１フレーム進ませると、７Ｅ００Ｄ７に０以外の数値が入っているとかなり大きく飛び、０が入っているとやはり規則的に上昇する（まあ当たり前）。

　とりあえず分かったことは、ダメージや行動決定、必殺の有無などかなり（もしかしたら全て）の部分で７Ｅ００Ｄ７の数値が使われている。ここを固定することは、すなわち結果の固定を意味する。「何歩でエンカウントしこの敵が出てきて、こちらの行動で何ポイントのダメージを与えて敵から何の攻撃を受けてどれくらいの被害が出て、ドロップ結果はこうである」まで決まってしまう。逆にこれを固定することで、乱数事象のかなりの部分が分かってくると思われる。

（2020.9.8追記）
　新エミュレータ「LSNES」と「SNES 65816逆アセンブラ」を導入し、逆アセンブル環境が少し整った。その結果、乱数処理ルーチンが浮かび上がってきた。以下がそのルーチン部となる。１６行と短めだった。SFCの機械語に関しては他のページで調べて欲しいところ・・・　書いてる自分でもほとんど理解できてない。

C0:63DA 08 PHP ; ここから乱数サブルーチン。まずステータスレジスタの保持。（電源投入時＝１周目はアドレス7E00D6〜D7の初期値＝0F0F）（２周目の初期値＝4B5A）
C0:63DB C2 20 REP #$20 ; A:16　Ａレジスタ（一時メモリ。一般プログラム言語で言う「変数」みたいなもの）を16ビットとして使用する宣言
C0:63DD AD D6 00 LDA $00D6 ; 指定アドレスのメモリ中身値をＡレジスタに代入。（１周目Ａレジスタの中身値＝0F0F）（２周目のＡレジスタの中身値＝4B5A）
C0:63E0 0A ASL A ; Ａレジスタ中身値を１ビット左にシフト（＝数値的には２倍）。（１周目Ａレジスタの中身値＝1E1E）（２周目のＡレジスタの中身値＝2D68）
C0:63E1 0A ASL A ; Ａレジスタ中身値を１ビット左にシフト。（１周目Ａレジスタの中身値＝3C3C）（２周目のＡレジスタの中身値＝2D68）
C0:63E2 18 CLC ; キャリーフラグ値＝０に宣言。１６ビットを超える頭は切り捨てられる？
C0:63E3 6D D6 00 ADC $00D6 ; Ａレジスタ中身値に、指定アドレスのメモリ中身値とＡレジスタ中身値（元）とキャリーフラグ値（１つ上で０と宣言済）を加算。
　　３行上の処理からここまでで、実質的にＡレジスタ中身値を５倍している（その上で６５５３６以上は６５５３６単位で切り捨て）。（１６ビット宣言中なのでアドレス7E00D6〜D7の初期値＝0F0Fを加算。１周目Ａレジスタの中身値＝4B4B）（２周目のＡレジスタの中身値＝78C2）
C0:63E6 EB XBA ; Ａレジスタ中身値の上位８ビットと下位８ビットを入れ替え。（１周目Ａレジスタの中身値＝4B4B）（２周目のＡレジスタの中身値＝C278）
C0:63E7 E2 20 SEP #$20 ; A:8　Ａレジスタを８ビットとして使用する宣言。上位８ビットは切り捨てられる（１周目Ａレジスタの中身値＝4B）（２周目のＡレジスタの中身値＝78）
C0:63E9 8D D7 00 STA $00D7 ; Ａレジスタ中身値を指定アドレスのメモリ中身値として書き込む。（１周目アドレス7E00D7＝4B）（２周目のアドレス7E00D7＝78）
C0:63EC 18 CLC ; キャリーフラグ値＝０に宣言。８ビットを超える頭は切り捨てられる？
C0:63ED 6D D6 00 ADC $00D6 ; Ａレジスタ中身値に、指定アドレスのメモリ中身値とＡレジスタ中身値（元）とキャリーフラグ値（１つ上で０と宣言済）を加算。
　　今回は８ビット宣言済なので８ビットを超える頭は切り捨てられる。（１周目Ａレジスタの中身値＝アドレス7E00D6初期値＝0Fのみ加算となり、4B＋0F＝5A）（２周目のＡレジスタの中身値＝アドレス7E00D6初期値＝0Fのみ加算となり、78＋5A＝D2）
C0:63F0 8D D6 00 STA $00D6 ; Ａレジスタ中身値を指定アドレスのメモリ中身値として書き込む。（１周目アドレス7E00D6＝5A）（２周目のアドレス7E00D6＝D2）
C0:63F3 28 PLP ; ステータスレジスタを保持しておいた値に戻す。
C0:63F4 6B RTL ; サブルーチン終わり

　・・・というルーチンが出てきた。乱数の種初期値＝始めに該当メモリに入っている数値は「１０進数で３８５５（１６進数で０Ｆ０Ｆ）」で、種が初期化されるタイミングは電源投入時、またはリセット直後。乱数が進むタイミングは１フレームごと、あるいは乱数を使用する事象が起きたら使用した分だけ進む（と思う・・・１フレームの進行保証分が入るかどうかがまだ不明瞭）。暗転時などに乱数が進まない箇所もある。実際に計算で使われる乱数値は７Ｅ００Ｄ７の方だけ（２バイトとすると上位１バイト）で、７Ｅ００Ｄ６は乱数計算に使われるだけの個所になる。
　新ルーチンを、ハンドブックの乱数ジェネレータ風にそれっぽい何かの言語で書き直すとしたら、こんな感じになるか。

BYTE rand( )
／ここから乱数生成アルゴリズム
{
WORD a = seed * 5;／／seed＝乱数メモリ保持アドレス２バイト分の値（上位８ビットがアドレス7E00D7、下位８ビットがアドレス7E00D6）であり、メモリに保持している数値そのもの。WORD：符号なし１６ビット整数として扱い、１６ビット以上の数値は切り捨てる

b = (a >> 8) & 0xff;／／aの上位８ビットを８ビット数値として個別に保持。乱数として返る値でもある。& 0xff：下位８ビットのみを使用して８ビット符号なし整数として扱う。９ビットより上位は切り捨てる。
a = (a << 8) + b;／／aの下位８ビットを上位８ビットに、上位８ビットを下位８ビットに置き換える。

seed = ((seed & 0xff) + b) + (b << 8);／／新たなseed＝メモリ保持値として、「b」を上位８ビット、「（元のseed下位８ビットにbを加えた数値）から９ビット目を切り捨てた値」を下位８ビットとした数値を代入

return b& 0xff;／／bを乱数として返して終わり
}

　・・・当初のジェネレータと違うのは計算の最終行だけ。「b=〜」と「a=〜」は返り値を分かりやすくするために敢えて分割しただけで、やってることは当初のジェネレータと同じ。
　この新ルーチンから他言語で処理スクリプトを作り、６万回まで回した結果の全リストはこちら（カンマ区切りCSV形式テキスト［Unicode UTF-16］：5620KB　OpenOffice Calc書類：4089KB　Excel書類：15126KB　表計算ソフト必須、超激重注意！　中身は１６進数表記箇所を計算式でやっているかベタ書きしているかの違いだけで、ほぼ同一）。乱数周期は５７９７３個で、計算結果が５７９７４回目から１回目に戻りループしているのが分かる。
　上記リストから「返される乱数結果」だけ抜き出したテキストファイルはこちらからどうぞ（269KB）。

　乱数の生成式が分かったので、これで一応「ほぼ解決」とする。後はこれを踏み台にして各種課題を突破するのみ。

余談：自作乱数ジェネレータで遊んでみたところ・・・
　・初期値を６５５３５にすると乱数返り値が最初の５１回も２５５が続く（この区間は乱数の種が１ずつ減っている）２７６８周期の表ができた。この乱数列は調査に上手く使いたい。
　・初期値０〜５１までは種から動かない＝１周期。乱数は全て０が返る。
　・残りは周期は様々ながらも乱数っぽくバラバラに動く。乱数列に目立った固まりはないようだ。なお、初期値７２・１０３・１６４・１６８・３６１・８４１で始めると全て網羅できる。
 

何を、どうやって調べたかった？
　提起編で掲げた謎は以下の通り。

（乱数が絡む提起項目）
・ブレス２はエンカウント率が高いと評されることが多いが、具体的なエンカ率はいくつ？　どのタイミングで判定している？　詳しい仕様は？
　・・・まだ分かっていません。
　とりあえずは、現在あちこちのチートコードページで挙げられているチートコード「エンカなし」は、エンカしてからｏｒフィールドを切り替えてからの歩数をカウントアップするアドレスを０に固定している、ということまでは分かった（ブレス２のエンカウントには３歩の歩数保証があるため、歩いた歩数を０にしておけば保証をずっと受けられる＝エンカウントしない）。

（2020.6.25追記）
　とりあえず乱数っぽいアドレス２つを０・０に固定し、低エンカ：ガンツ付近（フィールド）を歩いたら５６歩目でエンカした。高エンカフィールド：アルの洞窟だと１６歩目でエンカ。ただ同じ低エンカ帯でも一軒家の武器や周辺だと３２歩でエンカする。また、高エンカ帯のはずの無限の塔でＴＡＳさんが歩けている歩数よりも明らかに少ない。内部的に少しずつ違うのだろうか？

（2020.9.9追記）
　逆アセンブルのやり方が少し分かったので、以下の方法で分かるかもしれない。
　　・１歩ずつ「歩いた瞬間」にステートセーブを繰り返し、エンカウントするステートを引いたところで「乱数」アドレス：７Ｅ００Ｄ７（LSNESの場合は「WRAMの７Ｅ００Ｄ７」）にブレイクポイントを張る。ブレイクフラグは「読み込み時」とする。
　　・少し進めてエンカウント。無事ブレイクポイントに引っ掛かったら、機械語を１行ずつ読みつつエンカ処理をさせる。

・敵編成パターンの決定機構
　・・・まだ分かっていません。ＲＯＭ内になんかそれらしきものっぽい区画は見つけた・・・ような気がする。

（2020.6.25追記）
　とりあえず乱数っぽいアドレス２つを０・０に固定し、低エンカ：ガンツ付近（フィールド）を歩いたら５６歩目でエンカしたのだが、必ずガニメデ１体だった。高エンカフィールド：アルの洞窟だと１６歩目でエンカしたらスティンガー２体＋デックアールバ１体で固定。極端な話、「どのタイミングの乱数を回収するか」だけでも分かれば話が進むのだが。

（2020.9.9追記）
　逆アセンブルのやり方が少し分かったので、↑のエンカ処理を更に先に進めれば決定機構までたどり着けるかも。

・各敵のアイテム所持フラグ決定方法のようなもの
　・・・まだ分かっていないものの、少し理解が進んだ。
　戦闘終了後のアイテムドロップ内容の格納アドレスはチートコードとして挙がっていて、アドレス：７Ｅ０Ｆ４Ｂ・・・ここが戦闘終了時に００でない場合、入っているアイテム番号のアイテムをドロップ品として１つ獲得できる。
　また、敵の現ＨＰ：アドレス：１体目・・・７Ｅ１４４８、２体目７Ｅ１４Ｃ８。この間にアイテム所持フラグやステータス異常など、色々な何かがありそうとアタリがつく。
　で、カペタン村付近のポイズンムーバーを相手に数回戦ったら毒消しが落ちる編成に出会った。巻き戻してドロップ内容のアドレス数値を見ながら戦ったら、１体目では変化せず、２体目を倒したら値が変化した。逆に倒してもドロップ品が消えることはなかった。
　バイナリエディタでメモリ内容をじーっと見比べると、ＨＰ値の近くに１体目と２体目で値が違う箇所、該当アドレス：７Ｅ１４ＤＢが発見された。１体目でここに当たるアドレス：７Ｅ１４５Ｂの値は００、２体目では０７となっていた。所持アイテム：毒消しのアイテム番号は０７なのでおそらくこれだろうと判断。
　チートコードでアドレス：７Ｅ１４５Ｂの値をノートゥング相当に変えて敵を倒したらノートゥングが落ちてきた。また、１体目をノートゥング、２体目を毒消しのままにして１体目から倒したところ、ドロップ内容アドレス値もノートゥング→毒消しと変化し、毒消しが落ちてきた。つまり、アイテムのレア度や売価などの価値がドロップアイテム優先度に影響を与えているということもない。
　次戦、同じアドレスの値を見つつ戦闘突入したが、戦闘開始時に該当アドレスの値は０になっていた。もちろん戦闘ドロップはなし。
　よって、「敵のドロップ所持品は戦闘開始時にすでに決定していて、倒した順にドロップが上書きされる（０以外の時のみ）。ドロップフラグは敵のステータス内にアイテム番号そのものが格納されていて、０以外ならドロップあり。獲得乱数は格納されていない」・・・と確定できる。さらに言うと、ごく稀な「２体以上ドロップ所持」の可能性をケアし、目的の敵のドロップを反映させるように、複数種の敵が現れた時は目的のアイテムを持つ敵が混じっていたら、そいつを後に倒すべし。となる。
　残す謎は所持ドロップアイテムがいつ、どうやって決まるか。

（2020.6.25追記）
　とりあえず乱数っぽいアドレス２つを０・０に固定したエンカだと敵も固定な上にドロップアイテムも必ずレア品で固定・・・　と分かった。これが０・１だと同じ敵（例ではデスブリンガー：所持率２＝６４分の１）でも落ちない。単純に「乱数がこれ以下」という決め方ではないっぽい？　一番可能性が高いのは１フレームで１個ずつ進む仕様ではなく消化した分だけ進む、かな？　いやー、でも乱数は固定して観測したはずだしなぁ・・・　SNES9Xの乱数固定チートは６０分の１秒ごとにしか反応しないのか？

（2020.9.9追記）
　逆アセンブルのやり方が少し分かったので、以下の方法で分かるかもしれない。ただ、↑↑のエンカ処理の中で何かつかめればいっぺんに調査できる。
　　・エンカウント前に「敵１のドロップアイテム所持品」アドレス：７Ｅ１４５Ｂ（LSNESの場合は「WRAMの００１４５Ｂ」）にブレイクポイントを張る。ブレイクフラグは「書き込み時」とする。
　　・アトミックグミ・ガンガンヘッドのドロップ率がかなり高いので、これを狙って「巨大生物の島」でエンカウント。
　　・ブレイクポイントに引っ掛かったら、機械語を前に向かって１行ずつ読む。

・物理攻撃の必殺率
　・・・まだ分かっていませんが、かなり怪しい仕様を見つけたかも。

（2020.6.25追記）
　陣形をパラレル、乱数っぽいアドレス２つを０・１に固定しエンカ。究極合体ステン（調子２５５）で攻撃すると２番配置の時は必殺にならなかったが１番配置だと必殺になった。ウォークアバウトだと１番・２番配置共に必殺にならない。０・０にすると陣形によって必殺が出たり出なかったりする。調子がバラバラだからおそらくそれが原因だが、調子がいいキャラで出なくて、ちょっと低いキャラが出たりする。必殺率にキャラの性能差が出る可能性もかなり増してきた・・・？
　また、あるキャラが行動する前に乱数の固定数値を０から１に変えると、前ターンでは必殺が出なかったのが必殺になった。ということは、行動結果判定乱数は、行動する瞬間に拾ってくると推測できる。

（2020.9.9追記）
　逆アセンブルのやり方が少し分かったので、以下の方法で分かるかもしれない。処理ルーチンが分かれば確率も分かるか？
　　・４人目のコマンド入力を終える直前にステートセーブを行ない、１フレームずつずらして味方１人目の攻撃が必殺になるステートを引いたところで「１人目の一時ステータス異常」アドレス：７Ｅ１０６Ｃ（LSNESの場合は「WRAMの００１０６Ｃ」）にブレイクポイントを張る。ブレイクフラグは「書き込み時」とする（必殺を引いたらここが「80」になるため）。
　　・少し進めて、機械語を１行ずつ読みつつ必殺処理をさせる。

・魔法攻撃の必殺率
　・・・まだ分かっていません。ただ物理攻撃と同じ方法で調査できる可能性あり。

・スターブリンガー獲得確率
　・・・まだ分かっていません。ただし床のイベント判定は、戦闘終了メッセージを閉じるタイミング＝戦闘から抜けるを１フレームずらすだけで変化した。よって戦闘終了後にランダム判定が行なわれていると推測。

（2020.6.25追記）
　まだ試してないが、乱数を固定化できそうなことが分かったので調べやすいかもしれない。判定は戦闘終了後なので、乱数が変化するフレームだけ固定したらどの瞬間で判定するか、分かるかもしれない。検査法は乱数を真ん中くらいに固定して５０回施行、結果が変わらなければ飛ばし飛ばしにいくつか試行して挟み撃ち。

（2020.9.9追記）
　完全に固定できる乱数は０・０（完全固定）と２５５・２５５（５０周期程度）だけっぽい。それでも乱数が０・２５５の時に何が起きるか、については調べられる。おそらくどちらかで呪いがかかるか、スターブリンガーが拾えるはず。それぞれで両方が確認できたらラッキー。
　それはそれとして、逆アセンブルのやり方が少し分かったので、もうちょっと直接的に調べられる可能性が出てきた。変な顔で良く起きる「所持金が変化する（＋１・−１００）」＝所持金アドレスに書き込みが起きるタイミング（具体的にはアドレス：７Ｅ５０４Ａ［LSNESの場合は「WRAMの００５０４Ａ」］、ブレイクフラグは「書き込み時」）でブレイクポイントを張る。張り始めのタイミングは、戦闘終了メッセージが出きった後。成功したら、この行から前に向かって確認する。乱数ルーチンが直前に登場していたらなおよし。

（2021.1.3追記）
　処理分岐の直前に乱数が動いており、どうやら１つ動いた結果の乱数を判定に使っているっぽい？と判断できた。判定タイミングもだいぶ絞れてきた。乱数の固定化は、乱数表が手に入ったので「必要な乱数値」の１つ手前の数値に乱数を固定すればいいことになりそう。これで正しいかどうかは、例えば「０・０」と「２５５・０」・「１２８・０」などいくつかの「ｘ・０」が同じ結果を示すかどうか、「０・ｙ」や「２５５・ｚ」が違う結果を示すかどうかで検証できるはず。

・調合システムについて補足調査
　・・・まだ調べてません。ただ調査のポイントははっきりしている。調べ始めれば結論は早そうだが・・・？

・アイテム「闇鍋」の効果
　・・・まだ調べてません。まぁ、乱数の固定方法が分かって、発動タイミングが確定できたら、あとは乱数を１ずつ上下させるローラー作戦か数点ずらして確認する挟み撃ちでいい。

（乱数が絡まない提起項目）
　乱数が絡まない調査項目としては、以下のものが提起されました。
・敵のステータスを格納しているアドレスの調査
　・・・まだあまり分かっていません。「現ＨＰ・最大ＨＰ・現ＡＰ・最大ＡＰ・所持アイテム（倒すと入手できるアイテム：０ｏｒそれ以外）、所持経験値とゼニー」他いくつかの数値、戦闘時に使うアドレス区画と各敵の元々のステータスが格納されているアドレス区画は違う、までは見えた。敵１体・味方１人当たりのアドレス区画の範囲も分かった。これで大体４分の１くらいは解析できたか？

（2020.6.19全般的に修正）
　また、戦闘中にパラメータ増減魔法（ＳＴ増減魔法）をかけた時の挙動もかなり分かった。「元々のステータス」と「戦闘中のステータス」を格納するアドレスは敵味方ともに別管理で、戦闘時の計算には後者が使われる。ただし元々のステータスを参照する場面はそれなりにあり、例えばギガートをかけた場合、「ギガートがかかったフラグを立て、そのフラグが立っているので、戦闘中ステータスを格納する箇所に元々の攻撃力ステータスを２倍した数値を直接入れる」という操作を行なっている。つまり、補助魔法は変動後倍率を管理しているのではなく、かかっているかどうかのフラグを管理していて、その魔法をかけた結果を計算した数値を「戦闘中ステータス」に格納し、直接使っているのだ。再計算されるタイミングはＳＴ増減魔法がかかる、あるいは何かかかった状態から戦闘不能になるといった、「ＳＴ増減魔法フラグが変化した時」、それから「戦闘中に装備を変更した時」である。
　そして、ギガートとストール、カテクトとデイルは同居する。「この魔法がかかった」というフラグが別に存在し、それぞれ１回ずつ有効になる（一度かかった上下魔法は２度目は「失敗」扱いになる。対象者が倒れるとフラグはまっさらに戻るので１回ずつかけ直し可能）。上下が同時にかかった場合、ステータス増加→ステータス５１１キャップ判定→減少の順に判定される。「ステータス５１１キャップ」とは、通常のキャラでは「攻撃力・守備力・行動力は、素のステータス・装備品を加えた結果の最大値を５１１とする（攻撃力・守備力は減算される装備品がないためこれで確定だが、行動力だけは装備品の特性による行動力加算→５１１キャップ→鎧の重さ減少・・・の順で判定：鎧の重さ分だけキャップより下回る）仕様のこと。移動中にこの５１１キャップ判定でキャラのステータスが定まり、更に戦闘中はＳＴアップ魔法をかけた結果をもう一度キャップ判定にかけて最終結果を得ることになる。・・・はずなのだが、行動力だけは実際は上手く動作していない。　

　ハサートだけは何故か加算計算が行われるアドレスがおかしく、戦闘時行動力を示すアドレスから右に１つ・下に１つ（アドレス番号にして＋１１ｈ）ずれている。しかも何故か８ポイント加算処理をしている。この８ポイントがどこから出てきたかはともかく、実際の計算に使われるアドレス＝数値は変わらない。加算計算が行なわれない（ように見える）。ただしダールは正しく減算されるし、ハサートも雑魚敵が自身にかけた時は動いている（正しく動いているとは言っていない）ことを確認した。
　ＳＦＣ版においては、ハサートは効果はあるものの正しく動いていない。ではどう動いているかというと、戦闘開始時の値（雑魚敵の素早さは戦闘開始時、素の素早さ＋数ポイントの補正が入る。プレイヤー、およびボス敵にこの補正はない）→ハサートがかかると「素の素早さ」になる（数ポイントの補正が消えている）。このわずかな変動が起きるのは行動力補正がつく雑魚敵だけで、つかないプレイヤー・ボス敵においてはハサートは何の意味も持たない魔法となる。
　　よって、本来（ＧＢＡ版での仕様である）「１００％『分』アップ」になるべきところが、「１００％『に』アップ」（つまり現状ほぼ維持）になっている可能性が極めて高い。理由は仕様書の読み違いか、はたまた計算式解釈の間違いか・・・　「＋１００％」をどう読んだか知らないが、誤解が生じたというところか。ともかくＳＦＣ版においては戦闘時の素早さは正しく変動しておらず、これがハサートが機能しない理由と推測できる。
　なお、８ポイント加算されているアドレスは、「かけられたＳＴ増減魔法を管理するフラグ」とほぼ判明。

（2020.6.16追記、2016.6.21マップイメージ追加）
　既知のチートコードから、戦闘中の敵のパラメータ他アドレス管理は８×１６バイトを使用していると推測できる。対して、味方のアドレス管理は１０×１６バイトを使用していると推測できる。以下ではこれらを行列方式の方眼紙に見立て、８（１０）を縦とし「（１〜１０）行目」、１６を横とし「（１〜１６）バイト目」と表現する。なお、ＳＦＣはメモリ管理がリトルエンディアンになっているので、２バイト以上の数値は左が下位、右が上位の桁になる。
　以下、（不明）となっているところは未調査、あるいは良く分からない箇所。単に「データの切れ目」・「未使用」的に００が入っている箇所もある気はする。グラフィック系で使用していると推測できるところは、システム仕様を調査する観点からは蛇足になるので深い調査はしないつもり。［１６進加算］は明示された複数の値を１６進数の値として加算することで成り立つ箇所。１バイトを０と１で構成された８ビットとみなしてフラグ「ある・なし」を管理する。該当ビットが１なら有効、０なら無効。

（戦闘中の敵データ）
　敵１体目はアドレス：７Ｅ１４００からスタート。７Ｅ１４７Ｆまでが敵１体目の管理区画。戦闘に入ったら、出てくる敵のデータをＲＯＭ内の敵データ格納区画から引っ張ってきて埋めていく。なお、この区画は戦闘中だけではなく他のシーンでも使用されている。もちろん戦闘中ではないので用途は色々で、チートコードをそのまま使いっぱなしにしていると色々と変な動きをする可能性がある。逆に、移動中にしか使わないため戦闘中は意味を持たない、という区画も存在するようだ。以下の内容解析は戦闘中を基準にしているため、そういった区画は（不明確）または（不明）のままになる。
　「敵らしさ」の表現は、敵の名前、グラフィック、ステータス、行動パターン（敵ＡＩ）で決まってくるが、ブレス２ではこれらはどうやら連動していない。それぞれで独立した格納区画が存在する。以下推測だが、エンカウントが決まると、まず敵ＩＤを拾ってきて、それから該当するデータ（ステータスや行動ＡＩなど）を各所に格納。内部的には、「この敵ＩＤだからこの行動をする」ではなく「この行動ＡＩを持っているからこの行動をする」としているだけらしい。ただ、ボスはボスで特別な判定をしているか？
（2021.1.3追記）海外のフォーラムで解析している人を発見。敵ごとに「いくらかの確率でこの行動、いくらかの確率でこの行動・・・」というリストが作成されていた。参考になるかも？

（簡単なメモリーマップイメージ：灰色は不明、青は判明［グラフィック系］、緑は判明［パラメータ系］、ピンクは当てはついたが不明確）

敵グラ・演出関係？

敵グラ横軸

敵グラ縦軸

敵ＩＤ

アニメＣＴ

敵グラ横軸基準

敵グラ縦軸基準

敵の名前

敵現在ＨＰ

敵最大ＨＰ

敵現在ＡＰ

敵最大ＡＰ

特能頻度？

メッセ持ち？

行動内容？

敵の行動？

行動内容？

花咲きの有無

敵所持経験値

敵所持ゼニー

所持品

敵の運

敵属性

持ち感情値

タイマー？

敵現在攻撃力

敵現在守備力

敵現在行動力

敵賢さ

ＳＴ異常

行動タゲ

行動種別

行動内容

敵ＨＰゲージ

敵へ与ダメ・回復

ＳＴ上下フラグ

（内容詳細）
（１行目）１〜４バイト目：その敵が今どんな状態かを演出？（ダメージを受けた、攻撃した、などなど・・・　細かすぎて良く分からない）、７〜８バイト目：敵グラフィックの横軸、１０〜１１バイト目：敵グラフィックの縦軸、１５バイト目：敵ＩＤ（ゲーム内部での並び順。ボス・雑魚ひっくるめて管理。雑魚モンスターのＩＤはＳＦＣ版攻略本「ブレスオブファイア２のすべて」の敵データ表の並び順通りになっている。この数値はグラフィックのみに関わる。敵スプライトＩＤの基準となり、表示面積を決める元ともなる。実際に出ている敵のＩＤは、多分だが７Ｅ０Ｆ９Ａ、７Ｅ０Ｆ９Ｃ・・・以降で管理？）
（２行目）［ここからグラフィック・スプライト系の管理区画。どこまでかは不明］５バイト目：アニメーションのためのカウントダウンタイマー［フレーム数］、
（３行目）
（４行目）２〜３バイト目：敵グラフィックの横軸（基準：ダメージアニメーションで後ろにずれた後、この基準値を入れることで前に戻している）、４〜５バイト目：敵グラフィックの縦軸（基準）
（５行目）１〜８バイト目：敵の名前（日本語版では文字は特別なコードで内部定義されている［チートＷｉｋｉに文字コード掲載あり］、英語版ではおおむね現実のJISコードの１バイトコード［ASCII文字］と同様のコード）、９〜１０バイト目：現ＨＰ、１１〜１２バイト目：最大ＨＰ、１３〜１４バイト目：現ＡＰ、１５〜１６バイト目：最大ＡＰ
（６行目）１バイト目：通常の敵の場合は「特能を使う頻度」（０〜２５５、［この数／２５６］の確率で通常攻撃以外［防御・逃走含む、反撃・連続攻撃含まない］の行動を使うと思われる。おそらくＲＯＭのどこかに元数値があるはず。特別な敵の場合は「００」固定）、２バイト目：特別な敵の特別ＡＩ設定？（何かメッセージを持つ敵、イベント的に特定の行動パターンを取る敵の場合、ここが００以外になるっぽい。入る数値は会話内容？）、３バイト目：行動パターン？（６行−５バイト目と連動？、反撃・連続攻撃の特性はこちらで定義されている）、４バイト目：敵行動を示している？良く分からない、５バイト目：行動パターン？（６行−３バイト目と連動？）、６バイト目：アスパー「自然」の花咲きの効果（００：受けていない、１０：受けている）７〜８バイト目：所持経験値、９〜１０バイト目：所持ゼニー、１２バイト目：所持アイテム、１３バイト目：運の良さ（レベル？）、１４バイト目：敵の属性（01：ｇｈｏｓｔ、02：ｆｉｒｅ、04：ｗａｔｅｒ、08：ｉｃｅ、10：ｆｌｙ、20：ｕｎｄｅａｄ、80：ｈｕｍａｎ）、１５バイト目：その敵が感情値が上がる敵かどうか（０なら加算されない、１以上ならこの数値だけなら加算される［チートコードを使わない限り０か１しか入らない］）、１６バイト目：タイマーのようなもの（効果は不明。戦闘開始時からの大体の経過時間［フレーム数］０〜２５５、ただし初期値は０〜２５５がランダムで加算されてる、敵行動には関わってない、敵が倒れるか逃げたらカウントも止まる）
（７行目）３〜４バイト目：現攻撃力、５〜６バイト目：現守備力、７〜８バイト目：現行動力、９バイト目：賢さ（０〜７）、１３バイト目：一時のステータス異常（［１６進加算］０２：防御、１０：行動終了［２回攻撃用にターゲット再指定をしないようにする効果もあるかも？］、２０：ペポーパ、４０：ため［敵特能ちからため］、８０：必殺）、１４バイト目：行動ターゲット（「誰に」に当たる。０２：味方１、０４：味方２、０６：味方３、０８：味方４、０Ａ：敵１、０Ｃ：敵２、０Ｅ：敵３、１０：敵４、１２：敵５、１４：敵６、８０：敵全体、Ｃ０：味方全体）、１５バイト目：敵行動内容（「どんな行動を」に当たる。０２：通常攻撃、０４：特能、０８：防御、０Ａ：逃げる？）、１６バイト目：使用するもの（「何の技などを」に当たる。たいていは特能ＩＤ、一部例外的に、特定の「敵行動内容」との組み合わせで行動を表現している？）
（８行目）２バイト目：そのキャラのＨＰゲージ残量（０〜６４［ドット］。初出で「？」になる敵でもゲージ管理はしている）、３〜４バイト目：このキャラに与えたダメージ（０〜９９９）またはＨＰ回復量（２の補数：６５５３６−実回復量）、５〜７バイト目：（不明）、８バイト目：かかっているステータス増減魔法（［１６進加算］パリア：０１、ギガート：０２、ストール：０４、ハサート：０８、ダール：１０、カテクト：４０、デイル：８０）

（戦闘中の味方データ）
　味方１人目はアドレス：７Ｅ１０００からスタート。７Ｅ１０９Ｆまでが味方順列１番目の管理区画。ただしこれとは別に移動中のステータス格納アドレスが存在し、戦闘に入ったらそこからこの区画に必要なデータを移してくる仕組み。なお、この範囲は戦闘中だけではなく他のシーンでも使用されている。もちろん戦闘中ではないので用途は色々で、チートコードをそのまま使いっぱなしにしていると色々と変な動きをする可能性がある。逆に、移動中にしか使わないため戦闘中は意味を持たない、という区画も存在するようだ。以下の内容解析は戦闘中を基準にしているため、そういった区画は（不明）のままになる。

（簡単なメモリーマップイメージ：灰色は不明、青は判明［グラフィック系］、緑は判明［パラメータ系］、ピンクは当てはついたが不明確）

味方グラ・演出関係？

味方グラ横軸

味方グラ縦軸

味方ＩＤ

順列順番？

味方グラ・スプライト関係？

アニメＣＴ

味方グラ・スプライト関係？

移動中のみ？

移動中のみ？

味方の名前

加入状態

恒久ＳＴ異常

味方ＩＤ

味方ＬＶ

味方現在ＨＰ

味方最大ＨＰ

味方現在ＡＰ

味方最大ＡＰ

グラ基準

強さ

スタミナ

素早さ

調子

装備中武器

武器有フラグ

装備中盾

盾有フラグ

装備中鎧

鎧有フラグ

装備中兜

兜有フラグ

装備中其他１

他１有フラグ

装備中其他２

他２有フラグ

味方現在攻撃力

味方現在守備力

味方現在行動力

味方賢さ

味方運

感情値

根性

一時ＳＴ異常

行動タゲ

行動種別

行動内容

自ＨＰゲージ

味方へ与ダメ・回復

特技有効Ｔ数

ＳＴ上下フラグ

陣形補正？

（内容詳細）
（１行目）１〜４バイト目：その味方が今どんな状態かを演出？（ダメージを受けた、攻撃した、竜変身している、などなど・・・　細かすぎて良く分からない）、７〜８バイト目：味方グラフィックの横軸、１０〜１１バイト目：味方グラフィックの縦軸、１４バイト目：味方ＩＤ（リュウ、ボッシュ、ランド、リンプー、ニーナ、ステン、タペタ、アスパー、ディースの順で０〜８）、１５バイト目：順列順番？（１〜４人目が順に０〜３）
（２行目）［ここからグラフィック・スプライト系の管理区画。どこまでかは不明］１〜４バイト目：キャラのスプライトＩＤ？（良く分からない）、５バイト目：アニメーションのためのカウントダウンタイマー［フレーム数］、６〜１０バイト目：キャラのスプライトＩＤ？（良く分からない）、
（３行目）１バイト目：移動中のみ？・その味方がどの向きを向いているか（００：上、０１：右、０２：下、０３：左）、１２バイト目：移動中のみ？・歩行アニメのためのカウントダウンタイマー
（４行目）
（５行目）１〜４バイト目：味方の名前（日本語版では文字は特別なコードで内部定義されている、英語版ではおおむね現実のJISコードの１バイトコード［ASCII文字］と同様のコード）、５バイト目：仲間の加入状態（００：仲間になっている、４０：パーティーから外せない、８０：仲間になっていないｏｒ一時離脱）、６バイト目：恒久的なステータス異常（［１６進加算］０１：瀕死［ＨＰ残量も判定に関わってる］、０８：呪い、１０：毒、２０：ゾンビ、４０：完全ゾンビ、８０：戦闘不能）、７バイト目：味方ＩＤ、８バイト目：レベル、９〜１０バイト目：現ＨＰ、１１〜１２バイト目：最大ＨＰ、１３〜１４バイト目：現ＡＰ、１５〜１６バイト目：最大ＡＰ
（６行目）１バイト目：味方グラフィック・キャラ基準（ここの値は移動中フィールドのキャラグラ、および戦闘のキャラグラ及びアニメーションの基準になる。各キャラ、細かい合体パターンの数だけ用意されている。００なら合体していない時の普通グラ、０１〜４５まで）、２バイト目：強さ（０〜２５５）、２バイト目：スタミナ（０〜２５５）、４〜５バイト目：素早さ（０〜５１１）、６バイト目：調子（０〜２５５）、７バイト目：装備中の武器（アイテムＩＤを格納。以下装備品２まで同様）、８バイト目：武器を持ってるかフラグ（というよりも装備しているアイテムの「個数ｏｒ種別」。武器は１１固定、防具は２１固定、その他装備品と消耗品は個数。この区画は武器を装備していれば１１、していなければ００［以下装備品２まで同様］）、９バイト目：装備中の盾、１０バイト目：盾を持ってるか（装備していれば２１）、１１バイト目：装備中の鎧、１０バイト目：鎧を持ってるか（装備していれば２１）、１３バイト目：装備中の兜、１４バイト目：兜を持ってるか（装備していれば２１）、１５バイト目：装備中のその他装備品１、１６バイト目：装備品１を持ってるか（装備していれば０１）
（７行目）１バイト目：装備中のその他装備品２、２バイト目：装備品２を持ってるか（装備していれば０１）、３〜４バイト目：現攻撃力、５〜６バイト目：現守備力、７〜８バイト目：現行動力、９バイト目：賢さ、１０バイト目：運の良さ、１１バイト目：友好度、１２バイト目：根性、１３バイト目：一時のステータス異常（［１６進加算］０２：防御、０４：睡眠、２０：ペポーパ、４０：ため［究極リンプー・アスパー・タペタ］、８０：必殺。アルハメルによる特能忘れは、詳しくは不明だがステータス異常扱いではない）、１４バイト目：行動ターゲット（「誰に」。０２：味方１、０４：味方２、０６：味方３、０８：味方４、０Ａ：敵１、０Ｃ：敵２、０Ｅ：敵３、１０：敵４、１２：敵５、１４：敵６、８０：敵全体、Ｃ０：味方全体）、１５バイト目：行動内容（「どんな行動を」。０２：通常攻撃、０４：特能、０６：アイテム、０８：防御、１０：戦闘中特技［ステンの「死に真似」は通常攻撃＋使用するものＩＤを０Ａにして判別］）、１６バイト目：使用するもの（「何の技などを」。アイテムＩＤ、特能ＩＤなど・・・アスパーの自然を使うと、発動する予定の効果に割り当てられた特能ＩＤが入る）
（８行目）２バイト目：そのキャラのＨＰゲージ残量（０〜６４［ドット］）、３〜４バイト目：このキャラに与えたダメージ（０〜９９９）またはＨＰ回復量（２の補数。６５５３６−実回復量）、７バイト目：特技有効ターン数（土アスパーの「花」特技使用ターン＝５〜ターン経過ごとに１ずつ減、究極タペタの「切り裂く」使用ターン＝１、次行動回ってきたら＝０）、８バイト目：かかっているステータス増減魔法（［１６進加算］パリア：０１、ギガート：０２、ストール：０４、ハサート：０８、ダール：１０、カテクト：４０、デイル：８０）
（９行目）１４バイト目：陣形補正値？（ウォークアバウト・スクランブル・キープライフ・パラレルの順に１人目：００・０２・０４・０２、２人目：０６・０２・０Ａ・０４、３人目：０８・０４・０Ａ・０８、４人目：０Ｃ・０６・０Ｃ・０Ａ）
（１０行目）

・共同体の調査・・・全て解決済み！
（本命調査：ベレッタの商品群変更処理の仕方）
　・・・色々調査した結果判明はできた。その途上での副産物として、各住人に加入承認した時のアドレス値の変化は以下の通りと判明。
※チートコードとして使う場合、０を基準としてこれらの数値を足した値を使用する。
（例：ベレッタとウィンとカラシニコフのみを入れ、他の部屋は空欄にする場合、アドレス：７Ｅ５５ＥＣに４＋２＋１２８＝１３４［１６進数値：８６］、他３アドレスに０［１６進数値：００］を入力。ただし部屋４以降を使用するためには共同体が最大まで大きくなっているという条件は無視できないので、任意の住人を仮加入させてさっさと育てた上でこのチートコードを使う）

（建物１）
ヘッケラー（商人系）：アドレス：７Ｅ５５ＥＢが＋１
ケイ：７Ｅ５５ＥＢが＋２
プー：７Ｅ５５ＥＢが＋８
バック：７Ｅ５５ＥＢが＋４
ワッツ：７Ｅ５５ＥＢが＋１６（１６進数表記で＋１０）

（建物２）
ウィン：７Ｅ５５ＥＣが＋２
レミントン（商人系）：７Ｅ５５ＥＢが＋３２（１６進数表記で＋２０）
マクリーン：７Ｅ５５ＥＢが＋１２８（１６進数表記で＋８０）
ボクデン：７Ｅ５５ＥＣが＋１
ペチリ：７Ｅ５５ＥＢが＋６４（１６進数表記で＋４０）

（建物３）
ウーピ：７Ｅ５５ＥＣが＋８
マコティー：７Ｅ５５ＥＣが＋３２
アズサ：７Ｅ５５ＥＣが＋１６
ベレッタ（商人系）：７Ｅ５５ＥＣが＋４
アッキー：７Ｅ５５ＥＣが＋６４

（建物４）
ラッカー：７Ｅ５５ＥＤが＋４
カラシニコフ（商人系）：７Ｅ５５ＥＣが＋１２８
バロウズ：７Ｅ５５ＥＤが＋２
ガーバー：７Ｅ５５ＥＤが＋１

（建物５）
ハンズ（商人系）：７Ｅ５５ＥＤが＋８
マーチン：７Ｅ５５ＥＤが＋１６
エル：７Ｅ５５ＥＤが＋６４
ヨウゾウ：７Ｅ５５ＥＤが＋３２

（建物６）
ダイエ（商人系）：７Ｅ５５ＥＥが＋４
サルバドル：７Ｅ５５ＥＥが＋２
サマナー：７Ｅ５５ＥＥが＋１
セーフィ（商人系）：７Ｅ５５ＥＤが＋１２８

・・・アドレスの小さい順に直すと
ヘッケラー：７Ｅ５５ＥＢが＋１
ケイ：７Ｅ５５ＥＢが＋２
バック：７Ｅ５５ＥＢが＋４
プー：７Ｅ５５ＥＢが＋８
ワッツ：７Ｅ５５ＥＢが＋１６
レミントン：７Ｅ５５ＥＢが＋３２
ペチリ：７Ｅ５５ＥＢが＋６４
マクリーン：７Ｅ５５ＥＢが＋１２８

ボクデン：７Ｅ５５ＥＣが＋１
ウィン：７Ｅ５５ＥＣが＋２
ベレッタ：７Ｅ５５ＥＣが＋４
ウーピ：７Ｅ５５ＥＣが＋８
アズサ：７Ｅ５５ＥＣが＋１６
マコティー：７Ｅ５５ＥＣが＋３２
アッキー：７Ｅ５５ＥＣが＋６４
カラシニコフ：７Ｅ５５ＥＣが＋１２８

ガーバー：７Ｅ５５ＥＤが＋１
バロウズ：７Ｅ５５ＥＤが＋２
ラッカー：７Ｅ５５ＥＤが＋４
ハンズ：７Ｅ５５ＥＤが＋８
マーチン：７Ｅ５５ＥＤが＋１６
ヨウゾウ：７Ｅ５５ＥＤが＋３２
エル：７Ｅ５５ＥＤが＋６４
セーフィ：７Ｅ５５ＥＤが＋１２８

サマナー：７Ｅ５５ＥＥが＋１
サルバドル：７Ｅ５５ＥＥが＋２
ダイエ：７Ｅ５５ＥＥが＋４
（以下未使用）

　・・・アドレス：７Ｅ５５ＥＢ〜７Ｅ５５ＢＤまでの４バイトを使用し、２進数表記でフラグ管理している。あるケタが１ならその住人がいる、０ならその住人はいない、となる。これを数値の足し算の観点から見ると上記の書き方になる。数値の足し算だけなので無理やり２人以上を同じ部屋に住まわせるチートも簡単だが、商人系の住人がいるとその住人が優先され、商人系以外の住人は画面に出てこない。ダイエとセーフィはどちらも商人系だがグラフィックがかぶり、セーフィのみ有効＝預かり所になる。

　同居させた場合の各住人のイベント進行の扱いは、おそらくだが問題にならないと思われる。イベントが進む系の住人はそれぞれの建物で１名のみ（・・・建物５のマーチンとヨウゾウだけが怪しいが片方はティアの色管理、片方は「はい・いいえ」のみだからセーフ？）で、残りはその場で効果を発揮するタイプの住人かイベントがない住人ばかり。これらのフラグは部屋が違えば同時進行の可能性があるので別々に管理されているはず。
　ただし各部屋に住人が割り当てられているのではなく、「この住人が入る部屋はこの部屋」とプログラム上で決まっている。ある部屋に入った時、その部屋を使用する住人のチェックフラグ区間（アドレス数値の該当箇所）のうち、どこかが２進数上で「１」になっていれば（＝対応する住人がいることになっていれば）、その住人が登場する。だから例えば部屋１にベレッタを入れるという芸当はチートコードを使用しても不可能。
　また、ある部屋に住人を加入承認した・していないを管理するフラグは別に存在する（アドレス：７Ｅ５５ＥＡの８ビットのうち下６ビットを使用した２進数・・・１なら00000001だから部屋１のみ使用中、６なら00000110だから部屋２と部屋３が使用中。全部埋まると６３＝00111111を取る。使用中の部屋に入るはずの住人はプレイ中には加入承認できない・・・のでチートコードで無理やり入れたり同居させたり）。共同体を大きくするためには部屋１〜３に誰か適当に加入承認する必要、つまり７Ｅ５５ＥＡ＝７にする必要がある。

　しかし肝心のベレッタは解決できず。上記のリストを見た通り、ベレッタはデータ内に１人しかいない。ベレッタの商品変化はこれをいじるだけでは実現しないということ。どこかに違うフラグが存在する。戦闘数？　プレイ時間？　それともストーリー進度で変わるフラグがある？
　同じ部屋の住人候補「アッキー」も、ストーリー進度によって住人の数が増えるタイプ。これもベレッタと同じ要因で増えるのだろうか？　ただ、増えるペースは明らかにベレッタよりは早いように見える。

（2020.5.19追記）
　ベレッタの調査を少し進めた。ハイランド城突入直前にベレッタを加入させたところ、名人の笛をもらったところでも品揃えに変化なし。ハンドブックに挙げられている区切りはどうやら固定ラインではなさそう。戦闘回数・プレイ時間をいじるチートも使用してみたが変化なし。あるいは、区切り条件は挙げられた通りだが近すぎるとダメ？
　何となくグーグル検索していたら、以下の日記を発見。 　　参考ページ：http://www.enpitu.ne.jp/usr9/bin/day?id=93405&pg=20060115　から
　「共同体の発展状況も関係がある」（ハイランド城クリア前にランク１だったが、そのまま共同体を増築だけ行なったらランク２になった）という内容で、この通りなら、ストーリー進度というよりイベント進行回数が関わっている可能性が高い？　しかも「回数」は「共同体増築」も１回とカウントする可能性がある？　これだけだとランク２以上にするためには増築が必須である可能性の検証が必要だけど、増築前でもストーリー進度によってランク２になるなら増築必須の可能性は消える上に、「改築したことで増えるフラグ」をチェックすればベレッタのランクアップを実現する機構が詳しく分かるかもしれない。そう、ストーリー進行中、そのフラグを注視していればいい。なお、ハイランド城直前加入のデータでは、ハイランド城突破直後に変化なし、かつ増築しても変化なしだった。
　引き続きストーリーを進め、ファマ村：畑耕しイベントを終えてナマンダ寺院に行く直前（ランド母にお使いを頼まれる前：耕し後に話しかけていない）でセーブ→ベレッタを確認したところ、ランク１の品揃えだった。ここで増築を依頼し、増築を終えたところで再確認したらランク２に上がっていた。増築せずに共同体に８回出入りしても変化なし。また、耕し前にも同じことを行なっているが、その時は増築前・後ともに変化していない。よって共同体の増築、および畑を耕すイベントの完遂（あるいはイワオカインを倒す？）が何らかのフラグ要因（ストーリー進度の足し、あるいは進行ポイントの加算）の１つであることは確定。

（2020.5.20追記）
　ちょうど、そのすぐ後にナマンダ寺院にお祈りに行くシーンがあった。そこで、寺院でお賽銭を払った後に戻ってみたらランクが上がっていた。ならばと少し戻り、寺院の入り口をふさいでいる（畑を耕し終えないと入れてくれない）人をどかしたらすぐ戻ってみた。そうしたら、こちらもランクが上がっていた。
　そこでメモリ内容を見ながら増築を行ない、一度戻して寺院に入る許可をもらうシーンをこなし、と検証。どちらも完了後で同じ値になり、かつ値が増えているポイントを探したら３か所発見した。アドレス：７Ｅ５６Ａ２、７Ｅ５６Ａ３、７Ｅ５６Ａ４が該当。
　このポイントをそれぞれ数値を変えてベレッタの品揃えをチェックしたところ、品揃えが変わるアドレス：７Ｅ５６Ａ４を特定できた。ベレッタの部屋に入った時、このアドレスの値の範囲によって品揃えが確定すると判明した。残りの２アドレスの用途は今のところ不明。アッキー・プーに使うための値の可能性が一番高そうだが結論は出ていない。

（2020.5.28追記）
　アドレス：７Ｅ５６Ａ２は判明。予想通りプーのイベント進行度だった。０〜７：持ち家ゲットを喜ぶ、８〜１５：仕事を始めようか悩む、１６〜：「あれ」（月のしずく）を１０００Ｚで売ってくれる。ベレッタと違い、「話した瞬間の進行点」で変化。部屋の中でチートコードとして数値をいじったらその場で行動が変化する。進行点はベレッタと共通の進み方をするが、ベレッタよりも後に連れてきた場合、先に連れてきた場合における進行点変化はまだ未調査。

　以下、2020.6.1時点での結論。調査完了したので確定とする。誤認が判明次第修正・追記する。
　・ストーリー進度に関わる（というよりも特定の行動を終える、特定の敵を倒す、あるいはターゲットに話しかける、など）、ストーリー管理のフラグ値が変化する一部の行動に対し、品揃え進行点（仮称）に＋１がついている。そのポイントを通過するごとに進行点がたまっていく。
　・このポイントはベレッタ（というよりも３軒目の住人なら誰でも）加入時から累積が有効化される。ベレッタが加入しないとこの進行点は０のまま動かない。そして、ベレッタの商品ランクは品揃え進行点０〜７：ランク１、８〜１５：ランク２、１６〜２３：ランク３、２４以上：ランク４・・・と定まる。ベレッタの部屋に入った時、この値の範囲によって品揃えが確定する。この値を２４以上、かつ居住人フラグをベレッタがいるようにいじればチートコード（ベレッタ加入＆最終装備販売）として使用可能。
　・進行点が＋１されるストーリー上のポイントは、現時点で判明しているのは以下の通り。ベレッタ加入時に＋１があると仮定しても、最低でも＋１が２３か所、あるいは＋２以上されるポイントがあるはず。実際はベレッタ加入で＋１されなかったので、最低でも２４か所の加算ポイントがあると推測。
　　調査方法は、特定アドレスの値を見ながらストーリーを進め、値が変化したポイントと上昇値を記録すればＯＫ。基本的に、７Ｅ５６Ａ２〜Ａ４の３アドレスにそれぞれ＋１されるようだ。おそらくはストーリーが進む人だけと話して完全解決する問題ではないと思われるので、どの町もできるだけ全員話しかけてみるのが良さそう。

（2020.6.1追記）進行点が加算されだす条件は特定の住人ではなく、「その部屋に住人が誰か入った時」だった。この「誰か」は加算開始判定に影響せず、普通の商人でも他の住人でも、とにかく部屋に入居していれば加算が始まる（対象住人以外では無意味な管理数値になるだけ）。ただし住人を入れ替えることはできないので、実質的に入居させた住人専用の進行点となる。部屋１つごとに１バイトが当てられていて、アドレス：７Ｅ５６Ａ２が部屋１（プーが入る部屋）、７Ｅ５６Ａ３が部屋２（該当住人なし）、７Ｅ５６Ａ４が部屋３（ベレッタ＆アッキー）、７Ｅ５６Ａ５が部屋４（該当住人なし）、７Ｅ５６Ａ６が部屋５（マーチン＆エル）、部屋６は７Ｅ５６Ａ７（該当住人なし）が対応する。

（2020.6.1追記完成）進行点が加算されると判明しているポイント：おおよそストーリー順。
　（ストーリー上のポイントでない部分：条件を満たせばいつでも獲得できるが自発的に獲得する必要あり）
　・共同体の増築完了・スイマー城付近の滝でドラゴンの力を得た瞬間・魔女の塔で水シャーマンを見つけた直後・ファマ村で土シャーマンを見つけた直後（回数が足りず月のしずくを見つける、では加算されない）・バンドオ教会地下で聖シャーマンを見つけた直後（エブライ爆破前・後を問わず）・無限の塔で魔シャーマンを見つけた直後

　（ストーリー上のポイント部分：ストーリーを進める上で必ず通過することになるので、獲得を意識する必要はない。逆に、このポイントを過ぎてから加入させてもストーリーは戻れないので、ここに挙げるポイントは獲得し直せない）
　・タペタを見張る監獄見張りを倒した直後・偽タペタと料理勝負をすることになった直後・偽王子事件を解決してタペタを再び仲間に加え、陣形を組み直した直後・ゲイト村の事件をレンジャーギルドで聞き終え、仲間４人が集まった瞬間・くじら体内でムンマーを倒した直後・団長を倒しアスパーを仲間に加え、外に出た直後・名人の笛入手後、再びステンと合流した直後・ゲドが音楽の国の女王のダイエットに一度失敗し、手伝いを頼まれた直後・ダイエットを完了させて女王を救い、宝物庫の宝を持っていく許可を得た直後・大賢樹の夢の中でアルハメルを倒した直後・天の塔の入り口を守る海人に塔の調査の許可を得る（塔に潜る必要はなし）・天の塔最上階で風シャーマンを回収した直後・畑を耕し終えてランド宅で一晩休んだ直後・ナマンダ寺院の入院許可を得て、入り口の人が横に退く・ファマ村でランド母がさらわれ、エバ教信者を倒してエバ大教会に行く決意をした直後・翼の証を手に入れる（＝ニーナのご先祖様を倒して戦闘から抜ける瞬間）・ミイナが翼の証を使用した瞬間・エブライ初回突入時、クラリスに話しかけ、エブライから出る１歩前・盗人の墓で盗人の証を手に入れた瞬間・ネクロマンサーを倒して戦闘から抜ける瞬間・大教会突入直前の門番の問いに誤答して倒した瞬間（「正答して通過」はダメ。わざと誤答すること）・レイを倒した直後・ランド母がランドの身代わりとなり壁に潰され、ランドが階段を上がる瞬間・エブライを爆破した瞬間（ガナーを倒した場合はエブライから脱出した瞬間、救った場合は共同体にワープした後に話を聞き終わった瞬間）

　進行点が加算されない主なポイント：一見、進行点が加算されそうなポイントに見えるが実は加算ポイントではなく、品揃えやイベントは進まない
　（非ストーリー上）・ベレッタ筆頭に誰かを共同体住人として連れてくる（：進行点の加算が始まるだけでスタートは０点から）・エバ協会で寄付する、および寄付し続けてエバの書をもらう・エイチチを共同体井戸に招く・ディースを仲間に加える・アルジャーノンたちを倒しアルの実を手に入れる・ウパルパを倒す（逃がすか否かは無関係）・ナマンダ寺院にお賽銭を入れる（初回・リピートを問わず）・共同体を浮遊させる・鐘突きイベントをこなしてド＝ブンバ＝ラを獲得する

　（ストーリー上）・山猫を倒す・山猫にせんぎりを教えてもらう、あるいは料理を振舞ってもらう・ニムフから王家の指輪を回収する・スイマー城地下で大ミミズ・大ゴキブリ・金蝿を倒す・偽王子との料理対決に敗れる・クワドラを倒す・パティを発見し回収する・トラウトに真犯人を引き渡す・トラウトを倒し聞き耳頭巾を取り返す・グランパを叩き起こしくじらベルを手に入れる・団長にショー中止を直談判する・最初に大賢樹と話し、セラピの枕を持ってくるよう頼まれる・シュプケーと面会し、落とし穴に落とされる・トゥルボーと戦う（１回目・２回目ともに）・ステン単独でハイランド城を半分突破し、仲間と合流する・シュプケーを倒し名人の笛を手に入れる・音楽の国のおばばから女王のダイエットを依頼される・ゲドをパーティーに加えて音楽の国に出向く・キノコを回収してジジのかがみを手に入れる・宝物庫の番人からセラピの枕を手に入れる・大賢樹の夢の中でアルハメルを倒し、脱出する・霧の谷で霧が濃すぎて進めないという話を聞く・初めてファマ村に着き、ランド母とランドを会わせる・畑仕事で雑草、石ころ、切り株、イワオカインを倒す・ニーナがウインディア王と話をする・最初にコットの砦に入り、ティガと話をする・盗人の証を入手後砦に戻り、ティガと争いになる（けんかに至るかは無関係）・バンドオ教会で地下への抜け穴を発見する・教会地下の隠しモンスター（エバ教）を倒す・教会地下で護衛を倒す・大教会に乗り込む直前のティガの、エバの教えの問いに答える（正誤問わず）・大教会突入直前の門番の問いに正答してスルーする（誤答して倒せば加算される）・クラリスとティガが共に倒れる・ゲイト村でドラゴンを爆撃した直後・パティがハバルクに捕まり、バレリーに助けられるシーン・ハバルクを倒し、バレリーに封印の扉を開けてもらった直後・ドラグニールに到着し、長老の話を聞いた直後・バレリーの過去話をなぞり終える・アンフィニを獲得する・バルバロイを倒す（多人数で・１人でを問わず）・ラスボスにかけられた呪縛をレバー連打で打ち破る・ラスボスまで走り続け、一閃して正体を現させる・ラスボス第１形態でアンフィニを使い仲間を復活させる・ラスボスを倒す（＝クリア後もセーブデータへの反映および特典なし）

　・・・これでベレッタの品揃え強化タイミングが分かった。アッキー（今まで「あっきい」だとばっかり思ってた・・・　よくよく確認したら「アッキー」でやんの・・・）などについても分かったし、これで最終解決とする。

（付帯調査：マーチンの役割）
　いつまでに入れればいいのか、最大限早くした時（くじら岬クリア直後）と最大限遅くした時（音楽の国の女王のダイエット完了１戦前？）で比べたい。早い時でＯＫ、遅い時でＮＧが出たら挟み撃ちの要領で最低限のタイミングを計る。もし遅い時でもＯＫが出たら今度はダイエット直後に加入させて金を払い、ゲームクリアまでちょくちょく様子を見てみる。

ベレッタ調査を含む簡易チャート：
　まず共同体の部屋３が空白の状態のまま、クジラを取る。セーブし、ＡとＣ：マーチンの進行チェックのためだけのデータ　Ｂ：ベレッタの進行タイミング調査も兼ねたデータを用意。
　Ａ：適当に住人を入れてマーチンを即加入させる（最速加入）。金を払う→音楽の国ダイエットイベントを完遂→マーチンイベントチェック。これで
　　　イベントＯＫなら・・・Ｂのデータを進め、マーチンイベントが
　　　　　　　　　　　　　　ＮＧなら・・・Ｃ：加入タイミングを例えば名人の笛ゲット後、マオリ島に行く前、行った後など少しずつターゲットを絞っていく。 　　　　　　　　　　　　　　　　ＯＫなら・・・Ｃ：加入タイミングをダイエット後にし、ストーリーを進めていく。ＯＫになるタイミングはあるか？
　　　イベントＮＧなら・・・とにかくストーリークリアまで進めてみる。そのまま何も起きなければガセネタだったと結論。
　Ｂ：アスパーを助け、大賢樹に話しかけた後（ハイランド城に入る直前）まで進めたらベレッタを加入させる。品ぞろえが第１段階であることを確認。エンカなしのチートを使用し、最低戦闘数（イベント戦１回＋ボス３回）でクリア。ベレッタの品ぞろえをチェック。第２段階まで進んでいたらほぼストーリー進度がフラグ。進んでいなければ果たしてどうなるか？　どちらにしてもマーチンのイベントのチェックのためにダイエットイベントを途中まで進め、体内から脱出してからマーチンを加入させて金を払う。ダイエット後、イベントが進むか？　それでもダメなら（あるいは全く別調査として）、戦闘回数やプレイ時間をチートコードでいじってみて変化するか？　も確認すること。

（2020.5.12追記）Ａを進め、「イベントＮＧ」だった。そもそも、ソース元記事の記載をグーグル翻訳にかけた時の訳文を誤解釈していたっぽい。「ダイエット前に加入させればダイエット後に５０００Ｚゲットできる」ではなく、「ダイエット完了までに加入させないと５０００Ｚもらえない」という意味だったようだ。仕方ないのでクリア付近まで進めてみる。現在ファマ村：デイジイがさらわれたところまで調査、進展なし。
グーグル訳文：それから彼は戻ってきて、あなたがその男と戦うつもりだと言って、あなたがTunlan（音楽の国）の女王を治す前にあなたが彼を手に入れない限り、何も役に立たない、そして彼はあなたに5,000ゼニーを与える、それはそれほど長くは続かない。

（2020.5.15追記）更にストーリーを進め、バルバロイを倒すまで進行。残りはラスボスだけだがラスボス後はセーブ不可なので実質ここまでで事態が動くはず。しかしマーチンは帰ってこない。ＲＯＭ内に５０００Ｚに関するメッセージデータは存在しているので、何かあるとは思うのだが・・・　それとも逆に、加入から即解決させなきゃならない、ってことか？
　ただ、もう少し海外サイトを検索したところ、気になる文面が。

出典元：https://bof.fandom.com/wiki/Township　から
該当箇所のグーグル訳文：彼は「あの男」とだけ呼ばれる不特定の敵を倒すためにあなたとチームを組むことを提案しています。彼はすぐに彼の計画に資金を供給するために3,000ゼニーのローンを要求します。同意すると、彼はメモを残し、彼を探してゲームの残りの部分で消えるように指示します。あなたが拒否した場合、彼は後であなたをごまかそうとしたことを謝罪し、5,000ゼニーの1回限りの贈り物をあなたに与えるでしょう。
　・・・もしかして単純に、加入後に金貸しを拒否して（そもそも話しかける必要があるのか？）、いくばくかの間放置してストーリーを進めればいいだけか？

（2020.5.19追記）
　・・・イベントの内容はあっさり解決した。最速加入後、借金の申し出に「いいえ」と答え、ハイランド城をクリアして名人の笛をゲットするまで進めて共同体に戻ったところ、マーチンが負けを認め５０００ゼニーくれた。
　このイベントは、加入承認した後に共同体に戻り、一度は「話しかけて借金を拒否する」必要がある（最速加入後、話しかけずにハイランド城をクリアしても借金を持ち掛けられた＝イベントは始まっていない）、というところまで判明。
　続く（最後の）謎は、ストーリーをどこまで進めることが許されるか。とりあえず、ハイランド城クリア直後に始めると女王のダイエット成功直後に負けを認めた。一気に飛ばしてエブライ破壊直後まで進めてみる。ＯＫならバルバロイを倒してから加入させ、戦闘数やプレイ時間をいじる。ＮＧなら挟み撃ちでアタリをつけて調べてみる。

（2020.5.20追記）
　エブライ破壊直後まで進め、加入させた。もしベレッタと同じような進行点制度だとしたら、進行点がもらえるようなイベントをこなせば先に進めるのではないかと推測。借金を断った後、土のシャーマンと聖のシャーマンを見つけてきて進行点を＋２させ、再び話しかけたら５０００Ｚゲットできた。シャーマンを加えなかった場合はいつまでも借金を迫ってきた。
　更におまけ的な追加調査を行ない、エルも同様に連れてきてから＋２点でイベント発生すると判明した。
　・・・これで特定住人のイベント発生システムが分かったので、最終解決とする。

・仲間のドラゴンズティアの色における特能制限・感情の深まり方・・・解決済み！
　ティアの色による特能制限は、ＳＦＣ版でも存在する。ニーナのレベルをバルハラーを覚えるまで上げ、ティアの色を悪くするチートを使用したところバルハラーのみ使用不可になった。色を良くしたら使用可能になった。
　ティアの色は通常のフィールド戦闘において、ある条件で勝利＝各人に加算。カペタン村付近でレベル６０以上にして戦っても増えるので、味方ｖｓ敵の強さによる影響は受けない。そのキャラで敵を倒したかどうかも不問。
　条件は、敵の種類＆数と思われる。カペタン村周辺だとリザードマンを１体倒すと＋１、３体編成なら全滅させると＋３。ひとでキノコ・キラーゴブリン・ポイズンムーバーを何体倒しても＋０。この性質上、増えると決まった戦闘では巻き戻しを使っても結果は変わらない（＋１される敵が逃げない限り）。共同体付近ならめだまグミは＋１、ガンヘッド・まだらひる・バブルバックは＋０。コルセア付近のみなしごデビルも＋１。何か共通点がありそうな気もするがなさそうな気もするので、結局ストーリーを１周して全モンスターを調べてリスト化した方が早い感じと結論。
　ティアの色が＋１される敵を倒すと、そいつを倒したアニメが始まった瞬間（おそらく内部的に「倒した」処理が始まった瞬間）にアドレス：７Ｅ０Ｆ３７が＋１される。戦闘終了メッセージが始まる直前に各人のティアの色のアドレスの値にアドレス：７Ｅ０Ｆ３７の値が加算されて、アドレス：７Ｅ０Ｆ３７の値は０に戻る。（チートコード的には、アドレス：７Ｅ０Ｆ３７を２００くらい［元々リュウを含めどのキャラも初期値は１２８］にすると、戦闘終了後にリュウ以外３人の感情値が２５５になる）。
　なお、制限対象の特能を使用するために必要な感情値は、バルハラー・ドメガが１７５、リフレストが２００、リバルラが２５０となっている。通常はレアケースだがリュウもこの制限対象にかかる。

（2020.6.5追記）
　結局全敵調査を行なって、結果がまとまったので掲載。本記事用のページをそのまま転用する。別ページにて。これで全仕様が分かったので最終解決とする。
　チェック方法：とどめを刺したとき、特定アドレス：７Ｅ０Ｆ３７が１増えるか否か。
　その他のチェック項目・・・
　　・○の敵をリュウ１人だけで倒したときにどういう反応が出るかも確認しておきたい。・・・答え：７Ｅ０Ｆ３７の値は１増える。実はリュウ自身も初期値は１２８でみんなと同じように変動してる。
　　・ステンの「すり替え」で敵を変えると・・・答え：７Ｅ０Ｆ３７が１以上だったとしても０に戻る。

・ド・ブンバ・ラ獲得のためのナマンダ寺院ミニゲームの難易度
　・・・まだ調べてません。これが分かったからどうなるのか、という話でもないけどＧＢＡ版との難易度の違いが調べられる伏線にはなる。
 

その他
　厳密にはゲームの仕様の話ではないですが、個人的に知識として仕入れたい項目。

（Herb 9.0 Glitchというバグ技について）
　・・・まだ理解していません。

（デバッグモードについて）
　・・・まだ分かっていません。

余談
　いくつかチートコードやら、まだあまりまとまっていない仕様っぽいものが掘り返せたのでまとめておく。
・画面上のドラゴンズティアはどのシーンでも同時に１つだけしか表示されない。で、その色を示すアドレスは７Ｅ１４１Ｃで、値の範囲は０〜３１：指し示す感情値を８で割った整数値。最高の状態：虹色は、感情値で言えば２４０〜２５５。なお、感情値を保持するキャラは少なく、プレイヤーキャラ９人の他はおそらくレイ、山猫店主、バロウズ、ヨウゾウだけ。残りは会話ウインドウ上で決まった色に象徴的に変動させるだけ。
・上記４人の感情値は４バイト・１か所に固まっており、全て０〜２５５を取る。レイの感情値＝アドレス：７Ｅ５６７８、山猫店主の感情値＝７Ｅ５６７９、バロウズ＝７Ｅ５６７Ａ、ヨウゾウ＝７Ｅ５６７Ｂ。

・エバ協会に寄付した回数はアドレス：７Ｅ５０４Ｄ。お金が足りないまま寄付しようとして１０Ｚもらった時は、当然回数には加算されない。また、寄付した回数が２０回になった（＝累計１９回の時に寄付をした）時に限りエバの書をもらえる。なお、これをチートコードとして使って１９回に固定すると、寄付をするたびにエバの書が増える（複数持てる）。

・ナマンダ寺院にお賽銭を入れた回数はアドレス：７Ｅ５０２Ｆ。ソロ出現イベントに関わる判定タイミングを過ぎている（≒エブライを破壊している）と、ここを変えても結果は変わらない（回数達成状態でエブライを破壊し、その後に回数を減らした上でファマ村に戻ってもソロがいる）。つまり、ソロ出現フラグはどこかに別に１つ確保されている。なお、出現フラグの決定は最初にエブライに入る時ではなく、「クラリスを助けるために大教会に乗り込むところ」以降と判明した。端的に言うと、エブライへの道を手に入れた直後まではセーフ。さらに調査したらもうちょっと先の「ランド母がランドの身代わりとなるシーン」がチェックポイントだった。つまり土のシャーマンはナマンダの神がランド母の生まれ変わり（？）的な存在として巡り会わせた、と妄想できる。

・ゲーム内の昼夜を判定するような時間の変数は、アドレス：７Ｅ０ＣＢ８で秒数（１フレーム＝６０分の１秒で１カウント、６０で１分）、アドレス：７Ｅ０ＣＢ９と７Ｅ０ＣＢＡで分数（０〜１２７：何故か２アドレスともに同じ値が入る。内部処理的にはきっと違う処理に使っていると思うが詳しくは不明。２２〜９７が昼の時間帯）。さらにアドレス：７Ｅ０ＣＢ７で昼夜判定（０なら昼、１なら夜）となっている。ブレス２内の時間を１フレーム１秒、１日２４時間と仮定すると、「１時間」当たり６０×１２８÷２４＝３２０フレーム＝現実の５．３秒ほど。これは、ワールドマップ上で、コマンド画面を開かずにただ動かずじっと待っていても進む（コマンド画面を開いている間は進まない）。なお、リュウの特能「ひと休み」は、時間を４３（８時５分ほどに相当）・１１４（２１時２０分ほどに相当）のいずれか次に来る方の値にする。

・ブレス２のフラグ管理は、実は結構しっかりしている。例えば大教会。チートコードを使って上の階に先に行ったとしてもハバルクは待ってないし、少し手前の２つ目の壁を壊すシーンでは、ランド母を助ける前に壁を壊してしまってもストーリーは進まない上に、その後にランド母を助けても壁は復活していないのでイベントが進まない。ランド母の涙のシーンは回避不可能。コード的には、１つだけすぐ分かったものがある。ナマンダ寺院へお祈りに行くシーンのフラグ管理値変化は、アドレス：７Ｅ５５Ｄ４が１６進数値で０７（寺院に入る前）→２７（入る許可をもらって入り口の係がどいたシーン）→２Ｆ（お賽銭を１回以上入れた）。ここの値＝２Ｆの時、ランド母がさらわれる。ストーリー管理フラグはきっとこの周囲の何十アドレスかで構成されているのだろう。さすがに調べようとは思わないが、メモリ破壊系ＴＡＳで生きたりするのだろうか。

・アスパーの「自然」のうち、いまだ効果がはっきりしていないのは「ハナガサイタ」。草原フィールドで使用すると花が咲くことがあるが、花が咲く前後でメモリ観察をしてみると、どうやら花が咲くと敵全体の攻撃力・守備力・行動力が大幅減少しているようだ。ラグナライダーに試したところ攻撃力が４００→２００、守備力が２０８→１０４、行動力が２３０＋α（雑魚戦においては敵行動力に各個体ごとに数ポイントの＋補正あり）→１１５（＋α補正打ち消し）と、それぞれ５０％減少している。これはラグナライダーほどの耐性持ちでも無視して効果発揮するという証左でもある。発動すれば超難敵→ちょっと強敵程度まで能力が落ちる。まぁ、草原＝ワールドマップで、ワールドマップにボスはいないから問題ないといえば問題ないのか。

・対して、土アスパーの「花」の効果は、「使用後４ターン（使用ターンを含むと５ターン）ひとり突撃をかます代わりに、次ターンから４ターンの間のみ攻撃力２倍、防御５０％、素早さ２倍」となっている。この「攻撃力２倍」は素のステータスにかかるもののギガートが更にかけられる。その上、「ステータス５１１キャップ」を超過する。このキャップを超過できるのはアスパーの花だけ（「必殺」は単に与ダメが２倍になるだけ［＝元々の攻撃力が相手守備力を超えてないとダメージは１〜４］なので攻撃力は変化していない。力ため系の技でも一時的にキャップは突破できるが、ステータス上でも突破しているのは花だけ）。

・ブレス２では俗に「反撃必殺」と呼ばれる現象が起きる。これは「必殺が先に出たキャラの、そのターンの反撃は全て必殺になる」というバグのようなものだが、これが起きる原理はいたって単純。「必殺」は「一時のステータス異常」に区分される特別な状態で、「攻撃をした時、その異常になっていたら必殺扱いで与ダメ（≠攻撃力）２倍」という処理になる。この状態になるのは「通常攻撃を仕掛けた時に一定確率（または確定で必殺魔法になる一部攻撃アイテムを使用した時）」であるものの、その「［必殺］状態を消す」という処理はターン終了時まで行なわれない。おそらくは、単に「０」としてしまうと他の「防御」や「ペポーパ」などの異常も一緒に消してしまうことになるが、代わりの方法である「異常値が１６進数で８０以上なら、攻撃処理終了後に１６進数で８０だけ減算する」という処理をしなかった「手抜きなプログラム」の結果だろう。

・サルバドルが仲間の石像を作るのに要する時間は、プレイ時間で１０分。これは管理上は「借りた瞬間（「借りますぞ！」という会話ウインドウを閉じて仲間補充のためのメンバー選択に入った瞬間）のプレイ時間」を別アドレスに書き込み、ワールドマップ描画時に１０分以上経過していれば、あるキャラの石像が建つフラグを特定アドレスに加えて（コードは既出）、仲間を借りてるフラグを消す・・・という処理をしている。アドレス：７Ｅ５０２９〜２Ａまでが借りた時の「時間」、７Ｅ５０２Ｂが借りた「分」。ちなみに実プレイ時間は別管理されていて、アラビア風の酒場の客から聞けるのは「？？時間？分」までだが内部カウントは「？？時間？分？秒？？フレーム（６０フレームで１秒）」までされている。「リアル時間」とほぼ連動しているものの、一部例外あり。エンカウントした時、ワールドマップから街・洞窟などへ入る時やワールドマップに出る時、コマンド画面を開く時・・・　などには画面の暗転が入る。この暗転している間はプレイ時間は進まない。

・カセットＲＯＭ内の話。敵データの部分はおそらく、
（１行目）敵データの名前１〜８文字目（１文字１バイト。英語版では、おおむね現実の半角ＪＩＳコードと同様のコード、日本語版ではひらがな・カタカナが特定の文字コードで内部的に定義されている）、最大ＨＰ２バイト、最大ＡＰ２バイト、運の良さ（敵のレベル？）１バイト、攻撃力基本値２バイト、守備力基本値下位１バイト、
（２行目）守備力基本値上位１バイト、素早さ基本値２バイト、賢さ（ハンドブックのＭｓが−３＝賢さ７、＋４＝賢さ０）０〜７の１バイト、経験値２バイト、ゼニー２バイト、ドロップパターン０〜６２［ハンドブックの順番通り］の１バイト、属性（01：ｇｈｏｓｔ、02：ｆｉｒｅ、04：ｗａｔｅｒ、08：ｉｃｅ、10：ｆｌｙ、20：ｕｎｄｅａｄ、80：ｈｕｍａｎ）。ここまでは確認済で、残り６バイトは？？？？？？・・・最初１バイトはトレジャークラス［頭の４ビットで確率０〜７、後ろの４ビットは何なんだろう・・・？　レアアイテム出現比率ではなさそうだし、再抽選の確率だったりするのか？］、残り５バイトがＡＩ？（１バイト目と３バイト目で行動パターンが決まっているような・・・？、２バイト目は、何かメッセージを出す敵の場合に００ではなくなってるような、そうでもないような・・・　残り２バイトが分からない）との情報が。ホントかなぁ。なお、ハンドブックに記載がない「ガニメデ」の運の良さ（敵のレベル？）は５５。
　・・・の３２バイト構成。これが順に並んでおり、ここのデータを戦闘中ステータス管理メモリに読み込んで使用する。

・戦闘時の可変パラメータを管理している区画は、おそらくアドレス：７Ｅ０Ｆ００から始まっている。例えば７Ｅ０Ｆ７０は「コマンド入力を終えた人数」（プレイヤー４名→敵　の順）、７Ｅ０Ｆ７０２〜７Ｅ０Ｆ７Ｂまでの１０バイトで「行動者」（「コマンド入力順」→全員完了後に「行動力順」に並び替えられる）。戦闘ターンが始まると、７Ｅ０Ｆ７０が０になり、１人行動ごとに１ずつカウントアップ。全員行動を終えたら１５（１６進数値０Ｅ）が入ってターンエンド、となる。７Ｅ０Ｆ１９は経過ターン数（エンカ直後のターンは０ターン目）。敵の数は７Ｅ０Ｆ２４で初期数（なぜか２倍管理）、７Ｅ０Ｆ２４で現在数（なぜか２倍管理：倒した処理をすると倒した数だけ減る）？。
　ここからは裏が取れていないので推測ばかりの話。いわゆる「２回攻撃バグ」はここを見ていたら何か分かるかもしれない？　また、初出敵か（倒したことがある敵か）どうか、ボスフラグも敵ごとに管理している訳ではなく（敵ＩＤがこれ以上だからボスである、という管理の可能性は残る）、別の何かで管理している。ＢＧＭ変化とも対応している・・・　気はする。