| LBAパッチとかWindows2000のパーティション認識とか総合 リウ 2020年11月26日(木) 20:15 |
リサイクル掲示板よりはこちら向けだと思いますので
こちらで続行することにさせてください。
|
| とりあえず… KAZZEZ 2020年11月26日(木) 21:27 |
LBA_IDE.COMの修正版をNr15（/S10）の起動CFに入れてみましたが、
IPLware上で実行すると、OSがまったく起動しなくなるようでした。
起動メニュー（NEC製を使用）は出るのですが、Win98を選ぶと画面真っ黒で止まります。
IPLwareのF押し、もしくは起動メニューの終了でFDDからWin98を起動した場合も同様です。
起動メニューから2kを選ぶと、即座に起動メニューに戻ります。
旧版ではさすがにそんなことは無かったですので、何か深刻な不具合がありそうです。
取り急ぎご報告まで。
|
| ご迷惑かけます リウ 2020年11月26日(木) 21:39 |
  int1bhのAX=0380を最後に送るせいでCFリセットがもう一度発生する環境がありえます。
のでこれをやめます。
ですので固定ディスク起動メニューが呼ぶであろうシリンダ先頭を読む場合はCHS読みせずにLBA変換することにしました。
とりあえずその部分だけ写真にとって追記します。
（日本語おかしかった部分修正）
ただし、おそらく起動したらCFのHSパラメータがデフォルトに戻されちゃっているので…
そのまま起動するとWindows9xのIDEドライバはパッチしなければ16bitに落ちてしまうと思います…。
緊急報告した方も改変部分を…
22:16
バイナリも同じファイル名でアップロードしておきました。
起動できたなら直後にメディア側のHSパラメータの確認をお願いします。
8:17になれていないなら困りますので考えます。
22:43追記
やばいバグでしたのではやめに治します。上記のことはあまり関係ありません。
CHS読み（書き込みもです）をした場合Nw133ですべて！！LBA0番に変換されていました。
2700h系だとどこかでこわされているのではやく探します。（追記8G壁機全般の問題でした。）
23:12→23:14再アップロード（ごめんなさい…）
8G壁機種用の計算準備部分が飛ばされてしまっていました。
4G機と同じ計算をするようにしたのにその準備をしていなかったのでLBAに変換できずに壊れていました。
Nw133で実機確認しなおしました。
ご迷惑かけます。報告ありがとうございます！
何度もダウンロードしてもらうことになって申し訳ないです。
このように私のログだらけになりそうなので移動してもらいました。
すみません。
|
| なぜかHS_PARAの設定ができていませんでした。orz KAZZEZ 2020年11月27日(金) 3:32 |
修正ありがとうございます。結論から言うと起動できました。
当方の環境でうまくいかなかった原因は、
なぜかスレーブ側のCF(32GB・FAT32のSD変換)のHS_PARA設定ができていなかったためだったようです。
これを設定しなおしたらうまく起動するようになりました。
参照先のパラメータが不正だったのでOSが起動できなかったのかもしれません。
FAT32を扱えないMS-DOSでは起動できたので気付きました。
それでも謎は残ります。
スレーブ側のパラメータは最初に試したときに設定していたはずで
(4.3GB以上32GB以下なので16:63のネイティブパラメータです)
それ以降パーティションは一切いじっていないはずなのですが。
2kのパーティションですので、何らかの拍子にH:S設定が消えたのかもしれません。
# それともLBA_IDEのバージョンが変わるとHS_PARAの記録位置も変わることがあるのでしょうか？
一方の、4GBのCFのほうは頻繁に領域をいじったのでしょっちゅうH:S設定が消えていました。
パラメータ変更後は当然ながら領域サイズや内容が狂うので領域を確保しなおすのですが、
そうなるとHS_PARAで設定をやり直さなければならないのは
慣れないうちは忘れやすいので警告が必要かもしれません。
それでパラメータですが、
4GBのCFは8:17の標準設定にしてあるのですが、IPLwareでLBA_IDE実行後は
なぜかIDEINFが16:63（ネイティブと同じ）を返しました。
例によってFORMATXやCONV98ATでの表示は8:17のままですので、実際は8:17だとは思うのですが。
BigDriveパッチはまだ適用していませんが、この場合はWin98（無印）でもスタンダードIDEコントローラに（！）が付いてしまい、
認識したドライブがMS-DOS互換モードで動いています。
LBA_IDEを使わない場合は（！）は付きません。
----
そういえば再現性は無かったのですが、
パーティションやスリープ設定をいじっていると何らかの拍子に
IPLwareが全部消えていることが何度かありました。
HS_PARAのH:S設定もそうですが、
CFはHDDとして使うと先頭のほうのデータが消されやすいんでしょうかね？？
|
| 想定している現象とそうではないこと リウ 2020年11月27日(金) 6:12 |
># それともLBA_IDEのバージョンが変わるとHS_PARAの記録位置も変わることがあるのでしょうか？
設定場所はLBA1番のオフセット0Chの第一パーティションの終了ヘッドセクタ（windows2000以外では自動で0になるもの）の流用です。
場所は決めてからは変えていません。
ただしフォーマッタが第一パーティションを作ると必ず消去されてしまいます。
ここは注意喚起が足りませんでした。パーティション操作を行ったら再起動前にHS_PARAで設定の確認はしないといけません。ユーザーフレンドリーではないので考えます。パーティション操作でいじくられないはずの場所として考えているのはLBA2番の空き領域に2byteもらうことですが場所決めには慎重になっています。
スレーブ側のその設定が意識していないタイミングで消えた、というのはわかりません。が、そういうことが起こってもよいように考えます。
>IPLwareでLBA_IDE実行後は
なぜかIDEINFが16:63（ネイティブと同じ）を返しました。
なぜか？これがCF特有の現象です。デバイスのHSパラメータがふとしたことがきっかけでネイティブに戻ります。私もなぜかを知りたいです。（IO74Chの操作は原因の一つです。）とにかく起きてしまうので起きてもかまわないようにLBAでのアクセスにBIOSを改造することに決めました。
以前のバージョンでは設定したHSになっているかどうか確認してcommand91hを送り続けていました。一度この方法にも戻ってみようと思います。（ただしそうすると規格からは削除された機能に非対応のデバイスで無限ループということにもなってしまいます。）
またconv98atやformatxで表示されているのはBiosパラメータの方のヘッドセクタ値で、DOSを使っている間はもはやCHSをLBAに変換するときの計算に使われるだけになったものです。デバイス側の設定と一致していなくてかまいません。（CFリセットは起こるものとして想定しています。）こちらはD800:2700に保存されている値を表示しているだけです。ただしwindows9xやNTのドライバはここが一致していないと（普通は一致していますし一致していないとCHSアクセスに正確さが保証できません。）文句を言ってきます。
最後のIPLwareが消えるというのは書き込み内容が以前の状態に戻る、という現象でしょうか？
実は私も一度経験しています。色々書き込んだ内容がリセットとともに消える、ではなく戻る、という不思議なことがありました。
私の場合は新しくいれたはずのIPLwareプログラムが古いままだったということがありました。
パーティション操作をわざと何度もやるのは大変ですが試してみます。
追記
ここもHS設定が飛ぶことによるものの気がしてきました。プログラム保存場所はシリンダ1番よりも前の位置ですが、結局デバイス設定が変われば書き込む位置が変わってしまいます。
まずプログラムを分けて（91hに非対応かもしれないので）BIOSパラメータとデバイスパラメータを一致させるものを作っておこうと思います。
27日追記
作りました。
re_HS.comというものを同梱しました。IPLwareとして実行してもいいですし、DOSから実行してもかまいません。ただしいつもどおり何も表示しません。
何度か取り直しをさせてループしようとしましたがどうも私のプログラムがダメで一度だけの実行にしました。
デバイスパラメータがBIOSパラメータに一致しなければ何度か実行してみてください、すみません。デバッガから実行するとなぜかうまく行くようです。
># それともLBA_IDEのバージョンが変わるとHS_PARAの記録位置も変わることがあるのでしょうか？
変えました。
MBRの2byte目と3byte目にある9090hの無意味と思われるものが入っている場所を奪いました。パーティションをいじくってもここは変更されないと思います。
WindowsとMS-DOSは大丈夫でしたが、この位置は怖いので暫定的とさせてください。
|
| ATAコマンド91hは規格から削除されたので実装が無いのを前提とすべき かかっくん 2020年11月28日(土) 2:50 |
> なぜか？これがCF特有の現象です。デバイスのHSパラメータがふとしたことがきっかけでネイティブに戻ります。
此れが所謂『CFリセット』です
キチンと実装されていないからCFのコントローラがバグってハードウェアリセットが掛かるのかも知れません。
此のコマンドを遣うよりネイティブCHSを遣うかBIOS内で8:17と変換する方が良いかも知れません。
# でも気になるのは一旦通ってCHSが変更されたのが何かの拍子に元に戻る事も有るんですよねぇ
ちなみにまりもさんが指摘していますが此のコマンドはATAの仕様ではobsoleteなので実装が有るのを前提と
しては逝けません。無いのを前提とすべきで遣うべきでないでせう
(『強制リムーバブルのCFで2kを動かす。』スレ参照)
ATA-1 199x年 9.12 29ページ(PDF48ページ)
ATA-2 1996年 7.18 45ページ(PDF61ページ)
ATA-3 1997年 7.11 61ページ(PDF75ページ)
ATA/ATAPI-4 1998年 8.16 108ページ(PDF124ページ)
ATA/ATAPI-5 2000年 8.16 120ページ(PDF134ページ)
ATA/ATAPI-6 2002年 削除(obsolete)
ATA/ATAPI-8-ACSのxxvページ(PDF25ページ)
web.archive.org/web/20091211135449/www.t13.org/Documents/UploadedDocuments/docs2008/D1699r6a-ATA8-ACS.pdf
に
> 4) In table B.2 and table B.3, opcode 91 is listed as reserved instead of
> obsolete. This was INITIALIZE DEVICE PARAMETERS and was obsoleted when CHS was removed from ATA/ATAPI-6.
と有ります。仕様として削除されたので遣っては逝けないやうです。他の方法をとりませう
SD-CFコントローラFC1307Aのやうに、内部処理としてはサポートして居ながら常に16:63を返すやうなヘンテコな
実装の石も有ります。
ATA/ATAPI-8-ACSによると、CHSアクセス自体もobsoleteになっています(4ページ・PDF48ページ)。
CHSアクセスの実装もおざなり・なおざりでも通ってしまうんですな、今では!
> 3.1.18 CHS (cylinder-head-sector): An obsolete method of addressing the data on the device by cylinder number, head number, and sector number.
実用面ではもっと優れた代替案(SD-IDE)が有る以上CFにこだわる理由が有りませんから、CFの使用は研究用途に
留めて措いた方が良さそうでせう
と云うワケで研究です。D3765のやうに此のコマンドを実装していないドライブではどのような処理になりますか？
D3765ではCHS決め打ち(特定の1機種だけなら此れでも通る)なら応用は利きませんが、然うでなくネイティブ
CHSで動くなら其の処理をデフォにするのでも使えると思います。
結構出ていますね
page.auctions.yahoo.co.jp/jp/auction/r375856743
page.auctions.yahoo.co.jp/jp/auction/g353532458
T13のURLが
www.t13.org から
www.incits.org/committees/t13
に変わったやうです。過去ログのURLでは読めませんのでご注意
|
| 補足ありがとうございます リウ 2020年11月28日(土) 10:43 |
＞此のコマンドを遣うよりネイティブCHSを遣う
HSパラメータは使用者に決めてもらうようにしています。
しかしやはりCFを使うかぎりはメディアデフォルトの値を強くおすすめします。（きちんとパラメータ変更できないプログラムを提出している私が悪いのですけれど）
SSD（とSATAからIDEへの変換アダプタ）は買ったのですがまだまともに接続すらしていないので年末はこれで遊びます。CFリセット的なことが起こるのかどうかまだ報告が少なすぎて面白みがあります。
＞# でも気になるのは一旦通ってCHSが変更されたのが何かの拍子に元に戻る事も有るんですよねぇ
この原因さえわからないのでLBAでアクセスさせることが一つの対策だと思っています。
＞CHSアクセスの実装もおざなり・なおざりでも通ってしまうんですな、今では!
そういうことですから、現在売っているものがIPLware段階まで到達できればアクセスできるようにしました。（そもそも内蔵IDEはもはやノート型でしか使わないとも思いますが…）
WinドライバがどうせCHSで来ますのでそこにも問題があります。
まだ現段階ではLBAでのアクセスがそもそも正確かどうか確かめている段階です。
CFでデータが破壊されなくなったかどうかはロングラン運用してみて確かめるしかありません。
ただ私はこれでいけると思って取りかかっています。
＞もっと優れた代替案(SD-IDE)が有る
もはやCFも店頭にはありませんからおっしゃるとおりです。
>91hに非対応のデバイス
プログラム内ではデバイス側のパラメータは気にせず（つまりパラメータリセットが起きてもよいし、1:1~16:255どの状態でも関係がなく）BIOSで決めた方のパラメータを計算に使ってLBAでデバイスに渡します。
それをHDD側が受け付けるかどうかだと思います。
windows98Se用ドライバ
CHS判定をつぶしたものを同梱せずに以前に作っていた48bit対応させただけのものが入っていました。入れ替えておきました。もしすでに試されていたら無意味な時間をとらせてしまい申し訳ないです。
ついでにWindows95B用のK6対策ドライバとそれの改変も同梱しました。
さすがにこれを入れてももういいと思いました。が、ダメと指摘されたらパッチファイルだけに戻します。
NT用LBAドライバはuniataというフリーソフトの移植に関わろうか（ちょっかい出してやろう）と思いたった段階でまだ取りかかってすらいません。
|
| お返事とか。 KAZZEZ 2020年11月28日(土) 20:31 |
> re_HS.com
ありがとうございます。
昨夜のバージョンではIPLware登録するとビープ音が鳴り響くだけでしたのでAUTOEXEC,BATに登録してみましたが、
どうにかWin98のデバイスマネージャから（！）が消えました。
最初はre_HS.comだけ適用してみたのですがWin98のレジストリやファイルがエラーを返したり不安定でしたので、
HS_PARA2と新しいLBA_IDEを適用したらとりあえず安定したみたいです。
> windows9xやNTのドライバはここが一致していないと（普通は一致していますし一致していないとCHSアクセスに正確さが保証できません。）文句を言ってきます。
この意味でも本当はメディアデフォルトCHSが望ましかったみたいですね。
ただFD起動時にまったくHDDにアクセスできないと仮想FDを使ったソフトなどが使えなくなったり
トラブル時のメンテナンス性もありますから今回はBIOS標準（8：17）にしておきました。
まあ…それはそれでFD起動時にCFリセットで不正アクセスする心配もあるわけですが。
> 設定場所はLBA1番のオフセット0Chの第一パーティションの終了ヘッドセクタ（windows2000以外では自動で0になるもの）の流用です。
そういえばスレーブのCFに設定しなおしたときに現在値として00と表示されたような気がします。
0ヘッド0セクタとして扱われたとすれば、そりゃアクセスできませんよね。(^^;)
Win98というかDOSは起動時に認識したHDDすべてにアクセスしてから起動しますから、
このときWin98が止まってしまっていたのではないかと思っています。
この状態でも旧版のLBA_IDEでは（デフォルトパラメータで）認識できていましたので、
仕様変更の影響だったのかもしれません。
> 最後のIPLwareが消えるというのは書き込み内容が以前の状態に戻る、という現象でしょうか？
というよりローダも含めてぜんぶ消えていました。
ローダがないので新しく組み込みますと言われました。
ただ、それとは別に2つの異なる状態を行き来するような状態になったことはあります。
内容は同じはずなのにDIRコマンドで表示されるファイルの順番が異なっていましたので
何か別のアロケーションテーブルを参照していたのかもしれません。
> windows98Se用ドライバ
これも（旧版を）適用してみましたが…
SEでない初代Win98でもSEのファイルを用いてとりあえず動いてはいるようです。
# なにか不具合があっても文句は言えませんが。
(追記)
不安定な挙動が再発したので、切り分けのためにしばらくedsi_506のパッチ使用は控えてみます。(汗
> もっと優れた代替案(SD-IDE)が有る
とりあえず今回は以前買っておいたSD-CF変換を使いましたが…どうでしょうね。
いちおう2k上ではHDDとして認識しています。それで安定すると良いのですが。
個人的に以前から所有している（デスクトップ用の）SD-IDE変換のたぐいは
128MB制限や2GB制限のあるものばかりでしたが、CF変換で32GBのSDが認識できて良かったです。
> もはやCFも店頭にはありませんからおっしゃるとおりです。
たしかに2、3年前まではスーパーでも見かけたのですが最近めっきり見なくなりました。
ハードオフやブックオフで中古の出物を注意しておきたいですね。
秋葉原ではかろうじてまだ売っているところもあるようですが、同容量のSDの数倍は高く、
やはり値段ではmini-SDが一番安いですので、変換で使えるならそのほうが便利です。
しかし秋葉原でも肝心のSD-CF変換は見かけなくなった気がしますので
いずれCFに変えて運用できればそうしたいと思っています。
ノート機の内蔵スペースで2枚内蔵させやすいですし
スレーブ認識なら4.3GB壁を越えられますし。
SD-IDE変換の現行製品も機会があれば探してみようと思っています。
|
| 8:17の重要性 リウ 2020年11月28日(土) 21:35 |
re_HS.comだけアップデートしました。
どうやら手元ではIPLwareとしてもうまく動くようになったようです。
ご迷惑かけます…。
91hにも時間待は必要なだけでなくidentifyコマンドも時間待ちしないとデバイスが暴走してしまうようでした。
やはり4G機での8:17の重要性からは逃れられないので準備致しました。
さらにFreeDOS(98)のCHSアクセスがどうやらBPB内のHSパラメータを使っているということがわかりました。これがメディアパラメータと一致していないとおかしくなるようです。ご注意ください。
＞98側では少なくともMS-DOSのシステムではBPBのこの場所が積極的に参照されることがないようです（他のOSはどうでしょう？）。
まりもさん宛ですが先ほどソースを見てみたらFreeDOS(98)はここを見てるような気がします。
12月2日追記
FreeDOSのsys.comでLBAモードにすることができます。
sys config GLOLBA=1
sys config FORCELBA=1
と設定することでLBAパッチを当てた後も問題なく読み書きできるようです。
一応これで対処することとしてください。
パラメータが設定されていない場合4G機では8:17を押し付けることにしました。今まで使っていたものが突然起動しないとなるのはこの状態だと思われますので。
しかし日刊で改版しているのでとても申し訳ない気持ちです。
>ビープ音が鳴るだけ
ほかのIPLwareプログラムもLBAパッチ使用後に同じことが起こるかもしれません。
それならIPLwareのローダのほうが出すchksum不正エラーだと思います。
HDD(CF)のパラメータを変えたあとのプログラムの呼び出しを失敗していると思います。
こちらでは起きなくなっていたので失念していました。win9xではautoexec、NTならHSBすることで暫定的に対応お願いします。
12月2日追記
待ち時間が問題と思ってLBA_IDE内でも大量の待ち時間を設定してみましたが
手元のCFはやはり91hがうまく通りませんでした。タイミングだとは思うのですが…
|
| KAZZEZ 2020年11月29日(日) 0:39 |
とりあえずre_hs.com 11/28 21:02のバージョンに入れ替えてみましたが、
Nr15上でIPLwareでの挙動は同じで、ビープ音が鳴るだけみたいでした。
環境によって条件が違うとなると、なかなか難しそうなのですね。
# また私の勘違いでなければ良いのですが…。(汗
Win98を使う分にはAUTOEXECで問題無さそうです。
> 私の場合は新しくいれたはずのIPLwareプログラムが古いままだったということがありました。
私の場合はたまたまFDやHDDに入っていたIPLwareローダを使ったら、かなり古いバージョンだったことがありました。(ぉ
# FDからDOSしか起動できないような整備中のPCでは、ファイルを持ってくることが面倒なので、よくあります。(汗
途中からIPLware 3.61に入れ替えて使っています。
----(12/1 追記)----
よくよく考えてみれば、LBA_IDEはIPLwareの最後に登録しなければならなかったのですね。
LBA_IDEよりも後にre_HSをIPLware登録したから失敗していたようです。
パーティションをいじっていたらまたIPLwareローダがまるごと消えてしまい、
組み込みなおす際にまちがえてLBA_IDEより後に拙作TIMEDATEを組み込んだら
やはり同じようにビープ音が鳴り響くだけでしたので気付きました。(汗
ビープ音が鳴り響くのはIPLwareローダ側の仕様だったようですね。
re_HSの機能はLBA_IDEに組み込んだほうが良いかもしれませんね。
(さらに追記)
どうも(Win98の)FDISKでパーティションを変更したり、状態の変更を行うと
IPLwareがローダごと消えてしまうようでした。
当然でしょうけどACTVPTNやBOOTPTNで変更する分には大丈夫なようです。
|
| IPL wareが消える件/BPB まりも 2020年12月1日(火) 11:45 |
旧バージョン（3.xx）のIPLwareを使ったからといって消えることはないと思います。Windows9xのFDISKを実行すると何かの拍子で消されます。FDISKは古いMBRや起動メニュー見つけるとそれを書き直しに行きますから。PC/ATでもそうですが、今や純正FDISKは百害あって一利なしなしといっていいでしょう。
それ以外としてはCFを使っていればCFリセット問題ですが、それでもリセット後に見えなくなるだけで、存在が消えることはないはずです。なんらかのファームウェアが98と関係なくデバイス内で走っている物（SD変換、なんちゃってSSD）だと消されるかもしれませんが。
＜2020-1-11追記＞それがCFスーパーリセットですか
BPBにあるBIOS H:Sの問題ですが、FreeDOSが参照しているとすると困りましたね。FreeDOS（98）の方はそこを改変して回避できないものかと思います。PC/ATではファームウェアやら BIOS自体がガッツリそこをいじりに行きますし、Windows 2000、XPのブートローダーもそこ見てますから、「参照するな」とは言えません。だから98側では、98での状態と異なってでもPC/ATで都合が良い値（まあ255:63）を書いておきたいところです。
|
| メニューのバージョンとFDISK かかっくん 2020年12月2日(水) 3:36 |
> HSパラメータは使用者に決めてもらうようにしています。
> しかしやはりCFを使うかぎりはメディアデフォルトの値を強くおすすめします。（きちんとパラメータ変更できないプログラムを提出している私が悪いのですけれど）
此のユーザ定義のH:SとLBAをBIOSで変換してデバイスにはLBAを渡す仕様なら殆どのHDD・粗全てのCF/SSDで
動くと思います。初期のIDE HDDでCHSしか通らない物についてはネイティブCHSを渡せば良いでせう
残骸が残る位空きが有るのですから問題無く実装できそうな気がします。
> 手元のCFはやはり91hがうまく通りませんでした。タイミングだとは思うのですが…
91hで任意のH:Sを押し付けてから割り込み禁止してポーリングでキー待ち（此の間は他の処理は一切されない）を
して改めて調べてみるとどうなりますか？
キー待ちなら長時間待てますから、其れで消える(ネイティブに戻るか異常値になる)やうなら91hは使えないと云う
事になります。コマンド自体は通るのが厄介です
> 旧バージョン（3.xx）のIPLwareを使ったからといって消えることはないと思います。Windows9xのFDISKを実行すると何かの拍子で消されます。FDISKは古いMBRや起動メニュー見つけるとそれを書き直しに行きますから。PC/ATでもそうですが、今や純正FDISKは百害あって一利なしなしといっていいでしょう。
メニューについては判別子(0FCh)のバージョンを7Eh辺りにしておけばM$/みいそ窓9xのFDISKでも上書きされ
ない気がします(えぷ窓95は其の限りでない？)。IPLwareのインストール時にバージョンを書き換えて、アンインス
トール時に元に戻すとか？
BPBのH:SをFreeDOSが参照して居るそうですが、(98)は表示が1-0-0になって居<del>てちゃんと参照できて居ない
気がし</del>ます。
最初の領域を1-0-0からとるのは当然ですね
page.auctions.yahoo.co.jp/jp/auction/l635029658
aucview.aucfan.com/yahoo/l635029658/
auctions.c.yimg.jp/images.auctions.yahoo.co.jp/image/dr000/auc0111/users/074099936b776180acde725f3e1ed5f02edb8b28/i-img1200x900-1604538667sqxnp14812.jpg
|
| デバイスパラメータ リウ 2020年12月2日(水) 23:24 |
 色々やってみましたがうまくいきません。
re_HS.comではそれなりにうまくいくのでそれにまかせることにします。
＞91hで任意のH:Sを押し付けてから割り込み禁止してポーリングでキー待ち（此の間は他の処理は一切されない）をして改めて調べてみるとどうなりますか？
やってみました。どうやら時間待は関係なかったようです。結局二台目に触りに行くまでに1台目の設定が飛ぶようでした。2台目に触らせなければ1台目の設定は残っていました。
（パラメータ設定部分をInt1Bhで読みにいく場所とset transferしかしてない（つもりな）のでどちらかがダメなのでしょう…)
ルーチンを変えてパラメータを全部読んでから一気に91hを送るとre_HSと同じ手順になるので通るようになるとは思います。後回しにさせてください。
結局最後に触ったものだけが正確っぽいのでプライマリマスタを最後に触るようにループを変えました。
しかし調べる前の手元のバージョンではスレーブへのパラメータがマスタに飛んでいくというとんでもないバグを残していました。いつものことですが自分の頭のデバッグが必要です。
＞残骸が残る位空きが有るのですから問題無く実装できそうな気がします。
とても古いHDDを使う用事の人はこのパッチは必要なさそうな気が…もし簡単に判別できそうなら取り組んでみます。
＞BPBのH:SをFreeDOSが参照して居るそうですが、(98)は表示が1-0-0になって居てちゃんと参照できて居ない気がします。
これはパーティション先頭位置のシリンダ番号とヘッドセクタ番号が書かれているものです。シリンダ境界から始まってるのがはっきりわかります。
BPB内のパラメータはここには表示されません。
|
| SD変換とかFDISKとか。 KAZZEZ 2020年12月3日(木) 0:52 |
Nr15にてスレーブ側でCFに変換して使っていた、HIDISCの安物microSD(32GB)が壊れました。
幸いにも初期不良交換の期間内でしたが、壊れるのが早いですね…。
Nr15は配置的にHDDが排気ファン（CPU？）に近いので熱にやられたのでしょうか？
安物だったせいもあるかもしれませんが、あまり頻繁に読み書きする用途には向かなかったのかもしれません。
どうやらSD変換も万全ではないようです…。
# CFも同じでないとは言い切れませんが。
そんなわけで現在、マスターのCF（強制リムーバブルの4GB）だけで慎重に運用していますが
この構成ですとLBA_IDEの待ち時間がちょっと長い（8秒くらい？）ようですね。
また、DOSモードで起動すると、AUTOEXEC.BATでre_HSを実行した後（8:17）であるにもかかわらず、
FDISKで領域確保するときにCFリセットが起こることが多いようで、
「ドライブをチェックしています・・・」が100％になる間に、かなりCFに負担が掛かるみたいですね。
IDEINFで見ると16:63に戻っています。
やはりAUTOEXEC.BATで実行するのはタイミングが悪いのでしょうか？
この状態ではディレクトリも正しく見えていないことが多く、Win98を立ち上げれば当然エラーです。
ただ、その状態でもう一度re_HSを実行すると安定することが多いようです。
4GBのCFをFAT16で2GBだけ確保していますので、
残りの2GBをFDISKで領域確保するフリだけしてキャンセルすれば、IPLwareは消えません。
この環境では24％でいったんカウントが止まり、しばらくしてゆっくりカウントが動き出すことが多いです。
re_HSの再実行後は、FDISKの領域確保でも高速でカウントが進むようになります。
今のところ、必ずその手順で安定を確認してから、Win98のGUIを立ち上げるようにしています。
(追記)
新しいLBA_IDE.COMをIPLwareで置き換えましたところ、
FDISKを実行しなくても安定するようになりました。
ときどき上記のディレクトリが正しく認識できないような状態になっている事がありましたが、
そのような時はそもそもCFから起動できず、待ってもI/Oエラーになるようでした。
（特にNOTEベイにFDDを入れているときに起動できないことが多い？）
> Windows9xのFDISKを実行すると何かの拍子で消されます。
ありがとうございます。やはりそのようなことがあったのですね。
# この前の、再現性無くIPLwareが消えた件もその影響だったのかもしれません。(汗
FDISKを使って実験する場合は、IPLwuniあたりで複数のIPLwareの一括バックアップをして
一括で書き戻しをできるようにしておくと良さそうですね。
あるいはFDISK代替ツールに期待でしょうか…。
|
| LBAアクセスでも起きてる… リウ 2020年12月3日(木) 7:15 |
>ディレクトリが正常にみえていない
想定外です。そうならないためのLBAアクセスですので。
re_HSを使うと一見正常に戻せていたということからパッチがあたっておらずにCHSで読み書きしているように思いたいですが、
チェッカがありませんね…。
まずそれも作ろうと思います。
scandiskしてみて壊れていると出るならこの方法はCFリセット解決には全く役に立たないものということになります。
11:34追記
忘れていましたがFDISKはCHSでパーティション操作を行っています。
現行のパッチではシリンダ境界以外へのCHS読みに対してはそのまま素通しでCHSで渡します。（Windows9xプロテクトモードドライバのチェッカのため）
FDISKを行う時にはメディア側のパラメータがBIOSパラメータと一致していないと読み込みに対して結果がおかしいことになってしまいます。ベリファイが全部エラーを出してると思います。（それでも通すのがfdiskですが）
二枚挿しするとなぜかCFリセットが起こりにくくなることは以前にも報告したのですがこれも原因がよくわかりません。
DOSモードのことを書き忘れていました。
GUIに入ってからDOSモードで再起動をやってからexitでGUIに戻ろうとするとCFではかなりの確率で失敗します。PCMCIAにATA-CFを挿しているとなぜか戻りやすくなるようですが、その時に一部のパーティション認識が狂っていました。
実験中のSSDでは戻れましたのでこれも不可思議な現象です。
緊急報告！！！
書き込みに対してLBAでアクセスさせるはずがCHSのIO操作になってしまっています。
つまり今の状態ではBIOSを使って書き込みを行うとCHSでアクセスしてしまいCFリセットが起きているととんでもないアドレスに書き込みが起きます。
ファイルシステムを確実に壊します！！ 使用を止めてください。
メディアパラメータがBIOSパラメータと一致していないと確実に壊します。（修正）
本当にご迷惑かけます。
場所はFunc_DA_part2内の
cliです clcと間違えていました。
たまたまキャリーがクリアされている状態でここにたどりつくときだけLBAに変換されていたようです。
なので読み込み時もLBAでアクセスできていない可能性がありました。
精査ありがとうございます、とともにこちらの不手際が多すぎて破壊原因を作ってしまい申し訳ないです。
12月5日
削除していた状態から再アップロードしました。
re_HSの機能を内包しました。エラー処理がひどかっただけでした。
プライマリ側の２枚に対しては動くようになったと思います。
セカンダリと合わせて4枚までは試せていません…。
窓ドライバ
9xはINT1bのsenseからもらったパラメータでアクセスしようとします。
起動時にチェッカを通しデバイスパラメータが一致してないような素振りを感じるとロードをやめます。
ロードできたならアクセスエラーが起きるとすぐに91hを送ってパラメータを戻そうとします。
8G壁機やexide適用後だと任意のパラメータで使えます。
8:17に固定するようなルーチンも見た気がしますが、ATAの規格内であるならどのようなパラメータでもアクセス可です。
ちなみにPCMCIAに挿したものはメディアデフォルトのパラメータでパーティションを探しに行きます。（8:17で切ってしまったものは普通は読めません。）
NTのドライバは起動時のメディア側のパラメータでアクセスします。
パーティションが普通はBIOS側の設定で作られているので一致していないと認識不可です。
2000だけは特別で98型のパーティション認識はBIOSパラメータを使って、アクセスにはそのときのデバイスパラメータを使います。（おそらくいちいちそのときのパラメータをidentifyで確認してCHS変換してます。）
これらのドライバに対応するためだけに起動時の91hに拘ってました。
ですが32GBまでのCFではHS_PARA2でメディアデフォルトの値を設定して欲しいです。（設定しているのはint1bのsenseで返すほうです。）
これでも98IDEでは使えないという結果が出るのか、これならなんとか通用するのか？
という実験の部分が強いです。
6日昼追記
# そもそも標準の8:17に設定してあるのに、IPLwareを介さないで（つまりLBA_IDEを経由しないで）FD起動すると、
なぜかディレクトリが正しく認識できていません（一部のファイルやフォルダが見えない？）。仕様でしょうか？（よく理解しておらず、すみません。）
状況説明ありがとうございます。パッチしないと読み書きできないのはその時点でもうCFリセットされています。メディアのほうのパラメータを確認すると飛んでる（16:63に戻されてる）と思います。
使い物にならないタイプのCFと機種の組み合わせでは本当にすぐリセットされてしまいます。
|
| TLCやQLCのSDの耐久性は かかっくん 2020年12月5日(土) 19:39 |
> 安物だったせいもあるかもしれませんが、あまり頻繁に読み書きする用途には向かなかったのかもしれません。
> どうやらSD変換も万全ではないようです…。
TLCやQLCのSDの耐久性は数百〜1000回程度の書き換えだそうです。
小さい程チップ数が少なくなり不利になります。μSDでなくフルサイズのSDが良いです
使用毎にイメージバックアップが良さそうです。
91hについてはエラーを返さないだけの間に合わせの実装しかして居ない気がします。で、他の事をすると忘れる
ワケです。CFリセットの真相はこんなモンなのかも？
原因追及も必要かもですが、原因を追及して避けるより元から遣わない実装のが良さそうな気がします。
BIOSや窓のDRVをちゃんと読んで居ないので解って居ませんが、CHSを求める際に8と17は固定値で計算して
居ますか？其れとも何処かの値を参照して居ますか？後者ならネイティブCHSでも遣えそうな気がします。
8G機のBIOSでは8:17とネイティブCHSが併存して居るので固定値でないのは明らかですが、窓のDRVは
どうなんでせう？8G機用のうpdとか有りましたっけ？
或いはユーザ定義H:Sの値を何処かに保存しておき、其の値が未定義だったら初期値の8:17と見做しデバイスには
ネイティブCHSかLBAでアクセスするのが良さそうな気がしますが、BIOSを遣わないOSのDRVは別途必要に
なりますねぇ
窓9xやNT4/2kのDRVは必要として、BSDとかOS/2・LinuxのDRVは何とかして下さい、とか？
|
| 安いmicroSDで2k運用すると一週間で壊れるということですね。（汗;; KAZZEZ 2020年12月6日(日) 1:29 |
> TLCやQLCのSDの耐久性は数百〜1000回程度の書き換えだそうです。
なるほどやはりそうでしたか。検索するとそういう話はたくさん見付かりますね。(汗
どうせなら高耐久性を謳うドラレコ用が良さげですかね。
それでも同容量のCFよりは安そうですので。
もともとmicroSDを使ったのは大容量の認識実験のためで、
前述の通り、ある程度の期間の安定動作が確認できればCFで運用するつもりでした。
一応、壊れたmicroSDは別のメーカーの製品に(差額を払って)交換してもらったのですが、
今回のレベルの安物microSDで2kの起動実験を繰り返すとなりますと
一週間も持たないことが分かりましたので、
認識のテスト以外ではおとなしくCFで試そうと思っています。
# 今のところCFは8GB以下しか持っていませんが。
# それともドラレコ用のSD買うか…？
> 破壊原因を作ってしまい申し訳ないです。
いえいえもちろん安定するまでは重要なデータは入れませんし、
基本的にバックアップは取っておりますのでご心配なく…。
# 今のところ既存のHDDの丸コピーとか、OSだけインストールした程度のものです。
少なくともSDのほうは（壊れる以前は）ネイティブパラメータで安定して運用できておりましたので
故障原因とは関係なかったと思われます。
> re_HSを使うと一見正常に戻せていたということからパッチがあたっておらずにCHSで読み書きしているように思いたいですが、
そういえば現在の件の4GBのCF（Win98運用）の状況では、LBA_IDE適用後に
適当に安定したときを見計らってDRVCPYでドライブごとバックアップを書き戻したものなのですが、
ESDI_506.PDRにLBAパッチを当てるとGUI起動時にかえってエラーが出るようになりました。
# 某セキュリティソフト起動時に、ファイルが不正で実行できない旨を警告されます。
元のESDI_506.PDRを使えばエラーは出ません。
単にWin98無印にSE用のESDI_506.PDRを適用したせいかもしれませんが…
それでも以前は必ずしもエラーが出なかった気もしますので、
もしかしたら想定されていないドライブ認識(CHS状態?)でフォーマットされた状態になっているのかもしれません。
# そもそも標準の8:17に設定してあるのに、IPLwareを介さないで（つまりLBA_IDEを経由しないで）FD起動すると、
なぜかディレクトリが正しく認識できていません（一部のファイルやフォルダが見えない？）。仕様でしょうか？（よく理解しておらず、すみません。）
LBA_IDEの新しいバージョンはまだ試していないのですが、
念のため現状のバックアップを取ってから
LBA認識で正しくフォーマットしなおしたうえで書き戻したほうが良さげですかね。
|
| 逆の発想 まりも 2020年12月7日(月) 18:59 |
IDE BIOSでEXIDEを使った場合に限られますが、CFデバイスについては通常のH:S決定ルーチンに行かずに16：63かメディアデフォルトなH:Sで返すという手もありますね。CFリセット来るなら来いで。CF利用者はConv98AT変換でPC/AT直付けもするでしょうから、どんな容量でも16:63にしておくほうが都合は良いです。といっても32255MiBまでですけど、CFには十分でしょう。
さてidentifyで読んだワードのどこを見ればCFだと見破れるかですね。リムーバブル属性なら問答無用でCFでいいと思いますが、fixedのもあるので。CFAサポートあたりでよかったですかね。SDからのなりすましCFはどう対応するのが良いのか。モデル名称チェックで、CFリセット起こさないことが既知のはHDDと同等にするなどもあるといいかもしれません。
＃ミイソBIOSにある古いHDDの名前リストのデジャブ感がありますが
＜12月8日追記＞やってみたところH:Sのリセットには確かに耐性つきます。しかしその他の設定もデバイスリセットされているかもしれないので問題無しとまでは言い切れません。
|
| エラー処理 リウ 2020年12月8日(火) 13:13 |
>待ってもIOエラー 起動できない
原因はデバイスの暴走です。私のプログラムのIDEへのアクセス方法がへたくそなので（スレーブにつないでないと起動が遅くなるのもそうです。）
プログラム終了時点でIO64Ehの返事がFFになってしまうことがあります。
こうなるとATAリセット（IO74Chへ6をアウトしてある程度待ってから0をアウト）しないとIDEへの応答が全て死んでいます。
で、ATAリセットするとほとんどのCFではだいたいパラメータが飛びます。
一応今のバージョンですとそのエラー処理を見直したのですが（アップロードしたかの記憶がありません…）、それでも起きてるならもう一つチェッカを足します。
|
| その後の状況。 KAZZEZ 2020年12月9日(水) 19:38 |
先日、12月5日バージョンのLBA_IDEに入れ替えてみました。
Win98のパーティションをフォーマットしなおしたうえで
元のドライブのデータをDRVCPYで書き戻したところ、
LBAパッチを当てたESDI_506.PBRでもエラーが出なくなりました。
やはり以前のフォーマットでは何かが違っていたようです。
スレーブのCFについては手持ちの8GBのCFが思いのほか不安定でアクセスが遅かったため、
結局ドラレコ用のSDHC(8GB)を買ってCF変換して2kを書き戻しました（SP等はこれから当てます）。
32GBのmicroSDのほうはPCカード接続でバックアップ用途に使えば良さそうです。
# CFアダプタはスレーブに使ってしまったので、もう1個CFアダプタを調達する必要がありそうですが。orz
待っても起動しないことがある件については、
最近のバージョンに変えてからは起きていないようです。
お返事が遅れて申し訳ありませんでした。
|
| 仕組みはほとんど変えていません リウ 2020年12月17日(木) 23:42 |
最低限の文字表示を行うようにしました。
FreeBSD(98)のコードをコピペしているので権利が少しややこしくなったかもしれませんが、自力で書けない（書こうとしない）のでこのまま行きます。
あまり高くはない値段で買えたのでSeではないWindows98のESDI_506.PDRのパッチも入れました。
変更点は以下のこれだけです。
PIO-3へ速度変更をほぼ強制で行っています。実はよくないのでまた考えます。
（REDWOOD機のshadow-ram操作は入ってますが事実上何もやりません。）
今のところscandiskをかけて変なことは起きていません。
16:63で切っておいたものをPCMCIAに挿してもWin9xのGUIから素直に読めました。
|
| IPLwareの表示待ち KAZZEZ 2020年12月22日(火) 2:02 |
更新ご苦労様です。
わざわざ購入されてまでWin98無印に対応していただき感謝します。m(_ _)m
さっそくESDI_506.PDRのパッチをあてました。
ところでLBA_IDE.COMですが・・・
IPLware時にも必ずキー待ちを行う仕様でしょうか？
まりも氏のIPLwareモジュールでは基本的に
初期設定やエラーなどの特殊な警告のときだけキー入力待ちになることはありますが
# あとHELPキーでモジュールごとの実行可否を決めるときもキー入力待ちですが
それ以外は表示時間がある程度決まっていて
SHIFTキー投下時にだけ表示待ちを行うものが多いようです。
実験段階では毎回キー入力待ちのほうが便利ですが
実用時は1秒から数秒の表示時間にして、
（特殊な操作をしない限り）先へ進んでくれたほうが使いやすいと思います。
プログラムがIPLware上で動いているかDOS環境で動いているかを
判別する方法はいくつか考えられますので、
いっそIPLware上では待ち時間を固定（＆SHIFT時に表示待ち）にして
キー入力待ちを行わないようにしてはどうでしょうか。
あるいはエラー時にだけ入力待ちにするとか…。
1秒程度の表示待ちであればIPLwuniに組み込んで使うという手もありそうです。
# IPLDOSの場合は直後のEXIT実行時に1秒程度またはSHIFTキー投下中の表示待ちを行う機能がありますが、
# LBA_IDEはIPLwareの最後に置かなくてはならないという仕様がありますので
# IPLDOSでLBA_IDEを実行しても表示待ち機能を利用することはできませんね…。(汗
自前で表示待ちの任意時間を確保するにはインターバルタイマを使う形になるでしょうか。
秒単位の待ち時間であればカレンダ時計の変化を見るのが簡単ですが、
それだけだと計時の狂ったPCではフリーズする可能性がありますので…。
|
| 長めの時間待ちならVSync割り込みとか かかっくん 2020年12月22日(火) 20:35 |
> 自前で表示待ちの任意時間を確保するにはインターバルタイマを使う形になるでしょうか。
他にはVSync割り込みを遣うとか？名前の通りfV(56Hzか70Hz)に同期してIRQ 2がかかります
此れを直接遣うとかカウントして遣うとか？
fHが24kか31kか(とライン数)のフラグが有るので何のモードでも粗正確に計時できます。
|
| アドバイスどおりに作りました リウ 2020年12月23日(水) 0:49 |
Vsync割り込みを利用してキー入力をしないように致しました。
インターバルタイマを使おうと思っていたのですがこちらでうまくいったようです。
約1秒ほど画面を表示して停止します。
お二方とも提案ありがとうございます。
手元のLtでは動くようにもしていたのでそれ用の改変部分がたくさんあります。第１世代のBIOSもほぼおなじようにパッチしてやれれば動くとは思います。
＞# LBA_IDEはIPLwareの最後に置かなくてはならないという仕様がありますので
これは多分大丈夫になったかと… 暴走対策をもう一つ足しました。
未接続のスレーブをアクセスした後マスタに戻れないBIOSがそれなりにあったようです。
23日夜追記
2000のatapi.sysを強制LBAアクセスさせることに成功しました。
NT系にも手を出せるようになったことだけ報告します。
ただし相変わらずMicrosoftの規約にはまっこうぶつかってはいます。
これだけは注意されてしまうとどうにもなりません。
パッチ内容の公開すらダメだと言われてしまう可能性すらありえます。
25日追記
NT用ドライバのパッチを同梱しました。3.50~2000までです。
emulatorで裏から覗いてる限りはLBAで動いていますが実機でのテストが行えていません。とても危険です。
NTFSで動いてるOSに入れる場合は入れ替えが大変だと思いますので、なるはやでテストしたいとは思っています。
|
| スレーブに手を出すと戻らないBIOS まりも 2020年12月24日(木) 6:16 |
＞atapi.sysを強制LBAアクセスさせる
おめでとうございます。これでCFリセット来るなら来いになりますね。
＞未接続のスレーブをアクセスした後マスタに戻れないBIOSがそれなりにあった
9821Xe,Xs,Xp,XnなどのIDE第２世代後期型がそうですね。ideinf（もともとPCIアーキテクチャ,第3世代機用ツール）でも実行後にも長時間停止状態になります。
|
| ちゅーりっぷ 2020年12月25日(金) 6:35 |
リウさんのドライバー解析力には脱帽です。凄いです。
(フリーの？NT4.0用のFAT32対応)fastfat.sysは55AA関係で
正常作動しないようでした。
投稿しようか迷ったのですが(リウさんの仕事が増えてしまうと
いけないと思い踏みとどまっていたのですが)
こちらのNT 3.51 SuperPack
http://alter.org.ua/soft/nt_spack/nt3/
は(VGAは置いといて)Disk系はPC-98では駄目でした。
NTのDDKがないと難しいかも知れません。(私は持っていません。)
|
| CFスーパーリセット（新語） リウ 2020年12月26日(土) 0:47 |
 さきほどIPLが破壊されました。(先頭から吸い出して1MBほど見たところ全破壊です。)
どうやらMBRが発売時の状態に戻されたようです。
やったことはNa15でLBAパッチしたBIOSからNT４を起動して電源を落としただけです。
その前にNT351を起動しようとして失敗を二度ほどやってます。（CDドライブがあるとスレーブ強制認識させると起動できない、という現象だとは思います。）
パッチドライバはまだ適応させていませんでした。
CFリセットよりはるかに恐ろしい現象ですがこのようなことが起きたので報告します…。
夜追記
壊された状態で全域を一応読み出して保存していますので、いつでも見直せます。
まずmkptntblでは元のものを見つけてくれなかったので（IPLが破壊されているのにIPL_menuをし忘れました。）そのあたりは破壊されていると思います。
また明日確認します。
確認しました。
第3パーティション先頭にBPBは見えましたが、第1、第2、第4の位置には０やFFが並んでいました。
今日はNT3.51とNT4のLBAドライバのチェックをしました。3.51の方はよさそうです。
NT4の方はだめかも…
|
| 讀めたのは多分コントローラの初期値 かかっくん 2020年12月26日(土) 23:15 |
此の部分を見る限りパーティションテーブルが空になって居ますから、多分コントローラの初期値がFlashに書か
れるか、只讀まれるだけかの気がします。後者なら戻す方法(知りません)が有るかも知れませんが、前者なら内容が
永遠に戻らない事を意味します。
全領域をダンプするとどんなデータが残って居ましたか？
|
| NT4の領域認識方法 リウ 2020年12月29日(火) 1:37 |
内蔵IDEにつないだディスクが4G以下だと
8:17固定で探しに行かれるようです。SCSIの8:32や8:128強制と同じような処理が内蔵IDEでもされてそうな結果が出ました。
CFに対してメディアデフォルトの設定を強く推奨してきましたが、NT４を使う限りは8:17でないとダメなようです。
LBAパッチさえすればCHSでのアクセスはしなくなるので4G以下なら8:17も考慮しなくてはいけなくなりました。
8:17を回避する理由は今までなかったのですから、誰も報告してこなかったものだと思います。
なお、手持ちの64GBのCFが初期設定値が65535:16:63の32GBです。
もちろん91hで変換をして60000:16:128にして全量CHSアクセスできるようにしましたが、これもNT4ではまともに取り扱えませんでした。
NT４から領域確保するととんでもない位置にBPBがかかれます。
conv98atを通してIPL1のsignatureを消してFDISK型にしてもきちんと読めませんでした。（訂正）
変なCHS値を持ってるメディアはNT4では厳しいかもしれません。
インストール時点では4Gを越えていても8:17にされてそうな気配があります。これからAtapi.sysの中身を読みます。
|
| ちゅーりっぷ 2020年12月30日(水) 3:10 |
NT4.0SP5のATAPI.SYS(4.0.1381.92)変なパラメータのディスクを読み込もうと
したら駄目でした。
|
| PC-98版NT4.0のIDEの奇妙な挙動 チューリップ 2020年12月31日(木) 1:07 |
PC-98版NT4.0はBIOSから認識されたIDEディスクはリウさんの指摘の通り
4.3GB以下ではH=17、S=8で、4.3GB以上ではH=16、S=63となるのですが、
BIOSから認識されていないIDEディスク(例えばセカンダリスレーブ接続)だと
4.3GB以下ではH=16、S=63で、4.3GB以上ではH=64、S=32と
奇妙な挙動を示します。
↑
再検証してみました。NT4.0でBIOSから認識されていないIDEディスクは
基本的にH=8、S=128になるようです。(H=64、S=32というような値は
DiskExploerでサーチすると出てくる場合があります。)
不安定なバグ的挙動なので再起動したり他のOSから読めない場合がが
多いです。H=8、S=128でマッチしていれば、再起動したり他のOSで読める
場合があります。
更におおよそ4GB以下の場合は本来H=8、S=128は大容量SCSIのパラメーターなので低容量ではバグってしまうようです。このときパーティション作成した場合はH=16、S=63なものが出来る場合があります。この場合はかなり不安定で複数パーティションを作ってフォーマットしたときに一部のパーティションは読み書きできるような状態になる状態になることがあるが、
再度ディスクアドミニストレータを起動するとバグった領域表示になりました。再起動すると読めなくなるし、他のOSからも読めません。
|
| ちゅーりっぷ 2020年12月31日(木) 1:16 |
5chにあった投稿の引用です。
85名無しさん＠お腹いっぱい。2017/01/05(木) 08:07:14.38ID:QpcxZL2W0
訂正
NP21/WでNT4.0で4.3GB以上のHDDの挙動が変だったので
分析してみた。
NP21/W(IDE BIOS未使用、WINNTFIX=TRUE)で4.3GBを超えるIDE HDD
を接続したときは64ヘッド、32セクタで認識してしまうようだ。
通常のPC-98で4.3GBを超えるHDDのパラメータは16ヘッド、63セクタ
でありこちらはNT3.51、Win2000、Win9xで認識できる。
またNP21/W(IDE BIOS未使用、WINNTFIX=TRUE)で4.3GB以下のHDDを
接続したときは8ヘッド、17セクタでしか認識しないようだ。
NT3.51、Win2000、Win9xではそれ以外でも認識できる。
86名無しさん＠お腹いっぱい。2017/01/05(木) 09:48:37.96ID:QpcxZL2W0
NT4.0でもプライマリ･マスタに接続したときは4.3GBを超える
16ヘッド、63セクタなディスクでブートできた。NP21の内臓BIOSが
IDEのプライマリは認識しているから起動できるのかな？
あとSL9821の544MBを超えるディスクではブートできなかった。
NT3.51はSL9821の544MBを超えるディスクでもブートできる。
91名無しさん＠お腹いっぱい。2017/01/05(木) 10:22:55.84ID:QpcxZL2W0
>>85-86
IDE BIOS無しでセカンダリ･マスタに4.3GB以下のHDDを繋いだときも
16ヘッド、63セクタに設定されるみたい。IDE BIOS有だと8ヘッド、17セクタ
になるみたい。
PC-98エミュを語ろう16
ttp://egg.5ch.net/test/read.cgi/software/1482812256/
|
| 続NT４ リウ 2020年12月31日(木) 22:45 |
まずは情報感謝です。私が参加しはじめたころの書き込みがあって恥ずかしく思います…。
SP6のATAPI.SYSの話です。
まずはidentify情報でメディアデフォルトの方を使っています。
びっくりですがそうなっていました。
4351MB以下の場合デフォルトではなく8:17を押し付ける処理も入っていました。
デフォルトではなくカレントを使うように変更パッチしました。
変なデフォルトCHSを持つ64GBのCFが全量使えるようになったので動いてはいるようです。
インストール時にはSP1のATAPI.SYSとDISK.SYSがディスクの容量やパーティションを判別しています。これは4Gに限らず8:17押し付けです。
SP6のものに3ファイル入れ替えてインストールするとなんとかなるようです。
NT系列でInt1BのAH=84で取った諸元を使ってもらう方法を思いつけばまたやってみようと思います。
あけましておめでとうございます追記
NT４の新規インストール時にはDISK.SYSが使われるようです。
その際には4G以下なら8:17を押し付けられることは変わらないのですが、メディアデフォルトではなく現在値の方を取ってくれるようです。
この8:17押し付けをとりあえず解除するものも同梱しました。
16:128の設定の2Gのディスクにインストールができたので多分大丈夫だと思います。
|
| ちゅーりっぷ 2021年1月1日(金) 23:37 |
あけましておめでとうございます。
昔検証したNT4.0の変なパラメータ調べてみたりたがしっくりくるものが
見つからず、泥沼に嵌まってしまった。とりあえずそのときは
PC-98版NT4.0のディスク関係はパラメーター関係が厳しくて使い難い
印象を受けました。
あと一応補足しておくとPC-98版WintowsNTのIDEドライバはH=16、S=255の
ディスクは（ドライバ未改造でも）受け付けれくれます。
あと、NT4.0SP5のATAPI.SYSを使っている(た)理由は
NT4.0SP6のATAPI.SYSはATAコマンド0xe5 CHECK POWER MODEを呼び出しています。
NP21/W rev9とrev10がATAコマンド0xe5に非対応で、NT4.0SP6のATAPI.SYSが
動かなかった為です。
8GBの容量壁問題はNT4.0SP4以降なら対応していると思われます。
NT4.0SP5のATAPI.SYSに4.3GB以下の8:17制限解除及びLBAパッチを
適用してみたところ正常に作動することを確認しました。
↑とここまで書いたのだが古いNP21/WでSP4とSP5のATAPI.SYSを入れてみたがどちらもATAコマンド0xe5でNP21/Wがエラー出しました。
特段NT4.0SP5のATAPI.SYSに拘る理由も無く、SP6のもので良いと思いました。もしかするとSP3以前のATAPI.SYSだとATAコマンド0xe5を使わないのかも
知れませんが大容量ディスクが扱えないので利点は無い。
|
ディスクパラメータの関係で頭が混乱するので、簡単にまとめてみました。
PC-98版NT3.5xではOS対応のディスクパラメータ(SCSI及びIDE)に
対応していれば読み書き可能。OS非対応のディスクパラメータを使用
するとディスクアドミニストレータが容量誤認する等の問題が発生する。
PC-98版NT4.0ではディスクパラメータがIDEとSCSIで区別され、更にIDEで
4.3GB以下の場合はH=8、S=17が強制される。またIDE BIOSから見えていない
IDEディスクはSCSIディスクと誤判定される、これはバグった挙動なので
再起動すると読めなくなったり、他のOSで読めなかったり実用度は低いです。
パーティション作成とフォーマットしたときににH=8、C=128のパラメーター
になっているときは再起動しても読めたり、他のOSからも読める場合が
あるようです。体調不良だったが重い腰を上げて一応バグ挙動を調査。
調査がかなり難航したし実用度も無いからバグ挙動にかんしてはこれ以上は
深入りしないつもり。
|
| WindowsNTで使えそうなCHSパラメータ ちゅーりっぷ 2021年1月4日(月) 6:42 |
ちょっと訂正
あくまで98IDEでSCSI的パラメーターを使った検証ですが...(NT4.0では4.3GB以下の8ヘッド･17セクタ強制を解除パッチ適用。)
PC-98版NT3.5xはIDE、SCSIに関係なくDISK.SYSでパラメータ処理されているようですね。
PC-98版NT3.5xはヘッド数が2の累乗じゃないと正しい容量が取得できないようです。
更にPC-98版NT4.0SP5以前ではヘッド数が8以下の場合はセクタ数が
"17"、"255"、"2の累乗"じゃないと正しい容量が取得できないようです。
NT4.0SP6だと奇数系ヘッド数の認識率が向上するようです。
正常に作動しているかどうか確認する簡単な方法は1つパーティションを全容量で作成し、NTFSでフォーマットすることです。フォーマット失敗ならアウト。成功ならセーフ。(FATでフォーマットはチェックが甘いので信頼性が低いです。)
また、PC-98のSCSI BIOSでは28bitにCHSを割り振ります。
C/H/S 計28bit
55式 12bit/8bit/8bit
92式 16bit/4bit/8bit
IDE 16bit/4bit/8bit
IDEはH(ヘッド)が4bitしかないのに16ヘッドを扱えるのは0を16と見なす為です。
この為、ドライバ改造でPC-98版NT4.0及びWin2000で32GBを超える98パーティションのSCSIディスクを扱うならば、92式パラメータではIDE式に0を16として解釈し、この16ヘッドのSCSIを使えるようにルーチンを変更する。(最大128GB)、または8ヘッド以下の場合でも16ヘッドと同じようなルーチンで処理させるようにする。(最大64GB)となりそうです。
|
| NTの55ドライバ KAZZEZ 2021年1月4日(月) 22:23 |
> PC-98版NT3.5xのSCSIは55ボードも対応しているので割合幅広い
> パラメータに対応している傾向。
あれ、BIOSパラメータ＆98フォーマットのHDDに使えたのですか？
たしか公式にはNTの55ドライバは起動HDDには使えないことになっていたと思うので
てっきり92パラメータorFDISK/スーパーフロッピーフォーマットしか使えないのかと思い込んでいたのすが。
それともNECチェックの関係でそうしたのでしょうかね？
（追記）
手持ちでNT3.51を入れたHDDはどれも故障していた様子なのですぐには試せず、
とりあえずRC版NT3.51のSETUP98.TXTを見てみましたが
特にそのような記述は無さそうでしたので、
NT4.0と記憶がごっちゃになっていたのかもしれません…。(汗
（追記）
ベータ版NT3.51のハードウェア互換性リスト1995年8月版には記述がありました。
PC-9801-55U、PC-9801FA-02、PC-9801N-J03(R)について、
> この SCSI インタフェースボードに接続された固定ディスクからオペレーティングシステムを起動することはできません。
とのことでした。
製品版では違っているのかもしれませんが…。
|
| 続･WindowsNTで使えそうなCHSパラメータ ちゅーりっぷ 2021年1月5日(火) 4:52 |
結果的にNT4.0SP6のATAPI.SYSなら変なパラメータでもいけてNT3.51SP5でも
読めることが分かりました。NT3.51でも15ヘッド読めました。
NT3.5xの制限事項はシリンダ数が65534迄しか認識しないようです。
55ボードでストレージを使用出来る可能性はこれといった手がかりが
掴めていません。シリンダ数4094〜4096で試してみましたがこれといった
変化なし。
|
| SCSIの話題ばかりで脱線してすいません ちゅーりっぷ 2021年1月6日(水) 5:41 |
ふと思ったのですが、Windows2000ではATAPI.SYSとDISK.SYSはAT互換機でも
PC-98でも同一バイナリのようです。Windows2000はかなり共通化が進められて
います。しかしSCSIPORT.SYSはバイナリが異なっているようでした。
もしPC-98版のSCSIPORT.SYSが98パーティションのときにH=8、S=8or128の
92系ジオメトリを強制している部分だけの違いなら、AT互換機版のSCSIPORT.SYSを入れれば92系以外のジオメトリで98パーティションが認識できる可能性があると思いました。
あとMOの扱いも気になるところです。MOはHDDとは違うジオメトリですが
PC-98版Windows NTではどのように処理されているかです。
Windows2000ではリムーバルディスクは98パーティションを認識しないですが、やはりMOでも負荷なのかな。
追記
>>ベータ版NT3.51のハードウェア互換性リスト1995年8月版には記述がありました
製品版でも同じ記述のようです。
NT3.51のWindows NT セットアップ観て見ましたが、リストにPC-9801-55は
無かったです。（私の思い込みでした。）
NT3.51、NT4.0、Win2000のSCSIPORT.SYSを逆汗してみたのですが、
98パーティションが8:32または8:128じゃないと認識しない問題は
まだこちらでも分かりません。特段8:32または8:128以外を排除していないように見えますが、98パーティションではバグってしまいうまく認識できないのかも知れません。"66 81 7C 24 10 FF FF"のコードがある部分が怪しいとは睨んではいるのですが、特段AT互換機版のSCSIPORT.SYSとは違ってなさそうです。
また、NT3.51で特段55ボードに対応している訳では無さそうです。
更に追記
> この SCSI インタフェースボードに接続された固定ディスクからオペレーティングシステムを起動することはできません。
この部分に着目すると、ブート時は不可で、ブート後なら不可ではないと
解釈できます。NTLDRとNTDETECT.COMも調査してみます。
|
リサイクル掲示板の過去ログに行っていたのでリンクだけ掘り出してきました。
https://drive.google.com/file/d/1wcmycdaP3vU2o93oAZlvsdbUL5lT5SIJ/view
Windows9xのドライバはLBAパッチすればいいのでCHS読み機能は封印しました。
次はAsの予定です。
https://drive.google.com/file/d/1X8pA8XEV7uD_4-0kw4h_QDUsePiQ8klh/view?usp=sharing
一度SCSIについてまとめたことがありますが、新しいことは何も見つけられませんでした。
午後追記
https://drive.google.com/file/d/1xEbr8CHaCGSbWr3qn5-fgi83auZoh3-d/view?usp=sharing
強制的にCFリセットを体験するプログラムを作りました。
あ、HDDでチェックしてなかった。多分起きませんが
|
| Removal属性のCFでのWindows2000起動可能性 チューリップ 2021年1月8日(金) 21:53 |
  リームバル属性のCFでWindows2000起動可能性に前進有り。
以前CFADISK.SYSを使う方法では失敗するようで、諦めていたのですが、
DISKMOD.SYSを使うとリムーバル属性のCFでも起動可能になる可能性が
あります。（エミュレータを使っての実験ではPC-98でも機能しているようです。
内臓IDEをRemovalにするとWindows2000が起動しなくなるのを確認。）
PC-98版Windows2000で98パーティションを認識できる条件はFixedかつ
取り外し（ホットプラグ）不可デバイスであることが条件のようです。
DISKMOD.SYSのパラメータはPagingとRemovableがあり(0=無効、1=有効、2=デフォルト)、
Windows2000ではUSB等の取り外し（ホットプラグ）可能デバイスにページファイルを置くことが
できるが、WindowsXP以降はページファイルが置けなくなってしまいました。
Pagingはこの問題に対処する為の物です。一見Windows2000に関係ないように見えますが、
実はWindows2000で取り外し（ホットプラグ）可能デバイスで98パーティションを認識させる用途にも
活用できるようです。
更に注意点はWindows(特にWindows2000以降)がFDISK形式のつもりで98パーティションにアクセスしてしまった場合は98パーティションが壊れる場合が
あるので注意が必要です。
DISKMOD.SYSの注意点は付属のINFファイルでインストールすると簡単にはアンストール
できないので、システムのバックアップを取っておいたほうが良い。
あとDISKMOD.SYSをAT互換機実記に入れたときはMOドライブと相性が悪く、
MOドライブを接続しているとブート時に固まってしまう問題が発生しました。
追記
どうも98型パーティションの認識にdiskmod.sysのpagingは関係ないことが分かりました。
しかしWindows2000にはブート可能でないドライブ(IDEやSCSI以外)で98型パーティションを作成または認識しようとすると、CHSのSの値が8倍になって誤認されるケースが多いこと分かりました。さらに調査を進めるとSの値が
H×S(H*S)に設定されてしまう。たとえば本来H=13、S=11のディスクが
S=143と認識されてしまいます。当然Cの値が256を超えるとオーバーフローして不正な容量となります。(IDEとブート可能でないデバイスに同一のCHSパラメータ(もしかするとWindows2000署名も関係あるかも知れません)が存在するときは普通に認識されるケースがありました。)
更に追記
NVXはFDISK形式のディスクイメージは正しい容量で認識するようですが、
dskproveで確認するとHの値は正しくて、Sの値がディスクイメージのH×Sにした値になっていました。しかしFDISK形式の場合はLBA情報が入っているので読めるのかも知れません。
しかし以前に私が書いたようにIDE接続のディスクのパラメータが設定されるケースもありました。(当然PC-98版Windows2000でNVXを使用しないと98型パーティションは認識しません。)
この挙動はNVXのバグなのかWindowsのバグなのか分からないですが、
調べる程。泥沼に嵌ってしまうと状況になってしまいました。
手持ちのPCの環境ではUSBのドライブをdskprobeで調べると適切な値の
HSが設定されていましたが、下記のような容量誤認のケースがあるようです。
参考
ttp://blog1.bakw.sub.jp/?search=%A3%D0%A3%C3%A1%DD%A3%B9%A3%B8%A3%B2%A3%B1+%A3%D3%A3%D3%A3%C4%B2%BD%B7%D7%B2%E8
|
| 複数パーティションとか。 KAZZEZ 2021年1月9日(土) 20:38 |
以前報告した、リムーバブルドライブになっているCFにCONV98ATを適用して認識させた時は一応2kを起動できたのですが、
# パーティションが壊れる可能性は全く意識していませんでした…。（汗;;
あくまでリムーバブルのままの認識だったのでリムーバブルの制限なのか、
そのCF内ではパーティション1つしか2kでドライブ番号を割り当てることができませんでした。
（ACTVPTNを使えば一応複数パーティションの共存もできるようですが、
当然ドライブ番号の割り当てられないほうはアクセスできなくなります）
DISKMOD.SYSというのは使ったことは無いのですが、Removableが無効にできるのでしたら
もしかして複数パーティションでも認識できるようになるのでしょうかね。
|
| ちゅーりっぷ 2021年1月10日(日) 1:19 |
CONV98ATを適用してあれば、パーティションが壊れるリスクは回避できると思います。Windows2000以降はリムーバルディスクの場合はFDISK形式のパーテイション1つのみしか認識しない仕様です。DISKMOD.SYSでRemovableを無効にすれば複数パーテイション作成可能になります。
あと手持ち環境はエミュレーターのみなのですが、USBディスクで98パーティション認識できれば良いなということですが、USBディスクがまともに使えるエミュレータが手元には無いので、USBと似たような作動(取り外し（ホットプラグ）可能デバイス)として作動するNVXという(余計なことせずにシンプルに)デイスクイメージをマウントさせるソフトで検証した結果では、Paging有効で98パーテイションを認識するものの、極めて奇怪な作動でした。なぜか内臓IDEのCHSパラメーターに影響されているような。具体的にはNVXで読み込ませるものと同じパラメータのディスクをセカンダリスレーブに繋いだときは素直な挙動。セカンダリスレーブに未接続だと、本来よりもH*Sが8倍または16倍された値で処理されている雰囲気でした。セカンダリスレーブ限定では無くて接続IDが後ろの方のIDEに影響されているかの知れないが。で実記のUSB接続ではどうなるか未知数です。
DiskMod.sysについて詳しく解説したところがあんまりヒットしません。比較的詳しいReboot.proでもDiskMod関連のスレが現在見れないような状況でした。あとググってダウンロードできるのもの中にはUSBHDDasUFD.batとかが入ってたりしますが実行すべきではありません。このバッチファイルはREG.EXEが入っている前提ですが、USBHDDasUFD.batを不用意に実行してしまうと、USBなんちゃらと書いてあるものの、USB以外も殆ど全て(DiskMod.sysはWindowsXP以降のDVD-RAMドライブには効果がないようだ)をリムバールにしてしまう為、第一パーテイション以外にWindowsがインストールしてある場合は立ち上がらなくなります。
そこでオリジナルのDiskmod 0.0.2.2にアンインストール用ファイルと簡素な説明ファイルとソースコードを同梱したものを用意しました。
https://www.mediafire.com/file/3hqqphsueunpqsb/diskmod22.zip
よろしければご活用ください
あと内臓IDEの場合は"Paging"無効にしても常に"Paging"有効でした。
追記 ↑確認が不適切で設定は反映されるかも知れません
更に追記
どうもNVXで認識させたディスクをdskprobeで確認するとSの値が本来の
C×Sの値になってしまうようです。これはNVXのバグなのかWindowsのバグ
なのかは不明ですが、FDISK形式の場合はLBAの為かそのような値でも
ディスクが読み込めるようです。
|
| リムバーブルCFのスレーブ接続でWindows2000起動の件 チューリップ 2021年1月10日(日) 3:18 |
リムーバルディスクだとマスターとスレーブの両方に接続するとInaccessible Boot DeviceでWindows2000が起動できなくなるのが再現できました。
またマスターかスレーブにCD-ROMの場合は起動できるようです。
リムーバルだとパーティション1つか切れないなら、スレーブにもう一台増設しようとする場合があると思いますがみごとに玉砕される訳ですね。
追記、なんとプライマリマスターとセカンダリマスターに両方繋いだ場合も
Windows2000がInaccessible Boot Deviceで起動しませんでした。
これは複数のリムーバルディスク繋ぐとドライブレターがずれるか、
割り当てられないような状況になって起動できなくなる可能性大です。
私の環境ではWindows2000のブートドライブがAドライブの環境です。
|
| ドライブレターが狂うんでしょうか…？ KAZZEZ 2021年1月10日(日) 17:14 |
個人的にはリムーバブルと固定ディスク扱いのCFが混在している状態でしか
確認していませんので、単にリムーバブルのほうが後からドライブレターが割り当てられるために
起動CFのドライブレターが変わってしまったのかもしれません。
他のドライブが一切存在しない環境で、初めてリムーバブルがC:ドライブとして割り当てられるかのような感じでした。
現在はNr15に固定ディスク扱いのスレーブ側に2kを入れていますので
マスター側のリムーバブルCFはディスク管理でドライブレターを変更できることは確認しています。
ただ、マスタースレーブ両方存在するリムーバブルCFと単独のリムーバブルCFで
同じようにドライブレターの融通が利くかどうかは分かりません。
関係あるかどうかは分かりませんが、以前、
容量帯が大きく異なるCF(256MBと2GBとか)をオンボードIDEにマスタースレーブ接続する場合に、
DOS上で見る限り、単体では正しくフォーマットできているのに、
なぜかマスタースレーブで組み合わせると正しくフォーマットできていないことがありました。
同時に接続されているCFのパラメータの影響を受けるのか、
それともマスタースレーブだとCFリセットが起こりやすいのか、
当時その辺はまったく調べていませんでした。
|
| LtとWindows3.1 リウ 2021年1月10日(日) 23:28 |
Lt用パッチがAH=03の処理を適切に行っていなかったので修正しました。
またREIのドキュメントを読むとWindows3.1の32bitドライバがCHSでIDEにアクセスしていると書かれています。
が、IO EE0hへのアクセスを持っています。EPSON機かH98なのでしょうか？わかりません。
なお、現行LBAパッチを行った上でそのように32bitアクセスモードにするとなぜかIO432hでセカンダリへの切り替えをされてしまいます。
追記 私のIPLwareのバグでした。
IPLware終了時IO432hがセカンダリのままでした。
そのためWindows3.1にはIO432hを空読みされた後、上からセカンダリに強制的に切り替えられます。
DOS起動後にIO432hはプライマリ(０でいいです。)に戻してやってください。
Win3.1のLBAパッチができあがればバイナリもアップデートします。
/ここから無意味文章
Ltでは切り替えが無効なのでそのまま起動できますが（CHSでアクセスされます）他の機種ではKRNL386.exeが見つからないと怒られます。
/ここまで
これもパッチ予定です。
順序はAsよりも優先になりました。
＞DOS上で見る限り、単体では正しくフォーマットできているのに、
＞なぜかマスタースレーブで組み合わせると正しくフォーマットできていないこと
マニュアル内に追記しましたが、スレーブにつなぐとダメなCFを見つけました。私が作ったわけではないので断言できませんが、マスタ専用処理がされていそうなものが存在するのかもしれません。
|
| 複数のリムーバルディスク接続でWindows2000起動不可の件 ちゅーりっぷ 2021年1月11日(月) 0:56 |
KAZZEZ様。
最初に書いたコメントが違っていると思い削除してしまいましたが、
やはりドレイブレターがずれるか割り当てられていない可能性が濃厚
ですね。
Windows2000は新しいディスクが見つかるとC:から割り当てようと
します。IDEにリムーバルなCFを複数台繋ぐと新規に割り当てようと
する為にドライブレターが認識順にC:から割り当てられているのだろうと
思われます。
あとWindows3.1のWDCTRLこれはWIN386.EXEに内蔵されていることを失念して
いました
|
| 先頭から17セクタならど何の設定でも讀める かかっくん 2021年1月13日(水) 4:56 |
安直な考えですが、8:17でもネイティブCHSでも讀める、先頭から17セクタで自分自身(起動したデバイス)を再設定し、
他は適宜設定するやうにすればBIOSの値を遣って居るOS/DRVでは問題無く遣えそうです
使用中の物は遣えるやうにするか『要初期化・再インスコ』にするかは議論が分かれそうですが。
ところで、NSとかNS/Eの頃の最大容量って何Mでしたっけ？ぃぇ8:17か4:17か気になったので
しかし、当初のST-506系は本当に17セクタであった事から、FDよりも記録密度が低かったんですよねぇ
あ、当時は5インチだからFD(2HC15セクタ)よりは高いか。でも回転数が10倍だから転送レートも10倍位か
トラック密度は数倍でしたが。
思いついた事が有るのでIDE - ST-506板を捜してみようかと
98のHDDを讀む為でわなくIDE側でどんなコマンドを処理するとST-506がどう動くか？を調べたいので
|
| Windows3.1のLBA化 リウ 2021年1月14日(木) 2:58 |
ようやくパッチプログラムが書けました。
本業がプログラマの人なら数分の仕事だと思います。
3台目以降がBIOS経由になってしまうのは残念ですが、メモリが準備されてなさそうなので諦めました。
BIOSパッチの方は
IO432hの状態をIPLware終了時にプライマリに戻すようにする変更を含みます。
>先頭から17セクタ
512kb/Sでは
0 IPL 1FE0:0000hにロードされる
1 パーティション情報
2-16 起動メニューやIPLwareの置き場
ではないですか？
>IO EE0-EEF
こちらに書いてしまいますが、皆様情報ありがとうございます。
とりあえずこのパッチでは潰しています。
そういえばIDE-98のSMITのMMIO解析がNetBSD/pc98のソースに書かれていました。
|
| NT4のSCSIディスクのHSパラメータ リウ 2021年1月17日(日) 22:12 |
https://drive.google.com/file/d/15wypKhiX0WsZs7A0DQy9KeSSBN64ObNd/view?usp=sharing
壁ごえSCSIの付属品としてNT4のSCSIに対しての
8:32や8:128押し付け回避パッチを入れました。
対象はSP6のDISK.SYSです。
一応Na15実機でPCSC-F経由で1GBの16:63のディスクに対して正常にアクセスを行えました。これ以上のテストはできてはいません。
私はパッチ内容を理解していますが解説できません。なのでやっつけマニュアルになっています。ご容赦ください。質問されればもちろん答えます。
AsのIDE-BIOSが後回しになっています。結局第2世代機種もまだ手に入れられていません。
追記
>シリンダ数が65534迄しか認識しない
わざわざ1を引く処理がDISK.SYSのSCSI部にありますので65534がシリンダ数の最大ということになっています。（パッチでは解除しませんでした。）
Windows2000の場合
やはりdisk.sysの気配です。それっぽいコードは見つけました。
が、パッチするためにはemulatorでチェックしないと確信が持てないのでまだまだ提出できません。
18日追記
1626:15:63は1626:15:53の間違いですね…
16進から10進への計算すら間違うようではパッチの中身も信頼できません…
とツッコミは入れておいてご指摘ありがとうございます。
いずれにせよこの諸元に固定している部分は破壊しています。
おそらくとりあげてくださったディスクなのだろうとは思います。
IDEが8:17に固定してる部分のコードを乗っとれば破壊しなくてよさそうですが、この諸元に行くことも私が使うことはなさそうということで近場で破壊しました。
|
| C:H:S=1626:15:54 ちゅーりっぷ 2021年1月18日(月) 1:32 |
NT4.0SP6のDisk.sys
この部分
013BC7 68 0C3B0100 PUSH 00013B0Ch ;
は"NEC D5882"という文字列を参照しているようです。
分岐後に次のようなコード
013BDD 83C3 44 ADD EBX,+44h ;
013BE0 8B03 MOV EAX,dword ptr[EBX] ;
013BE2 C740 10 35000000 MOV dword ptr[EAX+10h],00000035h ;
013BE9 8B03 MOV EAX,dword ptr[EBX] ;
013BEB C740 0C 0F000000 MOV dword ptr[EAX+0Ch],0000000Fh ;
013BF2 8B03 MOV EAX,dword ptr[EBX] ;
013BF4 C700 5A060000 MOV dword ptr[EAX],0000065Ah ;
がありました。これはC:H:Sのコードだと思いますがC:H:S=1626:15:54になります。
NEC D5882は5インチのSCSIハードディスクドライブのようです。諸元をみると512バイトセクタ時はC:H:S=1630:15:54のようです。
undocのmemsys.txtに
メモリ
|
| IOポートEE0の正体？ ちゅーりっぷ 2021年1月18日(月) 3:07 |
PC-H98/70-E01、PC-H98/70-E03、PC-H98/70-E03がIOポートEE0h使っているのかと
推測したのですが多分違っているようでした。理由はIOポートEE0hがIDEっぽい操作を行っているから
です。
（PC-H98/70-E01とPC-H98/70-E03はSASIインターフェースでPC-H98/70-E02はESDIインターフェース
です。PC-98のSASIインターフェースはSASI→ST-506変換基盤の付いたドライブを接続する為のもので
基本的に容量決め打ちでインテリジェントではありません。PC-H98/70-E02は100MBのESDIドライブが接続できますが、恐らくSASI BIOSかほぼ同等BIOSでしょう。恐らく100MB決め打ちでしょう。）
Win3.1のWDCTRLとNT3.51のDISK.SYSとATAPI.SYSを解析した感じでは、この謎のIDEっぽいやつは
PC-98のIDEと比較すると
430h〜435h→430h〜435h
640h〜64Eh→EE0h〜EEEh
74Ch〜74Eh→1EECh〜1EEEh
このようになり、更に
8EE0h、8EE2h、8EE4h、8EECh ←NESA-F0？
NESA-FOポートみたいなの使っているのでNESA接続(当然PC-H98)のIDEかと推定されます。
ということでH98でIDE内蔵のものはPC-H98Tしか無いのでPC-H98Tの内蔵IDEのポートだと
推測されます。NESAのIDEボードは聞いたことが無いし...
|
| 2000も押し付け開放 リウ 2021年1月21日(木) 4:04 |
解放？
壁こえSCSIの付属物にWindows2000SP4用のHS押し付け回避パッチを同梱しました。
手元では１台しか外付けSCSI機器を持っていません。（IDE変換です。）
それを適度にIDを変えたり中身を入れ替えたりしてる限りではきちんと領域を認識してくれました。
Int1BのFunc.84ではなくIPL1の前の2byteをHS設定の判定に使っています。（NT4パッチでの判定とは違います。）どちらでもよかったのですが一応こちらにしておきました。
中身がNEC-IPLの9090の場合そのままヘッド90hセクタ90hとして受け取ります。
FreeBSD-Loaderの場合0が入っています。０除算エラーが出てしまうはずです。ご注意ください。
私は１台しかないのでテストできません。もし現役でテストしてやるぜ！って方はよろしくお願いいたします。
ただしデータの保証はいたしかねます。ご容赦ください。
またWindows2000はドライバをやたらと保管しているのでバックアップを消さないとまともにテストできないと思いますし、SP4以降もDISK.SYSはバージョンアップされています。全部には対応できません。
世界初ではないことはまりもさんから報告を受けていたのであまり自慢できませんが自己満足で納得できるものにはなりました。
WD33C93なボードが全滅な2000ですから実際は最初から8:32を押し付ける100ボードにマルチベンダなHDDをつないだときしかほぼ意味がありません。
大容量には意味がありますが安いサーバー用未使用HDDもいつのまにか見かけなくなりました…。
午後追記
HS設定プログラムにバグがありました。なぜかMS-DOSだと実行できてしまったようです。FreeDOSで暴走することで気づけました。
IDE-BIOSパッチ付属品も壁ごえSCSI付属品も入れ替えておきました。
と同時に第１パーティションの終了位置のHS設定への流用をやめることにしました。
先頭のIPL1直前とIBM形式のパーティション諸元の直前の2つで行くことにします。
windows2000のドライバ入れ替え方法は面倒なのでマニュアルに書かなくてはいけないと思いました。
以下私の方法です。
NTFSにインストールしてしまった場合
1 起動する
2 WINNT\driver cacheにあるsp4.cabとdrivers.cabを移動
3 WINNT\system32\dllcacheにあるdisk.sysを削除
4 WINNT\system32\driversに新しい方のドライバを配置
数秒待つとOSがSP4のCDを入れろと警告を出してくるのでキャンセル
5 再起動 一度目はやたら待ち時間が増えました。IDE起動でこけるかもしれないと不安になりました。
6 PCMCIA-SCSI経由で98フォーマットなSCSIディスクをつけたりはずしたりしてテスト
FATな領域にインストールしたならば別OSから同じことをやればいいと思います。起動中の入れ替えもできたことは報告します。またどのディレクトリも隠しフラグがついています。
|
| Giant Step まりも 2021年1月21日(木) 22:28 |
SCSI BIOSで32GiB(61.4GiB)超えをどうしようとずっと迷っていましたが、これで容量制限拡大は15:255が123GiBまで主流ということにできるので、よかったです。Func 84hを使わなければ4096以上シリンダモードで16ヘッド以上も行けそうです。
EB 0A xx xx "IPL1" のところは90,90や0,0のときそのまま解釈してしまうのは、、いろいろ制約の多いWindowsデバドラのパッチですので仕方ないところでしょう。これこそIPLwareで先回りして xx xxのところにBIOSで認識のヘッド・セクタ数を書き入れてしまえばいいような気がします。ただし起動の都度書き換えるのでは、たまたまSCSIボードのBIOSを取り替えたようなときに違うものに変わってまずいので、別な場所にも保管をし、世代管理する必要があると思います。その別な場所としてWindows 2000が書き込むパーティションテーブルの廃用終了ヘッドセクタ番地でもいいでしょう。
＞世界初ではないこと
一般に発表できる形にしなかったものは、存在しないも同じです。ですから世界初です。
＞Windows2000はドライバをやたらと保管している
コレ結構しつこいですよね（笑）、driverchacheというような名前のへんなフォルダもありますし。デバドラ差し替えは一般的にはsafeモードで行いますが、ディスク関連のドライバもそれで上手く行くのでしょうか。それとも別起動のWindows 2000/NTを使ってドライバ置き換えですか？
|
| 「世界初」 ちゅーりっぷ 2021年1月22日(金) 0:25 |
リウ氏が世界初ではないとした根拠ってもしかしてアレですか？
DOSで32GBよりも少し少ない領域を確保してから残りの領域をNT4.0で
確保するという危ないやりかた
|
| STAP細胞もこれから発見した人が世界初 まりも 2021年1月22日(金) 11:59 |
いえ、私の知っている人が試みたのですが情報すらも公開してないというだけです。後の人が追試できるものでなければ、存在したことにはなりません。
＞DOSで32GBよりも少し少ない領域を確保してから残りの領域をNT4.0で
これは、わたしのformatxのある時期のバージョンにあった、「SC-UPCI 32GB壁またぎフォーマット」のことだろうと思います。8:128で一杯まで領域確保してある状態で、Windows 2000などのディスク管理では、残りがあると表示されます。これは既にこのスレッドのみなさんが解析したように、全容量の取得方法とパーティションからの取得とが異なるから起こるわけです。覚えている限りでは、のこりの32GBオーバーなところを確保すると、98パーティションにも書かれるのですが、そのときの開始シリンダが０番地となったんですよね。Windows 2000はおそらく内部的には正しい処理をしていて、65536シリンダから開始と解釈したのでしょうが、テーブルに記入するときには16bitしかありませんから、全部桁落ちになってしまったと。で、結果的にこれはパーティションの記述が範囲重複となるだけでなく、０番地から使うとなるとパーティションテーブルもが使用領域となるので、自滅してしまうという危険があるわけです。そのため「壁またぎフォーマット」というのは廃止したという経緯があります。formatxの改版履歴に情報が残っている程度ですが。＄のログには当時の議論が残っているかもしれません。
|
| 現状の私が理解していること まとめ リウ 2021年1月22日(金) 12:17 |
あっちやこっちに話が飛ぶと後で参照できないのでこちらでまとめましょう。
過去に成功者がいたという報告については過去ログ
http://ematei.s602.xrea.com/cgi-bin/bbs39_ris2/bbs39.cgi?mode=past&year=2020&mon=11
HDDの認識パラメータについて、私が認識していることを書きます。
もちろん憶測を含むので間違っているかもしれません。
Windows2000はドライバでデバイスと会話します。
会話するアドレスを確定するために、HSパラメータが必要なのはPC-98特有です。
なぜならパーティション先頭位置がLBAで指定されておらず、シリンダ位置で指定されているからです。
この情報はBIOS-CALL Int1Bh Func84で取れますがNT系OSは普通こんなことをやりません。（Windows2000はやってましたが）
IDEならIdentifyコマンドで現在のメディアの状態を取れます。
（SATAも同じです。）
SCSIにはそのようなコマンドはありません。
システム領域0000:0460hからの28byteにはSCSI-BIOSが設定したパラメータは存在しますが、BIOSから認識されないディスクや、後から電源を入れたディスクに対しては何の効力も発揮できませんし、複数のSCSIドライバが同じものを参照するとバカな結果を呼びます。
従ってOS作成者はNEC純正のパラメータを容量で判別して8:32か8:128になるように設定をしました。（今回私が破壊したのはこの部分です。）
さてATAならIdentifyを取れるので容量間違いはおこしませんが、それ以外
例えばUSBやFireWireだとどうなるかです。
普通の使い方だとブートする必要のないデバイスですからPC/AT形式のMBRが書かれたものを使うでしょう。しかし中身を入れ替えて使うガワの使い方をすると98パーティション形式のものをつなぐこともあるかもしれません。
このときにちゅーりっぷさんの指摘されていることが起こるはずです。
ということで次は実機のカードバス経由のeSATAやUSBに98パーティションだけを書いたメディアをつないでみようと思います。8:32や8:128に固定されるのか？それとも何かまた別のことが起こるのか楽しみです。
そういえば実験途中で1GBのメディアが領域認識は正しいのに32TB判定されたことがありました。
容量誤認なのかパッチミスなのかはっきりさせていませんでしたが（どうせパッチミスと思いますよ）もう残していないコードなのでわかりません。
最後に私のパッチは今のところIPL1を見るところで同時に55AAを見る部分を潰しています。IPL1はあるけど55AAがない、というMBRはないと決めつけました。
|
| 自滅のやばい（SC-UPCIまたぎフォーマット） まりも 2021年1月22日(金) 12:47 |
全容量の認識とパーティションからの容量解釈の不一致は非常にヤバイですから、ドライバやBIOSを改造してでも、全容量きっちり認識し利用できるH:Sパラメータで使う方が健全だと思っています。
＞ちゅーりっぷさんの指摘されていること
まず、Windows2000で「98ブート不可能なディスク装置を98フォーマットをする」という手順・方法がよくわからないのですが（普通にはPC/AT FDISK形式で認識されるはずなので）、GUIのディスク管理でしょうか、DiskPartコマンドでしょうか。
それができたとすると98パーティション情報が書かれるわけですよね。それが間違った値（そもそも正しい値が存在しませんが）になるというのは、理由は２つあって、１つは上で書いたように、シリンダ番号が32bitになっているけど16bitまでしか書けない桁落ちによるもの、もう一つはわたしが以前報告した、「Windows 2000では H:S=255:63になるらしい」によるものの and ではないでしょうか。両方あるとカオス的になると思います。
|
| 「」 ちゅーりっぷ 2021年1月22日(金) 23:44 |
まりもさん、リウさん解説ありがとうございます。
---
>「98ブート不可能なディスク装置を98フォーマットをする」
私の説明不足ですいません、具体的にはIDE、SCSI以外のディスクドライブ
です。USB、IEEE1394、AHCI等が該当するかと思われます。私が実験したのはeuee氏のNVXという仮想ディスクドライバを使用しました。
GUIのディスク管理でパーティションを作成しました。拡張パーティションがグレーアウトしており、プライマリパーティションが5つ以上確保できました。
結局の所、皆様の指摘の通りIDE以外では適切なCHSを取得する方法が無く、
SCSIではそのため決め打ちのパラメータですね。(一応MODE SENSEコマンドはあるけども55ボード問題のように混乱を招きます。)
USBやIEEE1394は内部的にはSCSIコマンドを使用しているので、SCSIと同様に適切なCHSが取得できないかも知れません。IDE-SD変換機でも適当なCHSをでっちあげで作るようですし。
|
| タイムマシンに乗って まりも 2021年1月23日(土) 0:16 |
http://weblabo.griffonworks.net/dorlog/2nddorcom/98maniacs/20127.html
うわめちゃ熱い議論してますね。当時の活気が懐かしいです。
http://weblabo.griffonworks.net/dorlog/2nddorcom/pc-98/47861.html
現在の知見とは微妙に違うことを言っているような点もあります。BIOSなしの場合のことやディスク署名の有無は当時は把握してませんでした。
ところでシリンダ0からというのは記憶違いかもしれません。開始は0ではなく65535かも。SCSIだと最大値が65534までしか有効にしてもらえないので、その次です。そこからラップアラウンドして終了はそれより小さい値になり、開始と終了が大小逆転で記録されることになります。ヤバいには違いありません。
|
| ちゅーりっぷ 2021年1月23日(土) 23:49 |
  もやもやしていた部分が分かったのでとりあえず報告
NVXでディスクイメージを読み込ませた場合、本来の方をCHS、NVXで読み込んだ方をC'H'S'と
するとH'=H、S'=H*Sとなりますが、そうならならずに読めた場合が気になったので調べました。
（PhysicalDrive2がセカンダリ･スレーブ、PhysicalDrive3がNVXでマウントしたドライブ）
エミュレータでセカンダリ･スレーブとNVXで同じディスクイメージを読み込ませた場合、Windows2000ディスク署名が同一である為、セカンダリ･スレーブのディスク署名と各種設定（CHS）がレジストリに書き込まれます。
その後に同一署名のディスクイメージをNVXで読み込ませると先に読み込まれたセカンダリ･スレーブの設定(CHS)が設定される為に正常に読み込めたようです。しかしWindows2000ディスク署名が重複している
為にNVXの方のWindows2000ディスク署名が書き換わります。なので一旦マウント解除したり再起動するとC'H'S'の方が適用され読めなくなってしまったようです。
|
| 一通り実験したので報告 リウ 2021年1月24日(日) 4:36 |
パッチされたDISK.SYSはdllcacheディレクトリに同じものを置いておくと起動の待ち時間が短縮されました。どうやら起動時にいちいちバックアップと同じかどうかをチェックしているようです。
eSATAでの話になります。
まずeSATA経由でも98IPLでフォーマットをしようとはします。ですが私の環境ではまったくWindows2000からは初期化が完了できませんでした。
内蔵IDEにSATA変換してパーティションテーブルを読むと領域終了HSがかかれてあります。それを確認すると設定値はヘッド255セクタ63でした。（つまりパッチされる判定部を通っていません。）
Windows2000から初期化できないので今度はDOSから255:63設定で領域を切りました。
Windows2000に持っていくと領域サイズは切られた通りにきちんと取れますがFATをマウントできませんでした。
ダイナミックディスクに変換してから初期化すると素直に完了できました。
ベーシックディスクに戻すとやはり初期化できません。
従って255:63にされるタイプのものには現行のDISK.SYSのパッチは何も寄与できないようです。
いやそもそも私はまだパッチ後のDISK.SYSの動作を領域が認識されて中身が見えたことしか確認していませんでした。SCSIに対してもディスクの管理からの初期化を試していません。できたつもりにはなっていますがまだまだ精査が足りません。
30分後の追記
眠らずにさっそく試しました。SCSIは初期化が通りました。どうやらパラメータは間違えないようです。
よってeSATAは何か手が必要なのだと思います。
|
| USB ちゅーりっぷ 2021年1月24日(日) 14:47 |
いろいろ調査していただきありがとうございます。
私の書き込みでなんか振り回してしまって申し訳ないです。
WindowsでUSBのCHSの認識はたぶんMBRを見て設定される感じですね。
HDDの場合は大抵ヘッド255セクタ63ですがUSBメモリは異なる値でした。
PC-98のDOSで使おうと思うと例えば、擬装 for USBASPI for 98 DOSと
98DOS対応のASPIディスクドライバが必要となりますが、FAT32対応の98DOS対応のASPIディスクドライバは殆ど無いので、有用になる環境は限られてきそうです。
追記
ASPIディスクドライバはPC-AT互換機用のものでも動くようです。
（これは98型パーティションで扱えることを意味するものではありません。）
備考 似たようなもの?としてPCカードのSCSIが挙げられます。
これは起動時にSCSI-BIOSを認識させる手段が無いので、まずデバイスドライバでSCSI-BIOSを組み込み、そしてINT 1Bhディスクドライバを組み込むというスタイルとなっているようです。
|
| USBもチェック リウ 2021年1月24日(日) 23:57 |
実機eSATAでは500GBを越えてると255:63では16bitシリンダに収まらないため私の2TBのディスクでは操作がまともにできないのではないかと想像しました。
SC-UPCIに32GBを越えたものをつないでもWindows2000からは領域操作が正常に完了できない//削除（読む限りNT４から確保していたのですよね？）、ここまで//という事象とほぼ同じことなのだと思います。
さてUSBです。
IPL1を書いてあるものをつなぐと255:63で認識されました。
ただしチェックはemulatorで行いました。DISK.SYSの8G判定のされるところを通らないのでSCSI用パッチはやはり無効です。
おそらくFireWireも同じでしょう。
//ここから削除）リムーバブルデバイスフラグとは別の取り外し可能フラグがあるものは//
BIOSのないストレージでは255:63が選ばれるという以前からの報告を再確認しました。
BIOSのないPCI-IDEが気になります。SCSI判定されて8:32を押しつけられるのか。IdentifyコマンドからHSパラメータを取るのか、それとも255:63を選ぶのか
内蔵IDEのBiosから無視されるところはIDENTIFYを取られてはいますが。
まあ実用には無関係ですね。emulatorでまた調べます。
PC-98でフォーマットしたものをUSB籠やeSATA籠につないでPC-98版Windows2000に繋ぐ人”だけ”が困ります。
実際はconv98atしてからAT機につなげば何も問題が起こらないと思います。
どうしてもやる際もconv98atしてからIPL1を消せばまぁ読めると思われます。
|
| 色々判明 リウ 2021年1月28日(木) 3:49 |
まずはMicrosoftのWindowsドライバ関連の公開情報から
https://docs.microsoft.com/ja-jp/windows-hardware/drivers/ddi/ntdddisk/ns-ntdddisk-_disk_geometry
このようにドライバはCHS設定を行えることになっています。
https://github.com/microsoft/Windows-driver-samples/blob/master/storage/class/disk/src/disk.h
また79行目からの構造体にBIOSからジオメトリを取ることが許容されていることがわかります。
さて以降は逆アセンブルの結果です。
まずInt1BhのAH=84を取ってきたものはDiskGeometryFromBIOSが入ります。
ただしやはりSCSIのDA/UAに対してはやらないようです。何台まで行うかはちょっとわかりませんでした。
それ以外のものはIPL1があるとDiskGeometryFromNec98が入る判定に行きます。SCSIの8GB判定もここで行われます。（パッチした部分です。）
ドライバが設定しているものも取得できるように書かれています。
（紹介されている仮想ドライバやBIOSで見えない部分のATAPI.SYSやUIDE-66のドライバなどはここで返事をしてるのだと思われます。）
そこでPageFileが置けない判定？またはIPL1がなかった場合、PC/AT型ドライバが設定した値？を取り込もうとします。
DiskGeometryFromPortが入ります。
USBやSATAドライバはどうやら設定しません。DiskGeometryUnknownのままです。
いずれも終わったら容量チェックに入ります。ここでCLASSPNP.SYSを呼びます。
そこにはUnknownだった場合（実際はHもSも未設定で０の場合）FF:3Fに固定するルーチンがありました。
なおReactOSのGeometry.cがとても参考になりました。
https://doxygen.reactos.org/db/df2/geometry_8c_source.html
1114行目からにとても重要な情報が書かれています。
DiskGeometryfromNT4用に実際に64:32に固定しようとするルーチンはDISK.SYS内にありました。
そして255:63に固定するルーチンはclasspnp.sysにありました。
そこをいじくると255:63で切ってあったUSBストレージがきちんとマウントできなくなりました。
こっちもうまくパッチするかはまた考えます。
一応すべて説明はついたと思います。逆アセンブルは違反ですが
以上報告まで
LBA-BIOSの容量判定にIdentifyの28bit総セクタ情報を使っていますが
古いHDDだとここが0のものがあります。
WindowsドライバがなぜかCHSの掛け算で総セクタ数を取り扱おうとするのですがこんなディスクを想定してるからなんですね。
ということでまだ公開していませんがCHSの掛け算からも取れるようにしました
|
| やはり人柱版でした リウ 2021年1月28日(木) 19:29 |
Windows2000で8G判定パッチしたDISK.SYSがある状態で
IPL1を書いたUSBストレージやeSATAストレージをマウントしないでください。
未使用と思っていたスタックが使われたか
0除算が起きている気配があります。まだ調査段階です。
|
| スタックの上限と0除算 リウ 2021年1月31日(日) 20:08 |
Windwso2000の方のパッチを修正しました。
スタックの未使用と思う部分を取るのを使用中のものではなく（超危険でしたね）
これから使用されるかもしれない部分から選ぶようにしました。
(EBP+80hを使っていましたがEBP-E00hを使うことにしました。DISK.SYSのスタックは1000hなので今度ははみ出ている恐れがあります。）
実機でSCSI機器が任意のパラメータで取れながら
255:63型のもの（eSATA）が一応動いているようには見えます。
また0除算はやらないように対策しました。
全体容量は間違えますし255:63になっちゃうと思われます。
9090hな場合もそのまま受けとります。
ちょっとまたスパムがひどいですね。一度スレを落としてしまうこともあるかもしれません。
LBA-BIOSは上記のCHS掛け算もやるように変更しました。
また少し前のバージョンは"CD21"がバイナリの中にいくつか含まれてしまっていたようです。現在のものは入らないようにずらしました。
NT4の方も同じように危ない気がするのですが積極的に使う気がないので危険ですが後回しにします。
2/1追記
ipl1disk.sysという名前に変更して使うようにしました。
デバイスマネージャで入れ替えたものだけで仕事をします。
再起動が必要ですが
DISK.SYSはWHQLのもののままなのでWindows標準ドライバがいちいち警告をしなくなります。
少しは危険が減ったと思います。
|
| D800:207B D800:2088 D3766 リウ 2021年2月8日(月) 12:59 |
前者から
PCI機（おそらく第3世代機すべて）でここには計算途中でInt1BがLBAモードで呼ばれたかCHSモードで呼ばれたかのフラグが入っています。
がBsではIO 1E8Ehの状態が保管されていました。
動いたことだけは確認してまだアップロードしていませんが、今までと同じパッチだと何かおかしいことが起きるかもしれないので２世代では違う場所にします。
D800:2088の接続をDA/UAに変換するテーブルは２世代のBsにはありませんでした。
しかも81hが完全にセカンダリマスタに固定されています。
セカンダリマスタ一台だけつないでも起動メニューには行けません。
0000:0457hだけを見ています。0000:05BAにも入っていませんでした。
F8E8:0010も空です。
BsについていたD3766が現状のパッチ後BIOSではまともにアクセスできません。（LBAでIOアクセスすると返事はしてくれます。）
Int1Bhの返事がC0h（No-DATA）になってしまいます。
ブラックリストに入っている名前そっくりなので何か手順が必要なのかもしれませんが非対応にさせてください。
IPL1DISK.SYSについて
eSATAにつないだBsで初期化してきた255:255のものをテスト中です。
きちんと領域は見えるのですが何か気持ち悪い状態です。
常用する人はいないと思いますが注意してください。
|
| D3766はCHSだけ かかっくん 2021年2月8日(月) 17:25 |
D3766はCHSでしかアクセスできません。此れは過去ログ堕ちしたスレーブスレに有ります
ematei.s602.xrea.com/cgi-bin/bbs39_ken/bbs39.cgi?mode=past&year=2019&mon=3
元の構成でIDEINFすると判ります
|
| D3765はもっと凶悪 まりも 2021年2月8日(月) 18:18 |
|
そしてその1つ前の型番である D3765 は、LBA不可だけでなくCHS設定不可（コマンド91h受けず）という固定のCHSのようです。同じスレ参照。
|
| Bs対応他 リウ 2021年2月11日(木) 4:22 |
なんとかBsに対応することができました。
まずはIPL1DISK.SYSについて
Windows2000サポートツールであるdiskprobeで見ていただくとわかりますが
eSATAやUSBにつないだもののHやSがきちんと設定できているもののCが0になってしまいます。このため領域操作がまったくできません。
ただし領域は正常に認識してアクセスできます。
SCSIではCもきちんと渡しますので領域操作もできるはずです。（相変わらず私は1台しか使えませんのでわかりません。）
Bsで苦労したのは高速IDEフラグでした。
世のCFはこれもきちんと取扱いできません。
0000:045Dhに18hが入っているとコマンド20hではなくC4hでアクセスします。
またDA/UAの81hがセカンダリマスタに固定されているのを奪って82hに入れ替えます。
ただし0000:045Dhのbitはマスタ側で共用し、スレーブ側でもそれぞれ共用することになりました。（4台きっちり区別するのが一番よいのですが…）
第3世代の機種では0000:045Dhの設定はプライマリマスタとセカンダリマスタと1:1対応されているようです。が、よくわかりませんでした。
undocには0000:045ehに3台目、4台目設定があると書いてあるのですがどうでしょう。
CHS専用HDDに対しては
コードだけは残しているのでそのフラグを立てれば（LBA非対応スイッチをどこかに保存して）CHSモードを復活させられるのですが…放置します。
スレが落ちてしまいましたが
CPUと縦SASIは送ります。一眠りしてからeメールを送ります。
ATAPI.SYSのスレーブ非対応機種用パッチを足しました。
これでBfでもスレーブが使えると思いますが、わかりません。
またスパム対策で個別処理していただいていたようでありがとうございます。
12:05
eメールを送りました。
|
| うーん… リウ 2021年2月11日(木) 21:19 |
 気づいたらあげては見ますが
状況は厳しいですね。
壁越えSCSIに大きなバグがありました。
取り除けていません。
割り込みベクタテーブルにあるものを書き換えずにBIOS位置を変更しています。
PCIボードでの共有での割り込み番号検索が正しいか自信が持てません。
一度設定されたものを動かすとやはり混乱の元です。
WD33C系なら取れるので変更予定部だけ作りました。
|
| ちゅーりっぷ 2021年2月13日(土) 1:23 |
| SMIT-SCSIとIDEのCF リウ 2021年2月13日(土) 2:01 |
スレ落ち防止のため 話題が違いますが書き込みます。
以前やってたものの続きです。
http://ematei.s602.xrea.com/cgi-bin/bbs39_ken/bbs39.cgi?mode=past&year=2020&mon=9
割り込み処理の中でIO CC0のbit7が立っていると 0000:0483hのbit7を立てるという処理があります。
なぜかIDEに例のGreenHouse製CFを繋いでいるとMITモードやSMITモードではIO CC0のbit7が立ちません。またCC4のbit3も立ちません。
もちろんDMAモードやPIOモードでは立ちますし、別のCFなら立ちます。
さらに、割り込み処理自体がされない場合もあるようです。
レジスタ15の操作の後急激にOSの動作が重くなりますがIO74Chに6を送ってATAを止めるととりあえず操作はできるようになります。しかし改善はされません。
|
|
|
