今度こそ大丈夫な筈、です、多分。
X1turboのアルファにおいて、オープニングデモの銃声が２重に再生されたり、
ポリスロボットにつかまった後にCGが化ける問題が解決しています。
同じくX1turboのイース２のオープニングのタイミングは、もうちょっとかな？
MZ-80KのSP-6010の起動も高速化しています。
むしろ実機より高速っぽいですが、これはモータが回転し始めて、回転が安定して
READYが返るまでの時間が入ってないのが原因かと思います。
次はこの辺の改良を進めたいですね。
私のFDCの実装では、ヘッドの現在位置を意識してタイミングを取得しています。
具体的には、最後にDRQが立ったときのヘッドの位置と仮想マシン内の時間を控えておいて、
そこからの経過時間と、ディスクの回転数、トラック長から、現在のヘッド位置を算出します。
また、インデックスホールを先頭に、トラック全体のデータの並びを生成することで、
各セクタのIDやデータが、トラック上のどの位置にあるかを取得します。
例えばREAD/WRITE SECTORでは、現在のヘッド位置から、アクセスするセクタの位置までの
ヘッドの移動量を算出して、アクセス開始までの待ち時間を決定するという塩梅です。
ここまでは従来からやっていたのですが、じゃあ何が問題だったかと言いますと。
最後の最後で、セクタの位置の配列の引数が間違っていて、別のセクタまでの移動量を元に
タイミングを算出していたという体たらくでして（苦笑）
この方式、各セクタのIDやデータの、トラック上の位置を正確に取得できるかが重要ですが、
現在のディスクイメージでは完璧な実装にならないのが悩みの種です。
例えばD88フォーマットでは、トラック長やセクタ間のギャップ長の情報がありません。
標準的なフォーマットであれば、規定値を元に算出できるのですが、
モータの回転数を落としてフォーマットすることで、トラック長を大きくしてやって、
その分セクタを余分に突っ込んでいるようなものもあったりする訳で。
さらに2D形式などのベタイメージだと、セクターのIDの順番に格納されていますので、
セクターの並び順すら確実ではなかったりします。
将来的には、KryoFluxのRaw Stream形式をそのまま扱えるようにしたいのですが、
まずはKryoFluxを購入するところから始めないといけませんね（を
