98システム解析スレッド2022年4月-1 /人'A`;人\ 2022年4月1日(金) 5:29 |
ジョークじゃなくてすみません まりも 2022年4月1日(金) 21:34 |
98のITF ROMの内容をIntelのNIC上のフラッシュまたは未フォーマットのIDEディスクに保存するFDloaderアプリは、見通しが立ちました。NICフラッシュ保存版を作りかけていたところにIDEの話が出たので、どちらでも対象にできるようにしました。技術的には今まで自分が作ったものの寄せ集めです。
HDDの「どこに書くか」の検討だけが思案のしどころです。未フォーマットならどこでもいいので簡単ですが、使用中のをうっかり繋いでも内容をなるべく壊さずに記録したいところです。FDloader中ではBIOSのCHSは不明なのですが、だからといって容量から決め打ち判断するのは、EXIDEやLBA_IDEを使う人のことを考えると、かえってマズいのですよね。最大セクタ番号から遡って記録するのがいいですかねぇ。うまくすればシリンダ端数内の未使用部分になりますから。
まあ今日公開するとジョークソフトっぽいので、明日あたりに。
あとこれを作っていて思いついたのですが、FDloader段階ではIDEのHDD容量が壁を超えていても起動できるので、ICCと同等の容量変更(縮小)ツールをFDloaderにすると便利そうです。半永久に変更するのではなくて、電源が入っている間だけ有効(ノンパーマネント)の書き換えとするのもありかと思います。FD loaderアプリのFDを突っ込んで変更してからアプリが再起動かければいいので。かつて存在したメルコのADVANCED BIOS導入よりもわかりやすい仕組みにできます。
というように、まだまだ利用価値の見つかるFDloaderですので、開発する人向けに「FDloaderメディア簡単作成ツール」なども用意したいと思います。DOS上で開発したCOM形式のモジュールを読み込んでいきなりFDloaderのFDを作成してしまうモノになります。その点IPLwareっぽいですが、実際アプリを作るとなるとDOSもBIOSコールもシステム共通域参照も一切不可という厳しい制約のあるものになります。システム共通域で唯一の情報である「FDloader実行中フラグ 0000:0455h」しか参照できませんが、このフラグで実行環境を切り替えるように考慮すれば、大概のものはDOS上で(DOSとFDloader兼用で)開発できます。
そうなるとIPLDOSのFDloader版のようなモノはできないの?と思うかもしれません。有ればそこそこ便利です。IPLwareでは複数アプリを次々ロード実行できましたが、FDloaderではそれができないので難しいところです。CバスボードのROMはFDloaderでも読めるので、IPLDOSのようなモノのROM版を作ってAPI仕様を決めておけば、近いことは実現できそうです。
|
HDDがLBA対応なら常用がCHSでもLBA可 かかっくん 2022年4月2日(土) 1:38 |
HDDに記録する位置ですが、先月末の
> 或いは、FDloader用のFD(かイメージ)を作る際に、HDDにクラスタが連続する32K〜512Kの仮ファイル > (内容は0フィルではなく'getitf98'や'(C)まりも'等ROMの内容に有り得ない物が望ましい)を作って、其の位置を > CHSで求めてFDに書き込んでおくとか? > HDDにはファイルとして確保した位置に上書きされますから其の儘ファイルとして遣えます
のやうに、インストーラでFDに書き込む際にHDD(/SSD/CF他)に連続領域を確保して其のCHSかLBAをFDに 書き込むとか? 他のHDDに書き込むと内容が飛びますが、HDDの型番とサイズ位はチェックしますか? # I/Oで直接ですから、HDDがLBAに対応すれば常用時がCHSでもLBAでアクセスできます
|
領域なしHDDでお願いする方向 まりも 2022年4月2日(土) 8:49 |
CHSはH境界またぐと煩わしいのでLBAアクセス限定です。忌々しいミイソIDE BIOSを使わず直にデバイス制御するのに、わざわざCHSっていうのは御免被ります。たぶんデスクトップ98では、LBAが使えないのはコナーとミイソ純正の340MB以下のHDDだけだろうと思います。D3765,3766あたりのです。もうほぼ動かない物になっているでしょう。一応LBA対応かのチェックくらいは入れておきます。最近の中華SSDあるいはSDのCF変換に至っては、CHSはまともに使えないのが普通です。
予めダミーファイルを作っておくという方式は一理(一利?)ありますが、ディスク絶対番地のどこに作られるかはわからず、そのパターンを検索することになります。基本的に全セクタ検索となり時間かかり過ぎてよくありません。ROM化けっぽい機体がこのアプリの対象なのですから、長時間動作させてもいられません。ということで、未フォーマットまたは領域が一個もない状態かをチェックして、それなら直にセクタ番号72あたりから書き込むという方式で行きたいと思います。先頭領域のシリンダ番号が十分に大きいことを条件にするという甘々な仕様にする手もあります(がやめておきます)。
|
|
直にファイルで取り出せるメリット かかっくん 2022年4月2日(土) 16:40 |
全セクタ検索が要るか?と云うと然うでもない気がします。FD作成時点はDOSが稼働して居ますから、IDEストレージに 保存したファイルの位置は簡単に解ります。此れをLBA値に変換してFDに保存するだけです。健全な機種で最大 1024セクタ位なら何の問題も無く実行できそうです。 # インストーラをDOS汎用で作っておいて、イザと成ったらPCや仮想環境でもFDを作れると良さそうな? # IDEストレージにLBAでアクセスするならCHS変換の際の齟齬等は無いので他機種でも出来そうな気がします # 2HD/8がネック?此のツールをPCでセットアップしようと云うユーザなら3.5インチの回転数は手動で切り替え # 出来るでせう。5インチなら何の問題も無し
|
DOSの約束事から逃れたい/バッファローのCF まりも 2022年4月2日(土) 19:49 |
ダミーファイル作成と同時に、FDloaderを構築する予定のフロッピーに、ダミーファイルの位置情報を入れておくわけですか。まあFATファイルシステムからLBA番地を知るのは、ファイル先頭のDOS論理セクタ番号にパーティションのhiddenセクタ数を足すだけですから、そんなに大変というわけでもないですが、あまりやりたくはないかな? それよりも確実に連続クラスタでファイルを作ることや、それを調べることの方が難しそうです。FATチェインを追わないといけないですよね。これはアセンブリ100%のプログラムでは正直面倒です。DOSファイルシステムは触りたくないかな…
<3日15時追記> やっぱり[MMDUMP]の応用がいちばん簡単で使う資源も少ないですよね。ということでメインはこれで行きたいと思います(画像)。領域なしHDDがあればそこに書き込み、NICが装着されていればそこのflashを使うという凝った物になってしまいました。しかし3種盛りにした結果、アセンブリプログラムなのに肥大化して16KBを超えてしまうし、なによりも説明書を書くのが大変になってしまいました(汗、、、NIC Flashの説明はもう省きたいです(汗
先月末に出ていた「MMDUMP」とはなんぞや?という方もいると思うので、「デバッグポート出力」の話とともにノウハウを書いておいたところです。これも紹介しておきます。 ttp://hp.vector.co.jp/authors/VA012947/knowhow/mmdump.html
ところでです。バッファローの一見使えるけど危ないRCFシリーズのCFについてです。これって変なCFリセットを起こすのですね。上の書き込みの通りLBA対応かどうかをチェックしていたところ、リセット発動後にはLBA対応の指標(identify情報のワード60のLBA数)が消えることに気がつきました。なのにinitialize device parameter コマンドが設定したHSパラメータの方は飛ばなくて保持されていました。他のCFと違う特徴だと思います。LBA対応フラグが消えてもミイソBIOS経由では完全にCHSアクセスのため問題が見えないのです。「リセットを起こしにくいCF」と思われていましたが、むしろこのバッファローのは容易にCFリセット(というか正常でない状態になる現象)を起こすメディアだということになります。
|
GREENHOUSEのCFも似たようなものです リウ 2022年4月2日(土) 21:04 |
ここでは詳細を報告してこなかったかもしれませんが ATAリセット後にCHSパラメータが飛んでいるにも関わらず(!?)、CHSでアクセスするとパラメータが飛んでいない設定でのセクタにアクセスできてしまいます。 ですのでノート機で(SCSIとは同時使用しないしスレーブも使わない)場合に限るとここの製品はCFリセットが起こらないという意味だけでは正常に使えるわけですが identify情報が狂ったまま動作するのはまたとても気持ち悪いと感じています。
3日9時追記 DOS6が大容量HDDで起動が遅くなる現象について tweetはしましたがここでは宣伝しなかったので 98パーティション情報の方でした。終了シリンダ番号というフォーマッタしか見てなさそうな部分が原因です。(開始位置の方はしらべていません。)真実40MBのパーティションの終了位置をFFFFにしてやると起動があきらかに遅れました。ここの位置を参照してパーティションサイズを計算してマウントするOSにはfreebsd/pc98があります。DOS6は結局FAT16のBPB情報を優先させるようで嘘を書いても容量誤認しません。よって起動を早くするには終了位置を開始シリンダ1にしてやるだけでよくなります。当然ながら嘘値なのでどこかで不具合を起こす可能性はあります。
|
C値の末尾が嘘値で困るのは かかっくん 2022年4月3日(日) 23:56 |
C値の末尾が嘘値の場合、DOS自体はあまり問題無さそうですが(HD)FORMAT.EXEを始めフォーマッタの大部分で 不具合を起こします。具体的にはみいそDOSの(HD)FORMAT.EXEでは『領域が不正』と成り当該デバイスに対しては 初期化しか出来なく成ります 此れは旧掲示板の去年辺りのスレに有ります ematei.s602.xrea.com/kakorogu39/リサイクル掲示板202102.htm ematei.s602.xrea.com/kakorogu39/リサイクル掲示板202103.htm
|
感謝 まりも 2022年4月3日(日) 23:58 |
きょうはなんかいっぱい作りました。 1.ROMSUMSV 懸案のROM吸い出しデータ化FDloaderツール 2.FDLDMKFD COM形式実行モジュールからFDloaderフロッピーを作成するツール 3.MMDUMPとITFデバッグポートの解説文書(改訂)
1.ttp://hp.vector.co.jp/authors/VA012947/fdldrapp/romsumsv.html →廃止してROMSUMに統合 2.ttp://hp.vector.co.jp/authors/VA012947/fdldrapp/fdldmkfd.html
HDDに書き込むことを提案されたリウ様、MMDUMPがFDloader直後でも使えることを発見なさったKAZZEZ様 お二方には感謝申し上げます。一人でやっていたのでは気がつかなかったです。おかげでここ最近にやったてきたことがまとまりました。なお、しばらくは98から離れます。
<4日追記> ROMSUMSVについては、MMDUMP.DATからデータを抽出するプログラムが無かったので'MMDCUT'というのを追加しました。まず顕在化しないけどもバグがあったのでほかの実行プログラムもついでに修正。
<5日追記> MMDUMP.DATには1MB空間全てのスナップショットが記録されていますから、例えばゲーム実行中の画面でも保存はできます。といってもリセットボタンを押すことになるのだからゲームは続けられませんが。ゲーム続行よりもとにかくレア画面を保存しておきたいというような時には最終手段としてMMDUMPは使えます。ただしパレットが復元できないのですよね。パレット情報はメモリ上のどこにも保存されていないので。それとテキスト画面に書かれた外字コードの文字も。
<9日追記> ROMSUMSVは、元からあるROMSUM のバージョン2として改良・統合しました。
|
横道逸れますが くりすと 2022年4月5日(火) 21:50 |
MMDUMP.DATで起動中の某ゲーム(HDDにインスールできるMS-DOS形式のファイルには何らかの暗号化されていてファイルビューアで覗く程度では何も分からない)のメモリを採取したら、テキスト形式のスクリプトのようなものが見られてエンディングの条件が手に取るように分かったという…ことがありました(当時は重宝しました)。
今ならその辺りはエミュレータで事足りると思います^^;
|
MMDUMP→FDloader→MMDUMP まりも 2022年4月5日(火) 22:44 |
おおお、そのような使い方もできましたか。ゲームソフトはだいたい専用FDから起動させていて、デバッガ上からの実行を許すようなものはそうそうないですからね。
ところでFDloaderもMMDUMPも調べていないことが2つ残ってます。その一つはデフォルトでのA20ラインの状態です。システムリセットがかかっていればA20ラインマスク状態かと思います が、少なくともFDloaderは自前でアクティブにしていないかどうか。MMDUMPは相当昔からある機能なのでDOSがHMAを使うことなんて想定していないでしょう。DOSも含めてデバッグ情報取り出すことを目的にすると、1MB +64KB-16Bをダンプして欲しかったところです。しかしDMAの1MB超え設定などでさらに手間が増えるし、そもそもがITFのデバッグ用でしょうから仕方ないですね。 今回はFDloader→MMDUMPで情報を取り出しましたが、MMDUMPの直後にFDloaderに入ったら、ひょっとしてMMDUMP直前のメモリ内容が残っていてるのではないでしょうかね。で有ればFDloaderのときにA20ラインアクティブにして、HMAに相当する1MB超えの64KBを1MB以下にコピーしておき、またMMDUMPを実行して取り出すことで、HMAのスナップショットも取り出せるのではないかと。MMDUMP→FDloader(→MMDUMP)がメモリ内容保持できているのか?というのが、二つ目です。もちろんFDloaderがロードされる部分と割り込みベクタ部からシステム共通域までは破壊されるのは当然なので、それ以外の部分についてです。
<4月6日追記>MMDUMP.DATからBANK*.BINを取り出すプログラムを追加したわけですが、既にフロッピーのファイルになっているのだから、FATとディレクトリだけ書き換えてBANK*.BINが8個あるように見せかける手もありました。データを読まないので処理はほぼ一瞬で済みます。しかしサムも表示するには読まないわけには行かないので、MMDCUTのようなことになっています。 <4月7日追記>MMDUMPのときに読み出せるところに限られるので、裏RAMは不可、VRAMのB0000-BFFEFhが適当でしょう。
|
HMAを何処に写す? かかっくん 2022年4月6日(水) 22:09 |
HMAを何処に写すか?ですが、 ・主記憶の640K ・VRAM ・VRAM裏のEMS用RAM(B0-BF) ・シャドウRAM 辺りが候補に成りそうな?
|
FDloader内から直にMMDUMPに移行できる まりも 2022年4月8日(金) 18:00 |
表題のことはどうやら可能なようです。STOP CTRL SHIFT押し起動の時はITFから分岐してBANK2の先頭へジャンプしています。実行環境がよくわかりませんが、ITFがMMDUMPへのジャンプ前に行なっている仕事をそのまま真似たFDloaderを作ったところ、MMDUMPと同様の動作が行われました。つまり、FDloaderアプリ内でITFの吸い出しからフロッピー保存までが一括でできるということです。ただしMMDUMP移行前の設定が機種依存な感じです。I/O 18F0hと18F2hへの2段階I/Oを激しく行っています。DSレジスタの値が0は必須要件です。
ちなみにmate-RでもBANK2にMMDUMPのコード本体は存在しており、ITFからの分岐が削除されていただけでした。この方法ならmate-RでもMMDUMPできてしまいます。RaII 23のROMデータをMMDUMP.DATに落とすことができました。これは少し進歩ですが、BANK2が化けていたらどうにもならないので、これまで通りIDE HDDなどに保存する手段を残しておくことの意味はあると思います。
ところでMMDUMP.DAT(PCI機で作ったもの)について一つ妙なことを見つけました。テキストVRAMは保存されているように見えますがアトリビュートコードの部分はデタラメな値が入るようなのです。黒バック白文字の時はワード単位でFFE1hが読み出されなければならないのですが、そうなっていません。テキストVRAMのアトリビュートエリアは、奇数番地は本当は読んではいけないことになっていますが、普通に読み出せばFFhのはずです。偶数番地も読めてないのです。そもそも後続のA4000からA7FFFhもCGウィンドウですから普通に一気読みしても意味がないところです。A2000h以降は代わりに違うアドレスのデータを放り込んでいるように見えます。したがってMMDUMPではテキスト画面の完全なスナップショットは取れないことになりそうです。
いっぽうグラフィックVRAMは読めているようです。MMDUMPは最初に16色モードに設定していて(out 6A,1を実行)、E0000hのプレーンも読めます。
<20時追記> レガシー486機ではVRAMのアトリビュートエリアもCGウィンドウエリアも正しく(普通通りに)データが書かれていました。リウさんの推測通り、MMDUMPに入る前の御呪い18F0,18F2でKGC操作が関連してそうですね。まさかアトリビュートエリアの状態まで変える機能があるとは思っていませんでした。PCI機での呪術をやめれば読み出せるのかやってみます。<9日追記>やってみたところ画面は表示されたままMMDUMPに移行、途中で一瞬画面が乱れて戻りました(しかしドットアクセスモードになったのとは違う)。アトリビュートエリアのデータはやはりおかしいです。FDへのアクセスもそこらへんで一瞬もたつく感じです。
|
IO18F0 リウ 2022年4月8日(金) 20:40 |
ツイート拾っていただきありがとうございます。むしろMMDUMPするような状態ですとKCGの領域を弄くった値が覗けることがとても有用な気がしますので、NEC開発者としては想定どおりの気がします。 ところで、アドレスと機能についてどなたかまとめた方はいらっしゃるのでしょうか? 大熊猫さんのcbenableを読んでいるとPCI-BIOS関連の値を解析されていたようです。GRPH-2起動設定値は少し前にまりもさんの報告があったと思います。
ノート機ではこのPCI-BIOS関連の値は固定で動かせないようです。(IO18F0 0017が430TX機でも無効)PCIセットアップディスクが動かないこととも関わりありそうです。 (追記)確かめが甘くてだめです。固定ではありません。
|
98未開拓領域のひとつ18F0/F2 まりも 2022年4月8日(金) 21:21 |
二人で違う目的の違う解析作業をしていながら、同じところに収束しているというのがなんともです(笑。 LEMMの作者さんが裏KCG(漢字キャラジェネ)という言葉を使っている対象がそれだと思います。基本的に抜いちゃだめグラフィックボード上にあるSRAMの記憶域管理に関係しているとみられます。記憶操作そのものはI/O A1,A3,A5,A9によるCG操作です。それの補助的何かをしているのが18F0,18F2ですね。PCI機以前から存在はしていますが、レジスタ?はわずかです。レジスタもデータもワード幅あるようです(*)。PCI機以前だと レジスタ0015h,0016hぐらいしかないです。レジスタ0016hには0か1が書かれますが、記憶域のロック/アンロックでしょうかね。<追記>だけではなくて0でも1でも画面が全く表示されなくなる機能(副作用?)が含まれるようです。0だと操作不能にもなる感じ。</追記>
それがPCI機になってレジスタ番号0017hが追加になります。0017hも0か1が書かれ、これこそが裏KCGの記憶域のロック/アンロックです。メモリスイッチへの書き込み可否の上位にこれがいるので、PCI機では古い98プログラミング本の通りにメモリスイッチ変更をやってもうまく行かないんですよね。
拙作のPCISETでもPCI最大バス番号の記憶の際にレジスタ0017hを使っていますが、これはPCI BIOSのファンクションをトレースして当該箇所を見つけたものです。CGへのI/O書き込み値などは、BIOSコードまるパクリです。
BIOSトレースかITF解読くらいしか試みていないので全貌がつかめませんし、まとまった資料など見たことがありません。そもそも解析が一筋縄では行かないのは、2段階I/Oであることと、肝心のデータ出し入れのほうが4つのI/Oで行われることにあります。値のセットが多すぎて、とてもでないが短期記憶で覚えていられないんですよね。外字コードで7610h相当あたりは古い記憶層のデータがあるらしきところで、古くからの機能がどうもそこにあるようです。I/O 841EhからのソフトウェアDIPスイッチの記憶などです。新しい記憶層は仕組みがさっぱり不明です(初出のへんな用語で済みませんが、なんかそういう感じの)。
(*)ワード幅強制ってところがEGCっぽくてグラフィクスと大いに関係がありそうな
|
パーティションテーブルに一瞬だけ嘘をつかせる まりも 2022年4月10日(日) 7:49 |
さてこれをなんとかしたいと思っていますが、良いアイデアは? >DOS6が大容量HDDで起動が遅くなる現象について
パーティションテーブルに嘘書いたままでは非常に具合が悪く、ディスク管理ツール一切禁止になってしまいます。そこで、IPLwareで嘘書くけどもDOSのconfigデバドラで元に戻すというのはどうでしょうか。実はそのようなものは以前考えたことがありますが、目的はドライブレターの強制変更でした。DOSではパーティションテーブルの存在順序通りにドライブレターが割り振られるのですが、それを任意の順序にしてしまうというものです。しかしシリンダ番地昇順以外にするとディスク管理ツールが大変やばい誤動作をするので、config.sysの時点で元に戻すというわけです。
それでも非DOS系のOS、NT/2000,FreeBSD(98)などを使っているとそうは行きませんから、あまりスマートな方法とは言えません。遅い286機でこの問題が特にあるわけですが、286でそのようなOSはあり得ないからまあいいかなというところです。OS/2は?というツッコミは来そうですが、OS/2のデバドラってどうするんだかわかりません。やはりDOSへのパッチに期待? <22時追記> IO.SYSの当該箇所EB 2E とパッチしたところ行けました。9801DXでDOSが快適起動です。副作用はどこに出るかですね。int DChのパーティション位置情報ファンクションあたりでしょうか。<12日追記>当該ファンクションint DCh,ax=0,cl=80hは先頭アドレスなどを返すものでしたので影響は見られませんでした。ただこのファンクション、初めて使ってみたのですが数値が実際の倍の値を返します。
|
たぶん5.0A-Hも同じですよね? KAZZEZ 2022年4月10日(日) 22:37 |
> DOS6が大容量HDDで起動が遅くなる現象 それってもしかしてDOS6に限らず、5.0A-Hでも1GB超に対応した後のアップデートを適用済であれば同じじゃないでしょうかね。去年か一昨年くらいに私が報告したVM21(VXもどき)の例では、外付けSCSI-HDD(4GB)を2GBずつ2k(A:)とDOS5(B:)のパーティションに分けていて、HDD起動メニューからDOSの領域を選んだときに、V30/8MHzだと約1分待たされたというものだったと思います。一方で、486CPUアクセラレータで事前にIPLwareでキャッシュONにした場合は10MHz×4倍速で起動時に待たされる時間は約4秒ほどでした。
ところでA.Idei氏のFD(2.42)で上記環境のDOSパーティション(B:)のルートディレクトリを表示しようとするとなぜか0除算エラーで終了します。A:のルートに対してはエラーが出ませんので、もしかしたらこれも同じような原因なんでしょうかね?
> 286でそのようなOSはあり得ない さすがに上記VXもどきのようにV30切り替え可能機で2kを使うのは極端な例だと思いますが(RA21+ハイパーメモリCPUなら有り得なくもないか?)、NT3.xであれば386機でも使われていたと思います。件のVXもどきの環境で、486アクセラレータのキャッシュOFF(すなわち386SX/10MHz相当)の場合は約30秒待たされました。20MHzでも15秒は待たされそうな計算です。実際のところ386機でNTを使うとすれば386DXでしょうから、もう少しマシなのかもしれませんが。
> mate-RでもBANK2にMMDUMPのコード本体は存在 RaのITFにもMMDUMPの文字列がそれ以前と同じような感じで残っているのは私も気付いていましたが、なんと機能も残っていたのですか。BASICのROMみたいに別のプログラムから利用されているルーチンでもあるのでしょうかね?
ところで逆に、上記VM21/VXのROMにはMMDUMPの文字列は見当たりません。$ログを検索してみたところ、 ttp://weblabo.griffonworks.net/dorlog/2nddorcom/pc-98/23889.html > 昔の機種だとMS−DOSで読めるファイルにはならなかったはずです。(ディスクを直接読み書きしないとダメです。) とのことで、VM21(VX21側のROM)でやってみたところ、DOSはおろかN88BASICからも読めないFDが出来上がりました。FDの直データを読めるツールでしか読めないベタデータなのでしょうかね。 そんなわけで、いつ頃の機種からDOSで読めるようになったのかと思って手持ちの機種を調べてみましたが…あっさりRA2でDOSで読めるMMDUMP.DATが作成されました。VX21とRA2の間に線引きがあるようです(なおUV11には元々この機能が無いらしく普通にウォームブートしただけでした)。ノート機では調べていませんが、上記ログにあるNa9ではDOSで読めなかったというのは、恐らくFDかFDDの不調ではないかと予想します。
|
末尾C値は必要な値なのか? かかっくん 2022年4月10日(日) 23:31 |
で、各領域の末尾C値ですが、DOSの動作に必要な値なんでせうかねぇ? DOSの動作に不要ならIO.SYSにパッチして領域先頭のC値と同じと見做すか1に固定するとかしてパーティション テーブル自体を余り弄らない方が良さそうな? NT3では多分NTLDRのパッチで済みそうな気がします
> とのことで、VM21(VX21側のROM)でやってみたところ、DOSはおろかN88BASICからも読めないFDが出来上がりました。FDの直データを読めるツールでしか読めないベタデータなのでしょうかね。
VX21('87.6)とRA2('88.7)の間で286+の機種と云えば XL^2 UX(共に'87.10)辺りですか XL^2はFDに書き出してフォーマット解析を試して貰えますからあとはUXですか MMDUMPに遣うFDはフォーマットして居なくても遣えますか?其れとも特定のフォーマット(或る形式とかDOSの 2HD/8とか)をしておくやうですか?
DOSのINT24hで セクタが見つかりません (Sector not found) と出るか このディスクは扱(使)えません (Unsupported media) 無効な種類のメディアです (↑) と出るかで判ります。前者は物理フォーマットが規定外の場合、後二者はファイルシステムが規定外の場合です。 但しみいそDOS/えぷDOSはFDを物理フォーマット決め打ちで讀むのでFATの先頭1バイト(1エントリでわない)の 値が規定外の場合です。
考えられるのは<del>BASICの物理フォーマットでファイルシステムが無くDSKI$/DSKO$だけ遣えるフォーマットかも 或いは256/26フォーマット(BASICとの違いはシリンダ0サイド0とインターリーブ)とか</del> BASICや256/26は容量が1,048,576バイトより小さいので考え難いですね。やっぱり2HD/8か? LBA 0から埋めるかLBA 11(0Bh)から埋めるかの違いですかねぇ?
# -100板/AHA-1030P備忘録 ROMはU3にF、U4にA
|
DOS6パッチ情報 リウ 2022年4月10日(日) 23:41 |
手元では起動が早くなりましたので公開します。 パーティション情報を嘘シリンダにしたことをDOS6のIO.SYSの中身で実現するだけです。 595Bh 0D->05 5966h 0E->06 596Dh 0C->04 この付近でパーティション情報CとHSの掛け算で先頭LBAと終了LBAを計算しています。終了LBAを計算する諸元を先頭を示すものから貰い直しているだけです。 もうしわけないですがDOS5A-Hは所持しておりません。ので直接の値は示すことができません。逆アセンブルで+0xeを検索してそれの付近でmulがあると思いますのでそこを終了位置を示す +d +e +cをそれぞれ+5 +6 +4にすれば同じことは実現できると思います。 当然無保証です。パーティション操作系プログラムが文句を言わなくなり起動時間が短縮される利点はありますが、何が起きるかはまだわかりません。
|
DOS5の一部も同じコード かかっくん 2022年4月11日(月) 4:13 |
みいそDOS5では、製品番号0105がみいそ6.2と○々同じコードです 製品番号のチェック法は過去ログ参照 59E1: 8A 46 0D MOV AL,[BP+0D] ← 05 F6 E1 MUL CL 50 PUSH AX A0 0D 2D MOV AL,[2D0D] F6 E1 MUL CL 8B 4E 0E MOV CX,[BP+0E] ← 06 90 NOP F7 E1 MUL CX 59 POP CX 02 4E 0C ADD CL,[BP+0C] ← 04
0104以前は違います。
|
PCILIST 1.47 リウ 2022年4月12日(火) 11:55 |
デバイスヘッダ(PCIconfig空間 0eh)が82hの場合 ブリッジデバイスと見てくれないような結果が出ました。 01h、81hの通常PCIブリッジは当然見てくれます。カードバスの02hの場合は見てくれますが、そこにマルチファンクション(2枚挿せるタイプ)の82hになると見てくれなくなるような気配があります。 13日正午ごろ追記 最新の1.48を試していませんでした。同じでした しかし1.20だとブリッジ情報が表示されます。(しかも最大バスナンバーをBIOSから取得していないようでノート機でもブリッジの上が見えます。)大熊猫さんのfwcbena.sysのドキュメントに書かれていました。
|
PCIlist/PCI setなど まりも 2022年4月16日(土) 11:06 |
PCIlistのご指摘のところを何とかしたいのですが、ノート機ですぐ稼働できるものがない上に、カードバスでマルチファンクションのものがないんですよね。持っているのはアイオーのCBSCIIとメルコのLPC-TXくらいです。PCIデスクトップ機用のカードバスアダプタ(RICOHチップの)もあるはずなのですが見当たりません。 1.20は相当昔ので、PCIset(旧CHACHA)でやっている最大バス番号の設定法が未だ確立していなかった頃のものです。とりあえず力づくで調べていたのでブリッジ情報が見つかったのだと思います。また当初はPCI BIOSを使わずにハードウェアを叩いていました。設定と検出はPCIsetの方に全面的に移して、PCIlistは表示するだけとなっていますが、同時にPCIへのアクセスもBIOSに頼るようになっています。ノート機のPCI BIOSがそこまでひどいものとは知りませんでした。
まずはLa13を家に持って帰らないと。ビネガー化を恐れて、液晶開いたまま他所に保管していたりします。FDDがベルト蒸発で多分動かないので、直接IDE HDDをつなぐしかなさそうです。 <15時追記> La13ってカードバスは搭載していなかったような! そうすると下半身壊れてるNr15しかないのか。
<23時45分追記>VX21ぐらいの古い機種の MMDUMPの件に関連して。 DOS互換形式のMMDUMPが作られる機種のBANK2のコードを見ると、FDCに送りつけるCHRNのデータテーブル(4バイトの組み)が全トラック(0-76)分書かれているのですよね。VX21でも同様のテーブルがあって、物理フォーマットがどうなっているかは察することができるように思います。まあN88BASIC時代ですから256B/Sかなとは思いますが。
|
RA21のITFの場合は くりすと 2022年4月17日(日) 9:57 |
BANK4にCHRNのテーブルがありました。(それ以前にMMDUMP.DATの前に「MMDUMP むぉ」と、あるのは何なんでしょうね^^;)
BANK0〜3はSASI-BIOS除いて全てFFhだったりします。 RA2も同様と思いますが、VXはさすがに違うと思います。
|
とりあえずFD読ませた挙動だけ… KAZZEZ 2022年4月18日(月) 5:44 |
VX21相当で作ったFDは中身をまだ調べていませんが、FDDの動作音を聞く限り、1.25MBにフォーマットするときと同じように76回くらい動作音が鳴った後に、ちょっとテンポの速い動作音が58回くらい鳴りましたので、なんだか普通にフォーマットしてから書き込んでいるような感じです。 このFDを読ませると、N88BASIC(3.0)ではしばらく読み込んだ後にI/Oエラーでした。DOS(5.0A-H)からはこのディスクは使えませんと出ます。Fを押して続行するとINT24Hに失敗と出ますが、その後DIRコマンドを繰り返すとでたらめなファイル情報を表示します。 Win98のSafeモードコマンドプロンプトのみでは無効なメディアの種類と出て、Fで続行するとセクタが見付かりませんとなり、さらにFで続行するとINT 24で失敗しましたとなります。その後はやはりdirででたらめなファイルが見えます。
(23:30追記) はずかしながらDISKまわりは素人ですので、今になって適当なDOS用ディスクツールを昔のベクターCDから漁りました。(汗 (・_・#): じゃあどの分野で玄人やねん! (^_^;): 趣味の世界やし、器用貧乏が身の上かと…。(ぉ ディスクコピーツールADCの簡易アナライズによれば、自動解析で2HDと判断され、どのトラックもトラック内のセクタ長は3かつセクタ数は08でした。これはMD-DOSのFDと同じようで、BASICの起動FDの場合はそれぞれ1と26になりました。 ディスクイメージツールDPACKで無圧縮ディスクイメージを作り、Win上でバイナリエディタで見たところ、先頭はいかにも割り込みベクタテーブルという感じで、メモリマップの境目がA0000とかA2000とかC0000のように切りの良いところに現れていましたので、ファイルシステムなどの領域が無いことになります。なおC0000以降はFFで埋められている感じでしたので、もしかしたらITF領域は反映されないのかもしれません。 以上の感触から、どうも「ファイルシステム等の全く無いMS-DOSフォーマット」みたいなものではないかと予想します。 > 後二者はファイルシステムが規定外の場合です。 …で良さそうですね。
|
やっぱり2HD/8で(略) かかっくん 2022年4月19日(火) 1:06 |
R(S)8N3と云う事はやっぱり2HD/8で、LBA 0からダンプで埋まって居るやうですね LBA 11〜かC1(LBA 16)〜にすれば其の前にファイルシステムを置けそうです。C1ならパッチヶ所が少なそうな?
やっぱりBASICや256/26では1MiBには不足なので此れは無かったですね C000:〜が無いのはBIOSのコPYを防ぐ為の気もしますが、BASICのPEEKで採れるので余り意味無さそうな?
|
むぉ!RvII26には2つのMMDUMPが まりも 2022年4月22日(金) 21:22 |
RvII26を久しぶりに引っ張り出してきたので、MMDUMPを調べてみました。ROM BANK2に従来型のMMDUMPは存在し、FDloaderから飛び込めば機能しました。ところがなんとBANK1にも同様のコードがあるんですね。他のmate-R機種ならmicrocode updateが入っているはずのところにあります。この新型?MMDUMPはファイル名が異なるようです(画像)。しかしSTOP CTRL SHIFT 押し起動したからといって新旧どちらのMMDUMPにも移行せずダンマリでした。おそらく新型用のおまじないキーの組み合わせがあるはずです。まだ知られていませんよね? ちなみに新型MMDUMPにも[むぉ]は存在しています(笑)。どうも実行コード部とも思えませんから何かのキーワード?ちょっと上のムチムチムチムチも気になったり。
それからRvII26で謎が一つ増えました。GETITF98ではRvシリーズでは16個のROMダンプが行われます。ROMバンク切り替えは従来のI/O port 043Fhへの8個の値を叩くことで行われますが、0B00hにF0h, 0B02に00hの二段階を出力すると、ROMがそっくり下位バンクセットに切り替わります。そこのBANK3相当のところにRvII26のmicrocode updateがあります。
ところがFDloaderの段階でこの操作をしても変化しません。また0B02hを読み出した値もFFhです(本来は7Fhか7Ehが読み出せる)。どうやらこの二段階I/Oを上位でロック/アンロックする機構がどこかにあって、FDloaderの状態ではアンロックなようです。ROMSUMで16バンク出力する野望が砕かれてしまいました・・・
なおGETITF98は上記I/O 0B00,0B02hの誤検出でV7やBX4 ,Xe10でも16ファイルが作られる問題がありましたが、これを機会に修正してあります。
|
こんな処にもみいそCHKが? かかっくん 2022年4月24日(日) 12:49 |
去年M.P.SでSASI籠型I/Fが頓挫したらしい件が有りましたが、実は内蔵SASI BIOSにもみいそCHKが有るらしい と云う噺が! twitter.com/yukkuriz/status/1399407459379253253 ykz.f5.si/?p=248
サードパーティ品で50pのSCSI HDDを載せたSASI籠でも面倒そうな回路が載って居たのは此れも理由の 一つな気が?
|
inquiryコマンドもなんか変?とか リウ 2022年4月26日(火) 9:06 |
ttp://rednow.php.xdomain.jp/bbs/b.php/test/l50 SASIに関してはこのような話も?
|
|
|