「仰天もののディスケット」にはちっとも仰天しないという話

computer


少しレトロなテクノロジーのことが書いてあって、懐かしく思ったので当時のことを振り返って書いてみます。


仰天もののディスケット(本の虫)
http://cpplover.blogspot.com/2008/10/blog-post.html

一体誰がこのディスクフォーマットを手動で構築し、何を考えていたのか、
それが知りたい。発売元からの要求を満たすため、何週間も試行錯誤した上での
産物なのだろうか。あるいは、恐ろしく凄い奴で、わずか一日程で、これも仕事
のうちさと気軽に構えて、事もなくやってのけたのか。素晴らしい逸品だ。

ちょっと、ちょっと！！そんなの、全然凄くないっすよ！！

まさか混在フォーマットとは、世の中には凄い奴らがいるものだ。その昔、
FDを独自フォーマットにして容量を稼ぐという技術があったと聞くが、これは
知らなかった。

小学生のときにDIH(Double Index Holes)プロテクトを開発した私(→ http://d.hatena.ne.jp/yaneurao/20040805)からすれば、独自フォーマットで容量を稼ぐのは基本中の基本でした。


プロテクトとして、2HDのFDで、1セクタだけ2DDフォーマットしたり、FDC(Floppy Disk Controller)のバグを利用して、本来書けないデータを書き込んだりするのも必須テクニックでした。


例えば、SHARPのX1シリーズはクリーン設計のため、BIOS/ROMに相当するものがなかったのです。それゆえ、IPL(＝Initial Program Loader≒boot loader)がテープメディア or FDDからプログラムを読み込んだあとは、自力で(BIOSの力を借りずに)floopyにアクセスする必要がありました。


市販のソフトを出すならば、途中loadするタイプのゲームは、かならずFDDアクセスルーチンは自前で持っておく必要がありました。


つまり、当時の商用ソフトを出している誰もが、FDCにアクセスして、floopyを回転させ、seekして、index holeを検出して、1セクタ読み出す/書き出すというプログラムを書いたわけです。


そこまで書けていれば、formatterを書くのは容易です。file systemも自前のもので良いし、場合によってはfile systemすら持っていなくとも良いのです。FDまるごとを1本のstreamのように扱って良かったのです。「ゲームのマップデータは、各ステージごとにトラック15から1トラックずつ使おう」とかそういう乱暴も許されました。


それゆえ、例えば、1トラックのセクタ数を変更したり、セクタ番号を飛ばし飛ばしに(interleaveで)フォーマットをするのは、自前のformatterをちょっと書き直すだけで済みました。


私が凄いと思ったのは、SHARPのX1用の「リバイバー」です。次のマップのロード中にもBGMが途切れませんでした。X1turboシリーズにはCTC(Counter Timer Circuit)というインターバル割り込みを実現するための機構があり、こういうことをするのも比較的容易ではあるのですが、X1シリーズ(≠X1turboシリーズ)にはCTCは搭載されておらず、それはすなわち、1セクタの読み込みに必要なクロックを計算しておいて、1セクタの読み込みごとにBGMを再生するルーチンを呼び出してやる必要がありました。


また、FDの読み出しにかかる時間は一定ではなく、BGM再生ルーチンが呼び出されるタイミングはjitterringを伴うので、前回に呼び出された時刻からの経過時間をパラメータとして渡して補正する必要がありました。まあ、これをZ80アセンブラで書くのはなかなか職人芸的ではあるのですが、当時、商用ゲームを開発していた現場のプログラマならやって出来ないことはない範囲でした。


ところが、BGM再生をしていると、その処理時間によってFDが回転してしまい、次のセクタ読み出しが間に合わなくなってしまうので、セクタをinterleaveする必要があったのです。


ただ、私は数年前に「リバイバー」の制作者である吉村氏と話す機会があったので、そのへんの事情を確認のため聞いてみたところ、「あれ(独自フォーマットにしたの)は、BGM再生のためというよりは、FDDの容量を増やす意味合いのほうが大きい」と言われてしましたが。


少し話しを戻して、当時のゲームの大半には、本当に様々なプロテクトがかかっていました。それは、たいていのソフトメーカーが自前でformatterを作っていたから、それをちょっと工夫して、プロテクトをかけることはさほど困難ではなかったからです。部分的にunformatにしたり、不安定ビット(読み出すごとに値が変わる)を書き込んだり、FDDに紙を挟んで回転数を遅らせて書き込みしたり、ターゲットマシンのFDCでは書き込み無いデータを別のFDCを持つ機種から書き込んだり…。


そんな状況でしたから、2つの機種でブートセクタが異なるなら、それを利用してどちらの機種ででも立ち上がる混成FDを作ることは朝飯前だったわけです。あるいは、同じブートセクタであっても、ハードの違いを検知してブランチさせたり、CPUが異なるなら、うまくブランチするコードを書いて、どちらの機種でも動くようにすることは当時の開発者なら誰でも(?)出来たわけです。私もご多分に漏れずそういうFDを作ったことがあります。


原文には「あるいは、恐ろしく凄い奴で、わずか一日程で、これも仕事のうちさと気軽に構えて、事もなくやってのけたのか。」とありますが、その人は一日どころか、1時間すらかからなかったと思いますよ。