富士通FMシリーズの特異なブートセクタ (IPL)

2021-04-05 01:02:51 | 古いPC関係
Image: 富士通FMシリーズの特異なブートセクタ (IPL)

注意：長文です。

トップ画像は、河西, 朝雄 “MS-DOS Ve.5.0 オペレーティングハンドブック” p.271 , 1992年, 技術評論社より、MS-DOS起動メカニズムの説明図。この図のROMや5 1⁄4 インチフロッピーのイメージは、今となってはほとんどの人に通用しないだろうな。

私の中でMS-DOSに関して2つの未解決問題が存在する。一つはMS-DOS Ver.2.25の日本語版が実在したのかということ。もう一つはFMシリーズのフロッピーフォーマットについてだ。前者については確実な資料がないのでいずれ考察することにして、今回は後者の話をする。もっとも、FMRやFM TOWNSの実機・ディスクを調べたわけではないので、周辺情報からの想像で語っているに過ぎず、結論が出ない話になるだろうこと予め釈明しておく。

かつて、マイクロソフト公式のMS-DOS 6.2/V Upgradeサポート技術情報に次のような記事が存在した。

→ KB405980 - 1024FD.EXEと富士通FM-Rの5.25ichフロッピーディスクについて

日本国内のみで普及した1.2MBフロッピーディスクフォーマットは、PC/AT互換機のMS-DOSでは通常サポートされていないが、それでは日本の大多数のPCユーザーが困るということで、MS-DOS 6.2/Vにはこれを読み書きするためのユーティリティ (1024FD.EXE) が付属した。このサポート情報の文面を見るに、富士通の古いFMシリーズでは同等の論理フォーマットが使用されていたようだが、その一部分が「標準と異なる」ことから、1024FD.EXEではアクセスできないらしい。

1024FD.EXE の問題ではなく MS-DOS 6.2/V の仕様で、富士通 FM-R やFM-TOWNS でフォーマットされたフロッピーディスクのブートセクタの先頭の 3 バイトが、MS-DOS 6.2/V の標準の値ではないのが原因です。

とのことだ。ここでいうブートセクタとはフロッピーディスクやハードディスクなどの先頭のセクタ（シリンダ0・ヘッド0・セクタ1、あるいはLBAアドレス0）を指し示す。その先頭3バイトにはブートコードへのジャンプ命令が置かれることになっている。

この文面からは、まるで1024FD.EXEがAT互換機のMS-DOS 6.2/Vでフォーマットされたディスクしか読めないかのようだが、NEC PC-98でフォーマットされたディスクはMS-DOSの標準仕様に従っているため、1024FD.EXEを使って読めるはず。当時のパソコンユーザーの過半数はPC-98ユーザーであり、富士通も自社のFMVには1024FDに代わるプログラムを用意してFMR形式に対応しただろうから、大きく問題に取り上げられた形跡がない。

ブートセクタとは？

PCの電源投入後、POSTによる自己診断が完了すると、PCのBIOSにあるブートストラップローダーと呼ばれるプログラムがフロッピーディスクまたはハードディスクの先頭セクタを読み取り、メモリ上の特定のアドレスに配置した後、その先頭アドレスにジャンプして処理を渡すことになっている。ブートセクタはディスク上で最初に実行される小さなプログラムであり、同じディスク上にあるOSを起動するためのプログラムを探してメモリに配置し、それに処理を渡す（ブートセクタのサイズは固定で非常に小さいため、それ以上の処理を入れるのは難しい）。ブートセクタはIBM PS/2の技術解説書では「ブートストラップセクタ (Bootstrap sector)」と呼ばれ、MS-DOSでは「予約セクタ (Reserved sector)」とも呼ばれた。また、日本では昔からの慣習で「IPL (Initial Program Loader)」とも呼ばれていた。

MS-DOSではフロッピーディスクのフォーマットにFATを採用している。もっとも、狭義の意味でのFATはディスク全体のフォーマットではなく、ディスク上でファイルの「目次」を管理するファイル配置テーブル (File Allocation Table) を指し示す。例えば、MS-DOSとは互換性がない別のOSであるN88-日本語BASIC(86)ではファイルの管理に8ビットFATを使用しているが、そのディスクフォーマットの構造はMS-DOSが使用するディスクフォーマットとは大きく異なる。

先の話に戻ると、先頭3バイトにジャンプ命令が配置されるというのは、MS-DOSが定めたブートセクタ（予約セクタ）の仕様だ。この仕様では、その後にベンダーが定めるIDやディスクフォーマットの仕様を記述するBPB (BIOS Parameter Block) を挟むことになっていて、その後にOSの起動用プログラムを読み込むブートコード (IPL) が続く。異なるプラットフォームでファイルの管理仕様を統一することを目標に作られたMS-DOSで、しかも当時はデータ交換の主な記憶媒体であったフロッピーディスクが、FMRでは他の機種と異なるフォーマットを使用しているとは何事か。

しかし、IBM PS/55と同じく家庭に普及しなかったFMRの情報は、ネットではほとんど得られる見込みがなく、調査はここで一旦断念することになる。

きっかけは海外のレトロPCマニアのサイト

VOGONSという、主にIBM PC互換機とMS-DOS関係を扱うレトロPCユーザーの英語掲示板の中で偶然見つけたサイトで、この奇妙なフォーマットが話題に上がっていた。そのサイトによると、発端はMS-DOS 3.21 OAKのソースコードを精査していたとき、ブートセクタの有効性を判断するプログラムに奇妙な点を見つけたとのことだ。OAK (OEM Adaptation Kit) というのは、当時のマイクロソフトがPCメーカーに対して配布していたMS-DOSのソースコートで、PCメーカーはこれを各社のPC用に手直ししてユーザーにMS-DOSを供給していた。その存在自体は公にされていたが、ソースコードはもちろん機密情報となっている。ただ、今どきプレステの開発ハードやN64の開発キットが流出するくらいだから、30年以上前の資料を保存していた人があるタイミングで手放しても、おかしな話ではない。

そして、そのソースコードは次のもの。

         cmp    byte ptr cs:[DiskSector],069H   ; Is it a direct jump?
         je     Check_Signature                 ; don't need to find a NOP
         cmp    byte ptr cs:[DiskSector],0E9H   ; DOS 2.0 jump?
         je     Check_Signature                 ; no need for NOP
         cmp    byte ptr cs:[DiskSector],0EBH   ; How about a short jump.
         jne    BadDisk
         cmp    byte ptr cs:[DiskSector]+2,090H ; Is next one a NOP?
         jne    BadDisk

CMP (Compare) は2つの対象を比較する命令。JE (Jump equal) は直前のCMP命令の結果が「等しい」のであれば、そのアドレスにジャンプする命令。JNE (Jump not equal) は直前のCMP命令の結果が「等しくない」のであれば、そのアドレスにジャンプする命令。Check_SignatureやBadDiskというラベル名から察するに、ディスクの先頭バイトが69hかE9hかEBhであれば、ここにある条件はクリアということになる。E9hとEBhはx86系CPUにおけるジャンプ命令に該当する。ここで問題なのは、69hとの比較に対して「それは直接ジャンプか？」というコメントが書かれているにも関わらず、69hはIntel 8086では予約とされている命令コードで、また80186以降ではジャンプと無関係なIMUL（符号付き整数の乗算）命令が割り当てられていることだ。

これだけであれば不可解なコードとして片付けられた可能性が高い。ところが、これと類似するコードがWindows NT 4.0のリークされたソースコードに登場することが判明した。

    // FMR Jul.11.1994 NaokiM - Fujitsu -
    // FMR boot sector has 'IPL1' string at the beginnig.

    if (Buffer->Jump[0] != 0x49 && /* FMR */
        Buffer->Jump[0] != 0xe9 &&
        Buffer->Jump[0] != 0xeb) {

        result = FALSE;

コメントに「FMRブートセクターは最初に’IPL1’の文字列を持つ。」と書かれており、その次の条件文での0x49はASCIIコードで言う大文字の’I’であることを暗示している。つまり、49hはFMRで使用された署名の一部ということ。ここでようやくFMRのブートセクターの謎に繋がった（MS-DOS 3.21 OAKの69hの謎については後ほど説明する）。

このコードはマイクロソフト公式サイトからダウンロードできるWindowsドライバー開発キット (Windows Driver Kit version 7.1.0など) にも、fastfatというサンプルのfsctrl.cに登場する。そのサンプルでは0x49自体に関する有意義な言及（上記のコメント文）は一切ないが、他の場所で定義や関数名として「FujitsuFMR」という言葉が登場し、それが通常と異なるフォーマットを使用していることは察しが付く。

FMRのブートセクターの仕様

FMRに関する情報はネット上には乏しいが、FMRがベースの家庭用パソコンであるFM TOWNSとなれば話は別。エミュレーターや自作ソフトの開発など、アーキテクチャーに精通している人は少なからずいるはずで、その辺りの情報を探してみたら、FMRのブートセクタについて核心となる情報を見つけた。以下、Yukio KATOH氏の「うんづツールアーカイブ(2004/1/3版)」fmhd.hより。

/* FMR/TOWNSの論理ブロック番号 0: マスターブートブロック (512バイト) */
struct master_boot_block {
  /* 000h～003h: TOWNS用HDD署名 {0x49,0x50,0x4C,0x34}=="IPL4"  */
  /*           - boot ROM が当署名を見つけることができなかった */
  /*             場合は次のユニットの IPLを読みに行く(CMOS-RAM */
  /*             に設定してある起動ユニット(次のいずれか)→    */
  /*             CD-ROM→FDD#0～FDD#3→SCSI ID#0～SCSI ID#4→  */
  /*             CD-ROM→FDD#0～FDD#3→SCSI ID#0～SCSI ID#4…) */
  /*           - FMRでは IPL4 ではなく "IPL1"～"IPL5" となって */
  /*             いる。機種ごとに "IPLn" の "n" が決まっており */
  /*             対応する機種用の署名でないと起動しない。異な  */
  /*             る機種用のコードを誤って実行しないための boot */
  /*             ROM 側の配慮である。                          */
  /*           - 各機種の署名は以下のようになっている。        */
  /*             IPL1 … FMR50系/60系/70系/80系/250系/280系、  */
  /*             IPL2 … FMR30系、 IPL3 … FMR10LT、           */
  /*             IPL4 … FM-TOWNS、IPL5 … FMR50Λ系/70Σ系。  */
  /* 004h～1FFh: 80x86の16ビット機械語コード(IPLコード)ほか    */
  /* [補足] マスターブートブロック(IPL)の内容は、どの HDD / MO */
  /*        も (過去のものも新しいものも) 同じ内容であるようで */
  /*        あり、署名が "HD IPL V1.1 89/01/14" となっている。 */
  /*      - ちなみに FDDの C:0,H:0,R:1,N:? も CD-ROMの LSN #0  */
  /*        も、IPL起動するためには先頭 4バイトが "IPL4" と    */
  /*        なっている必要がある。TOWNS の boot ROM は、SCSI   */
  /*        CD-ROM ドライブに対応しておらず内蔵の専用 CD-ROMか */
  /*        らのみ起動可能。また、boot ROM はブロック長が 512  */
  /*        より大きくても IPL ブロックの先頭の 512 バイトしか */
  /*        読まないことがあるので注意 (HDD では心配ないが、   */
  /*        FD に対してソフトウェアリセット用コマンドの reipl  */
  /*        をドライブ指定で (reipl a: のように) 実行すると、  */
  /*        そうなるようである。ハードウェアリセットなら 1024  */
  /*        バイト読んでくれるようなのだが…。CD-ROM について  */
  /*        同じ問題があるかどうか未確認)                      */

IBM PC互換機との違いも簡潔に書かれている。

/* ブートセクタ (PBR,partition boot record) の機種による違い */
/* 一般的な、PC/AT、PC-9801 の PBR(ブートセクタ)との違いは以下。*/
/* ------------------------------------------------------------ */
/* 機種名        オフセット  長さ 意味                          */
/* ------------- ------------ --- ----------------------------- */
/* PC/AT,PC-9801 +000h～+002h (3) IPL先頭のjmp命令(3バイト固定) */
/*                                EB xx 90 または E9 xx xx      */
/* PC/AT,PC-9801 +003h～+00Ah (8) OEM名                         */
/*  …                                                          */
/* ------------- ------------ --- ----------------------------- */
/* FMR/TOWNS     +000h～+003h (4) 署名 "IPLn" (1 <= n <= 5)    >*/
/* FMR/TOWNS     +004h～+006h (3) IPL先頭の命令。主にjmp命令。  */
/*                                jmp命令以外で、かつ OEM名に食 */
/*                                い込んでも問題なくbootされる。*/
/* FMR/TOWNS     +007h～+00Ah (4) OEM名 (参考程度)              */
/* 以降は、PC/AT, PC-9801 と基本的に同じ。                      */
/* ------------------------------------------------------------ */

従って、FMRシリーズやFM TOWNSのMS-DOSでフォーマットされたディスクは、ディスク先頭にジャンプ命令ではなくIPLx（xは1から5の数字）という「署名」が記録されており、ブートコードの署名から対応機種に合致することを確認し、そのブートコードに直接ジャンプしていたことになる。逆に言えば、MS-DOSのシステムディスクは同じFMRシリーズの中でも機種毎に別々のディスクで用意され、異なる機種（異なるIPLxが記録された）ディスクからは起動できないということになる。

なぜFMシリーズ用MS-DOSのブートセクターに署名が必要だったか

上記エミュレーターツールのソースコードには「異なる機種用のコードを誤って実行しないための boot ROM 側の配慮である」と書かれているが、本当にそうだろうか。以下の予想を立てて、それぞれ考えてみる。

  1. アーキテクチャーが異なる機種に対して個別の対応が必要だった
  2. 旧来機種（FM16βやFACOM 9450）用ディスクとの互換性
  3. 機種によって命令コードの解釈が違った

仮定1. アーキテクチャーが異なる機種に対して個別の対応が必要だった

FMRシリーズはシリーズの中でも機種によって区分けされており、アーキテクチャーが異なる。アーキテクチャーの違いはBIOSやOSによって吸収され、FMR用アプリケーションの互換性はこれによって維持することが可能となっている。しかし、当時のソフトの開発事情を考えると、画面解像度やVRAMといった画面処理の根幹に関わる違いに対してマルチに対応するのは難しく、結局は機種毎にプログラムを用意する必要があったと思われる。

ただ、よく考えてみれば、MS-DOSの互換性を犠牲にしてまでブートコードを機種毎に作り替える必要があったかというと、それは疑わしい。機種の判別くらいであればブートコードやIO.SYSなどのMS-DOS起動時のプログラム内で行えば良いだろう。

で、実際の所はどうだったのかというと、機種によってディスクから読み取ったブートセクターの配置先が異なっていたことは確かなようである。配置先アドレス（ロードアドレス）は、512KBのコンベンショナルメモリを持つFM R-30は7000:0000h、768KBのコンベンショナルメモリを持つ系統はB000:0000hとなっている。

ブートセクタの読み込み先（ロードアドレス）を変えることにどんな意味があるのか。

例えば、IBM PCではオリジナルのモデル5150からロードアドレスを7C00hとしている。これは、ブートセクタのサイズ 512バイト (200h) と、ブートセクタ自身が使う作業用メモリ 512バイト、これらを合わせた1024バイト (400h) を8000h (32KB) から差し引いた数字である。32KBのメモリを搭載するモデルで、メモリの末尾にブートセクタを配置し、ブートセクターはメモリーの先頭（正確には400h）からDOSの初期化プログラム (IO.SYSやMSDOS.SYS) を配置していく。そのためのメモリをなるべく多く確保するため、ブートコードは末端に配置するよう設計されたようだ。モデル5150には16KB RAMのモデルも存在したが、DOSには最小32KBのRAMが必要で、16KBのモデルは内蔵ROMにあるBASICでの運用を前提としていたようである。

PC-98は1FC0:0000hとしている。初代PC-9801が128Kバイト (20000h) のメモリを搭載し、そこからブートセクターのサイズ 1024バイト (400h) を差し引いた数字になる。なお、FM記録方式のフロッピーディスクやハードディスクからの起動ではブートセクターのサイズが異なるため、ロードアドレスもそれに応じて変わる。

FM R-30は7000:0000h、FM R-50はB000:0000hとしている。FM R-30のメモリは512Kバイト (80000h) 、FM R-50は768Kバイト (C0000h)で、それぞれから64Kバイト (10000h) を差し引いた数字になっている。

さて、問題は機種毎にロードアドレスを変える必要があったのかという話になる。FMRのハードウェア解説本でメモリマップを見た限り、メモリの先頭から80000hあるいはC0000hまでの間には、先頭の割り込みベクタ以外のシステム使用領域はない。つまり、両機種とも80000hまでのメモリマップは同じということになる。また、IBM PCやPC-98ではメモリサイズが増えた後継機でもロードアドレスは変えていない。通常、OSには自身に必要なプログラムを追加で読み込むための「第2のブートコード」を持っており、この読み込みが完了した時点で最初のブートコードは不要になることから、最初の時点で大容量のメモリを確保する必然性がない。もちろん、ロードアドレスを変更することは互換性に影響する可能性があり、変える必要のない仕様は変えない方がいいだろう。

従って、FM R-50にしても7000:0000hにロードすれば十分で、わざわざメモリの搭載量に応じてロードアドレスを変える必要性は低い。ただ、ブートセクター用に64Kバイトという広大な空間を確保していることを含め、何らかの意図があった可能性はある。FMRは1986年10月発表、FM TOWNSは1989年2月発表と開きはあるものの、FMR開発時点で何かしらの将来性を意識した結果なのかもしれない。

仮定2. 旧来機種（FM16βやFACOM 9450）用ディスクとの互換性

FM-R以前に富士通が展開していたパソコン、個人向けのFM16βや企業向けのFACOM 9450との互換性が理由だろうか。どちらの機種もMS-DOSがオプションで供給されていたが、それらには例の”IPLx”署名が何らかの理由で含まれており、FMRではそれを引き継いだとか。こればかりはそれらの機種のMS-DOSを入手・解析しないことには分からない。そして、旧来機種がそのようなフォーマットを要求するのであれば、データ交換の互換性を確保するためにも必要だったといえる。

ただ、少数の文献を読んだ限り、FMRのアーキテクチャーは旧来機種との互換性よりも「32ビットアーキテクチャーの活用」に力を入れており、旧来機種との互換性は低かったという。実際、FACOM 9450は企業部門で善戦していたが、本流のOSはMS-DOSではなく独自OSのAPCSを採用している。一方、FM16βはパソコン市場で失敗しており、当時の調査でも市場占有率は非常に低い。このことから、まず旧来機種用のMS-DOSをFMRでそのまま使えるようにしたとは考えにくい。また、旧来機種のデータディスクを読むために”IPLx”署名への対応が必要ということであれば、FMRのブートストラップが署名に対応する必要はなく、MS-DOSが対応していればそれで十分だろう。旧来機種での読み取り互換性を確保する目的なら、FMRで非標準のフォーマットを使い続けるよりも、そのようなフォーマットオプションを付けて必要に応じて使った方が良いはずである。

仮定3. 機種によって命令コードの解釈が違った

私は最初この可能性を全く考えていなかった。FMRシリーズやFM TOWNSは基本的に80386などのx86系CPUを使用している。しかし例外はあった。FACOM 9450シリーズの後継機に位置づけられた、FM R-50ΛやFM R-70Σの存在だ。

これらが発表された当初の資料を見直してみると、「FM R-70Σの特徴は、24ドット／16ドット表示を兼ね備えた統合パソコンにある。すなわち、FACOM9450ΣmkII後継機かつFACOM9450ΛmkII互換、FM R-70互換、FM R-50互換」とある。しかも、CPUには「MN1617Xと386のマルチプロセッサを採用」とある。MN1617Xはx86系とは異なる系譜を持つパナファコム MN1610を起源とする16ビットCPUで、この系譜のCPUはFACOM 9450シリーズで使われていた。命令コードも当然x86系とは異なる。資料を読み進めていくと、FM R-70ΣのMS-DOSは富士通独自OSであるAPCSと同時に動作し、排他制御はAPCSにて行うとある。つまり、PC-98におけるノーマル・ハイレゾモードやCPU切り替えといったシステムではなく、MN1617X上で動くAPCSと386上で動くMS-DOSが協調して動作するという風に読み取れる。70ΣがMN1617Xの制御下でブートすると仮定すると、もしx86命令セットを使用したブートコードを実行してしまうと、データ破壊などの予期せぬ結果を引き起こすことが考えられる。FMRシリーズはブートセクターのプログラムを実行する前に、署名を照合してそれがx86用もしくはMN1617X用に書かれていることを確認した方が安全であるといえる。

問題はこれらの機種が1989年に発表されていることだ。FMRが発表されてから3年近くが経っている。また、対応する署名も”IPL5”となっており、数字の並びではFM TOWNSよりも後になっている。しかし、FM R-60, 70は当初からグラフィック制御用にFACOM 9450Σと同じHD63484を搭載している。グラフィックの仕様は異なるものの、当初からFMRがFACOM 9450とのアーキテクチャーの統合を狙っていた可能性は残っている。

FM R-70ΣがIPLx署名から動作モードやCPUを選択していた可能性はあるだろうか。例えば、”IPL1”であればFM R-70互換でCPUは80386、”IPL5”であればFACOM 9450ΣmkII互換でCPUはMN1617Xといったように。もしそうであれば、ディスクに署名を入れる方法はスイッチを切り替える手間を省ける利点がある。ただ、発表資料ではFM R-70ΣでFM R-70用のOSがそのまま使用できるかどうかは明言されていない。私の予想では、FM R-70互換というのはあくまでOS上のアプリケーションレベルでの互換性と考えている。

もう一つの謎：ブートセクターの先頭に署名を入れた理由は？

MS-DOS標準フォーマットの構造を考えると、OEM ID（ボリュームIDとは別）を署名に利用すれば互換性を捨てる必要はない。ただ、署名チェック自体がFMシリーズ独自の機能だから、将来的にOSが変わったりフォーマットが変わったりする可能性を考慮すると、ハードウェアの署名チェックをMS-DOSに特化するよりも独自のフォーマットを優先したのだろうか。1986年頃というと、富士通が国内でパソコンを除くコンピューター市場において絶頂期にあり、独自のプラットフォームの構築を優先してもおかしくはない。

あるいは仮定2に関連して、以前のMS-DOSやAPCSが元々同様のフォーマットや署名チェックを使用していた可能性はあるだろうか。

この謎はMS-DOSの非互換性を引き起こした核心部分であるが、今のところ明快な答えを見つけるには至っていない。

MS-DOS OAKに潜んでいた謎：69h ‘i’

ここまでFMRとWindows NTのソースコードに含まれている49h ‘I’の謎について考えてきた。しかし、MS-DOS 3.21 OAKのソースコードは69h ‘i’となっている。

同じIの大文字・小文字であることに共通点を見いだせるが、MS-DOSのOAKでは小文字のiとしたことにどんな理由があるのだろう。MS-DOSのコマンド入力やファイル名に大文字・小文字の区別はないが、該当のプログラムは単純にCPUによるデータの比較であり、その言い訳は通用しない。あるいは仮定2に関連して、元のフォーマットが”iplx”というように小文字だった可能性も否定できないが、この場合はなぜFMRで大文字の”IPLx”に変わったのかという疑問が生じる。後から小文字に変更したならともかく、最初から小文字で”ipl”とする可能性は低いだろう。

MN1610系のCPUを使用するFACOM 9450が69hをブートコードの一部として先頭に使用していた可能性はあるだろうか。MN1610系は16ビット固定長の命令セットであり、69hから始まる命令はAND, ANDI, LAD, LADIが該当するようだ。これらはジャンプ命令ではないが、その後のOEM ID（8バイト）の部分をブートコードに使えば、BPB (BIOS Parameter Block; MS-DOSから参照されるディスクの仕様情報) までにジャンプ命令を挿入することは可能だろう。ディスクの仕様を解析しないことには分からないが、理由としては若干こじつけのように思える。

ところでもう一つ奇妙なことに、このソースコードの直前に書かれているコメントには「最初の2バイトはロングジャンプか、ショートジャンプにNOPが続かなければならない。」という説明がある。69hや直接ジャンプについての言及がないのだ。これは暗に「それはマイクロソフトが定めた仕様ではないが、PCベンダーの要望あるいは互換性の懸念から組み込んだ。」と言っているのだろうか。

ここで別の仮定が浮かび上がる。このコードは専ら富士通からの要望を受けて用意されたかもしれないが、OAKそのものは様々なベンダーに供給されるものである。1980年代のマイクロソフトはMS-DOSを様々な機種に採用してもらうため、なるべく全てのPCベンダーに平等な立場をとる必要があった。その経緯をコメントに書いてしまうと富士通に肩入れしていると受け取られかねない。また、69hは8086 CPUでは未定義、80186以降では2オペランド・4バイト以上のIMUL命令だが、49hは8086でオペランド無しのDEC命令として使用される。PCベンダーからの視点では、DEC命令 (49h) を直接ジャンプと説明されると矛盾が生じる。しかし、IMUL命令 (69h) はそもそも冒頭の3バイトに収まらず、69hが命令コードを指しているとは考えにくい。何らかの互換性を確保していると考えた方が自然で、そこに疑問を投げかける者は少ないだろう。ブートコードの一部として使われる心配もない。そして、富士通は69hを49hに修正するだけでよい。

最後に

この疑問が晴れることは今後一生ないかもしれないが、こうして考察するのは面白かった。そして、わずか2行のアセンブラコード、1バイトのデータからここまで深く話を掘り下げたOS/2 Museumの面々に尊敬するとともに感謝したい。

4/9追記

本ページには次のような誤った認識があります。

  1. BPB (BIOS parameter block) はディスク上に記録される、ディスクの内部構造を表すデータである。 ⇒本来はMS-DOS内部のIO.SYSやデバイスドライバが持っているデータを指します。
  2. MS-DOSの標準的なフォーマットでは、先頭セクターにジャンプ命令やBPBを配置してから起動用プログラム（ブートコード）を配置する必要がある。 ⇒Windowsでは必須だが、MS-DOSでは必須ではありません。
  3. 69hは8086 CPUでは未定義 ⇒命令コード69hはIntel 8086/8088では79hとして解釈され、79hはJNS (Jump short if not sign)という条件付きジャンプ命令です。ただし、これはIntelの文書に記載されていない非公式の挙動であり、80186以降はIMUL命令が割り当てられます。どちらにしてもx86系の命令コードを指していたとは考えにくいですが…

いくつかの見落としと誤解があったため、更に調査を行いました。

次の記事→ (続) 富士通FMシリーズの特異なブートセクタ (IPL) - Diary on wind

参考文献

※コメント欄が表示されない場合はdisqusについてJavascriptが有効であることを確認して下さい。コメントはスパム防止フィルターによる承認制のため、投稿してもすぐに反映されない場合があります。

管理人 : Akamaki (akm)

は、PCとVTuberに夢中になっている電気技術者です。

私はレトロコンピューティングの愛好家ですが、そのようなリグはもう収集していません。

私の活動はトップページで見ることができます。読んでくれてありがとう！