アクセスログを確認していて、GET パラメータの最後に "2121121121212.1" を追加している怪しいログが時々あることに気づきました。一番古いもので 2017 頃から確認でき、ネット検索するとその攻撃（？）の形跡みたいなのがたくさん出てきます。SQL インジェクションで使われるマジックナンバーなのか分かりませんが、とりあえずこれが挿入されたらアクセス拒否するようにしておこうと思います。
0 件のコメント
してログ
プログラムで16進をよく使うので、常々あったらいいなと思っていたガジェットにN進数対応の電卓があります。機能的には Windows の電卓で十分だけど、手元で計算したいことも多く探しておりました。この Canon F-60G がこれ以外ないというくらいマッチしていて、同様に探している人にはお勧めです。
関数電卓ほど仰々しくなく、片手すっぽりの事務用電卓と同サイズで価格も1000円とコスパもすばらしい。
16進表示
商品紹介とかに16進表示の画面が無く７セグメントでどう表示されるのかは、買って確かめるまで分かりませんでした。どう表示されるかというと「AbCdEF」のように大文字小文字で表現されます。
スライドカバーの使い道
スライドカバーが付いていて、表と裏で装着できるのですが、キーを表にして装着したときに上 1/3 くらいの隙間に資料をクリップできるようになっています。説明書に記載が無いのでそういった使い方を意図しているのか分かりませんが、これがすごく便利に使えます。手帳型でないのがイマイチかなと思ったのですが、断然こちらのほうがいいと思います。
関数電卓なので
様々な計算モードや表示モードがあり、すべて使いこなすのは難しそうです。ただ、個人的によく使う計算（度分秒の変換、時間の計算など）ができるということなので、うまく使えるようになりたいと思います。
気になる点
なかなか良い商品であることは間違いありませんが、あえて気になる点を挙げてみました。関数電卓なので仕方ないとは言え、N進数計算に特化した商品があってもいいと思います。
- 液晶画面が少し小さい
- 16進で使うA～Fのボタンの位置と表示が分かり難い
- N進数モードの表示が小さくて分かり難い
- ２進数にしたときの桁が少ない（10進で511までなので2バイトの計算は無理）
総合評価：★★★★★
タイヤ交換ついてでに、金額合わせに買っておいたタイヤマーカーペンを使って、ホワイトレターを入れてみました。ペン先が結構太いので慣れるまでが大変でしたが、文字のエッジ部分は書くというよりは撫でるように色を乗せていく感じにしたら、それほど難しくはありませんでした。書く前に十分ペン先を突いて染み出させて、試し書きして量を調節しておくのがポイントかなと思います。
今回、初めて入れてみましたが、見た目の仕上がりもなかなか良いし、運転するのが楽しくなるドレスアップだと思いました。履いているタイヤだと書くには難しいので、タイヤ交換のこの機会に入れてみてはいかがでしょうか。
表ゼビウス
アーケード版ゼビウスでは自動難易度設定が導入され、プレイする度に内容が異なるようになっています。これが効果的に機能しているかは微妙ですが、「完全にパターン化できないがある程度調整可能」といった独特のプレイ感覚になっています。詳しい説明は他所に譲るとして、これには 0～127 で定義される攻撃パターンテーブルを指すポインタを増減させることによって実現しています。
先日気づいたことに「偶数番の攻撃コードだけが使用されているのでは無いか」ということがあります。理由は単純で、この増減の幅がひとつを除いて偶数になるためです。奇数になるのは、マップ上の決められたチェックポイント通過時に「出撃１機あたりのスコアが１万点以下（厳密には少し違う）でスコアの千の位が奇数のとき」だけになります。普通にプレイしている限り、この条件に該当するのは無いに等しく、結果として偶数攻撃コードの「表ゼビウス」が進行して行きます。
ポインタの増減
マップの進行による増加と、プレイヤーの行動による減少によってゲームが進行していきます（表は難易度がノーマル設定の場合）。
| イベント | 増減値 |
|---|---|
| 空中物出現時（固定以外） | 2増加 |
| 決められたチェックポイントを通過する | プレイ内容によって最大16増加 |
| ゾルバクを破壊する | 2減少 |
| 残機を失う | 16減少 |
だいたいエリア２序盤付近で２万点を超え、ある程度上達するとミスもしなくなるため、以降のチェックポイントでは毎回最大値（16）増加することになります。また、チェックポイントはエリア１で４箇所、エリア２で０箇所設定されていますが、エリア１の設定箇所は２個ずつ連続していて「奇数判定されても×2で偶数」になってしまいます。ただし、ごく稀に連続したチェックポイントの間でスコアが変動した場合のみ奇数になることはあり得ます。
裏ゼビウスへの入り方
意図的にプレイしてチェックポイントで奇数判定させれば、奇数番の攻撃コードで進行する「裏ゼビウス」に移行できます。エリア１は意図的にこれを行うのは難しく、エリア２は設定されていないため、次に設定されているエリア３のスペシャルフラッグゾーン付近で調整します。
- エリア3のスペシャルフラッグゾーン時点でのスコアを９、７、５、３、１千点代の何れかに調整する
- 例えば空中物ノーショットで、エリア１のスペシャルフラッグ、エリア２までのソル全出現で９千点
- スペシャルフラッグゾーン直後の空中物が出現すれば、奇数判定済みなのでスぺフラも空中物も普通に撃って大丈夫
- これ以降普通にプレイすれば「裏ゼビウス」のまま維持される
表と裏の違い
ほとんど違いはありませんが、いくつかの攻撃テーブルで敵機の数が１つ多く設定されています。良く分かるのがブラグザカートで、表ゼビウスでは１個、裏ゼビウスでは２個ずつ出現します。また、テラジの最大機数が１機多い５機となっており、総じて裏ゼビウスのほうが難易度が高くなります。詳しくは、以下の攻撃テーブル表で確認してください。
総攻撃 A3 も
奇数コードなので A3 は当初出せないと思いましたが、裏ゼビウスに移行してからエリア12まで行くことで出すことに成功しました。研究され尽くされていると思っていましたが、まだまだ色々とありますね。
追記：ファミコン版でも確認
ファミコン版ゼビウスでも同様のプレイをすることで、出現テーブル上のブラグザカートが２個ずつ出現するのを確認できました。この部分はアーケードの出現テーブルとロジックを忠実に移植しているようです。
またファミコン版はスコアに1000万の桁が存在しますが、チェックポイントでは100万以下の桁を計算に使用しているようです。このため、1000万点の超えた直後のチェックポイントで偶数奇数のレーンチェンジが起こる可能性があり、これが1000万点ごとに繰り返されると思われます。
追記：通常プレイで奇数パターンを確認
偶然に奇数パターンになったプレイの動画が撮れたので YouTube にアップロードしました。条件は推測していたので検証してみたところ、推測どおりの内容を確認できて確信できました。
奇数パターンに移行する可能性があるのはエリア１の２箇所で、ここはチェックポイントが間髪入れずに２個連続しています。スクロール位置がぴったり図の画面になった瞬間に、千の位の偶奇が変化すると奇数パターンに移行します。他の箇所では点数が高くなりすぎて、常に＋16（最大値）と判定されるため、意識してプレイしない限り奇数パターンには移行できないと思われます。
（[ゼビウス] AC版ゼビウスに総攻撃がプログラムされていた (6) からのつづき）
調整方法の早見表
エリア11の攻撃パターンの組み合わせから、エリア12で必要なテーブル調整方法をまとめてみました。なお、通常プレイでは偶数コード進行になるため奇数コードは除いています（奇数コードは参考資料を参照）。
追記：２パターンある場合があったので表を修正しました。
他のエリアでも再現可能
難易度設定によって、ミス時の減少値、空中物出現時の増加値が変わってくるため、HARD や HARDEST では他にも可能なエリアがありました。ただし、エリア3は HARDEST＋5機設定でないと難しい（チェックポイント通過時の判定を最大にするために点稼ぎも必要）です。
| 難易度設定 | 空中物出現時 （固定を除く） | チェックポイント 通過時（最大） | ゾルバク破壊 | 再スタート時 （ミス） |
|---|---|---|---|---|
| EASY | 0 | +16 | -2 | -24 |
| NORMAL | +2 | +16 | -2 | -16 |
| HARD | +6 | +16 | -2 | -8 |
| HARDEST | +16 | +16 | -2 | 0 |
- 空中物出現時に128以上かどうか判定されます
仕込み時の進行ポイントの目安
各進行ポイントまで進んでミスした場合、難易度設定毎に攻撃ポインタは下記のように変化します。
| エリア | 進行ポイント | EASY | NORMAL | HARD | HARDEST |
|---|---|---|---|---|---|
| エリア3 | スペシャルフラッグゾーンまで進行 | -8 | 0 | +8 | +16 |
| エリア12 | 斜めに道路が交差するあたりまで進行 | +8 | +16 | +24 | +32 |
| エリア13 | 埠頭の手前のゾルバク×4まで進行 | -8 | 0 | +8 | +16 |
注意など
ご自分の所有する基板、エミュレータ実装の市販ゲームなどでお試しください。ゲームセンターなどでは迷惑が掛かるのでやってはいけません。
追記：発動確認環境
エミュレータ実装のゼビウスであれば発動可能なので、逆にエミュレータなのか確認に使えると思います。最も移植精度の高いナムクラ、PS 3D/G+ は発動しないので移植作品だと分かります。
- アーケード基板
- NAMCO HISTORY VOL.1 (Window95/98)
- SUPER1500 ゼビウス (Windows95/98)
- ULTRA2000 ゼビウス (Windows95/98)
（[ゼビウス] AC版ゼビウスに総攻撃がプログラムされていた (5) からのつづき）
前回の検証で終わったはずでしたが、なんとプログラムの解析結果から未改造のゼビウスで総攻撃が発動する可能性があることが判明しました。ただし意図されたものでは無く、コード上のバグを利用して攻撃テーブルポインタをオーバーランさせることによって可能になります。
条件が成立するマップを探したところ１箇所だけ合致するポイントを発見しました。それがエリア12の冒頭部分で、ここは都合のいいことにテーブル調整が安定して行える正にうってつけのポイントでした。ほとんど同じ動きを最低５回繰り返す必要があるので、意図せず遭遇した人はいないと思いますが、まったく無いとも言えません。先日検証した巨大バキュラバグよりも、実は再現するのは簡単だと思います。
仕込み方法
再現条件は下記の通りで、普通にプレイしてフラグを立てることが可能です。攻撃パターンのチャートがあれば、テーブルの数値を頭で計算しながら調整できます。
- エリア12まで行く（残機はある程度必要です）
- エリア12の開始時に、空中物のテーブルポインタを調整しておく（直前のエリア11で、テラジ×3、またはテラジ×4が理想）
- エリア12のゾルバクを破壊しないでバーラ４つの右側の道路を降りてくるドモグラムの弾（タイミングの目安なので別のドモグラムのでも良い）に当たってミスする
- この手順を５回繰り返す（テラジ以外は後述の回数で）
- ６回目はそのまま４本ソルのところまで行くと総攻撃が始まるはずです（失敗するとリセットが掛かるか、何も起こらない）
テーブル調整はテラジが一番分かりやすいのですが、他にも下記のような空中物を目安にすることができます。カッコ内はエリア12でミスをする回数を表しています。
- ジアラ（６回）
- カピ（７回）
- タルケン＋ジアラ（８回）
※目安なのでゾルバク調整が必要な場合があります（それぞれ４～６パターン同じ機種の数違いが続くのでポインタの数値を確定できません／上記でだいたい40%～50%の成功率です）
追記：追記のほうに書いた「ザカート＞ジアラ」で調整するのが確実です。
仕込み完了後に操作可能なリプレイファイルも用意しました。
具体的な調整方法
これはだいたいの目安なので、ネットで攻撃パターンのチャートを探して（時間が出来たら私も資料作りますが）ください。具体的な手順は、エリア11の攻撃パターンをよく見ておいて、今どこにいるか把握します。エリア11の最後の攻撃が今いるポイントになるので、その数値を基準に下記の計算をしながら調整します。
- エリア12のバーラ４基（の先の道路が交わる部分が画面に出る）まで進むとプラス32
- ミスでマイナス16
- ゾルバク破壊で１基マイナス2
- 攻撃テーブルによる空中物の出現でプラス2
（ただし空中物の出現時に128以上かどうかチェックされるので仕込み中は出さないようにしよう）
これをうまく使って、エリア12スタート時に攻撃テーブルの数値を112～113に調整できれば勝ち確定です。この状態で上のプレイを１回行うごとにポインタをオーバーランさせ、６回目にそのまま川まで進むと総攻撃が始まります（調整に失敗した場合はリセット）。ただし、発動できても川の手前のごく僅かの時間だけで、川に差し掛かると通常攻撃に戻ってしまいます。
エリア12のみでテーブル調整（未検証／理論上可能）
残機があればエリア12の川直前の空中物で調整する方法があります。この空中物の種類がテラジ、カピ、タルケン＋ジアラのときミスした場合、上記の回数＋１回繰り返すと仕込みのラインに乗ります。もし違う空中物の場合は、ゾルバクを少し倒すなりして調整してください。ジアラを外したのは、攻撃パターンのグループが２つあり特定ができないからです。
何が起きているか
からくりは「攻撃テーブルポインタを2加算＞128以上になったら64減算する＞ポインタに対応する空中物を出現させる」というロジックになっているためです。つまり元のポインタが128未満であることしか考慮していないことを利用しています。更に、得点とミス回数から16加算する処理のバグ（範囲外になってもチェックしていない）を組み合わせることにより、次の空中物が出るときに総攻撃のパターンコード（162～163）を指すよう調整しています。
エリア12の序盤では、バグのあるこの処理が２回実行されるため、攻撃テーブルポインタが32進みます。ミスしたときは単純に16減算しているのみなので、１回のプレイでプラス16進むことになります。従って、（仕込み５回分で）112＋16×5＝192、（６回目のプレイで）192＋32－64＋2＝162（総攻撃パターンコード0xA2）となります。
なお、ハードやベリーハードの場合はまだ可能性のあるエリアがあるかも知れませんし、テーブル調整がしやすいかも知れません。こちらはまだ想像の範囲ですが、きちんと調べれば入り口の間口は広がるかも知れません。
とりあえず、総攻撃への入り口はエリア12にありました、というご報告でした。動画を作成していますので、できしだい追記＆アップロード致します。
追記１
下記に動画をアップしました。
- ゼビウスAC総攻撃 通常プレイで発動成功！（YouTube動画）
- ゼビウスAC総攻撃 通常プレイで発動成功！（ニコニコ動画）
この動画ではエリア11の攻撃が「ザカート＞ジアラ」だったのでポインタが104か105で確定できました。（上の目安で書いたジアラの少し後に出てくる2パターン連続しているジアラと特定）そのため、エリア12のゾルバクで調整を入れて必ず発動するよう調整しています。また、エリア11を繰り上げで抜けているので１回分多く仕込み作業をしています。ここら辺はややこしいので早見表を作っておくと成功率が上がると思います。
また想定外ですが仕込み中、変なところでスぺフラ効果音みたいなのが鳴っています。これ、コード上鳴りそうもないのに、どうしてなのかはまったく分かりません。
追記２
仕込み完了直後にプレイ可能になるリプレイファイルを作りましたので試せる方はご利用ください。
- xevious_org_alloutattack_a12_playable.zip（MAME 0.219）
だんだん慣れて成功率が上がってきました。エリア11の斜めの地上物から２回空中物が来ますが、ここが「ザカート＞ジアラ」となった場合は、仕込み×６回、ゾルバク×４個破壊、これで仕込み完了になります。もし、動画やリプレイファイルのように繰り上げでエリア12に来た場合は、仕込み×７回、ゾルバク×４個破壊、になります。
リプレイファイルでは、カウントを間違えて５個破壊していますが、恐らく１回目の仕込みの際に、若干スクロールさせすぎて空中物の＋２が入ってしまい帳尻が合ったと思われます。もう少し早めに当たった方が成功率が上がると思います。
追記３
A3 を出そうと思って少し気づいたことを書いときます。この出現テーブルポインタですが、加算も減算も偶数で難易度設定変えてもそれは変わらないと思います。そうだとすると、奇数には絶対にならないため A3 は出せないばかりか、出現テーブルの半分は実際には使われていないっぽいです。
追記の追記：チェックポイントで得点とミス数から出現テーブルポインタの加算値を算出しますが、その際に奇数になることがありました。
ただ、ゲーム開始の早いうちでないと以降ほぼ確実に +16 の判定になるっぽい（後ほど検証します）。
また、奇数になっているのはテーブル上のブラグザカートが ×2 になることで判断できます。
固定の空中物としてコードを直接指定されれば別ですが、それでも多くの使われない攻撃パターンがあると思われます。加算や減算の数値を半分にすれば、出現テーブルを倍使えるので非常にもったいないと思います。
おかげで A3 がちょっと難しそうですが、B2 であれば仕込み回数をもう１回増やすだけなので、後で挑戦してみようと思います追記２のリプレイファイルから仕込みを１回追加すると B2 の攻撃になります（動画も追加しておきました）。
あと、先ほどの偶数奇数の話に戻ると「ザカート＞ジアラ」と来た場合は仕込み方法がひとつしかありません。出現テーブル上は、同じジアラの攻撃が２連続定義されていますが、片方が奇数になるためポインタが 104 であることが確定するからです。テラジや他の機体でも編隊の機数によって、仕込み回数とゾルバク破壊個数が確定的に言えそうです。
更に改造のアイディアも。ということはですよ、何らかのトリガーで奇数にレーンチェンジできれば、出現テーブルが２本できますよね。ゼビウスアレンジメントのように、出現テーブルを２つ用意してプレイヤーを苦しめることができますね。
追記４：調整の早見表
攻撃順から起点攻撃コードを特定できるものを早見表にしてみました。繰り上げでエリア12に来た場合は、仕込み回数を＋１してください。
| エリア11の攻撃パターン | 起点攻撃コード | 仕込み回数 | ゾルバク破壊数 |
|---|---|---|---|
| ザカート ＞ ジアラ | 0x68 (104) | 6 | 4 |
| ジアラ ＞ トーロイド | 0x6A (106) | 6 | 5 |
| テラジ×2 ＞ テラジ×3 | 0x70 (112) | 5 | 0 |
| テラジ×3 ＞ テラジ×4 | 0x72 (114) | 5 | 1 |
| テラジ ＞ トーロイド | 0x74 (116) | 5 | 2 |
発動後に再チャレンジしたい場合
A2 の発動後はテーブルポインタが 146（0x92）になっているので、ゾルバク１個破壊することでもう一度ラインに乗せることができます。ラインに乗ったら、また仕込み３回行うと再びチャレンジできる状態になります。ただし、川付近まで進んだ場合は仕込みが壊れているので諦めましょう。
また、16進で考えたほうが分かりやすいです。まず、ラインに乗せた状態は16進で1桁目がゼロの場合になりますので、ゾルバクを使って乗せてください。仕込み１回で +0x10 進むので 0x90 → 0xA0 → 0xB0 → 0xC0 と仕込みを繰り返し、出撃の際に 0xC0 になっていれば条件が成立しています。
追記５：バグとは言ってはいけないの？
バックリンク先で、これはバグではないとか何とか的外れな批判がされていたので、少々追記させていただきます。
まず、範囲外になってもチェックしていない点について、似たような処理がいくつかある中でこの処理だけチェックが行われていません。第２に、この処理が２回連続しているので範囲外になる訳ですが、ハード設定以上では１回でも致命的なエラーを引き起こす可能性があります。第３に、最適化を気にしてチェック省くほどクロック数もコード量も必要無いと思います。
また、ほとんどすべてのプログラマがそうするでしょうか？ 致命的なエラーの可能性が分かってたら、まあ省かないでしょうね。逆に、この値をロードする敵の出現処理のほうでチェックし、ポインタを加算する全ての処理でチェックを省く方がスマートかと思います。
百歩譲って、表現としてバグがいけないとすれば、仕様でしょうか、瑕疵でしょうか。
今まで ROM チェックを無視して結果判定のところだけ NG に分岐しないよう改造してたんですけど、それをちゃんとチェックが通るようにしよう、ということで重い腰を上げてみた。
ROM データの最終バイトにチェックサム調整の数値が書き込まれているのは気づいていたので、恐らく総和の下位8ビットがゼロになるよう調整してあるんだろうと察しはついていました。実際に計算してみるとその通りだったので、チェックサムを計算してこの調整バイトに書き込んで終わり、と思ったのになぜかチェックが通らない。調べてみると、チェックサムを計算した計算結果が並ぶメモリがあって、そこの恐らく XVI6 に当たる部分がゼロになっていませんでした。でも、こちらのエクセルの計算結果はゼロになります。
プログラムを追ってようやく分かったのは、なんとサブ CPU にマップされる ROM はチェックサムを計算していない、ということです。データの中でたまたまゼロになっている１バイトのアドレスを、ただ計算結果のメモリにコピーしてるだけ！ そんなの有りですか？ 時間を返して欲しいです。
だから、プログラム内のたまたまゼロ値であるアドレスは変わりようがないので、XVI5 についてはチェックサムは関係なくてもパスします。しかし、出現テーブルの XVI6 は改変したら大きくずれて参照先アドレスがゼロ値でなくなり、チェックサムが合っていても ROM エラーとなります。しかも、ROM 5 という表示でいかにも XVI5 がエラーというふうなのですが、XVI6 がエラーというトラップもありました。
散々苦労しましたが、最初の ROM チェックを無視するというコードが正解でした。同時にプログラムの ROM を改造する場合は、最終バイトまで心置きなく使っても大丈夫なことが判明しました。たぶん、サブ CPU のほうはメンドクサイからそうしたのか、チェック完了のタイミングが CPU 同士で取るのが大変だから、とかそういう理由でしょうね。
ちなみに、エリア8の中盤で右側道路に3台のドモグラムが下りてくるシーンがあると思いますが、そのうち真ん中の１台のデータがそれです。このドモグラムを弄るか、この前のエリアに何か追加してずれてしまうと ROM エラーになります。
デモプレイに画面が切り替わる瞬間にクレジットを投入した際、ソルバルウなどが画面に残った状態で PUSH START BUTTON の画面になることが、このバグが成立した状態になります。ただし、状況によっては目立った変化が無い動画もあります、何れにしてもこれが成立していれば、スタート直後に横一列にバキュラが並んだ状態で出現します。こちらのページにそのリプレイファイルがあったので、今回はこのバグが成立する条件を探ってみました。
まず、大量のバキュラが出る原因はすぐに分かりました。バキュラのキャラクターコードが 0x01 で、これが地上物、空中物、バキュラ、スパリオなどのワークメモリすべて埋め尽くされるために起きています。これは総攻撃などと同じ原理で、どのワークに入れても指定したコードのキャラクタが出現するのと一緒です。そのため、空中物に入れられたバキュラは破壊可能で、得点テーブルも 0x01 で埋められているので対応した得点が加算されます。
問題はなぜこのような現象（0x01 で埋め尽くされる）が起きるかですが、やはりメインとサブの CPU が関係していました。画面モードが切り替わった直後にメイン CPU がワークメモリを 0x00 でクリアしています。原因はそのゼロクリアのし方が下記のようになっているためです。
該当箇所のコード（XVI4 の先頭から）
- クリアする先頭アドレスに 0x00 を書き込む
- ブロック転送命令で１バイト前のアドレスの値を指定回数コピーする
ld hl,$7900 ld de,$7901 ld bc,$06FF ld (hl),$00 ldir
このコードはシングル CPU であれば問題は起こりませんが、このブロック転送の最中にサブ CPU が介入してキャラクタの状態を表すワーク領域に 0x01 を書き込むと、意図しない値がコピーされてしまいます。具体的には、ひとつ前のアドレスをメイン CPU が読み出す直前に、サブ CPU がそのアドレスに 0x01 を書き込んだ場合です。本来は先頭に書き込んだ 0x00 がバケツリレーのようにコピーされるはずが、途中から 0x01 に差し替えられてしまい、以降の領域のすべてが 0x01 で埋め尽くされることによります。なお、画面にスプライトが残る残らないの違いは、どの場所をクリアできてどの場所がクリアできなかったかの違いで起きていると思われます。
この条件が成立するのはかなりシビアであり、狙って出すのはかなり難しいと考えます。それはデモ画面に切り替わった直後『サブ CPU がキャラクタの状態のワーク領域に 0x01 を書き込む直前』にクレジットを投入する、というタイミングと思われますが、クロック単位のシビアなタイミングが予想されます。
状況の再現
ロジックが分かったので再現して確かめてみました。前述のコードの先頭に書き込む 0x00 を 0x01 に変更しただけで再現できました。ただし、強制的にやっている関係でミスしても元に戻りません。
ld hl,$7900 ld de,$7901 ld bc,$06FF ld (hl),$01 ldir
ゼビウスの他のバグと根っこは同じ
ゼビウスってこれ系のバグが多いですよね。エリア繰り上げワープ然り、森の地上物さん然り、CPU 間でメモリを共有しているにも関わらず、タイミングが取れてないから意図しないデータ参照や書き込みが起きてしまう。もしかしたらまだまだレアな怪奇現象が起こるかも知れません。
追記：大量得点の件
破壊可能なバキュラから大量の得点が得られる点については、得点インデックスが３バイトの二進化十進数で定義されているためです。インデックス値としては３の倍数が期待されますが、そこに 0x01 というイレギュラーなデータが入り、１バイトずれた３バイトを参照してしまいます。その結果、本来20点であるはずのデータが20万点として加算されてしまうようです。
古い MAME をビルドする必要があったので調べた結果を共有しておきます。最近のバージョンはデバッガが使える状態になっていますが、古いバージョンはデバッガをオンにしてビルドしないと使えないためその必要がありました。ただ、あまりに古いのでビルドツールを見つけるのに苦労して探し回った結果、下記の掲示板にまとめがありましたのでリンクを張っておきます。
今回は 0.93 をビルドしたいので "MinGW-3.2.0-rc-3.exe + mingw-over-092.zip (0.92 - 0.104u1)" のリンクより２つダウンロードしました。作業用の WindowsXP にそれらをコピーしインストールします（Windows10 でビルドできるかは試していません）。
ビルド手順
※バックスラッシュは小文字の￥マークです
- MinGW-3.2.0-rc-3.exe を実行し解凍先を指定します（今回は C:\mame\MinGW にしました）
- mingw-over-092.zip を解凍して C:\mame\MinGW に上書きコピーします（ディレクトリ構成そのままコピーすればOK）
- mame のソースをダウンロードして C:\mame\mame093s に解凍しておきます
- ファイル名を指定して実行で cmd を入力し OK ボタン（コマンドプロンプトが開きます）
- カレントディレクトリを変更します
cd \mame\mame093s
- ビルドツールへのパスを通します（何度も使う場合はバッチファイルにします）
set PATH=C:\mame\MinGW\bin;C:\mame\MinGW\mingw32\bin;%PATH%
- ビルドを実行します
make
デバッガをオンにしてビルドする
MAME のソースコードのルートにある makefile をテキストエディタで開き、DEBUG=1 のコメントアウトを取って（行頭の # を取る）ビルドするだけです。ビルドが完了すると mame.exe と別に mamed.exe ができ、こちらがデバッガ内臓 MAME になっています。デバッガをオンにして起動するには、下記のようにオプションを指定します。
mamed.exe -window -debug [ROMNAME]
試したバージョン（0.93）ではエラーで落ちる
試したバージョン MAME0.93 ではエラーで落ちる事象が見られました。エミュレーション動作中にデバッガのコマンドを実行すると ACCESS VIOLATION で落ちます。このバージョンだけなのか、その他何が原因なのかは分かりません。
ただし、起動直後の停止状態のときであれば、デバッガのコマンド設定が通るのでそこでブレークポイント等を設定してなんとか使えています。最新の MAME で適当なブレークポイントを探しておき、0.93 の開始直後に設定して止まったところで、ステップ実行その他のコマンドを実行するという、非常に面倒な状況で使うしかありません。一応止まった状態からは、trace、dasm など使っても落ちません。
買ってから初めて使う機能だがぜんぜん言う事聞きません。印刷は何の問題も無くできるのに、プリンタのボタンからもPCからも同じエラーが出ます。