ORG 0h start: JMP pstart1 ; offset 00h jmp near code DB "ROM" ; offset 03h identifier of this program DB "PC9821" ; offset 06h OEM signature ? (size 6B) FD_data_size DW 0000h ; offset 0Ch Data size by KB CheckSum9821h DW 0000h ; offset 0Eh 全WORDチェックサムを9821hにする所 pstart1: ここから任意のプログラム・コード
ですのでどんなプログラムでも書いてよいのですが、BIOSコールが一切使えない(割り込みベクタが未設定状態)、多くの周辺ハードウェアが未初期化である、という厳しい条件でのプログラムとなります。グラフィック画面もそのままでは表示できません。ディスプレイコントローラ周辺のI/Oを適切に処理しないといけないようです。キーボード入力もBIOSが使えませんので、41h,43hのポートを操作する必要があります。とりあえずレガシーな98の機能だけは使えるようです。PCIデバイスは、ホストブリッジの最低限、Cバスブリッジの最低限しか初期化されていません。
プログラムの開始条件もよくわかっておらず、機種によっても異なるようです。たぶん仕様で間違いないと思われることは、FDローダの開始点(CS:IP)が0060:0000であり、CS=DS=ES=0060hであることです。SSはよくわかっていませんが0000hの機種もありました(*)。これはDOSのIO.SYSや、さまざまなIPLとよく似ています。割り込みベクタやBIOSワークエリアは未設定ですが、それらに影響を与えない仕様となっているようです。
なおBIOSワークエリアで設定済みなのは、 0455h (値C0h)と 0501h(値04h)だけです。後者は初期の9801からある1MB以内のメモリサイズ表示フラグで、640KB OKであることを意味しているだけです。前者は詳細不明ですが0455h bit6はFD loader実行フラグの可能性があります。
(*)<2019-2-23 追記> ロード実行開始時のSS:SPは機種により異なるようです。0000:0A05などとなっている例もありました。この場合、スタックの基底と0060:からのプログラム領域との間は39KB程度しかないことになりますので、データやコードが大きくなるとぶつかる恐れがあります。DOSのCOMファイル型プログラムを前提に設計しているとDS=SS、SP=64KB最大限 ですので、予期せぬバグが発生するかもしれません。基本的にはスタックはそのまま使うのではなく、FDloader自身で再設定して切り替えたほうがよいでしょう。そのほうがプログラムの設計自由度が上がります。