| 98システム解析スレッド2026年1月 ／人'A`;人＼ 2026年1月1日(木) 5:05 |
| 新年お慶び申し上げます リウ 2026年1月1日(木) 6:48 |
新年一発目からバグ訂正です。お目出度い気分を台無しにしてすみません。
KAZZEZさん、試用ありがとうございます。
割り込み設置ルーチンが間違えていました。(他にもありますが一番大きなのはこれです。)
また年末にPromise TX2000の板を仕入れましてそれに新規対応しています、残念ながらWindowsドライバがRAIDの構成をどこかから読み込んでいる（1/7追記 それぞれのディスクの終端に構成保存されます、カード側には情報保存されません。）らしく直接生ディスクにはアクセスできていません。DOSではXa無印で4MB/sくらいです。Windows98がBIOSモードで立ち上がることまでは確認していますがそこまでです。
VT6421もHDB98計測がうちでは8MB/sくらいは出るので何かまだ知らないことがあるかもです。
Identifyをするときに未接続のところを見てしまうバグに関してはなんとなく原因はわかってきたのですが修正は全くうまく行っていません。またatareset後の復帰がとても遅いHDDが手持ちにありました。(Maxtor製)その対処を全ファイルに行ったかの自信がありません。
1/2
画面表示部の対処を行いました。つながってないところには何も表示されなくなりました(はずです)。 HPTのものはあぶなそうなPCI config空間へのアクセスをやめました。uideinfで何かしら表示できている限りはHDDと会話ができているはずなので余計なことをやってる部分が不要のはずということで
|
| Promiseとか KAZZEZ 2026年1月1日(木) 21:54 |
皆様あけましておめでとうございます。本年もよろしくお願いいたします。
> お目出度い気分を台無しにしてすみません。
こちらこそ変なタイミングでの報告になってしまい失礼いたしました…。
Promiseといえば昔、ATA33のPC-98BIOSを作成された方がいらしたそうですが、結局どうなったのでしょうね。
weblabo.griffonworks.net/dorlog/2nddorcom/98maniacs/17663.html
どうもPCIボードに直接書き込んでも起動しないとかで、HPT368でも同じような問題なのかどうか興味深いところです。1/1版でもHPT368用PCIBIOSは実行されない感じで、COMファイルのほうはハングはしないようですがFDSK98はエラーを返すので以前と同じ感じでした。[追記]hpt368.com実行後はHPT368ボードを認識しなくなるようです。実行前はPCILISTやbarcheckからはボードの存在が見えるのですが、実行後は見付からなくなりました。
> うちでは8MB/sくらいは出る
試用した本体またはCPUの違いでしょうか？ こちらはPen2/233MHzですが…430VX機はオンボードIDEが少し速い気がしましたが関係あるのかどうか？
|
| 新春放談：フォーマット形式 まりも 2026年1月2日(金) 0:08 |
OneさんのUSBストレージドライバでスーパーフロッピー形式（以下sfd）が認識できないことは気がついていましたが、それでいいとは思います。もともとWindowsはsfdを認識しているとは言えません。わたしはかつてsfdformという98上のフォーマッタを公開していた事がありますが、OSがsfdを認識できたのはWindows95までだったと思います。少なくともWindows2000以降はsfdをきちんと認識できません。まっさら状態からWindowsのディスク管理でフォーマットすると必ずMBR形式になります。
参考 sfdについての解説記事（注意!!このソフトを使うことを推奨しているのではありません）
ttps://www7b.biglobe.ne.jp/~marimo9821/pcat/sfdform.html
すでにsfdでフォーマットされているものをMBRの形式に変更するには、LBA0番地を指すパーティションテーブルを記入する手があります。ただしWindows/DOS機の方でそのUSBメモリのブート用IPLを使っている（特殊な）場合、それに悪影響を及ぼす可能性があります。
なおOneさんのドライバはUSBメモリの総容量をファイルシステム外で取得するようなことはしていないようなので、2GB以上のUSBメモリであっても2047MiB以内のFAT16領域を作っておけば大丈夫です。もう2GB以下の物は売ってもいませんし、昔の物は概して書き込みが遅いので、無理して使うこともありません。
Windows/DOS機でフォーマットするとき、予約セクタ数＋FAT＋rootディレクトリの次が2の乗数の倍数になるようにしておくと、USBメモリの書き込みが速くなる（Windows機側で）可能性があります。ブロック境界をまたぐ無駄なread modify writeが起こらなくなるかもしれないためで、書き換え寿命にも少しメリットがあります。WindowsVISTA以降ではそのようにしてくれるので、気にしなくても構いません。WindowsXP以前だと疑問があります。
参考 →の一番最後 ttps://www7b.biglobe.ne.jp/~marimo9821/pcat/aft_drive.html
|
| スーパーフロッピー形式 One 2026年1月2日(金) 10:18 |
＞OneさんのUSBストレージドライバでスーパーフロッピー形式（以下sfd）が認識できないことは気がついていましたが、
自分の手抜きドライバの中身がばれてるw
先月のI/Oを隣にずらしての件も、設定できるようにしようと思いつつ面倒でやってなかったところでした。
スーパーフロッピー形式ですが、Xのドライバの使用報告を聞いてとりあえずLBA 0番地の最後を見て0xAA55かで判定してMBRが有効でなければLBA 0をBPBとみなしておくように書いておこうかと思ったんですが、本当はいろいろ怪しいですね。実害はほぼないのですが使えないのが気持ち悪いのでやっておくかもしれません。
あと、LBA 0番地をBPBにしたUSBメモリはWindows11で違和感なく認識されて使えそうでした。
ちゃんとした作り方がわからなかったので、BPBから始まるイメージを作ってDDでUSBメモリに書き込みをしています。
|
| SFD形式ってDOS時代の必要惡の産物？ かかっくん 2026年1月2日(金) 18:47 |
SFD形式わ窓9xでわサポートされて居ましたがNT系でわ碌にサポートされずMO全盛の頃わ各社が
MOドライブにSFDフォーマッタを添付して居ますた
M$がNT系でサポートしなかった理由と云うより窓〜9x(と云うよりDOS)でサポートする必要が有った
理由わDOS起動時点でブロックデバイスのドライブレターを確定する必要が有ったからのやうな？
専用DRVを入れずに起動するとMOにドライブレターが1ッ鹿割り当てられません
すると複数の領域が有っても第1エントリの領域鹿マウントされないと云う事に成増
# M$CDEX他を通す円盤わブロックデバイスとわ見做されず
NT系わ其の必要が有馬せんから積極的にサポートしなかったのでせう
もっと根本の問題として他機種でフォーマットした媒体が使用される場合も有馬す
98フォーマットのHDDをFM系やX68kで認識出来ないのと同様MO他も他機種で其の機種用にフォー
マットした物をDOSだけでわ認識出来ません。実際5インチMOの際わ混乱しますた
で128Mの3.5MOの場合DOS5を前提としたIBMフォーマットを規定し此れがSFDとして定着しますた
此れに由り媒体各社がFD同様DOS・窓フォーマット済MOを出す事が出来ますた
# 苹果用？旧苹果OSがリムバ全般を認識しなかったからドライブや別賣りのフォーマッタ
# (SilverliningとかHDTとか、後年わDrive7とか)に憑いて来るDRVを入れて対応
# 此れが仇と成りフォーマッタとDRVの相性が生じた
# 後年にわOSがリムバに対応して、フォーマッタも純正の【ドライブ設定】で対応したので収束
# (此の対応にわ一時期の旧苹果OS互換機も関係するらιぃ。互換機万歳)
> スーパーフロッピー形式ですが、Xのドライバの使用報告を聞いてとりあえずLBA 0番地の最後を見て0xAA55かで判定してMBRが有効でなければLBA 0をBPBとみなしておくように書いておこうかと思ったんですが、本当はいろいろ怪しいですね。実害はほぼないのですが使えないのが気持ち悪いのでやっておくかもしれません。
MBRもPBRも最後がAA55hナノで区別に成りません。其の前の64バイトの内容がパーティションテー
ブルの形式に成って居るか否かを調べる必要が有りそーデスが、其の部分がIPLコードの場合も有馬す
から出鱈目な内容ならPBRと見做すとか？
あとSFDであればFM系FDのやうに文字列から始まる事わナイでせうからjmp shortかjmp nearか
否か(MBRのIPLコードわjmpせずに書かれる事が多い)で判定するとか？
|
| 0xAA55ではダメですね One 2026年1月3日(土) 0:28 |
＞MBRもPBRも最後がAA55hナノで区別に成りません。
その通りですね。朝あまり考えずに書いてしまいました。
ざっくりMBRいくつか見てみると、CLI命令やXOR AX,AXからSS,SPを設定する流れが多そうで、さすがに0xEBや0xE9から始めることはなさそうが98とか考えるとちょっとややこしそうですね。
一般的な振り分けアリゴリズムはどこ判定なのでしょうね。
|
| FAT確認 リウ 2026年1月3日(土) 11:26 |
 オフセット36h(10進数54) FAT種別文字列
私はここの値を見て確認していますが緩いとは思っています。
|
| MBR優先で まりも 2026年1月3日(土) 13:22 |
 ＞一般的な振り分けアリゴリズムはどこ判定
結局のところ「決め手」がなくて、可能性の高いものとして判定するしかないです。拙作FDSK(PC/AT用)では先頭セクタの素性判定は画像のようにしていますが、SFDは完璧性というものがなく、試行錯誤しました。
「以前にはSFDであったが後でMBRになった」という場合はどうやっても決定できません。フォーマッタ（FDISK相当の機能を持つディスク管理プログラム）によっては、ブートIPLを一切触らないようにしていているものや場合があって、そのときはパーティションテーブルと末尾の55AAしか書きません（read-mod-writeをしてしまう）。その結果SFDの情報とMBRな情報が併存するけども一致しないという状態になります。したがって一応両方のチェックはするけどもMBRを優先しておくほうが無難です。Windowsもそのように扱っている感触です。
パーティションテーブルには「セクタ番地0から始まる」と書いておくと、PBR=MBRという意味になるだけなので、SFDで扱われてもMBRで扱われてもよいことになります。0から始まるのを不正と見なすシステムはたぶん無いでしょう。このこと自体がIBM-PCの仕様から来ていることなので。
扱いとしては以下のような感じでしょうか。ただしパーティションテーブルの解読は手間とコードサイズがかかるのでやりたくないですよね。デバイスドライバの常駐サイズまで増えてしまうほどならSFDを見ないほうがいいと思っています。
末尾55AAあるか？パーティションテーブルはあるか？ ある→MBRで扱う これだけでもよい
↓なさそう（パーティションテーブルの中身が怪しすぎるなど）
先頭ジャンプ命令EBあり、"FAT 16"のシグナチャがどこかにあるか？ ある→SFDで扱う
↓なさそう
システムを判定できないので拒否
|
| どこまで判定するか悩ましい One 2026年1月3日(土) 23:48 |
リウさん、まりもさん 情報ありがとうございます。
＞結局のところ「決め手」がなくて、可能性の高いものとして判定するしかないです。
ってことなんですね。ドライバで考慮しようかと、ちょっと考察をし始めるとややこしいことに気が付いてどうしようかと思っていたところでした。
USBのマスストレージって考えると例えばCFをアダプタを介してつなげばセクタを読むことができますから、様々なフォーマットがあることになってしまうので・・・
判定だけもややこしいなと思いつつ、PC-98で使っているHDDやCFをUSB変換して繋いだら読めるとちょっと嬉しいかもしれないなとは思いました。
98なのでそのまま挿せばいいし、DDでイメージ化すればなんでもできるのでそれほど需要はなさそうですが。
|
| 1/2版 KAZZEZ 2026年1月7日(水) 0:31 |
大熊猫さんのPCIFLASHでVT6421L（Winbond W49V002AP）にも書き込むことができました（ありがとうございます）。ITE8212の大熊猫BIOSは20年くらい前から使っていたのですが、気付いていませんでした。(汗
1/2版のvt6421.pciを書き込んでみたところ起動障害は無くなりましたが、ボードを認識した表示が出ず、FDSK98も装置を見つけませんでした。ヤドカリブートはできても該当ボード上のROMでは動作しないというのは何が原因なんでしょうね。barcheckやuideinfでは見付かるようです。図（左）はSATA1に8GBのSSDを繋いだものです。なおオンボードIDE-HDDは繋いだままですが、切り離す設定にしてあります。
[1/8 0:10頃追記] 1/2版でヤドカリブートしようとしたところデバイス表示がうまくいかずに止まってしまうようでした。もちろんVT6421が無ければPCは起動しますので旧版に戻しました。ヤドカリブートできる旧版でもVT6421ボード上のROMだと機能しない点は同じでした。
HPT368（hptbios.pci）のほうはuideinfが実行するたびに出鱈目な値を返すようで、図（右）は例の40GBのHDDを31.5GBに制限したもの…のはずなのですが、どうも表示が一定しません。何も文字列が無い場合もありました。やはり削った部分が無駄ではなかったような感じです。
ところでHPT368をPCIflash5の改造品で書き換えるとき、なぜかROMアドレスが2xxxxxxxのときは成功するのですが、4xxxxxxxに割り当てられているときはROMチップのIDにアクセスできないとかで書き換えられない様子でした。このあたりでもHPT36xは不安定なんでしょうかね。
|
  |
| テスト大感謝です リウ 2026年1月8日(木) 3:24 |
いつもテストありがとうございます。お時間いただけてとてもうれしいです。
さて手元で確かめましたところ、VT6421だけInitializeのreadybit判定が逆判定になっているというポカミスでした。ですが逆になっている限り絶対に動作しない、というひどいバグでした。それを修正しました。実カードでの動作が起きない、というものはsubclassの値が00で本物CARDでは04HのRAIDを示す数値とずれていたせいであろう、と睨んでいます。変更しました。動くようになっていることを期待します…。
HPT368はROMを書き込んだ状態ではIO反応が狂っているのが目に見えていますことから本物BIOSROMの中の数値が400hからだけではなく、他の場所も使われているのでは?と感じています。ヤドカリ形式でしかまともな動作を行えないかも?と本物BIOSの隙間を使う方法を考え始めています。
TX2000は強敵で…書き込みで8kBまでしかまともに転送できず、データ化けを起こしていることがはっきり判明しましたのでバイナリ削除中になりました。MMIOの未判明bitか判明しているPLLクロックのタイミング設定でなんとかなればよいな、という淡い期待です。
1/9大量追記
VT6421用ROMが実カードで動作しない、ということについて
まずは動作初期にBEEPを鳴らすコードを付け足しました。鳴った場合は動作しています、すぐに鳴り止んでしまった場合は失敗の方に飛んでいるという結果になります、修正を考えなくてはいけません。そもそも鳴らなかった場合はハードウェアプロテクトかも?
またbarcheckにATABIOSが配置されているかの表示を足しました。
TX2000は強敵でした。結局書き込みコマンド1回毎に out 43f a0を入れるとがちっと安定してデータ化けを起こさず書き込めるようになりました。全く理解不可能です。IOでやりとりしているはずなのにCPUがOSとのやりとりでディスクバッファのキャッシュフラッシュをうまくやらないようです。他の石では不要なのでとても不可解ですが、今のところうまくいき、無事にWindows98Seの新規インストールが完了できました。(のでCBUS用バイナリは復活しています。)ただしやはりWindows9x用ドライバがRAID構成をうまく処理してくれませんでした。255:63に合わせればうまく行くかも、との目論見はつぶれました。
HPT368もこのようなカード毎に起きる何かがあるのかもしれません。PIO転送ならどれも同じであろう、という軽い気持ちでやっていますが、解決できていなくて心苦しいところです。何月何日版のものだと化けない、という記録を残していないのでどれが悪影響なのか…
|
| 1/8版 KAZZEZ 2026年1月9日(金) 1:26 |
こちらこそ不定期な報告でお手数をお掛けしている状態で恐縮です。m(_ _;)m
1/8版のPCI版ではとりあえず大きな変化は無さそうでした。VT6421はヤドカリブートはできるように直りました（セカンダリスレーブの表示も直りました）が、VT6421ボード上のROMに書き込んだものだけでは認識せずbarcheckやuideinfも前回と同様な感じでした。
HPT368版のYADOKARI.HPTについても特にデバイスクラスらしき部分はいじらずに従来通りPCIRのIDだけ直してSiI3112ボードに書き込んで試してみましたが、HPT368ボードが存在すると黒画面で止まってしまうようでしたので、ヤドカリブートで実行はされているのかもしれません。なおHPT368ボードのほうにも無改造のYADOKARI.HPTを書き込んでありますが、こちらだけでは実行されないようでuideinfの挙動も前回と変わらないようでした。
|
| 大変申し訳ありませんでした。m(_ _;)m KAZZEZ 2026年1月9日(金) 23:36 |
> 何月何日版のものだと化けない、という記録を残していないのでどれが悪影響なのか…
試験機(Ra223)を詳しく調べたところ、テストに使っていたIDE-HDDのペリフェラル電源コネクタの分岐ケーブルの5V線に接触不良が見付かりました。たまたまVT6421に繋いだときは通電していたようで、その後VT6421ではSATA側でテストしていたので発覚しなかったようです。IDEケーブルだけ繋いで電源が入っていないときにとんでもない値が帰ってくるのは納得です。(汗;
タイミングとしてはちょうど
> HPTのものはあぶなそうなPCI config空間へのアクセスをやめました。
のときでしたので、てっきりその影響かと思っていたのですが、全然関係ありませんでした。重ね重ね余分なご心配お手数ご迷惑をおかけしており申し訳ありません。m(_ _;)m
ちょっとだけ言い分けしますと(ぉぃ)、Ra本来の2ndHDD金具は2ndFDDの下に付くタイプで、CPUと干渉しやすくCPU下駄と併用できないのでRa40/43非対応のやつです。CPUは元のPenIIに戻していますがそれでもスペース(に余裕)が無いので電源ケーブルにL字コネクタを使っていたのですが、L字のやつは電線の曲げに弱いようで、頻繁にいじっていると電線がコネクタから抜けかかってきます。気付いたときには5V線が完全に脱落しておりました…。(汗;;;
なおSiI3112ボードに書き込んだYADOKARI.HPTについてはHPT368が存在すると黒画面で止まってしまうのは同じでしたので、HPT368ボード上のROMに書き込んだときのbarcheckとuideinfを示しておきます（例によってICCFIXで31.5MB制限済みのHDDです）。
[追記] 長時間待てばヤドカリブートの3112ボードありでも起動しました。3112が存在するためIRQとI/Oのリソースが変わりますが、それ以外はbarcheckとuideinfの結果は同じようでした。
|
 |
| L形の電源コネクタって線が外れ易い かかっくん 2026年1月10日(土) 1:35 |
> ちょっとだけ言い分けしますと(ぉぃ)、Ra本来の2ndHDD金具は2ndFDDの下に付くタイプで、CPUと干渉しやすくCPU下駄と併用できないのでRa40/43非対応のやつです。CPUは元のPenIIに戻していますがそれでもスペースが無いので電源ケーブルにL字コネクタを使っていたのですが、L字のやつは電線の曲げに弱いようで、頻繁にいじっていると電線がコネクタから抜けかかってきます。気付いたときには5V線が完全に脱落しておりました…。(汗;;;
L形のってMolex(通称)もSATAも圧着(カシメ)でなく圧接のが多く線が外れ易いので、半田付けすると
外れ難く成増。お試しあれ
|
| CFのread-modify-writeのペナルティ？ まりも 2026年1月10日(土) 11:17 |
EXIDEPCI V5.31を使っている西側国の骸骨人が言うには、
・インダストリアルなSandisk製の32GB未満のCFを使っている、本体は9821Xv13 with K6
・CFを３領域に分け、うち１つは128MiBでFS ID=91hのセクタ長2KBのFAT16である
・Head=16,Sector=63 で使うと連続書き込みでエラーが起こり再起動しかなくなる
・Head=8,Sector=128（たぶん32ではない）で使うと問題が起こらない
・いずれにしてもscandiskで読み込んでエラーは出ない
だそうです。どこに問題があるのか聞かれてもわからんですよね。CFでなくHDDで試してというほかはありません。あるいはDIV0ROMだけ適用のうえH:S=8:17で使ったらどうなるか、リウさんのLBA_IDEではどうなのかを聞くしかありません。
MS-DOS 3.3互換のセクタ長2KBの領域をDOS 5から7で使うのもどうかと思うのですが、さらにSmartdrvも併用しているようです。そもそもこのタイプの領域にSmartdrvが使用できたのかどうか？ここも疑問点です。
H:S=16:63のとき かつ、書き込みでエラーが起こるというのが鍵でしょうか。EXIDEのモード1を使っており、CFリセットによるH:Sパラメータ喪失は無関係と思われるからです（しかし潜在的にCFリセットが起こって転送速度が落ちている可能性はある）。またCFリセットは読み込みだけでも起こりえますが、Scandiskでエラーが無いことから関係なさそうです。
ひょっとしてCFの read-modify-writeが間に合わなくなるとこのエラーが出るのではないでしょうかね。実はWestern Digitalの初期のAFTドライブを98のDOSで使ってみて経験したことがあります。
CFをオンボードIDEで使っていて、「CFリセットではないと確実に言えるけども連続書き込みでエラーが出た」という経験をお持ちの人はいますでしょうか？
|
| ディスクバッファのCPU側キャッシング リウ 2026年1月10日(土) 12:32 |
以下戯言ですが書き残します。
TX2000経由の書き込みでは謎の挙動の原因がタイトルの通りでした。
CPUキャッシュを切れる機種ではなさそうなので、適当なCPU操作ソフト（HSBでよいです）でキャッシュオフにしても同じことが発生するか？と確かめてもらうことが、HDDに入れ替えたりLBA_IDEを新たに導入してもらわなくても確認できる一つかと
|
オンボードIDEのためCPUが知らずにメモリにデータが転送されることはないので、CPUキャッシュの影響は受けないはずですが、smartdrv は怪しいかもですね。とりあえずsmartdrvは使うな、CF specificな問題だろうから違うメディアにするようにと返答しました。2KBセクタサイズの領域の使用はゲーム起動用DOSの関係で避けることができないようです。
TX2000はPCIデバイスですが、ふつうはPCIチップセットとCPUが連携して、データ転送先をキャッシュしないようにする（キャッシュしたままにしない）はずです。TX2000は持っていないのでわかりません。その先祖にあたるfasttrak 33と66ならありますが、おそらく大分違うでしょうねぇ。
|
| VT6421 大熊猫 2026年1月11日(日) 21:44 |
>VT6421
えええ、シリアルROMなのにあれで書き込みできましたか！？
実は当時VT6421もIDE相当で独立3chの標準的じゃない変な構造(下記)ということは分かっていて、
ブリッヂ無しのUSB、1394、LANの多機能ボードも個人輸入してあって、ATAPI機器がSATAに完全移行が遅れていた間、そのつなぎには良さそうに思っていました。
が、55h,AAhとかの書き込みコマンド発行している部分が見当たらず、書き込み方法が分からないので放置していました。
BAR0 16BYTE I/O;SATA CH.#1?
BAR1 16BYTE I/O;SATA CH.#2?
BAR2 16BYTE I/O;SATA CH.#1?ATA?
BAR3 16BYTE I/O
BAR4 16BYTE I/O;busmaster register(CH.#1h +0,CH.#2h +8,ATA +10h)
BAR5 32BYTE I/O
;7BYTE単位の構造体
3DE2 DW ;0のCOMMAND BLOCK REGISTER IO ADDRESS
DW ;CONTROL BLOCK REGISTER(10h,14h,18h+08h)
DB ;割りこみ
DW ;BUSMASTER REGISTER
3DFE DB バス番号
DB デバイス、機能番号
3E00 DB 01B0h DUP(0h)
409E DW Config +24h
4DB0 DB A8h,65h,65h,31h,20h;PIO転送モードに応じて書き込む値
4DB5 DB EEh,E8h,E6h,E4h,E2h,E1h,E0h;UDMA転送モードに応じて書き込む値
CMD649が出ていたころは各社からUDMA100〜133対応のボードが出ていて、CMD遅いとか散々な評判でしたが、複合ボードがないとやる気にならないのと価格、流通量、玄人志向マンセーでSiIのチップで書いていました。
プロミスは速いが化けるのでご利用は計画的に、と2chでは書かれていた覚えがあります。
Highpoint, Promiss, Acardを抜いてなんだかんだでPCI express以前はSiIが一番素直に動く広く普及したチップでした。
|
| FASTTRAK リウ 2026年1月12日(月) 12:50 |
まだPCIBIOSとしてROMに書き込んだ人はいないと思いますが
プロミスのカードもROMの中身からデバイスIDを作り出すタイプでした。
極めて厳しく20hというPC-98にとっては超超重要場所を参照しています。
一度でも私のプログラムを書き込んでしまうととんでもないことになりますのでやらないでください、と注意喚起だけやっておきます。自己責任という言葉で逃げますが。
1/15追記
結局手持ちカードはTX2000だったものがTX2になってしまいました。デバイスIDも6269hではなく4D68hを返してきます。公式書き換えプログラムが石に対して何かをやってるとは思います。注意です。
で、公式書き換えプログラムはプロテクト的なこともやってそうなのでそのパッチ情報だけは1/15版に情報としていれておきました。ただし書き換えは完全に自己責任で
そしてWindowsドライバが全くだめです。Windows9xではTX2としてドライバは登録され、HDDもデバイスマネージャから見えていますが実態はInt1Bアクセスのままでした。WindowsNT4はインストール時にF6を押してもドライバディスクを見つけてくれません、Windows2000はインストール時にドライバ指定はできましたがブルーバック直行でした。ということでPromissのカードでは大容量が使えるだけですね、今のところは。これなら内蔵IDEでも構わない、という状態です。out 43fh,A0hは遅いのでリアルモードである場合はwbinvdに変更しました。
VT6421の状況ありがとうございます。全く動作してなさそうです。
8kBサイズではなくBIOSファイルだけは64kBサイズにしてみました。状況変わらずかもですが
本物は64kBもあるのでPC/AT版BIOSと両用できる気がしています、がTX2000で痛い目にあったので今は封印ということで…
データシートを見直してセカンダリスレーブのタイミング部を修正しています。
HPT368はセカンダリ側の割り込みを封印してみました。それだけです…。
しかしやはりバスマスタのDMA動作はさせないと優位性がありませんねえ…。内蔵IDEの使いにくさからは開放されて、自作BIOSなのでやりたい放題なのは私にとってはとてもおもしろいのですが。
1/17 0:10追記
Windows3.1(のDPMI)がIO43fhにトラップしてそうな結果がでました。
またCPU命令のwbinvdではオンボードL2キャッシュがフラッシュされません。
ので1/15版のTX2000用BIOSもまだまだバグ状態です。近況報告として
0:25後方参照追記
上の報告を書いてから気づきました。
VT6421の64kBサイズROMでの報告ありがとうございます。いや困りました。手詰まりです。これもなんらかのプロテクトでしょうか。HPT368の方は時間待ちすると起動してくる、という話から実行だけはされてそうなのですが…
|
| 1/9版 KAZZEZ 2026年1月14日(水) 1:05 |
> シリアルROMなのにあれで書き込みできましたか！？
W49V002APがシリアルROMかどうかとか全く考えていませんでしたが、表示（左図）を見る限り32KB単位で書き込んでおり、成功しているように見えます。書き込んだものをPCIXROMで吸い出してFC/Bで比べても相違はありませんでしたし、元のBIOSに戻したとき（図の右側）も同様でした。
> 20hというPC-98にとっては超超重要場所を参照しています。
PC98シグニチャが無いときはAT互換機仕様でROMが実行されるということですから、そちらで何とかなれば良いのですが…。
> 動作初期にBEEPを鳴らすコードを付け足しました。
ありがとうございます。VT6421の1/9版もやはりボード上のROMではSSDを繋いでも認識しないようでした。BEEPも全く鳴っている感じではありません。聞き取れないくらい短時間であるなら分かりませんが…。barcheckの結果図はSATA1に1台繋いだだけのものです。
----1/15 2:15追記----
話は変わりますが1年くらい前にバッテリをCR2032に交換したH98/U90（相当品）ですが、もう電池が切れたと見えて電源OFF中に時計が進まなくなりました。CR2032の静電圧は0.4Vくらいに低下しており、リファレンスディスクは要求されませんでしたので設定内容が消えるよりも先に時計が止まる仕様のようです。電池ホルダー化してありますので簡単に直りましたが、やはりCR2032ではあまり長く持たないようですね（多少使い古しのCR2032だったというのもありますが）。マンガン電池2本とかのほうが良かったのでしょうか…？
ところでH98m90といえばODPを載せるとCPU交換を認識して表示に反映されるという話がありましたので、分解ついでに試してみました。
weblabo.griffonworks.net/dorlog/2nddorcom/pc-98/6880.html
少なくともDX4ODPでは486SX表示のままだったのですが、DX2ODPは持っていませんので、コプロソケット脇のジャンパ変更で486SXを停止して、普通のDX2（CPUID=0435）で試してみました。…ODPではなくともDX2なら表示が変わるんですね。そして$ログの通り、386相当や8MHz相当モードとかが反映されなくなりました。低速モードを使うならDX4ODPのほうが良さそうです。手持ちの個体はもともとFDDが若干不安定ですので、よく言われているFDDへの悪影響はよく分かりませんが。
一方でCPUID=0404の486DXは487SXとは見なされずITF表示は486SXのままです。本当に限られた範囲のCPUIDしか見ていないようですね。
----1/15 2:25後方参照----
> BIOS-ROMの多くのピンがほとんど未結線
私の手持ちのものはジャンク入手ですが、恐らく玄人志向から流れてきた青い基板のもので、SAPARAID-PCIと思われます。画像は検索で出てくると思いますが、言われてみればROMチップには未結線のピンが多いです。
----1/16 22:25----
とりあえず1/15版のPCI-ROMを該当ボードに直接書き込む限りでは、特に変化はなさそうでした。barcheckもVT6421版は変化が無く、HPT版でセカンダリが1fから5eに変わったくらいでしょうか。
|
   |
| VT6421のLPC接続 大熊猫 2026年1月14日(水) 21:11 |
 レスありがとうございます。あぁ、思い出してきました。
当時は、BIOS-ROMの多くのピンがほとんど未結線なので、VT6421との間はLPCモードでの接続と考えていて、ソフトウェアから意識せずに、透過的に、まさか単純にPCI拡張ROMアドレスから書き換えられると思っていませんでした。
何か複雑なことが必要だろうと思い込んでいたのです。というか、今、データシートも公開されているんですね。
2011年に個人輸入したものですが、世の中には画像のような怪しいコンボカードもありました。VT6421.INCを書いて、BIOSがまともに動いてWindowsのドライバが連携して動く、かつROM書き込みの手段が確保できたら玄人志向に販売希望出そうとか思っていたこともあります。
なんと、PCI-PCIブリッヂがないのでそれによる相性問題や性能低下もないはずで、IEEE1394のMMIOを拡張ROMエリアに出すこともできます。
chanpon2 TURBO-PCIと同じくIDE/SATAデバイスを4つつなげて、とくに、当時の日本企業のATAPI機器が良すぎたので後方互換のIDEポートがいいなあと思っていました。
|
| PCIチップセット機で直にCPUのキャッシュ関連ピンを操作できるのか まりも 2026年1月17日(土) 16:32 |
リウさんの17日追記ぶん
＞Windows3.1(のDPMI)がIO43fhにトラップしてそうな結果がでました。
＞またCPU命令のwbinvdではオンボードL2キャッシュがフラッシュされません。
機種は何を使っていますか？ 430VX機だと2行目のことが起きます。山猫でも怪しいです。
PCI機ではout 43Fh,A0hが果たして機能するのかどうかわかりません。この出力はCバスに流れてきており、そもそもPCIチップセットに作用するはずがないように思います。外部回路からCPUの何かしらのピンに直接作用させている可能性は残されていますが、そんなのでチップセットとの整合性が果たして取れるのかどうか？
という点から、やはり何も行っていないのではないでしょうか。ITFなどでは43FhをA0hで叩くコードが入っていますが、あっても無害なので削除していないだけかもしれません。mate-Rではout 43Fh，A0hは非常に限られたところ（CPUのF0 reset 突入前など）だけに存在し、オンチップL2キャッシュ制御を行っているようなところには入っていません。なので、もし機能があるとしても、out 43Fh，A0hはCPUやチップセットに作用するのではなく、98-CバスブリッジかCバスに繋がる周辺回路へキャッシュを無効にしたことを通知する目的なのではと思います。
あと、山猫機ではPCIのIDEボードは、たとえPIO転送であろうとも、まともに動作しないと思っています（根拠はなく経験で）。実験するなら430FX以降の機種でないといけないでしょう。
|
| PCIカードのPIO転送が化ける リウ 2026年1月17日(土) 18:34 |
最近試しているのは430NX(PCIバスが2本必要でした)のPC-9821Xa無印です。
さきほど430VXのV166D2も再度出してきまして試験を開始できる準備を行いました。
状況を説明します。これはXa無印の場合です。オンボードの2ndCacheが256kB存在します。
PromiseのTX2000とTX2に化けてしまったカードが2枚あります。自作BIOSでPIO転送で書き込みをすると化けます、対症療法として書き込み1コマンド毎にIO43fhにA0hを叩くことを行うと全く化けなくなりました。
この対処だけでWindows98Seのインストールまでは何度も成功しています。
しかしWindows3.1のインストーラが必ず途中で暴走します。(そしてテスト用HDDがさきほど壊れました。原因はHDD側にあるかもです。)IO43Fhへのトラップがあるのでは?と妄想しました。ですので仮想86かのフラグチェックをして、512kBの無駄読み出しを挟んでみました。これで無事に暴走はしなくなりました。(とても遅くなりますが)
それを行わず、PCIチップセットの50hでCPU側のキャッシュを切ってから書き込みを行っても(動作はとても遅くなりますが)化けなくなりました。
これらの結果からIO43FhのA0h出力でキャッシュフラッシュができると思っていますが、そもそもPIO転送なのにキャッシュフラッシュが必要、という想像もとても気持ち悪いです。そのため謎の山猫の変な挙動とも関係があるのかも?とつぶやきました。
ただ、この対処などでデータは化けなくはなったのですがWindows3.1の日本語MSゴシック、MS明朝のフォントファイルの結合で必ず失敗を起こします。インストールがまともに終われません。(これは私の書いたキャッシュフラッシュ部のバグでした。直したら430FX機でインストール完了しました。)
なお、VT6421でのPIO転送ではこんな余計な対処の必要もなく、インストールが成功していました。
というところでV166を出してきたのでまた試験を続けてみます。とりあえずきちんと動作するHDDの準備からです…。
直後追記
上記対処が行われているBIOSをTX2に書き込んでV166で起動させました。化けました。キャッシュフラッシュが必要という妄想が正しいという前提下(この前提がそもそもおかしい)ではこの機種ではIO43Fhでキャッシュフラッシュできないようです。敢えて仮想86環境に入り、遅いモードを使うと書き込みが化けなかったことまで確認、気持ち悪いですねえ…、そしてV166でこの石をまともに使うにはなにかをやらなくてはいけないと…
22:04追記
Xb10な430FX機でも43Fh A0hはキャッシュフラッシュされないようです。
で、書き込み1コマンド毎に512kB強制読み出しでキャッシュ吐き出しをする(バグってたので修正しました)ことにすると無事にWindows3.1がインストール完了しました。
気持ち悪いです。山猫+PCIIDEで同じことが起きているかはわかりません。
18日9:30追記
MWIに関してありがとうございます。
残念ながら430NXではホストのcommand bit4はROのようでした。Promiseのカード側もROのようで変更不可でした。落ちたままでした。
IO43Fhに関して、Windows3.1がトラップしているのは確定しました。Windows3.1のコマンドプロンプト内でIO43Fhの22hを叩いてもEMS側メモリに切り替わりませんでした。
1/19 18:15追記
www7b.biglobe.ne.jp/~drachen6jp/山猫.txt
山猫のチップセットconfigについてまとめちまいました。
パリティチェック関連を一応それっぽく(EDOフラグとインターリーブフラグはここのログ以外ではインターネット上におそらく出てきてないのでは?)
さて、先日から続いているIDEのPIO転送でのデータ化けですが、スタック領域が化けていることがデバッグトレースでわかりました。ですが起きていることを説明できません。知らないタイミングの割り込み(NMI?SMI?)が発生してメモリ書き込みされている?とは想像しますが、キャッシュフラッシュをすることでそれが起こらない、ということとの整合性がつきません。
またL2キャッシュまで含めて全部フラッシュする必要がありそうです、そのため搭載L2キャッシュサイズをいちいち調べる必要があります。(山猫機ではL2は抜くのが吉です!)上記山猫.txtはその必要性からまとめなおしたものです。実に辛いですが楽しいです。RCCチップセットは気が向いたらまたまとめますが不要ですよね。
1/20 11:40追記
ttps://www7b.biglobe.ne.jp/~marimo9821/util/memsetup.html
memsetup的なことをすれば山猫で超容量メモリが使えるかも?な調査を追記しました。おもしろいですね
|
| PCIバスの転送モードに まりも 2026年1月18日(日) 8:41 |
 PCI memory write and invalidate というのがあります。通常はこれにより、PCIバスマスタで書き込んだメモリのキャッシュは解除されるはずです。ところが何かの理由でこの転送モードが使われると不具合が起こることがあります。RvIIでは起こりやすく問題になるので、拙作PCISETでは動作禁止にできるオプションがあります。
MWI ビットを無効にするだけですので、まず試してみるとどうなりますかね？
【19日追記】これは関係なかったですか。そもそもが山猫機などではホストブリッジ側がMWIはサポートしていないようですね。
ところで山猫機のL2キャッシュですが、以前も指摘したように、L2Cを装着するとかえってメインメモリアクセスが遅くなります。その割にはキャッシュが切れなくて困る場面は増えるわけですから、使わない方がいいような気もします。画像は、キャッシュ有無でのメモリアクセス速度の比較です。EDOメモリを搭載し、WCATEDOで高速化してある状態なので、差が小さく出ますが、それでもreadが1.17倍遅くはなります。またキャッシュヒット時とそうでないときの差もWCATEDOを使うと縮まりますから、L2Cはますます要らん存在でしょう。
希少で高価になったL2Cを血眼になって探すよりは、WCATEDOを使いましょうということです。
(･_･)：それより山猫機は窓から投げ捨てたほうがええ言うてへんかった？
|
| L2の所為でRAMが遅く成る原因って かかっくん 2026年1月20日(火) 22:50 |
L2の所為でRAMが遅く成る原因としてTAGRAMサイズとか(仕様としての)キャッシュ可能空間とか
有りそーな？
何方もRAMサイズと関係有馬すがRAM 8Mと128Mで差が出るなら此の辺が原因でせう
# 後者のレイ 430VXや430TXが64M迄とか。超えると超えた空間にL1鹿利かない
# 尚K6-IIIやK6-2+の内L2わ↑両者の制限を受けない(?)
|
| PC-9801N-08とスイッチバー かかっくん 2026年1月29日(木) 15:27 |
今迄気付きませんでしたが、WikiのCバスの項に
---
規格
Intel 8086のCPUバスに準拠。
ただし、1985年発売のPC-98XA以降の機種では、Intel 80286に対応し、アドレス線が20bitから24bitに拡大されている。PC-9801N接続時、AB201〜AB231出力はHighレベル固定[1]。
[1] Note拡張ユニット 1990, p. 29.
参考文献
『PC-9801N-08 I/O拡張ユニットユーザーズマニュアル』NEC、1990年。
---
と有馬すた。Nのくだりわ知りませんですた
とわ云えPC-9801N-08にスイッチバー有の板って差さるンでせうかねぇ？
# UV21以降のV30機のスロットわスイッチバー有でわ差さらない籠に成って居る
# 但しPC-9801N-08がN,NVとNS以降で共用なら其の限りでナイ
# えぷPC-286のV30機(286Uとか)わ不明
# XAもスイッチバー有が差さらない籠の為みいそ純正でXAやV30機対応の板わスイッチバーが
# 折れる仕様
|
|
|
