[HOME]  [リストへもどる]
一括表示

  EMSテストマクロ - 文太 18/12/28-23:50 No.8638
  ┣ Re: EMSテストマクロ - konno 18/12/29-21:59 No.8639
  ┃┗ Re^2: EMSテストマクロ - 文太 18/12/30-12:09 No.8641
  ┃ ┗ Re^3: EMSテストマクロ - konno 18/12/30-14:43 No.8643
  ┃  ┗ Re^4: EMSテストマクロ - 文太 18/12/30-15:41 No.8646
  ┗ EMS_buff.def (0.5) - 文太 18/12/30-23:39 No.8647

(8638) 8638EMSテストマクロ  投稿者:文太   2018/12/28(金) 23:50
   コメント数 2

C:\DEF>vmap
----- EMS ver4.0 (frame: C000h) -----
handle pages   size  name
------ ----- ------  --------
     1     2    32k  for Vwx!
     1     2    32k  for Vwx!
     2     6    96k  VZ		;start

     2     7   112k  VZ		;^NX, sample string saved in EMS (1)
     2     7   112k  VZ		;^NY, sample string read & written to PR
     2     6    96k  VZ		;^N\Y, test EMS page closed (2)

 ※(1)から(2)までたどり着くのに、あいだ3時間あったら、5時間あったら
(もちろんVzをふつうに継続使用している)大丈夫なのか。途中不具合を誘発
しないか、(2)はふつうに行えるのか。これが課題です。

 できたような気がします。
 ただ、あくまで習作、テスト用です。

 EMSを保存バッファとして使えるのか、のテストです。
 たぶんできないと思う。思わぬ不具合に遭遇することになるのだと思う。

 発想はこうです。マクロバッファはあくまで一時的な保存バッファで、もっと
恒久的な(Vzが起動している間、僕の場合には常駐している間)バッファが欲
しい。 かつて konno さんに「1kbuf.com 113 2007-01-06 01:30」なんてのを作
ってもらったのですが(たぶんこっちに行くのだけど)、使うの大変なバッファ
でして、Vz標準の EMS 操作関数ではダメでしょうか? ということです。

 僕が悲観的なのは、ずっとこのEMSページをVzが管理してくれるのか、
ということ。どうなんでしょうか。このページを外してVzは自分のためにEMS
を使ってくれるのでしょうか? 前例がないような気がするのです。
 EMSをバンバン使っているマクロは高橋さんのマクロ。でも、マクロが終了
したら、そのEMSページ解放してるのね。保存バッファではなく作業バッファ
なんですね。
 というわけで、たぶん、失敗するのでしょう。

 お暇な方は改造するなりして、お使いください。あくまでテストとして。
 「こりゃまずいでしょう」という明らかなバグがあったらお教えてください。
 発想がまずいのなら、それも、どうか。

 しばらく自分でテストするつもりなので、即レスはないと思います。


 マクロの注意点。
 (1)キーアサインが僕のもののままです。読み出しとEMSの解放のほうは、
シフト起動です。

 (2)Bv256 前提です。EMSセグメント、ハンドル、文字列長を保存しておく
バッファがVzのお腹の中に必要です。
    消えないバッファは、こうとでもするしかないと思う。消えないバッファの
ための消えないバッファ。

 (3)高橋版の書式制御を使っています。konno 版でなにも問題ありません。


 メリークリスマス(遅いよ)&ハッピーニューイヤー 2019



=== EMS_buff.def by Bunta ===;
#if0
EMSに文字列を保存するテスト。
Bv (logtbl) 256 前提。
pq..145+128以降の6バイトを恒久的保存バッファとして使用
(中身は保存文字列長、EMSハンドル、EMSセグメント)
★カスタマイズが必要なのかもしれない箇所。
#endif

* Macro
50 ^NX "EMS_buff"

	;--- sample string & its length
        p="abcあdefいghiうjkelmnopqrstuvwxyz0123456789",	;<p>
        &Sn(p) l=r,						;<l>

	a=pq..145+128,			;Bv personal buffer★
					;upto +126, already used by hometext.def

	;--- save EMS info
        &Ea(1) 		a..0=r,		;EMS allocation, EMS handle 	<a..0>
        &Em(a..0) 	a..1=r,		;EMS mapping,    EMS segment	<a..1>
			a..2=l,		;strlen				<a..2>

	;--- memcopy prep
	ax=gz, si=p, cx=a..2,		;set source
	bx=a..1, di=0,			;set destination

	;--- iseg memcopy
	;str_cpy; ax,si -> bx,di, cx times

	&i("$(50,1F,53,07,F3,A4,C3)")

        &m("string <p> written on EMS; handle %d",a..0) .

;------------------------------------------------------------

51 ^NY "fromEMS"

	a=pq..145+128,			;Bv personal buffer
					;to +126, already used by hometext.def

	(ks&1)? >a			;Close EMS page by shift

        &Em(a..0)			;EMS mapped with handle (a..0)

	;--- memcopy prep
        ax=a..1, si=0, cx=a..2,		;set source
        bx=gz, di=pr,			;set destination

	;--- iseg memcopy
	;str_cpy; ax,si -> bx,di, cx times

	&i("$(50,1F,53,07,F3,A4,C3)")

        &m("%*s, read from EMS",a..2,pr) .		;hiro Vz


 :a 	;--- Del EMS buffer ---

        &Ef(a..0)			;close EMS
        &m("EMS buffer closed. Handle %d",a..0) .

*


      - No.8638 -    このTreeへ           [リストへもどる] pre

(8638) 8639Re: EMSテストマクロ  投稿者:konno   2018/12/29(土) 21:59
    8638 番 文太 さんへのコメント    コメント数 1

文太さん、やってますね。(^_^)

> 恒久的な(Vzが起動している間、僕の場合には常駐している間)バッファが欲
> しい。 かつて konno さんに「1kbuf.com 113 2007-01-06 01:30」なんてのを作
> ってもらったのですが(たぶんこっちに行くのだけど)、使うの大変なバッファ
> でして、Vz標準の EMS 操作関数ではダメでしょうか? ということです。

1kbuf.com のような外部メモリ方式は使うのが大変でしたか。
VZ起動中という事なら、VZ.DEF など、インクルードマクロで直に自前バッファ
が良さそうな気が。
問題はサイズですね。どのくらい要るのだろう。

あ、私はEMSはわからないので、テストはパスします。(^^;


      - No.8639 -    このTreeへ    コメント元:8638 へ [リストへもどる] soft

(8638) 8641Re^2: EMSテストマクロ  投稿者:文太   2018/12/30(日) 12:09
    8639 番 konno さんへのコメント    コメント数 1

>文太さん、やってますね。(^_^)
 はい、ちょっとだけですが。m(__)m

>1kbuf.com のような外部メモリ方式は使うのが大変でしたか。
 データ受け渡しのインターフェイスとデータ構造が問題で、素性が全部
分かっているぶん、1kbuf.comのほうが長い目でみて、安心安全なのですが、
ブラックボックスになるインターフェイス部分が、けっこう複雑で、、、。
 ま、そちらに落ち着くのだろうとは思っていますが。

>VZ起動中という事なら、VZ.DEF など、インクルードマクロで直に自前バッファ
>が良さそうな気が。問題はサイズですね。どのくらい要るのだろう。
 はい。まさしくそのとおりです。
 問題は、サイズ。どれだけ必要なの? というのがクルーシャルなところ。
 Bv256(vzlogはもちろん使わず)で、ぜんぜん足りなそうだというので、
 (1)徹底自己管理の2文字変数(バッファ本体は外)
 (2)インクルードマクロ(バッファ本体含む)
 というラインの延長で、とりあえずEMSを攻めてみることにしました。

>あ、私はEMSはわからないので、テストはパスします。(^^;
 いえいえ、何が起こるのか分からない実験ですから。
 「そういえば、あれはとってもやりたかったことだ」と思い出して、現実
逃避が主な目的で書いてみただけです。

      - No.8641 -    このTreeへ    コメント元:8639 へ [リストへもどる] soft

(8638) 8643Re^3: EMSテストマクロ  投稿者:konno   2018/12/30(日) 14:43
    8641 番 文太 さんへのコメント    コメント数 1

>  Bv256(vzlogはもちろん使わず)で、ぜんぜん足りなそうだというので、
>  (1)徹底自己管理の2文字変数(バッファ本体は外)
>  (2)インクルードマクロ(バッファ本体含む)
>  というラインの延長で、とりあえずEMSを攻めてみることにしました。

ふーむ、データ構造によっては、ファイルに保存するのがいい場合もあるかと
思ったんですが、もっと大変になりそうですね。

例えば、項目別に区切って、変数などのデータ領域とか、マクロ?などを
バッファ丸ごとコピー?する領域とかしておいて
メモリに書き戻す、みたいな感じかなぁ。
(それってVZ.DEF みたいなマクロファイルそのものじゃ?)
オーバーレイ的なものとか?
ファイル方式の利点はサイズが可変長というところですね。


# たぶん大外れだな


      - No.8643 -    このTreeへ    コメント元:8641 へ [リストへもどる] soft

(8638) 8646Re^4: EMSテストマクロ  投稿者:文太   2018/12/30(日) 15:41
    8643 番 konno さんへのコメント

 頭を一緒につかってくださって、ありがとうございます。
 そうなの、そうなのよ、という感じがとってもしました。

>ふーむ、データ構造によっては、ファイルに保存するのがいい場合もあるかと
>思ったんですが、もっと大変になりそうですね。
 「ファイルに書き出す」
 原始的だけど、これが、やっぱり正解中の正解でしょう。
 ほんとに「データ構造によっては」、いちばんいい。マクロも基本コマンド
でいいし。
 その結論みたいなのが、ちょびっとだけハイテクの入った、以下でした。

(再掲:#8154:Fラベル書き換えの意味 by 文太)
;恐ろしく邪悪なツリーだった。
;このマクロを探し出すのに、5分かかった。
;ああいうのは、イケナイ。
=== 009func by B ===;
ファンクラベル・ファイルを開き、ラインバッファに送ってから、
その「文字列」(1行)をファンクラベル領域(pq..100)に送り、
ファンクラベルをオリジナルに戻す。
ファイル名は決め打ち。c:\tmp\funcfile.txt。変更したければどうぞ。
ただし、上 (0fncfile.def)と連動すること。 
* M
50 ^^ "funcback"

	x="c:\tmp\funcfile.txt",
	mx[+,
	#R &?("%s",x) #m		;open funcfile
	#28				;send line to lbuf
	&Sm(pq..100,wa..18,244)
 	pn.4-,                          ;func key label ptr
	#C				;close funcfile
	mx], .

*
 ファンクラベルを書き換えたとき、書き戻しはどうするのか? 
 vz.defから元々読み込まれたメモリ上のオリジナル・ファンクラベルは
書き換えた時点でなくなっているのだから、どっか恒久的な場所に保存して
おかなくちゃいけない。で、ファイルだ、という展開でした。
 (ディスク上のファイルvz.defから再読み込みしたら? 検索が大変なのと、
逆=書き換えファイル用にも使えるから、こうなりました。
 じゃあ、これ、ファイルでなくEMSにしてみたら? うげげげげ。)

 とにかく。
 ね、恒久的データ保存領域って欲しくなるでしょ?
 僕だけかな? でも、何かすると、僕のばあい、必ずこの壁にぶつかって
きたものですから。


># たぶん大外れだな
 ぜんぜん。大当たりですよ。たとえば、そんな巨大保存バッファが使える
となったら、何をしたいのだっけ? とは少しは考えていましたから。
 嬉しいです、話が通じて、「そうそう、それのことなんですよ!」って
感じられるのは。m(__)m

>例えば、項目別に区切って、変数などのデータ領域とか、マクロ?などを
>バッファ丸ごとコピー?する領域とかしておいて
>メモリに書き戻す、みたいな感じかなぁ。
>(それってVZ.DEF みたいなマクロファイルそのものじゃ?)
>オーバーレイ的なものとか?
>ファイル方式の利点はサイズが可変長というところですね。

 上、新鮮で、ビンゴものでした。vz.defみたいなマクロファイルみたいなのが
ファイルの形式にせよ、メモリ上にせよ(1kbuf.com)、EMS上にせよ、取れたら、
使い道あるよなぁ、と思ってます。(注)
 「マクロなどのバッファ丸ごとコピー」。ステキです。
 できる? ほんとに必要? ということは、とりあえず考えないでおきます。(^^)
 あいかわらず夢をみている。
 だから、秀丸にはそうたやすく行けない。本格的にはぜったい行かないことが
決定されておりますが。だから、あのPATA HDの山と格闘しているわけで。

(注)これを追求すると、vz.comが起動時どのような仕組みでvz.defその他のdefを
読み込むのか、ということになる。最終的には、init.asm+core.asmぐらい?
 これまた楽しい夢想。

---------------------------------------------------------------------------
 今回は、大した時間を、VzないしVzマクロに使っているわけではありませんが、
プログラムって、メモリを使う、処理終わったらメモリを解放する、そして自分も消える
という風なのが超基本的姿なんだな、とか考えています。
 それこそ、dosの内部コマンドと外部コマンドみたいに。command.comの常駐部、
非常駐部みたいに。
 僕は、ずっとそこにいて、データを保持しつづけてくれる「常駐もの」みたいなの
を、ずっと前から欲しがっていたんだ、と。
 そして、この行く末が、マルチタスクなんだなぁ、と。インターフェイスは今も
好きではありませんが、Windowsはそれで偉かったんだ、とか。
 ネットワーク関係(インターネット)は、windowsですけどね。

 というわけで、「1kbuf.com」プロジェクトは、僕のVzにとっては、どんぴしゃに
正解だったんだ、と確信しております。多謝でありまする。


 さて、60枚の年賀状です! やれやれ。いつまでも逃げてるんじゃないの!


      - No.8646 -    このTreeへ    コメント元:8643 へ [リストへもどる] pre

(8638) 8647EMS_buff.def (0.5)  投稿者:文太   2018/12/30(日) 23:39
    8638 番 文太 さんへのコメント

 やりたいときにやってしまえ。
 記念に上げます。

 データ構造を少しだけ洗練させた(使うの、それ、ほんとに?)
 バッファを4つに増やした。EMS4ページ。
 きちんと環境管理できるなら、4つのマクロから別々にバッファを使えるはず、
なんだけど……。ヒストリーとか面倒なことなく。1個のデータね、それぞれ。
 こういう風にEMSって使えるのか、テストもまだろくすっぽしてないのにね。
 本質的には、約10年前の1kbuf.comのときと同じことをしています。
 同じところをぐるぐるぐるぐる。このパターンは不変。
 違いは、やっぱりVzマクロを素直に使うと(マシン語にばかり頼らないと)
コーディングが楽です。パパパっとできる。
 あくまでバッファを造ろうとしているだけなんだから、下はみんなブラックボックス
になるのが理想です。


=== EMS_buff.def (0.5) by Bunta ===;
#if0
 習作・部品・テスト用マクロ
 未完成(histcopy system, not yet)--- will you really do that?
  これは別マクロね、するとしても。
 以下は、テストのため、全部の機能を入れてしまってます。実用的には、
EMS情報領域確保、データ領域(EMS)確保
EMS解放
 の2つの間に、データの出し入れのマクロないしマクロ部品が存在するはずです(願望)

EMSに文字列を保存するテスト。
4ページ(16KB*4)の領域を、4つのバッファとして確保する。使いきれるとは思えないが。
Bv (logtbl) 256 前提。
pq..145+128以降の10バイト*4を恒久的管理用データ保存バッファとして使用。
 中身はアイテム個数、全体文字列長、先頭文字列長、EMSハンドル、EMSセグメント
 【データ構造】(a-d)
 a..0:アイテム個数
 a..1:データ全体長
 a..2;先頭文字列長
 a..3:EMS handle
 a..4:EMS frame seg

★カスタマイズが必要なのかもしれない箇所。
 ★1 Vzのお腹の中にあるべきデータ保存バッファ
 ★2 EMSページフレームのアドレス(セグメント)。vmapで調べておく。

二重起動しないようエラーチェックを入れた。
細かいことを書いておくと、文字列コピーとし、最後のヌルも転送することにした。
 その後の処理がこのほうが楽なような気がする。
EMS解放で、Bv管理データバッファもクリアするようにした。

 【to do】
 データの格納はヌル区切り、ヌルヌル末尾のヒストリー形式にすること。
 データ格納・管理が大変になるよ……。
#endif

* Macro
50 ^NX "EMS_buff"

	nn[, oo[, pp[, qq[,

	;--- sample string & its length with ending null
        n="aaaあdefい",			;<n>
        &Sn(n) nn=r+1,			;<nn>, +1 means "with null"
	o="bbbいいい",			;<o>
        &Sn(o) oo=r+1,			;<oo>
        p="cccうdefうx",		;<p>
        &Sn(p) pp=r+1,			;<pp>
	q="dddえええy",			;<q>
        &Sn(q) qq=r+1,			;<qq>

	;--- set Bv data buffer
	a=pq..145+128,		;Bv personal buffer★1 upto +126 (hometext.def)
	b=pq..145+138,
	c=pq..145+148,
	d=pq..145+158,

	;--- check if EMS buff exists or not
	x=$c000,		;<e> EMS frame address★2 各自、事前にチェック設定のこと
	(a..4==x)? {&m("EMS already gotten.") .}


	;-------------------------------------------------------
	;--- save EMS info
			a..0=1,		;item
			a..1=nn,	;all_length
			a..2=nn,	;top_str_length
        &Ea(1) 		a..3=r,		;EMS handle (allocation)
        &Em(a..3) 	a..4=r,		;EMS segment (mapping)

	;--- iseg strcopy (-> EMS)	<x> 4 identifiers, <y> str ptr in gz
	x=a, y=n, &00
        &m("1st string written on EMS(1); handle %d",a..3)
        &p
	;-------------------------------------------------------
			b..0=1,		;item
			b..1=oo,	;all_length
			b..2=oo,	;top_str_length
        &Ea(1) 		b..3=r,		;EMS handle
        &Em(b..3) 	b..4=r,		;EMS segment
	x=b, y=o, &00
        &m("2nd string written on EMS(2); handle %d",b..3)
        &p
	;-------------------------------------------------------
			c..0=1,		;item
			c..1=pp,	;all_length
			c..2=pp,	;top_str_length
        &Ea(1) 		c..3=r,		;EMS handle
        &Em(c..3) 	c..4=r,		;EMS segment
	x=c, y=p, &00
        &m("3rd string written on EMS(3); handle %d",c..3)
        &p
	;-------------------------------------------------------
			d..0=1,		;item
			d..1=qq,	;all_length
			d..2=qq,	;top_str_length
        &Ea(1) 		d..3=r,		;EMS handle
        &Em(d..3) 	d..4=r,		;EMS segment
	x=d, y=q, &00
        &m("4th string written on EMS(4); handle %d",d..3)
        &p
	;-------------------------------------------------------

&m("4 strings written on 4 EMS pages; handle %d,%d,%d,%d",a..3,b..3,c..3,d..3)
	qq], pp], oo], nn],
	.


	;--- strcopy prep		;<x> <y>
00:	ax=gz, si=y, cx=x..2,		;set source
	bx=x..4, di=0,			;set destination
	;--- iseg strcopy
	;str_cpy; ax,si -> bx,di, cx times

	&i("$(50,1F,53,07,F3,A4,C3)")


;----------------------------------------------------------------------------------

51 ^NY "fromEMS"

	a=pq..145+128,	;Bv personal buffer★1 upto +126 (hometext.def)
	b=pq..145+138,
	c=pq..145+148,
	d=pq..145+158,

	;--- check if EMS buff exists or not
	x=$c000,	;EMS frame address★ 各自、事前にチェック設定のこと
	(a..4==x)?? {&m("EMS buffer not exists.") .}

	(ks&1)? >A	;Close EMS page by shift


	;--- copy str from EMS buff to PR

	!01 (r<0)? {&m("canceled.").}
	(r)>? {(x=a)(x=b)(x=c)(x=d)}	;<x>

        &Em(x..3)			;EMS mapped with handle <x..3>

	;--- strcopy prep
        ax=x..4, si=0, cx=x..2,		;set source
        bx=gz, di=pr,			;set destination

	;--- iseg strcopy
	;str_cpy; ax,si -> bx,di, cx times

	&i("$(50,1F,53,07,F3,A4,C3)")

        &m("%s, read from EMS",pr)
	.

 :A 	;--- Del 4 EMS buffers ---

        &Ef(a..3)			;close EMS
        &Ef(b..3)			;close EMS
        &Ef(c..3)			;close EMS
        &Ef(d..3)			;close EMS

	&m("4 EMS buffers closed. Handle %d %d %d %d",a..3,b..3,c..3,d..3)

	;--- clear data buffer, thanx to mezala
        x=40/2,				;data buff/2
        (x){ x--, a..x-, }		;null by 2 bytes
	.

* P
01      "EMS buff str",15,4
        "A 1st string"
        "S 2nd string"
        "D 3rd string"
        "F 4th string"

*


      - No.8647 -    このTreeへ    コメント元:8638 へ [リストへもどる] pre