このメールは、OSASK伝言板に書き込まれた内容です。 この書き込みに返事を書く場合は、下のURLから書き込みを行なって下さい http://www.imasy.org/~mone/osask/index.cgi?REFER=3d5d0e96_c7d3 2002/08/16 23:39 川合秀実 [OSASK 4286]へのレスです。 >GSL=Gap Skip Lengthで誤植ではないのですが、 >調べてみるとせいぜい「フロッピ・ディスク装置のすべて」 >ぐらいでしか使われていない用語だったようで、、、 >すいませんです。 なるほど！Skipですか。・・・誤植だなんて言ってすみませんでした。お恥ず かしいです。 （ライト時のGSLの意味） >出力してはいないと思います。 >ここで指定するのはマージンであるべきGap3をSyncと誤認しては困るからではないでしょうか。 >たとえばセクタの上書き時に完全には上書きにならずに >いくらか前のデータが残ることも誤差範囲としてありえるわけです。 >そのとき、(前の残りカス)-GPL バイトをSyncの可能性がある領域として >走査してしまい、運悪くそのデータが連続する0xFFだったりしたなら >間違ったSyncとして認識する可能性があります。 なるほど。上書きがずれるかもしれないというのは僕も考えました。ここから 先は僕の予想ですが、やっぱりGAP3をGPL分だけ出力していると思います。もし 出力しないのなら、値によって読めるディスクになったりならなかったりする理 由が説明できません。これはズレた分のごみをつぶすために出力しているのでは ないでしょうか。 しかしそれでも僕には矛盾することだらけです。仮にGPL分だけ出力している にしても、ディスク上には十分なGAP3があるはずで、問題はないと思うのです。 また、実際問題として18バイト以上もずれるなんてことはないでしょう。だから やっぱり短い分には問題ないはずなんですが・・・。 もしGPLがGAP2の長さだとしたら、指定より短かったせいでIDフィールドとデ ータフィールドの間隔が狭くなってしまい、データフィールドを見つけられなく て読めなくなったと考えることはできます。・・・でもこれをやっているとした らAM2も上書きしていることになり、DMかDDMかを区別できないことになります。 それに正しい値である53はGAP2にしては大きすぎるし・・・。やっぱりGAP3でし ょうね。 うーん、結局お手上げです。 ちなみにSyncバイトは0x00です。もっともMFM方式では0xffを半bitずらして読 めば0x00に見えるので、やはり0xffの列をSyncと間違える可能性はありますが。 >FDCDRVを見てみましたが、あの値なら十分だと思います。 わざわざ確認していただいてすみません。 >Winは21sect/trackのDistribution Media Formatを読めるわけですし。 >（DMFがDOSでエラーになるというのはGap3が関係していることがあるのかどうか知りたいところです。） >ところで、DMFのような大容量フォーマッタは国内には存在しないようなので、 >OSASKが普通にDMFや1.68Mディスクを作ることができればユーザがごくわずかに増えるかもしれません。 多分、作ることも読むことも書くこともできるようになるでしょう（フォーマ ットの選択肢にごく普通に出てくる感じで）。それがOSASKってもんです。まあ それ以前に解決すべき問題がたくさんあるため、将来の話ではありますが。 (トラックイメージ) >こういうとき8877系は便利ですよね。 765Aでもトラックのイメージをそのまま読めます。READ DIAGNOSTICコマンド です。98エミュレータを書いたときにサポートしてうまくいったので、間違いな いと思います。まあ765Aではアドレスマークを見つけても同期を取ってくれない ので途中からビットずれをおこしたりしますが。確かにこの点では8877Aのほう がいいです。 >しかし、それより他のPC-98や互換機から問題のディスクが読めるかどうか、 >同機種別固体で問題が再現するかどうかなどをまず調べた方がいいような予感がします。 そう、そもそもI.Takさんのマシンでricky8nがうまくいったという報告もまだ ありませんし。GPLのミスだったかどうかさえ、はっきりしていません。 >うーん。大した事が言えないのであとは偉い人にお任せします。 >「フロッピ・ディスク装置のすべて」買っときゃよかったかな・・・ その本、僕も読みたいです。・・・どこかにないかなあ・・・。