Re: dpmitest - リウ(drachen6jp)

2024/02/07 (Wed) 22:44:25

アドバイスありがとうございます。
無事にLEMM内蔵DPMIからもAX=301hなint31hが呼べました。
emulator内でセレクタlimitを越えてメモリへ書き込まれていました。そのため他のDPMIでは実行できてしまっていたようです。自分では気づけないところで経験者さまのアドバイスは非常に助かりました。

便乗で質問を一つ、お返事なくとも構いません。
DPMIなプロテクトモードに入った後、AH=4chのInt21hでプログラムを終了する方法ではなく,呼び出したときの状態に戻る方法は簡単にあるでしょうか?
ファイルロードしてDOSプログラム実行をし、終了する、という方法を思いついてはいますがとても煩雑な気がしています。

Re: dpmitest - reiria

2024/02/08 (Thu) 01:56:15

何とかなったようでよかったです。安心しました。

INT-21h AH=4Ch を使わずに戻る方法ですが、たぶん少なくとも DPMI 0.9 の仕様内では無理そうな気がします。
そういう機能があるとすれば、非公開の裏仕様的なものか、もしくは独自拡張の機能かと思われます。

> ファイルロードしてDOSプログラム実行をし、終了する、という方法

その方法が汎用的で安全に思えます。その方法をちょっとひねって互換性や安全を無視すれば、
INT-21h AH=4Ch をフックして処理が DOS に行く前に CS:IP SS:SP 等を適宜設定すれば戻れそうな気もしますが、
そんな危ない方法を実際に使うのかと聞かれればたぶん使いませんね(^^;
(DPMI 自身が INT-21h のリアルモードベクタをフックしていて AH=4Ch で何らかの処理が必要だと危ない)

Re: dpmitest - リウ URL

2024/02/08 (Thu) 06:47:02

お返事ありがとうございます。
なるほど、裏技しかなさそうですか。汎用的で安全な方向で進めたいと思います。

Re: dpmitest - KAZ.K

2024/02/14 (Wed) 21:56:44

最初わりかし意味がとれなくて静観していたのだけど、えーと。つまりDPMIクライアントの終了が呼び出し元のDOSプロセスの終了と必ずセット扱いなのを一つのDOSプロセスの中でどうにかしてみたいところ、どうにもならないので fn 214B とかで実際に実行ファイルからの子プロセスに閉じ込めようとしている、で合っています？

単にDOS側のプロセス終了処理をちょろまかせばすむ話なのであれば、むしろDPMIを起動するより先に fn 2126 (Create new PSP) して Parent PSP と終了アドレスを書き換えてから fn 2150 (Set current PSP) で子プロセスの開始を一つ偽装してそいつを身代わりにすれば良さそうな気がしたんだけど、どうですかね。DPMI起動する前のDOS側の話なのでDPMIホストの実装には関係がないし、少なくとも実行ファイル自体を用意する手間は省けそうな気が・・・したんだけど、いやでもこれはこれでめんどくさいですかねぇ・・・。

Re: dpmitest - reiria

2024/02/14 (Wed) 23:54:27

それでもばっちしいけそうですが、PSP 自作系はオープンハンドルどうするのか微妙に気になりますヌ。
たぶんそのままでも暴走したりはしなさそうですが、
何も対策しない場合は FILES の Ref が通常と異なる値になるのでは・・・

PSP 領域に常駐するプログラムの書き方に PSP 移動しつつ標準オープンハンドルを自力 close する処理があって、
その逆に、今回の場合は何も対策しないと close 回数が多過ぎる状況(?)になるかも。
いや、自分自身今まで何も対策せずに PSP 常駐やってまして常駐後に Ref++ されるという(^^;;;;;;;;;;;;;

Re: dpmitest - KAZ.K

2024/02/15 (Thu) 07:32:41

その辺の事情は本物(?)の子プロセスを生贄に捧げた場合でも大差ないとは思うけれど、そもそも標準ハンドル漏れなんてDOS自身の中にすらわりと残っていませんでしたっけ。大丈夫だよ誰も気にしないっていけるいける（ぇ

Re: dpmitest - reiria

2024/02/15 (Thu) 09:39:16

たぶん普通に 4Bh で子プロセス実行する場合の PSP は DOS がやってくれて Ref の +- も維持されるのでは・・・
Ref++ の場合は最大値まで余裕ありそうですが、
Ref-- (close し過ぎ) だと何回が実行すると 0 になってラップアラウンドするあたりになると、
原因よくわかりませんが、何か変(filmtnh 終了時ハングとか)な気がするのはうちの環境が駄目なんですかヌ(^^;
生贄 PSP の +18h～ を FFh にして終了すればいいんですかねえ、この辺の仕組みよくわかりませんが。

Re: dpmitest - KAZ.K

2024/02/15 (Thu) 10:16:44

生贄ではなく本体のPSPのParentを自分自身にした上で終了アドレスを書き換えてプロセス終了をキャンセルするという手もありそうだけど、こちらはたぶん正規の手順ではないのでなんぞ余計なTSRと絡まったら余計なことを・・・起こそうと思えば起こしそうだけど、実用上はさほど問題ないかも？ うろ覚えだけど確か COMMAND.COM 自体の内部処理がそんな感じだった気がするんですよねぇ。この辺のアクロバットっぽいのって公式には文章化されてないのが問題なだけで、やったところで言うほどおかしな事にはならなさそうな気もする。なお書き換えたのは元に戻さないと本当に終了しなくなってゾンビ化します:)

Re: dpmitest - reiria

2024/02/15 (Thu) 16:57:58

> Ref-- (close し過ぎ) だと何回が実行すると 0 になってラップアラウンドするあたりになると、

まだよくわかりませんが、Ref = 0 でファイルを 2 個以上開きつつ文字表示(CON)するとハングぽい？
type file はハングしない、fc file file はハング、でも type file > o はハングしない。
今のところ Ref のラップアラウンドというかオーバーフロー自体は大丈夫ぽくて、0 の場合に何か変になるぽい？
0 の場合、FILES の頭のほうが標準以外のファイルで使われて、CON 等と混ざってそうな予感はしますが(^^;;;
ともあれ DPMI や filmtnh とか関係なく素の DOS で変になるぽい。

Re: dpmitest - reiria

2024/02/15 (Thu) 23:16:21

> 生贄ではなく本体のPSPのParentを自分自身にした上で終了アドレスを書き換えてプロセス終了

これも試してみたところ、生贄 PSP と違って close されないぽいし、
この方法使っていいならもうこれが一番シンプルでお気楽ご気楽いい気分に思えますな(^^;

Re: dpmitest - reiria

2024/02/15 (Thu) 23:58:04

あーこれ、生贄 PSP の場合も 26h じゃなくて PSP 常駐で使ってる 55h だと close されずにいけますな。
というかもしや 26h で作った PSP に 55h 同等の自力設定が足りなかっただけというオチ？(^^;;;

Re: dpmitest - reiria

2024/02/16 (Fri) 01:56:34

> というかもしや 26h で作った PSP に 55h 同等の自力設定が足りなかっただけというオチ？(^^;;;

そうじゃなくて、55h だと Ref++ されるみたいですな、Interrupt List によると。

PSP 常駐で 55h 使っていた時は自前で close しろって意味がよくわからなかった(参考書を真似ただけ)のですが、
つまり、55h 使ったら 2 回 close しないとまずいという意味だったんですな・・・ たぶん(^^;

で、今回の用途のように、プログラム内で 2 回終了するような場合にはむしろそのままで都合がいいと。

Re: dpmitest - KAZ.K

2024/02/16 (Fri) 07:45:33

あーそんなでしたっけ。いえそのへん調査したのは私もTSR作成コードをでっち上げた時の話でいったい何年前なのか、細部の記憶はあてになりませんナ(--;

うちのは 2126 で本体丸ごとリロケートして全部解放してからDOS任せで Best fit 投げてるんですよね。何しろ丸ごとリロケートなので常駐作業には一時的に本体ロードサイズの倍のメモリがいるという超絶手抜き仕様:)

Re: dpmitest - KAZ.K

2024/02/16 (Fri) 08:25:05

というかPSP作った時点で生贄が実子だろうとエア子だろうと元のとは別のプロセスになっていることには違いないわけで、オープンハンドルの引き継ぎ制限とかはばっちりかかってるんですよねぇ。どれでも動くっちゃあ動くと思うけれど、正規の手順に近いかわりに余計な動作が明確に多すぎるのと、やり口としてはいちばんやくざっぽいけど実は余計な動作が一番少なくておかしくなる余地が少なそうなのと、これはどっちのほうがマシなのか・・・。

Re: dpmitest - reiria

2024/02/16 (Fri) 23:37:49

> > 生贄ではなく本体のPSPのParentを自分自身にした上で終了アドレスを書き換えてプロセス終了
>
> これも試してみたところ、生贄 PSP と違って close されないぽいし、
> この方法使っていいならもうこれが一番シンプルでお気楽ご気楽いい気分に思えますな(^^;

DR-DOS (OpenDOS) のソースを眺めてみた印象ですが、このような終了処理が何かうまいこと使えてしまうのって、
ルートプロセスの解放回避が本来の目的ぽい感じなんですかねえ。
といっても、本物のルートかどうかの判別なんてしてないようで何でも使えちゃうぽいですが(^^;

MS-DOS でも同様なのかわかりませんが、command.com の内部で使っているなら互換性(?)もあるのかも？

Re: dpmitest - リウ URL

2024/02/24 (Sat) 23:16:24

議論が起きてるのは見ていたのですが
DPMIを一度動作条件から外して進めていました。
ドライバ内部でDPMIを呼び出し、仕事が終わったらその呼び出し位置に帰る、ということをやりたかったのですが、今はとりあえずのプロテクトモード移行になっています。
できたものはURL欄のものです。

まだとてつもなくα版なのですが ご報告致します。
アドバイスにも大変感謝しております。

USBSCANのソースが一番の頼りでした。公式ドキュメントよりもそちらを見ていた気がします。

Re: dpmitest - reiria

2024/02/25 (Sun) 23:58:32

早速、ohcimsd.exe を Xa16 の BUFFALO UCI2-P2 で USB メモリ 1GB (FAT16) を試してみました。
ohcimsd.exe の組み込み時に USB メモリの LED は点滅しますが「ドライバ組み込み失敗」と表示されます。
UCI2-P2 のポートは両方試してみましたが同様のようです。

あと、手持ちの USB I/F で PC-9821 対応が明記されたものに IODATA USB-PCI があるので、
この機会に Xa16 に UCI2-P2 と 2 枚刺しにしようと格闘してみたものの C バス SCSI と共存出来ず・・・ (^^;

Re: dpmitest - リウ URL

2024/02/26 (Mon) 02:53:35

動作実験ありがとうございます。軽く調べたところCMD製チップですね。LEDが光ったということはREAD_10の命令受付にまでは到達しているような気がします。MBRを読めても、その後領域先頭を読みに行くと失敗、のようなへたくそ実装が隠れています。全く自信がありません。

夕方頃の実験ではブリッジチップの先では動作不安？という結果も得ておりました。やはりα版もα版です。V166では書き込みもできてしまって喜んだりもしていたのですが速度も全くでていませんでした。
またくだらぬ質問をしてしまうかもしれません。お時間あるときにはお相手していただけると幸いです。

Re: dpmitest - reiria

2024/02/27 (Tue) 00:15:22

USB-PCI と V166 でも ohcimsd.exe を試してみましたが、当方の環境ではいずれも認識出来ないようです。
USB-PCI のチップは NEC D66565GCE15 0035PK001 で V166 内蔵のものと似てそうです。
(USB-PCI は rev 03、V166 は rev 01)

それと、USB メモリはサンワサプライ 600-UF4G というものなのですが、
USB-PCI と V166 では usbscan.exe でも認識出来ないようです。(UCI2-P2 では認識出来るぽい)

usbaspi.sys ではいずれでも OHCI で認識してアクセス出来るので、
usbaspi.sys ではちゃんと出来ている処理で usbscan.exe では出来ていない何かがあるのは間違いなさそうです。

Re: dpmitest - reiria

2024/02/27 (Tue) 17:56:05

> それと、USB メモリはサンワサプライ 600-UF4G というものなのですが、
> USB-PCI と V166 では usbscan.exe でも認識出来ないようです。(UCI2-P2 では認識出来るぽい)

usbscan.exe を何度も実行していたら何か運が良かったのか 1 回だけ認識出来まして、
となると処理不足というよりウェイト不足かなと usbscan.exe をオプション wait*10 とかにしても認識出来ず、
これはもしや、現状では全くウェイトを考慮していないところにウェイトが必要なのでは・・・ (^^;

あれこれやってみたところ、初期化時の MMIO への write 連射にウェイトが必要だったようで、
具体的には usbohci.c の _usbohci_init_Hc() の Hc_write() 連射が鬼門らしく、
とりあえずそこの Hc_write() 全部に wait(100000) を入れたらあっさり認識出来るようになりました(;_;)
より具体的にどの Hc_write() 連射が駄目なのか確認してみます。

Re: dpmitest - reiria

2024/02/27 (Tue) 23:21:05

> より具体的にどの Hc_write() 連射が駄目なのか確認してみます。

どうやら HcRhStatus と HcControl への Hc_write() 連射の間がウェイト不足ぽいです。

_usbohci_init_Hc() の、

> Hc_write(HcRhStatus, 0x00010000UL);
> //wait
> Hc_write(HcControl, 0x000000B3UL);

という箇所です。

とりあえず //wait を wait(500000) にしたところ 600-UF4G を USB-PCI や V166 で認識出来ました。

で、HcRhStatus について OHCI の仕様を眺めてみると、

> HcRhStatus and HcRhPortStatus must be writeable during the USBOPERATIONAL state.

と書かれていて、もしや HcRhStatus → HcControl (UsbOperational) の順に write してるのが駄目なのかも
と思い、逆にしてみたところ、むしろ認識されにくくなくなるような・・・ (^^;

USBドライバ - リウ

2024/03/01 (Fri) 21:50:06

ここで続けてもいいのか心配ですが
OHCI側をバージョンアップしました。
waitはいろんなところにかけました。
うちでは動いているのですが やはりどこにwaitが必要なのかよくわかっていません。

initial時のwaitですが
rhstatusとhccontrolの間ではなくそれの後ろにwaitを入れるとbitが立つ、というのがうちでは確認できていたようです。