• 34 名前: D-Type ID:1YWEyNzk4

    最近までWin95をインストールして動かしてみていたのですが、
    RS-232Cにクロスケーブルを繋いでLANにNull modemで繋いでネットに出ることに成功しました。
    といっても既にWin95ではhttps接続が必要なページは表示できないため、
    vectorのソフトライブラリとかは見られないのですが。

    うまくすればsmb1とかcifs辺りを使ってLANでファイル共有ができるかも知れないですね。
    まあ、ファイル転送はWindowsPCを直結したほうが手っ取り早いのですが。
    上限38400bpsでインターネットに繋がってgoogleが見られたので一旦一区切りとしました。

    なお、一つ前の書き込みで間違って書きかけで書いてしまいました。
    可能でしたら削除をお願いします。

    2022-10-02 12:10:31

  • 35 名前: cat ID:yOGIzNzky

    はじめまして。津軽利用しています
    津軽ですが、ホスト側のマウスカーソルを消す方法はありますか?
    津軽側のマウスカーソルとホスト側のマウスカーソルと二重に表示されてしまいまして
    よろしくお願いします

    2022-10-08 21:34:58

  • 36 名前: 山川機長 ID:0OWJhZTc3

    >catさん

    すみません、今のところホストのカーソルは消えないようになってます。今まであまり需要がなかったのと、VM上のマウスカーソル位置は少しのラグがあってホストのカーソルに追いついてくるので、見えていた方が安心なので消してません。カーソル消す需要って結構ありますかね?

    2022-10-11 08:07:31

  • 37 名前: BCC ID:2NmY2Njlk

    >山川機長さん

    動作自体には支障がなかったので要望していませんでしたが、オリジナルのマウスカーソルなどが表示されているゲームなどでは気になっていたので自分もオプション設定で欲しい機能です。>マウスカーソルの非表示

    マウスカーソルとは話が変わりますが、i486DX::Interrupt内で二か所存在するauto TempSS=state.SS();は、auto TempSS=state.SS().value;と値だけコピーされるようにしたほうがいいかもしれません。明確に差異が出る最適化ではないですがVSの警告メッセージで「コストのかかるコピー操作です。」とわざわざ表示される操作のようなので念の為。

    2022-10-11 11:02:11

  • 38 名前: WINDY ID:0MDA1Njk2

    私自身は気になってはいませんでしたが、確かにシチュエーションによってはホスト側のマウスカーソルが無い方が良い場合もあるのかもしれません。
    うんづではホイールによってどちらのマウスを操作するかを選べましたが、ホイールボタン(中ボタン)やホイールの回転で消せても良さそうですね。

    2022-10-12 12:57:24

  • 39 名前: 山川機長 ID:iMmJkMWY1

    おおなるほど。結構需要はあったんですね。うーん、Windowsだったらすぐやり方わかるから、とりあえずWindows版からそういう機能対応しようかな。

    BCCさん、

    TempSS了解しました。INTは結構飛び交ってるので重要ですね。それから、Pull Requestの__assume(0);なんてよく見つけましたね!僕はVisual C++が出してくるアセンブリを見るとswitch-caseで範囲チェックが不要なときも範囲をわざわざチェックしてからジャンプしているようだったので、なんとかこの範囲チェックを無効化できないか#pragmaでそういうのが無いか結構探したのですが、見つからなくて挫折しました。

    2022-10-17 11:00:43

  • 40 名前: BCC ID:jZGE5Y2E1

    >山機機長さん

    VCの解析ツールでCPU負荷がかかっている箇所を調べてSwitch文一か所だけで16%ほどCPU時間を食っていたようなので、たしか「switch テーブルジャンプ」とかで検索して出てきた同じようにCPUのエミュレータ実装を解説するサイトの情報を参考にしました。
    http://gigo.retrogames.com/t_lab/chapter1.html
    これだけでもswitch文の負荷が1.6%と10分の1になり、pri timebalance値も1.3倍ほどでした。
    指定せずコンパイラがswitch文をテーブルジャンプ化するのはおそらく
    ・caseの値が昇順になっている。
    ・caseでgotoやreturnを使ってswitchを抜けない
    ことが条件かと思います。
    opCodeRenumberTable配列を整理するのが面倒になってしまって__assume(0);のみの指定にしましたが、VC以外でコンパイルすることを考えたら整理しておいた方がいいかもしれません。
    他にボトルネックになっているFetchInstructionも見てみたんですが、こちらは改善する方法はまだ見つかりません。

    2022-10-17 20:17:27

  • 41 名前: BCC ID:jZGE5Y2E1

    すみません。誤字がありました。お許しを。

    2022-10-17 20:23:52

  • 42 名前: cat ID:5ZmE1OTk3

    山川機長さん、お返事ありがとうございます
    マウスカーソルoffの機能今の所は非実装の件わかりました
    今後のバージョンアップでカーソルON、OFFの選択ができると嬉しく思います
    マウスがブラー表示みたいになるので、そこを気にしてしまう事があります

    2022-10-18 15:18:57

  • 43 名前: 山川機長 ID:xYjE3MGRl

    > BCCさん、

    まあ、高速化はパズルを解くようなものなので、新しい解が思いつくとちょっと速くなって、を繰り返す感じですよね。

    ジャンプテーブルですが、VCが出してくるアセンブリを見ると、一応デフォルトでcaseがある程度を超えてif-elseの連続よりも速いと判定した場合は、ジャンプテーブルを使うようです。

    ただ、問題だったのが、caseの値が連続していない場合、この範囲はこのジャンプテーブル、別の範囲は別のジャンプテーブルというように、ジャンプテーブルをいくつも用意して、どのテーブルを使うかまず範囲チェックしてから飛ぶ、みたいなコードを出して来るので、とくに処理が単純なインストラクションに関して相対的に遅くなっていました。

    また、仮にジャンプテーブルをひとつにまとめることができたとしても、

    CMP EAX,case_minimum
    JB no_case
    CMP EAX,case_maximum
    JA no_case
    JMP [EAX*8+jump_table]

    みたいな処理になっていて、そもそもdefaultに飛ぶ可能性がゼロの場合、範囲チェック自体をスキップさせられないかと思って、#pragmaが無いか探していたのですが、多分解は__assume(0);だったんですね。あとは、頻繁に出てくるインストラクションをジャンプ元の近くに置くことでキャッシュにヒットしやすくする、というような可能性もあるので、多分、caseの値は、上り順にしなくても値を連続にする(範囲チェックを最小にする)ことでスピードが上がると思うんですがね。

    しかし、returnとgotoで変わるというのも、変える必要ないはずなんですが、オプティマイザがギブアップしてしまうんでしょうかね。


    > catさん、

    実はカーソルオフの需要が結構ありそうなので、近いうちに実装しますので、少しお待ちください。

    2022-10-20 00:45:39

  • 44 名前: BCC ID:3ZjA3ODZl

    Interruptのauto TempSS=state.SS().valueとFetchOperandについてPull requestsしておきました。
    auto &op1=instOp.op1;
    auto &op2=instOp.op2;
    とswitch文前でなってますが、op1のみしか参照されない、そもそも両方とも使用されないcaseがある、参照されてもそれぞれ1回のみなのでないほうがよいかもしれません。

    2022-10-23 11:05:20

  • 45 名前: 山川機長 ID:lNGFhMjRm

    BCCさん、pinさん、

    githubのdiscussionありがとうございました!まあ、高速化はパズルを解いていくようなものなので、のんびりやりましょう。あと、C++で同じ関数内で

    auto &op1=instOp.op1;
    auto &op2=instOp.op2;

    こういうのがあると、ポインタとして変数は作られなくて(変数作ってないからポインタのようにリファレンスを割り当てなおしたりできない)、エイリアスとして働くはずなのでCPU時間のロスはゼロだと思います。auto *op2=&instOp.op2; みたいになってると、ポインタ変数を作ってポインタの値を代入してというステップが入るので、数クロック食う鴨しれないんですがね。

    ところで、最近衝撃を受けたんですが、ゲーム保存協会からCRCエラーが出て読めなくなったディスクがCyclomethiconeという化粧品みたいな薬品を塗ると復活すると聞いて、実験してみたところ、次々にディスクが復活してます。汚れてそうな部分をまず無水アイソプロピルアルコールでクリーンして、その上にCyclomethiconeを塗って乾かすという作業なのですが、これまで相当状態が悪かったディスクが読めるようになったケースが多数あり、それも昨日までは、試す前に塗ってから試したので本当に状態が悪かったのか不明だったのですが、昨日はなんと一度CRCエラーが出て読めなかったFM77AV用「琥珀色の遺言」が読めるようになりました。

    ただ、いくつか注意点があって、

    - ディスクをドライブに入れてモーターがオンになったときシャカシャカと音がするものは復活できない。何かこすれるもの(ゴミとか)が入っているのでディスク移植が必要で、3.5inchだと結構難しいらしい。現在研究中、というか既に保存協会では手法を確立しているっぽいけど、ドキュメントにはなってないっぽい。
    - Cyclomethiconeを塗るとき、塗りすぎて窓の外に広がって行かないように注意する必要がある。ディスクの内部の布にしみ込んでしまうと多分布がふやけてシャカシャカ音が出始める。そのために、もう復活の可能性のないようなダミーディスクを用意して、塗るのに使う綿棒などにしみ込み過ぎていないかダミーディスクに塗って見て、大丈夫なら本番ディスクに塗る。
    - 根気が必要。5インチと違って、どこがインデックスホールかわかりにくいので、エラーが出てるトラックは一周塗らなくてはならないけど、あの小さい窓で塗って乾かしてを繰り返すと、ディスク一枚やるのに1~2時間ぐらいかかる。
    - Cyclomethiconeによる復活は一時的なものである場合があるので、KryofluxやPaulineなど高精度スキャンができる状態で復活させて、復活したらすぐ読んで保存しとく。

    なお、塗るのにはカモイス・ティップが強くお勧めで、ヘッドにCyclomethiconeが付着しても大丈夫だそうです。あと、シャカシャカ、カタカタ音がする場合でも、軽いものであれば割と行けます。というか、実機使ってた時も多少シャカシャカ・カタカタと音がするディスク読めてたと思うんですよね。

    Dinosaurの原本がCRCエラーが出て読めなくなってたんですが、シャカシャカ音は聞こえないので復活にトライして、Paulineがあるから高解像度スキャン取って、実機で起動させてみようと思います。一応、Dinosaurのプロテクトは既にD77で完全に再現できることはわかっているので、高解像度スキャンをしなおす意味はないんですが、一応念のためというのと、実機でオープニングだけでも一度見てみたいという感じですね。

    ちなみに、なぜこれで復活するかというと、どうもディスクのエラーは大半が磁気的なロスではなく物理的な問題で読めないそうです。ディスクの読み込みはパルス幅が全てで、もしもディスクに微妙な凹凸ができたり、布にホコリがたまってスムーズな回転ができなくなると、回転ムラが大きくなってきて、ついにパルス幅が許容範囲を超えてエラーが出るようになるそうです。Cyclomethiconeは多分凹凸を埋めるのか、あるいは潤滑剤みたいに作用してスムーズな回転を復活させるもののようです。

    Dragon Slayer英雄伝説も復活させたいんだけど、シャカシャカ音がするんですよね。これ、ちょっと逆に大量のCyclomethiconeを投入して布が柔らかくなってる間に読ませるとかいう手はないだろうかなどと考えてるんですが。

    2022-10-26 00:56:33

  • 46 名前: 山川機長 ID:lNGFhMjRm

    すげえ!Dinosaurと信長の野望・覇王伝のディスク復活した!

    というわけで、Dinosaurを実機で起動できましたが、確かに、最初の不協和音のとこ、津軽だとちょっと強すぎるかな。微妙に違うような。でもスピーカーの差のような。

    2022-10-26 12:50:45

  • 47 名前: 山川機長 ID:mZjAxMGI5

    そういえば、高速化と言えば、「陸奥」を書いてて思ったのですが、現状では、Deviceクラスにvirtual関数のIOReadByte / IOWriteByteみたいな関数を作って、その中でさらにswitch-caseでそれぞれに分岐するような対応してましたが、これ、別にデバイスが増えたり減ったりするわけでもないので、switch-caseで直接処理する関数に飛ぶ方が結構速いはずなんですよね。今だと、まずIOアドレスからデバイスのポインタを取ってきて、そのRTTIから関数のアドレスをゲットして間接コールで IORead / IOWriteに飛び、その中で switch-case で分岐、になってるので。そもそもvirtual関数だととび先をゲットするのにどうしてもoutside cacheアクセスが発生して遅そうな気がするんですよね。それともRTTI領域はアクセスが多いからキャッシュに入れっぱなしにするみたいな工夫してるのだろうか。CPUが自動判別するのは難しいけど、最近のCPUだと「この辺はアクセスが多いからキャッシュに入れとけ」みたいな指定するインストラクションとか内部レジスタとかあるのかな?

    あとメモリアクセスも同じなんだよな。しかもこれは相当頻繁に起きてるからここのvirtualやめるだけで多分目に見えて速度上がるんだけどな。ちょっと壊さずに構造変える工法が思いつかない。。。。。書いててちょっと思いついた。後で試してみるかな。


    この部分は変更しても、拡張性という点でも、新しいデバイスをサポートするときは、VMクラスのIORead/IOWriteにcaseを追加するのを忘れなければいいだけなのでそんなに問題にもならないと思いますし。ということで、今動いてるものを壊さずに変更する工程も大体考えたのでちょっとずつやっていこうと思ってるんですがね。

    動いてるものを壊さずに構造を変えていくのも結構アートですよね、と、思うのでデバッグ技術と合わせてうちのプログラミングの授業で教えたいと思うけど巨大な例題を与えても学生はついてこれないし。せっかくYSFLIGHTとか津軽とか陸奥とかあるから授業にも使いたいんだけどなあ。

    2022-10-28 02:31:27

  • 48 名前: 山川機長 ID:hYjdlZWJl

    githubに、マウスカーソルオン・オフ機能追加したソースをPUSHしました。これまでデフォルトでScroll LockキーでPause/Resumeでしたが、Shift+Scroll Lockでホストのマウスカーソルをオン・オフできるようにしてみました。まだWindowsのみ対応で、macOSとLinuxではカーソルオフになりません。よかったらお試しください。

    2022-10-29 14:13:18

  • 49 名前: 山川機長 ID:mODVlMTQx

    すげえ!一日がかりで何度もCyclomethicone塗りなおしてスキャンを繰り返すことになったけど、フロッピーディスク版FM OASYSもディスクイメージ作成に成功した!

    ディスク版だと編集始めようとするとなにやらRead Addressに失敗してディスク編集開始しませんね。調べて津軽修正しなきゃ。

    なおFM OASYSのイメージ化、Maked77だと最初のトラックがうまくできないですね。トラック1以降だとうまく読みますが。しかし、最近Paulineを導入したので、それを使って大体読み込んだものの、CRCエラーがどうしても消えなかったので、最後は実機ドライブで一部トラックを読ませたら読んだので、合わせてフランケンイメージにしました。MakeD77はDisk BIOS使ってるから、規格外のフォーマットだとときどき失敗しますね。まじめにI/O直接攻撃するように書き替えようと思ったままになってますが。

    2022-10-31 13:30:12

  • 50 名前: WINDY ID:2YWQ5YmE4

    >45 山川機長さん

    Cyclomethiconeですか、そのような物が有るんですね。
    興味があったので少しだけ調べてみましたが私が調べた限りではシリコーンオイルの類の様なんですが・・・ 果たして同じものを指しているのか不明です。
    シリコーンだとすると塗布して拭き取ってもスベスベするので確かにディスク上の汚れやゴミの影響でディスクの回転が不安定になっている場合には効きそうですね。

    あと、FM OASYSのトラック1は単密度だと言う記憶が・・・ どこで見たかなぁ? どこかで見た覚えが有ります。

    2022-11-02 15:08:44

  • 51 名前: 山川機長 ID:0ZTVlNGY0

    おおなるほど、FM OASYSのトラック1は既に知ってる人いたんですね。そうなんです。FMフォーマットでした。ということで、 https://github.com/captainys/FM ここのMAKED77.EXPをFM対応にしました。最初MFMで読んでみてセクタが見つからなかったらFMで再トライするようになってます。

    が、今はMAKAED77.EXPはDiskBIOSでやってますが、BIOSを使うといろいろ制限が多いので(とくにRead Trackの結果も保存したいけどそれができない)、I/Oを直接攻撃するように書き換えようと思ったのですが、TOWNSのFDCのI/OってIRQフラグが出てないんですね。FDCがReadyになるまで待つ方法だと何かDMAとタイミングが合わないのか、どときどきDMAが失神する現象が起きてます。なんとかFDCからのIRQをポーリングで取れないかやっているのですが、High-Cで

    #define IO_PIC0_IRR 0x00
    #define IO_PIC0_OCW3 0x00
    void WaitFDCIRQ(void)
    {
    _outp(IO_PIC0_OCW3,0x0A); // pp.65 of FM TOWNS Technical Databook
    while(0==(_inp(IO_PIC0_IRR)&IRR_FDC))
    {
    }
    }

    これで取れるかと思ったんですが、取れないんですよね。プロテクテドモードからだとIRQをTake Overするのがやたらややこしいし、この関数に入る前にCLIしているのでFDCの割込みに取られちゃってるということはないはず(津軽上だと動く)のですが。TOWNSでFDCからのIRQフラグをポーリングで知る方法ってだれか知ってます?

    2022-11-03 01:04:50

  • 52 名前: 山川機長 ID:2YTkxMzcz

    うーむ、PICにポーリングモードというのを見つけたから I/O 00H に 0Ah じゃなく 0Eh を書き込んでみたが、たしかにIRRが取れるようになったけど、ときどき取りこぼして無限ループ入りするなあ。惜しい。やっぱTOWNS実機ではIRQハンドラをなんとか乗っ取らないとFD読めないのかな。

    2022-11-04 13:48:50

  • 53 名前: WINDY ID:2Yjg2ZDkz

    >52 山川機長さん

    試された結果かもしれないのですが、これって割り込み管理BIOSを使っては駄目なのでしょうか?(INT AEH,AH=00H)

    2022-11-07 14:41:09

  • 54 名前: 山川機長 ID:kNTkwZDhi

    ああ、割込み管理BIOS試してなかったですね。これ、プロテクテドモードから使ってもリアルモードのハンドラしか設定できないのではないかと思ってたんですが、ここ数日Watcom Cでリアルモード用に書こうとしてたので、使う価値あるかもしれない、と、思ったんですが、昨日考えてみたらセクタ読み込みにかかる時間計測しようとしても、コマンド出してから読み終わるまでだとヘッドが回ってセクタにたどりつくまでの時間もカウントしちゃうからFM77AVのYs2とかSilpheedみたいにセクタの最初のバイトから最後のバイトまでの読み込み時間を計測するタイプのプロテクトに使える情報抜き出せねえじゃん、ということに気が付いて、やっぱTOWNSの実機だとBIOSを使う以上の情報は抜き出せないような気がしてきています。それと同時に、TOWNSだとなぜこの手のプロテクトが無かったのかわかった気がしました。(DMAのカウンタが変わり始めたタイミングをつかまえるという手も考えたけど、DMAが動いてる状態でCPUがDMAのカウンタ読んだら競合が起こる気がする。)

    MAKED77.EXPでTOWNS用のディスクのイメージ化だったらとくに困らないんですけどね。FM77用のディスクをイメージ化するとき、もう少し情報を抜き出したかったんですが。

    2022-11-08 02:26:06

  • 55 名前: WINDY ID:xMDQ0ZGU3

    >54 山川機長さん

    タイプIVコマンドでIRQを出すことは出来るけど、notREADY→READY,READY→notREADYのどちらも指定は出来るがREADYはFDD側での取り扱いとなる。
    んで、FDD側の手持ち資料を見ましたがREADYに関する記述ではMOTOR ON後500ms後にLOWとしか書かれておらず・・・・ 外部回路が絡んでなければ頼りにならない信号ですね。
    どちらにしても仰る通りデータを読んだ信号としては使えそうに無いとなると、FM-7/77/AVでのDRQ信号となる訳ですが、こちらの方は直接TOWNSのI/Oには出ていないのですが
    MB8877のデータシートを見るとタイプIIとタイプIIIのDataRequestビットの項目に"This bit is a copy of the DRQ output"と書かれていますのでステータスレジスタ(I/O 0200H)
    のbit1に出て来ているようです。

    これって使えそうな気がしますが、如何でしょう?

    2022-11-08 10:06:19

  • 56 名前: 山川機長 ID:kOTUyZTA4

    WINDYさん、

    おおなるほど!と、思ったけど、ステータスを読んでしまうとIRRをクリアしてしまうはずだから、ちょっと微妙鴨しれません。通常のセクタは最初のバイトでIRQが出ることはないので大丈夫そうですが、FM-7でときどき見かける、ID MarkがあるけどData Markが無いみたいなセクタが来た時難しいかもしれないですね。現在DMAのカウンタが動き出したタイミングをセクタの開始と見てはどうかというアイディアを考えてます。

    しかし、SCSIのディスクにアクセスすると次のフロッピーディスクアクセスでいつまで待ってもIRQがかかってこなくなる現象ではまってます。リアルモードで書いてるので、大きなバッファを取れないので、1セクタ読むとイメージファイルの追記して、を繰り返しているのですが、いったんSCSIアクセスすると高い確率で次のFDCへのコマンドでIRQが返ってこないんですね。パレットを使ってIRQ待ちループが回ってることは確認できているのですが。適当に40msのウェイトを入れたら成功する率が上がったので、おそらくfclose後もSCSIが何か終わってなくて、その影響でFDCとDMAが何かのデッドロックになってるのではないかと見てるんですが。

    しかし、DMAのI/OにはReadyみたいなビットは出てないし、BIOSの挙動を見てもフロッピーディスクのセクタ読み込みで何か待ってるような感じはしないんですよね。SCSIへの書き込みはきちんとすべてのフェーズが終わってBIOS Callを抜けてくるから、DMAが一仕事終わって放心してる間になんか書いてしまっているとしか思えない。ウェイトを増やすとか、セクタ読み込みにタイムアウトのチェックを入れるとか考えてますが、正しい方法がわからんのが難しいですね。

    2022-11-09 02:27:27

  • 57 名前: 山川機長 ID:kOTUyZTA4

    うーん、100msのウェイトにしたらより成功率が上がり、タイムアウトを入れたら当然タイムアウトしたセクタは読めないけど、次のセクタは普通に読むようになったところを見ると、FDCへのコマンドが無視されているとしか思えない。FDC StatusがReadyのときにコマンドを書いて無視されるというのはどういう状況なんだろう???あ、なお、割り込み管理BIOSを使うようにしてみましたが、結果変わらんですね。

    ただ、Read Trackコマンド成功しますね。セクタ読み込み時間がキャプチャできて、Track Readの結果も取れたらTOWNS実機で取れる情報は多分これですべてになると思うんですが。

    2022-11-09 07:58:37

  • 58 名前: WINDY ID:5YmFiOTRj

    山川機長さん

    うーん、やっぱり現実世界では様々な要素が有って難しいですね。
    uPD71071のデータシートを見たのですが今のところ、"これだ!"と思える記述が発見できていません。
    気になったのはDMAによるデータ転送後にバスフリーを行う処理が有るのですが、この時間が規定されていないようで100msのウェイトの件は此処にかかっているような気がします。
    I/Oの00A9Hのデバイスコントロールレジスタのbit0にBHLDが有るのですが、TOWNSの場合は0(バスリリースモード)で使用している関係でDMAリクエストは実行中のDMA処理が終わった後にしか受け付けてもらえない("無視される"とは書いてないのですが、無視されると思われる)ので、バスフリーが終わらないうちに次のリクエストが入っているのではないかと思われるところです。
    なぜバスフリー処理の時間が明確に規定されていないかについては、ターゲット側(HDD等)の処理時間が係わるからじゃないかと思っています。

    SCSIのデータ転送が終了したかどうかは、データレジスタを見てターゲットがコマンドコンプリートメッセージを送出したかで判断するようですが、SCSIのデータレジスタはアクセスするとACKを送出してしまう事から見ることは出来なさそうですね。

    2022-11-09 09:41:15

  • 59 名前: WINDY ID:5YmFiOTRj

    ↑に色々書いたのですが、SCSIとDMACで混乱してますね。(汗)
    バスフリー処理の時間に関してはDMACのバスフリーはCPUバスに対してだからSCSI側のターゲット側処理時間は関係無いですね。

    CPUバスなので、DMACクロックに対するサイクル数で表現されてそうですが、それがmsオーダーなんてDMACとしてあり得ない数値ですね。
    原因は何だろう・・・

    2022-11-09 10:04:26

  • 60 名前: 山川機長 ID:kOTUyZTA4

    いやあ、でもSCSI書き込み後にFDCが方針してしまうわけなので、SCSIとなんらかの関係があることは間違いないと思うんですがね。ただ、タイムアウトを見てリトライさせたらなんとなく動くようになったので、公開してみました。

    https://github.com/captainys/FM/tree/master/TOWNS/FDDUMP

    ここにソースとバイナリがあります。D77フォーマットでは表現できないセクタ読み込み時間と、Track Readコマンドの結果を保存するために.RDD (Real Disk Dump)フォーマットというファイル形式を勝手に作りました。また、値が変化するセクタは12回マルチサンプルするようになってます。そのままだと津軽や陸奥で使えないので、RDD2D77なるプログラムも書きましたが、いずれ津軽・陸奥で直接サポートしようと思ってます。

    まあ、あの手この手を試しているうちにだんだん複雑になってしまって、Watcom Cのインラインアセンブラを多用しているので、あんまり読みやすくないですが、もしも、何でFDCがときどき放心するのか、気が付いたことがあったら教えていただけると助かりますね。

    なお、津軽と陸奥は.D77EXT (あるいは.D7X)というファイルを.D77ファイルと同じディレクトリに置いておくと、セクタ読み込み時間の情報をそのファイルから読むように作ってあるので、Ys2とかSilpheedとか三国志とか琥珀色の遺言とかプロテクトそのまま再現できるようになってます。今のところ、PaulineとかFDShieldでキャプチャしたイメージから問題のセクタの読み込み時間を計測して手作業で.D77EXTファイルを書いて実験していましたが、このFDDUMP.EXEで作ったディスクイメージからRDD2D77で .D77 + .D7X に変換したディスクイメージは、そのまま陸奥で使えるはず、という予定なのですが、実機によるテストはこれから本格的にやらないといかんですね。

    本当はThexderとかFire Crystalみたいな、木の葉隠れプロテクトも検出してそれも読み込みに対応したいんだけど、Read Addressでタイムアウトが頻発してるっぽいから、ちょっと難しいかもしれんですね。

    2022-11-09 15:58:46

  • 61 名前: 山川機長 ID:wOGU0ZjE1

    なお、FDDUMP.EXE、実機MXで琥珀色の遺言のディスク1のセクタ読み込み時間の計測成功しました!陸奥で起動からチェッカーの通過まで確認できました!

    そうか、あと木の葉隠れに対応できればFM-7系に使われたプロテクトは(伝説の複数インデックスホールプロテクト以外)対応可能になるかな。というか、3.5インチではそもそもインデックスホールプロテクトは存在できないし。なんか考えよう。

    2022-11-10 01:03:55

  • 62 名前: 山川機長 ID:jMjdiMTAz

    木の葉隠れプロテクト、なんと対応できましたというか対応できてました。少なくともMXのディスクドライブだと、Read Trackコマンドでセクタデータが化けないので、Read Trackした結果から解析するとあっさり隠れた本物セクタが見えてしまいました。(というか、なんでFM-7だとRead Trackであんなにデータが化けたんだろう?同じMB8877なのに。)最初Thexderの隠れセクタのうちのひとつがインデックスホールをまたいでいるので取れないかと思ったんですが、それは気のせいで取れてました。これだと、FM-7シリーズのプロテクトは僕の知ってる範囲ではすべてFDDUMP.EXEでキャプチャできますね。

    あとは、ときどきFDCが放心状態になるのが格好悪いのでなんとかできれば完璧なんですけどね。Disk BIOSの動きを見てできるだけ同じになるようにしているつもりなんですが。一応今のところタイムアウトしたらリトライすればほぼ確実に読めてるので実用的には問題無いようです。

    2022-11-11 04:16:10

  • 63 名前: 山川機長 ID:jMjdiMTAz

    FDCの放心問題を解決するためにFM Towns Technical Databookを見直してるんですが、248ページの表 I-7-18の、2HDモードのモータ起動時間、"1000mS以上" って、"以下"の間違いですかねえ。少なくとも1秒かかる、だとあまり有益な情報じゃ無いような。

    2022-11-11 05:56:34

  • 64 名前: 山川機長 ID:hMDgxNzg3

    原因解明!タイマーでした。Disk BIOSの逆アセンブルを見ていたら、最初にタイマーをふたつ解除していたので、試しにタイマーをマスクしてみたらすべてがスムーズに動くようになりました。考えてみたら初期のTOWNSにはDisk Changed BitがI/Oになかったので、タイマー割り込みで定期的にディスクが抜けたことを確認して、そうなったらディスク交換があったと判定していたと思います。最も考えられるのは、そのタイミングでドライブセレクトを0と1に切り替えるのでFDCが止まってしまったの鴨しれません。津軽だとそういえばFDCコマンドを出した後でドライブセレクトを切り替えるという状況は想定してなかったですね。

    ということで、FDDUMP.EXE安定して使えるようになりました。

    2022-11-11 08:45:04

  • 65 名前: WINDY ID:iMGQ3NjY0

    無事解決できたようで安心です。
    タイマーかぁ~、確かにタイマー割り込み先でドライブセレクトされたらと考えると説明がつきますが、ウェイトとの絡み(ウェイトを増やすと安定方向へ行く)がよく解らないですね。
    でも、まあタイマーをマスクしたら安定するのならタイマー割り込み先での処理が原因だったと言えるので、解決ですね。

    モーター起動時間の件は2DDと2HDで違う(と言うか逆)事は無いと思いますので、2HD側の誤植でしょうね。
    3.5インチFDDの資料を何点か見ましたが、1000msって言うのは無くてMAX500msばっかりでしたので1000msってのは搭載するドライブが変更される事を見越して結構な余裕を持たせているのかもしれません。
    ただ、Over1000msってのはあり得ない表現なので。

    2022-11-11 09:30:45

  • 66 名前: 山川機長 ID:hYmRmMzky

    タイマーを増やすとエラーが減るのが、そこがわからんところなんですよね。タイマーと気が付いたのは、MON IOR 200 20F, MON IOW 200 20F とした状態で DIR A: とすると、読み込みが終わって少し待ってから208と20Cにアクセスするような動きがあったので、BIOSの逆アセンブルの最初の方を見たらタイマーのキャンセルの処理があったのでわかった、という感じなんですね。しかし、このタイマーの挙動はBIOSでFDを読んだ後に起こるようで、津軽上ではI/Oを直接いじってる限り再現しないんですよね。何か実機の挙動で解明できてない点があるみたいなんですが、おそらくTOWNS実機を使ってディスクイメージを作るプログラムを書こうなんて人は僕以外にいないと思うので、そこまで解明する必要は多分無いですね。昨日は試しにFM77AV用のマンハッタン・レクイエムのイメージをFDDUMPで作ってみましたが、陸奥でばっちり起動確認できました。どうやら起動中にF6セクタを読んでいるのでチェッカーも無事通過していたようです。

    2022-11-11 23:07:25

  • 全部読む/ 最新50/ 1-100/ 掲示板トップ