PC-98の隠し機能
「MMDUMP」と「デバッグポート出力」Copyright(C) 2022 まりも (DOSsoft) 2022-4-1
電源投入またはリセット起動時に、フロッピーディスクを挿入して後述の特定のキーを押しておくと、MMDUMPという機能が働きます。このことは、あまり広く知られていないと思います（N88BASICの時代にはcold bootとともに知られていた？）。MMDUMPはメモリチェックやROMの正当性チェックよりも前の段階でITFの処理の流れからすり抜けて分岐し、次のようなことを行います。
作られるフロッピーは普通のMS-DOSフォーマットの1024byte/sect,8sect/track,77 cylinder(1232KiB)で、「MMDUMP.DAT」というファイルが存在しています。そのサイズがちょうど 1MiB = 1024KiB = 1048576Byteとなっています（以降面倒なので1MBと書きます）。書き込まれるデータは、その時点でのメモリの1MB空間の内容すべてです。
ITF開発中のデバッグの一助としてメモリダンプが必要であることから、この機能が備わったと考えられます。この機能はITFが備わった機種（PC-9801VX）ころから存在するとみられますが、最終機のMate-Rシリーズでは削除されてしまっています。ともかくデバッグ用の機能ですから、メモリ（ROM,RAM）故障の診断にも応用はできそうです。ただしMMDUMPのプログラムコードが載っているITF自体が正常であることが条件になりますが。また逆に、MMDUMPが働くかどうかも故障の判断材料になり得ます。
リセットボタン押し離し操作、電源PGリセット操作、またはソフトリブート直前の時点で、[SHIFT][CTRL][STOP]の３つのキーを押した状態にします。これで起動するとまずビープが鳴りっぱなしとなりますが、焦らないようにしてください。これはMMDUMP機能開始の合図のようなものです。これは予め知っておかないと気がつかないでしょう。ここで[COPY]キーを押すと、上述のフォーマットと書き込みが始まります。それ以外のキー応答は無効です。
フロッピードライブのトラック移動音はフォーマット時のほうがやや遅く、速くなった段階から書き込みに移ったことがわかります。それが終了するとまたビープ音が鳴りっぱなしとなりますが、これ以降は操作せずに電源を切ってください。COPYキーを押してしまうと、同じことの繰り返しとなってしまいます。複数枚のフロッピーを作りたいときや、2HD 1024の1MBの物理フォーマットをしたいときには使える手段かもしれませんが（つまり98のDOSがなくとも物理フォーマットできる！）。
Windowsでもその他のOSでもよいですから、2HD 1024B/sectのFDDが扱えるパソコン環境でこのフロッピーの内容を見ると、MMDUMP.DATという1MBのファイルができあがっていることがわかります。これは物理番地の昇順のメモリ内容です。メモリチェックが行われる前に動作するのでメモリの内容が保持されています。ファイルが大きいですから、DOS版ソフトよりもWindows版のバイナリエディタで見るとよいでしょう。
なお「電源PGリセット操作」というのは、リセットボタンのない機種において、電源ユニットとマザーボードを接続する線のうちPowerGoodという信号線をGNDに落とすことでハードウェアリセットをかける操作のことです。この改造をしていないと、MMDUMPに入る操作は電源再投入しかないことになり、メモリ内容をDUMPするという目的での利用になりませんのでご注意ください。しかしソフトウェアからシャットダウン再起動をかけるようにすれば、そのときに[SHIFT][CTRL][STOP]の３つのキーを押した状態にすることでMMDUMPの機能を使うことは可能です。
バイナリエディタでみたときのファイルのオフセット番地はそのまま1MB空間のメモリアドレスに相当します。SYSTEM ROM域に、E8000、F0000には通常のN88BASICとSYSTEM ROMが現れています。F8000～のROMバンクは、PCI機ではROM BANK2が見えており、通常のBANK4のITFから切り替わった状態であることがわかります。MMDUMPはROM BANK2のどこかがエントリポイントだということになります。なおBANK2でない機種もあろうかと思います。古い機種ではそうです。
640KBまでの空間についても、それ以前の内容が残っていればそのまま記録されています。これをもとに、MMDUMP操作に入る直前の状態を解析できるというわけです。しかし一度メモリチェック表示が出たあとくらいにMMDUMP操作をした場合、メモリはクリアされているので、640KBメモリ空間のデータは0で埋まっています。
D0000～にCバスの拡張ROMがあればそれも出ます。直前に画面が表示されていた場合にはA0000～のテキストやA8000～のグラフィックのメモリアドレス帯に何かしらのデータが存在します。VRAMの内容のままです。
ただしPCIバス搭載機では、テキストVRAMのアトリビュートコード(表示色や飾りの属性を示す１バイトデータ)のエリアであるA2000番地以降が通常と異なるデータが書かれるようです。理由はよくわかりません。キャラクタジェネレータを読み出すウィンドウであるA4000h～も異なるデータです。いっぽうグラフィックVRAMは、16色モードのPC-9800標準グラフィックス(640*400)としては正しいデータが取得されています。MMDUMPに入る直前に9821拡張グラフィックモード（640*480 256色）であったとしても、MMDUMP内で標準グラフィックに戻されてしまい、正しい内容では読み出せません。
任意の時点で上述の3つのキーを押しながらリセットをかければよいので、一般的なDOSプログラムがハングアップした時点でのメモリの内容を保存できます。デバッグの参考資料となりますが、キーを押した時点がプログラムのどこを走行中であるかまではわかりませんから、開発者でもダンプ情報を使いこなすのは大変です。BIOSやDOSルーチン内にいたときのダンプはさらに判断が難しいでしょう。
フラッシュROM採用機には「FDloader」という機能があり、これもITF起動とは別にプログラムを走らせる手段のひとつになります。しかしFDloaderでは記憶装置や通信装置への入出力ルーチンを作るのが難しいため、実行結果を残すのは大変です。それでもメモリに実行結果を残しておき、MMDUMPで実行結果をフロッピーに回収するのであれば簡単です。つまりFDloaderと組み合わせることで利用価値のきわめて高いものになるわけです。ということで、活用事例のひとつとして、'FDloader'との組み合わせ運用を紹介します。
FDloaderとは、端的に言うと、[ESC][HELP][8]同時押し起動をしたときにフロッピー上のプログラムをロード実行できる機能です。ITFの動き出す前にあらゆることが可能となる反面、BIOSサービスなどソフトウェア割り込みが一切使えない制約があります。したがってFDloaderで実行した何かの結果をディスクファイルに残すというのが非常に難しいことになります。しかし実行結果をメモリ上に残しておき、MMDUMPでメモリ内容をFDに書き出すことで、実行結果をファイルとして取り出すことができます。
2022年4月現在では、FDloader内からMMDUMPに直接移行できることが判明しており、それを活用したのが拙作「ＲＯＭＳＵＭ」バージョン2です。このツールではITF/BIOSの入っている256KBのROMデータをメインメモリの10000h～4FFFFhに読み出し、その後MMDUMPを実行します。実行結果のMMDUMP.DATが次の図のようになります。
PCI搭載頃からのPC-9821シリーズのITFでは、I/Oアドレス 0610h番地に8bit値をときどき書き込んでいます。その値はITFの実行のステップにしたがってだいたい昇順になっており、00hから増えてゆきます。
しかし必ず連番で増えてゆくわけではなく、欠番もありますし、機種によってもある程度違いがあります。またITFでは電源投入直後以外にバイパスするような条件分岐がありますので、実際に出力される値はかなり飛び飛びです。
このポート出力の情報が何に使えるかというと、起動しないマシンの故障原因を探ることです。出力された値をITFコードと照らし合わせてみれば、どの初期化まで行ったかがわかります。いわばdying messageのようなものです。そういうわけで、使いこなすにはITFのコード解析にも慣れていないといけませんが、そこはあらかじめ慣れた人が情報を出しておけばいいことです。
偶数アドレスへの単なる8bitI/O出力ですので、CバスボードでIOWピンとアドレス0610hとデータビット0-7、CPUENBなどを監視してデータを一時保存（ラッチ）するようなボードを作ればOKです。その出力を7セグメントLED２桁で表示すればかなり見栄えはよくなります。しかしそのような物を自作しなくても、汎用のCバスパラレルI/Oボードを利用することができます。Contechやinterface社などがそのようなボードを出しており、I/Oアドレスは任意の（本当は禁止されている）16bitフル・デコードが可能です。16bitのDIPスイッチを、0610hに合わせればOKです。しかもビットごとのLED表示までついていますから、少なくとも最後に出力された値を目で見ることができます。
「入」出力ボードを使う場合にはひとつ注意が必要です。本体内部に存在するアドレスと同じ値を設定してはいけないという点です。本体内に存在するアドレスと競合すると入力時にCバスボードの出力（何もボードにつないでいなければ0,Lレベル）と衝突してしまい、誤動作や永久故障の原因となります。ですから0610h以外の値に勝手に設定してはいけません。0610h番地には本体内蔵で読み出されるデバイスが存在しないので大丈夫なのです。
もし任意のアドレスの出力もモニタしたいという場合は、それが入力になっても大丈夫なように、あらかじめCバスのピンのIOR をマスク（粘着テープなどで覆う）かパターンをカットして、入力に応答しないよう改造しなければなりません。なお出力専用のボードも存在しますから、そちらを入手したほうが簡単かつ安全です。
0610hと書きましたが、ごく一部のデスクトップ機、PC-9821Ap3/As3では違うアドレス0567hが使われていました。またノート機（のうち110ピン廃止機）ではCバス出力ができないので、プリンタポート40hに出力されています。プリンタポートは、ストローブ信号なしで現在の値をラッチして表示するようなものを装着すれば読めるはずです。なおPCIバス搭載機ではないPC-9801BX4やPC-9821Xe10にもこの機能は存在し、アドレスは通常どおり0610hです。
マザーボードの故障がわかると書きましたが、起動できない原因の多くは、なんらかのI/Oの応答待ちルーチンで、そのI/Oの先のデバイスの故障で永久にループから抜け出せない状態になることにあります。ですから一般論としては、ITFを解読して、デバッグ値が出力されるコードの直後くらいの位置にある当該ルーチンに原因が潜んでいると判断できます。そこで操作を行っているハードウェアを確認することになります。なおCPUが電気的に全く起動できないようなハード的故障もありえます。それに関してはこの手法は役にたちません。
| マザー ボードの G8型番 | 値 | 代表的機種名 |
| G8YKK | 21h | RaⅡ23,266,300,333,40,43 |
| G8YEW | 40h | Xa20/W,200/W,/M,/Y,/D |
| G8YEV | 40h | Ra20/N30,Ra18/N30 |
| G8XRZ | 40h | Rv20 |
| G8YLS | 40h | RvII26 |
| G8YVZ | 21h | V200,166/S,Xc16,200/S |
| G8YDP | 21h | V200/M,Xc16,200/M |
| G8WTP | 40h | Ra20/N12 |
| G8WSG | 40h | Xa13/W,Xa16/W |
| G8WTH | 40h | Xv13/W, Xv20/W |
| G8USL | 40h | Xt13/C12 |
| G8WPY | 40h | V12,V13(430FX) |
| G8VER | 40h | V7,V10,V12,V13(430FX) |
| G8XYH | 40h | Xv13/R |
| G8VWV | 40h | Xa**/K,/R(wildcat) |
| G8VSU | 40h | Xa10,12,13/K(wildcat) |
| G8VAZ | 40h | Xa7,9,10/C(wildcat) |
| G8VLJ | 40h | Xa7e,V7(430FX) |
| G8TZA | 0Fh | Xe10,BX4 |
| 黒ノート機 | 1Ch | プリンタポート40hへの出力 |
というようにハードウェアの故障はソフト的なモニタでは簡単にはわかるものではありませんが、ITF ROM内容の不正というのは、ソフト的にわかりやすいので、ITF ROMのデータ不正状態を探ることに使うのは容易です。その事例として、「まったくピポ音がせず起動しない」という、よくあるけども難しい故障診断を紹介します。
ITFを解読すると、ピポ音鳴動をさせているところというのは一応特定できます。beepの周波数2kHz/1kHz設定と、音出力ON・時間待ち・OFF、つまり「ピ・ポ・」をやっているところを探せばよいのです。それが行われる前後のデバッグポート出力をさまざまな機種で調べてみました。ピポの直前には何があるかというと、これも調べた機種すべてにおいて、「ITF ROMのチェックサム」正当性を調べるというものでした。そのさらに直前にあるデバッグ出力値について調べたのは次の表です。多くの機種ではITFサムチェックの直前に出力されるのは40hで、最終機に近い機種では21hなどとなっています。表にない２桁Value Star機はおそらく40hでしょう。したがってITF ROMのデータに異常があると、まったく起動音もせず画面文字表示もせずにダンマリになるというわけです。
もしITFのデータ化けならこの表のような値が表示されたところで止まるはずです。手持ちのどうやっても正常起動しないRv20,RvII26で調べてみたところ40hあるいは21hで止まりましたから、ROMデータ不良だと判断されました。別のハードウェアの故障の可能性はとりあえず小さくなったわけです。ROM内容の不正ならば書き込んでリフレッシュしたり別のROMに置き換えれば直るわけで、ハードウェア的な治療はしなくてすみます。
そうなると、過去に起動しなくなって処分したマザーボードが気になります。もしかすると捨てなくても直すことができたのかもしれないし、故障箇所が特定できて簡単に直せたかもしれないわけです。もしそのような起動不良マザーボード（PCIバス搭載機）をお持ちの方は、デバッグ出力値の表示を試してみるとよいでしょう。CバスI/Oボードは案外安く手に入りますから。役立たずと思われている物が利用できるのはすばらしいことです。
ちなみに全くCPUが動作しない故障の場合は、ITFの命令が最初の一歩からも実行されないわけですので、デバッグポートへの出力が一度も行われません。その場合は入出力ボードのLEDはすべて不点灯となります。値00hが出力された場合も不点灯ですので、両者の判断はつきにくいですが、不点灯ならまずCPUが動いていない可能性のほうが高いです。
参考までに書いておくと、外部のビデオ信号を入力できるRGB入力コネクタが備わっている機種（おおむねPCIバス搭載機）では、CPUがITFを実行し映像信号のリレーを操作して初めて、98のブランクの映像信号がRGB出力から出るようになります。それすら出ないようならCPUが動いていないという判断ができます。いっぽうそれ以前の98ではCPUがなくてもブランクの映像信号が出ますので、CPUが動いているかどうかの判断材料になりません。
なおこの記事は、各機種について一応のハードウェア的およびソフトウェア的調査をして書かれたものですが、事実関係の誤りや推論の誤りを含んでいる可能性はあります。たとえば故障修理の参考にする場合は、ご自身の責任で実機をよく調べたうえでおこなってください。この記事の誤りについて筆者はいっさい責任は負いません。
2022.4. 1 初稿
2022.4.10 改訂 ROMSUMSV廃止でROMSUM2に統合のため