| 98システム解析スレッド2025年8月 リウ 2025年8月1日(金) 2:46 |
| ASPIマネージャ くりすと 2025年8月1日(金) 10:21 |
PC-98用は商品としてASPIマネージャ(PS98-1223-W1)を販売していましたからさすがにダウンロードはできないかと…
ttps://support.nec-lavie.jp/support/product/data/spec/sft/94100056-1.html
CBUSが92以前、PNPが100、PCIがX-B02以降でしょうか。
ちなみに、このFDは以下の構成です。
A:\>DIR D:\ /S /A
ドライブ D: のボリュームラベルはありません.
ディレクトリは D:\
INSTASPI BAT 4,945 94-11-13 0:00
WINSTA BAT 4,323 94-11-13 0:00
WAID1 CMD 322 94-11-13 0:00
WAID2 CMD 369 94-11-13 0:00
WAID3 CMD 346 94-11-13 0:00
WAID4 CMD 195 94-11-13 0:00
WAID EXE 19,403 94-11-13 0:00
CBUS <DIR> 94-11-13 0:00
PCI <DIR> 94-11-13 0:00
PNP <DIR> 94-11-13 0:00
10 個 29,903 バイトのファイルがあります
ディレクトリは D:\CBUS
. <DIR> 94-11-13 0:00
.. <DIR> 94-11-13 0:00
VASPID 386 9,464 94-11-13 0:00
CBUS DAT 30 94-11-13 0:00
WINASPI DLL 6,304 94-11-13 0:00
ASPIGOGO SYS 4,086 94-11-13 0:00
6 個 19,884 バイトのファイルがあります
ディレクトリは D:\PCI
. <DIR> 94-11-13 0:00
.. <DIR> 94-11-13 0:00
VASPID 386 9,306 94-11-13 0:00
VSCSID 386 11,111 94-11-13 0:00
PCI1 DAT 30 94-11-13 0:00
PCI2 DAT 36 94-11-13 0:00
WINASPI DLL 6,656 94-11-13 0:00
ASPI8DOS SYS 27,192 95-12-05 0:00
8 個 54,331 バイトのファイルがあります
ディレクトリは D:\PNP
. <DIR> 94-11-13 0:00
.. <DIR> 94-11-13 0:00
PNP11 DAT 37 94-11-13 0:00
PNP13 DAT 37 94-11-13 0:00
PNP2 DAT 44 94-11-13 0:00
ASPI2DOS SYS 34,620 95-12-05 0:00
6 個 34,738 バイトのファイルがあります
一覧のファイル総数:
30 個 138,856 バイトのファイルがあります
1,094,656 バイトの空きがあります
|
| PCカードSCSIのASPIドライバ KAZZEZ 2025年8月2日(土) 0:14 |
PCカードSCSIドライバの続きですが、昔ダウンロードしたRATOC REX-9530系と思しきドライバに付属していたASPI対応HDD/MOドライバREXDISK.SYSはNEC FORMAT.EXE 形式（PC-9801-55L/UにつないでFORMAT.EXEでフォーマットしたHDD）に2GBまで対応しているという記述がありました（FDISK形式は7.8GBまで）。他のSCSIでフォーマットしたものだと互換性が無い場合があるそうです。タイムスタンプは99年でしたが92形式に言及が無いということは、やはりHS固定パラメータには対応していないと捉えるべきでしょうかね。
> ASPIGOGO SYS
これも調べてみたら昔ダウンロードしたマクニカMPS-110のドライバに入っていました。MPS-110はPC-9801N-J03RのOEM元ですから、もしかしたらNECのPCカードSCSI（J03/J03R）用かもしれません。カード側のASPIドライバなのかディスクドライバなのかは存じませんが、それにしても55ボードを意図してGOGOなのでしょうかね。追記：検索してみたら普通に55互換ボード用のASPIマネージャだそうで。→ ttp://weblabo.griffonworks.net/dorlog/2nddorcom/98maniacs/199903-199905/sled02993.html
ただ、ファイル名が同じでも機能まで同じとは限らないのが難しいところですが。たしかASPIDISK.SYSはAdaptecとアイオーのもので機能が少し違っていた気もしますし…（うろ覚え）。
|
| Adaptecのドライバ類 まりも 2025年8月2日(土) 12:28 |
ASPI2DOSはBIOS無効で使うと常駐サイズが12KB程度ですが、BIOS有効だと16KB程度になります。どちらかというとAHA-1030は2枚目のSCSIボードという意味合いが強かったこともあって、BIOS有効でASPIを使ったことがあまりなかったのですが、同期転送になるとは気が付きませんでした。
【数値訂正と画像添付】BIOS有効でASPI2DOSを使うとベンチマーク的には32KB転送速度で2500KB/sくらいです。細かいアクセスだと同期転送のメリットがあまり出ず、RAM化の効果のほうが目立つ感じです。
Adaptecの付属ソフトにはASPIDISK.SYSというデイスクドライバがあり、BIOS無効でもSCSI HDDにドライブレターが割り振られてアクセスできます。ところが以前試したところではこれ経由だと結構遅いのですよね。同期転送のはずなのに？です。さらにはSCSI HDDのパーティションジオメトリが8：32でないと認識しないようです。
勝手に非同期はMOドライブの場合にはメリットになります。PC-9821X-02Lのようにデフォルトで同期10MB/sにされてしまうとまずいのですよね。
＞REXDISK.SYSはNEC FORMAT.EXE 形式に2GBまで対応
この値は mode senseで容量を得る 16:63の場合の上限 2015MiBのことでしょうかね。各社のASPIディスクドライバは、どのようなSCSI HDDでのように容量認識するのか、またH:Sがどうなるかなどは、説明書に書かれた仕様だけでは皆目わかりません。パーティションIDがE1hのFAT32に対応したものも無いと思います。Conv98ATをかけてPC/ATのMBRとして認識させるほうが確実性があります。
となると非BIOSなASPI版Conv98ATは必要度が高いかもしれませんが、結局もとのSCSIアダプタ上でのH:Sがわからないことには、領域PBRのパターン検索を全セクタに実施するしかなく、大変過ぎますし、誤り（過去のゴミを見つける）も相当起こりえます。
|
    |
PC-9800シリーズ向けのAdaptecのASPIマネージャですが
2006年ごろは、なんか普通にAdaptecのサイトで公開されていたのですよね。
普通にフルパッケージで転がっていて、当時は気にせず拾ってきて使った話を報告してますし。（汗
ttp://ematei.s602.xrea.com/kakolog/200608.htm
それは既存のを持っている人向けのアップグレード用じゃないのか？って突っ込まれた記憶もありますが
それはいつだったかは探し出してません。
|
| LBA 1に各領域末尾CHSが かかっくん 2025年8月3日(日) 2:49 |
> となると非BIOSなASPI版Conv98ATは必要度が高いかもしれませんが、結局もとのSCSIアダプタ上でのH:Sがわからないことには、領域PBRのパターン検索を全セクタに実施するしかなく、大変過ぎますし、誤り（過去のゴミを見つける）も相当起こりえます。
LBA 1のパーティションテーブルって各領域末尾のCHSが記録されて居たやうな？其れともみいそ/
えぷDOSの領域って(HD)FORMAT(HD).EXEが1M単位で切り捨てて居枡が此の末尾の微調整も有馬し
たっけ？或るいわ末尾わシリンダ境界で、各領域のBPBのセクタ総数だけ切り捨てられて居ましたっけ？
> PC-9800シリーズ向けのAdaptecのASPIマネージャですが
> 2006年ごろは、なんか普通にAdaptecのサイトで公開されていたのですよね。
> それは既存のを持っている人向けのアップグレード用じゃないのか？って突っ込まれた記憶もありますが
> それはいつだったかは探し出してません。
OEM先の製品も動くと云うだけで、元々アダプの製品用デスから
# AHA-1030P→PC-9801-100、AHA-2940UW→PC-9821X-B10、etc.
|
| フォーマット仕様のあやふやさ まりも 2025年8月3日(日) 10:25 |
＞LBA 1のパーティションテーブルって各領域末尾のCHSが記録されて居たやうな？
これがですね、ルールがミイソの中でもあやふやで一定でないというのが問題で、あまり当てにできないのです。
DOS 5-6のformatで作ると、パーティションテーブルには最終シリンダ番号は書かれても、続く最終ヘッドセクタにはゼロが入ります。シリンダ単位だという規則にいつのまにか変わったからです。どうせ見ないからゼロでいいやということにしたようです。DOS 7（Wwindows95A）になると少なくとも開始位置は本当にシリンダ単位でないとブートも認識もできません。
いっぽうWindows2000のディスク管理でパーティションを切ると（切らなくても触ると）、最終シリンダの最終ヘッド、セクタ番号が書かれます。なのでこれらに1を足した値がH:Sとなり、判断できます。仕様としては正しく安全寄りだといえます。最終シリンダまで使うということは、最終ヘッド最終セクタまでを含んでいるはずだからです。シリンダ単位だという規則ならばこれらがゼロだとしても等価です。そうでない規則でも最終ヘッドセクタが書かれていれば安全です。
ということでH:Sを知る手段としてそこはあまり当てにできないことから、IDE-BIOS-LBA-patchでは、MBR先頭のジャンプコードの次の2バイトの使わないところ（NOP命令かゼロが入っている）を、H:Sの記録場所として流用しています。
＞此の末尾の微調整も有馬したっけ？
これもミイソ自身あやふやな仕様にしてしまっており困った問題です。DOS 7のfdisk／formatだとシリンダ単位まで使おうとします。
いっぽうDOS 5-6のformatだときっちり1024KB単位のところに切り詰めて容量を確保します。したがってその末尾から後のシリンダ境界までの間の若干の隙間（無駄）が発生します。領域の真の総セクタ数を、パーティションテーブルに書かれた情報から判断するのはまずいということになります。それ以下の値のどこかです。かつて（1994年以前）この無駄をしゃぶり尽くすソフト（HDU muda）がありましたが、Windows 9xのことを考えると使うべきではありません。
ちなみに拙作formatxでは、それぞれ /Wオプション、/Hオプションを用意して、これらのフォーマット仕様のいずれかを選択できるようにしています。
|
| 自分でした事も忘れるなんて かかっくん 2025年8月3日(日) 21:51 |
> DOS 5-6のformatで作ると、パーティションテーブルには最終シリンダ番号は書かれても、続く最終ヘッドセクタにはゼロが入ります。シリンダ単位だという規則にいつのまにか変わったからです。どうせ見ないからゼロでいいやということにしたようです。DOS 7（Wwindows95A）になると少なくとも開始位置は本当にシリンダ単位でないとブートも認識もできません。
そーですた。DOSのFORMAT /Hの儘でわ末尾がC値鹿入らないのですた(過去ログ参照)
ウチの環境でCHS凡ての値が入って居るのわNP2系でNHDを遣う場合、H:Sが8:17でない場合末尾HS値が
無いとFreeDOS(98)で認識しないからですた(此れも過去ログ参照)
# NHDにCHS数が記録されて居るので此の仕様もぉかιぃ気もし枡が
きちんと実機デモ追試しないと(略)＞我
～みいそDOS6の場合、領域末尾わシリンダ単位であっても領域サイズが1M単位で切り捨てデスから
シリンダ末尾迄遣う場合わ先ずナイでせう
# インスコ時に此の空きにプロテクトを書き込むアプリが有ったやうな？領域外でデフラグの影響を
# 受けない為
調べた処、認識しないのわDOS7(窓950/A)でなくDOS7.1(窓95B)ですた
> いっぽうWindows2000のディスク管理でパーティションを切ると（切らなくても触ると）、最終シリンダの最終ヘッド、セクタ番号が書かれます。なのでこれらに1を足した値がH:Sとなり、判断できます。仕様としては正しく安全寄りだといえます。最終シリンダまで使うということは、最終ヘッド最終セクタまでを含んでいるはずだからです。シリンダ単位だという規則ならばこれらがゼロだとしても等価です。そうでない規則でも最終ヘッドセクタが書かれていれば安全です。
NT系わ早期からM$に依る開発でしたから、みいその流儀など馬耳東風でPCと同じ仕様にしたのでせう
>＞此の末尾の微調整も有馬したっけ？
> これもミイソ自身あやふやな仕様にしてしまっており困った問題です。DOS 7のfdisk／formatだとシリンダ単位まで使おうとします。
DOS7に関してわ、みいその流儀でわなくPCと粗同じ流儀に成って居枡から、DOS其の物もみいそDOS6の
延長でなくM$謹製な気が？
# FDISK/FORMATだったり(えぷ窓95除)、RTCの装置名がみいそ/えぷDOSのCLOCKでなくPC用DOSと同じ
# CLOCK$だったり、みいそDOSに有った気の利いた機能が無かったり
FORMAT.COMに拠るFDのフォーマットの件も有馬すし(過去ログ参照)
と云うワケでみいそが揺れて居(てえぷも追随し)たと云うより、みいそとM$の流儀が違ったと考える
のが妥当な気が？
# PC用DOSのCLOCK$わ当初無く後付け
ところで中間(?)のOS/2 1.x(未だM$/みいそ)とか何方デモナイBSDとかOS/2 2～(IBM謹製)って
ド～でしたっけ？
|
| Windows2000仕様に矯正する まりも 2025年8月3日(日) 23:21 |
＞H:Sが8:17でない場合末尾HS値が無いとFreeDOS(98)で認識しない
実機ではどうなのでしょうね？ シリンダ境界を遵守するにしても、終了CHSはきっちり入れておいた方がいいとは思うので、Windows2000がやるように、DOSのフォーマット関連ツールでもそのように「矯正」するようにしたほうがいいのかもしれません。
まさか、あるパーティションが｛終了シリンダ番号，ヘッド０，セクタ０｝で終わって、次のパーティションが｛同じシリンダ番号，ヘッド０，セクタ１｝で始まる（なおミイソのHDDのCHSのSは0が基底）なんていうことはないでしょうから。MS-DOS 3.3時代にはやろうとすれば作れなくもなかったでしょうけど、普通には起こりえなかったと思います。
|
| EXIDE機種選択自動化 まりも 2025年8月3日(日) 23:26 |
拙作のEXIDE***ですが、4KBのROMの制約のため、機種グループごとに分かれており、現状では6種類もあります。
ttps://www7b.biglobe.ne.jp/~marimo9821/exiderom/exide5.html
そこで、SCSIボード流用に限ってですが、自動でROMのバンクを切り替えることにして、複数のROMイメージをセレクトして実行するというものを作り、動作実験してみました。
＜準備＞
・流用SCSIボードのIORを潰すがIOWは活かすよう改造
・流用SCSIボードのI/Oアドレスは通常のCC0h～からズラしてCF0h～にする
・ROMの基底バンクには、機種判別とROM選択を行うプログラムを入れる(4KB）
・各機種用のEXIDE***のイメージは4KBずつ上のアドレスに格納しておく(3個まで)
＜動作＞
・基底バンクに入れたプログラムは自分自身をRAMに移しRAM上で実行
・I/O CF0,CF2を叩いてROMバンク切り替えると対象機種用のEXIDE***のコードが現れる
・それを別の場所のメモリ上にロード・実行、IDE BIOSにパッチをあてる
・終わったらROMを基底バンクに戻し、RETFで終了する
これで、他にSCSIボードが存在していても影響を与えずにROMバンクが切り替わり、自動の機種対応が実現できました。起動中には、他のSCSIボードがBIOS動作でバンク切り替えを行いますが、EXIDEボードのROMは最初のROMコール（INIT 0）１回で実行が済んでいるので、たとえバンクが切り替わっても影響はありません。ただし他の活きているSCSIボードのBIOS(通常DC000h)より低いアドレスにEXIDEボードのROMアドレスが現れるように（D6000hなどに）する必要はありそうです。また他のSCSIボードが存在しない環境ならなんの問題も生じません。100ボード/AHA-1030も影響ありません。
DIPスイッチを手動操作して機種選択を合わせるというのよりスマートです。とはいっても一般的なSCSIボードではROMバンクは４つしかなく、そのうち基底の１個はローダですので、残り３機種グループ用イメージしか入れることができないという問題はあります。また可否はボードの設計に依存します。I/Oアドレスを変更するとROMイメージの出現位置が変わる古いボードではこのようなことはできません。ちなみにテストしてうまくいったのは、27C64/128までしか載らないICM IF-2755です。IF-2760まで同じ設計かと思います。ハイレゾでも動作可能であり、SCSIボードの「SCSIに全然関係ない機能」はしゃぶり尽くすことができたという気がします。
【４日追記】SCSIディスクのデータを破壊する有害ゴミで名高い「日本TEXA製HA-55BSWおよびBS4」のROMバンク切り替え方がわかりました。I/O CC0で54h（知られていないレジスタ番号）を出力し、一度CC2でレジスタの値を得て、最下位の2 bitを00bから11bで選択してから他のbitは保持して出力します。するとこの2bitに対応して、16KBの4ブロックが切り替わります。その中の4KBのバンクの選択は通常通りレジスタ30hです。これで64KBのROMを4ブロック＊4バンクで16個の部分の選択ができます。SCSI設定メニューと思しきところを解読して、おもてのBIOSに戻るコードから当たりをつけました。
|
| 要IOR？ かかっくん 2025年8月4日(月) 20:36 |
ところで、I/O 0CC2h(→0CF2h？)でレジスタ値を得るにわIORを活かした儘にする必要が有りそーな？
他のI/Oにしても動作し枡か？
其れともbit1,0だけを変えて他わ任意とか？
33C93が動作しないやうにする(CSピンをカットPU)か、
# DIP(21): 凹みの対辺から左回りに1ピン目か、窪みの対角のピン
# PLCC(24): 斜めの対角から右回りに5ピン目
# 参考 Vccピン DIP(40): 凹み・窪みから右回りに1ピン目・PLCC(44): 斜めから右回りに7ピン目
DMAやPIO/FIFOの板が余計な機能が無くて良さそーな？デモ、バンク自体少ない肝？
|
| IOWのみでも使える（と思いきや） まりも 2025年8月4日(月) 21:57 |
HA-55BSWのBIOSコードは、作法として read-modify-write をやっているだけで、bit0,1以外の機能がないようです。他のbitは鸚鵡返しに読み出せます。読まずに値0..3を書いてROMの投影位置が変わりました。IORを潰してもよさそうですし、他の未使用bitを一時記憶場所として活用するなら、普通使わないCF0hなどにI/Oアドレスをずらしておけばよさそうです。なお一般に33C93Bチップを撤去してもROMボードとしては動作します。
この高付加価値のゴミボードの最大の問題は、DIPスイッチレスであることです。IORが生きている状態で元のBIOS ROMを載せてやらないと、リソース割り当ての変更ができません。たまにオークションに出てくる設定フロッピーは、ROMが動作してなくても設定ユーティリティが動くので、大変意味があります。
【０時追記】ROM内のSCSI設定ユーティリティではI/Oアドレスを変更できないようです。メニューにありません。I/Oアドレスを変えると設定画面の起動ができなくなるからということなのでしょう。これだと流用目的ではIORを殺すしかありません。
それから、HA-55のBSWとBS4の両方のボードを持っているのですが、BIOS ROMをそれぞれ入れ替えると、どっちも起動時画面メッセージ無しのハングアップになります。BSWにはBS4に単にword FIFO用のSRAMが追加されているだけという違いではないのかもしれません。基板は全く同じに見えるのですが。
|
| IFN-SCのROM更新ソフト まりも 2025年8月6日(水) 22:50 |
海外の方から、「IFN-SCのROM更新プログラムって、どっかにパッチを当てればデータ自由になるんじゃね？」というご意見を頂いたので、少し解読してみました。結論としては、IFNUPROM.COMのデータ部を任意のデータに置き換え、コード部に一カ所パッチ（ジャンプ命令の74hを75hに置き換え）をするだけで通りました。
ですが、、、元のBIOSが見えている状態で起動していないと、もう二度と実行させてもらえなくなるのですね。手違いで失敗すると終わりですし、もとのSCSI BIOSに戻すこともできないので、本当にチャンスは一度しかありません。現れているSCSI BIOSをチェックしているところも飛ばさないと使い物になりませんので、もう少し解読するしかなさそうです。【7日昼追記】そこもすっ飛ばすようにして、書き込み開始までは進むようになったのですが、データ転送の途中で必ずハングアップしてしまうようです。しかも止まる場所はデータ内容に依存するようです。これは書き込みルーチンそのものを解読・理解しないといけない難しい問題です。ということでさらに追いかけたら少しだけ理解できました。SCSI レジスタ37h（ベンダ固有、unknown）に1を出力すれば書き込み可能になるようです。0でwrite protectedです。IFNUPROM.COMなど使わずに自前で書き込みできそうな予感。【/追記】
ところでI-O DATAの SC-98（初代およびII）のROM更新プログラムってもう現在ではダウンロード不可能になっているのでしょうかね？ざっと探してみても見つかりませんでした。確か、このプログラムでは、警告はでるもののデータ自由だったかと思います。
|
| SC-98の1.07 リウ 2025年8月7日(木) 15:42 |
www.iodata.jp/lib/software/s/332.htm#Windows%2095
Win95用のファイルしかありませんが、その中に入っていました。
圧縮ファイル内DISK.EXEをさらに解凍するといます。
|
| 1030B問題 リウ 2025年8月10日(日) 21:09 |
対症療法ではなくパッチになりました。
www7b.biglobe.ne.jp/~drachen6jp/1030B.zip
原因は0000:047Ehと0000:047FhをワークRAMにしてしまったことのようです。ここの使われ方が2.00のBIOSの特異な部分でしたので場所を変えました。無事にWindows98が文句を言わずに立ち上がりました。なぜWindows98がここをチェックしているのかは今もってわかりません。
adaptecが諦めた理由はなんとなく想像がつきます。
当時の状況でパッチROMを配布するのはコスト的に不可。実機RAMにパッチを当てる方法を提出するとROMが遅いことがバレる。あたりでしょうか
このファイルは起動中にパッチをあてるのでRAM化できる機種前提です。EPSON機は除外しています。ハイレゾ機も除外しています。
PCI機前提で書いてありますが、おそらく486機でも動作します。(手もとで確認していません。)その部分にパッチしてからROM焼きしても問題はないはずです。
ということで私的には満足感があります。お相手いただいた方にも感謝申し上げます。
12日未明追記
10日提出実行ファイルが完全にバグっていました。(壁ごえSCSI実行済みでなければ想定動作を行えない)ので差し替えています。通常状態からPCIRAMにコピーしてパッチするという手間がちゃんと行えているはずです。
ついでに320kBなFDDが使うメモリ(560hと561h)に変更しました。
また2.10での状況調査ありがとうございます。仕様バグとしてやはり0000:047Ehがダメだったとadaptec側も修正したのでしょうね、どうどうと公開しなかった理由は想像がつきませんが、当たりをお持ちの方はラッキーですね。
そういったことでBIOSが2.00であるかのチェッカも足しました。一応安全側には振れたかと思います。
|
| システム共通域 2.10では まりも 2025年8月11日(月) 9:31 |
Version 2.00のBIOSを見てみると、0000:047Eの使用は30箇所くらいありますね。ここはSCSI ID 7の諸情報を入れておくところですが、undoc2によればID7はデバイスで使わないのでゼロを入れておくとなっています。しかしSCSIホストアダプタのIDは7でなきゃ絶対いけないわけでもないので、ホストアダプタ用に勝手に使ってもいいはずです。AdaptecのBIOS開発者はそう考えたのでしょう。
そんなところを参照して勘違いするWindows98のほうが良くないので、直すべきはWindows98ですが、大変です。BIOSにパッチはやはり対症療法というべきかもしれません。
ところで引越し先がIDE4台目の作業域ですが、これだと当該機ではまずいのではないですかね？空いていそうなところとすると、320KB FDD BIOSのみで使う 0000:0562のほうがいいような気もします。それか、PCI機ではもう誰も使わないであろうB4670関連のところ（広い）です。
そして次にバージョン2.10のBIOSを見てみたら、、、なんと0000:047Eへのアクセスがなくなっている！？ もしかして2.10ならWindows98が起動できるのでしょうかね。これはやってみるしかないですねぇ。
|
| 320Kのが かかっくん 2025年8月11日(月) 11:38 |
B4670わ仕様としてPCI機デモ利用出来る事に成って居枡から2バイトの為に利用フカにするのわ如何なものか？
# B4670の代用で何とかしてネットワークブート出来るやうにしたい香具師＞我
320KならPCI機に仕様として有馬せんから他の装置にDA/UA(5xh)を流用するにしてもワークエリアを
遣っても問題無さそーな？
逆に320K I/Fが有る8086のE,F,M迄わ仕様外デスし＞1030B
# 出来れば320Kの3・4台目から降順で遣うとか？
|
| 1030関連 KAZZEZ 2025年8月11日(月) 14:02 |
> 8086のE,F,Mわ仕様外
8086機は持っていませんが、少なくともV30切り替え機の場合、AHA-1030P/BはV30モードでは使用できないようで、BIOSも現れません。80286では保証外だと思いますが動作するようでした。したがって、V30以下でしか使用しないようなワークエリアがあれば使用できそうに思います。DOS起動後に286以上からV30に切り替えると不具合は出るかもしれませんが、元からそうですので。
> 直すべきはWindows98ですが、大変です。
Adaptecとしては純正品には無い付加価値を付ける必要があったということでしょうけど。1030B（BIOS 2.x）でNECへOEM供給をしなくなったのが裏目に出た形ですよね。もしBIOS 2.xもNECへ供給されて名目上NEC純正だったのであれば対応しないわけにもいかなかったでしょうから、Windows98側で対応してくれたと思うのですが。
> 2.10のBIOS
私の手元のものは中身は見ていませんがシールにv2.1と書いてあったのでその可能性がありそうです。
[19:30追記]
BIOSは2.10でした。ちょっと試しただけですが、おっしゃる通り、Windows98でもHDDを繋いでエラーは出ないようでした。確認環境はRaII23(C3@1066MHz)、Ra40付属のWindows98初代(Ra40で4.3GBのIDE-HDDにリカバリしたものを移植)、外付けでクアンタムのSCSI-HDD4GB(FAT16×2領域)でした。ドライバはOS標準の1030Pを当て、再起動してもSCSI-HDDは最適なパフォーマンス（MS-DOS互換モードでない）で動いていました。
ところで1030P/Bって256BセクタのHDDも認識しないのですね。HDDにSCSIコマンドは通るようなのですが、ワークエリアにドライブとして登録されていない感じでした。SC-98IIIPであれば自動解析で認識しました。
[後方のレスを受けて12日16時すぎ追記]
DEBUGでDC00:0～を覗いただけですが、
> NECBIOS:PC-9801-100 Ver 2.10
> Copyright NEC Corp. 1994-1997
という文字列が確認できました。
[13日0:30追記]
私も忘れていましたが、
ttp://weblabo.griffonworks.net/dorlog/2nddorcom/98maniacs/22447.html
によれば、BIOS 2.00は94-96だそうですので、年号を修正しなかったわけではなさそうです。もともとWindows 98はWindows 97になる予定だったものが翌年に延期されたわけですから、ベータ版とかの段階ですでに問題点が判明していたのかもしれませんね。
WindowsのPnPまわりはWindows 98以前に95OSR2でそれなりに変更されていたような気もするのですが、OSR2では大丈夫だったのでしょうかね。さすがにOSR2で問題があればその旨の発表はあったと思うので杞憂だとは思いますが。
|
| Copyright 1997 まりも 2025年8月12日(火) 12:21 |
|
バージョン 2.10だとWindows 98のGUIが起動できるのですね。2.00だけがちょっと問題あって、その理由と回避策が二十数年を経てわかったとは驚きです。ところで 2.10のCopyrightには、1994,97 とあるのですよね。Windows98登場より前に問題はわかっていて2.00から修正したのかどうか？ それともただ97という数字に手を付けなかっただけなのか。手許のは最近入手したジャンクなので、実際の販売日などはわかっていません。
|
| SC-98アップデータは… MCtek 2025年8月12日(火) 17:16 |
>SC-98（初代およびII）のROM更新プログラム
こちらは28C64+27C***の構成のボードの28C64の部分(2バンク分)を書き換える用です。同構成のICM IF-2768には使用できました。
MELCOのボードは確か28C256が載っていて4バンク分あった記憶なので、使用できたとしても全域を書き換えられないことが想定されます。
余談ですが、IFC-NNのアップデータはWorkbit製SMIT汎用アップデータのようで、EEPROM(AT28C256)に乗せ換えたLHA-301でも動作しました。
ベンダーチェックはしているようで、クロスフラッシュ（Logitec⇔MELCO）はできませんでした。チェックを潰せば可能になるかもしれません。
|
| 98ROMware まりも 2025年8月14日(木) 21:07 |
WorkBit系SCSI-Cバスチップを使ったSCSIボードでは、SCSIレジスタ37hに１を出力すれば書き込み可能になりますが、多くのボードでは回路がROM専用になっているためどうにもなりません。しかし28pinICソケットの1番と27番をSRAM用に変更改造したうえで、SCSI-Cバスチップに出ているはずのWrite Enableの信号ピン（BMX-2では53番がそれっぽい）をROMの27番に接続することで、SRAMや28C256を載せる改造はできるように思います。
いっぽう既に何人かの方が開発されているように、ROM/RAMボードが普及しそうなムーブメントがやって来る気配を感じています。IDE容量壁以外にも応用はあると思います。壁超えSCSIもIDE-BIOS-LBA-patchもそうです。そのほかCPUキャッシュ関連もあります。CPUをあえて遅くしたり、逆に適正にキャッシュ制御して高速化したりです。山猫機や430FX機にMMXというのもあります。これらはOSFDIPLwareやFDIPLwareでも一応解決できますが、ROMボード上でやってしまったほうが手数が少なくて済むでしょう。
たとえばAp3,Xp,BX4,Xe10にはAMD 5x86を載せることができますが、そのままだとDMAが動作したときにディスクのデータを壊します。FDはまさにDMAで動いており、FDIPLwareにCPUL1WBでは間に合わない可能性が大で、ROMボードで動いていた方が安心かつ手軽です。
キャッシュを切って遅くする場合は、常にそうするわけでもないと思うので、ROMボードに入れっぱなしというのは不便かもしれません。メモリスイッチの空きやDIPスイッチの空きを流用、またはボード背面にDIPSWを設けて有効無効を制御すると便利そうです。
で、今後こまこまとした（サイズが4KBに大幅に満たない）ROMアプリがたくさん出てくるかもしれませんが、それらを１つのROMに入れることができたほうがいいでしょう。つまりROM版のIPLwareのようなものを作って、アプリを出し入れできるプラットフォームがあるべきかなという気がします。
現行のIPLwareアプリがそのまま実行できる仕様がおそらく最もよいでしょうね。
|
| RE:ROM版のIPLwareのようなもの KAZZEZ 2025年8月15日(金) 0:16 |
> ROM版のIPLwareのようなもの
昔からまりも様のROMデータには非公式でそのようなものを想定されているような文字列がありましたが、そういえばまだ出ていなかったのですね。
そのようなものがあれば、MSXみたいにROMボードでソフト供給ができるようにもなりそうですね。Cバス専用カートリッジなんてありそうで無かったような気が。
> こまこまとした（サイズが4KBに大幅に満たない）ROMアプリがたくさん出てくるかもしれませんが、それらを１つのROMに
IPLWuniの機能も統合できると良さそうですね。
> 現行のIPLwareアプリがそのまま実行できる仕様
そういえば最近のIPLwareローダはIPLの文字表示ルーチンを流用しているという話でしたが、モジュール側でも使われているものは無いのでしょうかね。
どちらにしてもROM段階とIPL段階で想定される環境の違いを理解しておく必要がありそうです。特にBIOSファンクションとかBASIC-ROMルーチンまわりはROM内でどうなっているのか…。たしかボードのBIOS ROMは起動時に何回か呼び出されるという話でしたが、その回数によっても環境が異なるのでしょうね。
|
| 必須共通部の提案を リウ 2025年8月15日(金) 2:49 |
RA一桁、RLのことを考えると少し面倒(さらにEPSON機のことも…)ですが
IO 53dh
IO 43fhのRAM窓調査のコード
これは事実上必須と考えています。0000:05A7と0000:05B6に数値保管も含めて
IPLWare内は64kBと広いので適当に作ってもサイズを気にせずにざっくり調査したのですが
4kBROMの場合にあのサイズは受け入れられないと思います。何かいいアイデアあるでしょうか？
後方参照でお返事
Xe10はジャンパでCPUIDが変わります。ITF内で既知のWBなCPUIDにのみIO63FをWB側に傾けます。ですので必須です。(過去ログ ematei.s602.xrea.com/cgi-bin/bbs39_ris3/bbs39.cgi?mode=past&year=2023&mon=10 の一番最後)
インストーラ型の選択は、個人的にボードの入れ替えやHDDの入れ替えを頻繁に行うので好みではないのですが…それも一案ですよね。とりあえず自分のチェックコードはloopである程度縮みそうだ という感触はありました。
RLは後期もだめでしたね、持っていない機種のことはすぐに忘れてしまうのでご指摘感謝です。
未知IO操作でCPUIDを変えられるのかもしれませんがフロッピーやSCSIからのブート時というどうにもならないタイミングで問題が発生するので"CPUを入れ替えるならば"ROMボードで制御するのがやはり正しいと思います。(今まではIDE-HDDからのIPLwareでやってましたが)WTジャンパを常に挿しておく、というのが一番安全ですがやはりもったいないので機能は有効にしておきたいです。
16日17:30追記
実物で動作を確かめながら反論しています。
IO63Fhはキャッシュの制御にしか使われておらずここを操作してもCPUIDは変わりません。ジャンパの有無だけでCPUIDが変わります(未知IOで変わる可能性はあり)し、ITFはその数値だけを見てIO63Fhのbit7の上下を行っています。そのため知らないCPUのWB/WT不整合状態では必ずDMAで不具合を起こします。
そして、SC-98IIのROMを改造してみました。
pbs.twimg.com/media/GydZDDjaAAAmMxJ?format=jpg
無事にAm5x86のx4倍動作のWBモードで(通常のITFではDMA暴走)バスマスタのSC-98からもフロッピーからもブートできました。
行わなければブートできませんから当方は満足です。
|
| Xe10ってWT かかっくん 2025年8月15日(金) 9:08 |
> たとえばAp3,Xp,BX4,Xe10にはAMD 5x86を載せることができますが、そのままだとDMAが動作したときにディスクのデータを壊します。FDはまさにDMAで動いており、FDIPLwareにCPUL1WBでは間に合わない可能性が大で、ROMボードで動いていた方が安心かつ手軽です。
ITF無怪造のXe10についてわリセット後のAm5x86わ元のAmDX4と同じWT動作デスからDMAを遣っても
平気な筈デス。HSB等での再起動の場合、準備が整った状態で出来枡から其れ以上の配慮わ不要かと？
# みいそに拠るPODP,WB iDX2(,WB iDX4?)以外でのWB封じの『仕様』
多分BX4も同じかと？
> Xe10はジャンパでCPUIDが変わります。ITF内で既知のWBなCPUIDにのみIO63FをWB側に傾けます。ですので必須です。(過去ログ ematei.s602.xrea.com/cgi-bin/bbs39_ris3/bbs39.cgi?mode=past&year=2023&mon=10 の一番最後)
当時の調査で、Xe10で問題に成ったのわ本体の設定がWTの儘で、下駄等でCPUだけWBにした場合、
CPUBENCHの結果わ最高に成増がバンクやDMAで落ちる(WT想定ナノで多分コピYバックせずにフラッ
シュだけする)結果ですた
I/Oを操作して本体・CPU共WBに設定すると、CPUBENCHの結果が↑と両方WTの中間に成りバンクや
DMAもおkと云う文句無しの結果に成増
Am5x86でのリセット直後わ両方WTに成増し、想定されたCPUなら両方WBに成増から、其の2パターン
だけなら無問題な気がし枡が、【本体のジャンパ】でCPUだけWBに出来ましたっけ？
阿ー、此のジャンパで本来わCPUも本体の設定もWBに成る処、Am5x86わ仕様外のCPUナノで本体が
WTの儘CPUだけWBに成ると。其れならジャンパをWT側にして後からI/OでWBに切り替えるのが
筋でせう
# 本体のI/OだけでCPUもWBに出来枡から、下駄等わ↑の通り本人の責任ナノで面倒見る事も(略)
尚【ジャンパでCPUIDが変わる】のわ確かデスが、CPUの設定がWBかWTかでCPUIDが変わり枡。
即ちI/O操作デモWBとWTが変わり枡からCPUIDも変わる筈デス
# 此のI/Oわ未知でなくUndoc2にも↑にも有る063Fh bit7(?)、詰まり本体設定と共に動く筈(？)
当時やった事↓
# Xe10でWTジャンパの儘Am5x86にソケットのPODPのWB関連配線を下駄で結び、I/Oで(当時既存の
# プログラムにて)WBに切り替えたので出来なければロット違ィ？
# CPUBENCHの結果が本体WT・CPUだけWBと、両方WTの中間。FDDのDMAもおk
# プログラムわZOBだか竹の塚だかに有ったやうな？
> RA一桁、RL一桁は少し面倒ですが
RLわ前後何方もメモリ周りが同じ事が判りますた。RLの全機種がRA2,5と同様にE0-FFのやうで
# 後わESとLSか、調べない限り判らん
> IPLWare内は64kBと広いので適当に作ってもサイズを気にせずにざっくり調査したのですが
> 4kBROMの場合にあのサイズは受け入れられないと思います。何かいいアイデアあるでしょうか？
ROM内部で持つのでわなくインストーラで機種判定するとか？
ROMのINIT部にもっと簡便な機種判定で対象機種か否かだけチェックするとか？
|
| Xe10／BX4に関しての誤解 まりも 2025年8月17日(日) 7:51 |
＞ソケットのPODPのWB関連配線を下駄で結び
これはXe10／BX4に関しては全く不要です。すでに配線されてますし。過去ログのこっちの通りです。11月11日の記事です。ピン配置の比較図があるやつです。
ttp://ematei.s602.xrea.com/cgi-bin/bbs39_ris3/bbs39.cgi?mode=past&year=2023&mon=11
WT/WBジャンパピンでは，CPUだけWB動作にできるが、周辺回路はWT対応のままなのです。ITFがCPU IDを見て、I/O 63Ehの操作により周辺回路をWB対応にしますが、ITF内に対応するCPUIDがなく、5x86は知らないCPU扱いなのです。なおこのI/O操作でCPUのWT/WBが（連動するCPUIDが）変わることはありません。
もしかすると最後期に出荷されたAMD486DX4にWB版が混ざっていた可能性がありますが、これは5x86のキャッシュ半減版に相当するはずです。強制的にWTにするジャンパを設けたことで、仕様通りのWB無し版と差がつかないようにしたと考えられます。
ROM版IPLwareの仕様構想についてはもう少し整理してから…コメントしたいと思います。なおROMサイズは皆さんの自作ボードについてはいくらでも広く取れますので、ソフト側で4KBの制約を設けてはマズイです。ROMのサイズを事前に知る手立てはない（ボード上に設けたDIPスイッチなどの設定をI/Oで読み出せる機構でも作れば別）ので、サイズ把握は使用者において行うということになります。
|
| 486機のx4設定について One 2025年8月17日(日) 9:32 |
会話を読んでいて、リウさんは直乗せ、かかっくんさんは下駄とのことで、すこし気になりました。ひょっとして、かかっくんさんの下駄はR17(CLKMUL)がない又は未結線だったのでは。
当時Xsを使っていた時に、Am5x86を乗せたくAT互換機の下駄を買っていてつないだところ、下駄のジャンパでx4設定にすると起動できませんでした。
x3設定だと起動できるので、立ち上がった後にジャンパショートしてx4に切り替えて無理やり使っていました。もちろんWTで動作していました。
しばらくしてdatasheetを見つけ、R17(CLKMUL)の動作,Lowでx2(x4),HiかZでx3を知りまして、そして買った下駄がR17は繋がっていました。
下駄ではこのピンをLowに落とすと起動しないということと判断して、R17ピンを折ったところ無事x4のWTで起動するようになりました。
当時はi486DX2のR17はNCなのに、XsのSocket3は配列おかしいから何か変な挙動をしていると思っていたんですが、おそらくITFの挙動ですよね。
Xsは処分済みだしこの近辺の486機を持っていないので再確認出来ないですが
これから、98用の下駄はR17のピンは処理してあり、WTのx4では起動できるのではと推察しています。
機種違いですし、関係ない話であれば、すいません。
|
| 下駄だった まりも 2025年8月17日(日) 12:30 |
ずっと5x86直載せの場合の話をしていたのですが、読み落としてましたが下駄使用ですか。下駄といっても仕様が不明では考察が難しいですね。WB/WTのB13（外周無しのソケット1基準のピン番）がどう処理されているかわからないので。ともかくXe10/BX4は完璧なsocket6（なので配線変更は不要）なのに周辺回路の動作可否はITFのソフトが行うという変な仕様なので、理解しにくくなっています。CPUのWT/WBピンの状態に合わせるよう、キャッシュ制御回路の動作可否のハードウェア設計をすればよかったのでしょうが、それだとピン配置違いの他のCPUに対応しずらいことから、ITFが判断してから決めることにしたのでしょう。実際Xe10に本来載っているAMD486DX4NV8Tと5x86とではヤバいくらいピン配置が異なっています。例えばB13はWT/WBではなくCLOCK MULなんですよね。
安心して使えるのはPK-586A/98くらいではないでしょうかね。ソフトは不要ということですから、マザーボードから見るとWTで動作しているつもりでも辻褄を合わせるように、アクセラレータ上の回路で処理しているはずです。メルコのHAS-33Qpはダメです。CPUを外すと分かるように、そもそもWTなDX4用下駄ですから。
直載せは，きっちりI/O 63Fの変更をすれば安全で最大のパフォーマンスが出せます。しかし変更しないと使い物にはなりません。
|
| 当時のプログラムを失念、当時の記録捜しの(略) かかっくん 2025年8月17日(日) 21:57 |
>＞ソケットのPODPのWB関連配線を下駄で結び
> これはXe10／BX4に関しては全く不要です。すでに配線されてますし。Xe無印と勘違いしてませんか？Xe無印はこれが必要なsocket 3 です。Xe10/BX4はダメ押しの過去ログのこっちの通りです。11月11日の記事です。ピン配置の比較図があるやつです。
> ttp://ematei.s602.xrea.com/cgi-bin/bbs39_ris3/bbs39.cgi?mode=past&year=2023&mon=11
此れわ確かに一昨年讀んだ憶えが有馬す。↑わ当時した事の羅列で其れ以上の検証わ有馬せんですた
で、Xe10にiDX4の、BX4にiDX2のロットって有ったんデスかねぇ？何方もAmDX4,DX2かPODPかだった
希ガス
次に下駄についてデスが、市販の物でなく其のプログラムのDOCの通りSocket3のPODP用ピンと5x86の
ピンを1対1で配線しただけで、魔法石とか他の回路わ有馬せん。其れ以上の検証をしませんですた
# 本体Socket3レベルでのPODPとWB iDX2/iDX4の両配線の有無とか
配線わ以下の通り
Socket3 19x19(5x86) 信号名
N1 B11(A10) INV
U1 B13(A12) HITM-
G1 C13(B12) CACHE-
B14 D15(C14) FERR-
T1 C14(B13) WB/WT-
Socket3のB14に相当する5x86のA13わINCの為、B14(A13)の○ピンソケットを抜いて5x86と絶縁した
上でD15(C14)に配線したピンを接着剤で固定
↑に拠るとT1 - C14(B13)以外わ既に配線されて居るやうデスが
其のプログラム自体を示せれば明白デスが記憶の彼方ナノで...
# 記録わ有る筈デスから捜し枡。確か苹果HFS(+でない)フォーマットの3.5MOに竹の塚やZOBの(以下略)
> WT/WBジャンパピンでは，CPUだけWB動作にできるが、周辺回路はWT対応のままなのです。ITFがCPU IDを見て、I/O 63Ehの操作により周辺回路をWB対応にしますが、ITF内に対応するCPUIDがなく、5x86は知らないCPU扱いなのです。なおこのI/O操作でCPUのWT/WBが（連動するCPUIDが）変わることはありません。そこも誤解されているようです。CPUのWT/WB属性はリセット時に決定され、不変です。
此の件(くだり)わ解り枡。惡魔デモ周辺わCPUIDの通り初期化され既知のWB CPUならWBに成ると。
↓に有馬すが、I/O 063FhでSocket3(PODP)のT1ピン(WB/WT- bit7?)やG1ピン(CACHE- bit5?)も動き
ませんか？
> もしかすると最後期に出荷されたAMD486DX4にWB版が混ざっていた可能性がありますが、これは5x86のキャッシュ半減版に相当するはずです。強制的にWTにするジャンパを設けたことで、仕様通りのWB無し版と差がつかないようにしたと考えられます。
実際AmDX4にWBのが有ったらιぃデスが検証した機種に載って居たのわNV8TでWTの8K品ですた
Wikiに↓の再定義前のWB AmDX4の画像(SV8B)が有馬すから製品自体わ有ったのでせう
upload.wikimedia.org/wikipedia/commons/8/86/AMD_Am486DX4-120.jpg
参考 AMD-X5とAmDX5
upload.wikimedia.org/wikipedia/commons/4/4b/AMD_Am5x86-P75.jpg
upload.wikimedia.org/wikipedia/commons/8/8d/Ic-photo-AMD--Am5x86-P75-(Am486DX5-133W16BGC)-(486-CPU).jpg
> 会話を読んでいて、リウさんは直乗せ、かかっくんさんは下駄とのことで、すこし気になりました。ひょっとして、かかっくんさんの下駄はR17(CLKMUL)がない又は未結線だったのでは。
CLKMULがオープンで3x(100M)、GNDへPDで4x(133M)に成増が、確かGND直結で4x固定にした記憶が？
> ずっと5x86直載せの場合の話をしていたのですが、読み落としてましたが下駄使用ですか。下駄といっても仕様が不明では考察が難しいですね。WB/WTのB13（外周無しのソケット1基準のピン番）がどう処理されているかわからないので。ともかくXe10/BX4は完璧なsocket6（なので配線変更は不要）なのに周辺回路の動作可否はITFのソフトが行うという変な仕様なので、理解しにくくなっています。CPUのWT/WBピンの状態に合わせるよう、キャッシュ制御回路の動作可否のハードウェア設計をすればよかったのでしょうが、それだとピン配置違いの他のCPUに対応しずらいことから、ITFが判断してから決めることにしたのでしょう。実際Xe10に本来載っているAMD486DX4NV8Tと5x86とではヤバいくらいピン配置が異なっています。例えばB13はWT/WBではなくCLOCK MULなんですよね。
「実際Xe10に本来載っているAMD486DX4NV8Tと5x86とではヤバいくらいピン配置が異なっています。例えばB13はWT/WBではなくCLOCK MULなんですよね。」
其れだ!
犯人わお前だ!(じっちゃんのナニ賭けて)
# >謎<
Xe10やBX4のCPUソケットわAm486を前提としたピン配置の筈デスからSocket6と呼ぶのわ如何な
物か？とわ憶い枡が、其れわ其れ
まりもさんのXe10にSocket6が載って居枡か？PODPモデルも有った(又わ予定(初期ロット)されて居た)
事も考えると本来のSocket6に本来のPODPわ考え難い気が？
PODPの場合其の辺の制御ピンがAm486と無関係な外周ピンに有馬すから難を逃れたのでせう(>謎<
ematei.s602.xrea.com/cgi-bin/bbs39_ken/bbsdata/3353-0.png
# 下駄の結線わ研究発表板を参照
詰まり本来わWB/WTジャンパでなく3x/2xジャンパなワケで。
↑の下駄でわSocket3のT1を5x86のB13(WB/WT)に配線(Socket3のC14を絶縁)しますた。他のピンも
DOCの通り
# Socket3のC14を5x86のR17に付ければ良かったのか
当時の検証わ凡て下駄とプログラムがセットで、直載せ・プログラム使用だけで動いたか？の検証しま
せんですた
因みに此の配線をしてもプログラム無しでわITFの仕様通りWT動作ですた。
CPUBENCHが直載せ・WT固定と粗同じスコアで、半端な動作でわ無さそーな？
# 当時もAm486と5x86の両方のデータシートをテレホDLしてプリントアウトして居ましたが其処迄
# 能く見て居ませんですた。何の為にDLしたんだか？
Am5x86わiDX4にピン配置を合わせたとされて居枡。元々Am486がi486SX/DX辺りに合わせた処、
其の後DX2,DX4と進化する際にピン配置が違って来たのか5x86で亦合わせたのかが訴訟と関連有り
そーな？
# i486わDX 50Mでテスト用ピンを、SLエンハンスでSMI等電力制御ピンを追加、iDX4でCLKMULと
# VOLDETを、PODPとWB iDX2/WB iDX4でCACHE-とWB/WTを追加。Am5x86でWB iDX4のピン
# 配置に追随。Am486が追随できなくも...ナイ鴨？矢張り訴訟？
# 訴訟の行方に依ってわVOLDETも駄目(外付けジャンパで電圧設定か下駄併用)だった鴨？
Am486DX*わ、Am5x86(AMD-X5)をAm486DX5と再定義した際に5x86(DX5)のピン配置に統一したやうデス
型番の法則が変わり見分けが付き枡
A80486DX4-100NV8T
datasheets.chipdb.org/AMD/486_5x86/19160D.pdf
AM486DX5-133W16BGC
www.datasheets360.com/part/detail/am486dx4-100v16bgi/-1011026324270423666
尚B14(PODP C15)のUP-とTMSの件わ487/ODPソケットでないと問題が起こらず、DX,DX2,SX2(≠ODP)
以外わ下駄併用と考えれば大した問題に成らないでせう
# ODPR？ODPRわODPソケットに差す物でナイので考慮外
> 直載せは，きっちりI/O 63Fの変更をすれば安全で最大のパフォーマンスが出せます。しかし変更しないと使い物にはなりません。
其のプログラムがする仕事も此のI/Oの操作だと憶い枡
|
| SCSI ROMバンク切り替え仕様 まりも 2025年8月18日(月) 10:03 |
Socket6の定義というか3との違いは、VoltDetのピン電位に合わせてVccを変えることができる点だと思います。さまざまなCPUのピン配置の違いまではSocket規格には関わってませんね。
さてSCSIレジスタ関連に話を戻します。レジスタ30hの bit７,6で4KBのROMバンクを4個切り替えることができますが、それだと16KBまでしか扱えません。それ以上のところは bit5を使うSCSI-Cバスチップ（WorkBit系や92ボード）もあれば、別のレジスタ例えば54hを使うものも（NEC D650マーキングのやつ）あります。というようにものによって異なります。
なお92ボードの場合ROMの総量は128KBもあるのですが、レジスタ30hの4bit＊4KBでは1bit足りませんので、全部の読み出しはできない可能性もあります。DIP SW2のbit 6,7の対象機種選択の2bit＊転送モード2bitで現れるROMが切り替わりますが、これで全4パターンですから、64KBです。128KBの上半分は読み出す必要はないのかもしれません。16bit幅のROMを使う都合で最低容量が128KB（1Mビット）であるというだけでしょう。【一部誤りあり新規記事参照】
ROMの物理アドレスがどう本体側に現れるかについて、少し整理すると、3パターンあるようです。
[1] I/Oアドレス設定に対応して16KBズレるもの DMA転送しかない古いボードはこれ
[2] 機種や転送モードに応じてイメージが2ないし4個入っているもの バスマスタ初期のボードと92
[3] 基本的に1個のイメージしかなく後方にメニューやマルチベンダ対応アプリが入っているもの スイッチレスのボード
|
| 16bit ROMって1M～？ かかっくん 2025年8月18日(月) 17:24 |
> なお92ボードの場合ROMの総量は128KBもあるのですが、レジスタ30hの4bit＊4KBでは1bit足りませんので、全部の読み出しはできない可能性もあります。DIP SW2のbit 6,7の対象機種選択の2bit＊転送モード2bitで現れるROMが切り替わりますが、これで全4パターンですから、64KBです。128KBの上半分は読み出す必要はないのかもしれません。16bit幅のROMを使う都合で最低容量が128KB（1Mビット）であるというだけでしょう。
確かに512KのROM(32K x16)わ無さそーデスね
# ロットに依って27C1024使用品有り。↓わSCSI石がSTのAIC33C93B
# jp.mercari.com/item/m48570400185
# static.mercdn.net/item/detail/orig/photos/m48570400185_1.jpg
まぁ一度外して外部で讀み出せば明白デスが
|
| MSC98K KAZZEZ 2025年8月19日(火) 1:57 |
一応1030関連（？）なのでこちらに。
ttp://ematei.s602.xrea.com/kakolog/2002/200211.htm
↑このときのSCSIボード「MSC98K」について、I/Oが出現するアドレスをIN命令で0000-FFFFほぼ総当りで調べてみました。見付かったのはI/O Fx40～Fx5F (xはロータリースイッチで0～F可変と思われ、手持ちのものは4) でした。
いやまあ、分かったのはそれだけなのですが…。
100ボードや1030P/BのI/Oはx840～x87F(x=1or3)で64バイト分あるのに、MSC98Kではその半分の32バイト分しかありません。AIC-6360Qは共通でも、MSC98KにはAIC-3340Qが見当たりませんので、そのせいでしょうか？ しかもIN命令で読める値の分布はずいぶん違うようで、互換性があるようには見えません。…ですのでI/Oアドレスを指定したところで多分100ボードや1030系のドライバでは動かないんじゃないかいう気がします。
他所の記述にもありましたが、手持ちのものもROMらしきものが見当たりません。載っているIC類はAIC-6360Qの他はターミネータ?(UC506DWP)と74系ICがいくつかとPALくらいです。実際にPCを起動してもSCSIとして認識されていませんから、ボードが壊れていなければ専用ドライバで認識させるタイプと思われます。
ただ53C406Aと書かれた空きパターンもありますので、これが実装された製品であれば何か違うのかもしれません。他にも印字のないICらしき空きパターンはありますので、それがROM用の可能性もありそうです。
|
| 偶数アドレスデコード リウ 2025年8月19日(火) 7:25 |
98のCBUSアドレスデコードは偶数アドレス選択のとびとびをとることが多い（100ボードも）のですが、その板では奇数アドレスも使って連続32byteで6360の機能がぎゅっと詰まってるのかと思われます。
IOアドレス先頭+1Fhの連続読み出しでASCII文字列が読み出せるはずです。これがソフトウェアで見張られているとそこもつぶす必要がありますが、そうでなければslimscsiのドライバがWindows9xでは使えるかもしれません。
|
| ユーザ解放I/Oアドレス まりも 2025年8月19日(火) 9:23 |
98のI/O空間はミイソ予約域が広すぎて、正式にはnnD0h-DFh くらいしかユーザに開放されていません。ということは64バイト連続で（偶数だけ奇数だけの32バイトでも）取ってはならんということになるわけです。MSC98Kが本当に64バイト連続で占有しているとすると、少なくとも98初期の頃の周辺装置やボード(*)とは一緒に動作しないと思います。またPCI搭載機でも注意深く最上位4bitを設定しないと動作できません。なので連続なら32バイト以下にされているはずです。残り32バイトは上位のアドレスで相当飛び飛びに配置されているのかも？
(*)SASIボードなんかもたったの2バイト、0080h，0082h、しか使わないのにフルデコードされておらず、上位8bit全部占有してしまいます。サードパーティ製、例えばICMのIF-2720ですらそうでした。【追記】9801RAからDAまでの機種に内蔵のSASIでもそうです【／追記】
|
| 初期の機種の**40h～**5Fhが全部埋まって居る かかっくん 2025年8月19日(火) 11:26 |
抑々**40h～**5Fhでわ初期の機種(下位8bitデコード、凡て埋まって居る)の
**40h～**46h **48h～**4Eh LPT(8255)およびイメージ
**41h,**43h **45h～**4Fh キーボード(8251)およびイメージ
**50h,**52h **54h～**5Eh NMIコントロールおよびイメージ
**51h～**57h **59h～**5Fh 320K I/F(8255)およびイメージ
にダブる気が？
16bitフルデコードの9821のやうにイメージが全く出ないのとわ違ィ、下位8bitの中にもイメージ
出まくりでユーザ解放アドレス以外わ遣い物に成らなかったので。
ウチのF2怪デモ、フルデコード迄わして居ません。惡魔デモ上位8bitを0にして居るだけデス
01**h～FF**hが全部空くだけデモすっきりし枡
実習用Z80ワンボードマイコンで、256本(65536本)のI/Oアドレス全部がたった一ッの8255に割り当て
られたのとかも有馬した
> (*)SASIボードなんかもたったの2バイト、0080h，0082h、しか使わないのにフルデコードされておらず、上位8bit全部占有してしまいます。サードパーティ製、例えばICMのIF-2720ですらそうでした。
SASI板わ兎も角、機種専用HDC板やSASI籠/ESDI籠(H98)ってド～でしたっけ？
> 【追記】9801RAからDAまでの機種に内蔵のSASIでもそうです【／追記】
矢っ張り
まぁSASI籠に付いてわ籠自体でなくスロットの方を責めるべきでわ有馬すが。
projectmps.net/images/dhard/pmdocerd/radapin.jpg
SASIスロットにA11迄鹿出て居ませんからスロットのレベルでデコードを済ませておくべきナノで
# 不足分をSCSIスロットで補う。SASIスロットをSASI籠で遣う分にわデコード済デモ無問題
デモSASIスロットにA11迄出て居てもSASI籠でノーデコードと云うのわ(略)
旧機種と云えば、9801元祖の14pLPTにBUSY以外の状態線も有る件わ過去ログに有馬すが、
機種判別に遣われるI/O 0042hのbit7,6の内bit7がSELECTに成って居枡
詰まりSELECTの状態に由り変化するのでUndocのio_prn.txtに有る元祖判別の0,0って正しくわ0,0
又わ1,0(io_prn.txtでわ『その他の機種』)と云う事で
> I/O 0042h
> 名前 ステータスポート
> 機能
> [READ] PORT Bリード
> bit 7,6: TYP1,0 システムタイプ
> 11b= PC-9801U,PC-98LT･HA
> 10b= その他の機種
> 01b= 未定義
> 00b= PC-9801初代
(以下略)
↓
I/O 0042h
名前 ステータスポート
機能
[READ] PORT Bリード
bit 7: プリンタインタフェイスSELECT信号■[PC-9801初代]
1= インアクティブ
0= アクティブ(SELECT状態)
bit 7,6: TYP1,0 システムタイプ
11b= PC-9801U,PC-98LT･HA
10b= その他の機種・PC-9801初代
01b= 未定義
00b= PC-9801初代
bit 5: プリンタインタフェイスPE信号■[PC-9801初代]
1= インアクティブ
0= アクティブ(PE状態)
bit 5: MOD システムクロック (略)
bit 4: (略)
bit 3: (略)
bit 2: プリンタインタフェイスBUSY#信号
1= インアクティブ
0= アクティブ(BUSY状態)
bit 1: (略)
bit 0: プリンタインタフェイスACK#信号■[PC-9801初代]
1= インアクティブ
0= アクティブ(ACK状態)
bit 0: VF VFフラグ (略)
遺憾な事にFAULTが無いのでRDiskのPIONECが遣えないんデスよねぇ(ピン数が一杯ナノで仕方無い)
そだ、前に14pLPT/RS-232C併用(RIONEC)としたのをOPN(0188h,018Ah)のJOYとの併用(FIONEC?)に
しよう
|
| 連続と偶数の違い KAZZEZ 2025年8月19日(火) 13:29 |
> 98のCBUSアドレスデコードは偶数アドレス選択のとびとびをとることが多い（100ボードも）のですが、その板では奇数アドレスも使って連続32byteで6360の機能がぎゅっと詰まってるのかと思われます。
多分そうじゃないかと思っています。ただ1030では奇数アドレスの一部にも何か出ているみたいでしたので断言できませんでした（今回IN命令はALを使った8bitアクセスだったので、16ビット分を読み出したわけではありません）。といっても大半の奇数アドレスはFFでしたが。1030ボードが無ければ1840～187Fのアドレスは偶数奇数すべてFFです。
> IOアドレス先頭+1Fhの連続読み出しでASCII文字列が読み出せる
情報ありがとうございます。どちらも「(C)1991ADAPTECAIC6360」（以下スペース）という32バイト周期で同じようでした。先述のようにSCSI ROMがありませんからSCSIチップ内蔵の機能なのですね。
読み出すたびに値が異なるI/Oアドレスは2、3個所あることに気付いてはいましたが、末尾以外のアドレスから読めるのは文字列では無いようでしたし、該当アドレスの相対関係がMSC98Kと1030系で異なるような気もします。
> slimscsiのドライバがWindows9xでは使えるかも
少なくとも9xでOS標準の1030P用ドライバは（そのまま組み込むだけでは）動かなかったと思いました。infを書くか、リソースを強制指定（追記：少なくともWin98ではinfに無い値は指定できませんでした）すれば良いのかもしれませんが、100ボードや1030PはPnP前提（非PnP設定でもリソースが固定になるだけの擬似レガシーという話だったような？）ですから、非PnPのボードが動くかどうかは不透明かもしれません。
[20:00追記] SlimSCSIというとAPA-1460系ですか…sparrowa.mpdは持っていませんが、とりあえずDLしたADP_98.INFをWindows98に読み込ませる限りは完全にPnP扱いで、非PnPデバイスには適用できない感じでした。ところでADP_98.INFには1030Bの情報もありますので、v2.1の1030Bを使うには良いかもしれません。
> 連続なら32バイト以下にされているはず
そのようですね。MSC98Kでは連続で32バイト分、1030系では偶数で32バイト（奇数も数えれば64バイト分）という感じでした。
> 16bitフルデコードの9821のやうにイメージが全く出ない
今回調べたのはRaII23だったので大丈夫だったようです。
なおI/O 6020（大熊猫BIOS＋SiI3114で使用中）を読もうとすると止まるので6000～60FFはスキップしています。
|
| 100ボードがdword 転送できない問題実は？ まりも 2025年8月19日(火) 14:17 |
＞奇数アドレスの一部にも何か出ているみたい
データ転送するときに使うI/Oは、ワードあるいはダブルワード仕様なので、その分は奇数アドレスから見えることになります。それじゃないですかね。
こういう点でもPC-9801-100はPC-9821-100と間違えるに相応しいボードでしょう。9801FA以前の機種ではあまり使わないほうが良さそうです。RAでデバイスドライバ使用時にdword転送できない問題も、Cバスが転送できない仕様によるのではなくて、これが関係している可能性があるかも？本体内部のフルデコードでない何かとI/Oアドレスが衝突している可能性です。
|
| *840h～*87Fh辺りって空きな気が？ かかっくん 2025年8月20日(水) 15:35 |
窓9xや2kでI/Oの一覧が出枡から、其処から衝突するI/Oが判ると憶い枡
# 100板の情報わUndoc2のio_scsi.txtに無いデスね
**40h～**7Fhについても*840h～*87Fh辺りわ空いて居たやうな？
# 9801中期以降A10(*4**h)とA11(*8**h)もデコード。
# D*辺り迄わオンボードの0040h～007Fhって*040h～*07Fh *140h～*17Fh *240h～*27Fh *340h～
# *37Fhだったやうな？
# 本来の値(レイ LPT出力)を別のI/O(0040h→0140hとか0340hとか1840hとか)に出して試してみるか
# あとタイムスタンパとかウェイトとかテキストGDCとか
あ、**D0h～**DFhが全部空きでわなくバスマウスが7FD9h～7FDFh、BEEP音程がBFD9hのやうに
一部遣われて居枡。
# ユーザ開放ポートって**D0h～**EFhでなく*@D0h～*@EFh @:0～7だった肝？流石に*0D*hで
# なかったやうな？
マウスI/FわF3,M3の本体デバイスで唯一下位8bitでないデコードに成って居枡
ところでXe10のI/O 063Fhのbit7やbit5でWB/WT(T1)やCACHE-(G1)わ動きませんでしたか？
# WB/WT以外の配線が両方に有るならWB/WT配線だけデモ良い鴨？
あと、逆にCPUをWT・本体をWBに設定した場合、何のやうな問題が起こり枡か？
|
| PC-9801-92のROMイメージ物理配置 まりも 2025年8月22日(金) 6:47 |
PC-9801-92のROMの現れ方があやふやであったので、ROM 27C1024に物理番地をデータとしたものを書き込んでから92ボードに装着し、バンク切り替え機構を使って読み出してみました。
まず128KBのデータがあるのですが、現れるのは上位64KB側のようです。ROM物理番地 10000hです。DIPSW-2の6,7（機種４択）やI/Oアドレスの変更でも変動はありません。ということからするとSCSI BIOS ROMのデータでは下位の64KBと完全に同じものが入れてあるだけと考えられます。【訂正】その考えは外れで、DMA／PIO転送モードに対応した別々のコードでした。
次にバンク切り替えですが、SCSIレジスタ30hの上位3bit(7,6,5)を使っています。bit4を操作しても変動しませんから機能はないとみられます。32KBまでの中の4KBの切り替えしかできないようです。ということは、64KBあっても32KBの繰り返しの可能性が高いです。16bit幅の石を使うために、容量的にはずいぶんムダしているという印象です。
bit ROM64KB
7,6,5 物理番地
0,0,0 0000h 0KB
0,0,1 1000h 4KB
0,1,0 2000h 8KB
～ 中略 ～
1,1,0 6000h 24KB
1,1,1 7000h 28KB
なおWorkbit製SMITチップの場合もこれと同じであるようです。64KBある27C512や28F512が載っていたとしても実質は32KBぶんでしょう。BMX-2やそれ以前のものは、bit6で4KB、bit7で8KBの切り替わりになる点で違います。結局のところ、ROMは取り外して読み書きしてみないと、バンク機能との対応はわからないし、配置もSCSI-Cバスチップで全然違うということになります。
|
| 86音源板のROMも16bit かかっくん 2025年8月22日(金) 11:43 |
 16bitのROMと云えば86板にも有馬すが、此れも16Kの繰り返しなんデスかねぇ？
汎用(E)EPROMなら兎も角マスクROMなら其の容量で造った方がダイが小さく
成り安上がりな希ガス
# 実わ此れが128K(16KiB)、92板のが512K(64KiB)だったりして？
> なおWorkbit製SMITチップの場合もこれと同じであるようです。64KBある27C512や28F512が載っていたとしても実質は32KBぶんでしょう。BMX-2やそれ以前のものは、bit6で4KB、bit7で8KBの切り替わりになる点で違います。結局のところ、ROMは取り外して読み書きしてみないと、バンク機能との対応はわからないし、配置もSCSI-Cバスチップで全然違うということになります。
結局板毎の個別対応に成り、汎用イヒするとバンクでなく平屋での利用に成ると？
と成ると手持ちが有るなら兎も角新規ゲッツなら二束三文で放り投げてあるみいそ55板とかのが(略)
8bitのROMをソケットから外したらNICで讀んでみるとか？16bitのROMも8bitずつ結線して讀むとか？
ユーザ各自でNICとSCSI板で讀んだ物を比較して貰うとか？此れならデータ自体やハッシュのやり取りで
ナイので(C)問題も起こらない希ガス
其れ用のツールなら創る意義有る鴨
# SCSI板のバンク毎に細切れにしてNICでリニア讀みして細切れにした物と各々を凡て比較する
# NICでのリニア讀みのファイル N00 N01 N02 N03 ... N09 N0A ... N0F N10かN0G ... Nnn
# SCSI板でバンクを切り替えながら讀んだファイル S00 S01 S02 S03 ... Snn
# N00とN01 N02 ... Nnnを比較、N01とN02 N03 (中略) Nnn-1とNnnを比較、一致したものを記憶
# しておく
# N00とS00 S01 S02 ... Snnを比較、N01とS00 S01 (中略) NnnとS00 S01 S02 ... Snnを比較
# 一致した物(レイ N00とS00 N01とS02)をN00-S00とS00-N00とかN01-S02とS02-N01とかにリネーム
# 但し内容が同じ場合-以降が若番に寄る(レイ S00＝S04の場合Nnn-S00)
# 最後にNnnの一致内容からNnn-SnnをNnn-Snn.Nmmにリネーム
# Nnn＝Nmmわ有り得るが、Nnnが全部別でSnn＝Smmが有った場合要再検討
ところで16M空間をシステムで遣う際わCバスにアクセス出来たと憶い枡が、00F00000h～00F1FFFFh(128KiB)
とか～00F3FFFFh(256KiB)とかをリニアに讀めてMMIOの同じ空間に書き込むとバンクを切り替えるのを
造ると捗りそーな？
RAM窓から讀めるのが128KiBずつナノでF0-F1デモ良さそーな？
|
| 断念 まりも 2025年8月22日(金) 15:02 |
そういうわけで汎用性のあるSCSI ROM吸い出しソフトは作れないということがわかりました。特定のボードまたはSCSI-Cバスチップ限定でしか作れませんし、ボード上のDIP、ジャンパスイッチの設定を変えることと組み合わせないと、全部は読み出せません。
ボード個別の対応を自動でするには、SCSIボード固有の識別情報を拾わないといけませんが、SCSI BIOS ROMが無い状態でそれは無理です。ただし DIPスイッチレスのボードについてはBIOS ROMがなくてもシルアルEEPROMから拾うことはできると思います。SCSI設定のほかに、ベンダ固有の文字列が入っている感じです。TEXAのHA-55BSW/BS4の設定ツールだとBIOS ROMがなくてもリソース設定可能（超便利）ですが、ボードは識別されます。TEXAという文字列比較をやっているので、多分そうです。
＞16bitのROMと云えば86板にも有馬すが、此れも16Kの繰り返しなんデスかねぇ？
RS232Cの9801-101も16bit ROMが使われています。これもおそらく16KBの繰り返しかも。なお92ボードのほとんどでは27C1024ではなくマスクROMが載っています。32KBより上位のアドレスをROM内でデコードしなければ実質容量は小さくてもいいので、無駄ってことは無くなりますね。
ところで話は変わりますが、ロジテックのLHA-201のBIOSを見ていたら、ハイレゾモード時の本体システムRAM BIOS F8000以降のところに大量のパッチを当てているのを見つけました。対象機種依存では無い部分で、おそらく80386以上のハイレゾ機共通のところです。SCSI BIOSの実行においてなんらかの不都合不具合があったのでしょうね？ もしかして92ボードでもやっているかもしれないので、確かめてみます。
|
| ハイレゾでわド～成る？ かかっくん 2025年8月22日(金) 16:51 |
唖、半量しか讀めないとしたら、ノーマルとハイレゾで分けて居ると云う事わ有馬せんか？
92板わ未だハイレゾ対応ナノでノーマルだけで試して居ましたらハイレゾも試してみて下さぃ
まぁ既存のROMを外して別に28C256等を載せるならBIOSの保存が不要デスから、BIOSのパッチでなく
全く別のプログラムを容れるなら其の板で書き込むとか？
# デモ、パターンカットだけで済むなら兎も角、要半田と成ると「できません。できる人はいいよね」な
# 人が増える感じがし枡。極力パターンカットだけで済む板を撰ぶのも一つかと
あとOneさんの板に期待するとか
|
| 92ボードROMレイアウトの情報訂正 まりも 2025年8月23日(土) 20:55 |
92ボードのROM配置ですが、128KB内で64KBズレたところにあるものは同一ではありませんでした。転送モードを設定するSW 5というジャンパピンがありますが、これを移すと別のイメージが現れます。DMA転送とI/O転送で異なるプログラムを使うようです。いっぽう64KB内に2度現れる32KBのブロックが同一内容で、しかもそれぞれ後半16KBが空っぽです。SCSIレジスタ30hのbit 7,6,5を使うのはその通りです。55ボード用に作られたROM吸い出しソフトでは7, 6しか操作しないので、正しく取り出せません。結局のところ実質容量16KBのROMイメージが実質2個だけしか存在していません。しかしROM内の配置が実に飛び飛びだったりダブりだったりというわけです。
ハイレゾモードのsystem BIOSにパッチを当てるのは、92ボードでも行っていました。過去ログでも言及していたことを思い出しました（汗 たぶんこれはミイソ公式情報に基づくものなのでしょうね。
|
| A1 空 A2 空 B1 空 B2 空 かかっくん 2025年8月24日(日) 10:16 |
詰まり128Kの16K毎に
低位← A1 空 A2 空 B1 空 B2 空 →高位、内容的にA1＝A2 B1＝B2
で、SW5でA1,A2かB1,B2かを撰ぶと。
実際に出るのわA1 A2 B1 B2の何れでせう？27C1024での調査で判り枡ね
Undocに拠るとCC0h:30hのCC2h bit5の他に<del>bit4も有るやうで</del>？
↑に由るとbit4わ不動作でしたね
但し92板・A-E10板の言及でわナイ点に留意(100板の記述全くナシ)
他の板も同様のやうに、DMAとCPU(みいそ用語 I/O,PIOと同義)が別プログラムに成るのわ普通でせう
転送の都度条件分岐するとオーバーヘッドに成増し
# RA21+に依るBIOSのRAMイヒを前提として、ROMから写す際にモードで識別する方法わナシでわナイ鴨
ところでHRパッチの内容て各板で同じdsk?
あと、メモリに対してのウェイトもCバスのIORDYで掛けられ枡か？名称からしてI/Oウェイトだけの肝？
|
| よくわからないSMITのROM まりも 2025年8月24日(日) 20:49 |
 文章で書くとわかりにくいので図で示しておきます。水色のところとピンク色の16KBは、内容が転送モードに対応した別物です。64KB（ワードでA14）の切り替えはSW5の機械スイッチによっているわけです。SCSI-Cバスチップによる切り替えは32KBまでです。
ところでSMITボードには32KBのROM 27C256/28C256が載っているものがほとんどですが、アイオーデータのSC-98IIIだけは64KBの28F512が載っています。しかもサポートプログラムとして配布されているSMIT.BINも64KBあります。さらに、SCSIレジスタ30hのbitの使い方が92と違うのか同じなのか、ROMを引っ剥がして読んでいないので不明です。SMIT.BINの内容がROM物理アドレス順でない可能性もあります。もし物理アドレス順だとすると、SCSIレジスタ30hのbit 7,6,5の使い方が92とも違うということになります。どうも 7,5,6 の順のようなのですよね。
書き込みプログラムの設計しだいなので、ファイル上のデータをROMの物理アドレス昇順にならべていなくても構わないといえば構わないのですが、わざわざそうするかどうか… なおbit4はどうも使っていないのではと思います。
ところで2、SCSIボードの機種4択設定で「80286以上ノーマルモード」と「ハイレゾ共用」はノーマルモードではどっちも動くから意味あるの？という疑問を少し上で書きました。どうも意味あるようです。それは、PCI機では「ハイレゾ共用」の設定だとROMが現れなくなってしまうという点に関係するようです。共用モードでは、本体がなにかしらCバスに働きかけないと、アドレスデコードを開始しないのでは？そしてPCI機はそれを実行しないのでは？ というわけです。そこにIORDYが関係あるかどうか？
|
| PCI機が普段しない事と手動Cバススロット かかっくん 2025年8月24日(日) 21:30 |
まぁ板とBIOSがセットで、他の組み合わせわ考えなくて良いのデスからアドレス順が板毎(BIOS毎)に
違ってもおかしくナイでせう
本来バンクを切り替えるのわ其の板のBIOS(と其の板用のツール)デスからリセット後のポートの値さえ
確定して居れば後わBIOS(やツール)がポートの値をド～変えやうと無問題デスし
# ROMの他社板への流用を防ぐ意味も有るでせう
PCI機が普段しない事と云えば、EMS板とかを差す際の儀式(リフレッシュ信号を出す)と関係有馬せん
かねぇ？関係無いとわ憶い枡が
斯う成ったら手動のCバススロットで、リセット後にBIOS空間の様子を観てみるとか？
# 完全にSW/LEDにすると面倒ナノで、手動スロットのアドレスバス他をPO(PIO)板と結ぶとか？
|
| SCSIボードのNモード機専用とHレゾ共用の働きの違い まりも 2025年8月24日(日) 22:41 |
ボード設定が「ハイレゾ兼用」のときは、ITFが実行する out 467hに応答するまでアドレスデコードを開始しないのでは？というのが最もありそうです。ノーマルモードのITFでもout 467hをやっているようなのですよね。以前I/Oボードで調べたときにLEDが点灯しなかったので、出力なしかと思いました。しかしゼロが出力された場合でも点灯しません。ノーマルモードのときはゼロ出力なのでしょう。そしてPCI機ではこの出力は行なっていません。であれば応答しないのは当然です。
いっぽう「80286以上のノーマルモード設定」ではリセット直後から応答できるという違いがあるのではないでしょうか。
【23時追記】
となれば実証あるのみ。PCI機で、「ハイレゾ兼用設定」でノーマルモードでFD起動後、out 467h , 0をやってみたところ、ROMが所定のD0000に現れました。この説は正しいようです。ちなみにout 467h，D2hとやったところROMの出現がなくなりました（というよりおそらくEE000hにマップされているけどもSYSTEM BIOSの陰で見えなくなっている）。さらに486機でこれをノーマルモード上でやるとクラッシュしました（これはSYSTEM BIOSを壊したっぽい）。やはりハイレゾ兼用設定はデコードを動的に変える仕組みであり、リセット後にout 467hが一度も発行されない段階ではハイレゾかノーマルかわからないのでアドレスデコードをしないというモードのようです。
|
| I/Oアドレスが聯續する意味って かかっくん 2025年8月26日(火) 13:31 |
デモ実際の処、I/Oアドレスが長く續いて居る意味って余り無いやうな？
どーせ1回のoutで出せるのわ最大32bit(＝4バイト)迄デスから4ッ續いてさえ居れば用が足りるワケで
I/O F040h～F043h F140h～F143h とかFx40h～Fx43hの4ッ續きで64アドレス割り当てとか
# CバスにIO00とか、I/Oアドレスの上位8bitが0でアサートする信号が有ったら上位8bitを0に確定する
# デバイスがもっと出たやうな？
唖、USB/ROM板とかを出す際わバスへの出力電流値(12mA以上。74HCバッファ不適)とかを守って
下さぃね＞Oneさん他
# TC74HC245APのIoh＝Iol＝±6mA、TC74VHC245Fで±8mA
# www.marutsu.co.jp/contents/shop/marutsu/datasheet/TC74HC245A_640A.pdf
# www.marutsu.co.jp/contents/shop/marutsu/datasheet/TC74VHC245.pdf
出力衝突の際にROMがトンだりする原因に成増。バッファを挟めばトブのわバッファで済み枡
SCSI板とかの怪造の場合、元の板が守って居枡から無問題
|
| よくやったIDE？ まりも 2025年8月26日(火) 18:39 |
それは多数の機能からなる多数のI/Oアドレスを、固定ではなく可変ににするためではないですかね。連続にしておくと、ベースアドレス＋変位 でアクセスできます。ベースを可変にするわけです。奇数だけ偶数だけの不連続でも、とにかく規則配列ならそれで行けます。PC/ATの世界では最初からフルデコードで連続的に割り付けできるので、周辺ハードウェアもそういう設計にする習慣となったのではと思います。必要性はないが必然性があったというわけです。
いっぽう98のように上位8ビットまで各I/Oアドレスがバラバラだとそうも行きません。その中でIDEのI/Oアドレスは無理やりまとめた感があります。VXくらいまでの時代の98に、IDEインターフェイスの回路をそのまま載せることはできそうな気がしません。640hから644hなんて8bitデコードだとプリンタと丸かぶりです。本体内蔵I/Oがフルデコードかの判断基準は、IDE搭載機かどうかで線引きできますかね？ ひどいデコードのSASI I/Oは廃止された機種でもあります。
|
| Soundblaster16/98 リウ 2025年8月26日(火) 20:47 |
この板のIO割付が
20D2h 21D2h 22D2h
のような付け方で奇妙だなあ、と感じていたのですがなるほどPC-98のIO空間に対しては下位8bitは固定して、上位8bitをずらすほうが便利だったのですね
自プログラムでは8bitデコード機のチェックにはA460hと0060hの比較をしていました。そうはいっても286機なら10bitか12bitでデコードしてくれてそうでした。（手持ちでは286VEが8bitIO機）
|
| バッファのIC One 2025年8月27日(水) 0:17 |
かかっくんさん、一応気にして、バッファは74ACT245の設計にしてます。
入力電流の低さから基本CMOSで組んでるんですが、ここがどうしようかと悩みポイントでした。
いくつかデータシート見てたららACTならいけそうと気がつき、ロジックIC全盛の当時もおんなじことになってACTは作られたのかなとか想像してました。
|
| 片方向バッファなら かかっくん 2025年8月27日(水) 15:16 |
 CバスのR/WピンわIOR IOW MR MWデスから245,645わ意外と遣い難かったりし枡
245でなく244が多用されたのも此の辺と関係有りそーな？
場処と予算が許せば244か541が便利そーな？
> 入力電流の低さから基本CMOSで組んでるんですが、ここがどうしようかと悩みポイントでした。
> いくつかデータシート見てたららACTならいけそうと気がつき、ロジックIC全盛の当時もおんなじことになってACTは作られたのかなとか想像してました。
当時からバッファに74S 74LS 74ALS 74F 74AC(T) 74BC(T)辺りが多用されますた
# 外付けにケーブルで引き回す物わ7407(N)や7438(N)が定番、其の後74Fにシフト
因みにCバス→板わ74(V)HCTデモ構いませんからVHCT541とAC(T)541と云うのもアリ鴨？
あとCMOSわ入力電流が少なく成増が入力容量わTTLより大きく成増。此れのドライブにも或る程度の
電流が必要デス
|
| 若し98のIDE(略)がMMIOだったら かかっくん 2025年8月27日(水) 23:08 |
 若し、98のIDE(擬きHDD I/F)がMMIO(BIOSやワークエリアの一部をI/Oとする)
だったら転送がもっと速く成って居たでせうかねぇ？
> それは多数の機能からなる多数のI/Oアドレスを、固定ではなく可変ににするためではないですかね。連続にしておくと、ベースアドレス＋変位 でアクセスできます。ベースを可変にするわけです。奇数だけ偶数だけの不連続でも、とにかく規則配列ならそれで行けます。PC/ATの世界では最初からフルデコードで連続的に割り付けできるので、周辺ハードウェアもそういう設計にする習慣となったのではと思います。必要性はないが必然性があったというわけです。
out DX+reg,ALとかout DX+imm,AXとかってコード有馬したっけ？MMIO(mov [BX+DI],ALとか)なら
解り枡が
奇数偶数でなくても100h飛びとか1000h飛びとかデモ規則性を出せ枡し
add DX,4とかやるならinc DH(add DX,100h)とかデモ済み枡し
確かにPC/ATの時点なら0～3FFhがシステム予約で400h～を遣える仕様に成って居枡がXT迄わド～だったか？
# 今更PC 5150やXT・其れ等の互換機で追試する気にわ成れん。IBM JXなら値段にも依るが欲すぃ
> いっぽう98のように上位8ビットまで各I/Oアドレスがバラバラだとそうも行きません。その中でIDEのI/Oアドレスは無理やりまとめた感があります。VXくらいまでの時代の98に、IDEインターフェイスの回路をそのまま載せることはできそうな気がしません。640hから644hなんて8bitデコードだとプリンタと丸かぶりです。本体内蔵I/Oがフルデコードかの判断基準は、IDE搭載機かどうかで線引きできますかね？ ひどいデコードのSASI I/Oは廃止された機種でもあります。
VXの場合、8bitデコードでなく10bitデスから640hならLPTと別な気が？
# 10bitわbit10とbit11がデコードされ*0**h～*3**h *4**h～*7**h *8**h～*B**h *C**h～*F**hに分かれる
# 尚A3等下位bitのイメージ(A3なら***0h～***7h＝***8h～***Fh)わnbitデコードに含まない
確かVM2,UV2辺りから(XAから？)10bitデコードに成ったやうな？
# U2わ微妙
# 画像わVX21の場合。FDD/HDDだけの差のVX01,41も同様、多分VM21,VX0,2,4も同様？
# VM2の調査デモ同様。同差のVM0,4も同様。RA後期(RA21<del>51から(略 過去ログ参照)</del>)も同様との報告
# 訂正 RA後期わRA21で、(略)わRL/51
VXの時点で*440h～*74Ehに割り当てたI/Oわ無かったやうな？
其れも考えて640h～64Eh 74Ch 74Ehにしたの鴨？
同じチップセットならデコードも同様デスからチップセットの世代が変わったF*やCS,UR,UF,US
辺り希望
確かおふがおさんのIDE板ってI/Oアドレスがオンボードと同様だった気がし枡がセカンダリを増設すれば
NECCDC辺りなら動きそーな？
IDEわ98のてでわ初期(NSわ兎も角NS/EならI/Oが同じ希ガス)から載って居ましたから余り判断基準に
成らない気が？
机上機ならURからでしたっけ？＞IDE
|
| IOアドレスが上位で連続 One 2025年8月28日(木) 9:43 |
同じボードで複数のアドレスを使う際に下位が固定、上位8bitで変更する手法はトラ技スペシャルno.3(1987年）に望ましいとして書かれていました。
皆さんが述べている理由で下位が飛び飛びでかつ、下位しかデコードされていないものも多いため、上位のビットで複数とるべきとなっています。
拡張ボードの設計をする上では皆さんこの号は見ていたと思われるのできっと参考にしていたのだろうと思います。
あと、バスバッファは双方向を使いたいけど、確かにきれいにハマる正解が良くわからないんですよね。でも結構245は使われているので、いろいろな設計でどうしていたのかが気になっていろいろ買ってしまいます。
|
| 98RLの本体内および周辺I/Oのアドレス まりも 2025年8月28日(木) 18:35 |
＞out DX+imm,AXとかってコード有馬したっけ？
書き方が悪くてプログラム側の話と理解されてしまいましたが、ハードウェア回路のほうです。アドレス飛び飛びはまだしも、規則性に乏しいほどだとデコード回路で共用できる部分が無くなってしまって面倒です。バイトで連続ならA0だけ、偶数か奇数で飛び石連続ならA1だけデコードして残りは共用できます。
どの機種まで何bitデコードなのか、RLまでの機種のマニュアルには書かれているのですが、それ以降は（買ってもないですが）少なくともAnのマニュアルにはもう無かったです。
PC-98RLのマニュアル（旧タイプRL、92ページ）に書かれている情報を載せておきます（画像）。誤植とみられる点があるので、その箇所は勝手な判断で直した上で赤文字にしています。それと、RLには確実にある未記載のI/Oを補足として載せておきました。【23:28訂正】DMAのベースアドレスは01hです。ですがマニュアルではbit 0に0と書かれています（画像2）。これらも誤植でしょうね（おそらく正しくは1）。そのほか画像１で1MB FDCのところ間違っていたので訂正。こういうのは手作業で写してもミスするので、写植屋／印刷屋泣かせだったと思います。【／画像３にて訂正】
【31日追記】9801VX21のマニュアルにも同様の説明表がありますが、そちらでは誤植はありませんでした。画像２の赤線のところは正しいものになっていました。
これを見る限りでは、VX～RLの時代には本体機能のほとんどは少なくとも10bitデコードです。8bitデコードになっているのは、それ以前からあってCバスボードであったものです。拡張ボードは"緩く"作られていたということのようです。
これをみてやばいと思うのが「サウンドボード」です。14か26Kかわかりませんが、188hからなので中途半端な9bitデコードじゃないですか。ハイレゾのメモリウィンドウ91h,93hが8bitなのも初めて気がつきました。いっぽうセントロプリンタI/Fはこの時点で10bitなのでIDEの回路を持ってきても確かに大丈夫そうです。この時代の「ネットワークボード」って何ですかね？PC-9864?
ところで98ノートでは xx8Ehというのをノート独自機能として大量に割り当てています。008Ehというのはこの表を見る限り何かに使われることがなかったので、上位8bitを全部ガメてノート機能にしたようです。
【20時追記】カレンダ時計ですが、bit3-1がxつまりデコードされなくて良いになっています。このため20hのデータは22h，24hなどにも現れてしまいます。Cyrix486がキャッシュ制御のためにCPU内部で22h-23hを使うのですが、これとぶつかるのですよね。
|
   |
| 老舗メーカでわ常識だった鴨？ かかっくん 2025年8月28日(木) 19:21 |
> 同じボードで複数のアドレスを使う際に下位が固定、上位8bitで変更する手法はトラ技スペシャルno.3(1987年）に望ましいとして書かれていました。
> 拡張ボードの設計をする上では皆さんこの号は見ていたと思われるのできっと参考にしていたのだろうと思います。
当時からの設計者わ讀んだと憶い枡が、後年の設計者わ此の記述が無いトラ技SP45の方を参考にして
居そーな？
# 阿、愚々れば出るのか＞トラ技SP3
# 讀んでみる(国内からリードオンリー)か
あとメーカの設計者とかの間でわ常識だった鴨？
アダプやSB16のクリエイティブのやうにPC先行で98にわ後発参入のメーカわ然うデモナイ設計をして
居たりし枡が
> あと、バスバッファは双方向を使いたいけど、確かにきれいにハマる正解が良くわからないんですよね。でも結構245は使われているので、いろいろな設計でどうしていたのかが気になっていろいろ買ってしまいます。
市販の板で245の向きを決めるのわ制御石に入って居そーな？
IORやMRの間だけCバス側にして、他わ板の内側に向ければCバス側の衝突を避けられそーな？
>＞out DX+imm,AXとかってコード有馬したっけ？
> 書き方が悪くてプログラム側の話と理解されてしまいましたが、ハードウェア回路のほうです。アドレス飛び飛びはまだしも、規則性に乏しいほどだとデコード回路で共用できる部分が無くなってしまって面倒です。バイトで連続ならA0だけ、偶数か奇数で飛び石連続ならA1だけデコードして残りは共用できます。
アドレスデコーダの噺でしたか、確かにアドレス一覧を見ると**@#hの@と#(奇数・偶数)で石を分けて
居る感じデスね
> PC-98RLのマニュアル（旧タイプRL、92ページ）に書かれている情報を載せておきます（画像）。
> 誤植とみられる点があるので、その箇所は勝手な判断で直した上で赤文字にしています。それと、RLには確実にある未記載のI/Oを補足として載せておきました。【訂正】DMAのベースアドレスは01hです。ですがマニュアルではbit 0に0、bit4にA3と書かれています（画像）。これらも誤植でしょうね（おそらく正しくはbit 0は1、bit4は0）。【／訂正】
DMACが10hに成って居枡が、io_dma.txtやトラ技SP45他に01hと有馬すね
RLのマニュアルに10hと有馬すか？
DMACわ1～1Fhデスからbit4わA3で合って居るかと？
> これをみてやばいと思うのが「サウンドボード」です。14か26Kかわかりませんが、188hからなので中途半端な9bitデコードじゃないですか。ハイレゾのメモリウィンドウ91h,93hが8bitなのも初めて気がつきました。いっぽうセントロプリンタI/Fはこの時点で10bitなのでIDEの回路を持ってきても確かに大丈夫そうです。この時代の「ネットワークボード」って何ですかね？PC-9864?
音源に依って標準の188hと288hか088hの切り替えが有り、188hと288hや088hわ別板と見做され枡から
26系以降わ多分10bitかと
ネットワークボードと通信制御アダプタが有馬すが、恐らく前者がB4670(9864他)、後者がISDNかと
HR RAM窓わCMT I/FのI/Oの再利用デスから**91h～**97hを予約としたのでせう
未デコードのアドレスでイメージが出た空間わみいそ的に予約と云う事で
メーカ品が出尽くした今日でわイメージが出ないアドレスを見付けて遣っても支障無さそーでわ有馬すが
勝手に固定で遣うのでわなく可変にすべきとわ憶い枡
> 【20時追記】カレンダ時計ですが、bit3-1がxつまりデコードされなくて良いになっています。このため20hのデータは22h，24hなどにも現れてしまいます。Cyrix486がキャッシュ制御のためにCPU内部で22h-23hを使うのですが、これとぶつかるのですよね。
Cx486に限らず、Cx5x86やCx6x86(/MX)も同様(I/O 0022h,0023h)デス
まぁCx5x86や6x86の対象機種の殆どわ16bitフルデコードの上4990でなく4993系の9821でせうが
# EUD-Hわ4990で一部未デコードのDA,RA21,51用
|
| 古い機種ではWSSが正常に再生されない KAZZEZ 2025年8月29日(金) 2:01 |
そういえばVXやRA21のような古い機種ではなぜかメルコWSN-AやWSN-VのPCM音源部がうまく再生されない症状がありましたっけ。ちょうど割り込みが競合しているときのような、短い音を繰り返す症状ですが、INTやDMAの設定をどう変えても直りません。Bfとかでは正しく設定すれば問題なく再生されるのでわけが分からなかったのですが、もしかしてこれも古い機種のI/Oデコードによる競合だったのでしょうかね??
とりあえずWSNの95ドライバのinfを見る限り、WSNのPCMが使用していそうなI/Oは、MATE-X PCMと同じ「0F40～9」「A460」の他に「5nEE～EF（n=1-2,6-7,9-B）」がありましたが…どうなんでしょうね。
[後方参照 (14:30追記)]
VX相当機（286）で、debugで「i 340」は00が読めましたが、「i F40」だとFFのようでした。ボードを装着してDOS上の専用ツールでPCM音源を有効化させるとF40はFFではなくなりましたが340の00とは別の値が帰ってくるようになります。どるこむのログではCPUアクセラレータで不具合が起きたという報告もありましたので、もしかしたら違うところに原因があるのかもしれません…。(汗;
|
| 互換機のIOデコード One 2025年8月29日(金) 9:29 |
＞ PC/ATの世界では最初からフルデコードで連続的に割り付けできるので、
PC/ATそのものは12bitしかデコードしない仕様でったので、AT時代の古いISAカードを使うと上位4bitは怪しいかと。（AT互換機とは？と思う）
あのアーキだとPC/XTは8088を採用していて8bitデータバスだったので偶数/奇数に関係なく詰められるのは良いですよね。8bitカードでは、D8-15がD0-7に転送されてきますし。
ROMボードのバッファはタイミングで悩むなら541使った方がすっきりするかと考え、回路修正中です。
このボード、IOアドレスもROMアドレスもけっこう自由に動かせるんですが、自分の目の届かないところでも使われることを考えると悩ましいですね。IOは偶奇はありますがどこにでも置ける仕様になってますし、ROMもC0000h以降の1M空間内に配置できてしまう。
自分用にはいろいろ遊べるし基板流用できて良いんですが、98アーキを知らずに変な設定にするとおかしな衝突が起きる危険性を感じてます。
|
| 9801FA前と後 まりも 2025年8月29日(金) 11:13 |
＞WSNのPCMが使用していそうなI/O
ミイソが、ユーザへの脅かしではなく本当にマニュアル記述通りにデコードしているのかどうかです。in 340h を実行して何かの値、例えば00hなどが読めるようなら、そうです。in F40hでも読めるようならもうダメです。RLのマニュアルの記述を見ると、一応10bitのようでもところどころ低いbitのところにx があって穴だらけという感じです。 本体内蔵モノがフルでコードになるのは、ノート機から、9821からとみて良さそうですかね。FAのあたりが境目？ 【追記】RLで実際やってみたところ、プリンタポートについては10bitデコードでした。F40h-は使えるはずです。他もいくつか調べましたが、ミイソが「ユーザを脅かして」ということはなく、概ねマニュアル通り（誤記除く）に作られているようです。
＞PC/ATそのものは12bitしかデコードしない仕様
そうだったのですか。これもいつ頃から16bitになったかですが、連続割り当てなので、98ほどの問題は起きにくそうです。
＞98アーキを知らずに変な設定にすると
ハードウェアEMSボードも、メモリアドレスはどこにでも設定できてしまう「凶器」です。「のっぺらボード」に至っては意図的にI/O入力に被せにきて本体FDC I/F を乗っ取りに来ます。リセットしても回復しない状況に陥ったことがあります。本体が壊れなかったのは運が良かっただけかもしれません。【追記】そういえばSCSIボードですらも、このスレッドで書いたように意図的にハイレゾ機に振る舞うI/O 467hを叩くと、ROMアドレスがSYSTEM BIOSとかぶって、機種によっては即動作がおかしくなりますね。
|
| ISAとCバス 一長一短 かかっくん 2025年8月29日(金) 15:35 |
> あのアーキだとPC/XTは8088を採用していて8bitデータバスだったので偶数/奇数に関係なく詰められるのは良いですよね。8bitカードでは、D8-15がD0-7に転送されてきますし。
ATで此の仕組みを導入した際、本体側の仕組みわ複雑に成りますた
# ATより先に286や8086,186を導入した互換機が有ったか？わ不明
# 尚、国内のPS/55以前のIBM 5550系(マルチステーション)わ8086だが非PC系
デモ本体側での事デスからカード側わD0-D7に寄せれば良く、D8-D15わ16bitだけで済み考え方が単純で
済み枡
但し、引き換えに98のやうに複数の石を同時にI/O出来ませんが
# RS-232Cの32hとシステムポートBの33hを同時にin出来、RS-232C状態線の状態を両方から同時に
# 得られる
> このボード、IOアドレスもROMアドレスもけっこう自由に動かせるんですが、自分の目の届かないところでも使われることを考えると悩ましいですね。IOは偶奇はありますがどこにでも置ける仕様になってますし、ROMもC0000h以降の1M空間内に配置できてしまう。
実際に出す際にわ、初期状態でI/O *@D*hだけ、ROM C0000h～DFFFFhだけにしておくと良いでせう
@: 0～7
パンドラの函を開けるにわパターンカットとかを必要にして其の事を周知せずに、其れをしたらもう
知らないと云うスタンスとか？
# A5000h～A7FFFhわ遣っても良い鴨
起動時に実行するにわC****hわ無意味でせう。D*にINITルーチンだけ置いてC*やA5-A7にメインルー
チンを置くのわアリ
>＞WSNのPCMが使用していそうなI/O
> ミイソが、ユーザへの脅かしではなく本当にマニュアル記述通りにデコードしているのかどうかです。in 340h を実行して何かの値、例えば00hなどが読めるようなら、そうです。in F40hでも読めるようならもうダメです。RLのマニュアルの記述を見ると、一応10bitのようでもところどころ低いbitのところにx があって穴だらけという感じです。 本体内蔵モノがフルでコードになるのは、ノート機から、9821からとみて良さそうですかね。FAのあたりが境目？ 【追記】RLで実際やってみたところ、プリンタポートについては10bitデコードでした。F40h-は使えるはずです。他もいくつか調べましたが、ミイソが「ユーザを脅かして」ということはなく、概ねマニュアル通り（誤記除く）に作られているようです。
VXやRAのin 340hなら画像に有る通り040h(LPT)のイメージが出て居枡
此れわxxxx 00xx (以下略)とあるマニュアル通りでせう
440h～740h・1840h・3840hに出なかった事から、F40hならLPTのイメージわ出ない希ガス
41h 43h (イメージ45h～4Fh)わキーボードに成って居枡から不用意にI/Oを試すと(略)
デバッガをRS-232C経由にするとか良いでせう
A460hわみいそがVXやRAも対象機種として居る86音源にも有馬すからおkな筈
> そうだったのですか。これもいつ頃から16bitになったかですが、連続割り当てなので、98ほどの問題は起きにくそうです。
チップセットに依る構成に成ってからの気がし枡
但し486の頃わいんてるのチップセットわ(少なくとも国内で)マイナーだったので(略)
P5以降の430系PCIset以降なら間違い無いでせう
# 機種に依存するデバイスを全てサウスにしてノースを共通で遣えるやうにしたかのやうに見えたが
# メモリ管理等にも機種の違ィが有りA20マスク(メモリでなくCPU周り)をサウスにしたものの98の
# バンクRAMが廃止される一因に成った。尤も其の頃バンクRAMのユーザわ少なく実害わ少なかった
I/O 22hもチップセットの設定用で、Cyrixが未使用レジスタをCx486～6x86MX(～M3,Geode?～？)に
流用したらιぃとか？
まぁCyrixが98用とかFM用として出したワケでわナイので其れ等で動かなくてもCyrixへのクレームわ
論外デスが
# 其の場合クレームわI-O他98向け等特定の機種用アクセラを出した販賣元へ
> VX相当機（286）で、debugで「i 340」は00が読めましたが、「i F40」だとFFのようでした。ボードを装着してDOS上の専用ツールでPCM音源を有効化させるとF40はFFではなくなりましたが340の00とは別の値が帰ってくるようになります。どるこむのログではCPUアクセラレータで不具合が起きたという報告もありましたので、もしかしたら違うところに原因があるのかもしれません…。(汗;
I/O 340hが0とわ限らず040hに出力して居ると別の値の場合も有馬す。i 40＝i 340かド～か？デス
VXならLPT用8255(LPTとRS-232Cの間？)のCSピン(DIPなら6)かRDピン(5)を精密ニッパでカットして
Vcc(26)にPUしてみると340hが変わり枡か？
ポートBもポートCも大した事をして居なさそーナノでカットしてみませう
# カット前に本当にLPTとRS-232Cの間の8255がLPT用か？を再確認して下さぃ。間違えてシステム
# ポート用なら大変な事に成増
ところで、INFファイルの内容より窓で認識されたリソースのが正確な気がし枡。特にPnP板の場合
|
| PC/ATは10bitでした One 2025年8月29日(金) 22:47 |
自分で書いて、何か変・・・と再度IBMのテクニカルリファレンスで確認すると、A9までの10bitですね。参考にした文献が間違ってた。
3FFhまでなので、3xxhあたりはかなり渋滞している感じです。
それにしても、回路図も見るとシステムI/OはA8/A9が0ときA5/A6/A7の3bitで8個のICに振り分けて使っているというかなり贅沢仕様で、1つあたり5bitもあるから下はスカスカです。
IBMだとPS/2は16bitデコードですね。OADGのドキュメントに書いてあります。
他社もPS/2のMCA対抗のEISAはINTELからチップセットが出ていますから16bitだったのでは。
自作ROMボードの設定は、自分がいろいろできるボードが欲しくて作ったものなので、なるべく使える人は広く使ってほしいですが、危ないですよね。
あとアドレスAxxxxhの設定は、A18用の選択が必要なのでSWの追加がいるので悩ましいですね
|
| 3xxhあたりの渋滞と云えば かかっくん 2025年8月29日(金) 22:59 |
> 3FFhまでなので、3xxhあたりはかなり渋滞している感じです。
同じアドレスにFDCとST-506が同居して居たり(過去ログ参照)
# 名残がIDEの中後期迄續いた
> あとアドレスAxxxxxhの設定は、A18用の選択が必要なのでSWの追加がいるので悩ましいですね
『A5-A7希望者わ要ジャンパ』としてジャンパ用の穴を開けておくだけデモ良いでせう
|
| 結局よく分からず KAZZEZ 2025年8月30日(土) 0:16 |
WSNの件は環境を書いていませんでしたが、不具合は2k上でNT4ドライバで動かしたときに確認しています(VX・RA21・Bfで同じHDD環境を使いまわし)。
試しにVXのDOS上でPCMを使うゲームで試したところ、FM音源無効だと予想通り再生されなかったりハングしましたが、なぜかFM音源が有効のときに限りPCM再生ができました。WSNのハードウェア内部、もしくはドライバの問題でしょうか？
> INFファイルの内容より窓で認識されたリソースのが正確な気がし枡。特にPnP板の場合
逆を言えば非PnPの場合はデバイスマネージャのリソースはあまりアテにならなかったりします。2kだとオンボードシーラスなんかはリソースが表示されませんでしたし（9xからのアップグレードインストールだとデバイスマネージャにリソース情報が残っていることがあります）。そうでなくともNTドライバではレガシーボードのリソースが全く表示されない場合があります。WSNのNTドライバもコントロールパネルのマルチメディアからリソースを設定しなければなりません。
> 間違えてシステムポート用なら大変な事に成増
今回そこまでやるのはやめておきます。(^^;)
VM21/VXのマザーは予備も無いですし（CPUボードとEGCボードだけ確保していますが）。
|
| Cx486の22h One 2025年8月30日(土) 17:15 |
>【20時追記】カレンダ時計ですが、bit3-1がxつまりデコードされなくて良いになっています。このため20hのデータは22h，24hなどにも現れてしまいます。Cyrix486がキャッシュ制御のためにCPU内部で22h-23hを使うのですが、これとぶつかるのですよね。
Cx486は扱ったことがないのですが、ROMに書くキャッシュコントローラーは作ってみたいのでちょっと気になりました。
Cx486の22hって適正な値をOUTした場合、CPUの外部には出ないと思っていたんですが、実は信号が出てるんでしょうか。
PC/ATも20h/21hは使っていてA1～4がデコードされていないので22hにも現れてるはずで、286置き換えで問題になりそうと思い疑問になりました。
もしくは、PC-98の判定ややこしいので、CPU判定で22h/23hの反応確認しないと有無のしきれなかったりするのかもとは想像しました。ちゃんとやり切るのは大変そうです・・・
|
| ドキュメントに記述有り かかっくん 2025年8月30日(土) 19:26 |
確かデータシートだかマニュアルだかを讀むと然う書いてあった気がし枡
(今年4月の買い物ヤフオクX(旧ツイッター)ウォッチスレ参照)
ematei.s602.xrea.com/cgi-bin/bbs39_ris3/bbs39.cgi?mode=past&year=2025&mon=4
逆にRTC(4993系)が設定されない可能性のが有りそーな？
# 但しI/O 22hわ4993の互換モードと拡張モードの切り替えの為殆ど支障無し
因みにI/O 22hの【直後の】I/O 23hが外に出ないそーデスからI/O 23hの配慮わ不要そーな？
# 間に他の命令が入るとI/O 23hが外に出る(設定もされない)のでCLIする事。可能ならNMIも無効に。
NMI無効が98で出来枡がPCデモ出来るか？わ知りません
|
| もっと前の まりも 2025年8月31日(日) 0:06 |
過去ログは2024年 5月のほうではないですかね？
ttp://ematei.s602.xrea.com/cgi-bin/bbs39_ris3/bbs39.cgi?mode=past&year=2024&mon=5
自分でも忘れかけていますが、以下のようなことを書きました。
----以下引用
ところでCX486IPLでは、CPUIDを0000:486のシステム共通域から得ていましたが、これは元80286機では不可能なんですね。意図的にリセットかけて調べるしかないですかねぇ。ただそうなると仮想86では動作しなくなります。Cyrix限定なので先にI/O 22hをつついて23hを読み出すといいですかね。いきなり23hを読み出すとDMAコントローラのほうに行ってしまいます（W/Oなので返り値はFFh）。Cyrixのデータシートを読む限りでは、22hを正しい値で叩いたあとはCPU外部に23hが出ることはなくなるようです。その後は22hに無効な値を叩き込んで元に戻しておかないと、本当の23hのDMAコントローラの方に書き込みできなくなってしまうようです。
----引用終わり
このときの議論では、CX486のキャッシュツールのIPLware化はあまり有用でないかもという結論でした。DOSが起動した後にXMMやEMMでCPUリセットされると、設定が飛んでしまうからです。ROMアプリでキャッシュ有効化の場合も同様のことになると思います。それでもSCSIボードが100ボードのときは、BIOSエリアをキャッシュ可にするとデバイススキャンの時間が短縮されるようなことは期待していいかもしれません。いっぽう33C93なボードのBIOSではROMバンクが切り替わるのでキャッシュ不可です。
|
| キャッシュ再設定ルーチンの置き場の問題も？ KAZZEZ 2025年8月31日(日) 2:35 |
> XMMやEMMでCPUリセットされると
…と言いますか、結局RAM化可能な元386機ではそちらにキャッシュ再設定ルーチンを置いて対策されたんでしたよね。それができない元286機や、仕様の不明なEPSON機において、ROMアドレスに再設定ルーチンを置いてそこを呼び出せるようにする手もありそうな気が…？
|
| DOS起動までの間の効果にどれだけ熱を注ぐか まりも 2025年8月31日(日) 8:21 |
元80386機の場合、設定ルーチン本体は拡張ROMボードに置くことで、本体RAM 上のSYSTEM BIOSに置かれるコードの量を少し減らすことができます。
元80286機ではどうするのがいいですかね。SYSTEM BIOSとITFにはCPUリセットからの復帰ルーチンがあるわけですが、ここからCX486キャッシュ設定に自動的に飛び、元々走っていたところに何事もなかったように戻らなければなりません。
ここがどうにもならないので、本体ROMの書き換えしか方法がないような、、、それとも、あらかじめ拡張ROMボードのEEPROMに本体のF0000h以降のROMをコピーしてパッチも当てて、本体のROMを引っこ抜いて動くかどうか？これができれば結構凄いですね。しかしそこはF8000以降がバンク切り替えのため、本体ROMに戻さなければならない期間があります。本体ROM（ITF側）と拡張ボード上のROM（SYSTEM BIOSのコピー）とを自動的に切り替える機構（out 43Dhに応答する）でもつけない限りやっぱり無理です。それなら全部ROMボード上のROM内容で切り替えるか。まずは80286機で本体ROMに来ている信号がどこまでCバスと同じなのか調べてみるのは面白そうですね。
それでもDOS起動後は、EMMを使う場合はそれに内蔵のCX486キャッシュ設定に頼った方がいいと思います。
|
| 拡張ROMでやるなら One 2025年8月31日(日) 13:50 |
＞過去ログは2024年 5月のほうではないですかね？
読みごたえあり、非常勉強になりました。リセットの挙動は厳しいですね。
自分もDOSや他のOSが使えるならそこで処理するのが妥当だと思います。
拡張ROMでやるなら、やはりFDゲーム対応でしょうね。気にせずFD起動してキャッシュONで使えると嬉しいのでは。
ほぼVM以降ターゲットで、プロテクトモードは使われていないと思いますので、一度設定しておけば使えそうな気がします。もしリセットを使ってたら、他のツールでも駄目だから、しょうがないかなと思いますし。
キャッシュに限らずDOSやIPLで手出しができる状態だと、そこで設定するツールがいろいろあるので、空間も広いしそこでやれば良いかなと自分も思います。拡張ROMでは、FD起動するゲーム等で使えるツールが便利な気がします。サウンドボードの設定などなど。
あとはHDDの付け替えが多い人等にも良いかもしれないので、同じことをするにしても処理位置の選択肢は多いに越したことはないですが。
|
| Cx486のI/O 22hと23h かかっくん 2025年8月31日(日) 15:46 |
 窓NT,2kわ窓9xのやうに総当たりで検知(アノHDDゴリゴリの正体)しないので
非PnPデバイスが正しく出ないのでせう
FDゲーム起動前の設定ならFD-IPLwareで用が足りそーな？
本当にROMが必要な用途と云えばDIV0やSASI籠のみいそチェック回避等、
他のBIOSのINITルーチン介入の場合でせう
I/O 22hについて、去年5月のSYSスレにわ↑の段落しか無かったやうデス
あと、今年4月のXスレに有る通り、22hに設定と無関係な値をoutすると通常通り出てくる(設定後に
22hに無意味な値のout不要)やうデス
# TI486SXL/SXLCデータシート 頁2-9に「I/O 22hの値がC0h～CFh以外で外に出る」と記述有り
# 4993の設定わ0*hか1*hの為無問題。4990機わI/O 20hだけで済むので外に出ないなら無問題
# 其れなら内部設定のout 22hをword outにしてほしかった鴨、外に出ないのデスから23hの考慮が不要デスし
www.bitsavers.org/components/ti/TI486/1994_TI486SXLC_and_TI486SXL_Microprocessors_Reference_Guide.pdf
> ここがどうにもならないので、本体ROMの書き換えしか方法がないような、、、それとも、あらかじめ拡張ROMボードのEEPROMに本体のF0000h以降のROMをコピーしてパッチも当てて、本体のROMを引っこ抜いて動くかどうか？これができれば結構凄いですね。しかしそこはF8000以降がバンク切り替えのため、本体ROMに戻さなければならない期間があります。本体ROM（ITF側）と拡張ボード上のROM（SYSTEM BIOSのコピー）とを自動的に切り替える機構（out 43Dhに応答する）でもつけない限りやっぱり無理です。それなら全部ROMボード上のROM内容で切り替えるか。まずは80286機で本体ROMに来ている信号がどこまでCバスと同じなのか調べてみるのは面白そうですね。
ROM板の方にもI/O 43Dhを載せ枡。12hだけ板のEEPROMを接続して他わ切り離し枡。
本体のROMにわアドレスに応じてCSを出すアダプタを噛ませ枡
# バッファが有ったら(略)ROM自体をEEPROMに置き換える方が近道鴨
VX(,VM21)ならCPU板のROM板を抜くだけで良さそーな？寧ろROM板をEEPROM板に替えるとか？
其処迄するならいっそSRAMも載せてE8-FFのRAMイヒも出来るやうにするとか？
# 64Kx16のSRAM有るやうデス
# VX01,21,41の場合2組有り両方必要？但し286/8とV30の両方で遣われる事に留意
UXもBIOS SASI FMのROMが別デスからROMを抜けば良いでせう
# 恐らくLXも別
RX,EX,DXの場合SASI(RX～)やFM(EX,DX)と兼用デスから面倒そーな？
まぁ286機に此処迄する意味が有るかド～か？わ別の噺
ところで、Cx486SLC/DLCとTI486SXLC/SXL(Potomac)のデータシートを較べると、CCR0のbit6の
意味が違ィ枡ね(Cx486わキャッシュを2ウェイかダイレクトか、Potomacわ内部クロック1xか2x)
CCR1も違ィ枡
|
| I/O 22hダダ漏れ問題 まりも 2025年8月31日(日) 22:26 |
試しにIPLware用の拙作CX486IPLをROMアプリ化してみましたが、DOS起動までの時間はわずかには短縮しました。ないよりマシではあります。さらに効果を期待して、少々危ないF8000～をキャッシュ可にしてみましたが、とくに問題は起こりませんでした。Cバス拡張ボードのROMスキャンの間にF8000～のSYSTEM BIOS のROMバンクがITF側になるようなことはないのでしょう。意図的にITF側に切り替える人なんて開発者か解析者しかいないので、もうF8000～はキャッシュ可をデフォルトにしていいような気がしてきました。
＞HDDの付け替えが多い人等にも良いかもしれない
わたしなどはまさにこれで、CX486のキャッシュソフトをできればIPLwareには入れたくないのです。RLでしか走らせることは無いですから。ROMボードアプリなら、動作機種はもうそこの本体しかありませんので、機種判定ルーチンを手抜きできるというメリットがあります。
さてI/O 22hのダダ漏れ問題のほうです。Cx486キャッシュ設定中、22hにはC0h～CFhしか出力せずその直後に23hに読み書きします。この状態の解除にはそれ以外の値の出力なので、D4990Aのほうに出てしまう可能性はあります。D4990Aへのコマンドとして無効ないしは安全なダミーの値を出力しておけばいいのかもしれません。00を出力するとD4990Aのコマンドとしては「レジスタ保持」らしいので、カレンダ時計に作用することはなさそうです。心配ならコマンドとして無効値の07hでもいいかもしれません。【0時追記】次のコメントによれば、22hにダミーを出力しなくてもいいとのことです。「2回目以降の23hへのI/Oは素通しになる」ということから、一度でも23hへのI/Oを実行すれば自動的に解除になるわけですか。不用意に22hをC0-CFで叩いてそれっきりにするようなバグを作らない限り、無問題ということになります。【／追記】
なおRLでCx486DLCのキャッシュ制御プログラム開発中に何度も変な値で22hを叩きましたが、カレンダ時計がおかしくなったことはありませんでした。経験的にも心配要らないように思います。例えばメーカ製のキャッシュユーティリティで時計が狂ったなんていう話は聞いたことがありません。
＞ROM板の方にもI/O 43Dhを載せ
ここまでROMボードを作り込めばもうITF/BIOSの書き換えは何でもOKになりそうですが、80286機まででしょうかね。ROMに27C4000が使われている486機では、Cバスにアドレスは出ていそうですが、ChipselectやOEなどがCバスのMRCと同じタイミングとは思えません。
|
| データシートから引用、設定モード解除の要否って？ かかっくん 2025年8月31日(日) 23:41 |
> さてI/O 22hのダダ漏れ問題のほうです。Cx486キャッシュ設定中、22hにはC0h～CFhしか出力せずその直後に23hに読み書きします。この状態の解除にはそれ以外の値の出力なので、D4990Aのほうに出てしまう可能性はあります。D4990Aへのコマンドとして無効ないしは安全なダミーの値を出力しておけばいいのかもしれません。00を出力するとD4990Aのコマンドとしては「レジスタ保持」らしいので、カレンダ時計に作用することはなさそうです。心配ならコマンドとして無効値の07hでもいいかもしれません。
データシートにわ其んな事書いて居ないんデスけど必要な事dsk?
# データシートにわ「無効値を出すと其の儘外に出る」と有るだけで「設定後解除せよ」とわ無い
其れともI/O 22hにC*h(有効値)を出した後にI/O 23hを出さない場合dsk?
CYRIX Cx486SLC MICROPROCESSOR Data Sheet Febuary 1992 の頁2-22および
CYRIX Cx486DLC MICROPROCESSOR Data Sheet May 1992 の頁2-22
2.3.2.4 Configuration Registers
に
---
Access to the Configuration Registers is achieved
by writing the address (referred to as the index)
of the register to I/O port 22h. I/O port 23h is
then accessed to read or write data from or to the
configuration register. Accesses to the on-chip
configuration registers do not generate external I/O
bus cycles. However, each I/O port 23h opera-
tion must be preceded by an I/O port 22h opera-
tion, otherwise the second and later I/O port 23h
operations are directed off-chip and produce
external I/O bus cycles. Accesses to I/O port 22h
with an index outside of the CO-CFh range also
result in external I/O cycles and do not effect the
on-chip configuration registers.
---
と有馬す。又 TI486SXLC and TI486SXL Microprocessors Reference Guide 1994 の頁2-9
2.3.3.2 I/O Address Space Range
に
---
The I/O locations
22h and 23h are used for Configuration register access on all versions of the
TI486SXL(C) microprocessors.
The TI486SXL(C) family of microprocessors address space is accessed using
IN and OUT instructions to addresses referred to as ports. The accessible I/O
address space is 64K bytes and can be accessed as 8-bit, 16-bit, or 32-bit
ports. The execution of any IN or OUT instruction causes M/IO# to be driven
low, thereby selecting the I/O space instead of memory space for loading or
storing data. The upper eight address bits of the TI486SXLC processor and
the upper sixteen bits of the TI486SXL processor are driven low during IN and
OUT instruction port accesses.
(此の項わ22h/23hとわ無関係)
The microprocessor Configuration registers reside within the I/O address
space at port addresses 22h and 23h and are accessed using the standard IN
and OUT instructions. The Configuration registers are modified by writing the
index of the Configuration register to port 22h and then transferring the data
through port 23h. Accesses to the on-chip Configuration registers do not gen-
erate external I/O cycles. However, each port 23h operation must be preceded
by a port 22h write with a valid index value, otherwise the second and later port
23h operations are directed off-chip and generate external I/O cycles without
modifying the on-chip Configuration registers. Also, writes to port 22h outside
of the microprocessor index range (C0h to CFh) result in external I/O cycles
and do not affect the on-chip Configuration registers. Reads of port 22h are
always directed off-chip.
---
と有馬す。何処にも「設定後解除せよ」と書かれて居ませんが、何のツールも設定後にダミーコマンドを
出して居枡か？
或いわ無効値を出さずに次に進むと不具合が出るとか？
# 今回わ参照して居ませんが真坂Cx486DXとかCx5x86とかで不具合が出るとか？
|
|
|
