～ＭＯＫＵＺＩ～
ＢＧＭの不具合を修正
ＢＧＭの不具合を修正２
音のＩＤ一覧
文字コードの一覧
水上で立ったまま釣りを始める不具合を修正
敵（動物）のＩＤ一覧
魚のＩＤ一覧
釣りメモのＲＡＭ配置
びくのＲＡＭ配置
動物とのエンカウント
与ダメージ計算式
被ダメージ計算式
体力と経験値の最大値
与ダメージがオーバーフローする不具合を修正
ＢＧＭの不具合を修正３
魚の体長算出ルーチン
大物が釣れる確率
現在フィールドに存在する魚データの初期化ルーチン
画面範囲内に存在する魚配列の初期化ルーチン
魚のアタリ判定ルーチン
ファイト中の魚の挙動について
フィールドにおける魚の生成時の座標範囲マップ
ＢＧＭの不具合を修正
釣り中はＢＧＭが川のせせらぎに変わりますが、釣りをしているときに釣りメモを開いてから閉じると、フィールドのＢＧＭに戻ります。
フィールドに戻ったときにも釣りは継続中ですから、本来はせせらぎ音が流れるハズでは・・・？
大した問題ではありませんが、なんとなくこれを修正してみました♪（*＾＿＾*）
釣りメモを閉じたときに、釣り中であってもなくてもフィールドのＢＧＭを鳴らすようになっているのが原因です。
したがって、釣りメモを閉じたあとで、釣り中かどうかの判定を行い、釣り中ならば川のせせらぎ音を鳴らすようにすればいいです。
バンク０の後半が空きエリアーとなっているようですので、ルーチンを０：３０００Ｈ（バンク０Ｈのアドレス３０００Ｈという意味。以下同様。）～に追加することにします。
そして、０：０ＦＤ５Ｈの「ＬＤ （０ＤＤ９ＥＨ），Ａ」を「ＪＰ ３０００Ｈ」に置き換えます。
３０００Ｈ～には以下のルーチンを書き込みます。
； 追加ルーチン ０：３０００Ｈ～
ＬＤ （０ＤＤ９ＥＨ），Ａ ； 元々の０：０ＦＤ５Ｈで行われていた処理
ＬＤ Ａ，（０ＦＦ９０Ｈ） ； ＲＡＭ領域ＦＦ９０Ｈの値の．．．
ＢＩＴ ２，Ａ ； ビット２が１なら釣り中
ＬＤ Ａ，（０ＤＤ９ＥＨ） ； 元のルーチンへ戻る前にＡレジスタの値をセット
ＪＰ Ｚ，０ＦＤ８Ｈ ； 釣り中ではないときはここで元のルーチンへ戻る
ＬＤ Ａ，０ＦＨ ； 釣り中ならばここへ来る
ＬＤ （０ＤＤ９ＥＨ），Ａ ； （ＤＤ９ＥＨ）へ音のＩＤ？（０ＦＨ＝せせらぎ音）を格納
ＪＰ ０ＦＥ８Ｈ ； 元のルーチンへ戻る
これで、釣りメモを開いてからフィールドに戻ってきたときでも、釣り中ならちゃんとせせらぎ音が流れるようになります。
なお、釣り中かどうかの判定にＦＦ９０Ｈの値を用いましたが、（ＦＦ９０Ｈ）のビット２は釣り糸を垂らすと１となり、いざ魚とのファイトが始まると０になります。
ただし、上記のルーチンを追加することによって、別の問題が発生します！
タライに乗って渓流から上流湖へ初めて移動した際に、タライが壊れるイベントが発生しますが、釣り糸を垂らした状態で上流湖へマップ遷移すると、タライが壊れたあとも川のせせらぎが流れたままとなってしまいます。
釣りメモを閉じたときとマップが切り替わったときとで同じルーチンを通っていることが原因です。
修正前は、マップ遷移時には釣りをしている状態でもマップに応じたＢＧＭが流れるようになっていたため、上流湖へ移動した時点で、釣り糸を垂らしているかどうかに関わらず上流湖のＢＧＭが流れるようになっていました。
ところが、修正後のルーチンではマップ遷移後に釣り糸を垂らしている状態だと川のせせらぎが流れるようになっています。
そして、タライが壊れるイベントの発生時に川のせせらぎ音が流れている状態は想定されていないため、タライが壊れて歩行状態となった（＝（ＦＦ９０Ｈ）のビット２がリセットされた）あとでも新たに上流湖のＢＧＭが流れることはありません。
この問題を解決する方針としては、
１．タライが壊れた時点で（釣り中フラグが解除されたタイミングで）上流湖のＢＧＭを鳴らすようにする。
２．マップ遷移時には釣り状態を解除する。
３．上記の修正したルーチンを元に戻す。
などが考えられますが、３番目の方法だと、釣り状態のままマップ遷移をした際に、釣り状態であるにも関わらず川のせせらぎ流れないという、上記の釣りメモと同様の問題が発生してしまいます。
２番目の方法でもいいのですが、さすがにそこまで仕様を変えてしまうのはどうかという気がします。
１番目の方法だと「釣り中は川のせせらぎを鳴らす」かつ「釣り中ではないときはマップのＢＧＭを鳴らす」という両条件をともに満たしていて、例外を設ける必要がないので今回は１番目の方法で修正することにしました。
タライが初めに岩にぶつかったときに釣り中フラグとタライフラグが解除される（（ＦＦ９０Ｈ）＝０Ｈとなる）ため、ＢＧＭ切り替えのタイミングとしては、タライが初めに岩にぶつかったときが条件面的にも演出面的にも好都合です。
７：６９７５Ｈ～の３バイトを「ＪＰ ３０４０Ｈ」に置き換えます。
そして、３０４０Ｈ～に以下のルーチンを書き込みます。（空き番地ならどこでも可。）
； 追加ルーチン ３０４０Ｈ～
ＬＤ ＨＬ，０Ｃ９Ｂ６Ｈ ； 元々の７：６９７５Ｈで行われていた処理
ＩＮＣ （ＨＬ） ； ７：６９７８Ｈで行われていた処理をここで実行
ＬＤ Ａ，（０ＦＦ００Ｈ＋９０Ｈ） ； 釣り中フラグを取得
ＢＩＴ ２，Ａ ； 釣り中かどうか？
ＪＰ Ｚ，６９７９Ｈ ； 釣り中ではないならばＢＧＭの変更は不要
ＰＵＳＨ ＢＣ ； サブルーチン呼び出しに備えてＢＣレジスタを退避
ＰＵＳＨ ＤＥ ； サブルーチン呼び出しに備えてＤＥレジスタを退避
ＰＵＳＨ ＨＬ ； サブルーチン呼び出しに備えてＨＬレジスタを退避
ＲＥＳ ２，Ａ ； ＢＧＭ再生ルーチンを呼び出す前に．．．
ＬＤ （０ＦＦ００Ｈ＋９０Ｈ），Ａ ； 釣り中フラグを解除しておく
ＬＤ Ａ，３ＦＨ ； 上流湖のＢＧＭのＩＤ＝３ＦＨ
ＣＡＬＬ ０ＦＣ７Ｈ ； ＢＧＭ再生ルーチンをコール
ＰＯＰ ＨＬ ； ＨＬレジスタを復帰
ＰＯＰ ＤＥ ； ＤＥレジスタを復帰
ＰＯＰ ＢＣ ； ＢＣレジスタを復帰
ＪＰ ６９７９Ｈ ； 元のルーチンへ戻る
これで、釣りをしているときにタライが岩にぶつかったタイミングで上流湖のＢＧＭが流れるようになります。
釣り中フラグはこのルーチンのあとですぐに解除されるので（（ＦＦ９０Ｈ）＝０Ｈとなる）、ルーチン内でフラグを解除したまま元には戻していません。
また、ＡＦレジスタに関してはこのルーチンの後続処理にてどっちみち破壊されるため、退避は不要です。
ＢＧＭの不具合を修正２
セレクトボタンを押すとポーズをかけることができますが、ポーズ中にＢＧＭの一部の音が鳴ったままになることがあります。
これも大した問題ではありませんが、せっかくなので修正してみました！（*＾▽＾*）☆
ポーズはフィールドの移動中や魚とのファイト中だけでなく、会話中やマップ切り替えの途中でもかけることができます。
ポーズ中かどうか？の判定にはＣ９８４Ｈの値を使用しています。
（Ｃ９８４Ｈ）が非ゼロのときはポーズ中で、ゼロならばポーズ中ではありません。
上の修正（釣りメモの件）と同様に、バンク０の後半の空き領域にプログラムを追加することにします。今回は３０２０Ｈに追加しました。
１２ＤＦＨ～の３バイトを「ＪＰ ３０２０Ｈ」に置き換えます。
３０２０Ｈ～には以下のルーチンを書き込みます。
； 追加ルーチン ３０２０Ｈ～
ＯＲ Ａ ； （Ｃ９８４Ｈ）＝０か？
ＪＰ Ｚ，１２Ｅ２Ｈ ； ポーズ中ではないので元のルーチンへ戻る
ＬＤ Ａ，８０Ｈ ； ポーズ中ならばここへ来る
ＬＤ （０ＦＦ００Ｈ＋２６Ｈ），Ａ ； 音を消すための手続き
ＸＯＲ Ａ ； 音を消すための手続き
ＬＤ （０ＦＦ００Ｈ＋２５Ｈ），Ａ ； 音を消すための手続き
ＪＰ １２Ｅ６Ｈ ； 元のルーチンへ戻る
これで、ポーズをかけると鳴ったままの音が消えるようになります。
音を消すためのルーチンは、釣りメモを開いたときに音を消すルーチンを参考にしました。
なお、ポーズ切り替えのタイミングで音を消すだけだとうまくいきません。
マップ切り替えのタイミングでは音のフェードアウト処理がポーズ切り替え処理の後で行われるため、音に関するメモリーが上書きされてしまうからです。
１２ＤＦＨは定期的に通るので、やや強引な気もしますがここに挿入すると確実に音を消すことができます。
音のＩＤ一覧
音のＩＤをまとめてみました。
マップ切り替えなどのタイミングで（ＤＤ９ＥＨ）へ書き込むと好きな音を鳴らすことができます。
ＩＤは１６進数で表記しています。
音のＩＤ一覧
文字コードの一覧
文字コードをまとめてみました。
この文字の符号は何かな？と気になったときに参照してください。
文字コードの一覧
水上で立ったまま釣りを始める不具合を修正
タライを所持している状態で、Ｂボタンを押しながら水面に向かって十字キーを押すと、移動先の水面の上で釣りを始めるという現象を発見しました。
本来ならば水上ではタライが水に流されてゆきますが、この方法を利用すれば流されずに釣りをすることができます。
ゲームの進行には影響を与えませんが、いわゆる「バグ技」として悪用されうる不具合ですので修正してみました！（*＾＾*）☆
本来ならば移動中にマップチップの地形判定が行われ、進行先のマップチップの地形情報は（ＦＦＡＦＨ）に格納されます。
移動先が水面のとき、（ＦＦＡＦＨ）＝０となり、タライを所持していればタライに乗ります。
タライに乗っているときは（ＦＦ９０Ｈ）のビット３が１となり、乗っていないときは０となります。
なお、移動中には（ＦＦ９０Ｈ）のビット０が１となり、移動中ではないときは０となります。
十字キーとＢボタンが同時に押されると、釣りが始まるので（ＦＦ９０Ｈ）のビット３が１となりますが、このとき、移動中であるにも関わらず進行先の地形判定が行われません。
釣りをやめて釣り中フラグが解除されると、やっと形判判定が行われて、それから（ＦＦＡＦＨ）＝０となり、タライに乗り始めます。
したがって、この不具合を解消するためには、「釣り中は地形判定を行わない」のではなく、「『釣り中』かつ『移動中ではない』ならば地形判定を行わない」ようにすれば十分です。
このあたりのルーチンはバンク１の中で行われていますが、１：７０００Ｈ～が空き番地となっていますので、ここにプログラムを追加することにします。
そして、１：４ＡＢ３Ｈ～の３バイトを「ＪＰ ＮＺ，７０００Ｈ」に置き換えます。
１：７０００Ｈ～には以下のルーチンを書き込みます。
； 追加ルーチン １：７０００Ｈ～
ＢＩＴ ０，Ａ ； 釣り中かつ移動中かどうか？
ＪＰ Ｚ，４ＣＥ６Ｈ ； 釣り中だが移動中ではないときは地形判定を行わない
ＪＰ ４ＡＢ６Ｈ ； 釣り中かつ移動中のとき、地形判定を行う
これで十字キーとＢボタンを同時に押したときでも、進行先が水上ならばちゃんとタライに乗って釣りをするようになります。
元々、釣り中フラグと移動中フラグが同時に立つことはないという想定だったのでしょう。（；＾＾）
敵（動物）のＩＤ一覧
動物のＩＤとＨＰ、倒したときにもらえる経験値をまとめてみました。
ＩＤは１６進数で表記しています。ＨＰと経験値は１０進数で表記しています。
動物のＩＤ一覧
魚のＩＤ一覧
魚のＩＤと体長（最小値、基準値、最大値、幻湖最大値）、安静／抵抗時間の最短秒数および最長秒数、釣れるエサ／ルアー／フライをまとめてみました。
ＩＤは１６進数で表記しています。
魚のＩＤ一覧
釣りメモのＲＡＭ配置
釣りメモには釣り上げた魚の情報が記録されています。
これは（ＣＡＡ０Ｈ）～（ＣＢ３ＦＨ）に格納されています。
１種類の魚につき４バイトの情報で構成されていて、魚の種類は全４０種類ですから、４バイト×４０＝１６０バイトの領域となっています。
以下の表のアドレスは、ＣＡＡ０Ｈ＋魚のＩＤ×４を基準とした相対アドレスです。
| アドレス | 内容 |
| ＋０Ｈ | フラグ情報 ＦＦＨのとき：未釣り上げ 非ＦＦＨのとき：[０]大物フラグ／[１]育成フラグ |
| ＋１Ｈ | 体長の最高値 |
| ＋２Ｈ | 体長の平均値 |
| ＋３Ｈ | 釣り上げた総数 |
びくのＲＡＭ配置
びくの情報は（ＣＡ３３Ｈ）～（ＣＡ５２Ｈ）に格納されています。
１種類の魚につき２バイトの情報（順に、魚のＩＤと体長）で構成されていて、びくの最大容量は１６ですから、２バイト×１６＝３２バイトの領域となっています。
（ＣＡ３２Ｈ）には、びくの最大容量値が格納されています。
動物とのエンカウント
エンカウント判定は、一歩進むごとに１：５Ｆ３１Ｈ～のサブルーチンの中で行われています。
動物の出現する場所としない場所とがあり、出現する場所では毎歩１／６４の確率でエンカウントします。
与ダメージ計算式
プレイヤーが攻撃した際の敵に与えるダメージ量の計算は、６：６１Ａ９Ｈ～のサブルーチンの中で行われています。
与ダメージ量は次の計算式によって求められます。
与ダメージ量＝（（（プレイヤーのＨＰ／２＋｛０～３の乱数値｝）を２５６で割った余り）×｛２：弱点に当たったとき／１：弱点以外に当たったとき｝）を２５６で割った余り
このように書くとわかりにくいのですが、簡単にいうと、与ダメージ量は大体プレイヤーのＨＰの半分くらい、ということです。
しかし、この計算値はプレイヤーのＨＰ（（Ｃ９ＣＦＨ）と（Ｃ９Ｄ０Ｈ）にリトルエンディアンで格納されている）が２４９以下のときは整合性が取れているのですが、２５０以上になるとおかしなことになる場合があります。
たとえば、ＨＰが２５０のときの与ダメージ量は通常１２５～１２８の範囲ですが、弱点に当たったときはこれが２倍となるので、２５０～２５６となります。
ところが２５６だとオーバーフローするため、与ダメージ量が０となってしまいます。
被ダメージ計算式
プレイヤーが攻撃を受けた際に敵から受けるダメージ量の計算は、６：６３３１Ｈ～のサブルーチンの中で行われています。
被ダメージ量は次の計算式によって求められます。
被ダメージ量＝敵のＨＰ／２＋｛０～３の乱数値｝
敵のＨＰは１バイト値であるため、計算式もシンプルになっています。
与ダメージと違って、オーバーフローしておかしな値になったりすることもありません。
体力と経験値の最大値
たいりょくの最大値は経験値によって決まり、具体的には次の計算式（１Ｄ２ＤＨ～のサブルーチン）によって求められます。
たいりょくの最大値＝（経験値／１０）×３＋３０
ただし、この計算によって求めた値が９９９より大きいときは、上限値として９９９が設定されます。
よって、経験値が３２３０以上のとき、たいりょくの最大値は９９９となります。
経験値の加算処理は１Ｄ５ＤＨ～のサブルーチンで行われていて、上限値は９９９９となっています。
倒した動物の経験値をテーブルから取得し、その値を現在の経験値に累積してゆきます。
上限値（９９９９）のチェック以外に経験値の上昇を制限する処理はありませんので、根性があれば経験値を９９９９まで上げることは可能です。
したがって、たいりょくは２５０以上となり得るため、上記の与ダメージのオーバーフローの問題は実際に発生します。
与ダメージがオーバーフローする不具合を修正
この作品には攻撃力という独立したパラメーターはなく、体力が与ダメージを支配しています。
体力が増えるに連れて与ダメージは増えるのですが、体力の値によっては計算式中でオーバーフローが発生し、与ダメージが暴落する場合があります。
（詳しくは上記の「与ダメージ計算式」を参照してください。）
仮に、そういう仕様だといわれれば、そうなのかなあ・・・？という感じもしますが、「０ポイントのダメージをあたえた！！」と表示されるのは違和感があります。
しかも攻撃が弱点に当たったにも関わらず、かえって値がオーバーフローして与ダメージが暴落することもあり、これは不具合といわざるを得ないでしょう。
修正するにあたっては、「理論上２５５を上回る与ダメージ量となったときは、上限値として、与ダメージ量を２５５とする」という方針で対応することにしました。
たとえば、たいりょくが２５５で乱数値が１のときに攻撃が弱点に当たると、理論上の与ダメージ量は２５６となりますが、実際にはこれを２５６で割った余りの「０」が与ダメージとなります。
この場合には「２５５」が与ダメージとなるように修正します。
動物との戦闘などのルーチンはバンク６の中で行われており、６：７０００Ｈ～が空き番地となっていますので、ここにルーチンを追加することにします。
そして、６：６１Ｂ４Ｈ～の３バイトを「ＪＰ ７０００Ｈ」に置き換えます。
６：７０００Ｈ～には以下のルーチンを書き込みます。
； 追加ルーチン ６：７０００Ｈ～
ＣＰ ２Ｈ ； 体力＜５１２かどうか？
ＪＲ Ｃ，７００９Ｈ ； 体力＜５１２のとき、ＨＬを半分にする処理へ
ＬＤ ＨＬ，０ＦＦＨ ； 体力≧５１２のとき、割り算を行う代わりに．．．
ＪＲ ７００ＤＨ ； ＨＬを上限値の２５５に設定する
ＳＲＬ Ｈ ； ＠７００９Ｈ 体力＜５１２ならば．．．
ＲＲ Ｌ ； ＨＬを半分にする
ＬＤ Ａ，（０Ｃ９６ＤＨ） ； ＠７００ＤＨ 乱数値を取得して．．．
ＡＮＤ ３Ｈ ； ０～３の範囲に変換し．．．
ＡＤＤ Ａ，Ｌ ； ＨＬに加算する
ＬＤ Ｌ，Ａ ； （ＨＬへの加算処理）
ＬＤ Ａ，０Ｈ ； （ＨＬへの加算処理）
ＡＤＣ Ａ，Ｈ ； （ＨＬへの加算処理）
ＬＤ Ｈ，Ａ ； （ＨＬへの加算処理）
ＯＲ Ａ ； ＨＬ＜２５６かどうか？
ＪＲ Ｚ，７０１ＥＨ ； ＨＬ＜２５６のとき、値の加工は行わない
ＬＤ ＨＬ，０ＦＦＨ ； ＨＬ≧２５６のとき、ＨＬを上限値の２５５に設定する
ＰＵＳＨ ＨＬ ； ＠７０１ＥＨ ここで、ＨＬ＜２５６となっている
ＣＡＬＬ ５ＦＦ８Ｈ ； 弱点判定を行う
ＣＰ ２Ｈ ； 攻撃が弱点に当たったかどうか？
ＰＯＰ ＨＬ ； Ｌレジスタに与ダメージ量が格納されている
ＬＤ Ａ，Ｌ ； Ａ＝弱点ではないときの与ダメージ量
ＪＰ ＮＺ，６１ＣＥＨ ； 弱点に当たっていないとき、元のルーチンへ戻る
ＡＤＤ Ａ，Ａ ； 弱点に当たったとき、与ダメージ量を２倍にする
ＪＰ ＮＣ，６１ＣＥＨ ； ２倍してもオーバーフローしなかったので、元のルーチンへ戻る
ＬＤ Ａ，０ＦＦＨ ； ２倍するとオーバーフローしたので、与ダメージ量を上限値の２５５に設定して．．．
ＪＰ ６１ＣＥＨ ； 元のルーチンへ戻る
これで与ダメージがオーバーフローして暴落することはなくなります！（*＾＾*）☆
ＢＧＭの不具合を修正３
通常、宿屋に泊まるとＢＧＭが消えて、キー入力をするとプレイヤーが起床するとともに宿屋のＢＧＭが流れ始めます。
一方で、動物に襲われて倒れたとき（たいりょくが０になったとき）は宿屋からのスタートとなりますが、このとき元から宿屋のＢＧＭが流れていて、キー入力をするとプレイヤーが起床するとともに宿屋のＢＧＭが再度初めから流れ始めます。
これは不具合か仕様か微妙なところですが、宿屋のＢＧＭが止まって再度初めから同じＢＧＭが流れるというのはおかしな感じがするため、意図した演出ではなく不具合であるという判断をしました。
修正の方法は色々思いつきますが、今回は簡単に「たいりょくが０の状態で宿屋へ入ったときはＢＧＭを流さない」ように対応しました。
フィールド上でたいりょくが０となると自動的に宿屋へ送られるため、「たいりょくが０の状態で宿屋へ入る」という状況は、戦闘などで倒れた場合にしか起こり得ません。
宿屋へ入ったときの処理はバンク１の中で行われているので、１：７０１０Ｈ～にルーチンを追加することにします。
そして、１：４６６２Ｈ～の３バイトを「ＪＰ ７０１０Ｈ」に置き換えます。
； 追加ルーチン １：７０１０Ｈ～
ＰＵＳＨ ＨＬ ； 体力＝０かどうか？
ＬＤ Ａ，（０Ｃ９ＣＦＨ） ； （体力のゼロ判定処理）
ＬＤ Ｌ，Ａ ； （体力のゼロ判定処理）
ＬＤ Ａ，（０Ｃ９Ｄ０Ｈ） ； （体力のゼロ判定処理）
ＯＲ Ｌ ； （体力のゼロ判定処理）
ＰＯＰ ＨＬ ； （体力のゼロ判定処理）
ＬＤ Ａ，１８Ｈ ； 宿屋のＢＧＭのＩＤ＝１８Ｈ
ＣＡＬＬ ＮＺ，０ＦＣ７Ｈ ； 体力＞０の場合に限り、宿屋のＢＧＭを流す
ＪＰ ４６６７Ｈ ； 元のルーチンへ戻る
これで、たいりょくが０となって宿屋からの再スタートとなった場合はキー入力するまでは無音状態となります。
魚の体長算出ルーチン
魚の体長は、釣り上げたあとに６：４２Ｃ７Ｈ～のルーチンの中で算出されます。
まず、２１６０Ｈ～のテーブルから魚の種類ごとに決まっている基準体長を取得します。
そしてこの基準体長に対してばらつきを加減して体長が決定されます。
ばらつき量は基準体長によって異なり、５段階にわかれています。
ばらつき量（の絶対値）の最大値を定義するテーブル（ここでは仮に「ばらつきテーブル」と呼びます）には次のように５バイトが並んでいます。
ＤＢ ０２Ｈ，０４Ｈ，０７Ｈ，０ＣＨ，１２Ｈ
このテーブルにアクセスするためのインデックスは、次のように基準体長によって決まります。
（条件式が真のとき、インデックスは右の値となる。）
| 条件式 | ＩＤＸ |
| ０ｃｍ＜基準体長＜１１ｃｍ？ | ０ |
| １１ｃｍ≦基準体長＜２１ｃｍ？ | １ |
| ２１ｃｍ≦基準体長＜４１ｃｍ？ | ２ |
| ４１ｃｍ≦基準体長＜６１ｃｍ？ | ３ |
| ６１ｃｍ≦基準体長？ | ４ |
たとえば、イトモロコちゃん（ＩＤ＝１６Ｈ）の場合、基準体長が６ｃｍなのでインデックスは０となって、ばらつきテーブルの０番目の値「２Ｈ」が、ばらつき量（の絶対値）の最大値となります。
実際のばらつき量は「ーばらつき量（の絶対値）の最大値～＋ばらつき量（の絶対値）の最大値」の範囲内の値となり、これは乱数によって選ばれます。
体長は基準体長にばらつき量を加味した値となります。
イトモロコちゃんの場合だとばらつきの範囲は±２ｃｍとなり、体長は４～８ｃｍとなります。
ところで、現在のフィールドが幻湖のとき（（Ｃ９Ｄ７Ｈ）＝４Ｈのとき）は、この体長にさらにボーナス値が加わることになります。
（わたしはこれを「幻湖ボーナス」と呼んでいます。（笑））
ボーナス値にもばらつきがあり、通常のばらつき量とは別にボーナス値のばらつき量（の最大値）を定義するテーブルが定義されていて、そこでは次のように５バイトが並んでいます。
ＤＢ ０２Ｈ，０３Ｈ，０５Ｈ，０８Ｈ，０ＣＨ
アクセス用のインデックスは、通常のばらつき量を求めた際のインデックスと同じ値です。
なお、ボーナス値は体長に対して足されるのみで引かれることはありません。
よって、幻湖で釣れるイトモロコちゃんの体長は６～１０ｃｍとなります。
ちなみに、体長が（幻湖ではなく、通常の）最大値のとき、またそのときに限って大物と判定されます。
したがって、幻湖でのみ釣れるサイズの魚は、いくら大きくても大物とは判定されません。
それどころか、幻湖の大物サイズは魚の種類に関わらず６７ｃｍで固定となります。
これは不具合のようにも感じられますが、幻湖で釣った場合には大物判定を行わず、釣りメモの最大サイズだけが更新されるため表面上の問題は起こりません。
大物が釣れる確率
大物と判定される条件については上述した通りですが、ここでは大物が釣れる確率について述べます。
ただし、幻湖ボーナスについては考えないものとします。
ばらつきテーブルのアクセス用インデックスは基準体長によって一意に決まります。
そして、取得したばらつき量（の絶対値）の最大値から実際のばらつき量を求める際に乱数が用いられています。
以下の説明では、「ばらつき量の絶対値の最大値」のことを「絶対最大ばらつき量」と表記することにします。
絶対最大ばらつき量から実際のばらつき量を算出する手続きは次のようになっています。
- 絶対最大ばらつき量に１を足した値をＢＣレジスタへ格納する。
- 乱数値（（Ｃ９６ＤＨ））を取得してＡレジスタへ格納する。
-
とする。ただし、 はＡレジスタのビットｉのことであり、０または１のいずれかの値を取る。 - 乱数値（（Ｃ９６ＤＨ））を更新する。
- （Ｃ９６ＤＨ）のビット４が０のときはＨレジスタの符号を反転する。
１のときは反転しない。 - ここで、Ｈレジスタの中身が実際の（符号つきの）ばらつき量となっている。
たとえばイトモロコちゃんの場合だと、絶対最大ばらつき量は２なので、「大物が釣れる」ことは「実際のばらつき量が＋２となる」ことと同値です。
そして「実際のばらつき量が＋２となる」ことは「乱数値が１７１以上であり、かつ符号反転が行われない」ことと同値です。
よって、イトモロコちゃんの大物が釣れる確率は８５／５１２≈１６．６％となります。
ただしこの確率は、乱数値のどの値が選ばれる確率も等しいということが前提となっていることに注意してください。
ちなみに、かわのぬしの大物が釣れる確率は、１３／５１２≈２．５％で、イトモロコちゃんよりも大物が釣れにくくなっています。
これはぬしだから特別に大物が釣りにくいというわけではなく、基準体長が６１ｃｍより大きい魚はすべて大物が釣れる確率は２．５％となります。
現在フィールドに存在する魚データの初期化ルーチン
現在のフィールド内に存在する魚の情報（魚の種類（ＩＤ）、初期座標、個体数）は宿屋に泊まると初期化（生成）されます。
この初期化は３：４９０ＣＨ～のルーチンで行われます。
生息する魚の種類（ＩＤ）と初期座標の基準値、初期座標のばらつき量は３：５０８ＢＨ～のＲＯＭエリヤーにフィールド別のテーブル形式で定義されています。
（以降、このテーブルデータを「魚テーブル」と呼びます。）
魚テーブルの先頭アドレスは、フィールド別にそれぞれ次のようになっています。
渓流 ３：５０８ＢＨ～
上流湖 ３：５０ＣＣＨ～
清流 ３：５１５５Ｈ～
下流湖 ３：５１Ｅ６Ｈ～
幻湖 ３：５２ＢＦＨ～
魚テーブル内の情報１件あたりの構成は次のようになっています。
以下の表のアドレスは、魚テーブルの各データの先頭アドレスを基準とした相対アドレスです。
| アドレス | 内容 |
| ＋０Ｈ | 初期Ｘ座標の基準値を１６で割った値 |
| ＋１Ｈ | 初期Ｙ座標の基準値を１６で割った値 |
| ＋２Ｈ | 初期Ｘ座標のばらつき量の標準値 |
| ＋３Ｈ | 初期Ｙ座標のばらつき量の標準値 |
| ＋４Ｈ | 魚のＩＤ |
| ＋５Ｈ | ０Ｈ |
| ＋６Ｈ | ０Ｈ |
| ＋７Ｈ | ０Ｈ |
この魚テーブルを元にフィールド内に存在する実際の魚の情報が生成されて、ＣＣ０ＢＨ～のＲＡＭエリヤーに格納されます。
（以降、このＲＡＭ領域内に格納されているデータを「魚データ」と呼びます。）
魚１匹あたり８バイトで構成されていて、詳しい構成は次のようになっています。
以下の表のアドレスは、各魚データ（１匹分）の先頭アドレスを基準とした相対アドレスです。
| アドレス | 内容 |
| ＋０Ｈ | 魚の移動情報（ＬＯＷ） |
| ＋１Ｈ | 魚の移動情報（ＨＩＧＨ） |
| ＋２Ｈ | Ｘ座標（ＬＯＷ） |
| ＋３Ｈ | Ｘ座標（ＨＩＧＨ） |
| ＋４Ｈ | Ｙ座標（ＬＯＷ） |
| ＋５Ｈ | Ｙ座標（ＨＩＧＨ） |
| ＋６Ｈ | ＦＦＨ |
| ＋７Ｈ | ＦＦＨ |
魚テーブル内の情報１件に対して、６件の魚データが生成されます。
初期生成ルーチンの本質的な流れは次のようになっています。
上図のうち、「（ＨＬ）～（ＨＬ＋３Ｈ）の値を元に魚の初期座標および移動情報を算出～」の詳細は少々ややこしいのですが、結論だけを書くと次のようになっています。
ただし、ｍｏｄ はモジュロ演算を表しています。
- Ｘ座標の候補＝ （ＨＬ）×１６＋〔乱数値 ｍｏｄ ｛（ＨＬ＋２Ｈ）×８ ｍｏｄ ２５６｝〕×２
- Ｙ座標の候補＝（ＨＬ＋１Ｈ）×１６＋〔乱数値 ｍｏｄ ｛（ＨＬ＋３Ｈ）×８ ｍｏｄ ２５６｝〕×２
- 上記候補の座標におけるマップの地形判定を行い、水辺でなければ乱数値を再生成して候補値を選びなおす。
- 地形判定の結果が水辺ならば初期座標が確定する。
- 移動情報（ＬＯＷ）←乱数値＆００００００１１Ｂ，移動情報（ＨＩＧＨ）←０Ｈ とする。
各「魚データ」の先頭アドレスからＣＣ０ＢＨを引いて８で割ったときの商・・・これを「魚番号」と呼ぶことにする――を６で割ったときの商をインデックスとして、魚テーブルからＩＤを参照することができます。
実際に魚のアタリ判定では各魚データからそのようにして魚のＩＤを取得しています。
画面範囲内に存在する魚配列の初期化ルーチン
（ＣＢＥＤＨ）～の１２バイトには画面範囲内に存在する魚の魚番号が格納されています。（以降、この領域のことを「魚番号配列」と呼びます。）
ただし、「魚番号」は「魚のＩＤ」とは異なる概念です。
この魚番号配列に含まれている魚番号に対応する魚のみが移動制御の対象となって画面内を遊泳し、釣り上げることができます。
魚番号配列の初期化は、仕掛けのキャスト直後に３：４７Ｅ７Ｈ～のサブルーチンの中で行われます。
ＲＡＭエリヤー内の各「魚データ」に対応する魚番号は、アドレスの小さい方から順に０、１、２、・・・、となりますが、これを一般にｉと表し、魚番号ｉの魚のＸ座標をＸｉ、Ｙ座標をＹｉとそれぞれ表すことにすると、
- 描画画面範囲の左端のＸ座標≦Ｘｉ＜描画画面範囲の右端のＸ座標
- 描画画面範囲の上端のＹ座標≦Ｙｉ＜描画画面範囲の下端のＹ座標
描画画面範囲の左端のＸ座標は（ＦＦＢ５Ｈ）に、上端のＹ座標は（ＦＦＢ９Ｈ）に格納されています。
また、ゲームボーイの画面の大きさは横１６０×縦１４４ドットになっていますので、上記の条件は次の表現と同値です。
- （ＦＦＢ５Ｈ）≦Ｘｉ＜（ＦＦＢ５Ｈ）＋１６０
- （ＦＦＢ９Ｈ）≦Ｙｉ＜（ＦＦＢ９Ｈ）＋１４４
十分性を主張するためには次の２つの条件をも同時に満たさなければなりません。
- 魚番号ｉの魚データの先頭アドレスの中身の値がＦＦＨではない。
- 魚番号配列に格納済みの魚番号の件数が１２未満である。
ＦＦＨではないときはフィールド内に存在します。
魚番号配列には最大で１２件の魚番号が格納されます。
そのため、たとえ座標に関する条件を満たしていても魚番号配列に魚番号が１２件追加されていると、それ以上追加されることはありません。
つまり画面範囲内に同時に出現する魚は最大で１２尾となります。
以上の４条件を同時に満たすことが、魚番号ｉの魚が画面内に存在するための必要十分条件となります。
魚番号ｉの魚が画面内に存在するとき、魚番号配列にｉを格納します。
この手続きをすべてのｉに対して行って画面内に存在する魚の一覧を決定します。
魚のアタリ判定ルーチン
３：４ＣＡＦＨ～のルーチンにおいて、魚番号配列内に格納されている魚番号に対応する各魚に対して、８フレーム（約１３３ｍｓ）に１度の定間隔で仕掛けとの"アタリ判定"を取っています。
細かい部分については省略しますが、本質的には次の４つの条件をすべて満たすとき、またそのときに限って対象の魚がかかります（ピピ音が鳴って魚が仕掛けのまわりを回って仕掛けが沈む）。
- 乱数値の下位４ビットが０（１／１６の確率）。
- ウキのＸ座標と魚のＸ座標との差の絶対値が７未満である。
- ウキのＹ座標と魚のＹ座標との差の絶対値が７未満である。
- 仕掛け（エサｏｒルアーｏｒフライ）の条件が合致している。
仕掛けの条件が合致していて、かつ魚が仕掛けの近くにいるにも関わらず魚がかからない場合は、確率による条件で弾かれています。
仕掛けの条件では、合致するか合致しないかのどちらかであり、「食いつきやすさ」のような違いはありません。
仕掛けの合致条件は魚のＩＤごとに決まっていて、２１５ＤＨ～のテーブルに定義されています。
このテーブルデータでは魚１種類あたりの情報が４バイトで次のように構成されています。
以下の表のアドレスは、各魚の情報の先頭アドレスを基準とした相対アドレスです。
| アドレス | 内容 |
| ＋０Ｈ | 釣れるエサ |
| ＋１Ｈ | 釣れるルアー |
| ＋２Ｈ | 釣れるフライ |
| ＋３Ｈ | 基準体長 |
現在の釣りの種類がウキ釣りｏｒ投げ釣りならばエサの条件が、ルアー釣りならばルアーの条件が、フライ釣りならばフライの条件がそれぞれ適用されます。
現在の釣りの種類は（Ｃ９ＥＡＨ）に格納されていて、０：ウキ釣り／１：投げ釣り／２：ルアー釣り／３：フライ釣り となっています。
各条件は１バイトで、それぞれのビットが食いつく／食いつかないの判定条件を正論理で表しています。
エサの判定条件におけるビット割り当ては次のようになっています。
| [７] | [６] | [５] | [４] | [３] | [２] | [１] | [０] |
| ミミズ | サシ | こんちゅう | アカムシ | カワムシ | ネリエ | こざかな | カエル |
ルアーの判定条件におけるビット割り当ては次のようになっています。
| [７] | [６] | [５] | [４] | [３] | [２] | [１] | [０] |
| スピナー | スピナーベイト | ミノー | クランクベイト | ホッパー | スプーン | ワーム | カエル |
フライの判定条件におけるビット割り当ては次のようになっています。
| [７] | [６] | [５] | [４] | [３] | [２] | [１] | [０] |
| メイフライＷ | メイフライＤ | カディスＷ | カディスＤ | ディプテラＷ | ディプテラＤ | ストーンフライＷ | ストーンフライＤ |
たとえばイトモロコちゃん（ＩＤ＝１６Ｈ）の場合、テーブルデータには９ＣＨ、８２Ｈ、ＡＡＨ、０６Ｈの４バイトが定義されていて、左から順にエサの判定条件、ルアーの判定条件、フライの判定条件、基準体長となっています。
仮にエサの判定条件について見てみると、９ＣＨ＝１００１１１００Ｂとなっていて、正論理ですから、「ミミズ」「アカムシ」「カワムシ」「ネリエ」には食いつき、これら以外のエサには食いつかない、という具合になっています。
ファイト中の魚の挙動について
ファイト中の魚の挙動に関するルーチンはバンク６の中にまとめられています。
ファイト中に魚が仕掛けに食いついているとき、魚が仕掛けを左に引っ張って逃げようとする「抵抗状態」と、魚が静止していてプレイヤーが右に引っ張ることのできる「安静状態」とを交互に繰り返します。
これらの状態間の遷移は、（ＣＢＢＢＨ）～（ＣＢＢＣＨ）に格納されている値（以降、これを「タイマー値」と呼びます。）がゼロになったときか、プレイヤーがＢボタン（Ａボタンでも同様）から指を離したときに行われます。
Ｂボタンの押下状況による状態遷移は６：４Ｂ４４Ｈ～のサブルーチンの中で行われ、次のような流れになっています。
上図ではタイマー値の値が変化する箇所を赤背景にしています。
このサブルーチンは毎フレーム呼び出されます。
前フレームでプレイヤーが引っ張っていたかどうか（プレイヤーの引っ張りフラグ）と現フレーム時におけるＢボタンの押下状況によって、大別して４つのルートに分岐します。
なお、ファイト中の状態に関する各種のフラグは（ＣＢＢ９Ｈ）に格納されています。
（ＣＢ９９Ｈ）のビット割り当ては次のようになっています。
| ビット | 内容 |
| [０] | 魚の状態（１：安静状態／０：抵抗中） |
| [６] | 魚に逃げられたあとかどうか （１：逃げられた／０：逃げられていない） |
| [７] | プレイヤーの引っ張りフラグ （１：引っ張っている／０：引っ張っていない） |
前フレームでプレイヤーが引っ張っておらず、現フレームでも引っ張っていない（Ｂボタンが押されていない）ときは、このルーチン内では何も処理されません。
前フレームでプレイヤーが引っ張っていなかったものの、現フレームでＢボタンが押されたとき、プレイヤーの引っ張りフラグを立てて（（ＣＢＢ９Ｈ）[７]←１）、「ピピ限界時間＞０？」の判定を行います。
「ピピ限界時間」はわたしの造語ですが、これは「魚の抵抗中にＢボタンを押し続けていられる時間（カウンター）」のことを指しています。
この値は（ＣＢＣＤＨ）に格納されています。
魚の抵抗中にＢボタンを押して魚を引っ張ると「ピピーーー！！」という音が鳴りますが、このままピピ限界時間までずっとＢボタンを離さずに押し続けていると魚に逃げられてしまいます。
ピピ音が鳴っているときにＢボタンを押し続けている時間（カウンター）は（ＣＢＣＢＨ）に格納されています。
（ＣＢＣＤＨ）≧０ですが、ハリの大きさが魚に合っていないとき、またそのときに限り、（ＣＢＣＤＨ）＝ピピ限界時間＝０となります。
ハリの大きさが合っていないときに引っ張ると、魚は問答無用で即逃げます。
一般にピピ限界時間は魚の大きさ（対象の魚の基準体長を１０で割ったときの商）とハリの大きさによってのみ一意に決まり、次の表中の値となります。（６：４５Ａ２Ｈ～）
ただし、この表における値はすべて１０進数で表記しています。
| ／１０商 | ０ | １ | ２ | ３ | ４ | ５ | ６ | ７ | ８ | ９ | １０ | １１ | １２ | １３ | １４ | １５ |
| ハリ小 | ４０ | ５０ | ６０ | ４０ | ０ | ０ | ０ | ０ | ０ | ０ | ０ | ０ | ０ | ０ | ０ | ０ |
| ハリ中 | ０ | ０ | ０ | ４０ | ５０ | ６０ | ５０ | ４０ | ０ | ０ | ０ | ０ | ０ | ０ | ０ | ０ |
| ハリ大 | ０ | ０ | ０ | ０ | ０ | ０ | ４０ | ５０ | ６０ | ５０ | ４０ | ４０ | ４０ | ４０ | ４０ | ４０ |
たとえば、イトモロコちゃんの場合だと基準体長が６（ｃｍ）なので、１０で割ったときの商は０ですから、ハリ小のときのピピ限界時間は４０となります。
ハリ中やハリ大のときは０となり、ハリが合わないということになりますので、イトモロコちゃんは即逃げてしまいます。
（そういうところも可愛いです。（*´ω`*））
ちなみに、ルアー釣りｏｒケバリ釣りのときのピピ限界時間は一律で６０となります。
ルート分岐の話に戻ります。
ピピ限界時間＞０のとき、ピピ音が鳴っているときにＢボタンを押し続けている時間（（ＣＢＣＢＨ））を０に初期化し、魚が抵抗中ならばピピ音が鳴った回数（（ＣＢＥ０Ｈ））をインクリメントします。
魚が安静状態ならばピピ音は鳴らず、プレイヤーが魚を右に引っ張ることになります。
なお、ピピ音が鳴った回数が８以上になると魚とのファイトが終わったときにハリやルアーが壊れてしまいます。
前フレームでプレイヤーが引っ張っていて、現フレームでも引っ張っている（Ｂボタンが押されている）とき、魚が安静状態ならばこのルーチン内では何も処理をせずに魚を引っ張り続けます。
魚が抵抗中のとき、（ＣＢＣＢＨ）＜ピピ限界時間ならば（ＣＢＣＢＨ）をインクリメントします。
（ＣＢＣＢ０Ｈ）≧ピピ限界時間ならば魚は仕掛けから離れて逃げてしまいます。
前フレームでプレイヤーが引っ張っていたものの、現フレームでは引っ張っていない（Ｂボタンが離された）とき、プレイヤーの引っ張りフラグを解除し、魚は抵抗状態へ遷移します。
続いてタイマー値の設定が行われます。
設定されるタイマー値は正の値で、単調減少しますので、設定される値が小さければ抵抗時間は短くなってあまり遠くまで仕掛けを持って行かれずに済みます。
設定される値が大きくなるほど抵抗時間は長くなり、遠くまで仕掛けを持って行かれて逃げられる可能性が高くなります。
この設定される値・・・「抵抗時間」の基準値は６：４５Ｄ２Ｈ～のテーブルに魚のＩＤごとに定義されています。
抵抗時間には学習値が存在し、（ＣＢＣ５Ｈ）～（ＣＢＣ６Ｈ）にリトルエンディアンで格納されています。
抵抗時間の学習値は「基準値」で初期化されていて次第に減少してゆきます。（詳しくは後述します。）
学習値の最小値は「基準値／２」であり、抵抗時間の決定アルゴリズムは上のフローチャートに示した通りです。
抵抗時間（と後述する安静時間）については 魚のＩＤ一覧 にまとめました。
タイマー値が設定されたあとで魚の移動速度を決定していますが、この値は符号つきであるため、ＦＤ００ＨとＦＥ００Ｈとでは、ＦＤ００Ｈの方が絶対値が大きくなります。
移動速度（の絶対値）は小さいほどあまり遠くまで仕掛けを持って行かれずに済みますので、ピピ音が鳴ったら早めにＢボタンを離すことが重要です。
次に、タイマー値がゼロになったときの状態遷移について説明します。
タイマー値のデクリメントおよびゼロになったときの状態遷移は６：５２７ＢＨ～のサブルーチンの中で行われ、次のような流れになっています。
タイマー値がゼロになったとき、安静状態ならば――つまり安静状態が終わった直後ならば、抵抗時間と移動速度を決定し、抵抗状態へ遷移します。
プレイヤーが引っ張っているときに抵抗状態に遷移した場合はピピ音が鳴ります。
抵抗時間（タイマー値）は１／４の確率で基準値×２となり（最長抵抗時間）、これまた１／４の確率で基準値／２となります（最短抵抗時間）。
残りの１／２の確率でタイマー値＝学習値となります。
学習値が基準値／２より大きければ学習値から１６を引いた値を新たな学習値として更新し、タイマー値＝更新後の学習値となります。
学習値が基準値／２以下のときは学習値の更新は行われません。
つまり、抵抗時間の学習値は次第に減少してゆき、下限は「抵抗時間の基準値／２」です（厳密には「抵抗時間の基準値／２ー１５」）。
タイマー値がゼロになったときに抵抗状態ならば――つまり抵抗状態が終わった直後ならば、安静時間を決定し（移動速度は０）、安静状態へ遷移します。
安静時間（タイマー値）は１／４の確率で基準値／２となります（最短安静時間）。
安静時間の基準値は６：４５Ｄ２Ｈ～のテーブルに魚のＩＤごとに定義されていて、抵抗時間の基準値とは別の値です（たまたま同じ値となる場合はある）。
残りの３／４の確率でタイマー値＝学習値となります。
抵抗時間と同様に安静時間にも学習値が存在し、（ＣＢＣ３Ｈ）～（ＣＢＣ４Ｈ）にリトルエンディアンで格納されています。
（安静時間の）学習値が基準値×２未満のときは学習値に１６を足した値を新たな学習値として更新し、タイマー値＝更新後の学習値となります。
学習値が基準値×２より大きいときは学習値の更新は行われません。
つまり、安静時間の学習値は次第に増加してゆき、上限（最長安静時間）は「安静時間の基準値×２」です（厳密には「安静時間の基準値×２＋１６」）。
なお、このサブルーチン（６：５２７ＢＨ～）は魚の静止中（安静状態かつプレイヤーが引っ張っていないとき）は毎フレーム呼び出されますが、プレイヤーが引っ張っているときは４フレームに１度しか呼び出されません。
したがって、たとえば安静時間が０．７５秒だとしても、魚が静止してからすぐにＢボタンを押せば３秒間引っ張ることができます。
フィールドにおける魚の生成時の座標範囲マップ
魚の生成時の座標範囲をマップ上にまとめてみました。
魚の分布マップ