VTDOS+VZ でファイル編集中に #N や、#P で、拙作の TAGL_F5.DEF を実行すると
&z("expand") を呼ぶところでマクロエラーになります。
ESC を押すと、VTDOSが、ラップアラウンドエラーで落ちます。

実は、私の環境では、expand.def が無かったんです。
つまり、ファイル操作窓で、マクロ呼び出しなどでファイルが無いエラーになると
ESC で入力窓を閉じる時、VTDOSが、ラップアラウンドエラーで落ちるのです。
エラー内容は

2018-10-18 20:29:03 VZIBMJ(17EA) 17EA:DE8E 'REP MOVSW 命令ラップアラウンド'

AX=0023 BX=4000 CX=0082 DX=FF00 SI=EA60 DI=FF04 BP=CBEE DS=E800 ES=F800 FLAGS=0246

CS:IP=17EA:DE8E
17EA:DE7E 40 06 51 57 51 57 E8 B1 00 E8 2D 04 5F 59 F3 A5 
17EA:DE8E E8 44 04 5F 59 36 03 3E 46 06 48 75 E5 E8 AC 2E 

SS:SP=274A:CACE
274A:CABE 00 00 04 FF CD E2 04 FF 23 00 8A DE 04 FF 82 00 
274A:CACE 04 FF 82 00 4A 27 4A 27 76 03 DB A3 90 06 00 FF 

-u 17EA:DE7E
17EA:DE7E 40            INC	AX                                 
17EA:DE7F 06            PUSH	ES                                 
17EA:DE80 51            PUSH	CX                                 
17EA:DE81 57            PUSH	DI                                 
17EA:DE82 51            PUSH	CX                                 
17EA:DE83 57            PUSH	DI                                 
17EA:DE84 E8B100        CALL	DF38                               
17EA:DE87 E82D04        CALL	E2B7                               
17EA:DE8A 5F            POP	DI                                 
17EA:DE8B 59            POP	CX                                 
17EA:DE8C F3            REPZ	                                   
17EA:DE8D A5            MOVSW	                                   
17EA:DE8E E84404        CALL	E2D5                               
17EA:DE91 5F            POP	DI                                 
17EA:DE92 59            POP	CX                                 
17EA:DE93 36            SS:	                                   
17EA:DE94 033E4606      ADD	DI,[0646]                          
17EA:DE98 48            DEC	AX                                 
17EA:DE99 75E5          JNZ	DE80                               
17EA:DE9B E8AC2E        CALL	0D4A                               
-q

 0000:DE59       POPWINDOW

ここは、入力窓ルーチンの窓を閉じるところですね。
SORT.DEF も、バックアップルーチンで、#N を使用していますが、
何かエラーが出ていた気がします。

MSDOSPlayer や、DOS窓では、マクロエラーがあっても落ちません。
この辺に何かありそうな気がするのですが。

> ざっくりですが、画面の出力座標かサイズに問題が起こってるようですね。
> 外してるかも知れませんけど、scrn.asm の win か doswd2
> これらはマクロからアクセスしてログを取ることなどは出来ますか？

えーと、何をすればいいのかわかりませんが

VTDOS環境では、全てのVZで同じ操作で落ちました。
オリジナルVZとオリジナルDEFでも、#Nで、拙作の TAGL_F5.DEF を実行して
落ちます。

TAGL_F5.DEF の冒頭は

24  [F05] "検索文字列の取得"
	(s==1||s==2)? { &z("expand") >* }	; コマンドライン

こうなっていて、これは、上村さんの、GET.DEF と同じです。
私はこのマクロをベースに改造したのですが、expand.def が無いのに
気が付かなかったのです。

入力窓の中で、マクロがエラーで止まって、フラグとか
スタックとかの数値に矛盾が出てるんでしょうかね。

　/     マクロの実行を終了
　  ネストレベルに関係なく全てのマクロが終了する
　  マクロを終了するときは '.' を使うほうがよい
　  （モード型のマクロも終了してしまうため）

　誰かがもう少し詳しく纏めていたような気もしますが、僕に分かったのは
これだけです。使ったことないですよね。ほとんど禁止されてたみたいなもの
だった気もするし。

　「/　マクロを強制中断（使用禁止？）」（上村さんの「道場」より）
　プッシュ・ポップも戻さないで、強制終了。
　僕の印象のソースは、ここかもしれません。

　でも、その!abort技、ありなんじゃないでしょうか。かなり稀な緊急事態のような
気もするし。こうなったら、Ｖｚを再起動せよ、で、いいような。

過去ログを読んでも、!Abort 処理は挙動がよくわからないので、
皆さん入れてない人が多いのではないでしょうか。
老師の言によると

> 03777/03785 XXXXXXXX  m.gann           RE:Ｑ：lbuf を文字列として扱うのは可
> (15)   97/01/03 21:30  03719へのコメント

> 　通常、「変更できません」や「オープンできません」などのエラーで、実行中
> 　の全マクロ（モード型を含む）が強制終了してしまいます。
> 　これは、'/' 抜きの !Abort で解消できますが、各マクロで、(r)?. などの、
> 　自前のエラー処理が必要となります。

> === test
> * M
> 1 ^\ "" ?. mr[$80, #28 mr], #] &b(3) &m("r: %d",r)
> 1 "!V"  ?. &m("a") &b(3) &w(60) ''
> 1 "!A"  &m(r) &b(3) &w(60)
> *


こういう記事を見て、下記のようにしました。

1 "!Abort" 
	 &m("!Abort %s",r) &b(3) &w(60) 
;        (r>0&&r<45)?&m(r) s-, &w(60) &d &b(3) cm0~,

下側のコメントは、別の書き込みの物で、今交互に試しています。
!Abort を通ると、"/" が無くても、#N の事例でVTDOSが落ちないようです。

現状副作用として、View モードの時、Enter でファイルが閉じなくなりました。

1 "!View"　マクロの

	(cm==4)?{ &m("") (mb)?. #C &d. }			;#m

この行が最後のほうにあったのを、先頭に持ってきたら正常動作になりました。
これでしばらく様子を見ようと思います。

　いつもの超断片的補足です。(^^;

http://tamaneko.world.coocan.jp/vz/TAGL_F5.def

=== tagl_f5.def v.06 ===
* M
24  [F05] "検索文字列の取得"
	(s==1||s==2)? { &z("expand") >* }	; コマンドライン

　このように、tagl_f5.defは、sが

　    1 : 文字列入力モード
　    2 : コマンドラインモード

であると、expand.defが呼ばれる仕様になっているのですが、
expand.defがないばあい（%vzdef%ディレクトリに、かな？）、つまり

>ファイル操作窓で、マクロ呼び出しなどで、ファイルが存在せずエラーになると
>ESC で入力窓を閉じる時、VTDOSが、ラップアラウンドエラーで落ちるのです。

　失礼しました。
　マクロを見るまで、何を言ってるのかよく分からなかったもので。m(__)m


#N
　#72  #N  新規ファイルオープン
　[ESC]N @N

#P
　#25  #P  ファイル名の複写
　^QN  le_copyfile
　  r は常に 0
　  編集中のフルパスのファイル名が
　  カーソル位置に書き込まれる
　  &?(wa+146) と同じ

　に何かあるのかも？　と。

　追試するには、まだまだ環境整備がままなりません。m(__)m

　もう少し問題を絞り込んだほうが良いような気がしますが。
　マクロのどの部分でかとか。 
(s==1||s==2)? { &z("expand") >* }	; コマンドライン
　この部分だけで落ちますね。

　で、落ちるのはvtdos環境に限定されていないと思います。今、純ＤＯＳで
expand.defを0expand.defにリネームして、
=== tagl_f5.def v.06 ===
* M
24  [F05] "検索文字列の取得"
　のマクロを再カスタマイズ、検索窓で[F05]したら、マシンが落ちました。
落ちるのはまずいだろう、とは思いますが。
　マクロがいけない？　vz.comがいけない？　マシンが落ちるのが正しい？
　補足でした。

> この件でVTDOSに手を入れてログを取ったりしてちょこっと追っかけてみたけど、
> これやるの？って所まで来てる（精神的に

10#さん、ご面倒をおかけして、すみません。

SCRNIBM.ASM	 の中のエラーになるルーチン
popwindow proc 	 のところで rep	movsw の手前に

	cmp	si,imgstack
	jc	popw8
	cmp	si,di				;★追加
	jbe	popw8				;★
	mov	si,[si-2]
	mov	imagep,si
_repeat
IFDEF J31
	call	putline
ELSE
	pushm	<cx,di>
  IFDEF DOSV
	pushm	<cx,di>
    IFNDEF US
	call	chkkanjilow
    ENDIF
	call	vrestore
	popm	<di,cx>
    rep	movsw				;★★★


このように、si と di のチェックを追加したら、#N でのマクロエラーで
!Abort が無くても落ちなくなりました。

これで何かわかりますでしょうか。


ちなみに、CX がゼロ以下かのチェックを入れても変わらなかったです。

（Ａ）
>これは環境によって落ちたり落ちなかったりしているのかも。
>つまりメモリのどこかを壊しているが、たまたまそこで落ちないだけとか。
　すいません、話が見えておりません。

　検索窓を出す、&z("xxx") >*をする、xxx.defは%vzdef%に存在しない。
　これで落ちない環境ってあるのでしょうか？
　申し訳ないことに、vtdos環境ではやっていないのですが、DOS, WinMEでは、
上でしっかり１００％落ちました（実験２回ですが）。
　窓落とすのもマシン落とすのも嫌い。

　通じていると思いますが、s==0の編集モードでは、エラーメッセージが
出て、落ちません。


　こちらは僕が完全に話の流れを見失ったのかもしれませんが、上の件と、#N
は繋がってるのですか？　「ここで繋がっていたでしょう！」というばあい、
発言番号でポイントしていただけますでしょうか。
　#Nって、sort.defから来てますよね？
　（#Nって、よっぽど特殊なファイル名?を指定しないとファイルオープン
に成功するのじゃなかったでしたっけ？　これでは上のファイルオープン
失敗の&z("")の話とのリンクがない？？？）

　上の件（Ａ）は、&z("")の手抜き仕様（仕様は仕様）みたいに想像していました。

　ご面倒でしたら、スルーしていただいて構いませんよ。
　何か、僕に考えられることは、もうないような、気が、して、おりまして、、、。


>マクロや環境を見直した方がいいということかもしれませんね。
>DOSのメモリ管理は厳密ではないとはちょっと思いますね。
　話が見えません。m(__)m

90 [F11] ""
   &z("xxx") >*

これで窓（なんでもいい）でF11押すと落ちます。

> 90 [F11] ""
>    &z("xxx") >*
> 
> これで窓（なんでもいい）でF11押すと落ちます。

DOS窓やMSDOSPlayerではやっぱり私の環境では落ちなかったです。
私家版は弄っているので、オリジナルVZで確認しました。


MSDOSPlayerでは、
#N 窓では、エラー表示は出ますが、黄色いマクロコードは表示しません。
ESC ２回までは画面が変化なし。
ESC 3回目で入力窓が消えるので、画面の再表示になっているのでしょう。


DOS窓では、
げげ、オプションエラーのせいか、起動前に窓が落ちた。
高橋版も同様でした。
修正前の公開版VZk07t1 では、カスタマイズエラーと出ますが起動成功。
Rf オプションが無いからですね。

で、#N 窓では、エラー表示が出て、黄色いマクロコードも表示しました。
ESC １回で、画面にゴミが表示されます。
ポップウインドウで、違う領域のメモリを画面に書き込んでいると思われ。

ESC 3回目で入力窓が消え、画面も再表示されて正常に戻ります。
その後、おかしくなりやすいファイラーコマンドなども特に異常なしです。

　（またしてもどこに繋げてよいのか分からない。直近のここに失礼します）

#8273

2018-10-09 23:49:11 VZ(15F3) 15F3:DC5B 'REP MOVSW 命令ラップアラウンド'
AX=000C BX=269C CX=009F DX=FF7D SI=2440 DI=FFE4 BP=CF52 DS=D000 ES=C000 FLAGS=0206
CS:IP=15F3:DC5B
15F3:DC4B 67 EB 8E C0 58 8B F7 36 8B 3E 40 06 51 56 F3 A5 

　この話、ここから始まっているんですよね。
　で、


#8349 (sort.defのコード)
	pf[=pr,bl[=kp-k,#N #P #m  
	(r<0||wa..13+v<bl+v) bl],pf],?{ #C r+,>e}		;<v>僕、読んでませーん。

　の#N #P に何かあるということになった（？？？）
　僕は、マクロコードを説明しただけです。ここに何かあるなんて言ってません。


#8375 
VTDOS+VZ でファイル編集中に #N や、#P で、拙作の TAGL_F5.DEF を実行すると

　うーん、僕も、#8273 のことを後で考えていたとき、その前に、何かが起こって、
デバッグエラーコードが指すルーチンは、おかしなsi, diをもらって発狂したんだろう、
そのルーチン（pushwindow）に問題があるわけではなく、と思ったのです。教えて
もらって、そう想像したのです。

#8309

>> 改めて調べてみたら該当箇所はscrnibm.asmのpushwindowでした。
>> ざっと見た感じではfarsegの内容？のように思えますが、
>> これが何なのか…

>私も確認しました。
>これはおそらく、メニューウインドウの裏のテキストを退避、復帰している
>のだと思います。

　すると、今回の件も、そもそも、&z("")に手抜きの仕様があり、#Nで起きていることは
「おかしなsi, diをもらって発狂」という事態なんじゃないのかな、sort.defの#N #P
と繋げるべきなのかなぁ、などと思っています。

　それより、sort.defが#Nの箇所で狂っている、って事実は確認されたのかなぁ、と
いうことが、少し気になりました。


　総じて、引っ込んでいたほうがいいようですね。そうさせて頂きます。お休みの日です。
安息日です。敬虔なクリスチャンなのです。嘘です。クリスチャンは嘘をつきません、
たしか。だといいな。

　あ、まだ休んでない。休みましょうよ、疲れた。

　もちろん、僕にはＶｚのソースを読むことなんてできません。
　い、いつか、、、。

in #8375 konno wrote:
（上に逆アセコード）
>ここは、入力窓ルーチンの窓を閉じるところですね。
　これをみて、

in #8376 10# wrote:
>画面の出力座標かサイズに問題が起こってるようですね。

　細かい点がちゃんと分かっているわけでもない文太は、偉そうに

in #8382 文太wrote:
>「画面の出力座標かサイズに問題」。これに一票。
>vz.comの問題だと思う。
　とか書いてます。窓が出るか、出ないか、この違いだ、と。


　下がkonnoさんの仮説ですが、うーん、ですよね。
>SORT.DEF も、バックアップルーチンで、#N を使用していますが、
>何かエラーが出ていた気がします。


>MSDOSPlayer や、DOS窓では、マクロエラーがあっても落ちません。
>この辺に何かありそうな気がするのですが。
　検索窓で&z("xxx") >*をする、xxxは存在しない。
　これで、落ちませんか？　純ＤＯＳで落ちる場合、Ｖｚ的には
落ちるのが正しい、というのが僕の判定なのですが。

　ありがとうございました。
　こんなことが調べられるとは、、、。

EMM386.EXEのエラー(Exception Error)について
#6   Invalid opcode  (無効オぺコード)

　どっか変なところへ飛んでいった。
　お休みなさい。

Bunta wrote:
>> 　検索窓で&z("xxx") >*をする、xxxは存在しない。
>> 　これで、落ちませんか？

konno wrote:
>ここは、同じ実験をした結果なので、手順を間違えていなければ
>どちらも事実だと思います。〔＝MSDOSPlayer や、DOS窓では、
>マクロエラーがあっても落ちません。〕
>VTDOSでは、REP 命令でチェックしているために落ちていますが
>DOS窓やMSDOSPlayerではそこにチェックルーチンはありません。
>そして、私の環境では落ちなかったのです。
>
>マクロがエラーになると、画面下に黄色くマクロコードが出ますよね。
>私のマクロはバグが多いので昔からよくこの状況に会っていますが
>このエラーが出ると大抵マクロの動作がおかしくなって、VZを再起動
>するはめになっています。
>ポインタやスタックが狂ってしまうんでしょうね。

（Ａ）
#N &z("xxx") >*		;xxx.def存在せず

　というコードで、落ちたり、あるいは、致命的打撃を受け、その後Ｖｚ
の再起動を余儀なくされたりする。
　&z()は、s>0でのエラーチェックが弱いので、si, di（たとえば）を
ぐちゃぐちゃにする。
　#N時に&z()されると、まだ#Nは処理を終了していないのに&z()に
「ポインタやスタックを狂わされている」ので、落ちる、あるいはやがて
再起動ということになる。

　#Nの問題なのだろうか、というのが、変わらぬ（進歩しない）僕の疑問
です。

>MSDOSPlayer や、DOS窓では、マクロエラーがあっても落ちません。
　を僕は、ここ以降の記述も考慮して、上で「致命的打撃を受けたけれど」
と解釈しました。
　（Ａ）のあと、ふつうにＶｚで作業を続けられる状態【だった】のですか？
続けられる状態【なの】ですか？

　konnoさんのvtdos+vz.comにむけての意図は理解しているつもりです。
　上の僕の疑問点に回答をいただいても、もう僕にできることはないだろう、
と思っております。
　話の整理をしようとしているだけで、２年後の僕に、状況を分かりやすく
してやっているだけです。

　konno版07t(旧版) on MS-DOS 6.2Vでは、以下の結果でした。
　きれいに全部落ちました。
　ラップアランドを見直すことで、vz on vtdosの振る舞い全般が改善するので
あれば、それは僕にとっても喜ばしいことですが、、、。

=== Macrotmp by B ===;
xxx.defは%vzdef%に存在しない。
窓はもう少しあったと思うけど、いいんじゃないですか？　描画のし直しで問題が
顕在化する（そこでＶｚが死ぬ）と分かっているのだと思うので。
* M
50 ^^ "Macrotmp"
			;常駐			非常駐
#F &z("xxx") >*		;dead emm386 etc	dead ０で除算
;#N &z("xxx") >*	;dead ０で除算		dead ０で除算
;#O &z("xxx") >*	;dead emm386 etc	dead ０で除算
;#J &z("xxx") >*	;dead ０で除算		dead emm386 etc
*

　意味ないでしょうね。

=== Macrotmp by B ===;
マシンにしろ窓にしろ、落とすの嫌だなぁ。ＥＭＳありです。
* M
50 ^^ "Macrotmp"
			;常駐(80x25)	非常駐(80x25)
#F &z("xxx") >*		;マシン落ち	マシン落ち
			;常駐(80x30)	非常駐(80x30)
;#F &z("xxx") >*	;窓落ち		窓落ち
*

＊当然のことながら、このような場面で、WinMEは大変に弱いＯＳです。
　「マシン落ち」はＯＳ再起動を、
　「窓落ち」はＯＳは落ちないが窓は落ちること
　を意味します。
＊問題の切りわけのため必要な作業なのでしょうが、ＥＭＳなしのＶｚは、
　そのような状態でＶｚが起動する設定（各種バッファの縮小）を捜すのが、
　そもそも大変なことなので、パスです。

4F1A <--    2  138512  vz 1.60t -z                1B 21 29 FA
70ED        1  115920  <free>
8D3B 0007   4   72736  emsmagic

----- EMS ver4.0 (frame: 8F00h) -----       ----- XMS ver3.00 -----
handle pages   size  name                   HMA used: 61 KB by DOS
------ ----- ------  --------               EMB free: 2048 KB (max: 5120 KB)
     1     2    32k  for Vwx!
     2     6    96k  VZ

　このようにファイルをほとんど読み込んでいなくても、ＥＭＳは６ページ確保
されるvz.defでありvzfl.defです。NEC98の時代から、こうなのです。
　このノートは元ＸＰ用で、emsmagicを使わないといけないという特殊なマシンです。
ありがたいけど、これすら嫌い。このように我侭な人間には、昨今のＯＳでＶｚする
のは、やはり困難なことなのでしょう。

既に説明していますけど、EMM386#6は定義されていない命令を実行しようとしたときに発生するもので、
通常これは予期しないアドレスにジャンプした場合か、予期していたジャンプ先が書き換えられた場合に発生します。
その直接的な原因はスタックのpush/popが狂った、スタックのリターンアドレスが書き換えられた、
ジャンプテーブルの内容が書き換えられた、ジャンプテーブルのインデックスが異常になった、
コードセグメントの一部が書き換えられた、割り込みベクタが書き換えられた
等が考えられます。

> そのたび窓が落ちたりしないように、rep 命令で、si と di が矛盾していたら
> そのループ命令は実行しないでスルーするという風なルーチンを仕込んでいる
> DOSがあるという事は無いでしょうか。
> つまり、０回のループとしているとかで。

一般的なx86プロセッサはストリング命令のセグメントラップアラウンドはそのまま処理します。
この命令にトラップを掛ける機能はありません。
例えば転送先が 8000:fff0 で転送バイト数が100hバイトだった場合、8000:fff0からffffまでに転送したのに続いて
8000:0000から00efまでに転送します。

DOSのEMM386#6の原因にストリング命令は直接的には関与していないと思われます。
間接的に関与していたりとか、双方の原因となる論理的なエラーが発生している可能性はあります。
少なくともMS-DOS/V+EMM386とNP2/NTVDMの間には非互換性があるようです。   

> これは妄想の想像にすぎないかもしれませんが、VTDOSに現在ある、SCASB_MODE=1
> というオプションは、rep 命令で矛盾があってもスルーするのですよね。

SCASB_MODE=1 はスルーしているのではなく、セグメントラップアラウンドを正確にエミュレートしています。

> 既に説明していますけど、EMM386#6は定義されていない命令を実行しようとしたときに発生するもので、
> 通常これは予期しないアドレスにジャンプした場合か、予期していたジャンプ先が書き換えられた場合に発生します。
> その直接的な原因はスタックのpush/popが狂った、スタックのリターンアドレスが書き換えられた、
> ジャンプテーブルの内容が書き換えられた、ジャンプテーブルのインデックスが異常になった、
> コードセグメントの一部が書き換えられた、割り込みベクタが書き換えられた
> 等が考えられます。

なるほど、VZマクロはスタックセグメントで実行されているため、マシン語マクロも
同じセグメントで動作するので、マクロのエラーや中断などでセグメントが違ってしまう
事もあるかのなと思っていました。
セグメントが違えば、そこには実行コードと違うものが存在しているので、無効命令と
なってしまうのかなと思っていました。

とすると、EMM386 の場合は、rep 命令で落ちているのではなくて、そのメモリ操作
によって、予期しない不正な場所のメモリが書き換えられたからエラーとなる。
こういう理解で合ってますかね。

VZの入力窓のポップは、退避していたVRAMデータを書き戻しているだけなので
多くても2000bytes 程度だし、辻褄が狂ってゴミデータをVRAMに書き込むだけなら
実害は無いのですが、別の場所（セグメントなど）に書き込むとしたら危険ですね。
例のマクロでEMM386 エラーが出るのはその実例ということですかね。


> DOSのEMM386#6の原因にストリング命令は直接的には関与していないと思われます。
> 間接的に関与していたりとか、双方の原因となる論理的なエラーが発生している可能性はあります。
> 少なくともMS-DOS/V+EMM386とNP2/NTVDMには非互換性があるようです。   

> SCASB_MODE=1 はスルーしているのではなく、セグメントラップアラウンドを正確にエミュレートしています。

ここが最初あれ？　と思ったのですが、上の文章と合わせて読むと、非互換性に対処する
処理を追加したモードというか、互換性を高めたモードと考えればいいわけですか。


ポップウインドウの問題はVZの手抜き仕様が原因なので、VZのソースで対策した
ほうが良さそうな気がしています。
単にスルーさせるだけより、何かエラーメッセージ的なことが出来ないかなと
考えています。

> なるほど、VZマクロはスタックセグメントで実行されているため、マシン語マクロも
> 同じセグメントで動作するので、マクロのエラーや中断などでセグメントが違ってしまう
> 事もあるかのなと思っていました。
> セグメントが違えば、そこには実行コードと違うものが存在しているので、無効命令と
> なってしまうのかなと思っていました。

x86は全て命令実行はcsとなってますね。スタックセグメントで動作する、というのは、
csとssが同一であるということですかね？確かVzはss=dsでcsは分離でしたが、
マクロのマシン語はss配置ですか。
「セグメントが違う」というのはいろんな意味合いに取れてしまいますが、
例えばセグメントレジスタが予期しないものとなった場合は予期せぬ動作からの無効命令は
あるかもしれません。

> とすると、EMM386 の場合は、rep 命令で落ちているのではなくて、そのメモリ操作
> によって、予期しない不正な場所のメモリが書き換えられたからエラーとなる。
> こういう理解で合ってますかね。

ストリング命令が無効命令例外を発生させることはありませんが、その結果が無効命令例外に
繋がる可能性はあります。別の所に原因がある可能性もありますよ。


> VZの入力窓のポップは、退避していたVRAMデータを書き戻しているだけなので
> 多くても2000bytes 程度だし、辻褄が狂ってゴミデータをVRAMに書き込むだけなら
> 実害は無いのですが、別の場所（セグメントなど）に書き込むとしたら危険ですね。
> 例のマクロでEMM386 エラーが出るのはその実例ということですかね。

VTDOSのエラーログを見る限りdiがFFxx付近を示してるため、ここは疑似VRAMとは違う場所になります。


> > DOSのEMM386#6の原因にストリング命令は直接的には関与していないと思われます。
> > 間接的に関与していたりとか、双方の原因となる論理的なエラーが発生している可能性はあります。
> > 少なくともMS-DOS/V+EMM386とNP2/NTVDMには非互換性があるようです。   
> 
> > SCASB_MODE=1 はスルーしているのではなく、セグメントラップアラウンドを正確にエミュレートしています。
> 
> ここが最初あれ？　と思ったのですが、上の文章と合わせて読むと、非互換性に対処する
> 処理を追加したモードというか、互換性を高めたモードと考えればいいわけですか。

セグメントラップアラウンドの説明は以前に行いましたので省略しますが、
これをなにがしかの実装テクニックとして活用する可能性もなきにしもあらずなんですが、
一般的なセグメントの構成は上位伸張か下位伸張かのどちらかで、通常はオフセット0000付近か
FFFF付近（スタック）に集中するため、セグメントの両端を一度に操作するセグメントラップアラウンドを
活用する設計はきわめて不自然であると言わざるを得ません。
実際にVZのソースに於いてストリング命令の箇所は全て確認しましたけど、そのようなメモリ配置を
行ってると推測される事例は見当たりませんでした。
こういった理由からVTDOSではセグメントラップアラウンドは何らかの問題の結果と見なして、
通常は致命的エラーとしています。
また、セグメントラップアラウンドのエミュレーションはコスト高になるというのも理由です。
SCAS_MODE=1は、わざわざコストを払って何らかの問題を見て見ぬふりをしてるというのが僕の認識です。

>VZ の &z は、編集モードのみ動作保証しているようで、ファイラーで誤動作は
>周知徹底してますが、入力窓も駄目ということですね。
　いろいろありそうだよなぁ、とは思いますが、以下のようなのは、ふつうにうまく
いきましたよ。
　もちろん、expand.defがある状態で実行しました。

=== Macrotmp by B ===;
* M
50 ^^ "Macrotmp"

#F "auto" &z("expand") >*
&m("%s",ps)
*
kekka: autoexec.bat

C:\>type autoexec.bat
REM Dummy file for NTVDM
　そういうものだったんだ。

>オプションの数値をいじれば落とせるようになるかなぁ。
　落とせない悩み（笑）
　ＸＰのntvdmが、ある意味優秀になったということなのかな？

>すぐに引っ張り出せる古い環境というと、WinXPしかありませんでした。
>command.comを呼び出すと80x25に縮んでしまう。これ、command.com直呼び出し
>でもこのサイズ。どうやれば80x50にできるかわからない。
　ＸＰでvtdosを使用していないばあい、25行にしかなれない、というのがＸＰ
の仕様だったんではなかったでしたっけ？

#F &z("xxx") >*

　はい、WinXP with command.com	落ちません
　はい、WinXP with vtdos	落ちます

　konno版（k07t, 旧版）＋ＥＭＳあり。

http://mezala.la.coocan.jp/bbs/upload/clip.cgi?
　ＸＰでも色々と無理すれば、できなくはなかったのですね。
　僕は荒野に一人で足を踏み入れないタイプなのだった。

とりあえず、自分のところにつけます。

みなさんの発言から、落ちる／落ちないを拾って表にしてみました。

       発言 試験          常駐   画面      
報告者 番号 方法 結果     有無   サイズ 環境         VzVer
konno  8314 SORT 落ちる   ?      ?      VTDOS        ?
konno  8342 SORT 落ちない ?      ?      DOS窓(?)     ?
konno  8342 SORT 固まる   常駐   ?      VTDOS        榊原版
konno  8342 SORT 落ちない 非常駐 ?      VTDOS        榊原版
konno  8375 &z   落ちる   ?      ?      VTDOS        ?
konno  8375 &z   落ちない ?      ?      DOS窓(?)     ?
文太   8381 &z   落ちる   ?      ?      純DOS(6.2?)  ?
文太   8391 &z   落ちる   ?      ?      純DOS(6.2?)  ?
文太   8391 &z   落ちる   ?      ?      DOS窓(WinME) ?
10#    8393 &z   落ちる   ?      ?      VTDOS        ?
konno  8400 &z   落ちない ?      ?      DOS窓(?)     ?
文太   8402 &z   落ちる   ?      ?      DOS6.2       ?
としき 8408 &z   落ちない 非常駐 80x50  DOS窓(Win7)  1.60t03k
文太   8409 &z   落ちる   常駐   ?      DOS6.2       k07t
文太   8409 &z   落ちる   非常駐 ?      DOS6.2       k07t
文太   8416 &z   落ちる   常駐   80x25  DOS窓(Win7)  ?(k07t)
文太   8416 &z   落ちる   常駐   80x30  DOS窓(Win7)  ?(k07t)
文太   8416 &z   落ちる   非常駐 80x25  DOS窓(Win7)  ?(k07t)
文太   8416 &z   落ちる   非常駐 80x30  DOS窓(Win7)  ?(k07t)
konno  8418 ?    落ちる   ?      80x25  DOS6.2       ?(k07t)
としき 8421 &z   落ちない 常駐   80x25  DOS窓(WinXP) 1.60t03k
としき 8421 &z   落ちない 非常駐 80x25  DOS窓(WinXP) 1.60t03k
文太   8422 &z   落ちない ?      80x25  DOS窓(WinXP) k07t
文太   8422 &z   落ちる   ?      80x25  VTDOS        k07t
としき 8426 &z   落ちない 常駐   80x50  VTDOS122     1.60t03k
としき 8426 &z   落ちない 非常駐 80x50  VTDOS122     1.60t03k

純DOSは80x25と決め打ちさせていただきました。
V-TEXT使っていたらごめんなさい。
また、間違っている部分があれば、それもごめんなさい。併せて、私が見落として
いる部分や、不明で「?」としている部分を補完していただけると助かります。

この表を一見してわかることは、いろんなOSや画面サイズで事象が発生していると
いうこと。一方で、報告者に偏りがあるところが弱点ではありますが、高橋版では
全く落ちていないという状況があります。
やはりこれ、Vzのバージョンとか各人のvz.defでのオプション設定が影響している
可能性があるのではないかなぁ。

>ということが明確になりそうです。
>ならない可能性も高いけど。
　ならなかったと思う。

　全て非常駐です。

・93年版Vzと93年版DEFでDOS6.2	落ちる
・konno版Vzと93年版DEFでDOS6.2	落ちる（０除算）k03t3（まだ、、、）
・93年版Vzと文太常用DEFでDOS6.2	落ちる		５つエラー。Nf,dw,色３つ

> 　ならなかったと思う。

そんな感じですね。
でも、今まで誰からも報告がなかったことが報告されるということは、解決できる
かどうかは別として、少なくとも解決の方向に１歩進んだことは間違いない。
誰かのせりふで
「失敗したということも大切な成果」
というようなのがありましたよね。

あと、

> ・93年版Vzと93年版DEFでDOS6.2	落ちる

これがわかったことは、私にとっては大収穫。
なぜなら、現状の私は落ちない環境を持っているわけなので、比較すれば、どこ、
または何が悪いか、絞り込める可能性があるというわけで。
もちろん、スキルその他の問題で、絞り込めない可能性のほうが高いのですけど。
あともう一つ、ある意味で純粋な環境で落ちたということは、エミュレーション
環境であるVTDOSでも落ちる必要がある、ということを意味すると思うのですが、
この私の解釈であっていますでしょうか。

えと、確認ですが、DOS6.2で落ちるということは、リセットが必要になるという
ことでよろしいですよね。EMMあたりがエラーをはくか、単に黙ってフリーズする
か、そのあたりは別として。なぜ、それほど特殊とも思えないような設定による
不具合が今まで発覚しなかったのか、というのも不思議な気はします。

とりあえず、私が次にできることは、落ちる環境探しです。
がんばってみましょう。

> どうも再現性が不安定なんですが、落ちそうなマシンに当たりました。

う〜ん、どうもよくわからん。
もしかしたら、ハードウェアの問題も絡んでくるのかも。
とりあえず、途中経過。

試験方法としては、DOS窓、またはVTDOS122窓を開き、対象Vzのあるディレクトリ
をカレントにして、誤って別のDEFファイルを読まないようにしました。そして、
Vzを起動し、存在しないファイルを&zで呼ぶマクロのファイルをオープン。^K^で
読み込み。そのまま、そのマクロファイルを開いた状態で、新規ファイルを開く
窓と検索窓でファンクションキーから呼び出し、というもの。
マシンについては、２台のWinXPマシンで行いました。
１台は、VTDOS122の入っていたマシン、富士通の一体型デスクトップです。
もう１台はVz k08q2の入っていたマシン、東芝のノートです。
なお、DEFファイルは、93年版のCOMファイルには93年版のDEFファイルを、その他
はそれぞれ同じディレクトリに入っていたものを使っております。


さて、結果です。

       試験          常駐   画面      
マシン 方法 結果     有無   サイズ 環境         VzVer
Note   &z   落ちない 両方   80x25  DOS窓(WinXP) 931206
Note   &z   落ちる   両方   80x25  DOS窓(WinXP) 1.60t03k
Note   &z   落ちる   両方   80x25  DOS窓(WinXP) k08q2

DskTop &z   落ちない 両方   80x25  DOS窓(WinXP) 931206
DskTop &z   落ちない 両方   80x25  DOS窓(WinXP) 1.60t03k
DskTop &z   落ちない 両方   80x25  DOS窓(WinXP) k08q2

DskTop &z   落ちない 両方   80x50  VTDOS122     931206
DskTop &z   落ちない 両方   80x50  VTDOS122     1.60t03k
DskTop &z   落ちない 両方   80x50  VTDOS122     k08q2


う〜ん、これは。
VTDOS122はロバストだから、Vzがどんなバージョンでも落ちないのかもしれない
けど。でも、Vzのバージョンによって落ちるか否かが決まる、という私の仮説は
もろくも崩れ去りました。あ、落ちないというのも、単に落ちないというだけで
あって、画面は乱れまくるので、一旦コマンドラインに抜けるなりしてから編集
画面に戻る必要はあります。
でも、私の環境では、オリジナルバージョンが、なかなか落ちない。
文太さんのところでは簡単に落ちたようだし、konnoさんのところでも落ちている
のですよね。そうすると、やっぱりハードウェアの関係もあるのかも。

新しく話が出てきたのは、疑似VRAMの位置ですか。
あとで、それぞれの環境で調べてみます。

> > 高橋版では落ちていないという報告は見てないような気がします。
> 
> そうですか、それは申し訳ありません。
> #8430の表も含め、今まで何回も書いた「1.60t03k」というのは高橋版のつもり
> だったのですが、99年12月19日版というのは高橋版ではなかったようです。
> 大変失礼しました。

あう、す、すみません、私が見落としていただけでした。m(__)m
こちらこそ大変失礼いたしました。
ごめんなさい。m(__)m


> > SORT では、私の手持ちの主なVZを全て試したので、高橋版も駄目だったです。
> 
> ごめんなさい。
> 今度は逆に、私のほうがその報告を見落としていたようです。
> 何番の発言に掲載されておりますでしょうか。
> あの表に追記したいと思っておりますので、発言番号を教えてください。

試したのは、#8342 です。

> SORT.DEF（高橋版）を色々な環境で試してみました。

> ここからは、SCASB_MODE=0 のVTDOS環境です。
> 
> ・VZS 榊原版VZ
> 常駐ではソート実行時に固まった。
> 非常駐では動いた。何で？
> 
> ・その他のVZは皆駄目でした。
> 　なお、非常駐VZだと、エラーになってもVZが落ちるだけで
> 　VTDOSは動き続けますね。

このように書いたので、これではわからないですよね。
事象を正確に伝えるのも把握するのも難しいものだと改めて思いました。


ところで、私も思い込みで書いてしまったのは、#8430 の記事で

> この表を一見してわかることは、いろんなOSや画面サイズで事象が発生していると
> いうこと。一方で、報告者に偏りがあるところが弱点ではありますが、高橋版では
> 全く落ちていないという状況があります。
> やはりこれ、Vzのバージョンとか各人のvz.defでのオプション設定が影響している
> 可能性があるのではないかなぁ。

ここを読んで、あれ？　と思ったからですが、私が高橋版と書かなかったのと逆に、
としきさんは、高橋版でテストしていたんですね。

#8416 の文太さんの環境は、Win7のDOS窓ではなくてWinMEのDOS窓だと思ったのですが。
つまり、私が読み間違えていなければ、NT系のDOS窓ではどのVZも落ちないという認識です。


VTDOS122 では、&z テストが落ちないんですね。
それで、過去ログを見てみたら、#6582 で

> 20100326 0125	REP MOVSB セグメントラップアラウンド修正・LHA対応
> 20100123 0122	ストリング命令セグメントラップアラウンドチェック不具合修正
> これで、もしかして、と思い、VTDOS Ver121 でSORT.DEFを試してみたら
> 無事に動きましたよ。

とありました。
この辺のVTDOS は何かが違うのかもですね。

>#8416 の文太さんの環境は、Win7のDOS窓ではなくてWinMEのDOS窓だと思ったのですが。
>つまり、私が読み間違えていなければ、NT系のDOS窓ではどのVZも落ちないという認識です。
　konnoさんが正しいです。僕は見落としてました。

>それで、過去ログを見てみたら、#6582 で

>> 20100326 0125	REP MOVSB セグメントラップアラウンド修正・LHA対応
>> 20100123 0122	ストリング命令セグメントラップアラウンドチェック不具合修正
>> これで、もしかして、と思い、VTDOS Ver121 でSORT.DEFを試してみたら
>> 無事に動きましたよ。

　す、すごい。執念。

V-TEXTは環境によって実装が異なり、疑似VRAMの割り当て位置も違っていると思われますが、
それらの情報を表示するVTI.EXEというソフトが存在します。
VTDOSでは以下のような表示になります。

ttps://www.vector.co.jp/soft/dos/hardware/se012553.html

VTI.EXE Version 1.10  (c)鯖/LP-Project,1994.

--- BIOS ($Disp.sys) ---

Video Mode          70h
Screen Size         127x62
Int 10h Vector      FFFF:0060h
DOS/V $Disp.sys     Installed.
$IAS.sys            Installed. (Not Active.)
Psuedo Text Buffer  F800:0000h
Buffer Size         7B08h (31496 Bytes)

EGA Palette  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Ovr
            00h 01h 02h 03h 04h 05h 06h 38h 07h 09h 12h 1Bh 24h 2Dh 36h 3Fh 00h

--- DOS/V Extension Info. ---
Not Supported.

> V-TEXTは環境によって実装が異なり、疑似VRAMの割り当て位置も違っていると思われますが、
> それらの情報を表示するVTI.EXEというソフトが存在します。
> VTDOSでは以下のような表示になります。

おお、これがありましたね。
DOS窓では、V-TEXT が無いので、v.com というもう一つのソフトと
両方表示させてみました。


vv	; ====== Win10 DOS窓 ======
V - Video mode information
    R1.0  (C)ChaN,1993

Current Video Mode = 03h
Screen Size        = 80x28
Character Height   = 14
VRAM Mode          = A/N
VRAM Address       = B800:0000 (Real VRAM)

vti
VTI.EXE Version 1.10  (c)鯖/LP-Project,1994. 

--- BIOS ($Disp.sys) ---

Video Mode          03h
Screen Size         80x28
Int 10h Vector      08BE:0A11h
DOS/V $Disp.sys     Not Installed.   (Int 7Dh not Defined!)
$IAS.sys            Not Installed.
Psuedo Text Buffer  --- None ---
Buffer Size         1180h (4480 Bytes)

EGA Palette  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Ovr
            00h 01h 02h 03h 04h 05h 14h 07h 38h 39h 3Ah 3Bh 3Ch 3Dh 3Eh 3Fh 00h

--- DOS/V Extension Info. ---
Not Supported.


; ====== MSDOS Player ======
vti
VTI.EXE Version 1.10  (c)鯖/LP-Project,1994. 

--- BIOS ($Disp.sys) ---

Video Mode          03h
Screen Size         120x32
Int 10h Vector      08EC:0A11h
DOS/V $Disp.sys     Installed.
$IAS.sys            Installed. (Active.)
Psuedo Text Buffer  F800:0000h
Buffer Size         2000h (8192 Bytes)

EGA Palette         --- Not Supported ---

--- DOS/V Extension Info. ---
Not Supported.


; ===== Win10 VTDOS =======
VTDOS|C:\VZ>vti
VTI.EXE Version 1.10  (c)鯖/LP-Project,1994. 

--- BIOS ($Disp.sys) ---

Video Mode          70h
Screen Size         126x33
Int 10h Vector      16AA:0A11h
DOS/V $Disp.sys     Installed.
$IAS.sys            Installed. (Active.)
Psuedo Text Buffer  F800:0000h
Buffer Size         40F8h (16632 Bytes)

EGA Palette  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Ovr
            00h 01h 02h 03h 04h 05h 06h 38h 07h 09h 12h 1Bh 24h 2Dh 36h 3Fh 00h

--- DOS/V Extension Info. ---
Not Supported.


こうして見ると、VTDOS だけ、Video Mode 70h と認識されてますね。
これが何か関係しているのだろうか。


VTDOS121 落ちない

VTI.EXE Version 1.10  (c)鯖/LP-Project,1994. 

--- BIOS ($Disp.sys) ---

Video Mode          70h
Screen Size         100x40
Int 10h Vector      FFFF:0060h
DOS/V $Disp.sys     Installed.
$IAS.sys            Not Installed.
Psuedo Text Buffer  D000:0000h
Buffer Size         3E80h (16000 Bytes)

EGA Palette  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Ovr
            00h 01h 02h 03h 04h 05h 06h 38h 07h 09h 12h 1Bh 24h 2Dh 36h 3Fh 00h

--- DOS/V Extension Info. ---
Not Supported.


VTDOS124　落ちない

BREAK=1
;PASTEDELAY=10
;USECMD=1
;TPAEXT=1
TPALOW=1

VTI.EXE Version 1.10  (c)鯖/LP-Project,1994. 

--- BIOS ($Disp.sys) ---

Video Mode          70h
Screen Size         80x25
Int 10h Vector      FFFF:0060h
DOS/V $Disp.sys     Installed.
$IAS.sys            Not Installed.
Psuedo Text Buffer  D000:0000h
Buffer Size         1F40h (8000 Bytes)

EGA Palette  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Ovr
            00h 01h 02h 03h 04h 05h 06h 38h 07h 09h 12h 1Bh 24h 2Dh 36h 3Fh 00h

--- DOS/V Extension Info. ---
Not Supported.


VTDOS125　落ちる

VTI.EXE Version 1.10  (c)鯖/LP-Project,1994. 

--- BIOS ($Disp.sys) ---

Video Mode          70h
Screen Size         80x25
Int 10h Vector      FFFF:0060h
DOS/V $Disp.sys     Installed.
$IAS.sys            Not Installed.
Psuedo Text Buffer  FC00:0000h
Buffer Size         1F40h (8000 Bytes)

EGA Palette  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Ovr
            00h 01h 02h 03h 04h 05h 06h 38h 07h 09h 12h 1Bh 24h 2Dh 36h 3Fh 00h

--- DOS/V Extension Info. ---
Not Supported.


VTDOS.CFG を、124に合わせても落ちる

VTI.EXE Version 1.10  (c)鯖/LP-Project,1994. 

--- BIOS ($Disp.sys) ---

Video Mode          70h
Screen Size         80x25
Int 10h Vector      FFFF:0060h
DOS/V $Disp.sys     Installed.
$IAS.sys            Not Installed.
Psuedo Text Buffer  D000:0000h
Buffer Size         1F40h (8000 Bytes)

EGA Palette  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Ovr
            00h 01h 02h 03h 04h 05h 06h 38h 07h 09h 12h 1Bh 24h 2Dh 36h 3Fh 00h

--- DOS/V Extension Info. ---
Not Supported.


VTDOS124までは落ちなくて、125 以降は落ちるようです。
何が違うかは、わかりません。

XPのNTVDMはDOS/V相当でした。
疑似VRAMはアッパー領域に取っているため、例の現象が発生しても落ちません。

VTI.EXE Version 1.10  (c)鯖/LP-Project,1994.

--- BIOS ($Disp.sys) ---

Video Mode          03h
Screen Size         80x25
Int 10h Vector      0617:19D3h
DOS/V $Disp.sys     Installed.
$IAS.sys            Not Installed.
Psuedo Text Buffer  D853:0000h
Buffer Size         1000h (4096 Bytes)

EGA Palette  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Ovr
            00h 01h 02h 03h 04h 05h 14h 07h 38h 39h 3Ah 3Bh 3Ch 3Dh 3Eh 3Fh 00h

--- DOS/V Extension Info. ---
Not Supported.

> このサンプルだけに関して言うと、VTDOSがセグメントラップアラウンドを
　致命的エラーにしてる、というだけのことだと思います。

なるほど、納得です。

> Win10のNTVDMはDOS/V相当では無く、CGAとして扱ってるようですね。あるいはJEGA？

JEGA ってなんだっけ？　と思ったら、昔のAXの規格ですか。
基本は、CGA なのかなとは思います。

関係ない話ですが、Win10の64ビット版にVTDOS導入するときに、漢字の片割れ
半角分しか表示しなくて、焦ったことがあります。
フォントの設定がなかなか入らないんですよ。

> MS-DOS/Vのサンプルがあれば、それが落ちる理由がはっきりするかも知れません。

MSDOS6.22 の DOSモバで試してみました。メモリカードのデータ移動が大変でした。

A:\DOS>A:\UT\VTI.EXE
VTI.EXE Version 1.10  (c)鯖/LP-Project,1994. 

--- BIOS ($Disp.sys) ---

Video Mode          70h
Screen Size         80x15
Int 10h Vector      097C:37F0h
DOS/V $Disp.sys     Installed.
$IAS.sys            Not Installed.
Psuedo Text Buffer  0AA1:0000h
Buffer Size         0960h (2400 Bytes)

EGA Palette         --- Not Supported ---

--- DOS/V Extension Info. ---
Not Supported.


DOSモードの初期状態では、VZIBMJ.COMは表示が異常で動作しません。

A:\DOS>vv
V - Video mode information
    R1.0  (C)ChaN,1993

Current Video Mode = 03h
Screen Size        = 40x25
Character Height   = 0
VRAM Mode          = A/N
VRAM Address       = B800:0000 (Real VRAM)

確かこんなだったような。
英語版VZは動くだろうか。

> Video Mode          70h
> Screen Size         80x15
> Int 10h Vector      097C:37F0h
> DOS/V $Disp.sys     Installed.
> $IAS.sys            Not Installed.
> Psuedo Text Buffer  0AA1:0000h
> Buffer Size         0960h (2400 Bytes)

ディスプレイドライバーのロードアドレスは不明ですが、エントリーポイントが097c:37f0hで、
疑似VRAMが0AA1:0hとなってますね。
ディスプレイドライバーが自分自身のロードアドレスの直後に疑似VRAMを配置してると思われます。
TPAがどこからスタートしているかは不明ですけど、このセグメントのオフセット0FFxxh付近に書き込みが
行われれば何らか問題が生じるんじゃ無いですかね？
これの VMAP は見れますか？

> ディスプレイドライバーのロードアドレスは不明ですが、エントリーポイントが097c:37f0hで、
> 疑似VRAMが0AA1:0hとなってますね。
> ディスプレイドライバーが自分自身のロードアドレスの直後に疑似VRAMを配置してると思われます。
> TPAがどこからスタートしているかは不明ですけど、このセグメントのオフセット0FFxxh付近に書き込みが
> 行われれば何らか問題が生じるんじゃ無いですかね？
> これの VMAP は見れますか？

ちょっと長いですが

A:\DOS>Vmap 
VMAP Version 2.01  Copyright (C) 1989-91 by c.mos

addr PSP  blks   size  owner/parameters           hooked vectors
---- ---- ---- ------  -------------------------  -----------------------------
D403 sys    1   11376  cardlite                   1A
D6CC sys    1   11184  sramata
D989 sys    1    4640  power                      13 14 17 25 26 28 2A 6C
DAAD sys    1    4080  kkcfunc
DBAD        1     112  <free>
DBB5 <--    1    2192  dblpatch
DC3F-DCFE   1    3056  <free>
E003 sys    1    3072  apmexdrv
E0C5 sys    1    1552  sounddrv
E128 sys    1    3680  ssricoh
E210 sys    1   34976  dblspace
EA9B ED25   1     112  unstick (env)
EAA3 <--    1   10256  keyb JP,932,J:\DOS\KEYBOA
ED25 <--    1    6928  unstick                    0F 33 81
EED7 EEDF   3     736  setpow
EF08 <--    1     720  dkick                      09
EF36        1     112  <free>
EF3E <--    1    1008  cmfctrl                    84
EF7E-F000   1    2080  <free>
                       --- UMB total: 100 KB ---
0271 sys    1    1104  himem
02B7 sys    1    2688  ramdrive
0360 sys    1   10416  emm386                     4B 67
05EC sys    1    4592  unfont
070C sys    6    5312  <config>
085E <--    3    4240  command                    22 23 24 2E
096A        1     256  <free>
097C <--    1   18480  mogd -v4                   10 15 16 7D
0E00 <--    1    3088  pansi                      2F
0EC2 <--    1    3888  vz 1.60t -z                1B 21 29
0FB6-9FFF   1  590992  <free>

----- EMS ver4.0 (frame: C000h) -----       ----- XMS ver3.00 -----
handle pages   size  name                   HMA used: 63 KB by DOS
------ ----- ------  --------               EMB free: 106 KB
     1     6    96k  VZ
  free    32   512k
 total    38   608k


DOSモバのディスプレイドライバーはいくつかありますが
ここでは、MOGD.COM というのを使っています。
入力窓などでのキー入力に若干問題があって、常用するには難があります。
今回&zテストではすぐに落ちず、ファイルクローズでEMM386エラーが出ました。