元のスレッドは2024年4月のリサイクル掲示板 システムスレです。
問題はXsでSCSI単体では使えない、という報告。
Windows95で特に顕在する、という話題でした。
そこで手元のXaとXfで調べたところ
PCI-SCSIは正常動作するが
CBUSのSCSIは100ボードですらおかしな動作が見られる。
という状態でした。読み込みはおそらく正常?なのですが
書き込みがおかしく領域ごと破壊まで起こしますから大変です。
でCBUS自体が壊れているのでは?ということでPC34をプロテクトメモリにしてみたところA20ラインがつながっているときしか中身にアクセスできなさそうだ。という報告までやりました。
次です。EMSモードで起動させました。
MELWAREがEMSを見つけて来ません。壁こえSCSI付属のEMStoRAM.COMを実行してみたところC0000-D7FFFにメモリの割り当てができました。A20の有効無効は関係なくできました。
この状態でリセットボタンでリセットするとmelwareが32Mbyteもの巨大EMSを見つけてくるようになります。
ということで何かはおかしい（emm4j.sysでやるべきです。）ですがCBUS自体は動いているような気配を感じます。
で、ついでに壁こえSCSIのある状態で100ボードのASPIを試してみたところ
Xfでは正常化したような気配を感じました(そもそもそのこと自体が信じられない)が、Xaではやはりおおごけしました。
メモリアクセスタイミング?が何かおかしく?CBUSのROMが正常に読み出せない?という可能性はないでしょうか 何で調べたらよいのかわかりませんが
ASPIドライバはメインメモリに常駐していますから問題を引き起こす理由がさっぱりわかりません。
壊れている としてもSCSI以外は正常っぽいところが気持ち悪いですね
|
| すぐできることは まりも 2024年4月2日(火) 14:20 |
修正 |
PCI機ですからXfでは100ボードは動くはずです、aspiも含めて。発売時期も同じ1994年です。いっぽうバスマスタなSCSIボードや92ボードは動かなくて当然と思っています。SMITはDMAに問題なければ動作して当然という気はしますどうでしょうか。
初代Xaだけが特に怪しいということ、不定愁訴的に動作不良を起こすことから、とりあえずメモリも別のにしてみることくらいです。あとはSCSIケーブルでしょうが、アンフェノールミニは使わないようにするくらいでしょうか。100ボードには（変換器挟みますが）使ってはいけないことになっていたような気がします。
|
| XfとXaで再実験 リウ 2024年4月2日(火) 22:53 |
修正 |
Xfでは100ボードは動いているようです。再検証しました。
Windows95がインストール完了できました。DOS用ASPIドライバも動いています。
書き込みで破壊した というのは同時に両機種を触っていたことによる勘違いと思うことにします。(きちんとしたメモを残していない私が悪いです。)
SMITの動作については両機種ともIFC-NNでは電源投入後にROM SUM ERRORが発生してしまい起動不可能です。(SC-98IIもハイレゾ設定をいれておくと同じ現象が起こります。のでもしかするとハイレゾ設定が残っているかも?また見ておきます。)
ハイレゾ設定が存在しないLHA-301では起動可能なのですが、やはり小さなファイル書き込みは可能ですが大きなファイルを書き込むと止まったり領域破壊が起こったりします。
Xfでインストール完了したWindows95のシステムを100ボードのドライバを動作停止状態にしておいてごそっとXaに移しました。
内部メモリとCPUは別ですが同じ100ボード 同じケーブル 同じ外付けHDDです。
ディスクドライバがDOSモードにはなっていますが起動自体はできました。
そしてドライバを有効にして再起動すると領域を破壊されました。
どうしてもダメなようです。うちのXaはがんこです。BIOSでは動作しているとしか思えませんがどうしてもASPIやwin95ドライバではこけます。
このあとメモリを足してNT3.5を入れてみます。また報告にきます。
FreeBSD/pc98 NT3.51
ともにBIOS動作からドライバ動作に切り替わったタイミングで何かを書き込んだら領域のブートセクタ付近を破壊しました。
ヲチスレでコンデンサの話題が出ていましたのでまたそれも見てみます。
|
| オカルトです リウ 2024年4月3日(水) 12:46 |
修正 |
メモリを70nsの8Mから60nsの64MBに変えています。
XaでSMITボードが読み書きとも正常に動き始めました。
FreeBSDのドライバは待ち時間を結構取っているので動くかな？と期待しただけなのですが、調査後にリセットしてDOSから書き込んでもファイル破壊をおこしませんでした。（後から思い出すとこのときは壁越えSCSIを使っています。）
なのでCBUSが壊れている、というものはほぼ除外してよいかと思うのですが、相変わらず100ボードのドライバ動作だけおかしいです。
そういえば100ボードには1030P板と1030B板の二種？あったということを思い出しました。
片方はwin98での動作が保証されていない、という文言をどこかで見たことがあります。関係ありますかね？
ematei.s602.xrea.com/cgi-bin/bbs39_ken/bbs39.cgi?mode=past&year=2018&mon=10
ここでした。
うちの手持ちは二枚で、ともに1030Pでした。
weblabo.griffonworks.net/dorlog/2nddorcom/pc-98/46480.html
PnPで何かを間違えているという可能性ですか… なるほど
|
| 違い発見 リウ 2024年4月3日(水) 19:45 |
修正 |
手持ちには100ボードが2枚ありましたので
一応オカルトですが入れ替えてみました。
なんと入れ替えるとXaでASPIをロードした状態で正常に動作します。
ますますオカルトじみてきました。
とはいえ調べられることは調べたいのでBIOSの中身をダンプしました。
どちらも1.10なver表記ですが中身が違います。
6Xなシリアルナンバー持ちの1080P S1 9070000 D 9633 BIOS A3EE F412
がダメなボードでBIOSの最終バイトはB3hでした。
5Yなシリアルナンバー持ちの1080P S1 9070000 C 9542 BIOS A1F2 F20E
な方はXaでも使えるものでした。こちらは以前からCx13にさしっぱなしにしてあったものです。
とはいえプロテクトモードに入ったあとにBIOSを呼び出すようなことがそんなにあるのか?という疑問は持ちます。ダメな方も少なくともXfではきちんと動作をしてくれましたことを確認したばかりですし。
やはり何か変ですね。
ソケットですからBIOSROMは簡単に入れ替えられる、ahasel98でeepromの中身を見る、ということもまだできることに含まれるのでやります。
|
| AHASEL98さまさまです リウ 2024年4月3日(水) 21:41 |
修正 |
BIOSが原因ではありませんでした。eepromです。
XaでASPIやドライバ動作でHDDの中身を吹き飛ばす方のボードはeepromが読めない状態でした。
Xfに刺すと読めるときもあるのですが、読めないときもあります。(不安定)
そのため公式のドライバは(PCIのときにドライバは解析したので動作は予想付きます)設定をそこからもらってこようとしますが、読んだ値が予想外のものになっているので大暴走している ということで決着できそうです。
おさわがせいたしました。
そろそろSCSIボードのeepromも寿命が来ているかもしれませんね…。
100ボード以外のドライバはeepromを読まずにIOで設定を見ていると思いますが、ドライバでだけこける原因に納得行く結果が得られました。
おさわがせいたしました。おふがおさんにはここでも感謝申し上げます。
1030Bのeepromの中身がもしかするとWindowsのドライバの求める標準的な値とはずれてるのかもしれませんね、などという妄想も湧いています。
じつは報告に焦りすぎて勘違いしている可能性も残っていますが 少し冷静になったらまた考えます。
6日0時更新
上記のことはやはり勘違いだったのですが、一度大々的に報告したのでtwitterでは消していません。本当にeepromが消えた人はいましたのでその例をもって嘘ではないということで…
emulatorを使ったりASPIを使って指定アドレスに書き込みをやってみたりと続行しています。同期転送を疑っていたのですが原因ではありませんでした。ダメな方の板でもASPIで同期設定をした後、リセットでBIOS動作に変えると同期のままになり、そこで書き込みを行っても化けませんでしたし、Windows95の動作で非同期を選んでみても化けました。
Xaでダメな方の板でASPIを使ったときだけ1WORDごとに後半が壊れることが見えました。
その後さらにBIOSとASPIをトレース実行してみました。BIOSではword転送なのですがASPIでは割り込み処理の中でdword転送しているようです。
また1.10Cと1.10Dでの違いは事実上2byteだけです。ver.CではIO指定部分のやり忘れがあったようです。
FreeBSDのドライバでもdword転送をしているのですが、その部分をこれからword転送に変えてみます。これで化けなければこれが原因と言えそうです。
|
EEPROMが原因でしたか。しかも完全にデータが飛ぶのではなくて中途半端に化けるような。うちには10枚近く100ボードがありますがEEPROMが壊れているか一時的に不調になったものがあるかもしれません。以前報告した、リソース設定が言うことを聞かなかったりPCIデバイスとIRQが同じになってしまうやつなんかは怪しい気がします。
100ボードのほかDIPスイッチレスのSCSIボードでもリソースの設定記憶にEEPROMが使われています。EEPROM不良でリソース設定がデフォルト値（というかbitの値が1側）から動かせなくて（対象機が98XAハイレゾに固定される結果）使えない緑電子のSCSIボードがうちにあります。
1030BとPの違いはPnP情報の違いであって、1030BがWindows98で動作しなくなる原因になっていますが、EEPROMではなくてBIOSそのもののPnP部の内容の問題かなと思っています。
|
| 原因はdword転送です リウ 2024年4月6日(土) 17:10 |
修正 |
FreeBSDのドライバ動作を変更してみました。
dword転送に行くルーチンをword転送に変更したものを作成し、
FAT16のディレクトリに二枚の100ボードをXaに入れ替えて挿し、どちらでもFAT16に約10MBのファイルを書き込みました。結論としてファイル及びFATテーブルは化けませんでした。
ソフト的な原因ははっきりしました。ASPIや各32bitOSのドライバがdword転送を（必ず）行うのでうちのXaと100ボード（1.10DのBIOS持ちの方）の組み合わせの時に必ずデータ化けによる領域破壊が発生します。
ですがハード的な問題は何になるのでしょうね？別の板だとなんの問題も起きなく、この板も別機種（Xfでしか試していませんが）に持って行くと正常にdword転送できます。
不思議ですね、相性という言葉は使いたくありませんが
|
| BIOSのバグでわ？ かかっくん 2024年4月6日(土) 22:47 |
修正 |
別の板だと無問題ならdwordの問題でわなさそーな？
1.10Dの板で、ROMを差し替えての動作は如何でせう？其れで正常ならBIOSのバグ確定な気が？
ところで、各板のEEPROMの初期設定イメージデータとお手軽なEEPROMライタが有れば慌てずに済みそーな？
BIOSと違って(C)の問題は無さそーデスし
其れとも新品のEEPROMの内容は真っ新でも無問題dsk?
|
| 100ボードのPnP リウ 2024年4月6日(土) 23:37 |
修正 |
eepromが不正な状態ですとPnP機では起動不可に陥ります。(AHASEL98で雑な値を書きました。それをやると再現できますがやりたくないです。)このときはPnP非対応の初代BXに挿してAHASEL98で有効な設定をすると再度起動可能状態になりました。
1.10CのBIOSと1.10DのBIOSに違いはあります。それは1.10Cの方に一つだけIO指定忘れ(?入れなくともよい場所なのかもしれません)があるわけですが、どちらの板もBIOSでは正常に動いています。物理的に入れ換えなくともIPLwareでDC00hをRAMにしてやれば簡単に入れ替えられます。それでやってみますがこれは多分関係ないと思っています。
ところでBIOSver2.00(AHA-1030B)がdword転送していませんかね、1030Pより少しだけ早いというお話があるわけですが。
原因はほぼdword転送だと確信しちゃっていますが、見忘れ、確認し忘れはすぐやらかしますので何かありましたらぜひご指摘ください。そもそもこの組み合わせのときだけおかしい、というのもおかしいので他機種にも挿しまくってみます。
|
| いずれのバージョンでもBIOSではdword転送なし まりも 2024年4月7日(日) 10:24 |
修正 |
dword転送とは命令語でinsd/outsdを使っているということですよね？ であればどのバージョン（ついに1.00から2.10まで揃いました）のROMコードにもありません。PnP部を除けばそもそも386命令を使っていないので、80286機でも動作可能です。
Dword転送をしているのはaspiドライバaspi2dosのみでしょうけど、Cバスに対しては物理的に16bit転送サイクルが2度発生するだけだと思います。もしかしてそれに失敗する初代XaのCバスブリッジのバグ？ないしは個体の故障でしょうか。CバスブリッジのリビジョンはXa初代とXfで違っていますか？
【17時30分追記】 ttp://www.webtech.co.jp/company/doc/undocumented_mem/pci_pcmc.txt
Undocのチップセットのところには430NXのことが書かれていますが、初代Xaではリビジョンが古いものが混在しており、古いA0のやつは「メモリへのポスティングができない」と書いてあります。これがどういうものかわからないのですが、ホスト→PCI→メモリへの書き込みのときになんか問題があるってことでしょうね。inストリング命令ではメモリに勝手に書き込みが発生しますが、そいういうときに問題になったりしませんかね？気になりました。insdで2度メモリへの書き込みが起こるときに問題起きてないかと。この場合、メモリへの書き込み＝ディスクからの読み込みだけが問題になりそうですが、ディスクに書いた内容もおかしくなっていたのか、書いてから即座に他機種に繋いでの検証が必要そうです。またXaでも個体によっては大丈夫ということになります。
＃ いやこれはもう２台くらい初代Xaを買わなあかんわって
【18時30分追記】あれ？ Intelsatのレジスタ説明とundoc2の記述が微妙に違うところありますね。どっちが正しい？
|
| PCIレジスタにも原因！？ リウ 2024年4月7日(日) 19:43 |
修正 |
まずはBIOSの全バージョン所持おめでとうございます。そして検索ありがとうございます。
Xa固有の原因も見つかりました。
intelsatをやるべきだ、というご指摘ありがとうございます。
CPUのCR0レジスタでキャッシュを切ってもデータ化けが発生しましたが
430NXのレジスタでprimaryキャッシュを切るとASPIの転送が壊れなくなりました。（驚いています。）
この指定はCPUキャッシュを無効にするようです。時間待ちの余裕ができるんですかね?まだひとつも分かりませんが
これからこの状態でwin95を起動してみます。CPUキャッシュなしでwin95は地獄ですが…やります.
21:15結果報告
PCIチップセットレジスタでL1を切ってもOSがまたL1を有効にします。のでWin95のNeptuneドライバを無効にした上でINTELSATでL1を切り、win.comを実行
の順で起動させましたところデータ破壊が起こらずにWindows95が起動しています。(21:25追記 再起動したらデータが全部化けていました。1度の起動はできましたが、データは破壊されました。報告焦りすぎです。)
きちんと動作するほうの板ではこんなことは不要なのですが、ダメな方でも動かせるようにする方法としてこれも正解でした。
まとめると
dwordでのPIO転送がAIC6260の石には能力としては存在する。
DOS用ASPIはそれを強制的に使う。FreeBSDのドライバも事実上強制的に使う。
FreeBSD/pc98のドライバでdword転送をしない設定を作ったところデータ破壊は起こらなくなった。
ここから下の文言削除(21:25)
また430NXのチップセットレジスタでL1キャッシュを無効にすると
DOS用ASPIドライバでのデータ破壊が起こらなくなった。
同様の設定をきちんとやるとWindows95のドライバもデータ破壊を起こさなくできる。
ということです。430NXがかなりあやしくなってきましたが、対処しなくとも動く板の方と何が違うんですかねえ…。
|
| ASPI2DOS.SYSにパッチあて リウ 2024年4月8日(月) 11:42 |
修正 |
PC-9801RA2で100ボードのBIOSは動作するのですがASPIドライバを入れると読み出しすら不可になります。ここでは報告していませんでしたがつぶやきはやっていました。
この機種ではIOのdwordアクセスを分割せずに直接CBUSに送ろうとした動作をしていそうでしたので、ASPIドライバのパッチに取りかかりました。変更が必要そうな箇所はいくつか見つかるのですがここだけの変更でBIOS使用中の場合は通るようです。(BIOS無効扱いの2枚目動作用?などは放置されている可能性があります。)
読み出し側
1DF2: 20->40 mov cl,20->mov cl,40
1E01: F3->90 後ろへ
1E02: 66->F3 prefix 66無効
書き込み側
20AE: 20->40 同上
20BF: F3->90
20C0: 66->F3
この変更でRA2でもASPIドライバが動作しているように見えます。(詳しくはやっていません、とりあえずの動作です。)
そしてXaに持っていったところダメな方の組み合わせでデータ化けが発生せずに書き込めてしまいました。やはりCBUSのdwordIOアクセスに手元のXaはおかしい場面があるようです。winのドライバも変更してやると動きそうな気はしますがそれよりもCBUSブリッジの動作がとてもあやしく思えてきました。
しかしやはり個体特有の問題の気がしますね、最初はXaなんてとんでも機種の大問題かのように思っていましたが。お付き合いありがとうございます。一人でやってると勘違いしまくっていたと思います。
16:50追記
・いくつかの100ボードのうち一つで起こる →手持ちはたったの2枚でそのうちの片方の1枚で(Xaと組み合わせた時に必ず)起こる。
・430NXのリビジョンは関係なさそうで 問題のXaではrev.A1
・ディスクのread/writeともにdword転送でおかしい→ Xaでドライバ動作でのwriteの時だけデータが化けます。読み取りは大丈夫です。
・化けるのはhigh側ワードではなくてhigh（奇数側）バイトだけ
・問題のXaだけでなく9801RAでも起こる→手持ち両方ともASPIで全くの動作不可、BIOSでは両方とも問題なく動作可です。
いろいろわかりにくい書き方をしてしまっていて申し訳ないです。
NT3.51のドライバにもパッチをあてて実験中です。
|
| 人工知能の意見も聞きたい まりも 2024年4月8日(月) 16:05 |
修正 |
・いくつかの100ボードのうち一つで起こる
・430NXのリビジョンは関係なさそうで 問題のXaではrev.A1
・ディスクのread/writeともにdword転送でおかしい
・化けるのはhigh側ワードではなくてhigh（奇数側）バイトだけ
・問題のXaだけでなく9801RAでも起こる
人工知能はこれらの情報を読み取ることができるのか、できた後どう判断するかわかりませんが、普通に考えると、その100ボード固有の問題があるという結論でしょうかね。RAまで動作不良起こすとなるとほかの機種でも起こりそうであり、もっと知られる大問題になっていたはずです。98本体を試すためのなんらかのテスターになるかもしれないので、当該100ボードはある意味貴重品かもしれません。
そう言えば一つ疑問ですが、80286機でCPUを486に載せ替えた場合、dwordのIN/OUTストリング命令はちゃんと動作するのでしょうか？命令セットとしては通りますが、実際にwordでやり取りするI/OポートにワードI/O転送サイクルが2回発生しているのかどうか？そこはCPUがやらないといけないですが、CPUアクセラレータ用の486はちゃんとハードウェアでやっているのですかね。まあワード幅のI/Oができるデバイス自体があまりなかったりしますが。サードパーティ製のSASI/SCSIと、内蔵デバイスではEGCくらい？ しかしEGCの同じレジスタに連続outsd命令を食わすシチュエーションってあり得ないですよね？
それから、ワード転送できるものはI/Oアドレスが奇数にはならない気がします。EGCもSASI、IDE、SCSIいずれも偶数アドレス配置ですね。IDEのデータレジスタはI/Oアドレスが0640hで、dword転送できる場合はアドレスが4の倍数であることも制約条件でしょうか？
|
| 286→486機の場合 かかっくん 2024年4月8日(月) 17:33 |
修正 |
286→486機の場合、元からバスが16bitの486SLC系は無問題の筈デス。問題は486DLC系・486BLの場合デス
が、アクセラに依りけりとわ念い枡が対応して居なかったらずっと前から問題に成っていた筈でせう
> それから、ワード転送できるものはI/Oアドレスが奇数にはならない気がします。EGCもSASI、IDE、SCSIいずれも偶数アドレス配置ですね。IDEのデータレジスタはI/Oアドレスが0640hで、dword転送できる場合はアドレスが4の倍数であることも制約条件でしょうか？
然うデス。奇数アドレスへのword転送は2ヶのbyte転送に分解され枡。8088/188/V20/V40系では凡ての
外部との転送がbyte転送として処理され枡
# 余談としてMC68000ではアドレスエラーのトラップ(86系での例外、旧苹果OSでわ爆弾)に成増
4の倍数でない偶数アドレスでのdword転送はword転送x2に、奇数アドレスでわbyte word byteに成るか
byte x4に成るか何方でせう？
|
| CBUSの4byte転送 リウ 2024年4月8日(月) 17:37 |
修正 |
NT3.51のドライバにもパッチをあて(つぶやきには場所を書いています、省略)インストール完了できました。もともとのドライバだと破壊されていましたから意味のあるパッチではあるようです。
問題はこのCBUS相手の4byte転送だと思います。
RAでは例えばIO188h(FM音源に使われるもの)にbyte読み出しすると正常に読め
word読み出しすると 188hと189h(?これは謎)の内容が読めているように見えます。
しかしdword読み出しをすると常に不正な値が出てきます。
そのため100ボードのASPIドライバもdwordでのIO読み書きのせいできちんと動作できないのだと思えます。
これがXaでは
dwordで読むと188hｰ18Bhの値が連続で読めているように見えます。
IDEのデータポート640hに対してはbyte転送とword転送とdword転送でどうなってるのか?word読み出しで640hと641hを使っているとは思いません。データポートはword用でしか開いていないと思っています。一部機種では可能になっているdword転送の時も642hや643hに分けずにそのまま渡していると思っています。(642hはデータポートではありませんので、640hに二回で渡してるかもですね)
100ボードのデータポートは186Ch(word)もしくは1870h(dword)です。
が100ボードは偶数アドレスにしかIOは出ていませんのでwordアクセスが奇数アドレスに出ているかはわかりません。
本体側でCBUSにdword転送できそうならそのまま渡す、できないと判別したらwordに分割する、それでもできなければbyteに分割する。をやっているとおもうのです。件の100ボードの場合だけdword転送できるはずなのにできないと思い込まれて分割され(妄想)highbyte側が彼方へふっとんでいる。こういう状態だと思うのです。なぜできないと判断されてしまうか、の部分が組み合わせでぶっ壊れていると思います。(妄想注意)
GPIOでdword転送しているものを探しますかねえ…。そういえばビデオキャプチャボードは持っていました、がこれもDMAなしでビデオメモリへの転送してますかね、PCMはステレオですら2byteですから4byte転送はしないと思います。確かめる方法には何がありそうですかね…。
|
| RA当時って かかっくん 2024年4月8日(月) 18:09 |
修正 |
> 本体側でCBUSにdword転送できそうならそのまま渡す、できないと判別したらwordに分割する、それでもできなければbyteに分割する。をやっているとおもうのです。件の100ボードの場合だけdword転送できるはずなのにできないと思い込まれて分割され(妄想)highbyte側が彼方へふっとんでいる。こういう状態だと思うのです。なぜできないと判断されてしまうか、の部分が組み合わせでぶっ壊れていると思います。(妄想注意)
RA当時は此んなにスマートな(賢い)仕組みでわなかったと憶うんデスけどねぇ
抑々I/Oの拡張手段がCバスしか無かったRA当時はdword I/Oは御法度だった気が？
dword I/Oが解禁されたのはネイティブで32bit I/Oの拡張(NESA)に対応したH98以降な気がし枡
# 逆にNESA以降の32bitバスはdword I/Oでないと性能が出ない
RA当時は8bitな石だらけの98でword I/Oすら余りしようとは考え難いデスし、同じ石に再度アクセスするには
I/Oリカバリタイムの考慮が必要デスがbyte/word I/Oの際もプログラムで時間待ちせぇと云う時代デスから
ハードウェアで為されて居たとわ憶えませんし
ところで、メモリ空間に対してはCバス宛にmov r32,[mem32]とかrep movsdとかでも正常に動くん
デスよねぇ？
性能をMMIOに求めたSMITの考えは正しかったのでわ？
> GPIOでdword転送しているものを探しますかねえ…。そういえばビデオキャプチャボードは持っていました、がこれもDMAなしでビデオメモリへの転送してますかね、PCMはステレオですら2byteですから4byte転送はしないと思います。確かめる方法には何がありそうですかね…。
LPCM音声は16bitステレオなら1サンプルは32bitに成増
まりもさんやおふがおさんがお持ちのP(I)O板にdword outしてみて結果が想定通りかで判る気が？
P(I)O板と高速ロジアナが有ればdword outする元データとロジアナが拾ったデータとの比較で判りそーな？
|
| PO-32 まりも 2024年4月8日(月) 19:44 |
修正 |
  メモリのサイクルとI/Oのサイクルは別のものです。メモリではdword転送はRAの頃でも可能だしRSのような386SX機でも可能です。68000と違って境界がずれていても遅くなるだけで不可能ではないです。
I/Oのほうは、OUTSDではCPUないしはCバスブリッジが勝手に2回word転送するものと思っており、深く考えたことはありませんでした。
PIO板のうちPO-32ではベースアドレスは4の倍数のみ指定可能で、バイトI/Oポートが連続で4個並んでいるような感じでも使えますし、word、dwordでOUTすると、ベース＋1、＋2、＋3それぞれのアドレスのところに上位のバイト分のデータが出ます。なんの捻りもないです。9821Xsで調べてみました。RAもXaもないのですがRLでも試してみます。【追記】RLでも同様でdwordのOUTはできました。これはPIO-32ボードが連続アドレスに8bitずつ送れるように設計されているから見えるのであって、word幅のデータしか受け取れないボードでは最初の16bitのデータを引き抜くように作られていないと、動作しているかどうか外部からはわからないでしょうね。
|
| PO板のリードバック かかっくん 2024年4月8日(月) 20:17 |
修正 |
 昆TECのPO板は(IORを元に戻せば)レジスタのリードバックが出来た気がし枡。
word outしたデータをdword inして同じかド〜かでも判りそーな？
PIO板は入力に成増から外部にレジスタを設ける必要が有馬す
|
| BIOSやらドライバなどなしに直接PIOアクセス リウ 2024年4月8日(月) 21:50 |
修正 |
AIC6360石と直接対話してみました。もちろん問題が起きているXaです。
データシートを見たところ内部FIFOへのやりとり方法がありましたのでそのとおりにやってみました。
io 1864h bit7が転送モードONでbit4がdwordOKモード、bit3が方向bitです。
98hにしておいても1870hからFIFOの中身は読み出せません。
その状態で1870hに32BIT書き込みました。
そしてbit3を落として読み出しモードにして読み出しました。
通常に使えている板の方では書いた値がそのまま読めましたが、やはりダメな方では化けてしまっていました。(いやそもそもバイトオーダー順序も狂ってませんかねこれ
22:45追記
左が正常動作板で右が化ける板です。
左のバイトオーダーが狂っているように見えるのは186Chで1WORD先読みしたせいです。)
まともに状況は確認できてしまいましたがこうなると板が壊れている、というのが一番ありえる話なんですかね?他の機種に持っていくとなんともないのが不思議なのですけれども
追記22:25
ということでXb10に両方を挿して追実験しました。古めのものということでBXでも確かめました。
以下(妄想を含む)考察
AIC6360石はdwordなIOアクセスを受け付ける。
手元のXaとD板の組み合わせではそれが超不安定、dwordでそのまま送ろうとするとhighbyte側が化ける。(22:45 妄想は間違いと判明したため以下削除)
9日9:53
RA2での動作画像追加
この機種では32bitIO操作（CBUS->CPU）では上位2byteが2回繰り替えされるみたいです。CPU->CBUSの値は正しいようです。書いた後にword読み出しで二回読むとFIFOの中身が読め、32bit書き込んだものが見えました。
|
   |
|
