98システム解析スレッド2024年1月 /人'A`;人\ 2024年1月1日(月) 4:10 |
全面を同色にしてチェック? かかっくん 2024年1月1日(月) 23:05 |
>>EXTENDED GRAPHIC VIDEO RAMのチェック > なんでもいいから256色640*480ドットのモードに切り替えるプログラム(automate -wとか)を実行し、描画がおかしいところを目視すればいいような気がします。ただしGVRAMの物理アドレス位置、CPUから見たアドレス位置、ドット座標位置の関係はよくわかりません。プレインモードとpackedピクセルモードでも違いますから、画面の中ほどに異常があるからといってアドレス的にも中程とは言い切れません。うちのソフトだとgrad256というのがあります。packedピクセルで描いています。
あーApデスから480ライン256色が有るんでしたね 256色packedピクセルなら1ドット=1バイトに成増から位置の特定は容易そうデスが、全面を同一カラーコード (0とFFh)にしてチェックとか?
|
GVRAMチェッカ リウ 2024年1月1日(月) 23:33 |
報告忘れてました。 作って公開だけはやってます。 drive.google.com/file/d/1trG90DYQE9_SCk0-qgPjFJ81Bs1qB7gc/view ゴーストメモリ的なものが見えないようにしましたがどうでしょうかねえ…
情報の公開元には感謝です。 [8日追記] 動作報告の話題が出ましたので これに関しては故障した人には直接ポストしていません。その人が実際に試すことを期待はしますが、自信を持って故障原因を示すことができないからです。 お住まいがどこかもわかりません、もし被災地の方でしたら、あれこれ指示してしまったら大変です。そのため大晦日時点では公開をし(元日に訂正もやり)ましたがその後は放置気味です。
|
素朴な疑問 まりも 2024年1月3日(水) 0:59 |
80286機にi486相当アクセラレータを載せるのがいまだに流行っているようですが、15-16MBシステム空間と同じものがFFF00000hのアドレスに現れるのでしょうか?CPU周辺回路(本体側)にはそれが可能な仕組みはないはずです。アクセラレータのCPU上でアドレスをシフトないしマスクさせる仕組みがあるのやら?知りたくなりましたが286アップグレードの486アクセラレータはお高くて、、、 調べるにはGetITF98 V3.10 をあえて/4 オプションなしで実行し、得られたデータが全部FFhや00hで埋まっているかどうかで判定可能かと思います。
>GVRAM3 GVRAM素子の貼り替えやパターン修復を試みる人向けに、256色の場合00F00000hからのオフセットと、異常があったビットパターンも表示するとよいかも。こんな感じです。 ttp://hp.vector.co.jp/authors/VA012947/util/memtst03.html 画面いっぱいまでの列挙もあった方がいいです。不良のアドレスが連続(または周期的)で出ていればデータ線パターン切れと判断できます。
【追記】まあこれは表示ONで00フィルFFフィルしたときに画面に縦縞が現れる(残る)ことで誰でも気がつくであろうからプログラム的には不要でいいでしょう。メモリ素子異常の場合は1箇所でもあれば貼り替えですから、複数調べなくてもいいですよね。面倒臭いこと言って済みません。
|
Re:GetITF98 V3.10 をあえて/4 オプションなしで実行 KAZZEZ 2024年1月3日(水) 12:27 |
IBM486SLC2なVXもどきで試したところ、以前と同じように8バンクすべて同じ特定のバンクのデータが読み出せているようです。 なお/4付きでは286時と同じようにbank4-7で異なるデータが読み出せております。
> 不良のアドレスが連続(または周期的)で出ていればデータ線パターン切れと判断できます。 周期的に出るとすればデータ線というかアドレス線のパターン切れでしょうか? メモリチェックのたぐいでは、単純に書き込んだデータと同じデータを読み出せるかどうかを調べ続けるだけだとアドレスビットの不良のよる周期的パターンが不良として検出できないことがありますよね。まだ書き込んでいないはずのアドレスから、別のアドレスに書き込んでいたデータが読み出せるか否かなど、アルゴリズムに工夫が要りそうです。
|
正月からお化けの話 まりも 2024年1月3日(水) 17:59 |
そうするとアクセラレータではきちんと16MB直下の空間を4GB直下に投影しているということですね。安心して普通にi486機として使うことができます。ただしどこでどうやってそれを実現しているかです。上位のCPUアドレスを全部highに釣るようなやり方だと、16MBサイクルで、システム空間でなくメモリ空間まで同じものが見えることになります。流石にそこまで手抜きはない?というかアクセラレータ用のCPUってピンにA24以上のアドレス線は出ていないですよね?ピン数少なめですし。CPU内での回路でしょうね。
>周期的に出るとすればデータ線というかアドレス線のパターン切れでしょうか? 基本的には連続としています。周期といっても2、4バイト単位の短いものです。これは一度のチェック単位が{バイト、ワード、ダブルワード}とあり得るので念のためカッコづけで書いています。データのどこかのビットが落ちていると必ず全部の{バイト、ワード、ダブルワード}単位で読み書き不一致となります。
アドレス線の化けは基本的に調査困難です。上位の線が切れたらもうどこだかわからないくらい遠くに行ってしまいます。ただしVRAMということからするとアドレスの範囲は限定され、間違ってメインメモリのデータを破壊するようなことはないはずです。アルゴリズムは、うーん難しいですね。取り外し可能で電気保持可能なメモリ(普通そんなのはない)なら、正常な装置に繋いで特徴あるパターンをまず書き込み、問題ある装置で読み出すというようなことでわかりますけど。PCIのSCSIアダプタでのディスクのデータ化けがPCIのAD線のアドレス化けにあることを、それで見つけたことがあります。
|
486SLCだから鴨? かかっくん 2024年1月3日(水) 22:06 |
此れは元からメモリ空間が16MiB分だけの486SLCだからもあるのでわ? 4095M〜4096Mだけ特別に15M〜16Mと同じ範囲を参照するとか? 4GiBフルに有る486DLCや486BLでは亦違った結果に成りそーな? # 286→486DLC/486BLアクセラに有る石の幾つかは此の制御鴨
ところで前から疑問デスが386DX/i486+/486DLC系は仮想アドレスの合計が64TiBに成って居枡が 386SX/486SLCはド〜なんでせう?64TiBが4GiBx16384だから16MiBx16384の256GiBに成るのか、 其れとも4GiBは実メモリ空間でなくポインタの空間だから矢っ張り64TiBナノか?何方でせう? # 286の仮想空間は1GiB
取り外し可能でデータ保持(電気保持?)可能なメモリと云えば(E)EPROM・FlashとかFeRAM辺りdsk 何れも主記憶としては実用的でないデスが
オープンソースなMemtest86+のソースコードを讀んでみるとか?
|
386DXとpin互換の486相当CPUを載せた286用アクセラレータ まりも 2024年1月4日(木) 16:46 |
「386DXとpin互換の486相当CPUを載せた286用アクセラレータ」 と書いて自然言語処理システムがちゃんと理解できるか怪しいですが、とにかくそういうやつですよね。これは外部回路での処理(または正しく処理しない)の可能性ありますね。というわけで続報お待ち申し上げます。
あと上で追記しておきましたが、GVRAMの場合見ればわかる利点があるので、エラー箇所を枚挙しなくていいです。修理目的からすると、色々な98でのGVRAM構成の情報を上げることが有用ではないかと思います。何機種で何bit幅何Kの素子が何個という程度でも十分です。それにしても初代Apで16色9801グラフィックと256色9821グラフィックとで使用場所が完全に排他?というのは気が付いていませんでした。これなどもまずはVRAM素子の構成を調べないと裏付けも取れませんから、Aeをベッドの下から出してきました。
【5日追記】まず重要なところから。 (1) Aeのマザーボードを観察したところ、16色モード用に64K*4bitのD42264V-10が8個(画像)、これらの合計は256KBです。256色モード用に128K*8bitのHM538123-7が4個、これらの合計は512KBです。やはり別々です。初代A-mateの豪華さと高性能さ(256色用はメインメモリより高速版)がわかります。 (2) 256色VRAMと16色VRAMが別々なのは初代A-mateくらいで、他の9821では共用です。16色VRAMにデータ入れたまま256色に移行し何か描画してまた16色に戻っても、データは残っていません。切り替わり時には元のデータが再配置されたパターンが表示されます。 (3) Undoc2に書かれたようなI/Oポート6Aの操作だけできちんと256色packed pixelモードに移れる/戻れるのも初代A-mateだけです。他の9821ではそう簡単でありません。間違いのない移行にはdisplay BIOS int 18hの機能を使うべきです。 (4) A-mate以外の9821では16色256色モードともグラフィック座標先頭は00F00000hです。前半部が共用です。16色4プレーンのデータを256色モードで一気にリニアアドレスに書き込んでから16色モードにして表示、ということも可能かも。脳内EGCの構築が必要ですが。
※ 初代A-mateの256色モード用VRAM HM538123の存在位置はサウンド回路の近くなのですよね。子基板の下で、ケミコン液漏れのありがちな場所です。8bit構成*4ですから32bitでチェックしたデータのビット位置で特定できます。以上の情報と共にパターンチェック頑張ってください、とお伝えください。
|
Re:386DXとpin互換の486相当CPUを載せた286用アクセラレータ KAZZEZ 2024年1月5日(金) 1:39 |
メルコとアイオーの写真のような製品(映り悪いですが)を試しましたが、同じでした。/4のときのbank4と思しきデータが読めるようです。やはりCPUが要求するアドレスに対して上位アドレス線が無いわけですから読めるメモリは24bitかそれ以下でループするしかないように思えます。 ところで286機+CPUアクセラレータの環境では基本的にi386と判定されるようですが、キャッシュを有効にすると486相当に認識される場合があるなと思ったら、メモリのワーキングエリアのCPU情報を見てi386と486相当を判別していたのですね。手元のPK486D.COMは恐らく386用アクセラレータの付属品だったのかワーキングエリアを変更しないタイプでしたので、(別途対策ツールを使わない限り)そのままでは286機でDOS6.2/Win3.1のインストールには使えないことになりそうです。286用アクセラレータ付属のPK486SQのほうは大丈夫でした。
> アドレス線の化け 仮にアドレスが1ビットだけ化けている前提であれば、書き込んだアドレス±(2のべき乗)のどこかを読めば同じデータが返ってくるでしょうから、そこだけチェックをすれば良さそうな気はします。複数のビットが化けていたとしてもメモリアドレスを変えていくうちにたまたま1bitだけ問題になる個所も出るでしょうから検出できるかもしれませんし。もちろんハード的に連続したメモリであればの話ですが…。
|
IPLwareとROM空間のRAMイヒと似非BIOS かかっくん 2024年1月9日(火) 1:02 |
MMCのDRV再び(?)と云った処で、DRVではDOSでしか遣えませんからBIOSイヒして他のOSデモ遣える哉?と。
でもメニューやIPLwareを起動する際にはもうワークエリアの設定は済んで居て其の後での BIOSでの初期化は手遅れの肝? 若し間に合うならIPLwareでROM空間をRAMイヒしてBIOS擬き(DA/UAは未使用のを遣っても?)を 載せて、DRVでなくBIOS擬きでイケる哉?と。
如何でせう?
ところで此のDRVって窓9xのGUIでDOS互換モードとして動き枡かねぇ?
|
あまり意味ないかも まりも 2024年1月12日(金) 12:30 |
I/O待ちが長かったり割り込み禁止が長かったりのデバイスだと、Windows9xのDOS互換ドライブとして安定的に動作するかどうかわからんところがありますよね。そこはデバドラ形式でもDA/UA付きドライブでも同じかと思います。DOSブート可能にできること以外にDA/UA付きドライブにするメリットはないでしょう。
ところでCOM形式プログラムでは64KBのメモリブロックだけでなく、DOSがロードしたときには640KB以内のメモリを全て確保してしまいます。したがってDOSファンクション48hでいきなりメモリ確保をしようとしても必ずエラーとなります。作法的には悪いですが、高目の物理セグメント番地(CS+1001hより高位)を勝手に使う方が手軽には違いありません。もちろん正しい作法は、ファンクション4AhでBX指定セグメント以降を全部解放し、48hで確保し直すことです。BXの指す場所は通常はスタック(SS=CSの場合)より上とします。COM形式を変換して得たEXEプログラムでもこの点は同じです。
|
プロテクトモードとデバッガ まりも 2024年1月14日(日) 21:56 |
ddebですがプロテクトモードがらみのコードは実行はできてもデバッグできない感じですよね。unrealモードのコードもブレークポイントで止めるとセグメントセレクタのキャッシュが飛んでしまいます。GS =0008hなどとやっているといつのまにかリアルモードの意味になっていて、割り込みベクタを壊していたりします。
そのほか、unrealモードのときのリニアアドレス表記に[32bitレジスタ+変位]や[32bit即値]を使えないようです。意図したところと違うところを指している感じです。これもデバッガが使えないので実際どこを指しているのかわかりません。しかしこれは本質的にデバッガの問題ではないように思います。アセンブラの作り出すコードの問題なのか、そもそもunrealモードで許されないアドレッシングなのかわかりませんが。
|
DOS用のデバッガはリアルモードで動く かかっくん 2024年1月14日(日) 22:13 |
普通DOS用のデバッガはリアルモードかV86で動き枡からプロテクトモードのデバッグは出来ないでせう プロテクトモードのデバッグはDOSエクステンダ使用の物かWin32上で動く物が必要そーデス
窓用のデバッガ(OllyDbgとか)がVM上の窓3.1+Win32sか窓95(敢えて9xでなく)で動けばプログラム自体の デバッグは出来なくても似たルーチンのデバッグは出来る鴨?
ところでCOMをロードした際に喰われるのは640Kの遺り全部でわなくCOMがロードされたMCBの全域デスね フリーエリアが不連続なら未使用部が遺り枡 云い方を変えれば喰ったMCB内は好き勝手遣っても良い、但しサイズは64KiB分しか保障されないと云う事デスな AH=4Ah int21hでサイズを縮めてから改めて確保するより必要量に直接変える方が新たにヘッダが造られず 節約に成増 尤も新たに確保する領域を常駐させるなら別のヘッダが要り枡が 主記憶に常駐させてからUMBに移してINTテーブルを変えるとか?
|
旧い機種のGVRAM,表示しながら読むと化ける? まりも 2024年1月15日(月) 21:49 |
>AH=4Ah int21hでサイズを縮めてから改めて確保するより必要量に直接変える方が それだとそこのデータ領域の物理アドレスが、CS:XXXXのどこかになるのですが、64KBのバッファを確保したいとときなどは segment:0000 にしたいので、あまりやらないですね。例えばそこが1234:3210h だったとき、12340h+3210h=15550h --> 1555:0000h のような正規化をすればいいのですが、16の倍数境界の制約もあるし、面倒じゃないですか。どっちみち16バイト未満の端数が出てしまうので、MCBぶんの16バイトをけちってもしょうがないと思っています。function 48hだとセグメントだけを返すので、頭使わずに0000hから使えます。
DMAの物理64KB境界をまたがないディスクR/Wバッファの割り付けのときは とりあえず128KB確保して、X000:0000になるような位置を返すなんてことをやってます。無駄が出ますがしょうがないです。これに関してもっとうまい方法ってありますかね?
ところで98RLのグラフィックメモリのテストをしていたところ、エラーがボロボロ出てきました。しかし描画は正しくなされているので書き込みは正常です。読み出しのときにときどき化けるようです。表示したままでのG-VRAM読み出しって何か制約ってありましたっけ?少なくとも32bitで一気に読み出してはいけないような感じです。Rシリーズ時代の9801では、32bit CPU機でもG-VRAMは16bit接続なのでしょうね。なおRLでもハイレゾモードではそのようなことが起きません。
|
UHCI専用USBメモリドライバ リウ 2024年1月17日(水) 0:19 |
ttps://drive.google.com/file/d/1yCGhRF5eQAM_aS-jsxofkzIy0YHdJLVm/view 一応ひとさまに見せられる状態?にはなりました。 でかいファイルでこけます。全然ダメです。 超アルファ版になります。GVRAMか仮想86のEMSを使います。
|
自前で計算 かかっくん 2024年1月21日(日) 1:40 |
COMの場合は****:0〜:FFFFhの64KiB(以上の空きMCB)が確保されSPが:FFFEhに成増から此の範囲の 何処かに@000:0が有馬す。 1234:100hにロードした場合、フリー(?)エリアの直上の64K境界はサイズに依り2000:0か3000:0に成増。 残念な事にCOMをロードしてもファイルサイズはレジスタにもPSP(CS:0〜)にも無いので自前で計算する必要が 有馬す。予めサイズをファイル内に保存しておけば計算が楽デス
↓は実行時のPSPとレジスタの一部の内容を標準出力に出す物デス 0100 mov CS:[0FFC0h],AX 0104 mov CS:[0FFC2h],BX 0109 mov CS:[0FFC4h],CX 010E mov CS:[0FFC6h],DX 0113 mov CS:[0FFC8h],SP 0118 mov CS:[0FFCAh],BP 011D mov CS:[0FFCCh],SI 0122 mov CS:[0FFCEh],DI 0127 mov CS:[0FFD0h],CS 012C mov CS:[0FFD2h],DS 0131 mov CS:[0FFD4h],ES 0136 mov CS:[0FFD6h],SS 013B mov AX,CS 013D mov DS,AX 013F mov AX,4000h 0142 mov BX,1 0145 xor DX,DX 0147 mov CX,100h 014A int 21h 014C mov AX,4000h 014F mov BX,1 0152 mov DX,0FFC0h 0155 mov CX,18h 0158 int 21h 015A mov AX,4C00h 015D int 21h
FFC0: 00 00 00 00 FF 00 DF 10-FE FF 30 09 00 01 FE FF FFD0: DF 10 DF 10 DF 10 DF 10
此のレイでわ10DF:100hにロードされて居枡。DX:SIが実行時点のCS:IP、DIがSPのやうデスね 因みにEXEイヒしたCOMならヘッダにヘッダ込のサイズが有馬す # SSが違っても此処には無いので必要に応じて保存すべし
|
|
|