コグノスケ

初めてニコニコ動画に投稿した

目次: Might and Magicファミコン版

TAS動画に解説をつけたかったのですがYouTubeのSubtitleのつけ方が良くわからんのと、日本語はあまり歓迎されていない？ようなので、ニコニコ動画にも同じTAS動画をアップロードしました。リンクは、【TAS】FC版Might and Magic Book One 14分10秒 マップ付き - ニコニコ動画 です。

ニコニコ動画は期待通り、投稿者コメント機能がとても使いやすくて便利です。嬉しくなってつい100コメントくらい書いてしまいました。あんまり解説しすぎも良くないと聞きますが……、まあいいか。

動画の投稿機能自体はYouTubeとさほど違いはないように思います。私の場合はニコニコ動画の方が若干画質が良かったです。YouTubeはテレポートのエフェクトの後にビットレート不足で画が崩れていましたが、ニコニコ動画は割と耐えてました。

テレポートエフェクトによって画が崩れた様子（YouTube）

画の崩れが直った様子（YouTube）

どちらのサービスも再エンコードは免れないので、エンコーダーとの相性次第ですかね？今までYouTubeやニコニコ動画の画質なんて気にしたことありませんでした。自分でアップロードしてわかることもあるものですね。

ユーザー層も違うようでYouTubeはほぼ誰も見てくれませんが、ニコニコ動画はTAS動画が人気らしく、30年以上昔のゲーム（発売は1989年）にもかかわらず1日で数百回ほど再生されていました。

日本語版だったのも良かったのかもしれません。TASVideosの場合、日本語版を投稿すると逆に嫌がられる（英語版が推奨されている）から、難しいところですけども……。

Might and Magicの隠しコマンド

目次: Might and Magicファミコン版

Might and Magicの入力を受け取っている部分を見ていたら、リセット直後になぜか2コンのキーを見ています。これは何だろう？と思ってちょっと解析してみたところ、セーブデータ消去の隠しコマンドでした。

• 2コンの ↓AB同時押しながらリセット
• 画面に何も出ないはずなので……
• 以降AB押しながら、↑→↑←

とするとセーブデータが消えます。ファミコン版のMight and Magic Book Oneはセーブデータを消す方法がないので、おそらくデバッグ用に存在しているのでしょう。イメージを示すとこんな感じです。

セーブデータ消去コマンドの入力方法

ABを押している限り、入力が終わるのをずっと待ってくれるので、1フレーム単位で入力する必要はないです。

Might and Magic Book OneのRAM領域とマップデータ

目次: Might and Magicファミコン版

Might and Magicの拡張RAM領域に書いてあるデータの意味のメモです。カートリッジはMMC3と呼ばれるタイプでiNESのマッパー番号でいうところのマッパー4 に相当します。

ファミコンのRAM領域は0x0000〜0x07ffですが、MMC3の場合0x6000〜0x7fffにも8KBのRAMがあります。詳細はNesdev wikiをご参照ください（MMC3 - Nesdev wiki）。

• 0x6200〜0x62ff: 現在いるマップの壁、ドア（ROMの0x32000辺りに元のデータがある）
• 0x6300〜0x63ff: 現在いるマップの鍵、イベントなどのフラグ
• 0x6880〜0x6a3f: オートマッピング踏破フラグ（2021年10月17日の日記参照）
• 0x6cc0〜0x6eff: オートマッピング踏破フラグ
• 0x6f00〜0x76ff: キャラクターのステータス（プレイ中のデータ）
• 0x7700〜0x7eff: キャラクターのステータス（セーブデータ）
• 0x7f00〜0x7fff: キャラクターの名前リスト

何に使っているか良くわからない領域も多いですが、わかっているところは以上のとおりです。

壁、ドアの領域の意味

アドレス0x6200から並んでいて、マップ1マスにつき1バイト使っています。Xは昇順（0 → 15）で、Yは降順（15 → 0）に並んでいて、X, Y座標から配列インデックスを計算するときはi = (15 - Y) * 16 + Xです。オートマッピングのフラグと並び方が違うんですね……。

各ビットの意味は下記のとおりです。

• ビット7: 北のドア、壁の場合はたいまつ、別のタイプのドア（マップによる）
• ビット6: 北の壁
• ビット5: 東のドア、壁の場合はたいまつ、別のタイプのドア（マップによる）
• ビット4: 東の壁
• ビット3: 南のドア、壁の場合はたいまつ、別のタイプのドア（マップによる）
• ビット2: 南の壁
• ビット1: 西のドア、壁の場合はたいまつ、別のタイプのドア（マップによる）
• ビット0: 西の壁

壁とドアを両方セットした場合、マップによって挙動が変わります。下記のようになっているようです。全マップチェックしたわけではないので、これで完全かどうかわかりませんが……。

町、城の場合

• ドアのみ: ドア
• 壁のみ: 壁
• ドア＋壁: 壁＋たいまつ

ダンジョンの場合

• ドアのみ: ドア1
• 壁のみ: 壁
• ドア＋壁: ドア2

地上の場合

• ドアのみ: 山
• 壁のみ: 森
• ドア＋壁: 森

全くわからない状態から解析したので面倒に感じましたけど、わかってしまえば非常に素直というか、わかりやすい並びでした。

イベントフラグ領域の意味

アドレス0x6300から並んでいて、マップ1マスにつき1バイト使っています。並び順は壁、ドアの領域と同じです。

各ビットの意味は下記のとおりです。

• ビット7: イベントフラグ（強制エンカウントもこれ）
• ビット6: 北側通れない
• ビット5: 暗闇
• ビット4: 東側通れない
• ビット3: ？
• ビット2: 南側通れない
• ビット1: 魔法使用禁止
• ビット0: 西側通れない（ドアならカギ、壁なしならバリア）

ビット3が良くわからないですけど、他は割と素直です。壁かどうかと、通れるか通れないかを分けているので、通れる壁やバリア（通れない空間）が作れるんですね。なるほどねえ。ちなみにイベントが起きるか起きないかは、ビット7とパーティーが向いている方角に依存します。方角はどこか別のところで管理されているようで、この領域を見てもわかりません。

方角に依存したイベントで一番わかりやすいものは、宿屋のドアの前のメッセージです。宿屋のドアの前のマスはビット7がセットされていますが、ドアの方向を向いていないとイベント（メッセージ表示）は発生しません。

オートマッピング

以上の情報を見ると地図が書けます。ゲーム画面と重ねるとゲームが見えないので、右側に余白を確保してそちらに書くようにしました。

壁、ドア、イベント解析で描いた地図の例（デューム城）

壁、ドア、イベント解析で描いた地図の例（アストラル世界）

ゲームシステムの制約（アストラル世界など、オートマッピングができない）も無視できますし、オートマッピングでは描かれない（鍵が開いているか開いていないか）情報も取れます。

この機能、元々はTASのルート決めの補助として作りましたが、普通にゲームで遊ぶ時も非常に便利ですね。詳細な地図が見えない地上エリア、バリアだらけのアストラル世界なんかは難易度が格段に低くなって攻略しやすいです。

ヘネパタ本

会社で勉強会で発表担当になっているので、ヘネパタ（コンピュータアーキテクチャ 定量的アプローチ）の2章をスライドにしているんですけど……、な、長ぇーー！所詮36ページと思いきや、日本語版は1ページの文字数が尋常じゃなく多いです。全く進みません。

前回の担当分（補足B）のスライドを作ったときも同じことを思いましたけど、ヘネパタの説明って、日本語はわかるけど結局何が言いたいのかわからんときがあります。補足スライドを作るのに凄い時間が掛かりました。

話があちこち飛ぶというか、項目を列挙しているのに説明する性質が一致していなかったり、読んでてイライラします。もう3/4くらい進めた時点で疲れてしまい、最後は超手抜きです。それでも80枚くらいありました。

これでも2章は比較的短い章で、3章や4章なんて50ページありますからね！？スライド100枚でも説明できないのでは？

メモ: 技術系の話はFacebookから転記しておくことにした。

レガシィのバンパーを直すか否か

目次: 車

レガシィに乗るたびに後ろの壊れたバンパー（※）がズレてきて、手で押しこんでも戻らなくなってきました。一応固定されているので脱落することはないですが、いい加減に修理しないとイカンかなあ。高そうで嫌だなー……。

昔、左側のドアも電柱に盛大にぶつけたから、左側がボロボロで悲しい見た目です。それと車体とは関係ないですけど、燃費表示するセンターコンソールも点かなくなりました。あんまり乗ってないけど、さすがに10年以上経つと色々壊れるものだ。

（※）以前、駐車場の坂で尻もち付いたときに、左1/3くらい固定用のビスが折れました。

Might and Magic Book One TAS最後の更新2

目次: Might and Magicファミコン版

Might and MagicのTASはもうやらんと言いましたが、少しだけやってます。

会社に向かって歩いているときに「もしかしてあの部分は飛ばせるんじゃね？」と思いついたアイデアを試したところ、合計で298フレーム（4.8秒くらい）速い、14分06秒になりました。ニコニコ動画にも載せておきました（【TAS】FC版Might and Magic Book One 14分06秒 マップ付き）。

更新箇所は下記のとおりです。

• エルキューン、アガールに会わずに脱出: 98フレーム
• ダスク、幽霊を無視: 68フレーム
• ダスク、テルゴランの依頼に「いいえ」: 83フレーム
• ポートスミス、ザムに会った後に即エンカウント: 43フレーム

ダスクの交差点にいる幽霊を無視すると、敵と強制エンカウントすると思いこんでいたのですが、実はそんなことはありませんでした。直進ならエンカウントしません（旋回するとエンカウントします）。確認は大事ですね。

正直に言って2番目と3番目以外は期待していませんでしたが、どれも0.8〜1.5秒程度の短縮と、良い方向に予想を裏切ってくれました。特にエルキューンでアガールをすっ飛ばすのは予想外の効き目でした。

もう短縮できそうなところは思いつきません。このルートで14分切るのは無理かなあ。

Might and Magicのメッセージスキップ処理のタイミング

目次: Might and Magicファミコン版

Might and Magicのメッセージスキップについて動作を軽く調べたところ、変な実装になっており超厳しいタイミングを要求されることがわかりました。

メッセージ表示をしているコードは0x9AAE〜0x9B09です（たぶん。表示処理は詳しく見てない）。この処理を実行しているときはROM 0x16000が0x8000にマップされているので、ROMのアドレスでいうと0x16000 + 0x1AAE = 0x17AAE〜 に該当します。このコードの中でスキップ判定をしているのは0x9AF7です。

9AAE :	20 B4 E3	JSR	$E3B4	;
9AB1 :	A9 00		LDA	#$00	;
9AB3 :	8D 73 03	STA	$0373	;
9AB6 :	A2 00		LDX	#$00	;
9AB8 :	8A		TXA		;
9AB9 :	48		PHA		;
9ABA :	20 49 9B	JSR	$9B49	;
9ABD :	20 48 9A	JSR	$9A48	;
9AC0 :	68		PLA		;
9AC1 :	AA		TAX		;
9AC2 :	BD 20 9B	LDA	$9B20,X	;
9AC5 :	85 7B		STA	$7B	;
9AC7 :	8A		TXA		;
9AC8 :	48		PHA		;
9AC9 :	0A		ASL	A	;
9ACA :	AA		TAX		;
9ACB :	BD 0A 9B	LDA	$9B0A,X	;
9ACE :	85 00		STA	$00	;
9AD0 :	BD 0B 9B	LDA	$9B0B,X	;
9AD3 :	85 01		STA	$01	;
9AD5 :	A5 00		LDA	$00	;
9AD7 :	48		PHA		;
9AD8 :	A5 01		LDA	$01	;
9ADA :	48		PHA		;
9ADB :	20 5F 9A	JSR	$9A5F	;
9ADE :	68		PLA		;
9ADF :	85 01		STA	$01	;
9AE1 :	68		PLA		;
9AE2 :	85 00		STA	$00	;
9AE4 :	20 7F 9A	JSR	$9A7F	;
9AE7 :	20 48 9A	JSR	$9A48	;
9AEA :	68		PLA		;
9AEB :	48		PHA		;
9AEC :	85 7B		STA	$7B	;
9AEE :	A9 0B		LDA	#$0B	;
9AF0 :	38		SEC		;
9AF1 :	E5 7B		SBC	$7B	;
9AF3 :	AA		TAX		;
9AF4 :	20 C2 9C	JSR	$9CC2	; コントローラの状態確認
9AF7 :	AD 73 03	LDA	$0373	; メッセージスキップの条件判定
9AFA :	C9 01		CMP	#$01	;
9AFC :	D0 04		BNE	$9B02	;
9AFE :	68		PLA		; メッセージスキップ発動
9AFF :	4C 09 9B	JMP	$9B09	;
9B02 :	68		PLA		; メッセージスキップ発動せず
9B03 :	AA		TAX		;
9B04 :	E8		INX		;
9B05 :	E0 0B		CPX	#$0B	;
9B07 :	D0 AF		BNE	$9AB8	;
9B09 :	60		RTS		;

最後の方で関数0x9CC2 → 0x9D14 → 0x9B2Bとcallし、変数0x0373（コントローラ状態変更フラグ）が0以外ならメッセージスキップします。後ろから見ていきましょうか。

9B2B :	A9 00		LDA	#$00	;
9B2D :	8D 73 03	STA	$0373	;
9B30 :	20 C5 E7	JSR	$E7C5	; コントローラの状態チェック関数、結果は $0200に格納される
9B33 :	AD 00 02	LDA	$0200	;
9B36 :	CD 01 02	CMP	$0201	;
9B39 :	F0 0D		BEQ	$9B48	; 前回と状態が変わっているか？
9B3B :	8D 01 02	STA	$0201	; 変わっているなら、変数 $0201に状態を保存
9B3E :	AD 00 02	LDA	$0200	;
9B41 :	F0 05		BEQ	$9B48	; 状態が0以外（＝何か1つでもキーが押されている）か？
9B43 :	A9 01		LDA	#$01	; 押されているなら、変数 $0373に1を設定
9B45 :	8D 73 03	STA	$0373	;
9B48 :	60		RTS		;

関数0x9B2Bは現在のコントローラの状態と、保存していた前回のコントローラの状態を比較し、変化していたら変数0x0373に非0の値をセットする関数です。推測するに、プレイヤーがボタンを押したら変数0x0373がセットされ、メッセージスキップが発動する……はずだったのでしょう。

ところが関数0x9D14の実装が完全におかしくて、画面描画が1回終わる（※）まで、関数0x9B2Bを「何度もビジーループで呼ぶ」のです。

9D14 :	8D 64 02	STA	$0264	;
9D17 :	A9 C0		LDA	#$C0	;
9D19 :	8D 51 61	STA	$6151	;
9D1C :	20 2B 9B	JSR	$9B2B	; ↓このループが全力で回りまくる
9D1F :	AD 51 61	LDA	$6151	;
9D22 :	D0 F8		BNE	$9D1C	; ↑
9D24 :	60		RTS		;

短期間に関数0x9B2Bを繰り返し呼ぶとどうなるかというとですね。プレイヤーがコントローラのキーを押して変数0x0373がセットされても、次の呼び出しですぐに「前の状態と変化ナシ！」と判定し、変数0x0373がクリアされてしまい、キーは押されていなかった扱いになるわけです。ええー……なにこの実装。

（※）VBlank NMIを契機に画面描画され、変数0x6151に0がセットされます。

メッセージスキップの発動条件

最速でメッセージスキップを発動させようとすると、プレイヤーは下記の条件を満たす刹那の間にキーを押す必要があります。

• …
• 関数0x9B2B
• 関数0x9B2B（この処理が終わった後から）
• 関数0x9B2B（この処理が始まる前まで）
• 画面描画

トレースログで測ったところ入力の猶予は1,055クロック、ファミコンの6502は1.79MHz駆動らしいので、わずか0.589msです。短すぎだよ！！

TASの経験から1フレーム（16.667ms）未満だろうとは思いましたけども、まさかのサブミリ秒でした……。道理で、フレーム単位入力のTASでは最速のメッセージスキップができないわけです。人間ならなおさら無理ですね。このタイミングを毎回狙って押せるやつは100％人間辞めてます。

以上は最速のタイミングを狙って発動させようとした場合の話であり、メッセージスキップを拝むこと自体は割と簡単です。なぜならキーを「押す」タイミングは非常に厳しいものの、他の条件は厳しくないからです。救いの手は2つ、

• 毎フレーム判定が行われる
• キーを「離す」タイミングは30フレームくらいと猶予が大きい

ですから適当にキーをガチャガチャ連打していれば、たまに条件に該当してメッセージスキップが発動します。