随想

親というものは何歳になっても自分の子供は子供に見えるという。昨日、親が外から帰ってきて私にプレゼントがあると言った。ペンギンの抱き枕だった。この歳のおじさんにペンギンは辛い。しかも抱き枕だから、巨大なペンギンだ。私は対応に困ったが、とりあえず丁重にお断りした。別に動物の形をしていなくても抱き枕として機能するだろうに。どうしても動物というならば、せめてアザラシくらいにしてほしかった。そこで私は、いくらでも売っていそうに思えたアザラシの抱き枕をインターネットで検索した。そうしたら、あるにはあるが、思ったほど売っていなかった。アザラシが流行ったのははるか昔だからだろうか。いやそれ以前に驚いたことがある。抱き枕といえば実用的なものだ。そのはずだった。ところがネット検索して出てきた画像の大半が、エッチな漫画絵の抱き枕ではないか。中にはエッチでないのもある。おそ松さんの抱き枕。それはそれで、おじさんはどう反応していいかわからない。世の中がここまで来ているなら、いっそのことエッチな抱き枕というのはどうか。私は画像を見ていった。そして落ち込んだ。知っているキャラクターがいない。知っていたのはレールガン女だけだったような気がする。自分がアニメ関係から遠く取り残されているのはとっくに知っていたが、いざその現実をまのあたりにするとやはり落ち込む。何とかしなきゃと思いながら延々と生きている自分が辛い。アニメは、かろうじて境界のRINNEはまだ見ている。高橋留美子の作品はハズレがない。でもとにかく抱き枕は、エッチなのもエッチでないのもやめた。例の巨大なペンギンは、いま母の部屋で宙を見つめている。

いけない、前置きが長すぎて外出時間が近づいた。そう、抱き枕は実は前置きだ。本題のほうを数行で片付けて私は外出の用意をしなければ。ようするに抱き枕を諦めた私は、他に何かないかと「ついでのネットサーフィン」をしていた。そうしたら昔のPC-98ゲームのデータベースと称するサイトに行き当たった。
https://refuge.tokyo/pc9801/pc9801.html
これが、ものすごい数のゲームを紹介している。昔のものばかりに興味を示すのは私の残念な所だが、それでも何かに興味があるのは、何も興味がないよりはいい。このサイトを余暇に見ていったら、何日も、いや何週間も楽しめるのではないか。

結果の追求ではなく、今の幸せのために【T98NEXT+Windows95】(3)

私の実験場のWindows95は画面解像度が640x400で色数が16色です。これらの値はどちらも、多くのWindows95用ソフトをまともに動かせない値です。少なくとも640x480、256色にしなければなりません。私はずっと、ドライバソフトが必要なのではないかと考えています。前回試したMIDIの場合を参考にして考えると、こうなります。T98NEXTの作者さん自身が、MIDIを鳴らすためにはmpu98.nhwとMPU401コンパチドライバが必要と書いていました。つまりデバイスに相当するnhwと、デバイスドライバが必要でした。画面も同じではないでしょうか。GDC.nhwと、そして何か適切なドライバが必要なはず。Windows95の「ハードウェア ウィザード」で「ディスプレイアダプタ」という所に表示されるのが、きっとそのドライバソフト。考え方としては合っている気がしませんか？ではその適切なディスプレイアダプタは、どれなんでしょう。

ひょっとすると、本来ならばインストール時に自動的にそのドライバが選択されるはずだったのかもしれませんね。それが何の因果か選択されなかったのかも。T98NEXTの作者さんがディスプレイアダプタについて何も書いていないのも、本来は自動的にインストールされるはずだからかもしれません。で、実際には自動的にインストールされなかった。だから今から何とかしなきゃ。

念のためにひとつ考えておくべきことがあります。ディスプレイアダプタをネット上のどこかから取ってきて入れてやる必要があるかどうか。以前に調査した時の私のメモに、こんなことが書いてあります。PC/AT互換機用エミュレータのために作られたディスプレイアダプタがネット上にあり、これをエミュレータに組み込むと高解像度フルカラーを実現できるそうです。この場合は、Windows95に含まれるドライバではなく、後年に作られたドライバを入れてやるわけです。でもT98NEXTの作者さんはディスプレイアダプタに何も言及していません。もしも特別なソフトが必要ならば言及しているはず。だから特別なソフトは、要らないはずなのです。

もうひとつ考えておきます。現状で、T98NEXT上のWindows95は稼働しています。すでに動いてはいるのです。そして、T98NEXT作者さんによると20100611bは「人柱版」です。現在開発途中で、みんなで一緒に改良してゆこうというわけです。ということは、ひょっとして現状でここまでの機能（640x400、16色）しかないという可能性は、あるのでしょうか。これについては、同じく作者さんのサイトにある次の言葉を信じることにします。

やっつけにつき、256モードも、CPUも、Win95専用です

256モードというのは、256色モードですね。つまり、どうにかすると256色までは出るはずなのですね。それなら、実験を続けようではありませんか。

Windows95の「ハードウェア ウィザード」で「ディスプレイアダプタ」という所には多くのアダプタが表示されますが、その多くは特定の機種の名前が付いています。そんな特定の機種用のアダプタがGDC.nhwに使えるとは思えません。もちろん今までにいくつか試しました。初期状態で選択済みのディスプレイアダプタ。私の機種と同じディスプレイアダプタ。どれも駄目でした。可能性があるのは汎用的なアダプタのはず。特定の機種の名前が付いていないもの。

ディスプレイアダプタの[製造元]にMicrosoftはありませんでした。そうなると、PC-98ですから[製造元]はやはりNECでしょうか。試してみましょう。




[製造元]NEC
[モデル]スタンダード ディスプレイ アダプタ (9821 シリーズ)
結果：
メッセージ「インストールしようとするハードウェアと競合するハードウェアが使用されています」が出た。[次へ]をクリックして続行した。
インストールは完了したが、競合があると出た。引き続きトラブルシューティングを参考に調べてゆくと、競合ではなく、トラブルシューティングでは解決できないと出た。
デバイスマネージャで[スタンダード ディスプレイ アダプタ (9821 シリーズ)]のプロパティを見ると、デバイス エラーになっていた(Code 27)。
[画面のプロパティ]の[ディスプレイの詳細]では、[カラー パレット]に256色だけが選択可能だった。256色が選択されていても実際の画面は16色だった。[デスクトップ領域]は灰色表示で設定不可だった（640x400のまま）。



この手の実験は以前にもたくさんやって、それで以前は駄目だったのだから、今回簡単には解決しないようですね。でも気長に行きます。[製造元]がNECでは駄目なのでしょうか。もっと汎用的な、製造元がどこだかわからないというのを試したらどうなるでしょう。



[製造元]その他のディスプレイ アダプタ
[モデル]その他のディスプレイアダプタ
結果：
インストールは完了した。再起動が始まった。
エラーメッセージ「ディスプレイ アダプタが正しく設定されていません」が出た。
デバイスマネージャで[その他のディスプレイアダプタ]のプロパティを見ると、デバイスの状態が「存在しないか、正常に動作していないか、またはすべてのドライバがインストールされていません」(Code 24)だった。
[画面のプロパティ]の[ディスプレイの詳細]では、[カラー パレット]に何ひとつ選択可能でなかった。画面は16色だった。[デスクトップ領域]は灰色表示で設定不可だった（640x400のまま）。



[製造元]の名称はディスプレイとアダプタの間に半角スペースがあり、[モデル]の名称は半角スペースがありませんでした。それはもちろん、どうでもいいことですが、実験の経過については事細かにメモしておこうと思っています。仮にこのあと私が忙しくなって１か月後に実験を再開したとしたら、その時には色々なことを忘れているはず。すべて忘れた人間でも読めばわかるように、何でも細かく記録しておくのは大事です。今までに何をやったか。何から再開したらよいか。

私はひとまず頭を冷やして出直します。きっと私が見落としている何かがあるのです。この問題をいつも考えていたら、そのうちにふと道が開ける時が来るかもしれません。きっと大事なのは、いつも作業を楽しむことです。結果の追求ではなく、今の幸せのために。

結果の追求ではなく、今の幸せのために【T98NEXT+Windows95】(2)

そういえば、T98NEXTの作者さんのサイトで、「Win95をインストールしたい人柱版」の所にこんな風に書いてありました。

MIDIは、mpu98.nhwを入れて、MPU401コンパチドライバ、E0D0-E0D2、IRQ6で動きます

つまりmpu98.nhwとMPU401コンパチドライバが存在して、E0D0-E0D2とIRQ6の設定をすればMIDIは音が出るはずなのですね。これから始めましょう。まずはドライバのインストールです。



[コントロールパネル]から[ハードウェア]を開くとダイアログボックス[ハードウェア ウィザード]が開く。
自動的に検出というのは無意味なのでラジオボタンの[いいえ]を選ぶ。[次へ]。
インストールするハードウェアの種類は[サウンド、ビデオ、およびゲームのコントローラ]を選ぶ。[次へ]。
[製造元]は[Microsoft]、[モデル]は[MPU-401 Compatible]を選ぶ。[次へ]。
[次へ]。[完了]。[ハードウェア ウィザード]のダイアログボックスは閉じる。



ドライバがインストールできました。次は設定の変更です。



[コントロールパネル]から[システム]を開くとダイアログボックス[システムのプロパティ]が開く。
[デバイス マネージャ]タブをクリック。
[サウンド、ビデオ、およびゲームのコントローラ]の下位に[MPU-401 Compatible]があることを確認（MPU-401 Compatibleをインストールする前には存在しなかった）。しかし感嘆符が付いている。
[MPU-401 Compatible]をクリックして選択してから、ダイアログボックス下方の[プロパティ]ボタンをクリック。新しいダイアログボックス[MPU-401 Compatibleのプロパティ]が開く。
[リソース]タブをクリック。
表示されている[I/O ポート アドレス]も[IRQ]もT98NEXT作者の指示とは違う値だった。これをT98NEXT作者の指示に合わせなければならない。
[I/O ポート アドレス]をクリックして選択してから、下方の[設定の変更]ボタンをクリック。[値]のテキストボックス右端のスピンボタンを操作して、T98NEXT作者の指示 E0D0 - E0D2 に合わせる。
[IRQ]をクリックして選択してから、下方の[設定の変更]ボタンをクリック。[値]のテキストボックス右端のスピンボタンを操作して、T98NEXT作者の指示 05 に合わせる。
ダイアログボックスの[OK]ボタンをクリックすると、進行状況を示す表示が出てディスクアクセスが始まったが、途中でフリーズした。ところがエミュレータのウィンドウを×ボタンで閉じてT98NEXTのエミュレートを[初めから]開始したところ、フリーズの直前から作業を開始した。その後もう一度フリーズしたが、また[初めから]開始したらデバイスドライバMPU-401 Compatibleのインストールは終わっていた。



これでMIDIは鳴るようになりました。でもまだPCMが鳴りません。これも続けて再挑戦したのですが、こっちは失敗しました。日を改めてゆっくり考えます。

結果の追求ではなく、今の幸せのために【T98NEXT+Windows95】(1)

私は年をとって、新しいものにほとんど興味が湧かなくなってしまいました。そうなると、人生はかなり無味乾燥なものになります。最近の若者向けの歌を聞いて、私は別に負の感情をもちませんし、いい感じの歌だと思いますが、それにのめり込むことはできません。最近のアニメを見ても、のめり込むことができません。この年で「萌える」のも、これもまた難しいです。それでつい、私は昔のものを追い求めてしまうのです。自分が若かった頃のものを。アニメ「忍者マン一平」のような、ごく一部の人々にしか見向かれないものでも、私個人に昔の思い出のかけらがひとつぶでもあれば、私にとっては今どきのどんなアニメよりも音楽よりも好きになれるのです。

でもこれが、私の不安と心配でもあります。人間は、常に明日へ向かって歩くものだと思います。過去へ向かって歩くのではありません。だから本当は私は新しい歌、新しい小説、新しいドラマ、新しいアニメに興味をもち引かれなければいけないのに、それができない。そんな自分は正しくない生き方をしているのではないか。でも今の私はそれしかできないのです。

先日ちょっと精神的に救われたことがありました。５月５日こどもの日に、FMラジオでみんなのうたスペシャルをやっていました。みんなのうたが始まった頃から新しい時代に至るまで、さまざまな時の歌を取り上げる番組でした。昔のものを求める私はもちろん聞きました。その中で、人々が昔の歌を懐かしんだり、自分の子供にも聞かせたいと考えたりしているのを知りました。それを知って私は、そうなのか、昔のものを懐かしんでもいいんだ。懐古趣味の人間は駄目な人間と決まったわけじゃないんだ、と思い、少し救われました。

そこで私は考えました。それでは仮に、人様に迷惑をかけないなら何をやってもいいとしようじゃないか。昔が好きなら懐古趣味でもいい。とことん眠りたいなら惰眠をむさぼってもいい。もしそうなら、自分は何をしたい？何をしたら、自分は前向きな気持ちになれる？

私はふと、T98NEXTでWindows95を動かす試みを再開したくなりました。この試みの最初の目的は、日常的に使っているPCでWindows95用ソフトを動かしたいというものでした。それができれば、これからも末永くWindows95用ソフトの思い出を保存できる気がしたから。でも今では事情が少し違います。私はもともとT98NEXTのようなソフトウェアをいじるのが好きです。別にエミュレータが好きというのでなく、AviUtlも好きですし、市販のビデオオーサリングソフトも好きですし、画像処理ソフトも好きです。PCをいじるのが好きなんです。それに加えてWindows95の画面というのは、私が若かった頃の懐かしい色、懐かしいデザインで、私にとっては思い出という意味で格別なんです。だからWindows95用ソフトが動かなくても、T98NEXTをいじっているだけで、そしてWindows95の画面の色とデザインを見ているだけで、私は幸せになれるんです。

たしか、以前に実験した時には、T98NEXT上のWindows95よりもWindows10のほうがWindows95用ソフトをうまく動かすことができたと記憶しています。私の実験場では、T98NEXT上のWindows95はまだ解像度640x400、同時発色数16色だから、実用には程遠いのです。だから純粋にWindows95用ソフトを動かすことを目的とするならば、T98NEXTの実験を続けるのは得策でないのです。でも、この実験をすれば、私はT98NEXTをいじることができるし、Windows95のデスクトップ画面の色とデザインを見ることができます。人様に迷惑をかけないのだし、やってもいいじゃないか。

たしか、以前の実験では、Windows95の稼働とCDのアクセスまでは成功しています。未解決なのは、画面解像度、画面発色数、音が鳴らない。この３つでした。この中からひとつ選んで、とにかく始めたいと思います。

【大団円】PC-98万歳、MAHALITO万歳、キャノワードミニ万歳

ついに満足できる結果が出た。私個人は、これ以上のデータ解析は必要ない。私のように理系の学部に進めない頭の持ち主でも、人生の時間を費やして、寝ても起きてもそのことを考えてヒントを捕まえてゆけば、いつかは理系的な望みが叶うのだ。

そもそも今回のフロッピーディスク解析には根底に私の２つの思いがあった。

そのひとつは、言うまでもなく文書フロッピーから昔自分が作った文書を取り出したいという強い思い。

もうひとつは、「私にはディスク解析は難しすぎてわからない」というトラウマだった。

あれは私がPC-98に入れ込んでいた頃だから、高校生の時だと思う。小さい頃から何をやっても成功しなかった私が、ふと手に入れたプログラミングという分野で生まれて初めて「自分が何かやって成功する」という結果を得た。私はPC-98のハードを（当時まだ汎用的なプロトコルが確立していなかった通信と印刷の分野を除いて）完全制覇したと自負した。私がCで書いた自作ライブラリは（通信と印刷は除くがそれ以外の）すべての機能を引き出す関数を含んでいた。ところで、当時PC-98というと、ゲームソフトのプロテクトが一般的だった。ソフトハウスとしては、ユーザーがゲームのディスクを勝手にいくらでもコピーして友人に配るのでは商売あがったりだ。だから通常の手順でディスクをコピーしても使えないような工夫をした。すると、それに対してプロテクト外しというのが出てきた。正直なところ、いたちごっこだった。PC-98完全制覇を自負していた私は、完全制覇のために自分はそのプロテクトというのも理解していなければならないと思った。「これは私の手に余るのでわかりません」とは言いたくなかった。書籍を買った。ところが、難しすぎた。最初に書いたが、私は理系に進めない頭の持ち主だと自分で認めなければならない。ひとつには、その本が「プロテクト外し」の本であり、「ディスクのフォーマット解説」の本ではなかったのがいけなかった。私はその本を何度も読み直し、そして白旗を上げた。PC-98完全制覇を自負する私は、それでも「自分の限界」を認めた。それ以来、趣味プログラマーとしてのトラウマになった。

このところずっと書いてきた一連の記事の中でGAP3というのが出てきたが、あれが私に決心させた。高校生のころに読んだ本で私は初めてその言葉"GAP3"を知った。でも結局白旗を上げたので、私にとって"GAP3"は自分のトラウマの代名詞みたいなものだった。過去のトラウマを解消するには、今度こそディスクのフォーマットをマスターするしかないんだと私は思った。

あれから数十年、私はしがないおじさんになり、もはや新しいプログラミング言語を学ぶ気力すらないけれども、今回、過去のトラウマをひとつ解消できた。

今回うまく行ったのは、まず何よりもPC-98実機を処分せずに持ち続けていたからだ。これがなければ、私は文書フロッピーからデータを読み出すことができなかった。

MAHALITOとの出会いも重要だった。大昔にPC-98完全制覇を自負していた私だから、探せば自作Cライブラリの中に、PC-98のハードを制御してセクタからデータを読み出す関数はあると思う。でも、長年の間に私はたくさんのものを忘却し、Windowsプログラミングばかりやっていたから、自分でMAHALITOを作るのはとても無理だった。

そしてキャノワードミニよ。私が近視になってまで愛用した機械よ。その当時の懐かしい思い出だけでなく、今回キャノワードミニのまだ知らなかった世界を見た。キャノワードミニのプログラム開発者がどんなコンセプトでデータ構造を開発したか。私はその開発者に会ったことはないが、その人の思いの一端を垣間見た気がした。これまで私にとってワープロには、２つの要素しかなかった。１つめは、道具として使い、壊れたり不要になったりすれば処分される実用機器であるワープロ。２つめは、数十年後に「昔持っていたなあ」という哀惜の対象となるワープロ。今回文書フロッピーの解析をしたことで、私は「ワープロを作った人の思いの一端」を見ることができた。古い古い機械を通じて、それを作った人と私との「新しい出会い」があった。私はその出会いに感謝したい。それは今まで思いもよらなかった、ワープロの３つめの要素だ。

私は今までの解析結果と、その解析途中で作ってきた解析用プログラムを総合して、最終的なプログラムを組んだ。そしてこの件をすべて終わりにした。プログラムの主目的は文書フロッピーディスクから文書を読み出し、HTML文書にして保存すること。（もちろんその過程でPC-98とMAHALITOも必要になる。）その他に副次的な目的が２つある。すでに削除された文書も、そのデータが幸運にもフロッピーディスク内に残っていたならば取り出す。これは、パソコンで削除したばかりのファイルが復活可能かもしれないのと事情は似ている。もうひとつは、ユーザーが作成し登録した外字は文書内で使われていなくてもすべて取り出してPNGとして保存すること。昔の私が、愛用していたワープロで楽しみながら何をしたか、それを知りたいから。

プログラムは、MAHALITOが出力したDATファイルと2Dファイルを読み込んで、HTMLファイルを出力する。DAT内に外字が登録されている場合は、それらもPNGとして出力する。出力されたHTMLをブラウザ等を使って開くと、必要に応じて外字のPNGを表示しつつ、文書フロッピーディスク内のすべての文書が表示される。HTMLのいちばん上には「登録文書名一覧」がある。文書名の順番は、文字列の昇順で並ぶ。この文書名は文書本体にリンクしているので、文書名をクリックすると文書本体へ飛ぶ。すべての文書名の下に、「もしもフロッピーディスク内に削除された文書の消え残りがあれば、ここに表示される」がある。これも（もしそのような消え残りの文書があれば）文書先頭にリンクしている。

ゆっくりと1D FD解析再開(21)

その後私は壁に突き当たったままでいた。理屈から考えてFATは必ず存在し、それはトラック0にあるに違いないが、そこにある（00Hでも文字列データでもない）わずかなバイナリデータにトラック番号らしきもの、セクタ番号らしきもの、全トラックのセクタを連番で処理したもののいずれも見つからなかった。私は壁に突き当たりながらも、できることだけした。既存の自作プログラムを改造し、文書本体の書き出しだけでなく各トラック読み取り開始時には<HR>で区切り、"C=??H"と書き出し、さらに48バイトのバイナリデータをダンプした。文書ヘッダならば文書名も書き出した。さらに、トラック0の内容は80Hずつのブロックとして処理し、文書名と48バイトのバイナリデータを書き出した。夜寝るとFATの場所を解析している自分を夢に見るようになった。でも新たにわかるのはFATでなくその周辺のデータだけだった。思えば文書フロッピーがあるのに中身が読み出せなかった頃は、欲しいものがその中に確実にあるのに手に入らないという思いでいた。そしてMAHALITOでフロッピーの中身が読み出せた今も、事情は同じだった。欲しいFATは目の前のたった数十バイトの中に確実にあるのに手に入らない。それから数日が経ち、私は今日もPCのディスプレイとにらめっこをしていた。その時、ふと思い至ることがあった。そしてFATが見つかった。「ほんの数バイトの単純すぎるデータをどう見たらFATに見えてくるか」というパズルだった。

改造した自作プログラムでトラック0を書き出す時、ブロックごとにダンプデータを1行にして末尾で改行したのが良かった。こうすることで、ひとつの文書フロッピー内にある全部のファイルを指すブロック（ディレクトリエントリ）の同一オフセットが縦一列に並び、比較したり推測したりできた。もうひとつは、今までの試行錯誤による知識が功を奏した。この文書フロッピーではデータをトラック単位で書き込んでいるので、FATにセクタ情報はなくてもよく、トラック番号だけで十分とわかっていた。そしてそのトラックは最多でも40個だ。蛇足ながら、数日前にディスクファイルシステムについてネット検索した時、このワープロのファイルシステムがMS-DOSほど複雑でないと察した私は、それ以前の時代によく使われたものとしてCP/Mのディスクファイルシステムについて検索した。CP/Mではディスク全体を一括管理するFAT領域が設けられておらず、各ディレクトリエントリにFATに相当する情報が含まれていたという。ディスクで扱う情報量が少なかったからこそそれでも事足りたのだろう。そしてこのワープロのディスクは扱う情報量がまさに少なく、時代的にも、CP/Mと似たファイル管理をしている可能性が高いと思っていた。

私はディスプレイとにらめっこをしながら、自作プログラムで書き出したHTMLのいちばん上にある"F14DOC"と、その下に続くファイル群のデータを見比べていた。先日同じようににらめっこをしていて気がついたが、各ブロックの同一オフセットにある値の意味を考える時、ディスク全体のヘッダともいえる"F14DOC"ブロックとそれ以外の個々のファイルのブロックとでは値の意味が「似て非なるもの」だった。たとえばオフセット+8には、個々のファイルのブロックでは使用トラック数が入っているが、"F14DOC"ブロックでは常に28Hつまり十進数で40。これは全トラック数だ。私の頭の中にはこれがあったから、"F14DOC"ブロックを見ていればそのオフセットの値が意味する「全体的な何か」が見えてくるかもしれないと、ほとんど無意識に"F14DOC"ブロックを見ていた。00Hという値も結構ある中で、オフセット+16から+20までの値がFFHなど妙に大きい。思えばその時私が見ていた文書フロッピーが、ファイルを一杯に詰め込んだフロッピーだったことも幸いした。そうでなければ+20あたりが00Hになっていたかもしれず、私は気づかなかったかもしれない。何に気づいたか。値が妙に大きい場所が5バイト。1バイトは8ビット。全部で40ビット。そう、最大トラック数も40。これはもしやと思った。次に私はデータを縦に見た。全ファイルの同一オフセットの値をビットごとにORし、その結果を"F14DOC"ブロックと比べた。ほとんどの場所でそれは一致した。例外はオフセット+16。全ファイルの値をORしても最上位ビットは0だが、"F14DOC"ブロックでは最上位ビットは1。このビットがあらわす場所は、そう、どのファイルも割り当てられていないがディレクトリとして使用中の、トラック0だ。このファイルシステムはファイルを書き込む時、ディレクトリエントリ末尾にあるFAT情報にビットデータを書き込むと同時に、"F14DOC"ブロックのビットデータも更新する。次にファイルを書き込む時は、"F14DOC"ブロックだけ見れば、どのトラックが未使用かがわかる。でも待てよ、ディスクに記録済みのファイルを読み出す時、どのトラックを読めばいいかはこれでわかるが、どういう順番で読めばいいかはわかるだろうか。必ずトラック番号の若いほうから順に読むのか。どうやらそうらしい。たとえば既存のファイルを上書きする場合でも、まずそのファイルのFAT情報を消してしまい、それから改めて"F14DOC"ブロックの情報にしたがって空きトラックのうち番号の若いほうから順に使用してゆく。これで問題なく無駄もなく空きトラックを使用できるだろう。

ゆっくりと1D FD解析再開(20)

文書はトラック単位で書き込まれている。
文書ヘッダはトラックのR=1セクタに書き込まれる。これに続けて文書は同じトラックのR=2セクタ以降に順に書き込まれる。
文書が長くてR=5セクタまでで書ききれない場合は、次のトラックへ行くとは限らず、離れたトラックに書き込まれるかもしれない。そのさいもR=1セクタから順に書き込まれる。
だからセクタのチェーン情報は、実際にはトラックのチェーン情報があればよい。

最初のトラックの最初の2セクタにある大きさ80Hのブロックは、先頭に文字列が格納されていることが判明した。まずは文書フロッピーを意味するIDと思われる"F14DOC"。その他のブロックにはJIS文字コードの全角文字が格納されており、"登録句２"、"学習２"、"２４外字"がある。そして文書名が格納され文書ヘッダを指すと思われるブロックがある。これらの文字列は文書本体のように「C0Hで始まる3バイト」ではなく2バイト1文字なので、3バイト1文字の変換プログラムを使っていた私は発見が遅れた。こうなると、この部分が場所といい内容といいディレクトリエントリに見える。ところがこのブロックに、本体のアドレス（たとえばトラックやセクタ）を指すと思われるデータが見つからない。あるはずなのに。

たとえば外字は、ある文書フロッピーではC=3,R=2のセクタにあった。文書がトラック単位で格納されていることを考えると、C=3のトラックが外字用のトラックと思われる。（もしも私がたくさんの外字を登録したならば、他のトラックも使われたかもしれない。）このC=3をあらわす情報が最初の2セクタ内の"２４外字"ブロック内にあるはずだ。ところがこのブロックには、

ブロック先頭に16バイトの文字列領域"２４外字"(以後全角スペース埋め)
その後48バイトに23 47 20 00 00 00 00 00 01 00 00 02 00 00 00 00 10 以後00で埋め
その後16バイトは21Hで埋め
その後48バイトはC0 21 21の繰り返し（これは文書内での全角スペースを表す3バイト）

これでおしまいだ。この中にC=3をあらわす情報があるとすれば、
23 47 20 00 00 00 00 00 01 00 00 02 00 00 00 00 10
の中以外には考えられない。でもどこに。

もうひとつ別のブロックを見よう。外字用セクタ以外でわかりやすいのは文書用セクタだ。とある文書はC=2,R=1に文書ヘッダがあり、C=2,R=2から文書本体が始まる。これに対応するブロックは

ブロック先頭に16バイトの文字列領域（半角かなで文書名）
その後48バイトに23 45 20 00 00 00 00 00 03 00 00 48 00 34 00 00 20 00 00 60 以後00で埋め
その後16バイトは21Hで埋め
その後48バイトは文書本体の先頭のコピー

詳細は省くが、もうひとつ文書のブロックを調べた。

どうだ、
C=3(,R=1)が 23 47 20 00 00 00 00 00 01 00 00 02 00 00 00 00 10
C=2(,R=1)が 23 45 20 00 00 00 00 00 03 00 00 48 00 34 00 00 20 00 00 60
C=13(,R=1)が23 45 20 00 00 00 00 00 04 00 00 8C 00 26 00 00 00 06 80 02

この判じ物が解けるか？無茶だよなあ。

文書ならば、ブロック先頭の16バイトと同じ値が文書ヘッダのセクタ先頭にもあるから、ブロックにシリンダ番号やセクタ番号が格納されているのでなく全シリンダをシークしてR=1セクタ先頭のデータを比較したのだと強引な推測もできなくはないが、外字のほうはそうは行かない。例に挙げた文書フロッピーでは、外字登録の本体はC=3,R=2の先頭から始まる。これは外字のJIS文字コードで始まるので先頭バイトは2Cだ。C=3,R=1が文書と同じようにヘッダのようなセクタだとすると、その先頭データは00 02 2F 2C 60 2C 以後00で埋め。R=2もR=1もブロック先頭の"２４外字"とはまったく違う。だからブロックがディレクトリエントリのようなものならば、先ほどの「セクタ先頭のデータを比較」という強引な推測は成り立たず、やはりブロック内のあの48バイトのどこかにシリンダ番号か何かがあるはずだ。

怪我の功名というか、ひとつわかったことがある。やはり上のC=3,R=1は外字登録のヘッダだ。2バイト目は登録数、それ以後は2バイトずつでJIS文字コード（下位バイト、上位バイトの順）をあらわし、余白は00Hで埋められている。

それはわかったが、さっきの判じ物を何とかしなければ。私は16進数とにらめっこしたが、どう考えてもシリンダ番号をあらわしていない。疲れた私は、また「セクタ先頭のデータを比較」という強引な推測に立ち戻った。文書ヘッダは必ずR=1セクタにある。もしも文書本体ならばC0Hで始まり、外字登録ヘッダならば00H、他に先頭がFFHと09HのR=1セクタが見つかった。文書ヘッダの先頭に必ず16バイトの全角かな文書名があるので、それはC0H,00H,FFH,09Hのいずれとも競合しない。強引に推測すれば文書ヘッダを探して読み出すことは可能ではある。そしてこの文書ヘッダに、もしも長い文書ならば「次にどのトラックへ飛ぶか」のチェーンが記録されているという、強引な推測だ。でもこの推測はちょっと嫌だ。一度フロッピーに書き込んだ文書を削除する時はどうすればいいんだ。文書ヘッダを読んでチェーンをたどり文書を記録した複数のトラック（の少なくともR=1セクタ；文書はトラック単位で書き込まれる）に「未使用セクタ」の印を書き込まないと。私はここ数日調べている文書フロッピーの中身を全部調べたが、そのような「未使用セクタ」の印の付いた文書ヘッダは見つからなかった。私がフロッピー一杯に文書を書き込み、データを削除されたトラックというのがないのか、それとも削除されたという未使用印は文書ヘッダ以外の場所にあるというのか（でも上で調べたけど最初のトラックにはなかったじゃないか）。

ゆっくりと1D FD解析再開(19)

今日はまず1枚の文書フロッピーを選んで、セクタごとに何が記録されているか（または不明か）を逐一メモした。それで午前中が終わってしまった。文書フロッピーの1セクタ目と2セクタ目はどうもディレクトリエントリではないようだ。そうなるとフロッピー内に文書ヘッダや外字登録を見つけるためのディレクトリエントリは存在しないようだ。全セクタを総当たりで読んでデータを探したというのか。

試しにその「総当たり」ができるかどうか下調べをした。外字登録セクタは先頭から外字フォントが詰めて置かれ、そのフォントデータは先頭2バイトに文字コードが格納されているので、セクタの先頭は2CHのはずだ。先頭が2CHのセクタが各文書フロッピーにいくつあるか調べたところ、外字がひとつでも登録されているフロッピーには必ず1セクタあり、外字が登録されていないフロッピーにはひとつもなかった。1セクタ（1024バイト）に登録できるフォントデータ（74バイト）は13個なので、ユーザーがたくさんの外字を登録したならば2つめの外字用セクタができるのかもしれない。ユーザーにより外字がひとつでも登録され保存されるとそのためのセクタが作られ、ユーザーが登録済みの文字コードのデータだけが書き込まれる。順番はおそらく登録順で、コード順ではない。文書フロッピーごとに外字登録セクタは異なるトラックにある。偶然か必然かは知らないがいずれの文書フロッピーでもトラック内のセクタ番号はR=2だ。

今日は午後も頑張って、ついに文書フロッピーからすべての外字をPNGで書き出し、JIS文字コード表で特定の文字が割り当てられていない所に独自の文字が割り当てられている場合も可能な範囲はすべて表示できるようにした。これでほぼ満足だ。用紙サイズや1ページ行数には興味がないので、あと知りたいのは長い文書が複数のセクタに記録されている場合のチェーンのたどり方だけだ。それがわかれば完璧といえる。でも今日はここまでにして寝よう。

ゆっくりと1D FD解析再開(18)

どんなディスクファイルシステムを使っているか。そのものずばりがネット上に出ているとは思わないが、こんな大昔にディスクファイルシステムを使うとしたらよくあった形式くらいは見つけられると考えた。しかしネット検索で情報に行き当たらなかった。

仕方がないので、少なくともディスクファイルシステムの勉強という意味で参考にはなるDOSのFATを学ぶことにした。

FATならば、最初のセクタの36バイトにはFAT12でもFAT16でも同種の情報があるという。最初の3バイトはブートストラップコードへのx86ジャンプ命令、あ、そもそもx86は関係ないだろうな。まあいい、少し学ぼう。次の8バイトに文字列が格納されている。でもこれらは起動ディスクの情報だな。いっぽう文書フロッピーは、最初のセクタの1バイト目から"F14DOC"が格納されている。起動ディスクじゃないからこのへんにブート情報は不要で、文書フロッピーであることが認識できればいいんだろう。DOSのFATではその後の2バイトにバイト単位のセクタサイズが入っているはずなんだが、文書フロッピーではこのあたりが21Hで埋められている。でもセクタの最後まで21Hではなくて途中で値が変わっているから、何らかの情報が入っている。残念ながら何もわからない。

DOSならばこの後どこかのセクタからFATが始まり、その次にFATのバックアップがあり、その次にルートディレクトリエントリがあり、そしてファイルデータ領域があるらしい。でも文書フロッピーではかなり違う。最初のセクタは上記のような状態。次のセクタにも何かデータが入っている。3つめから5つめまでのセクタは、もったいないことに00Hで埋められている。これで最初のトラックおわり。そして2番目のトラックの最初のセクタにはもう文書データが入っているんだ。どこがFATなんだろう。どこがディレクトリエントリなんだろう。DOSと同様ではなくても、複数のセクタのチェーンをたどってゆく仕組みはどこかにあるはずだ。

ここで、最初と2番目のセクタをもう一度見る。今度は自作プログラムでJIS漢字表示できる部分は漢字にする。するとなんと、最初のセクタの途中からすでに、文書名らしきものが見える。2番目のセクタにも同様にいくつかの文書名らしきものが見える。つまり1セクタの中に、ある程度の間隔をあけて複数の文書名がある。そして、2番目のトラック以降のセクタをずっと後まで見てみると、文書データ入りのセクタの他に、文書名（文書先頭文字列）が見えるセクタもある。このセクタは、1セクタの中にひとつだけの文書名を含む。最初の2セクタにある文書名と対応しているらしい。ということは、最初の2セクタのほうがディレクトリエントリ＋FATのようなもので、後のほうのセクタは文書名や文書全体の書式を格納したデータ領域かもしれない。以上のことは別の文書フロッピーでも同様だ。

私は2番目のセクタの内容をバイナリエディタで見てみた。これがディレクトリエントリやFATのようなものならば、文書名らしき部分の後または前に少なくとも最初のセクタを示す情報があるはずだ。

セクタ冒頭から、64バイトは00Hが多いが、64バイトのうち最初の16バイトあまりを中心に何かのデータがある。
その直後の16バイトは21Hで埋められている。
その直後の48バイトが文書名らしき文字に充てられている。
そして、次の文書の情報が続く。

まだ私はひとつの文書フロッピーの2番目のセクタの先頭付近しか見ていない。他の部分はどうだろう。私の仮説が正しければ、この部分のデータは64+16+48=128バイトでひとつのまとまりとなって、それが連続しているはずだ。調べたところ、途中に完全に00Hで埋められている部分もあるが、128バイトずつのブロックが連続してるのは本当のようだ。

でも、文書名の入ったブロックを16進数で眺めても、どこがセクタまたはクラスタを表しているやらさっぱりわからない。

ゆっくりと1D FD解析再開(17)

ゆっくりと1D FD解析再開(17)

複数の心配事があって、昨晩はよく眠れるかどうか自信がなかった。データ解析は以前のような進展がないというか、先へ進むためには本格的にバイナリエディタとにらめっこしなければならず、たとえそれをしても何かが見つかると決まったわけではない。私はそんな可能性の少ないことをする気が起きなくなっていた。眠れない時の用意に、私はスマホに昔のドラマとアニメを入れた。脇腹をしこたまぶつけてからまる４日以上経ち、治るどころか痛くなってきた。仰向けに寝るのと患部を下にして寝るのは良いが、患部を上にして寝ようとすると痛い。この頃眠りが浅いのは心配事だけでなくこれのせいもある。それでもいつのまにか眠って夢を見た。私は夢の中で、家の最寄り駅から何駅か行ったところにある大きな駅の辺りにいた。実際よりもかなりレトロな雰囲気だ。私は床屋を探していた。夢の中では行きつけの床屋という設定だったのに、見つからなかった。やっと見つけた床屋は、私よりも後から来た人を先に散髪しようとする。慌てて自己主張して椅子に座るが、散髪を始める気配がない。ふと気づくと私は床屋を出て家へ帰ろうと歩いている。散髪はしていない。駄目じゃないか。私は床屋へ引き返す。ところが床屋の雰囲気がさっきと変わった。これは床屋でなく軽食店のカウンター席だ。店の人に聞いてみた。店の人は、ああ、以前にはここに理容室があったようですねと答えた。私もそんな気がしてきた。私が帰ろうとすると、店の人がワインをどうぞという。ワインなんて高いものをいただくのは悪いので、私はちょっとでいいですよと言う。店の人は何かの皿に入った白ワインの残りを、テーブルの上にあった変な容器に移した。残り物だし一口分もないし変な容器だし、これならタダでくれると言うのも納得だ。私はその少量の白ワインを口に流し込んで、そうだ何か言わなくちゃと気づき、変な容器を高く掲げて「このお店に乾杯」と言った。店のテーブル席にいたお客たちが私に拍手する中を、私は店の出口へと向かった。結局散髪はできなかった。私は目が覚めた。その時ふと思った。確かに私は外字フォントがフロッピーディスク内にないことを確認した。でもその時は、どれが外字でどれがROM内の文字かがわかっていなかったではないか。昨日の調査で、外字らしきものが絞り込めた。もう一度調査してみるべきだ。

私はプログラムを組んだ。プログラムにアドレスを渡しておくと、プログラムはMAHALITO.DATを開き、そのアドレスまでシークし、そこから24x24ドットのフォント情報を読み出し、それをPNGで出力する。私はまず、第二水準漢字フロッピーから1文字読み出してプログラムの動作を確認し、それから文書フロッピーのうち、2C21Hに不明の文字があるものから読み出した。果たして、外字登録は存在した。2C21Hの外字登録がどのトラックのどのセクタにあるかは、文書フロッピーにより異なる。今のままではMAHALITO.DATを調べて2CH,21Hが連続する所を見つけ、複数あれば順に調べなければならないので外字読み出しの自動化ができない。文書フロッピー内の「外字ファイル」を読むためにどのセクタからどんな順番でセクタを読んでいったらいいのかを知る必要がある。

ゆっくりと1D FD解析再開(16)

コードの調査と考察


その１・行頭書式データ

00 私の文書では、これが先頭にある行には'・'だけが連続して打ってあり、その1行下の文字を見ると強調したい文字に対応しているようだ。つまり'・'は、1行下の文字上部に傍点として付くらしい。だからこの00は「行間00」の意味ではない。もしも行間0（重ね打ち）ならば、'・'は1行下の文字の真ん中に重なってしまう。では一体どんな行間なのだろう。

05,03,0B 私の文書では、この3つの書式データは3行に連続して出てくる。まず05の行があり、それは普通の文章。次に03の行があり、ここには文中の特定の場所に付ける注番号だけが書いてある。そして次行は0B。これは普通の文章で、先ほどの注番号に対応する部分を含む。05の行と0Bの行の間が通常の行間のサイズで、その間に注番号の行03を挟み込むために行間を工夫しているに違いない。しかしそれ以上はわからない。なお、0Bは他にも、文書の最初に0Eの行があり、その後は普通の行(0A)で、最後に0Bの行という場合もあった。0Bは特定の行間でなく「行間リセット」の意味をもつ可能性もある。

4A,1A これはセットで出てくる。まず4Aの行があり、この行には文章はなく227BHで埋められる。そして次の行が1Aで、これは文章を書ける行。行間を空けるための書式データと思われるが、詳しくはわからない。


その２・半角文字コード

いわゆる半角カナのほかに、60H以降にはその半角カナの不都合を補うための濁点半濁点つき半角カナと、JIS文字コード表になくて一部のユーザーが困る欧文特殊文字が独自に割り当てられている。


その３・全角文字コード

2233 上位バイト22Hの場所には文字として表示する他にも書式制御コードが割り当てられており、その可能性もある。事例が少なく、文脈を見てもこれが何を意味するコードだったのかはさっぱり推測できない。

2268 文字コード表では'∵'に相当するが、上位バイト22Hの場所には書式制御コードも割り当てられており、私の文書ではまるでブックマークでも付けるかのように使っている。

2278 文字コード表では'‡'だが、実際の文書を見るとそれはありえない。私は注番号の直前と直後に付けており、こんな使い方を私はひとつしか思いつかない。つまり、字間をかなり開けて書式設定した論文で注番号だけは文字間を詰めなければ体裁がおかしいという可能性だ。「このコードで前後を括った文字列は書式設定にかかわらず字間を詰める」という指示ではないだろうか。

227B これは単独では現れず、上記4A,1Aと共に現れる。「文字を書く行ではない」という意味のデータだろう。

2321から先 （ここから先3文字は環境依存文字、文字化けの可能性あり）ⅠⅡⅢ...があった。ネット上のJIS文字コード表を見ると2D35Hから先に（文字化けの可能性あり）ⅠⅡⅢ...があるが、おそらくここには割り当てられていなかったのだろう。

2742から先 カッコ書きの数字か、丸の中に数字か、あるいはひょっとしてi ii, iiiかはわからないが、とにかく上記（文字化けの可能性あり）ⅠⅡⅢ...の下位分類に使える1からの数字があった。

2776 ♪があったと思われる。私の文書にはこれしかないが、この付近にはJIS文字コード表で特定の文字が割り当てられていないコードがいくつもあるので、きっと様々な記号文字が独自に割り当てられていたのだろう。

28?? この部分にはJIS文字コード表では罫線があるが、それはなかった。そのかわりに、ここに全角欧文特殊文字が独自に割り当てられていた。日本人の多くはそんな文字を使わないが、しかし一部の日本人には必要だった。今の英語一辺倒みたいな風潮になる前は、フランス語やドイツ語、そしてイタリア語スペイン語も今より高いステータスで必要とされていた。

2921 2つ並べるとつながるダッシュ

296E 文脈から推測するに、二点リーダーか三点リーダーか。でもそれは2144H,2145Hにあるのだが、どういうことか。

2C?? 以前の調査でフロッピーに外字は記録されていないということになったのだが、私はどうにも一抹の疑問を払拭できない。ここに登録されている文字は、私が登録した外字だったのではないか、と。

4F78 ずいぶんコードが飛んだが、ここにはハートマークが割り当てられていたらしい。今でこそパソコンでもスマホでも当たり前に使えるハートマークだけど、JIS文字コードにはハートマークがないんじゃないかな。昔のワープロは、こういう人々がよく使う文字の不足にも、欧文特殊文字を書く数少ないユーザーのためにも、独自形式だけど対応しようと努力してくれたんだ。

ゆっくりと1D FD解析再開(15)

いまだ解析できない書式データを、私はまず手持ちの全部の文書フロッピーから書き出し、そして推測しようとした。でもこれに数日かかるとわかった。あらかじめ私が自作プログラムに「未解析データ」として赤い字で16進数も書き出させている部分があり、それは見やすいのでどんどんチェックできる。ところが、未解析データは実はそれだけではなかった。JIS漢字コードで罫線が割り当てられている所に、別の文字が割り当てられている。だから全角の欧文のところどころに罫線が出てくる。プログラムの書き直しをサボったばかりに、私はディスプレイに映った欧文をいちいち読み、罫線を見つけてはチェックする羽目になった。それで数日かかる。それで・・・途中で投げ出した。気晴らしに、他のことをちょっと始めた。

論文が入ったフロッピーの中身を見ると、何度も論文を書き直し保存したものだから、連続したセクタに最後まで続けて記録されてはいなかった。途中で切れていたり、途中から始まっていたり。こうなると、どういう順番でセクタを見ていったら良いかが気になる。もっとも、テキスト情報が取り出せた今では、文脈・前後関係から推測してつなげることもできるが。もしもフロッピー内に、特定の文書のセクタをどういう順番で読めばよいのかを記録した情報が見つかれば、スッキリするだろうなあ。

文書フロッピーの先頭トラックの先頭セクタが"F14DOC"で始まるのはわかった。これを最初に読んで、文書フロッピーかどうかを判断するわけだ。でもそれ以外は、難しい。文書の本体を記録したセクタだけは今まで書いたようにかなり解析できたが、ではその他のセクタの中身は何なんだ。当たり前に思いつくのは、文書に付けた名前、用紙サイズ、1行文字数、1ページ行数、その他ひとつの文書全体の書式を記録したセクタだ。でも他に気になるセクタがあった。文書名や全体の書式を記録したとも思えず、文書の本体でもない。これがもしもパソコンのフロッピーならば、いろんなアプリケーションソフトのいろんなデータが記録されるから、「なんだかわからん」で終わりになる。でもこれはワープロ専用機のフロッピーだから、記録されているのは必ずワープロ専用機が使う何かのデータなんだ。気になる。

ゆっくりと1D FD解析再開(14)

外字登録の機能があったのだろうか。それともなかったのだろうか。自作プログラムで文書をHTMLに書き出すと、JIS漢字コードで特定の文字を割り当てていないコードの使用を発見する。これはROMに元からあった文字なのか、それともユーザーが作成した外字なのか。それをはっきりさせたい。もしもROMに元からあった文字ならば、もはや機器も添付冊子も失われた今では調べようがない。いっぽう、もしもユーザーが作成した外字ならば、フロッピー内にそのフォント情報が残っているはずだ。

私の持っているフロッピーには外字と書かれたものがないので、もしも外字登録機能があったならば、外字は専用フロッピーにではなく、各文書フロッピー内に登録されたはずだ。

だから各文書フロッピー内にそれらしいセクタがあるかどうか調べてみよう。（文書は必ずセクタ先頭から記録されているから、もしも外字があればそれもセクタ先頭から登録されているだろう。）

でも、文書フロッピー内を闇雲に探してもどれが外字かそうでないのかわかるまい。そこでまず、JIS第二水準漢字フロッピーの中身を調べよう。このフロッピーにはおそらく第二水準漢字のフォントがドットデータとして記録されているはず。（当時はまだベクタフォントなんて使っていなかった。）もし外字登録があればそれも同様のドットデータだろうから、第二水準漢字のデータフォーマットがわかれば、同様のものを文書フロッピー内で探せばよい。

私は第二水準漢字フロッピー2枚のうち1枚目を自作プログラムでセクタごとに16進数として書き出した。すると面白いことがわかった。最初のトラックはたいしたデータが入っておらず、2番目のトラックから何かのデータで埋められているが、そのR=5から先、4番目のトラックのR=2までの8セクタ。冒頭のデータがみんな50Hだ。それに続く7セクタは冒頭が51H、続く7セクタは52H、その後も同様に。私はネットでJIS第二水準漢字のコードを調べた。第二水準漢字の上位バイトは50H以降。ビンゴだ。

さらに詳しく見よう。2番目のトラックのR=5は50H,21Hで始まる。推測ではここから5021Hの'弌'が始まる。その後最初に50H,22Hが現れるまでが（50H,21Hを含めて）74バイト。さあ、これがどんなフォーマットになっているのだろう。通常の大きさのフォントと、その他に上付き・下付き文字用の小さいフォントが格納されている可能性もある。

私はしばらく5021H'弌'で頑張っていたが、このたいして複雑でない文字でも「文字フォントのフォーマットを当てる」というパズルは私には難しすぎた。きっと1ビットが1ドットのはずと思い、2進数に直してパズルをするものの、どうしても'弌'にならなかった。そこで私は、いちばん単純な文字でやることにした。5026H'丶'。これならば、ただの「チョン」だ。果たして、フロッピーの50H,26Hから続く72バイトは大部分が00Hで、真ん中あたりだけそれ以外の値になっている。間違いなくこれは「四角い空白の真ん中にあるチョン」だ。でもこれもパズルは難しかった。ネット上のJISコード表を見ると、この文字はただの斜めの短い棒だ。ところがフロッピーのデータをビットに直したものは、どうも棒の斜めの向きが逆なだけでなく、棒の太さも場所により異なる。私はネットのJISコード表を見ながら、現在のブラウザの表示はフォントが"MS ゴシック"ではないだろうかと考えた。フロッピーのラベルに「明朝体」と印字してあったのを思い出した。そこでメモ帳にこの文字をコピー＆ペーストし、メニューから文字フォントを"MS 明朝"に変更した。すると、さっきまでの「チョン」はただの斜めの棒ではなく、筆で書いたように下の方ほど太くなった。これだ。棒の斜めの向きが逆というのは、ビットの並びを下位ビットから上位ビットへと並べるのかもしれない。それにしても、「チョン」が真ん中に来ない。最初に5021H'弌'に相当するデータを見た時3バイトごとに同じ値があったものだから、最初は3バイトずつ並べて調べていたが、試行錯誤の過程でそれはやめていた。でも、5026H'丶'でもほとんどの00H以外のバイトが3バイトごとに現れる。普通は半角で横8ドット、全角で倍の16ドットだろう。3バイトってのは、最初の1バイトはフォント情報でなく何かのフラグなのか？いや、「チョン」が真ん中に来るためにはどうしても左右に1バイトずつ00Hが必要だ。とするとこれは、縦横24ドットのフォントデータか。横3バイト縦24バイト、合計72バイト。できた！パズルを解くカギは、下位ビットから並べることと、横のバイト数だった。

第二水準漢字フロッピーのフォント情報は、セクタ先頭から最多で13個続き、末尾に未使用領域があれば00Hで埋められている。各フォント情報は74バイトで、最初の2バイトがJIS漢字コード、残りの72バイトが横3バイト縦24バイトのビットマップフォント情報。マップの左上から右下へとバイト情報を1ビット＝1ドットで割り当てれば良いが、そのさい下位ビットのほうが左、上位ビットが右に来る。



これでフォント情報のフォーマットはわかった。同じフォーマットで文書フロッピー内にデータがあるだろうか。

自作プログラムで出力した文書は、2バイト文字がJIS漢字コードで特定の文字を割り当てていないコードでもそのまま書き出しているので、その結果「中点」のような表示になっている。この部分のデータを調べ、「中点」ではなく「JIS漢字コードで特定の文字を割り当てていないコード」だということを確認し、そのコードを使って上記フォント情報を文書フロッピー内で探した。

2744H。この値が連続している場所は当該文書フロッピー内に4箇所あった。バイナリエディタで27H,44Hの後を見てみると、4箇所のうち3箇所はC0Hや00Hで始まる3バイト、つまり文書内の文字データだった。残る1箇所は00Hの多いデータ列で、これは文字フォント情報かもしれないと思った。ところが上記の方法でビットをドットに変換して並べても、それらしい外字の形が現れなかった。念のため文書フロッピー内でもうひとつ、2742Hも調べたが、こちらも27H,42Hの後はすべて文書内の文字データだった。私は、外字作成機能はなかった、文字データがJIS漢字コードで特定の文字を割り当てていないコードの場合はROMに元からあった文字だった、と結論付けた。

ゆっくりと1D FD解析再開(13)

自作プログラムをHTML出力に変更したので、現在までに実現した機能と不明な部分を整理して書き出した。

文書書式のうち、1行文字数は再現している。文字間隔、行間隔、1ページ行数は不明。

全角文字、半角英数字、半角カナ、アンダーライン、上付き文字、下付き文字は再現している。

JIS文字コード表のうち文字が割り当てられていない場所に、独自の文字が割り当てられている可能性がある。それは不明。

一部の書式表現はHTML文書で表現できないので、そのかわりに青い文字で表示してある。「改」は液晶表示で改行マークがあった場所。「改頁」はユーザーが指定した改ページ位置。「◆」はインデント。「大」はおそらく液晶表示で文字が横に2倍に表示された場所で、「大」の次にある文字が「大」の場所まで横長になると思われる。

一部の書式データは解析ができておらず、それは赤い文字で表示してある。HTML文書の各行左端1文字分は文書エリアではなく、通常は空白が表示されるが、赤い英数字が表示されることがある。これは、通常とは異なる行頭データがあった場所で、おそらくは行間指定が通常と異なるのだろうが、詳細がわかならい。半角文字がJIS文字コード表で文字の割り当てられていない場所だった場合は、赤い字で'?'を表示する。ここには独自の文字（濁点半濁点付き半角カタカナ）を割り当てていたと思われる。全角文字は、(1)JISコードの範囲を完全に逸脱しているエラーならば赤い字で"??"（私の所持するフロッピーには存在せず）、(2)未解析の書式データかもしれない領域の文字コード（22??Hのうち※〒→←↑↓以外）は赤い字で当該文字を表示（その文字を表示していたのかもしれないが、全角文字コードの一部を書式データとして使っており、それかもしれない）、(3)JIS文字コード表で文字の割り当てられていない場所だった場合は赤い字で当該文字を表示（独自の文字を割り当てていたと思われるが、その文字が不明なので無関係の1文字が表示される）。

ゆっくりと1D FD解析再開(12)

前回の記事の続き。

次の日、私はまたせっせとデータ解析をしていた。論文の一件はどうなったのかって？あれを私は、やっぱり見たくないようだ。別に論文に悪いことは書いてないのだが、どこかに小さな心的外傷でもあるんじゃないか。そこで私は、そのフロッピーを見ないことした！元からあったフロッピーデータだけを見て、それだけを解析しようとしたら、また私の元気は戻った！

以下の記事は私用のメモが元になっているので時々あなたにとって意味不明の固有名詞も出てくるが、それでもデータ解析関係は意味がわかると思う。

文字列「愛のABCD」が見つかった。ABCDはだんだん大きくなるので分析は簡単だった。
08H,20H,41Hで半角スペース+下付き文字のA
80H,42H,43Hで下付き文字のB+半角文字のC
以前の記事に、半角文字データとして1バイト目が00Hと書いたが、正確には上位4ビットと下位4ビットに別々の意味があり、0ならばASCII文字、8ならば下付きASCII文字、そして以前の記事に出てきたがAならば半角カナだった。

「作品一覧」は、プリントアウトした大昔の感熱紙が残っている。それと見比べると、1バイト目が40だと上付きASCII文字+ASCII文字、44だと上付きASCII文字+上付きASCII文字。ずっと下のほうには1バイト目が04もひとつある。

22H,36H,59H("カル"),22H,36H,5DH("カン")発見。これは"SHIITAKE"等と共に記されているので、半角カナだが上付きや下付きではない。つまり1バイト目が20H,22H,02Hの場合に（装飾なしの）半角カナだ。22H,38H,67H("ク？"),"湯"というのも見つかった。これは"クズ湯"だから、JISコードの半角カナで本来使われていない67Hに半角の'ズ'があてがわれていたことがわかる。ここで、先に発見していたAAH,4FH,6EHの3バイト目がJISコードではこの場所に文字が割り当てられていないが'ド'のはずだというのを思い出せば、独自に割り当てた文字のエリアがわかってくる。

「用語解説」に11H,50H,2EH("P."),11H,53H,2EH("S.")を発見。文脈から"P.S."と思われ、上付きや下付きではない。しかし普通のASCII文字は1バイト目が00Hだ。この11Hはおそらく強調（アンダーライン）だろう。

今までに発見された半角文字関係の1バイト目（上位4ビットまたは下位4ビット）をまとめると、
0 (0000b) ASCII文字
1 (0001b) アンダーラインASCII文字
2 (0010b) 半角カナ
4 (0100b) 上付きASCII文字
8 (1000b) 下付きASCII文字
A (1010b) 下付き半角カナ
ここから類推するにビットフラグは左から順に、
下付き文字か(1)そうでないか(0)
上付き文字か(1)そうでないか(0)
半角カナか(1)ASCIIか(0)
アンダーラインか(1)そうでないか(0)
と思われる。これでビットは使用し尽くしてしまうので、他の可能性はないだろう。
ただし、2バイト（全角）文字を忘れてはならない。1バイト目がC0Hだと2バイト文字のJISコードが続くので、まず2バイト文字かどうかの判定をしなければいけない。

その2バイト文字にも修飾フラグがある。「作品一覧」にC1H,23H,30Hがある。前述のとおりこれはプリントアウトした感熱紙が残っており、それによるとこの字は全角の０にアンダーラインが付いたものだ。1バイト目がC1Hだとアンダーライン付き2バイト文字だ。このビットフラグは、うまい具合に半角文字の場合のビットフラグと同じ位置だ。

その他に、"作品一覧"の前後にはC0H,2AH,71Hがあり、感熱紙を見るとこれは網掛けになっている。



いままで自作プログラムからの出力はプレーンテキストだったが、上付き文字や下付き文字が出てくるとそうも行かない。自作プログラムをHTML出力に変更しよう。

なお、今までは解析しているフロッピーのワープロ機種名も当たり前に書いていたが、念のためにこれからは書かないようにしようと思う。大昔と違って現代は色々なことに規制がある。表現の規制、権利の擁護、いずれもいいかげんな気持ちでいると足元をすくわれかねない。この特集で扱っているのは売られなくなって相当な年数が経つ機器なので、クレームは来ないと思うが、それでも万一こんな事でクレームをもらったらそれは人生が辛い。なぜなら私は人生の辛さの中で生きがいを求めてこれをやっているのだから。これは、楽しくなければいけない。辛さから脱却するためのもので辛くなるのは御免だ。そういう事情で今後のこの特集記事では意図的に機種名等に触れずに書くので、ずっと先の記事になったら読む人が「はて、これは何の解析をしている記事なんだ？」と思うかもしれない。

ゆっくりと1D FD解析再開(11)

文字情報をあらわす3バイトの1バイト目が想定外の値だった場合を全部書き出すようにプログラムを変えた。そうしたら、数は多くないが、とんでもない値の1バイト目があった。数が少ないくせにその種類は多く、ひとつずつ解析または類推するしかない。

1バイト目がAAHならば2バイト目も3バイト目も半角カナのJISコード、
1バイト目がA0Hならば1バイト目が半角カナで3バイト目はASCII（時として7FHというありえない値も入る）、
1バイト目が0AHの実例は手元にないが、上記2つがあるならばこれもないとは思えない。

これらが下付き文字かどうかは、上付き文字のデータと見比べれば類推できるだろう。そして上付き文字は論文で使った。私は論文のフロッピーをMAHALITOで読み出したデータを探した。ガーン！なんと、はるか昔の論文はもう見たくないというわけで、論文はMAHALITOで読み出していなかった！フロッピーは天袋に上がっている。

私はどうにもたまらなくなり、天袋からフロッピーを下ろしてPC-9821とMAHALITOでデータを読み出した。論文のフロッピーは3枚もある。後で後悔しないように第二水準漢字フロッピーもデータを読み出しておいた。1Dだからこれも2枚に分かれている。計5枚を、1枚読むたびにPCが機嫌を損ねて再起動しながら読んだ。

ところがこの論文を見ているうちに、なんだかやりたくなくなってきた。昨日の晩、フロッピー解析をどうしても止められなくて夜中の1時までやってしまったのが嘘のようだ。私はそんなに論文が見たくないのだろうか。困った。とにかく今日はここまでにしよう。

ゆっくりと1D FD解析再開(10)

今までにわかっている事をまとめた。自分のプログラムのコメント、というか解説用にまとめたものだが、実はこれで終わりにはならなかった。それを記述するにはあと2つ記事が要る。

たぶんお察しのことと思うが、近頃の記事は、まず私がデータ解析を進め、それを後から記事が追いかける形になっている。それが理由でブログ記事は予約投稿になっていて、私は記事が実際に投稿されるより前に修正することができる。それで、「あと2つ記事が要る」という予言者みたいな発言ができる。どうせ予言者なら今のうちに予告しておく。キャノワードミニ9の文書フロッピーは、最終的に上付き、下付き、アンダーライン、網掛けを含めて、まあまあ満足できる所までHTML文書化できる。網掛けはHTMLのCSSでは難しいので文字背景色として表現したが。

では、今回の記事だ。



キャノワードミニ9はセクタの冒頭から文書を書き込み始める。余分なデータは冒頭にない。
（直前のセクタに、文書名（とおそらくは書式設定）らしきデータが見られる。）
文書はキャノワードミニ9の文書書式での1行単位で書き込まれ、セクタの残りバイトが1行格納に足りなくなると残りバイトはFFHで埋められ、文書の続きは次のセクタに書き込まれる。
1行のデータは連続する3バイトずつ意味をもち、1バイト目がフラグ、2バイト目と3バイト目にJIS文字コードが格納される。
フラグは、00Hならば後続の2バイトは2つの半角文字、C0Hならば後続の2バイトは1つの全角文字をあらわす。特定の全角文字は表示用でなく書式データの役割を担う。00Hで始まる半角文字の3バイト目は時として7FHというありえない値になっていることがある。
例外的にフラグC0Hの後には00H,0AH(つまりLF)もありうる。
書式データLF(C0H,00H,0AH)は1行の先頭をあらわす。
書式データ" *￢"(C0H,00H,2AH,C0H,22H,4CH)は改ページをあらわす。1行の先頭にあり、その後は行末まで'≒'で埋められる。C0H,00H,2AHは書式データLF(C0H,00H,0AH)と同じく1行の先頭もあらわすと思われる。私のプログラムが書き出すのはプレーンテキストなので改ページはできず、[改頁]と表示した。
書式データC0H,00H,4AHとC0H,00H,1AHも確認されている。書式の意味は判明していないが、1行の先頭にあることは書式データLFと同じ。この他にも未発見の書式データもあるだろうから、C0H,00H,??Hの書式データがあれば1行の先頭と判断してよさそうだ。
前述のとおりセクタの冒頭から文書が始まるので、C0H,00H,??Hで始まるセクタの中身は文書の可能性が高い。（1行の末尾にはとくにデータはない。）
書式データ'⇒'(C0H,22H,4DH)は改行をあらわす。ただしキャノワードミニ9の文書データは改行の次にすぐ次行の文字が来るのでなく、文書書式の1行文字数に従って右端まで'≒'(C0H,22H,62H)で埋められる。だから'⇒'をWindwosテキストのCR-LFに置き換えるわけにゆかない。
'≒'は「文字のない領域」をあらわすが、読み飛ばすわけにもゆかない。なぜなら1行の中で'≒'よりも先に文字と改行が見つかった事例があるから。全角スペースで埋めるのが妥当。
書式データ'⊥'(C0H,22H,5DH)はインデント。したがって1行の左端または右端にあるはずだ。
書式データ'≫'(C0H,22H,64H)は禁則処理のフラグ。句読点を行頭に持ってこないように置かれる。
書式データC0H,22H,7CHは拡大文字のフラグと思われる。この3バイトに続いて2バイト文字をあらわす3バイトを格納することで、文字を横2倍に引き伸ばす。私のプログラムが書き出すのはプレーンテキストなので文字を拡大できず、文字を左右から[ ]で括って拡大をあらわした。
他にも書式データ（これまでの事情から考えておそらくC0H,22H,??H）があるに違いないが、C0H,22H,2AHは普通に右矢印として使っているのを確認した。C0H,22H,??Hならば書式データというわけではない。

ゆっくりと1D FD解析再開(8)

自作のプログラムにCONVERT2Dという名を付けて、これでフロッピーのデータをシフトJIS漢字コードに変換してみた。これをもとに、キャノワードミニ9のデータを調べようとした。今回も自分用のメモをほとんどそのまま転記するのをご容赦いただきたい。なにしろ調べれば調べるほど新しい事柄が出てきて、今も先へ進んでいる最中なので、「まとめて書く」ということができない。



2バイト文字をあらわす3つのバイトのうち、2番目と3番目のバイトがJIS漢字コードだということはわかっている。では1番目のバイトには何が入っているか。調べたところ、いずれの文字でも1バイト目はC0Hだった。もしも文字に何らかの書式指定をしたならばこの値は変わるのかもしれないが、通常の2バイト文字ではC0Hらしい。

文書データのあるセクタはその冒頭数バイトつまり1文字目があるべき場所がCONVERT2D出力では半角スペースになっている。これはつまり、JIS漢字コードの範囲外の数値が入っていることを意味する。調べたところ、C0H,00H,0AHだった。これはつまり、1バイト目は2バイト文字をあらわす3バイトと同じ値、2バイト目と3バイト目がLFの文字コードだ。C0Hは後ろに文字が来ることを示すのではなく、制御データの前にも付くらしい。

文書データのあるセクタは一定間隔おきにCONVERT2D出力では半角スペースによる区切りが見られる。文書が一定間隔おきに区切られるので、おそらく書式指定に従った右端の折り返しを意味するのだろう。調べたところ、これもC0H,00H,0AHつまりLFだった。

これらのLFが行頭を表すのか行末を表すのかだが、1セクタに格納された数行分のデータの後にはLFがなくFFHで埋められている。だからLFは行頭を表す。

改行を表すらしいデータ'⇒'も見つかった。C0H,22H,4DHだ。驚くべきことに、224DHはJIS漢字コードに含まれる。しかも1番目のバイトはこれもC0Hだから、本来漢字として表示されるべきだ。しかしキャノワードミニ9ではこれが改行データらしい。おそらくこのデータを見つけると、キャノワードミニ9は液晶画面のその場所に改行マークを表示したのだろう。

普通のプレーンテキスト文書では、改行コード（たとえばDOSやWindowsではCR-LF）の次にはすぐに次行の文字データがある。しかしキャノワードミニ9では、文書書式での1行文字数に達するまで専用のデータ'≒'で埋められているようだ。それがC0H,22H,62Hで、驚くべきことに2262HもJIS漢字コードに含まれるので本来漢字として表示されるべきものだ。しかしキャノワードミニ9はこのデータを見つけると液晶画面のその場所に「文字なし」を意味する空白なり点なりを表示したのだろう。

それではC0H,22H,62H('≒')が現れたらその行のそれより右側にはもう文字がないのかというと、そうとも言い切れない。アドレス23552から始まるセクタの後ろのほうを見てみると、1行のほとんどが'≒'で埋められているが、ちょうど真ん中あたりにひとつ'＊'があり、その次に'⇒'つまり改行がある。'＊'は私が打ち込んだ文字だろう。1行の真ん中にあるというのはセンタリングを指定したのだろうか。しかしセンタリングを意味する制御コードが見当たらない。この行の先頭には他の行とまったく同じLFがあるだけで、この行の末尾はとくに何もないまま'≒'で終わり、セクタの最後までの空きバイトはFFHで埋められている。

そういえば、1セクタの最後に空きバイトがあるが、これは必ずFFHで埋められているのだろうか。全部は調べていられないが、たとえばアドレス12288からひとつのセクタが始まるので、その直前はひとつ前のセクタの末尾だ。調べてみると、最後の文字'つ'の後はFFHで埋められている。アドレス97280からひとつのセクタが始まるので、その直前はひとつ前のセクタの末尾だ。調べてみると、最後の文字'≒'の後はFFHで埋められている。あとひとつだけ調べよう。84992の直前を調べてみると、最後の文字' 'の後はFFHで埋められている。

前述のとおりに1行の右端と思われる所でLFが現れるが、その直前に'≫'が現れることがある。そしてLFがあり、その次に文書の残りの文字が続く。'≫'は文書として意味がなく、これを読み飛ばすと前後がつながる。さらに、'≫'とLFの後を見ると間近に句読点がある。これは間違いなく禁則処理のフラグだ。C0H,22H,64H。このフラグは2つ連続して現れることもある。

アドレス20480からのセクタに半角英字を発見した。半角文字は2つまとめて3バイトで記録されている。1つめのバイトは00H、残りの2つのバイトはそれぞれの半角文字のASCII文字コード。2バイト文字をあらわす3バイトでは1つめのバイトがC0Hだった。この違いで半角か全角かを区別している。上記のように全角文字の一部を書式指定データに割り当ててもいる（'⇒', '≒' '≫'）。

アドレス83968からのセクタには「愛と夢の飛行船」というタイトルが格納されている。私の記憶では、ここは目立たせるために横に2文字分の拡大文字にしたように思う。そして案の定、各文字をあらわす3バイトはそれぞれの間が3バイトずつ空いている。まずC0H,22H,7CHの3バイトがあり、これが拡大文字をあらわす書式データと思われる。それから2バイト文字をあらわす3バイトがある。

アドレス106496からのセクタなど数か所に、C0H,00H,2AH,C0H,22H,4CHが見られる。文字で表現すれば" *￢"となるが、これは書式データだ。必ず文章末に現れ、1行の先頭にあり、その後は行末まで'≒'で埋められる。改ページだろう。注意すべきは、この書式データは1行の先頭にあるのに、ひとつ前の行との間にLFがない。位置的にはC0H,00H,2AH(" *")がLFに相当する。そういえばC0H,00H,2AHもLFも3バイトのうち2バイト目が00Hという共通点がある。C0H,00H,??Hは改行しておいたら良いのかもしれない。

C0H,00H,4AHと、C0H,00H,1AHも見つけた。書式データの意味は不明だが、やはり1行の冒頭にある。

C0H,22H,??Hの中には他にも書式データがあるに違いない。たとえば上付き文字、下付き文字は表示できたはずだ。しかしC0H,22H,2AHは普通に右矢印として使っているのを確認した。どれが書式データかわからない以上は、ひとまず2バイト文字として表示するしかない。

この他に、数は少ないが不明なデータが見つかっている。1バイト目からしてAAHやA0Hというまったく意味不明なデータだが、文書内の文字ではなく、これも3バイトで1文字分に充てられてはいる。

キャノワードミニ9は文書フロッピーのセクタをあまり複雑に使っていないのかもしれない。もしもこれがMS-DOSならば、複数セクタにまたがる文書ではセクタが連続しているとは限らず、チェインをたどって行かなければならないだろう。しかし偶然なのか必然なのか、今解析しているフロッピーは複数文書にまたがるセクタが連続している。ディスク上でセクタの並びが順番でない場合は、R=1,2,3,4,5の順に直してやると文書がつながった。

他にも、文書はどうやら1行単位で記録され、1行分に満たないセクタの余白はFFHで埋められて次のセクタへ行くので、文書が格納されたセクタは冒頭が必ず（行頭に必ずある）C0H,00H,??Hで始まる。その結果、「2バイト文字をあらわす3バイト」は必ず3で割り切れるアドレスから始まる。「2バイト文字をあらわす3バイト」が別のオフセットで現れるセクタもあるが、これはどうやら文書の本体ではない。

ゆっくりと1D FD解析再開(7)

データ読み出しプログラムを少し改良した。1セクタの内容を変換開始位置をずらして3回書き出すのは、悪くない方法だがゴミデータが多く表示されすぎる。不要なゴミデータの表示を少しでも少なくしたい。今私は文書内のとくに2バイト文字を読み出そうとしている。私は半角のアルファベットを打った記憶もあるが、今読み出したい詩の中で打った記憶はない。そこで、上記セクタの内容を書き出す1行にひとつも2バイト文字が含まれなければ書き出さないことにした。これにより1セクタの内容が3行ではなくたった1行で書き出せる場合もある。データのアドレス表示（テキスト以外の余分な情報）もやめた。

データをシフトJISに変換した時点で気づいていたが、文書は一定間隔おきに文字間に数バイトが挟まっている。これはどうやら文書右端の折り返し位置らしい。とくに改行キーを押さなくても、書式で文章が右端まで来ると何らかのデータを挟み込む仕様らしい。文書によってこの一定間隔に違いがあり、これは文書ごとの1行文字数指定によるのだろう。その折り返し情報の手前によく同じ2バイト文字が表示され、その文字は文書の文字と関係ない。これはたぶん私のプログラムで制御データが文字として変換されてしまったものだろう。禁則処理の可能性がある。ここまでならば、私が目で見てそれなりに体裁を整えれば良いことだった。ところが私は今詩を読み出したい。散文は長文なので一定間隔おきに折り返されているのがわかれば十分だが、詩は1行の文字数が少なく頻繁に改行する。文書の右端までずらずらと続いて折り返すことは逆にない。それに、行頭に字下げがあるかもしれない。おそらくは文書の左端から必要なぶんだけ全角スペースを打って字下げしてあるはずだ。当時の私がどんな体裁で詩を書いたのか、どこで詩行を改行したのか。これは知りたい。この欲求に加えて先ほどのこと、改行データなどが調べればある程度わかりそうだという気持ちが加わり、もう少し詳しくキャノワードミニ9のデータ構造を調べたくなった。

とはいえ、私とて毎日こればっかりやって過ごすわけにはゆかない。家事や仕事のようなやるべき事をやり、その合間に自由時間を見つけてはこれをやるのでなければいけない。だから、少しずつ進めて、いつの日かまとまった結果が出た時点でブログ記事にしよう。それがいつの事か、数日後か数週間後かは、私自身もまだわからない。

ゆっくりと1D FD解析再開(6)

*** 今までのまとめ ***

キャノワードミニ9の文書フロッピーディスクから文字データを読み出す方法



目次
事前の注意書き
必要なもの
上記「必要なもの」の解説
読み出し方
補足



事前の注意書き
キャノワードミニにはいくつかの機種がある。私が試したのはキャノワードミニ9の文書フロッピーだけだ。他の機種で同じようにできるとは限らない。

必要なもの
1. キャノワードミニ9の文書フロッピーディスク（大昔に文書を保存したもの）
2. 1Dのフロッピーディスクを読めるフロッピーディスクドライブ+フロッピーディスクコントローラー（普通はパソコンという形で一体化している）
3. 上記2のプラットフォームで使用できる、1Dのフロッピーディスクからデータを読み出すためのソフトウェア
4. プログラミングの環境とプログラミングの知識（データを効率的に処理するために必要）
5. 2のプラットフォームから4のプラットフォームへデータを移す手段（4に関連して必要）

上記「必要なもの」の解説
1のフロッピーは、もちろん大昔のものを今まで保存していなければどうにもならない。
2と3の組み合わせは、私の場合はPC-9821実機+MAHALITOだった。MAHALITOは（2のハードウェアがあるという前提で）2Dのフロッピーをサポートしている。1Dはサポート外（ドキュメントに記載なし）だが、実際に試したところ幸運なことに1Dは2Dと同じ条件でフロッピーディスクドライブを動作させ、ディスクの片面だけを読み取る仕様らしかった。つまりMAHALITOはフロッピーからデータを正しく読み取り、ただディスクのうち記録されていない片面分はフォーマット情報が「アンフォーマット」となった。
4は、必須ではない。フリーソフトのバイナリエディタを使い、データを自分の目で見ながら1バイトずつ解析するのは理論的に可能だ。ただしその場合、数百メガバイトという量のデータを1バイトずつ自分の目で見て判断し、ネット上のJISコード表を見て認識するので、あまりの大変さに途中で投げ出す可能性が高い。
5は、私の場合はPC-9821実機からWindowsパソコンへファイルをコピーする手段だった。私個人はMOを使ったが、これについては人それぞれに手段は異なる。

読み出し方
I.1のフロッピーディスクを2のドライブに入れ、3のソフトウェアを使ってデータを読み出してファイル化する。
II.そのファイルを5の手段を使って4のプラットフォームへコピーする。
III.（ここから先の記述はプログラミング関係の知識を含む）データの中にある文書のうち2バイト文字はJISコードで記録されており、3バイトで1文字分のデータとなっている。1バイト目はキャノワードミニ9が文字を認識するための情報と思われる。2バイト目と3バイト目がJISコードで、たとえば'愛'ならば2バイト目が30H、3バイト目が26Hとなる。JISコード用のバイトにはJISコードだけが入っており、未使用ビットが他の用途に使われることはなく、未使用ビット分をビットシフトして2バイトを連結してもいない。（つまり当該の2つのバイトをJISコードとして扱えばよい。）注意点は、(i)データの中のどこから「2バイト文字のための3バイトのデータ」が始まるかがわからない。(ii)文字列を格納した領域は、基本的には前述の「2バイト文字のための3バイトのデータ」が連続しているが、2つの「2バイト文字のための3バイトのデータ」の間に1ないし数バイトの制御データが挿入されている可能性もある。

補足
制御データのバイトを解析できれば、効率よく文字情報を取得できるだろう。しかし長年の間に自分がどんな書式で文書を作ったかを忘れた今では、制御データの解析はまず不可能だ。それで私は「総当たり戦」で臨んだ。「2バイト文字のための3バイトのデータ」がどのアドレスから始まるかわからないならば、すべての可能性を試せばいい。3バイト周期と想定して事を始めたのだから、1バイトずらして処理を始めた場合と、2バイトずらして処理を始めた場合を加えれば、それら3つのうちのどれかには（もし存在すれば）2バイト文字が現れるはず。この3つをそれぞれ1行、全部で3行に表示すれば、上下を見比べて必要な行の情報だけ読み取ることができる。（ただし1セクタの情報を1行とすると1行がとても長いので、Windowsの「メモ帳」では設定にかかわらず折り返されてしまう。Microsoft Visual Studioに読み込めば大丈夫。）



追記
後日の記事で多少の（前向きな）修正がある予定。キャノワードミニ9では文書保存時に必ずセクタの冒頭から文字情報／書式情報を記録する。上述のとおり1文字に3バイト使うが、書式情報にも必ず3バイト使う。その結果、1バイトずつずらして処理を3回しなくても良いことがわかった。でも、それを知るために上記の「総当たり戦」で臨んだ事は、データ解析の知識を得るために有意義だったと思っている。今でも、何か不明なデータに出会うとこの「総当たり戦」プログラムに立ち戻って頑張っている。詳しくは、今後の何回もの記事で段階的に進展を記録することになる。

ゆっくりと1D FD解析再開(5)

作業に熱が入りすぎてしまい、ブログの記事としての体裁を整えて文章を書く暇がない。自分用のメモをほとんどそのまま出すのをお許しいただきたい。我ながらちょっと頑張りすぎた。でも好結果は出つつある。今回と次回の記事で解析は第一段階完了の予定。でもその先もまた見えてきた。とにかく今回の分を出したい。



いま調べているフロッピーディスクに
"愛と夢の"という文字列データは必ず含まれる。
そこで、まず'愛'がMAHALITO.DATにあるか調べた。

'愛'はJISコードで0x3026
30Hの出現場所を調べた
26Hの出現場所を調べた
両方の場所が近接している所を書き出した
その結果、30Hの次バイトが26Hの場所が多数見つかり、
最上位ビットのマスクも要らなかった。
その他に、1バイトないし数バイト空いて出現する場所と
26H - 30Hの順で出現する場所が少しあった。

30H - 26Hは、予想したよりはるかに多く出現した。
あまりに多いので、これは文字コードでなく書式フラグがたまたま
この値である可能性が濃厚だ。さらに調べなければ。

"愛と夢の"ならば、'愛'の次に'と'があるはずだ。
順序は必ず'愛'の次に'と'があり、書式フラグがあるはずだから
次バイトに続いてはいないはず。'と'は'愛'の後に1バイトないし
数バイト空いて出現するはず。

'と'はJISコードで0x2448
24Hの出現場所を調べた
30Hと26Hの近接点の数バイト後に24Hが出現する場所を書き出した
30Hの次バイトが26Hの場所が多数見つかっていたが、
その多くが1バイト空けて次が24Hだった。
"愛と"の可能性が高くなった。

48Hの出現場所を調べた
30H,26H,24H,48Hが近接する場所を書き出した
その結果、前回書き出した場所の多くは48Hがなくて削除となったが、
それでも20たらずの場所が残り、これは有望だ。
30H,26H,??H,??H,??H,??H,24H,48Hの並びが3箇所（下記のアドレス879等）
30H,26H,??H,24H,48Hの並びが14箇所
30H,26H,??H,24H,??H,??H,48Hの並びが1箇所(たぶんこれは違う)

アドレス879からバイナリエディタで見てみることにした。
879は16進数で36FH
バイナリエディタの左端000360、上端+Fの所から。
確かに"愛と夢"が確認できた。

アドレス83039からも見てみたが、同じく"愛と夢"までだった。文書名だろうか？



上位バイト,下位バイトの次に1バイト空いて上位バイト,下位バイトと続く14箇所については、プログラムを組んでしまうことにした。

データ冒頭からJIS上位バイト、JIS下位バイト、1バイト飛ばして、JIS上位バイト、JIS下位バイトとみなして読み、JIS文字コードをシフトJIS文字コードに変換して（さらに内部的にUnicodeにして）テキストファイルに書き出す。

そのさい、上位または下位バイトの値がJIS文字コードの範囲外ならば、それはJIS漢字ではないので、ASCII文字コードならばASCII文字を、そうでなければスペースを書き出す。1バイト空けた部分も同様にASCII文字またはスペースとして書き出す。

キャノワードミニのフロッピー内で漢字が3バイトで表現されているのは間違いないだろう。しかし漢字用3バイトと次の漢字用3バイトの間に制御データ等が挟まっている可能性がある。そうすると後の漢字用3バイトの位置がずれる。そこで、ひとつのセクタの内容を3回処理し、1回目は冒頭バイトから漢字とみなし、2回目は2バイト目から漢字が始まる、3回目は3バイト目から漢字が始まるとみなして処理する。これらの結果をそれぞれ1行のテキストデータとして書き出し、上下に見比べることができるようにする。もしもデータがJIS漢字を含んでいれば、3つの行のうちどれかに漢字として表示されるはずだ。

半角カナは表示しない。キャノワードミニ9が半角カナを表示したかしなかったか記憶にない。キャノワードミニ9で半角カナを打った記憶はない。今は除外する。

ゆっくりと1D FD解析再開(4)

私が当面やるべきことは何か、考えてみた。

1.まずそもそも、私が使っていたワープロの機種は何なのか。それがわかれば、何年ごろのものかがわかり、当時主流だった文字コード位はわかるだろう。

2.次に、今でも私が所持しているワープロ付属フロッピーディスクを確認する。もしもこれを始めにやっておいたなら、きっとそこに1Dである事が書かれていただろうに。その基礎的な事を怠ったせいで私は2Dだと思い込んで作業してしまった。その他にもフロッピーから何かがわかるかもしれない。

私は1.から始めた。

私が持っていたワープロはその外観の記憶からキヤノワードミニ9で間違いない。キャノワードミニの各機種はそれぞれ外観が明らかに異なるようだから。定価10万8000円もしたそうだ。これは当時親が買ってくれた。勉強用だが趣味にも使った。私はこういう機械を触るのが大好きで、暗い部屋で毎日いじっていたら近視になってしまった。発売は昭和61年（1986）だそうだ。

この当時主流だった文字コードは何だろう。日本語文字コードの主なものは
JISコード
区点コード
シフトJISコード
EUCコード
Unicode

Unicodeは1993年制定だから1986年のワープロで使われるはずがない。

EUC=Extended Unix Code
EUC-JP=Extended UNIX Code Packed Format for Japanese
日本語UNIXシステム諮問委員会がUNIXで日本語を扱うための文字コードについて議論した結果をもとに1985年4月に同委員会から報告書がAT&Tに出された。1986年のワープロで内部データにこれを使っている可能性はとても低い。

シフトJISが生まれたのは1982年。1986年のワープロで内部データにこれを使っている可能性はあるのだが、どうだろうなあ。可能性を完全に捨て切る訳には行かない。

残るはJISコードと区点コード。この時点で、私はJISコードとは何ぞやという問題に直面した。私が今まで
JISコードと呼んでいたものは、何なのだろう。

1978年に、日本語用の漢字文字やかな文字、記号類を情報交換で用いるための文字集合を規定する工業規格としてJIS C 6226-1978ができた。俗に旧JISと呼ばれる。1983年に大幅改定され、1987年に廃止された。私のワープロ(1986)が内部で使っていたのはこれを元にした文字コードに違いない。

上のJIS C 6226は符号化された文字コードを意味するのでなく文字集合を意味するそうだ。これを元にした符号化方法がいくつもあり、シフトJISコードもEUCコードもそうだという。その他にISO/IEC 2022がある。

インターネットの電子メールで用いられるJISコード（ISO-2022-JP） はJIS X 0208を元にしており、そのJIS X 0208の改定前の最初の形ですら1990年なので、これは完全に除外できる。

あれ？私が今までJISコードと呼んでいたものは、選択肢に含まれていなかったぞ。

EUC-JPもISO/IEC 2022に基づく符号化表現のひとつだそうだ。シフトJISは違う。

フロッピーに記録されている文字コードの可能性は
1 私が今までJISコードと呼んでいたもの
2 区点コード
3 シフトJISコード
この３種類を試そう。

どうやって試そうか。あるフロッピーに必ず使っている文字があるので、データの中からそれを探し出そう。もし探し出せたら、その時の方法がきっと正しい方法だ。

そのまま試す（無理だろうけど）
文字コードで使われないビットを0にしてみる
文字コードで使われないビットはビットシフトして詰めてみる
上記３つについて、上位バイト下位バイトを入れ換えてみる（ビッグエンディアン/リトルエンディアン）
データが圧縮されている可能性（どうにもならん）

実際の作業として、次のものを考えた。文字コードの上位または下位バイトをプログラムに与えておく。データを読み、1バイトずつ値が同じかどうかチェックする。そのさい、そのまま試すだけでなく、文字コードで使われないビットを0にしても試す。仮に上位バイトがビットシフトされていても、下位バイトはシフトされていないだろうから、下位バイトだけでも検出できるはずだ。もし下位バイトが検出できたら、その前または後に上位バイトがないか調べる。もしもあれば、前にあるか後にあるかでビッグエンディアン/リトルエンディアンもわかる。目的の値が見つからなければ、他の文字コードで同様に試す。

ゆっくりと1D FD解析再開(3)

前回までのフロッピー解析の記事２つは、残念ながらまとまりのない物になってしまった。FM/MFMもDAM/DDAMも、MAHALITOで読み出したデータを自分で解析するぶんには不要な情報だった。（MAHALITOがデータを別のフロッピーにコピーするためには必要な情報なのだろう。）SYNC, CRC, GAP3も不要な情報だった。フロッピーのフォーマットを理解するという意味では有意義とも言えようが、調べるために沢山の時間を費やしたばかりか、各記事が私の思い違いから来る間違いを含み、それを後の記事で訂正してゆくという、読者にとっては有り難くない形になってしまった。

さらに、てっきり2Dだと思っていたキャノワードミニのFDが1Dだったことにより、そもそもMAHALITOがこのサポート外のFDを正しく処理してくれたかどうかが不明だ。

でも、地道に一歩一歩進んできたお陰で、とにかくMAHALITOが読み出したデータをフォーマット情報に従ってセクタごとに区切って1バイトずつ16進数で表示する所までは出来たと思う。ここまで来たら乗りかかった舟、MAHALITOによる読み出しが成功してデータがFDの中身を含んでいると仮定して、作業を進めよう。

今までの私はフロッピーの一般的なフォーマットを調べなければならなかったが、これから先は、キャノワードミニがそのフロッピーにどのようにデータを書き込んだかを調べなければならない。そういう情報は企業内のものだから、詳しい情報がネット上に出回っているとは思えないが、いろいろ検索したらヒントくらいはあるかもしれない。書式を規定するデータまで解析しようというのではない。テキストだけ取り出せれば良いのだ。

もちろん前途多難ではある。一文字に何バイト使っているのか、その中のどこからどこまでのビットが文字コードなのか、そもそもどんな文字コードを使っているのか。今はまだ全部わからない。だからこそ、闇雲で行き当たりばったりに事を起こすのでなく、まずはネットを検索し尽くすくらいに検索して情報を集めなければならない。プログラムを組んでデータをいじるのはその後だ。



時が過ぎた。私はネットを検索し尽くすくらいに検索して情報を集めるために、何日もかけて検索するぞと決心し、検索を始めた。２、３分後、私のスマホに次の画面が出た。


全部で31件だった。検索は２、３分で終わった・・・。

私は「検索結果をすべて表示するには、ここから再検索してください」のリンクをタップした。


私自身のブログ記事がズラズラと出てきた・・・。


そして終わった！

ゆっくりと2D FD解析再開 (2)

私はもうじき一時的に忙しくなる。この記事の次に書けるのは来週の月曜か火曜か。その前に、今書けることを書いておく。

前の記事に「MAHALITOで書き出されたデータは、どこからどこまでなのだろう」と書いた私だか、DAM/DDAMはフォーマット情報に書いてあるし、CRCはチェックサムのようなもの、GAP3は次のセクタまでの埋めらしいから、データ本体だけが書き出されているのかもしれない。まずはフォーマット情報に従ってデータを区切り、16進数で表示するプログラムを組むことにした。そうすれば各セクタの先頭データを見て判断できるだろう。で、今朝そのプログラムは組んだ。ちょっと困った事が起きた。フォーマット情報に従ってデータを読んだつもりが、データが足りなくなってしまった。私のミスの他にも気になる事があって、セクタ長情報として3が入っている。これだとセクタ長は1024バイトになってしまう。2Dは普通512バイトなのだが。時間のある時に再確認するつもり。

ここから先は私の試行錯誤の記録に過ぎない。



DAM/DDAMって何なのよ

What does DDAM stand for?
DDAM stands for Deleted Data Address Mark

フロッピーディスクコントローラの制御コマンドの拡張ビット
（中略）
Skip flag
スキップフラグ
削除済みデータアドレスマークが付いているセクターを飛ばすかどうかを指定します
0：READ/WRITE DATAコマンド時に削除済みデータアドレスマークが付いているセクターを飛ばしません
1：READ/WRITE DATAコマンド時に削除済みデータアドレスマークが付いているセクターを 自動的に飛ばします。逆にREAD/WRITE DELETED DATAコマンドは削除済みデータアドレス マークが付いているセクターのみアクセスします。

・・・
だから何なのよ！

セクタの中身がファイルの一部か、それとも未使用領域のクズデータかという問題とは関係無さそうだな・・・



FM=Frequency Modulation
ウィキさんの説明によれば、データビット間にクロックビットとして1が付加される。たとえば「00110110」をFMでエンコードした場合、クロックビットから始まるとすると「1010111110111110」に変調される。だそうだ。
するってえと、1ビットおきに1ビット取り去って詰めれば元データになるのか？でも、「クロックビットから始まるとすると」が引っかかる。クロックビットから始まらない場合もあるって意味じゃん。
あと気になるのは、記録されたデータの半分がタイミングのためのクロックビットってことになる。1.44MBのフロッピーにおよそ0.7MBのデータしか入らなかったの？仮に1セクタが512バイトだとしたら、そこから取り出される元データは256バイトなの？

MFM=Modified Frequency Modulation
こっちもデータビット間に1ビットおきにクロックビットが入るのは同じらしい。ただし、クロックビットは隣接するデータビットの状態によって0だったり1だったりする。これを使うと倍密度のデータ記録が可能らしい。
これより詳しい話はもはやデジタルの世界ではないらしく、磁性がどうの波長がどうのとアナログ的な話になってしまう。ラジカセのヘッドで磁気テープに記録する話をちょっと思い出したよ。できればその手前までの勉強で終わりにしたいなあ。

こんど時間がある時に、MAHALITOで取り出したデータがFMまたはMFMでエンコードされているかどうか調べてみよう。そうすれば、このデータがそのまま使えるのか、デコードする必要があるのかがわかるだろう。

と、書いて締めくくろうとした時にたまたま見つけたサイトがある。

http://m.chiebukuro.yahoo.co.jp/detail/q12104352007
で
fried_turnipさんいわく

例えば、00110110という8ビットの情報は、磁性体表面上には
0010010100010100と記録されます。
しかしこれは16ビットの情報が記録されているとは言いません。
16bitで表される信号ではありますが、MFMによる8ビットの情報です。
なぜならば2^16の全パターンが許されている訳ではありません。

ほえ？

さらになんかよう、出てきたよう。
http://www17.tok2.com/home/taro/WEB_HOME/BOOK/NO48/hontai.htm
ウィキさんよりもこっちのほうが詳しそうだけど、わっけわかんねえ！最初にウィキさん読んどいたからそれが少しは理解の助けになったけど。




さらに時は経ち、就寝前に頑張ってあと少しだけやった。フォーマット情報のセクタ長はどうやら正しかった。データが足りなくなったのは、私が連続データのフラグを無視していたせいのようだ。エラーチェックを増やしたが、それでもエラーは出なくなった。ところが、とんでもないことがわかった。

キャノワードミニのFDを私はてっきり2Dだと思い込んでいたが・・・

これを見る限りでは1Dではないか？MAHALITOのサポート外だな。正常処理の保証はないな。あーあ。

とにかくこれで私は就寝し、明日以降の数日間は忙しくて出てこられないだろう。

ゆっくりと2D FD解析再開

家事や仕事といった「やらねばならん事」だけやってると人生あまり有意義に感じないので、やはり趣味や楽しみも同時にやりたい。

私が趣味でやりたい事は「趣味予定表」に書いてはどんどんこなして行くのだが、この度、ずらりと書かれていた趣味予定表がめでたくほとんど真っ白になった。「やりたい事は全部やった」という快挙だ。

去年から続けていた刑事コロンボ旧作の視聴も#45まで来て一段落した。

そこでぼちぼち「いつかやろうと思っていた事」に着手しようと思う。あれだけ趣味プログラミングが好きだった私が妙に無気力なので、どこまで続けられるかはやってみないとわからない。所さんの笑ってコラえてを耳で聞きながら目と指はスマホで文章を書き、頭は構想を練り、プログラミングする時だけPCの前へ行くという形でひとまずやってみたい。

「いつかやろうと思っていた事」というのは、キャノワードミニのフロッピーからテキスト情報を読み出したいという目的だった。手持ちのPC-9821のFDドライブとMAHALITOで2Dのフロッピーがどうやらエラーなしで読めたらしいので、そのデータを見てみたいという段階だ。PC-98がらみで始まったので今はブログのカテゴリーがPC-98だが、作業がPC-98から完全に離れたら記事のカテゴリーを変更するだろう。

まずやらねばならないのは、MAHALITOのドキュメントに書かれている用語を私が理解するという基礎的な作業だ。拡張子.DATのファイルがフロッピーの中身、拡張子.2Dのファイルがフォーマット情報だそうだ。フォーマット情報の用語としてシリンダ、トラック、セクタがある。シリンダについてネット検索すると今どきハードディスクについての解説が出てきて分かりにくいが、たぶんMAHALITOのドキュメントにある「シリンダ数」は「片面当たりのトラック数」と考えて良いだろう。その「トラック」というのは円形のディスクを同心円状に区切った領域のひとつひとつ。セクタというのはトラックを一定角度で区切った領域のひとつひとつで、一度に読み書きする最小単位。隣り合ったセクタに連続してデータが記録されているとは思わないほうが良い。フロッピーディスクでは外側のトラックも内側のトラックもセクタ数は同じ。2D、2DD、2HDの2というのはディスクの両面に記録されている事を表す。その後のアルファベットは記録密度等を表すらしいので、今は深く考えずにMAHALITOのフォーマット情報に従ってデータを見ていったら良いのではないか。

MAHALITOのフォーマット情報では、トラック情報の所に「FM／MFM」というのがある。どうやらこれはデータを読む際に大事なようだ。ディスクには、読み出したいデータ以外にもクロックビットが記録されているそうだ。拡張子.DATのファイルからフロッピーの中身を読み出す際にクロックビットを取り除かねばならないのだろう。

MAHALITOのフォーマット情報では、セクタ情報の所に「DAM／DDAM」というのがある。DAM／DDAMはデータ部の最初のほうにあるデータだそうだ。拡張子.DATのファイルからフロッピーの中身を読み出す際にDAM／DDAMを読み飛ばさなければならないのだろう。そもそもデータ部とは、セクタ部をID部とデータ部に分けたうちのひとつで、データ部にはSYNC, DAM/DDAM, データ, CRC,GAP3があると記述するサイトがある。さあ始まった。最初から一筋縄では行かないと思っていた。MAHALITOで書き出されたデータは、どこからどこまでなのだろう。ID部にあるC, H, R, Nはフォーマット情報のファイルに記録されているから、データ部冒頭のSYNCから書き出されているのだろうか。いずれ実際にデータを見て確認しなければならない。

もう、所さんの笑ってコラえて３時間スペシャルが終わってしまった。私は寝なければならない時間だ。技術情報の理解に何日もかかる事は始めからわかっていた。地道にゆっくり着実に、が良いだろう。今日はここまでにしよう。

次回私は、セクタ部のデータ部にあるSYNC, DAM/DDAM, CRC,GAP3について詳細を調べよう。

PC-98と遊べればそれでいい(2)

またPC-98の電源を入れて作業の続きをするには、まず日常的に使っているPCとのデータの受け渡しを実現しなければならない。

私が思いついた方法は２つ。

1. 中古外付けMOドライブを購入し、あと2枚残っているMOディスクを使ってデータの受け渡しをする。

2. 中古SCSI USB変換ケーブルを購入し、PC-9821にSCSI接続しているハードディスクをWindows10に一時的接続してデータの受け渡しをする。

どちらも理屈的に可能らしい。以前は商品が売られていたらしい。でも製造中止になって何年も経つらしい。中古品として売られていることがあるらしい。

2.に関連してだが、箱を開けて基盤を取り出して接続するタイプの変換機器は使えない。なぜならハードディスクはPC-9821と接続して使い続ける予定だから。Windows10とのデータの受け渡しのたびに箱を開けて基盤を取り出すわけには行かない。

私がもっているPC-9821にも通信機能はある、いや、あったが、どうも使えない。インターネットはXPが入っていたPCでさえ動作が重くて使えなくなった。（そのPCは今はもうない。）ましてやPC-9821のソフト(Win95/98時代)とハードでネット接続はいまさら厳しすぎるのではないかと。PCとPCをケーブル接続してシリアル通信というのは、昔は試したことがある。その時でさえ巨大なファイルを転送中に処理が止まって先へ進まなくなったりしたと記憶している。できればやりたくない。

そういうわけで、上記の２つの方法（1.または2.）のうちどちらかで何とかしたい。それぞれの長所と短所を列挙することにより、あまり感情や気分に流されずに理性的に正しい選択を試みたい。



1.の方法の長所
2.の方法よりも安く中古品が売られている。
古いPCには古いSCSI接続MOドライブを使い、新しいPCには動作確認済みのUSB接続MOドライブを使うので、各機器間の相性の悪さによる失敗の可能性がほとんどない。

1.の方法の短所
あと2枚残っているMOディスクがオシャカになったら使えなくなる。あるいは中古MOディスクを探して買わなければならない。



2.の方法の長所
PC-9821の外付けハードディスクをそのままWindows10に接続するので、どんなに大きなデータであろうと大量のデータであろうと転送がたやすい。MOを使わないので、あと2枚残っているMOディスクがオシャカになると転送できないという心配をする必要もない。

2.の方法の短所
1.の方法よりも中古品が高い。
変換ケーブル自体がうまく機能したとしても、ハードディスクをWindows10で動かすにはドライバ（ソフトウェア）が必要ではないだろうか。（それともWindows10に初めから入っているドライバで動くのだろうか。）OSがバージョンアップしたらそれまでのドライバが使えなくなったという話はよく聞くのだが、大丈夫だろうか。



あなたがこの記事を読んで下さる頃には、きっと私の状況に進展があると思う。

PC-98と遊べればそれでいい(1)

今日は、昔のキャノワードミニのフロッピーからデータを読む試みの続きを始めた。続きというのは、ずっと前にも何かやっていたという意味だ。これをやっていたのは何年前だっただろう。当時は（今もだが）かなり曖昧な推測で行動していた。

キャノワードミニのフロッピーをPC-98のフロッピードライブに入れて、試しにPC-98エミュレータのユーティリティでイメージ化してみたら、エラーを出しながらも何かが読めた。

この時点で少なくとも２つの曖昧すぎる点があった。まず、使用したユーティリティが特定のエミュレータ用のイメージファイルを作成する物だから、ベタデータではなく何らかの特別なフォーマットで記録されているはずだ。２つめに、エラーを出しながら読んだのだから、その結果のデータにどれほどの意味があるかは不明だ。

それでも、これは当時の私にとって大きな進展だった。なぜなら、普通にウィンドウズからキャノワードミニのフロッピーを読もうとすると、そもそもまったく受け付けないからだ。理由はたぶん、フロッピーが2HDでも2DDでもなく2Dだからだと思う。それで私は諦めていたのに、フロッピーが読めた。「なんだかわからんがフロッピーを読んでいる！」というだけで私は舞い上がるほど嬉しかった。

でも私の感情とは別に、上記のすさまじい曖昧さが存在していた。

私はさらに、そのデータに文字情報が含まれていないか調べようとした。句点コードとかいうのが怪しいと（これもかなり曖昧に）推測し、データの中に句点コードとして読める文字列が存在するかを知るためのプログラムを組んで試したが、好結果が出ないまま力尽きて中断し、今まで長い間何もしなかった。

その私がどうして作業を再開したかというと、ある情報を得たからだ。私がやっているような、DOSで扱わないフォーマットのフロッピーを扱うためにmahalitoというフリーソフトがあると。そして今日、mahalitoを試すことになった。

今の私にとって一番の問題は、PC-98と日常使っているPC(Windows10)との間でどうやってデータを受け渡すかということだった。私が持っているPC-98は9801ではなく9821、でも惜しいかな、CD-Rが扱えるようになるひとつ手前の機種だ。つまりCDは読み出すだけで書き込めない。どうして少しだけ待ってCD-Rが扱える機種を買わなかったかといえば、それまで使っていたPC-9801が壊れてしまって早急に次を買わなければならなかったから。CDドライブでデータの受け渡しができないならば、どうする。フロッピーディスクドライブは健在だ。でも日常使っているPCのほうにFDドライブがない。PC-9821には外付けHDDがある。でも当時はSCSI接続。日常使っているPCには接続できない。PC-9821には外付けMOドライブもある。そして、私は以前にアマゾンでUSB接続のMOドライブを買った。いけるじゃないか？いけるはずだったが、PC-9821のほうのMOドライブがオシャカになった。それでも今まで、リードエラー、ライトエラーを日常茶飯事に出しながら、万が一にも成功するならまだ使えるという考えで使ってきた。事実今までは万が一にも成功した。でもそんな事をした結果、書き込み中にエラーを出して多数のMOディスクを駄目にした。ケースに２、３箱分あったMOディスクが、とうとうあと２枚だけになった。

私は今回も馬鹿なことに、万が一使えるかもしれない可能性に賭けた。MOディスクは駄目にならなかったが、そもそも全然アクセスできなくなっていた。私は、とにかく今日の作業を諦めた。

片付けを始め、こうなったらやけ酒をあおって馬鹿になり切るかと思っていた時、ふと頭をかすめた考えがあった。確かに今は、PC-9821から日常使っているPCへデータを送ることはできない。でも日常使っているPCからPC-9821へデータを送ることはできる。CD-Rに焼けばいい。私が一番最初にやるべきなのはmahalitoが使えるかどうかを確認することだ。PC-9821へmahalitoを送り、キャノワードミニのフロッピーをPC-9821にセットし、mahalitoを試す事までは今日できる。その結果しだいで、２つのPCの間でのデータの受け渡し方法を模索するか、それとも全て諦めるかが決まる。

私はまずバッチファイルをひとつ作った。こんなのだ：
mahalito a -2d d: b:\mahalito > log.txt

d:はPC-9821のフロッピーディスクドライブ、b:\mahalitoのフォルダは作成済みだ。このバッチファイルとmahalito本体をCD-R経由でPC-9821に入れ、キャノワードミニのフロッピーをPC-9821にセットし、mahalitoをDOS窓で試した。なんか読んでいる！（この私のリアクションは数年前と変わらん・・・）でもb:\mahalitoには新しいファイルが作成されなかった。一瞬落胆した。でもその後、なぜかbドライブのルートにデータが出来ていることを確認。私は何か間違えたかな？

ファイルが見つからずに慌てたせいで、log.txtが出来ているかどうかは確認するのをすっかり忘れてPC-9821を仕舞い込んでしまった。ちなみに、うっかりDOS窓を使わずにバッチファイルを実行してしまったこともある。即座にフリーズした。

こうして、数年前と同様にフロッピーから何やら読まれ、その結果がPC-9821のHDDの中に入った。数年前と違うのは、mahalitoが（FDドライブが対応していれば）2DのFDもエラーなしで読んでくれる仕様だということだ。フロッピーから読まれたものを解析するのは、２つのPCの間でのデータの受け渡し方法を模索した後でのことだ。

キャノワードミニのフロッピーからテキスト情報を読み出せるかどうかは、まだ五里霧中だ。可能性は低い。でも、私はそれでもいいと思えてきた。はるか昔に愛用していたPC-98が独特の音を出して起動するのを聞いて、私は自分の目的がキャノワードミニのフロッピーだけではないと思えてきた。PC-98とまた遊べる。それが楽しい。私はたった今タイプミスをしていない。「PC-98と」遊べるで正しい。「PC-98で」遊ぶのではない。私はカセットテープのデジタル化をした時も「カセットテープちゃんと遊ぼう」と表現した。PC-98やカセットテープを自分の大事な思い出ではなくただの道具とみなしている方々には理解できないであろう、熱き思いだ。PC-98やカセットテープとまた遊べる！それは私にとって最高に幸せなことだ。

個人的な調査の記録(ObsidianのBGMその2)

前の記事に書いた通りに健康上の理由からPCの前には座らないつもりだか、昨日はPCの前ではなく電車のシートに座ってスマホをいじっていた。そうしたら、CoolSoft VirtualMIDISynthの情報が出てきた。CoolSoft VirtualMIDISynthは私が前に試したソフトだ。その時は、Windows10で既定のMIDI出力デバイスが選択不可になっていたので実験失敗、やはりWindows10で既定のMIDI出力デバイスは変えられないという結果だった。ところが今回見つけた情報によると、それでも既定のMIDI出力デバイスは変えられるという。つまり、CoolSoft VirtualMIDISynthをインストールし、サウンドフォントとしてTiMidity++をインストールしてそのA320U.sf2をCoolSoft VirtualMIDISynthで選択し、既定のMIDI出力デバイスは選択できないもののWindows Media Player用既定のデバイスにCoolSoft VirtualMIDISynthを選択し、オプションのオーディオ出力デバイスをスピーカーにすると、Windows8以降でも既定のMIDI出力デバイスとしてA320U.sf2が選択できるというのだ。PCの前に座らないと決めた私だが、ここまで有望な情報が手に入ったら試さないわけには行かない。
私の目的はObsidianのBGMを鳴らすことだ。私は上記の通りにCoolSoft VirtualMIDISynth等をインストール＋設定し、Obsidianは以前に試してBGM以外は動いた時の方法でセッティングした。
ところが、BGMが鳴るかどうか以前にOBSIDIAN.EXEが起動しなかった。厳密には起動直後のウィンドウが表示される前にフリーズしたらしく、タスク マネージャを見るとmTropolis Windows Player (32 bit)のプロセスが残っており、これにObsidianのアイコンが付いている。試しにCoolSoft VirtualMIDISynthをアンインストールした（TiMidity++はそのまま）ところ、Obsidianが起動するようになった。CoolSoft VirtualMIDISynthとObsidianは相性が悪いらしい。
残念だが、せっかくの新情報もObsidianには使えなかった。

では他のゲームソフトならばBGMが鳴るのか。私がWindows10での起動を試していたWindows95ゲームソフトでMIDIを使うのはあと永遠の都だけだ。永遠の都は、Windows10の初期状態ではMIDIが鳴ったり鳴らなかったりと不安定で、大抵は鳴らなかった。VirtualMIDISynth等をインストール＋設定した後はMIDIの音が出た。ただし、ゲームソフトのメニューからMIDIをOFFにしても音は止まらなくなった。

今回の記事もPCではなくスマホで書いている。これからも、可能な限りPCの前に座らないでブログ記事を書きたいと思っている。

今のうちにやめるんだ

さあ逃げるぞ。これ以上続けるときりがない。きょう偶然にもAliveが動いた。動いてるうちにそれで満足してWindows95とはオサラバだ。明日になったらまた動かないに違いない。今のうちに逃げるんだ。



今日の実験まとめ　ここから＞＞＞


3. Windows10での稼働をしつこく試し、今日は稼働したので、稼働しているうちに試せることを試し、まとめておく。

稼働要件は明確に判定できない。Windows10でユーザーが設定できる項目だけでは決まらず、同一の設定項目で一度稼働しても次回は動作停止した。以下に記したことも、同じ条件で翌日試してうまく行くと言い切れない。いや、今までの度重なる実験から考えてうまく行かないのではないかと思う。

3-1. ゲームのインストール

他のアプリケーションソフト、とくにGoogle Chromeを終了しておく（Google Chromeが動作中だと必ずAliveのAUTORUN.EXEが動作を停止することを確認した）。ゲームのCD-ROMをディスクイメージにしたものをDaemon Tools Liteにマウントした。自動再生を開いてAUTORUN.EXEを起動した。これでインストールできた。ただし、必ずうまく行くという保証がない。同じ設定で後日試しても、「Aliveセットアップ」ウィンドウが開いた直後に「Aliveは動作を停止しました」が出た。一度動作を停止すると、その後うまく行かなくなると思ったほうが良い。動かなかった時にはAUTORUN.EXEの互換性を色々といじった時もあったが、動く時には互換性をいじらなくても動くので、互換性は気にしなくて良いのかもしれない。むしろ、Daemon Tools Liteでマウントした仮想ドライブのドライブレターを変更してみるのが効果的かもしれない。

3-2. ゲームの稼働

他のアプリケーションソフト、とくにGoogle Chromeを終了しておく（Google Chromeが動作中だと必ずAlive.exeが動作を停止することを確認した）。ゲームのCD-ROMをディスクイメージにしたものをDaemon Tools Liteにマウントした。インストール先のAlive.exeを起動した。これでゲームは稼働した。ただし、必ずうまく行くという保証がない。同じ設定で後日試しても、「Alive」ウィンドウが開いてロゴが表示される直前に「Aliveは動作を停止しました」が出た。一度動作を停止すると、その後うまく行かなくなると思ったほうが良い。動かなかった時にはAUTORUN.EXEの互換性を色々といじった時もあったが、動く時には互換性をいじらなくても動くので、互換性は気にしなくて良いのかもしれない。むしろ、インストール先のフォルダ名を変更してみるのが効果的かもしれない。

＜＜＜今日の実験まとめ　ここまで



ゲームプレイ動画５分を20秒に縮めたもの(2.16MB)
Aliveから逃げるにあたり、記念に何かしておくことにした。なにせ明日になったらきっとまた動かないから。はるか昔のセーブデータを読み込んで、途中から5分間だけプレイした。それをoCamでキャプチャした。他人がプレイしているゲーム画面というのは退屈なものなので、そのままUPするのは記事を見に来てくれた方に申し訳ないと思った。それでビデオオーサリングソフトを使って全長5分20秒を0分21秒にまで縮めた。チャカチャカと高速で動いて少しはコミカルになるかと思ったが、退屈なものが出来てしまった。DLしなくても良いと思う。私がAliveから逃げる前に記念に何か残したくて置いているにすぎない。

記録

昨日スキャナで画像にした昔のCD-ROM外見とその付属品です。本当はこんな形でなく、「Windows95用ソフトがWindows10でも動いた」という記事にしたかったんですが、それはできませんでした。


私をさんざん振り回してくれたAlive。Windows10での稼働はもう諦めるしかなさそうです。「私をさんざん悩ませてくれたソフトを最後には何とかして動かしてみせる」という気持ちでやってきましたが。最後に諦めるというのは、とても嫌なものです・・・


実は外見のデジタル化の後、Aliveはまた完動したんです。動作停止せず、普通に動きました。もちろん私は舞い上がって喜び、翌日つまり今日、同じ設定で動かしたら・・・また動かない。こういう動作要件が不明で動いたり動かなかったりする手合い（アプリケーションソフト）が、いちばん厄介で、疲れます。


これも前に記事にしたソフトAsgaldh。そしてこれもWindows10で動かなかったソフト。やっぱり、あっさりと動いたソフトにはあんまり関心がなく、てこでも動かないソフトに関心があります。ゲームがどうのでなく、動かすことへの情熱です。でも、これも諦めた末に画像だけ出すことになりました。


ポスターは折り目のせいで顔がしわくちゃだったので、CD付属の紙を600dpiに引き伸ばしてみました。


こんなのも出てきました。これはWindowsでなくPC-98用です。


動きそうで動かないMYST。CD-ROMへデータを読みに行った時点で動作停止するみたいです。これはAliveみたいに動作要件不明なタイプではないので、さらに追究すれば先へ行けるかもしれません。ところで、「お願いだ。頼む。」って元の英語ではなんて書いてあるんでしょう。please pleaseとは言わないはずだから。


Obsidianです。「あれ？CD-ROMは赤かったはず」と思う日本人は多いでしょう。これは英語版だから黒いです。日本語版が赤いと私が知っているのは、そう、そっちも持っているからです。このゲームは、BGMが鳴らない間抜けな状態でですがWindows10でも動きました。


CDが綺麗だというだけの理由で保存してあるゲームソフト。今回のWindows10上での稼働実験に加える気もなかったという、ちょっと不遇な扱いのゲームです。


私が中古品を買った珍しいケースです。もはや中古でないと手に入らなかったので。で、高いお金を出して買ってきたらタバコ臭くて。最初の持ち主がタバコ吸いながら扱っていたのがよくわかりました。

他にも葉っぱの雫痕東鳩がありますが、割愛します。美少女ゲーは私の歳になると再プレイはキビシイですが、昔の思い出とか綺麗な絵とかは良いものです。

美少女ゲーでないObsidianとMYSTは、再プレイしてブログに「数十年遅れのゲームレビュー」でも書きたい気分です。どちらのゲームもネット上にプレイ動画があるのは知っていますが、ゲームは自分がプレイするのが楽しいはずですし、日本語版のプレイ動画はネット上にもありませんし。MYSTは最近のWindowsで動くのが出ているようですね。英語版ですが。それが出たせいで、ネット検索しても古いMYSTを今どきのWindowsで動かそうという記事が全然見つからないんです。