第三章 『 RBFという迷宮』《 OS-9のディスクを読む 》
【OS-9のディスクを読む】
SWI2を実装すると、OS-9のプログラムが少しずつ動き始めた。
これは面白い。画面に文字が出る。プログラムが終了する。
簡単なものなら、それなりに動く。
ところが、当然のように次の問題が出る。ファイルである。
OS-9のプログラムは、ファイルを開こうとする。
「そんなもの、Windowsのファイルを開けばいいじゃないか」
最初はそう思った。
実際、それでもよいのである。現にそうしてみた。
WindowsのディレクトリをOS-9のディレクトリのように見せて、openされたらWindowsのファイルを開く。
簡単なプログラムなら、それで動く。
しかし、私が使いたいものは、そこにはない。
昔のOS-9のディスクの中にある。
OS-9のコマンド群、マイクロウエアのCコンパイラ。アセンブラ。
いろいろな、ソースファイル。
せっかく昔のディスクをイメージ化したのだから、そのまま使いたい。
もちろんエディタもある。まあ、これは最新のものを使いたい。
OS9のファイルシステムで書かれた、RBFイメージファイルを読まなければならないのだ。
1 RBFって何？
読者のために解説しておこう。
OS-9を使っていたころは、RBFなんて意識していなかった。ディスクを入れて、
dir
と打てばファイルが出る。
chd
でディレクトリを変える。
copy
でコピーする。それだけである。
RBFとは、Random Block File Manager。
OS-9のディスクファイルシステムを担当しているプログラムである。
使っている側からすれば、そんなものを知らなくてもよい。
ところが、今度は自力でその中身を読まなければならない。
手元には富士通の青い本であるOS-9のマニュアル群や、秀和の解説書、日本で出版されたありとあらゆるOS-9関連書籍があったりする。
意外と構造の載っている本は少ない。
LSN0。
File Descriptor。
Bitmap。
Directory Entry。
そうそう、こうだった。
思い出してくる。
そして、昔の資料を今読むと、当時とは読み方が違う。とりあえず、イメージファイルをダンプしながら確認である。
【 2 まずLSN0を読む】
RBFディスクの最初には、LSN0がある。
Logical Sector Number 0。
名前の通り、論理セクタ0番である。
FMシリーズの場合、星光電子が最初FM-8移植した版はそのままだったが、富士通版はトラックがオフセットしてあるので、CoCo版とは違うのである。
MS-DOSやF-BASICのFATとは違う。ここにディスク全体の情報が入っている。
ディスクサイズ。クラスタサイズ。Bitmap。Root DirectoryのFile Descriptor。その他いろいろ。
つまり、「このディスクはどういうディスクですよ」という名札みたいなものだ。ファイルダンプソフトで、イメージファイルを眺める。そして、ソフトでまず、ここを読む。バイト列を表示する。資料と見比べながら読む。Windwosには他人の作ったツールもあるが、昔F-BASICで作ったツールもあったので、やり方が思い出される。
ここがTotal Sectorだったな、ここがRoot FDだったな、などと懐かしく思い出される。Root DirectoryのFile Descriptorが分かれば、そこを読む。すると、そのディレクトリのデータがどこにあるか書いてある。そこへ行く。するとDirectory Entryが出てくる。ファイル名と、そのファイルのFile Descriptorの番号がある。そのFile Descriptorへ行けば、ファイルサイズやデータの場所が分かる。なるほど。ちゃんと筋が通っている。この構造、４0年も前のファイルシステムだが、なかなかよく出来ている。
【3 ところが、フロッピーは素直じゃない 】
ここで一つ問題がある。
OS-9から見ると、ディスクは、LSN0、LSN1、LSN2……と、きれいに並んでいる。しかし実際のフロッピーディスクはそうではない。
Cylinder、Head、Sector、そしてセクタサイズ。
さらにFM-11のディスクは、これが少し変わっているものがある。最初のトラックだけ構成が違うのだ。片面単密。128バイトセクタがあったりする。その後は256バイト。26セクタ。昔は電電フォーマットと呼んでいた5インチ２HDである、8インチの2Dディスクに合わせているから、今の感覚で見ると変なものだ。しかし当時は普通だったのである。
先に、ディスク吸出しツールを作っていたのだが、FM-Rで読むソフトを作っていたMiyazaki氏のソース、F-BIOSを利用したものだが、これを真似して、PC98のBIOSを利用し作り直したPC-9821用のツールがある。
FM-TOWNS時代のHi-Cで書いたものがあるのだが、これは動かない。
5インチ２HDのドライブがついているのは、PC286や98DOである。DOS-Extenderが使えない。古いコンパイラーで使い方のわかっている、PowerCで書いた。ラージモデル、懐かしいね。
それで、PC-9821で吸い出したRAWイメージを見ながら、「これは、どこがLSN0なんだ？」というところから始める。
世の中には、D88もある。それのネーム変更版のD77もある。こちらのツールが主なのだが、これはまたの機会にすることにして。とりあえずイメージファイル、RAWファイルだ。
【4 ファイル名が変だぞ】
Root Directoryが読めるようになって、「よし、dirを出してみよう」と思った。ところが、ファイル名が変である。頭は合うのだが、文字の表示がバグる。何だか覚えがあるぞ、これは。資料を見ると、ああ、そうだったOS-9のファイル名はC言語みたいな0終端ではないのだ。最後の文字のbit7を立てるのである。だから、OS-9では、7ビット文字しかファイル名に使えないのである。
これはOＳ-９の最大の欠点だった。最後の文字のビット7を立てておくのである。
ダンプイメージを見て思い出す。作ったのはアメリカ人だからね、終端用の0を1バイト使うより、最後の文字の最上位ビットを使い、1バイト読んでマイナスなら終わりにしていた。これは、マイクロソフトBASICの予約語であるコマンドなどもそうしている。
また、使えない文字も結構ある。リストアップすると、小文字の！＃＄％+-・＜＝＞＠￥である。これを忘れると、幽霊ファイルが出来てしまう。
昔は、そういう時代だった。SIFT-JISで2バイトを使い、UNICODEで32ビット文字が使える現代とは大違いだ。
だから、直す。Signed char が負になるまで読み出し、終端文字として、$7Fでマスクして表示するのだ。
なおしてから、もう一度dir。今度は、
CMDS SYS DEFS SRC Window2 StartUp
と出た。
「おおっ！」ついに昔のOS-9ディスクのディレクトリがWindows上に出た。これは、うれしい。ただのバイナリイメージだったものが、急に昔のディスクに戻った感じだ。
【 5 File Descriptorというやつ 】
OS-9では、Directory Entryにファイルの全情報が入っているわけではない。
そこにはファイル名と、File Descriptorの場所がある。
File Descriptorには、属性 所有者 日時 ファイルサイズ そしてデータのセグメント情報 が入っている。
今のファイルシステムで言えば、inodeに近い。ファイルのデータは、必ずしも連続していない。何セクタかの塊がいくつもある。そのため、File DescriptorのSegment Listを順番に読んでいく必要がある。昔は「面倒だなあ」と思った。でも、よく考えるとよく出来ている。ディスクが断片化しても、ファイルを複数の場所に置ける。当たり前のことだが、8ビット時代のDISK-BASICでもちゃんとやっている。
OS-9は、UNIXライクOSなのだ。
【 6 まずは読むだけにしよう 】
ここで一つ方針を決めた。「最初は書かない。」読むだけ。古いディスクには、もう二度と手に入らないものが入っている。下手なプログラムで壊したくない。幸い、イメージファイルならコピーはいくらでも作れるがうっかりすると壊してしまう。
まず、dir ができる。ファイルをopenできる。readできる。seekできる。closeできる。そこまで作る。これだけでも、かなり使えるのだ。
昔、G-EDITAVでDISKBASICのコンパクト版を作った時を思い出した。
Windows上からOS-9ディスクを見ることができる。OS-9の実行モジュールを読み込むこともできる。そういうツールを作ったのだが、それを発展させたものが、このプログラムである。つまり、昔のディスクから昔のプログラムを読み込んで、Windows上の6809エミュレーターで実行できるのだ。
MIYAZAKI氏のFM-11シミュレーターでOS-9を動かし、マイクロウエアCで即席のファイルリード表示プログラムを作ったり、ファイルDUMPプログラムを作ったりして、そのバイナリーを持ってくる。
動く！やったね！読める読める！
FM-11シミュレーターがあるのはとても助かる。
こうやって、ネオマンハッタン 略してNMHシステムが形になってきた。
【 7 外へ出したい】
元々、「中のファイルをWindowsへ出したい」という目的のために作ったプログラムに、実行ソフトをくっつけたものであるから、Windows上で動いているこのNMHに「copyout」コマンドを作った。
システムが直接にRBFのファイルを読み出すのだ。Segment Listをたどる。データを読む。そして、Windows側へ普通のファイルとして保存する。これができると世界が広がった。
OS-9のソースファイルをVisual Studioやエディタで読める。バイナリを逆アセンブルできる。
バイナリをAI君に渡すと、6809コードとして読んで解説してくれる、ディスアセンブラになる。これは有りがたい。比較できる。検索できる。むかし、インタラクティブという言葉が流行ったが、そのものなのである。そうして、それまでディスクの中に閉じ込められていた40年前のファイルが、現代のPCへ出てきた。これが大きかった。
もう忘却の彼方に沈んでいたものが、ディスクがよみがえる。特にソースファイルである。確か作ったはずだ、というものが出てくる。読んでみると、若い日に自分で書いたものなら、大体覚えている。が、忘れていて、おお！こんなことしていたんだというものも出てくる。
グラフィックエディターのソースコードなどは、Cで書いた後、アセンブラで最適化して、縮めているが、この原版からGeditTownsを作っているから、GUIもあって、面白い。FM-TOWNSに移植したときのことを思いだしたり、これはSmall-Cのライブラリーを修正して利用していたんだなあなどとおもいだした。このゲームは会社の同僚のY氏がDOHCで書いた物がベースだな、とか見て分かる。面白い。自分で作ったFM音源のミュージックエディターなんかもある。
【 8 今度は戻したい 】
人間は欲張りである。取り出せたら、戻したくなる。Windows側で修正する。
再アセンブルしたい。再コンパイルしたい。
コピペは通るけど、エミュレーター上のエディターは遅いので取りこぼす。
やはり、きちんとOS-9イメージファイルに戻したい。戻すと最低限FM-11シミュレーターでコンパイルできたりする。
と言うわけで実装するのが、【copyin】である。
しかし、これは怖い。読むだけなら間違えてもディスクは壊れない。書くとなると違う。破壊する可能性が大である。
空きセクタを探す。
Bitmapを書き換える。
File Descriptorを作る。
Segment Listを書く。
Directory Entryを追加する。
既存ファイルならどうする？上書きする？
サイズが大きくなったら？
小さくなったら？
途中で失敗したら？
ひとつ間違えると、ファイル一個では済まない。
ディスク全体の管理構造を壊す可能性がある。
「これは慎重にやろう」
となった。
まずコピーしたイメージで試す。
壊してもいい。
壊れたら、またコピーする。
今はストレージが大きい。
昔ならディスクイメージ一枚を何十個も保存するなんて考えなかった。
今なら、いくらでもできる。
これは本当にありがたい。
【 9 mountしてみる 】
NEO MANHATTAN側では、RBFイメージを、
mount /d0 disk.img
のようにして使いたい。
OS-9プログラムから見れば、
/d0
である。
Windowsのどこにあるファイルなのかは知らなくていい。
これは大事だ。
昔のOS-9プログラムは、
/nd0
/nd1
/h0
/h1
などを前提にしている。
Windowsの、
C:\xxxx\yyyy\disk.img
なんてものを見せたくない。
OS-9側はOS-9らしく。
Windows側はWindowsらしく。
その間をNEO MANHATTANがつなぐ。
この考え方は、後でCP/MにもF-BASICにも効いてくる。
---
【10 CHDとCHXが違うんだった 】
RBFを使い始めると、OS-9特有のところが次々に出てくる。
たとえばCHDとCHX。
データ用のカレントディレクトリ。
実行ファイル用のカレントディレクトリ。
別である。
長年WindowsやMS-DOSの感覚でいると、
「カレントディレクトリは一つだろう」
と思ってしまう。
ところがOS-9は違う。
昔は普通に使っていたのに、作る側に回ると忘れている。
「ああ、そうだった！」
ということが何度もあった。
PWDはデータ側。
実行側を見るなら別。
こういう細かいところを適当にすると、昔のプログラムが妙な動きをする。
だから結局、当時の仕様に戻って調べる。
本を読む。
直した実機で試すのも良いが、もっと便利な、M氏のFM-11シミュレータで試す。
【 11 本物のOS-9ならどうする？】
ここでM氏のFM-11シミュレーターが非常に便利になる。
NEO MANHATTANは、OS-9そのものを起動しているわけではない。
Windows上でOS-9のサービスを再現している。
だから、何か変な動きをしたとき、
「NEO MANHATTANのバグなのか」
「OS-9本来の仕様なのか」
分からないことがある。
そんな時は、このFM-11AD2+を起動する。
こちらでは本物のOS-9が動いている。しかし、これにはまだマンハッタンシステムはシミュレートされていないのが残念だ。（この時はそうであった、今はほぼ完ぺきにシミュレートされている。）
同じディスクイメージがマウントできる、同じコマンドを打つ。比べる。これは強い。仕様書を読むだけでは分からないものも、実際に動かすと一発で分かる。
「なるほど、本物もこうなるのか」
ならNEO MANHATTANもそれに合わせる。
「いや、本物は違うぞ」
なら、こちらのバグだ。だんだんこのFM-11シミュレーターが、**動く仕様書**のようになってきた。
【12 ディスクが読めると、昔が近くなる 】
RBFを読めるようになると、昔のOS-9環境が急に近くなった。
単なるディスクイメージではない。
dirできる。
ファイルを開ける。
ソースを読む。
モジュールをロードできる。
Windowsへ取り出せる。
戻すことも考えられる。
40年前のディスクが、現代の開発環境の一部になっていく。
これは、ちょっと感動する。
保存とは違う。
使えるのである。
そして、使い始めると、昔の記憶がどんどん戻ってくる。
「このコマンド、こう使ったな」
「このディレクトリ構成、覚えてる」
「このファイル名、懐かしい」
その中にはManhattan関係のものもある。
pCPM。
pOS9。
ApIf。
ApDv。
昔は、ただ使っていた。
今度は中身を見る。
逆アセンブルする。
AI君にも読ませる。
そして、
「これ、今なら作り直せるんじゃないか」
と思い始める。
【 13 読むだけでは終わらなかった】
RBFは読めるようになった。しかし、当然それで終わらない。書き込み。
rename。delete。新しいファイルの作成。ディレクトリ。モジュールロード。
mount。
そして、実際のOS-9プログラムを動かしていると、「そんな使い方するのか！」というものが次々に出てくる。
最低減コンパイラーが動くと作られる中間ファイルを読み書きできなければならない。RBFの6809コードのドライバーを流用することも考えたが、そうするとものすごく複雑な感じになりそうである。
というわけで、OS-9相当部分をCで書くのである。しかし、ファイルネーム関係で、後になってたった一つのrename処理が、文字列の終端を０とみなすプログラムが混ざっていて、ファイル名の終端後に古い文字を残していた、なんていう、とんでもない問題まで出てくることになる。
その時はまだ知らない。ただ、「だいぶRBFのコードが出来た」くらいに思っていた。RBFは、まだまだ奥が深かった。
しかし、その前に。
このRBFの動きを確認するために、何度も使うことになる「もう一台のFM-11」の話をしておきたい。
1999年頃からM氏が作り続けてきた、
FM-11AD2+。
63C09仕様。
その上では、
OS-9そのものが動く。
そして、このシミュレータの存在が、
NEO MANHATTANの開発を何度も助けることになる。
# 幕間IIへ
## 『もう一台のFM-11――1999年から続くFM-11AD2+シミュレーター』
