[HOME]  [全部表示 会議室風]  [全部表示 保存用]  [HOME]  [リストへもどる.] [リストへもどる]

一括表示


異セグマシン語関係 - 文太 07/01/13-14:01 No.2052
ヌル2つを見つける(再び) - 文太 07/01/14-12:10 No.2057
┃┃┣ Re: ヌル2つを見つける(再び) - 文太 07/01/14-13:21 No.2058
┃┃┣ str_len2.def すいません - 文太 07/01/14-17:24 No.2061
┃┃┗ Re^2: ヌル2つを見つける(再び) - としき 07/01/14-18:54 No.2063
┃┃┗ delmemと1kbuf - 文太 07/01/14-23:20 No.2065
┃┗ Re: ヌル2つを見つける(再び) - Konno 07/01/16-00:16 No.2069
┃┗ Re^2: ヌル2つを見つける(再び) - 文太 07/01/16-08:52 No.2071
┃┗ Re^3: ヌル2つを見つける(再び) - Konno 07/01/18-07:26 No.2072
┃┗ Re^4: ヌル2つを見つける(再び) - 文太 07/01/18-12:19 No.2073
┃┃┃┣ delmemなら - 文太 07/01/19-00:20 No.2075
┃┃┃┗ Re: delmemなら - Konno 07/01/22-23:09 No.2078
┃┃┃┗ Re^2: delmemなら - 文太 07/01/23-01:03 No.2079
┃┃┃┣ 追記メモ(PSPなど) - 文太 07/01/23-11:17 No.2081
┃┃┃┃┃┣ MASM6のrepとrepe - 文太 07/01/23-12:06 No.2083
┃┃┃┃┃┗ Re: MASM6のrepとrepe - としき 07/01/23-19:35 No.2084
┃┃┃┃┃┃┗ Re^2: MASM6のrepとrepe - 文太 07/01/23-20:37 No.2085
┃┃┃┃┃┃┗ Re^3: MASM6のrepとrepe - Konno 07/01/23-22:36 No.2088
┃┃┃┃┃┃┃┗ Re^4: MASM6のrepとrepe - 文太 07/01/24-00:13 No.2090
┃┃┃┃┃┃┃┗ Re^5: MASM6のrepとrepe - Konno 07/01/24-01:16 No.2092
┃┃┃┃┃┃┃┗ Re^6: MASM6のrepとrepe - 文太 07/01/25-00:12 No.2103
┃┃┃┃┗ Re: 追記メモ(PSPなど) - としき 07/01/23-21:50 No.2086
┃┃┃┃┣ Re^2: 追記メモ(PSPなど) - 文太 07/01/24-09:28 No.2093
┃┃┃┃┃┗ Re^3: 追記メモ(PSPなど) - としき 07/01/24-19:39 No.2098
┃┃┃┃┃┗ Re^4: 追記メモ(PSPなど) - 文太 07/01/25-00:04 No.2102
┃┃┃┃┃┃┗ Re^5: 追記メモ(PSPなど) - としき 07/01/25-00:46 No.2107
┃┃┃┃┃┃┗ Re^6: 追記メモ(PSPなど) - 文太 07/01/25-01:14 No.2112
┃┃┃┃┣ seinさんのmeuで1kbufの常駐解放! - 文太 07/01/24-14:55 No.2096
┃┃┃┃┗ Re^2: 追記メモ(PSPなど) - としき 07/01/24-21:54 No.2100
┃┃┃┗ Re^3: delmemなら - Konno 07/01/23-22:24 No.2087
┃┃┃┗ Re^4: delmemなら - 文太 07/01/23-23:17 No.2089
┃┃┃┗ Re^5: delmemなら - Konno 07/01/24-01:12 No.2091
┃┃┃┗ Re^6: delmemなら - 文太 07/01/24-09:39 No.2094
┃┃┗ Re^5: ヌル2つを見つける(再び) - Konno 07/01/19-02:01 No.2076
┃┃┗ Re^6: ヌル2つを見つける(再び) - 文太 07/01/19-15:35 No.2077
Buf_Hcpy.def (v.0.5) - 文太 07/01/18-12:28 No.2074
┃┗ やっぱMCBで判断に変更 Buf_Hcpy.def (0.51) - 文太 07/01/24-15:45 No.2097
┃┗ Re: やっぱMCBで判断に変更 Buf_Hcpy.def (0.51) - Konno 07/01/25-00:23 No.2105
┃┗ Re^2: やっぱMCBで判断に変更 Buf_Hcpy.def (0.51) - 文太 07/01/25-01:00 No.2108
┃┣ thanx for buf1k.com & bufxchg.def (debut or prototype) - 文太 07/01/26-00:44 No.2113
┃┃┃┣ Re: thanx for buf1k.com & bufxchg.def (debut or prototype) - 文太 07/01/26-00:55 No.2114
┃┃┗ Re: thanx for buf1k.com & bufxchg.def (debut or prototype) - Konno 07/01/26-01:55 No.2116
┃┃┗ Re^2: thanx for buf1k.com & bufxchg.def (debut or prototype) - 文太 07/01/26-11:12 No.2118
┃┃┗ Re^3: thanx for buf1k.com & bufxchg.def (debut or prototype) - Konno 07/01/27-01:13 No.2119
┃┃┗ Re^4: thanx for buf1k.com & bufxchg.def (debut or prototype) - 文太 07/01/28-00:26 No.2123
┃┃┗ buf1k v0.1をテスト板に - Konno 07/01/29-01:34 No.2126
┃┃┗ Re: buf1k v0.1をテスト板に - 文太 07/01/29-02:05 No.2127
┃┃┣ Re^2: buf1k v0.1をテスト板に - 文太 07/01/29-15:50 No.2129
┃┃┃┃┣ Re^3: buf1k v0.1をテスト板に - としき 07/01/29-22:34 No.2133
┃┃┃┃┗ Re^4: buf1k v0.1をテスト板に - 文太 07/01/30-15:31 No.2140
┃┃┃┃┃┗ Re^5: buf1k v0.1をテスト板に - としき 07/01/30-20:43 No.2143
┃┃┃┃┃┗ Re^6: buf1k v0.1をテスト板に - 文太 07/01/30-22:23 No.2145
┃┃┃┗ buf1k の動作 - Konno 07/01/30-00:19 No.2135
┃┃┃┣ Re: buf1k の動作 - 文太 07/01/30-17:00 No.2141
┃┃┃┃┗ Re^2: buf1k の動作 - としき 07/01/30-21:04 No.2144
┃┃┃┗ Re: buf1k の動作 - 文太 07/01/30-22:38 No.2146
┃┃┃┗ Re^2: buf1k の動作 - Konno 07/01/31-00:17 No.2147
┃┃┃┗ Re^3: buf1k の動作 - Konno 07/01/31-00:42 No.2148
┃┃┃┗ Re^4: buf1k の動作 - 文太 07/01/31-01:54 No.2149
┃┃┃┗ Re^5: buf1k の動作 - としき@会社 07/01/31-13:44 No.2152
┃┃┃┗ Re^6: buf1k の動作 - 文太 07/01/31-18:30 No.2153
┃┃┃┗ Re^7: buf1k の動作 - Konno 07/02/01-00:40 No.2154
┃┃┃┗ Re^8: buf1k の動作 - 文太 07/02/01-11:14 No.2156
┃┃┃┗ buf1k v0.2 - Konno 07/02/02-00:09 No.2157
┃┃┃┣ Re: buf1k v0.2 - 文太 07/02/02-00:56 No.2158
┃┃┃┗ Re: buf1k v0.2 - 文太 07/02/03-14:01 No.2159
┃┃┃┗ buf1k@MASM6 - 文太 07/02/03-21:26 No.2160
┃┃┃┣ Re: buf1k@MASM6 - 文太 07/02/03-22:08 No.2161
┃┃┃┗ Re: buf1k@MASM6 - Konno 07/02/04-00:04 No.2162
┃┃┃┗ Re^2: buf1k@MASM6 - Konno 07/02/04-00:13 No.2163
┃┃┃┗ Re^3: buf1k@MASM6 - Konno 07/02/04-00:32 No.2164
┃┃┃┗ Re^4: buf1k@MASM6 - 文太 07/02/04-01:36 No.2165
┃┃┃┗ [全部表示] はほぼFGAL形式 - Konno 07/02/04-15:09 No.2168
┃┃┃┗ Re: [全部表示] はほぼFGAL形式 - 文太 07/02/04-23:19 No.2175
┃┃┃┗ Re^2: [全部表示] はほぼFGAL形式 - Konno 07/02/05-01:11 No.2177
┃┃┃┗ Re^3: [全部表示] はほぼFGAL形式 - 文太 07/02/05-21:40 No.2183
┃┃┗ Re^2: buf1k v0.1をテスト板に - Konno 07/01/29-23:03 No.2134
┃┃┗ Re^3: buf1k v0.1をテスト板に - 文太 07/01/30-01:40 No.2139
┃┗ Re^3: やっぱMCBで判断に変更 Buf_Hcpy.def (0.51) - Konno 07/01/26-01:37 No.2115
┃┗ buf1k's ID, MCB, meu.comとか - 文太 07/01/26-10:53 No.2117
Dbuf.def (0.80) - 文太 07/01/30-00:47 No.2136
すぐ修正情報m(_b_)m - 文太 07/01/30-01:01 No.2137
Dbuf.def (0.81)  m(__)m - 文太 07/01/30-01:20 No.2138
Dbuf.def (0.82) - 文太 07/01/30-20:13 No.2142
DbufXchg.def (0.80) - 文太 07/01/31-12:25 No.2150
DBufInit.def - 文太 07/01/31-12:33 No.2151
FixedIn & FixedOut - 文太 07/02/01-01:29 No.2155

(2052) 2052異セグマシン語関係  投稿者:文太   2007/01/13(土) 14:01
   コメント数 3


 (勝手なのですが)スレッドを立て直します。m(__)m >all

 1 「文太さぁ、あれはマクロバッファをテスト対象にしてるからじゃない?
君のやりたことからすると、とりあえず、少なくとも今のところは、それ、飛ば
なくてもいいハードルだと思うよ」。はい。

 2 元にもどって、以下でテスト。#F窓で「んんんん b」とやっても問題あ
りません。

 3 少し休んでから、異セグ str_len に進みます。m(__)m
   cの保存は嫌だ!

 4 「何やってんだか?」かもしれませんが、実は、今日、ほとんど初めて、
僕は、個人的に、自分の着実なる進歩を実感してしまいました。
 どうでもいいね、あは。それでも感謝の気持ちは忘れておりません。(いくら
なんでも、そんなにすぐ忘れるものかよ、そもそも。あは2)☆\(^^;)


=== Macro Tmp by Bunta ===;
異セグコピー基本(パクリじゃない!)
* Macro
50 ^^ "mactest"

x=$9FBF, ;dummy buf seg (要1kbuf.com)
(ks&1)? >B

#F &Cr
;===受け渡しは5つ、ax,si,bx,di,cx(c)
;----- writing
;--source
ax=gz, ;ds
si=ps, &Sn(ps) c=cx=r+1,
;--destination
bx=x, ;es
di=0,

&00 .

:B
;----- reading
;--source
ax=x, si=0, cx=c,
;--destination
bx=gz, di=ps,

&00
&m("%s",ps)

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

*

;----- ax (==ds), si, bx (==es), di, cx (length) 受け渡しは5つ
;ds:si -> es:di, cx (bytes to be copied)
push ax
pop ds
push bx
pop es
rep movsb
ret

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

(2052) 2057ヌル2つを見つける(再び)  投稿者:文太   2007/01/14(日) 12:10
    2052 番 文太 さんへのコメント    コメント数 2

 (長文で失礼します)

 以下(マクロ・アサムコード1)を試していただくなり、読んでいただくなり
して、直し方をお教えいただきたいのです。無気味な数字を返してきます。不思
議なことに、いつも 60??? うまくいっていたように見えたことも…???

 名前を変えました。str_len2 です。ヌル2つ発見と str_len の2つ目をかけ
た。いずれにせよ、異セグでヌル2つを検索する、というものです。用途はさす
がに通じているかと思いますが、ヒストリーバッファ終端の発見です。複数の格
納文字列の合計長の計算という意味を持ちます。

 バッファは最初に初期化します(マクロ2)。ヌルだらけ。ここにヒストコピ
ーを繰り返すのですが、すでに2つの文字列が格納されている場合、2つの文字
列の向こうにあるヌル2つを発見し、そこまでの文字列長を取得したうえで、こ
の2つの文字列を新規文字列ぶん後方にずらします。この過程で、文字列長回ぶ
んのコピーが必要になる、というわけです。
 バッファサイズとの比較とは別に、ヌル2つの検索は、ヒストコピーでは常に
なされなければならない測定の一部なのです。(この仕様だと)

 (マクロ3) は、先日のものに str_len ルーチンが加えられたものですが、
そこは今は関係ありません。実地に試したい方のために用意しました。まだヒス
トリー機能はありませんが、 これで 1kbuf のバッファに1つは文字列が転送で
きます(もちろん書き出しもできます)。また 1kbuf.com by としきは、実行フ
ァイルをあざらしに上げます。

 (必要があれば) これで、 僕とまったく同じ環境で実験ができるはずです。
(たぶん、必要ないだろうけど)


 異セグだと駄目なのか? というより、どっかでものすごいタコをやってるだ
けのような気がするのですが、ちょっと長時間の実験でめげまして、救いの手を
求めることにしてしまった次第です。 どうか宜しくお願いいたします。m(__)m
 一晩あけたら何か思いつくかと思ったけど、駄目だった。ああ。
 ほとんど金野さんが書いたままで、マクロバッファでの実験では何ら問題なか
ったのになぁ???


=== Macro Tmp by Bunta ===;
str_len2 test
* Macro
50 ^^ "mactest"

x=$9FBF, ;base buf seg
y=1024, ;buf max length

dx=x, ax=y,

&i("$(52,1F,33,DB,33,F6,39,1C,74,04,46,48,73,F8,C3)")
(ax==y)? {&m("Warning: buffer destroyed.").}
&m("%d",si)

*

str_len2(ヌル2つまでの距離を測定)
; dx = dbuf segment
; ax = バッファサイズ
; si = (出力)文字列長

START:
push dx ;セグメント設定※ ここがいけない???
pop ds ;同※
xor bx,bx ;初期化(ワード)
xor si,si ;初期化(カウンタ)
NEXT:
cmp word ptr [si],bx ;ワードで比較 (ds..0==0)? <--macro語
je FIN ;一致で終了
inc si ;1バイトずつずらす
dec ax ;限界値をデクリメント
jnc NEXT ;限界値に達したら終了。そうでなければNEXT
FIN:
ret

------------------------------------------------------

=== binitial.def by Bunta ===;buffer initialization
* Macro
50 ^^ "binitial"

x=$9FBF, ;dummy buf seg (要1kbuf.com)
y=1024, ;buf max length

cx=y, bx=x,
&i("$(53,1F,33,FF,32,C0,3B,CF,74,05,88,05,47,EB,F7,C3)")
&m("dummy buffer initialized") .

*
push bx ;segment受け渡し
pop ds ;同
xor di,di ;di-,
xor al,al ;al-,
ABC:
cmp cx,di ;(cx==0)?
je FIN
mov [di],al ;
inc di
jmp ABC

FIN:
ret

------------------------------------------------------

=== Macro Tmp by Bunta ===;
;異セグコピー基本2(str_lenが付いたので書き出しの変数依存はない)
;dump -mx9fbf -s16
* Macro
50 ^^ "mactest"

x=$9FBF, ;dummy buf seg (要1kbuf.com)
y=1024, ;buf max length

(ks&1)? >B

#F &Cr (r<0)?.

;===受け渡しは5つ、ax,si,bx,di,cx
;----- writing
;--source
ax=gz, ;ds
si=ps, &Sn(ps) cx=r+1,
;--destination
bx=x, ;es
di=0,
&00 &m("writing finished: %s",ps).


:B
;----- check the buf & get str_length (1)
bx=x, dx=y,
&i("$(53,1F,32,DB,33,F6,8A,04,38,D8,74,04,46,4A,73,F6,C3)")
(si==0) ? {&m("Empty. Cannot write out").}
? {cx=si+1,} ;--

;----- reading (temporarily onto PS)
;--source
ax=x, si=0, ;--
;--destination
bx=gz, di=ps,
&00 ;(2)
&m("%s",ps)

0: &i("$(50,1F,53,07,F3,A4,C3)") ;(2)

*


(source 1; str_len)
;------------------------------
;search 0 in ds:si (<-- ds==bx)
;--> bx (dbuf seg), dx (max)
;<-- si (counter)
START:
push bx ;ds
pop ds
xor bl,bl ;0
xor si,si ;counter
ABC: mov al,[si]
cmp al,bl
je XYZ
inc si
dec dx
jnc ABC
XYZ: ret


(source 2; str_cpy)
;----- ax (==ds), si, bx (==es), di, cx (length) 受け渡しは5つ
;ただしこれは素直に(Vz仕様のまま)cldなので、上書きのみ。histは無理。
;histはstdでお尻から動かすこと。
;ds:si -> es:di, cx (bytes to be copied)
push ax
pop ds
push bx
pop es
rep movsb
ret


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

(2052) 2058Re: ヌル2つを見つける(再び)  投稿者:文太   2007/01/14(日) 13:21
    2057 番 文太 さんへのコメント    コメント数 2

 (大したことではないのですが)ヌル2つの発見に失敗して(バッファサイズ
限界に到達して)マシン語ルーチンから返ってきたことの判定、というつもりの
覚え書きだったのですが、間違ってました。(^^;

(ax==y)? {&m("Warning: buffer destroyed.").}

(ax==-1)? {&m("Warning: buffer destroyed.").}

 また、としきさんの 1kbuf.com は、としきさん掲示板の #870 にあります。
(必要ならば???)そのソースから各自、アセンブルしてください。m(__)m
 あざらしが休業中、僕が上げるのは失礼だろう、などなどに思い至りました。
m(__)m

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

(2052) 2061str_len2.def すいません  投稿者:文太   2007/01/14(日) 17:24
    2058 番 文太 さんへのコメント

 何だかお騒がせだけしています。すいません、ぐすん。

 何も変わっていません。変わったのは、マシンの状態だけです。たぶん。
 でも言い訳ですが、PCの再起動だって昨晩も今朝もさんざんやったのです。
 どうみても前のままで動くはずです。下も名前を付けてコメントを直しただけ。
 str_len2, 完成です(小さい声)。虚しく時間が過ぎたなぁ…。

=== str_len2.def by Bunta ===;
* Macro
50 ^^ "str_len2"

x=$9FBF, ;base buf seg
y=1024, ;buf max length

dx=x, ax=y,

&i("$(52,1F,33,DB,33,F6,39,1C,74,04,46,48,73,F8,C3)")
(ax==-1)? {&m("Warning: buffer destroyed.").}
&m("%d",si)

*

str_len2(ヌル2つまでの距離を測定)
; dx = dbuf segment
; ax = バッファサイズ
; si = (出力)文字列長

START:
push dx ;セグメント設定
pop ds ;同
xor bx,bx ;初期化(ワード)
xor si,si ;初期化(カウンタ)
NEXT:
cmp word ptr [si],bx ;ワードで比較 (ds..0==0)? <--macro語
je FIN ;一致で終了
inc si ;1バイトずつずらす
dec ax ;限界値カウンタをデクリメント
jnc NEXT ;限界値が0に達したら終了。そうでなければNEXT
FIN:
ret

------------------------------------------------------

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

(2052) 2063Re^2: ヌル2つを見つける(再び)  投稿者:としき   2007/01/14(日) 18:54
参照先:http://toshiki.la.coocan.jp/
    2058 番 文太 さんへのコメント    コメント数 1

しつこくて申し訳ないのですが。

>  また、としきさんの 1kbuf.com は、としきさん掲示板の #870 にあります。
> (必要ならば???)そのソースから各自、アセンブルしてください。m(__)m

delmemではいけないのですか?

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

(2052) 2065delmemと1kbuf  投稿者:文太   2007/01/14(日) 23:20
    2063 番 としき さんへのコメント

としきさん

> delmemではいけないのですか?

 うーん、難しいですね。 いけなくないでしょう。でも、delmem はどうなって
いるのか研究・実験しなくてはいけません。MCB が動いてますし。1kbuf は、仕
様がはっきりしています。 「常駐解除できないかわりに、zmap でも名前が消え
てもいいなら 1024bytes まるまる使える」。 すいません、新たな道具に期待し
ておりますし(冗談)、それよりバグとかなんとかより、今は実験段階だし、取
れるバッファの量で、1kbuf を贔屓にさせていただいております。delmem は、
どこまで使っていいか分からないから安全に倒して損をするということです。今
のところの話ですが。
 モバでは delmem になります。ソースが読めて MS-DOS メモリー管理の仕組み
が理解できるまでは、したがって、不幸なことに、取れるバッファの量が減りま
す。m(__)m

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

(2052) 2069Re: ヌル2つを見つける(再び)  投稿者:Konno   2007/01/16(火) 00:16
    2057 番 文太 さんへのコメント    コメント数 1

文太さん

もう完成したのかもしれませんが、このマクロ、使い方がよく判らないので
まだ試してません。1kbuf.com を常駐させてから、マクロ2を実行させ、
それからマクロ1を実行するのでしょうか。

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

(2052) 2071Re^2: ヌル2つを見つける(再び)  投稿者:文太   2007/01/16(火) 08:52
    2069 番 Konno さんへのコメント    コメント数 1

金野さん

 どうぞ、どうぞ試してください。m(__)m
 手順はこうです。

 (1)Vzは常駐外す。
 (2)1kbuf.com起動。Vz起動。
 (3)念のため、dump -mx9fbf -s16でメモリ状態の確認(-s32, -s64でも面白い)。
 (4)マクロ2で初期化。(ダンプでまっさらを確認)
 (5)マクロ3で書き込み。(ダンプで確認)
 (6)マクロ3シフトで読み出し。
 (7)マクロ1で長さが取得できることの確認。

 実験的要素を除くと、実質的な意味があるマクロは、(5)と(6)だけで
す。
 昨晩、ようやくヒストリー機能の骨格部分が完成しましたので、そのうちヒス
トリーつき 1024 バッファマクロに仕上げます。いつか…。取り出し方がまだ…。
ヒストリーが遡れない。

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

(2052) 2072Re^3: ヌル2つを見つける(再び)  投稿者:Konno   2007/01/18(木) 07:26
    2071 番 文太 さんへのコメント    コメント数 1

文太さん

>  どうぞ、どうぞ試してください。m(__)m
>  手順はこうです。

ようやく試すことが出来ました。バッチリ動きました。(^_^)

>  (1)Vzは常駐外す。
>  (2)1kbuf.com起動。Vz起動。

1kbuf や delmem 1u なら、上位メモリに常駐するので、Vzは常駐したままでも
よさそうですね。

>  (3)念のため、dump -mx9fbf -s16でメモリ状態の確認(-s32, -s64でも面白い)。

私は dump を持ってないので debug で確認しました。

>  (4)マクロ2で初期化。(ダンプでまっさらを確認)

ここで気が付いたんですが、delmem で1024バイト確保するというのは、pspも
含めてなんですね。psp が全部ヌルになってビックリしました。(^^;
このままだとモバギではまずいのでは。128バイトずらすとか。

x=$9fc7 ; $9FBF, ;base buf seg
y=896 ; 1024, ;buf max length


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

(2052) 2073Re^4: ヌル2つを見つける(再び)  投稿者:文太   2007/01/18(木) 12:19
    2072 番 Konno さんへのコメント    コメント数 2

金野さん、ありがとうございます。m(_B_)m

> ようやく試すことが出来ました。バッチリ動きました。(^_^)

 よかった。ふう。

> 1kbuf や delmem 1u なら、上位メモリに常駐するので、Vzは常駐したままでも
> よさそうですね。

 なるほど、そういうことか、とやってみました。成功! 当たり前なのでしょ
うが、言われないと分からないもので…。いやあ、これは楽だわい。ずっと、外
して 1kbuf して常駐し直して、をやってました。m(__)m
 だって窓がしょっちゅう落ちるのだもん。アセ。


 で、別件なのですが、少々気になることを発見しました。ここのところ逆アセ
with symdebをやっていないので、まだそっち方面のバッチ連係2窓作戦は進展
がないのですが、 sw3には戻ってます。 で、先ほど、「後から1kbuf」をやって
vmapしてみると、

14BD <-- 1 3888 vz 1.60Q -z 1B 21 29 (1)
15B1 1795 1 1408 command
160A <-- 1 6304 kb16 JP,932,C:\WINDOWS\sy 09 2F
1795 <-- 1 3856 command 22 23 24
1887 <-- 2 194352 キ 1.60Q -z (2)
47FC 1 359440 <free>
9FBF <-- 1 1024

 とメモリが分断状態なのです。もちろん@XPです。(1) は MS-DOS 窓起動と
ともに常駐したVz。(2) は、ファイルをオープンしたときに上がったVzと思
われます。これは、健康な状態なのでしょうか?


> 私は dump を持ってないので debug で確認しました。

 さすが。お、オプションは何ですか?(^^;

 金野さんんなら、その気になれば自分の欲しいものを探せるはずですが、僕が
使っているのは、30行バイオスのlucifer/walkerさんの

http://www.vector.co.jp/soft/dos/util/se002401.html

 です。他にもいっぱいありますねぇ。

> ここで気が付いたんですが、delmem で1024バイト確保するというのは、pspも
> 含めてなんですね。psp が全部ヌルになってビックリしました。(^^;
> このままだとモバギではまずいのでは。128バイトずらすとか。
> x=$9fc7 ; $9FBF, ;base buf seg
> y=896 ; 1024, ;buf max length

 そうだ、そうだ。モバギ用にここの解析をしなくてはいけなかったんだ。FC
BとかDTAとか MS-DOS 用ワークとか…。128 で常駐解除まで行けるかやって
みます。m(__)m


 ついでに(は?)、ヒストリー機能のついた新版を上げておきますね。ダンプ
しないとヒストリーしてるのが分からない、また取り出し時にヒストリーが遡れ
ないので実用性はない、の状態なのですが。でも、常駐チェックはしてくれまー
す。…本当は、もう少し整理できるはずなのだけど…。
 お暇なときにでも。
 次はメニューで出すつもりなので、いつになるやら…。

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

(2052) 2075delmemなら  投稿者:文太   2007/01/19(金) 00:20
    2073 番 文太 さんへのコメント    コメント数 1

 モバでまだ十分な実験はできていないのですが、 以下のように 144 bytes 無
駄(?)にする、というところで常駐解除オプションを生かせます。

x=$9fc8, ;base buf seg
y=880, ;buf max length


0009FBF0 CD 20 FF 9F 00 9A C0 00-00 00 DE 01 95 17 4B 01 |ヘ ...埖...゛...K.
0009FC00 95 17 56 01 95 17 95 17-01 01 01 00 02 FF FF FF |..V.............
0009FC10 FF FF FF FF FF FF FF FF-FF FF FF FF 00 00 0E 05 |................
0009FC20 17 3A 14 00 18 00 BF 9F-FF FF FF FF 00 00 00 00 |.:....ソ.........
0009FC30 05 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |................
0009FC40 CD 21 CB 00 00 00 00 00-00 00 00 00 00 55 31 20 |ヘ!ヒ..........U1
0009FC50 20 20 20 20 20 20 20 20-00 00 00 00 00 20 20 20 | .....
0009FC60 20 20 20 20 20 20 20 20-00 00 00 00 00 00 00 00 | ........
0009FC70 07 64 65 6C 6D 65 6D 0D-66 20 2D 73 32 35 36 0D |.delmem.f -s256.
                              ココ
 きっと標準的なテクニックなのでしょうが、ココをIDにしているようです。
 逆にココまで削ると常駐解除ができなくなります。

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

(2052) 2078Re: delmemなら  投稿者:Konno   2007/01/22(月) 23:09
    2075 番 文太 さんへのコメント    コメント数 1

>  モバでまだ十分な実験はできていないのですが、 以下のように 144 bytes 無
> 駄(?)にする、というところで常駐解除オプションを生かせます。

結構取られるものですね。常駐ソフトによっては全体で数十バイトしか使わないものも
あるので、やり方次第ではもう少し減らせないかと思うんですが、ソースが・・・

文太さん、delmem のMASM6用ソースがまだあるようでしたら、メールでいただけない
でしょうか。自力で改変するのはすぐには出来そうに無いもので。m(__)m

>  きっと標準的なテクニックなのでしょうが、ココをIDにしているようです。
>  逆にココまで削ると常駐解除ができなくなります。

私もこのあたりをいろいろ勉強しようと思っています。

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

(2052) 2079Re^2: delmemなら  投稿者:文太   2007/01/23(火) 01:03
    2078 番 Konno さんへのコメント    コメント数 2

金野さん

>  結構取られるものですね。常駐ソフトによっては全体で数十バイトしか使わな
> いものもあるので、やり方次第ではもう少し減らせないかと思うんですが、ソー
> スが・・・

 まったく同感です。何しろメインメモリーですし、常駐解除が必要とされるの
は、EMSも十分とは言えないドコモバなわけで。
 (余談ですが、その後、このダミーバッファ計画をEMSにごっそり移すこと
も、いちおう考えました。確かに効率的です。無駄がまったくない。ただEMS
の場合はハンドルなどを記憶しておかなければならず、そのために僕などは、ロ
グ履歴のバッファを使うしかない、その管理の仕方もきっちり決めなくちゃなん
だよな、と気づいてしましました。ある意味、決め打ちできる 1kbuf,delmem は
管理が楽です。少なくとも開発環境はこっちがいいですね。)

>  文太さん、delmem の MASM6 用ソースがまだあるようでしたら、メールでいた
> だけないでしょうか。自力で改変するのはすぐには出来そうに無いもので。m(__)m

 了解しました。(またですが)明日、お昼頃までにはお送りします。HDをご
そごそしないといけないのと、ちょっと経緯の意味などを確認したいので。アセ
ンブラをまったく知らずに何やらしてましたので…。(^^;

> >  きっと標準的なテクニックなのでしょうが、ココをIDにしているようです。
> >  逆にココまで削ると常駐解除ができなくなります。
>  私もこのあたりをいろいろ勉強しようと思っています。

 ありがたいです。m(_B_)m

 その後、ちょっとだけもにょもにょしておりますが、うーん、道は険しいです
ね。でも楽しいです。Vzソースの暗号がすこーしずつ意味を持ち始めたりして。
これは嘘だ。m(__)m

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

(2052) 2081追記メモ(PSPなど)  投稿者:文太   2007/01/23(火) 11:17
    2079 番 文太 さんへのコメント    コメント数 2

 少しは頭に入れようと写してみましたが、下手くそで使いものにならん。
 9行目(80h以降)の件だけ、確認しました。

0 1 2 3 4 5 6 7 8 9 A B C D E F
+---------------------------------+ 20h = INT 20h
00h| 20h size call 0005h P終了a ^C | P = Program, a = address
10h| ^C |
20h| 2Ch環境seg| 環境セグメント・アドレス
| |
| |
50h| 21h RETF 拡張FCB |5Ch FCB |
60h| FCB |
70h| (File Control Block) | commandline = ★9行目
80h|文 commandline 0Dh|DTA | コマンドラインのパラメータ文字列
| DTA | 文 = 文字数
略 | (Disk Transfer Address) |
| |
| |
F0h| |
+---------------------------------+
(ナツメ、『システムコール・ハンドブック』p.30より)


0009FBF0 CD 20 FF 9F 00 9A C0 00-00 00 DE 01 95 17 4B 01 |ヘ ...埖...゛...K.
0009FC00 95 17 56 01 95 17 95 17-01 01 01 00 02 FF FF FF |..V.............
0009FC10 FF FF FF FF FF FF FF FF-FF FF FF FF 00 00 0E 05 |................
0009FC20 C7 58 14 00 18 00 BF 9F-FF FF FF FF 00 00 00 00 |ヌX....ソ.........
0009FC30 05 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |................
0009FC40 CD 21 CB 00 00 00 00 00-00 00 00 00 00 55 31 20 |ヘ!ヒ..........U1
0009FC50 20 20 20 20 20 20 20 20-00 00 00 00 00 20 20 20 | .....
0009FC60 20 20 20 20 20 20 20 20-00 00 00 00 00 00 00 00 | ........
0009FC70 07 64 65 6C 6D 65 6D 0D-00 00 00 00 00 00 00 00 |.delmem ★9行目

0009FBF0 CD 20 FF 9F 00 9A C0 00-00 00 DE 01 95 17 4B 01 |ヘ ...埖...゛...K.
0009FC00 95 17 56 01 95 17 95 17-01 01 01 00 02 FF FF FF |..V.............
0009FC10 FF FF FF FF FF FF FF FF-FF FF FF FF 99 58 75 01 |............儿u.
0009FC20 F1 58 14 00 18 00 BF 9F-FF FF FF FF 00 00 00 00 |&#57556;....ソ.........
0009FC30 05 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |................
0009FC40 CD 21 CB 00 00 00 00 00-00 00 00 00 00 20 20 20 |ヘ!ヒ..........
0009FC50 20 20 20 20 20 20 20 20-00 00 00 00 00 20 20 20 | .....
0009FC60 20 20 20 20 20 20 20 20-00 00 00 00 00 00 00 00 | ........
0009FC70 07 31 4B 20 62 75 66 0D-66 20 2D 73 32 35 36 0D |.1K buf.f -s256.
★同じく9行目

 IDは、たぶん、MS-DOS自体が配置したものを、delmemなんかは常駐解除その他
のオプションのために使っているのじゃないかな。
 でも、2つ目では、コマンドラインでは、>1kbufとしているので、としきさんは
何か細工をしてますね。(-s256などはその後のdumpコマンドの文字列ですね。ここ
に入るのが正しいのかどうか? カレントPSPか?)
 IDの位置は動かせるのかな? あるいは、VWXのAPIのように、'1K' or 'DE'と
いった2文字(バイト)だけでのID判定でもいいような…? 我が侭なのか…。



 (参考資料:f_call.shdより)<そういえばYASATさんも作成に協力されてました!
やっぱソース派なんだ。m(__)m

@PSP @プログラムセグメントプリフィクス @Psp  ★
F_関連資料
 PSP プログラムセグメントプリフィクス
  MSDOS は .exe.com をメモリにロードする時,プログ
  ラムセグメントの前に 100h バイトの作業領域を準備
  する。これを PSP(Program Segment Prefix)という。
    +00h dw int20h(プログラム終了)
    +02h dw 使用できるメモリのサイズ
         (割り当てられた MCB の直後のセグメント)
    +04h db 予約
    +05h 05 CALL 0005h用ファーコール(CP/M互換)
    +0Ah dd int22h プログラム終了アドレス
    +0Eh dd int23h <CTRL-C>の抜出しアドレス
    +12h dd int24h 重大エラーの抜出しアドレス
    +16h dw 親プロセス PSP セグメント
    +18h 20 JFT(ハンドル <--> 内部 FCB 対応表)
      0 〜 0FEh:内部 FCB ブロック番号 0FFh:未使用
    +2Ch dw 環境変数のテーブルのセグメントアドレス
    +2Eh dw SP 待避領域
    +30h dw SS 待避領域
    +32h dw ファイルテーブルの数(=14h)
    +34h dd ファイルテープルへのポインタ
    +38h dd 以前の PSP へのポインタ
    +3Ch dd 予約
    +40h dw MS-DOS バージョン(int21_30h 返り値)
    +42h 14 予約
    +50h 03 int 21h,retf
    +53h dw 予約
    +55h 07 拡張FCB
    +5Ch 36 FCB (File Contrl Block)
    +5Ch 16 第1FCB
    +6Ch 20 第2FCB
    +80h 128 DTA (Disk Transfer Address)
    +80h 〜 コマンドライン文字数
    +81h 〜 コマンドライン, 0Dh, DTA・・・・・  ★これが9行目
> FCB ファイルコントロールブロック
> JFT ジョブファイルテーブル
> DTA ディスク転送アドレス
; > MCB メモリコントロールブロック

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

(2052) 2083MASM6のrepとrepe  投稿者:文太   2007/01/23(火) 12:06
    2081 番 文太 さんへのコメント    コメント数 1


日本語
http://support.microsoft.com/kb/120155/ja
英語
http://support.microsoft.com/?scid=kb%3Ben-us%3B120155&x=9&y=14

 別に、こんなことで機械に勝って喜ぼうというのでもないですが。念のため、
事態を正確に把握すべくやってみよう(前回やるべきだった(-_-; とはいえ、
そりゃ、無理だったな)。



【結論】
 解決方法
 OPTION M510 ディレクティブを使用する。あるいは、 REPE 命令プレフィックス
を使用する。

 RESOLUTION
 Assemble using the OPTION M510 directive, or use the REPE instruction
prefix.

--------------------------------------------------------------------------


 現象
 1 REP プレフィックスを使用した string-compare 命令(たとえば REP CMPSB)
をアセンブルすると、次のエラーメッセージが表示されます。

 エラー : 許可されていない命令プレフィックス A2068
 このコードは、バージョン 5.1 の MASM では、エラーなしでアセンブルされ
ます。

 SYMPTOMS
 Assembling a line of code that uses the REP instruction prefix with
one of the string-compare instructions, such as

REP CMPSB

 produces the following error message:
 error A2068: instruction prefix not allowed
 The same line of code assembles without error under MASM version 5.1.

--------------------------

 原因
 REP CMPSB 命令は、MASM5.1 、あるいはMASM 6.xでOPTION M510を指定すると、
REPE CMPSB としてエンコードされます。

 CAUSE
 With MASM version 5.1, as well as when using MASM version 6.x with
OPTION M510, the REP CMPSB instruction is encoded as a REPE CMPSB.

--------------------------

 注:これらの命令の違いは、REPがゼロフラグ(ZF)に関係なくCX 回命令を繰り
返すのに対して、 REPE と REPNEの方は、繰り返しに際してゼロフラグ(ZF)を確
認する点です。 REP CMPSB のためのエンコードは実際上存在しないため(何の
ことだよ?!)、 MASM 6.1 と 6.0 では、エラー メッセージが表示されます。

 NOTE: The difference between these instructions is that the REP
instruction repeats CX times regardless of the zero flag (ZF); however,
the REPE and REPNE instructions check the ZF flag as they repeat.
Because there is virtually no encoding for REP CMPSB, MASM versions 6.0
and 6.1 generate an error message.

--------------------------

 最後にミソがついた感じ。 わかんねーじゃねーかよ。うーん、「repだけが有
意味で、repeで置き換えられない場面はないため」という意味なんでしょうね。


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

(2052) 2084Re: MASM6のrepとrepe  投稿者:としき   2007/01/23(火) 19:35
参照先:http://toshiki.la.coocan.jp/
    2083 番 文太 さんへのコメント    コメント数 1

> Because  there is virtually no encoding for REP CMPSB, MASM versions 6.0
> and 6.1 generate an error message.

う〜ん、virtually はテクニカルタームではないので私には難しいのですが。
例えば、
「REP CMPSBをアセンブルしないことが現実的なので、MASM6.0と6.1では
 エラーメッセージを出力します」
っていうのだとどうでしょうか。

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

(2052) 2085Re^2: MASM6のrepとrepe  投稿者:文太   2007/01/23(火) 20:37
    2084 番 としき さんへのコメント    コメント数 1

> う〜ん、virtually はテクニカルタームではないので私には難しいのですが。

 はい、まず間違いなく、「仮想なんとか」なんかではなく、辞書にふつうに載
っている「実際上、事実上」でしょう。

> 例えば、
> 「REP CMPSBをアセンブルしないことが現実的なので、MASM6.0と6.1では
>  エラーメッセージを出力します」
> っていうのだとどうでしょうか。

 僕は、no encoding のほうに引っかかりました。つまりそれが意味している事
柄に。で、たぶん、分かりました。

 REP CMPSB に対応するマシン語コード(ここの正確な単語は分からないけど、
16 進のあれですよ。mov ax が B8 になるときに B8。符号? 他の箇所では
エンコードとなってる)が、事実上存在しないので、MASM はエラーメッセージ
を出力します。

 大まかな意味は分かっても、こういうところがね。
 いいでしょ? これ。

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

(2052) 2088Re^3: MASM6のrepとrepe  投稿者:Konno   2007/01/23(火) 22:36
    2085 番 文太 さんへのコメント    コメント数 1

私が文太さんの訳を見て思ったのは

古いアセンブラでは、rep はゼロフラグを見ない仕様だったが、使いにくいので、
MASM5.1で repe を追加し、ついでに rep も同じ動作にしてしまった。
しかし、互換性の問題などを指摘されたので、MASM6では、区別するようになった。


全て想像です。(^^;

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

(2052) 2090Re^4: MASM6のrepとrepe  投稿者:文太   2007/01/24(水) 00:13
    2088 番 Konno さんへのコメント    コメント数 1

 (割と即答できる事柄を先にしてしまってます。すいません、としきさん)

> しかし、互換性の問題などを指摘されたので、MASM6では、区別するようになった。

 これより前はたぶんそんな感じかな、と思うのですが、ここは違うでしょう。
MASM6 では、rep(e なし) は廃止なんです。 存在しないのです。だからエラー
になるのです。ち、違う? delmem.asmの;buntaの行2つ目を、repe -> repと
すると(オリジナルに同じにすると)ml.exeが止まるはずです。

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

(2052) 2092Re^5: MASM6のrepとrepe  投稿者:Konno   2007/01/24(水) 01:16
    2090 番 文太 さんへのコメント    コメント数 1

>  これより前はたぶんそんな感じかな、と思うのですが、ここは違うでしょう。
> MASM6 では、rep(e なし) は廃止なんです。 存在しないのです。だからエラー
> になるのです。ち、違う? delmem.asmの;buntaの行2つ目を、repe -> repと
> すると(オリジナルに同じにすると)ml.exeが止まるはずです。

そうでしたね。言いなおしましょう。

しかし、互換性の問題などを指摘されたので、MASM6では区別し、rep を
使用できないようにした。(もともとのバグ仕様の証拠隠滅のため)


ああ、妄想がぁぁ

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

(2052) 2103Re^6: MASM6のrepとrepe  投稿者:文太   2007/01/25(木) 00:12
    2092 番 Konno さんへのコメント

金野さん

> もともとのバグ仕様の証拠隠滅のため

 あまりこだわって欲しくないかもしれませんが、やっぱ仕様自体がバグっぽい
ですか? ゼロフラグをチェックしないというのは。どうも分岐のキモであるフ
ラグが分かってなくて…。

>  注:これらの命令の違いは、REPがゼロフラグ(ZF)に関係なくCX 回命令を繰り
> 返すのに対して、 REPE と REPNEの方は、繰り返しに際してゼロフラグ(ZF)を確
> 認する点です。

 ただ、これはrep cmps(b|w)の場合ですよね。rep自体は生きている。

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

(2052) 2086Re: 追記メモ(PSPなど)  投稿者:としき   2007/01/23(火) 21:50
参照先:http://toshiki.la.coocan.jp/
    2081 番 文太 さんへのコメント    コメント数 3

あとで修正するかもしれませんが。
DOSのメモリ管理でまず最初に覚えておく必要があることは1つ。
確保したメモリブロックの前に、そのメモリブロック自身を管理するための領域
が16バイト確保される、ということ。この16バイトの中に、サイズやら次の
メモリブロックへのポインタやらその他モロモロの情報が格納されます。今回の
例では

> 0009FBF0 CD 20 FF 9F 00 9A C0 00-00 00 DE 01 95 17 4B 01 |ヘ ...埖...゛...K.

の部分。

次に、確保したメモリブロックの使い方なんですが、大抵はそこにプログラムが
入るわけです。常駐プログラムならcommand.comに抜けますが、常駐でなくても、
このへんは全て同じです。チャイルドプロセスなんてものが可能なプログラムも
あったりしますので、そこでメモリ状況をモニタリングしてみることも可能。
そして、PSPだのDTAだのというのは、そういうプログラム自身のために用
意されます。それらの領域の後ろにプログラム本体というか実体が鎮座するわけ
です。
もしここで、プログラムに実体がなければ、すなわち、単にメモリを確保してい
るだけならば、PSPやDTAなんてどこからも利用されないわけですから、そ
の部分まで含めて、他のプログラムから使うことも可能です。つまり、1KBの
メモリを確保したなら、丸まる1KBのメモリを自由に使ってしまっても構わな
いわけです。

が、実際には、それだけではなかったりします。
メモリの開放という事を考える必要があるかもしれません。
この場合、全く無関係のメモリを開放するわけにはいきません。
ではどうするか。メモリのどこかに印を付けておき、開放時にはその印をチェッ
クして、間違いなく自分が確保したもののみ開放する必要があります。既に忘れ
ていますが、delmemは多分、そういうことのためにDTAの直前の領域を使って
いるのではないかなぁ。1kbufについては、常駐解除を行わないのでわざわざID
を埋め込むこともないのですが、メモリマップ表示ツールで表示した際の見栄え
のためだけに埋め込みを行っております。
ということで、常駐解除を放棄し、さらにメモリマップ表示ツールでの表示も気
にしないことにすれば、この部分まで丸々使うことが可能です。

なお、常駐解除については、メモリアドレスを指定して強制的に開放させるとい
うツールがあったはずです。
また、メモリマップ表示ツールのために、IDというか任意の文字列をメモリの
特定の領域に埋め込む、なんてツールも見たことがあります。確かこれは、RIKA
ちゃんのソフトハウスの作品だったような。
両方とも、今でもベクターあたりにあるのではないかなぁ。
あとで探してみます。見つかったら紹介します。

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

(2052) 2093Re^2: 追記メモ(PSPなど)  投稿者:文太   2007/01/24(水) 09:28
    2086 番 としき さんへのコメント    コメント数 1

としきさん、ちょっとずつ

> DOSのメモリ管理でまず最初に覚えておく必要があることは1つ。
> 確保したメモリブロックの前に、そのメモリブロック自身を管理するための領域
> が16バイト確保される、ということ。この16バイトの中に、サイズやら次の
> メモリブロックへのポインタやらその他モロモロの情報が格納されます。

 これがMCBのことですよね。「メモリブロックの前16バイト」。

> 今回の例では
> 0009FBF0 CD 20 FF 9F 00 9A C0 00-00 00 DE 01 95 17 4B 01 |ヘ ...埖...゛...K.
> の部分。

 前にも同じやりとりをしてると思うのですが、ここ、間違ってませんか。僕は、
上はPSPの先頭行だと思うのですが。
 で、この前が、MCBではないかと思うのです。


 もっと具体的に。
 下が、メモリ環境についてのvmapによる情報です。

1887 <-- 1 3888 vz 1.60Q -z 1B 21 29
197B 1 549936 <free>
9FBF <-- 1 1024
----- EMS ver4.0 (frame: CF00h) ----- ----- XMS ver2.00 -----

 Vz常駐前に delmem を u1 オプションで常駐させてVzも常駐させた状態の
vmap。で、ダンプ。


C:\WORK2\DELM\ORG>dump -mx1886 -s32 ;Vzの16バイト前
00018860 4D 87 18 F3 00 82 DC 82-56 5A 00 50 00 4D 00 83 |M....ま7Z.P.M.ο
00018870 CD 20 7A 19 00 9A F0 FE-1D F0 DE 01 95 17 4B 01 |~ z..夸..&#57501;...K.
; int 20h

C:\WORK2\DELM\ORG>dump -mx9fbe -s32 ;delmemの16バイト前
0009FBE0 5A BF 9F 40 00 00 00 00-00 00 00 00 00 00 00 00 |Zソ檗............
0009FBF0 CD 20 FF 9F 00 9A C0 00-00 00 DE 01 95 17 4B 01 |ヘ ...埖...゛...K.
; int 20h

 ね、 M と Z で、PSPの256バイトの前16バイト、「次のメモリブロッ
クへのポインタ」などの情報を含む部分であるMCBでないですか? 違います
か?

> そして、PSPだのDTAだのというのは、そういうプログラム自身のために用
> 意されます。それらの領域の後ろにプログラム本体というか実体が鎮座するわけ
> です。

 ここまでで、何かとんでもない勘違いをしてますでしょうか。m(__)m


(間)うーん、うーん、うーん。前にも、密かに、巡った場所である。


 そうすると vmap はMCBはメモリブロック先頭とみなさず、PSP先頭をメ
モリブロック先頭とみなしているわけですよね。PSPがメモリを使っているプ
ログラム自身のためののもので、MCBがそれらを管理する MS-DOS のためのも
のと考えるなら、当たり前???。

 そうすると、delmem や 1kbuf が中からMCBに何かする、というのがよく分
からなくなります。

> MCB_LOWER equ 0
> MCB_MINIMUM equ 1
> MCB_UPPER equ 2
> MCB_MAXIMUM equ 3
> REMOVE equ 4
(from delmem.asm)

 用語定義にまつわる誤解ですか???

 MCBって、

>  MCB メモリコントロールブロック
>   プロセスがロードされたり,メモリを確保(int21_48h など)
>   すると,その手前に作られる 16 bytes の管理領域。
>   ┃ ↑ MS-DOS ┃
>   ┣━━━━━━━━┫ 《MCB memory control blocks》
>   ┃ <MCB> ┃  +00h db メモリ管理用マーク
>   ┣━━━━━━━━┫  'M' = 次のブロックがある
>   ┃ PSP ┃ 'Z' = 最終ブロック
>   ┠────────┫  +01h dw 使用するプロセスの PSP セグメント
>   ┃ プロセス ┃  (0h 未使用, 8h DOS, 9h ADDDRV)
>   ┣━━━━━━━━┫  +03h dw パラグラフ(*16=サイズ)
>   ┃  <MCB> ┃  +05h db 未使用
>   ┣━━━━━━━━┫  +06h 10 オーナー名(プログラムまたは)
>   ┃ ↓ 確保メモリ ┃ 'SC'System Code
(from f_call.shd)

 「プロセス」のあと、「確保メモリ」の前にも取られるのですよねぇ???
 やっぱり、ワカワカだぁ〜。僕はどこで何を間違えているのでしょう? すい
ません。

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

(2052) 2098Re^3: 追記メモ(PSPなど)  投稿者:としき   2007/01/24(水) 19:39
参照先:http://toshiki.la.coocan.jp/
    2093 番 文太 さんへのコメント    コメント数 1

>  前にも同じやりとりをしてると思うのですが、ここ、間違ってませんか。僕は、
> 上はPSPの先頭行だと思うのですが。

はい、おもいっきり間違っています。
文太さんのおっしゃることの方が正しいです。
資料を確認しないで書くとこんなものです。

>  そうすると、delmem や 1kbuf が中からMCBに何かする、というのがよく分
> からなくなります。
> > MCB_LOWER equ 0
> > MCB_MINIMUM equ 1
> > MCB_UPPER equ 2
> > MCB_MAXIMUM equ 3
> > REMOVE equ 4
> (from delmem.asm)

もう覚えていませんが、1kbufはプログラム内部からMCBをゴニョゴニョする、と
いうことはしていなかったはずです。
delmem.asmのこの部分は、単に可読性向上のための記号定数という事ではないか
なぁ。

>  「プロセス」のあと、「確保メモリ」の前にも取られるのですよねぇ???

なんかイメージが合わない。
通常というかデフォルトでは、下位からメモリが確保されます。
確保された中にプログラムがストアされて、これがこの場合の「プロセス」を意
味しているのだと思います。が、プロセスの後ろは確保されなかったメモリ、つ
まり空メモリになるような気がするのですが。まぁ、空メモリにしろ、どれだけ
のサイズがあるのかということをDOSは管理しなければならないので、そこに
MCBがあるのは不思議ではないのですが。

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

(2052) 2102Re^4: 追記メモ(PSPなど)  投稿者:文太   2007/01/25(木) 00:04
    2098 番 としき さんへのコメント    コメント数 1

としきさん

 遠い昔のふにゃふにゃしてしまった記憶については了解です。
 僕は記憶にすらなっていない。もっとも(繰り返しですが)、SEINさんもPS
Pを含めた部分をMCBとドックで呼んでたと思いますよ。ごっちゃになりやす
いのでしょう、一般に。

> もう覚えていませんが、1kbufはプログラム内部からMCBをゴニョゴニョする、と
> いうことはしていなかったはずです。

 うん、そうみたいだった。MCB なんとかとか変数名には(定数か?)けっこう
使ってあったみたいだけど。

> delmem.asmのこの部分は、単に可読性向上のための記号定数という事ではないか
> なぁ。

 うーん、うん。ただdelmemと1kbufではMCBの内容が違うのは確か。もうどうで
もいいけど。 いいのか、そういうこと言って。とりあえず1kbuf+meuで常駐外れ
るので、MCBだけ残すラインでいきます。1024ゲット(^^)v
 いつか色々道具が揃って、やっぱ2キロバイトどうしても欲しい(メインメモ
リーにかよ)ときにはdelmem+meuに乗り換えます。そういう問題じゃないか?

> >  「プロセス」のあと、「確保メモリ」の前にも取られるのですよねぇ???
> なんかイメージが合わない。
> 通常というかデフォルトでは、下位からメモリが確保されます。

 はい、前とか上とか言ってましたがが、00000h番地からです。常駐ものAは後
からメモリーに載せられるBより(VWXとVz) 下位に置かれ、PSPはプログラ
ム本体より下位に、MCBはPSPより下位に置かれます。通常。

> 確保された中にプログラムがストアされて、これがこの場合の「プロセス」を意
> 味しているのだと思います。が、プロセスの後ろは確保されなかったメモリ、つ
> まり空メモリになるような気がするのですが。

 なると思います。 驚いたことに 1kbuf と delmem を meu で外したとき、<
free area> に MCB がついていて、Z の印があった。これを見たとき、少しはな
るほど! と思った。sein 様々です。

> まぁ、空メモリにしろ、どれだけ
> のサイズがあるのかということをDOSは管理しなければならないので、そこに
> MCBがあるのは不思議ではないのですが。

 あれ、イメージが合わないのは、どこだ?
 あ、「確保メモリ」だ。うーん。?

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

(2052) 2107Re^5: 追記メモ(PSPなど)  投稿者:としき   2007/01/25(木) 00:46
参照先:http://toshiki.la.coocan.jp/
    2102 番 文太 さんへのコメント    コメント数 1

> > もう覚えていませんが、1kbufはプログラム内部からMCBをゴニョゴニョする、と
> > いうことはしていなかったはずです。
>  うん、そうみたいだった。MCB なんとかとか変数名には(定数か?)けっこう
> 使ってあったみたいだけど。

ソースを確認してみました。
確かに、いくつかMCBなんとかっていうのを使っていますね。
これ、実は、delmemで使っているものをそのまま名前を変えずに使いまわしてい
るのです。名は体を表すようにするべきであり、そうであれば、MCBという言葉を
やめてストラテジという用語を使うべきなんでしょうね。

>  あ、「確保メモリ」だ。うーん。?

そです。
確保していないはずのところを確保メモリと表現しているようなので、なんとな
く違和感バリバリという感じです。

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

(2052) 2112Re^6: 追記メモ(PSPなど)  投稿者:文太   2007/01/25(木) 01:14
    2107 番 としき さんへのコメント

としきさん

> ソースを確認してみました。

 どういう文脈でも、どすが効くなぁ。

> 確かに、いくつかMCBなんとかっていうのを使っていますね。

 了解。

> これ、実は、delmemで使っているものをそのまま名前を変えずに使いまわしてい
> るのです。名は体を表すようにするべきであり、そうであれば、MCBという言葉を
> やめてストラテジという用語を使うべきなんでしょうね。

 これは、将来的に、けっこうおいしい情報かも。

> >  あ、「確保メモリ」だ。うーん。?
> そです。
> 確保していないはずのところを確保メモリと表現しているようなので、なんとな
> く違和感バリバリという感じです。

 とはいえですね、たぶん和生さんだと思うけど、どっかからそのまま写してる
と思うのです。僕は、com ファイルでの、データセグメントのこと? exe ファ
イルだとそんな具合になる? とか空想したのですが。
 ま、バリバリだ。笑い。

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

(2052) 2096seinさんのmeuで1kbufの常駐解放!  投稿者:文太   2007/01/24(水) 14:55
    2086 番 としき さんへのコメント

サンクス、としきさん

> なお、常駐解除については、メモリアドレスを指定して強制的に開放させるとい
> うツールがあったはずです。

 この一言で、昨晩から探した探した。読めないドックを読んだ、読んだ。
 じゃーん、以下で外れます。常駐解除後 vmap しても、正常です! おっし、
これでモバでも 1008 取れる! (MCB16 バイトは触らない。先頭4バイトを常
駐確認に使っているので、PSP 一行目の 16 バイトも触らない。)

http://www.vector.co.jp/soft/dos/hardware/se004906.html
(天下のseinさんの優れものです)


 1kbuf常駐後、以下で常駐解除。

>meu -qr mem segment=09fbe

 当然、読めないドックを読みながら、PSPとかMCBとか考えているわけで
すが、 16バイトと言ったら、やっぱり int 21h の前の行のことじゃないのか
な、と思っています。 狭義のMCB。ただ、sein さんも、PSPを含めて「メ
モり制御ブロック」と呼んでいるような感じがしました。広義のMCB。外れ?


 というわけで、2つのマクロの先頭は、醜いブロック if 文から解放され、ど
のマシン環境でも、以下のように設定すればよいことになりました。>金野さん。
 最初の16バイトはしょうがないでしょう。


=== Buf_Init.def by Bunta ===;buffer initialization
* Macro
50 ^^ "Buf_Init"

x=$9fc0, ;base buf seg
y=1008, ;buf max length


=== Buf_Hcpy.def by Bunta ===;Dummy Buffer Histcopy
* Macro
50 ^\ "Buf_hcpy"; dummy buffer histcopy

?.
w=$9fbf, ;check seg
x=$9fc0, ;base buf seg
y=1008, ;buf max length

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

(2052) 2100Re^2: 追記メモ(PSPなど)  投稿者:としき   2007/01/24(水) 21:54
参照先:http://toshiki.la.coocan.jp/
    2086 番 としき さんへのコメント

> あとで修正するかもしれませんが。

大きな間違いがありまして、申し訳ありませんでした。
別発言参照、ということで。

> なお、常駐解除については、メモリアドレスを指定して強制的に開放させるとい
> うツールがあったはずです。

これは文太さんが見つけてくださったのでよいですね。

> また、メモリマップ表示ツールのために、IDというか任意の文字列をメモリの
> 特定の領域に埋め込む、なんてツールも見たことがあります。確かこれは、RIKA
> ちゃんのソフトハウスの作品だったような。

う〜ん、自分のHDDの中の関連のありそうなディレクトリを総ざらいしてみた
んだけど見つからない。かすかに記憶に残っているドキュメントの体裁から、絶
対にRIKAちゃんのソフトハウスかHeiwa-Rappa's Software Propsの作品だと思い
込んていたんで、WEBで検索をかけてみたところが、そもそもRIKAちゃんのソ
フトハウスの作品はWEBにほとんど乗っかっていない。平和ラッパさんの作品
はベクターにも幾つかあったけど。
一応、τομοακιさんの作られたMCB
http://www.vector.co.jp/soft/dos/hardware/se001104.html
にはこの機能があるようだけど、その他のいろんなツールのドキュメントによる
と、どうもDOS3までの場合のみ必要になる機能みたい。DOS4以降の場合
は、OSの機能できちんと表示できるという事なのかな。

なお、手元のHDDをサルベージする過程で、delmemでもeatmemでもないメモリ
イーターを発見したので紹介しておきます。TTYの時代のヘビーチャッターな
ら名前ぐらいはご存知だと思いますが、IDPICKというソフトがありました。この
ソフトの作者である「ばるちゅす」(H.Yamanaka)さんという方が作られたソフ
トで、GOMI.COMというものを発見してしまいました。残念ながらソースは同梱さ
れていませんでした。
このソフトもWEBの世界では発見できませんでした。というか、ばるちゅす氏
の作品がほとんど発見できませんでした。うみゅ、こうやって、だんだんとかつ
ての面白いソフトや当時のスター作家が埋もれていくのでしょうね。

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

(2052) 2087Re^3: delmemなら  投稿者:Konno   2007/01/23(火) 22:24
    2079 番 文太 さんへのコメント    コメント数 1

文太さん

>  了解しました。(またですが)明日、お昼頃までにはお送りします。

いただきました。ありがとうございます。m(__)m
で、早速アセンブルしてみたんですが、なんか、com のサイズがみんな違うなぁ。

1994/03/30 01:11 1,024 DELMEM.COM   TASM  オリジナル
2007/01/23 21:35 1,048 DELMEM1.COM  MASM6  konno
2007/01/23 21:27 1,064 DELMEM5.COM  MASM5.1
2007/01/23 12:08 1,002 DELMEM6.COM  MASM6  文太

同じMASM6で違うのはなぜなんだろう?


>  その後、ちょっとだけもにょもにょしておりますが、うーん、道は険しいです
> ね。でも楽しいです。Vzソースの暗号がすこーしずつ意味を持ち始めたりして。

Vzのソースは最高の教科書かもしれませんよ。あの榊原さんも高橋さんも
DANNYさんもみなさんVzのソースでアセンブラを覚えたみたいですし。

私は覚えが悪くてまだまだですが、ソースを読むことで逆にマクロの仕組みが
わかったりするし、なによりVzが好きだから苦にならないんですね。

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

(2052) 2089Re^4: delmemなら  投稿者:文太   2007/01/23(火) 23:17
    2087 番 Konno さんへのコメント    コメント数 1

金野さん

> 2007/01/23 21:35 1,048 DELMEM1.COM  MASM6  konno
> 2007/01/23 12:08 1,002 DELMEM6.COM  MASM6  文太

 これ、何か間違ってませんか? すぐひとを疑う奴。すいません。☆\ (^^;)
 だってバージョン用の変数領域削っているので、オリジナルより小さくなるは
ずなんです。 ラベルは増えてるんだっけ? う、あの sed スクリプトがバグっ
てた? いや、ちゃんと diff したし、だって金野さんと僕は同じソースを使っ
ているはずなんだ。

 もしかして、 リンカと exe2com で、できあがりサイズが違うってことあるん
ですか?

ML.EXE 372,736 1999-03-29 16:45
LLD.EXE 27,417 1993-02-08 17:43
EXE2COM.EXE 14,699 1988-03-08 20:42

 を僕は使っているのですが…。 確か MASM6 のヴァージョンも同じだったはず
なので、すごく変ですよねぇ。いえ、上記のとおり、僕、送る前にアセンブルし
てるものですから、…???


 Vzソースのことは、あははははは、ということで。榊原、高橋、DANNY、
金野、ということでありますから。錯綜したソース、にまでまだ届いていません。
「マクロ」と「モジュール別開発法」までいけたらなぁ、とは少し思いますが。

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

(2052) 2091Re^5: delmemなら  投稿者:Konno   2007/01/24(水) 01:12
    2089 番 文太 さんへのコメント    コメント数 1

>  もしかして、 リンカと exe2com で、できあがりサイズが違うってことあるん
> ですか?

exe2comは私も使っているので関係ないでしょう。

> LLD.EXE 27,417 1993-02-08 17:43

私のはたぶんMASM5.1のリンカですが、このLLD.EXE が最適化性能がいいのかなぁ。

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

(2052) 2094Re^6: delmemなら  投稿者:文太   2007/01/24(水) 09:39
    2091 番 Konno さんへのコメント

金野さん

C:\WORK2\DELM>ml DELMEM.ASM
C:\WORK2\DELM>lld delmem.obj
C:\WORK2\DELM>exe2com delmem.exe
C:\WORK2\DELM>Command.com /cDir delmem.*

DELMEM ASM 7772 07-01-23 12:07
DELMEM COM 1002 07-01-24 9:32
DELMEM EXE 1770 07-01-24 9:32
DELMEM OBJ 1419 07-01-24 9:31

 やっぱ、lld.exe が偉い、と考えるしかないようですね。違う delmem.asm を
間違えて送った、ということもないようですし。

 pconsoleのバグ出るし…。アセ、アセ。直すのやだぁ。

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

(2052) 2076Re^5: ヌル2つを見つける(再び)  投稿者:Konno   2007/01/19(金) 02:01
    2073 番 文太 さんへのコメント    コメント数 1

> 14BD <--    1    3888  vz 1.60Q -z                1B 21 29	(1)
> 15B1 1795 1 1408 command
> 160A <-- 1 6304 kb16 JP,932,C:\WINDOWS\sy 09 2F
> 1795 <-- 1 3856 command 22 23 24
> 1887 <-- 2 194352 キ 1.60Q -z (2)
> 47FC 1 359440 <free>

この 'キ' は半角ですよね。これはオリジナルVzでも高橋版でもこうなると思います。
autoexec.vz で常駐したVz(sw3)で何かファイルをオープンしてから、[ESC] E で
コマンドラインに行き、小文字で vmap を実行すればこれが確認できます。
ということで、XPでのVzはこうなるようです。この状態で大きなプログラムを
実行すると分断されたままになってしまうので、良くないのは明らかですね。

> > 私は dump を持ってないので debug で確認しました。
>  さすが。お、オプションは何ですか?(^^;

D 9fbf:0
でダンプするだけです。(^^;

>  金野さんんなら、その気になれば自分の欲しいものを探せるはずですが、僕が
> 使っているのは、30行バイオスのlucifer/walkerさんの
> http://www.vector.co.jp/soft/dos/util/se002401.html
>  です。他にもいっぱいありますねぇ。

あ、わざわざどうも。探せばどこかにあるかもしれないんですが、落としたほうが
早いですね。(^^;

>> このままだとモバギではまずいのでは。128バイトずらすとか。

すみません、全然違いましたね。適当なことを言ってしまい、申し訳ない。m(__)m

>  ついでに(は?)、ヒストリー機能のついた新版を上げておきますね。

こちらも手が空いたら試して見ます。だんだん形が出来ていくのが楽しみになってます。
(^_^)


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

(2052) 2077Re^6: ヌル2つを見つける(再び)  投稿者:文太   2007/01/19(金) 15:35
    2076 番 Konno さんへのコメント

金野さん

> ということで、XPでのVzはこうなるようです。この状態で大きなプログラムを
> 実行すると分断されたままになってしまうので、良くないのは明らかですね。

 やっぱり。うーん。気づかない方が幸せだったかも。

> でダンプするだけです。(^^;

 了解。(^^;

>  ついでに(は?)、ヒストリー機能のついた新版を上げておきますね。
> こちらも手が空いたら試して見ます。だんだん形が出来ていくのが楽しみになってます。

 こう言ってもらえるのがこんなに嬉しいとは。m(__)m
 次は遠そうです。3日ばからオフラインな出張をしてきます。m(__)m



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

(2052) 2074Buf_Hcpy.def (v.0.5)  投稿者:文太   2007/01/18(木) 12:28
    2052 番 文太 さんへのコメント    コメント数 1

 文太くん、珍しく、こつこつやっております。blog以来のことと思われます。
 次に、いける? という不安があるので、とりあえず、ここまで来ました、と
いう御礼とご報告。

=== Buf_Hcpy.def by Bunta ===;Dummy Buffer Histcopy
;special thanx to konno, YASAT and Toshiki. m(_B_)m
;thanx to Takahashi's Sabrina, Toshiki's 1kbuf.com and Se's delmem.com.
;ダミーバッファ用ヒストコピー。ブロックでデータ取得(まだ試行段階。テスト
;が楽)。普通起動でデータ保存(ヒストリー)、シフトで書き出し(とりあえず
;PSへ)
;dump -mx9fbf -s16
;dump -mx9fbf -s32
;dump -mx9fbf -s64
;dump -mx9fbf -s300

* Macro
50 ^\ "Buf_hcpy"; dummy buffer histcopy

?.
w=$9fbf, ;check seg
x=$9fc0, ;base buf seg
y=1008, ;buf max length

; --- check TSR
dx=w, &20 (ax)?? {&m("1kbuf, not on memory!").}

(ks&1)? >R

(mb)? {ps[=pr, #G ps], >a}

pw[=pr,
&g("*** sending to the dummy buffer ***",30)
pw], (r<0) ?.

:a &Sn(pr) a=r, ;☆SOURCE STR: pr,a
&m("->Buf: %s",pr)


;--- check the buffer & get the strlen2 info ---
; --> si 0:empty; n:len of all str in buffer
dx=x, ax=y,
&i("$(52,1F,33,DB,33,F6,39,1C,74,04,46,48,73,F8,C3)")
;☆DEST STR: x,b(si)
(ax==-1)? {&m("Warning: buffer destroyed.").}
(si)?? >B


;--- if strlen2+new_strlen, too long, discard the oldest str ---
:c bx=x, (a+si+3>y)? { &i("$
$(53,1F,32,DB,4E,8A,04,38,D8,74,0B,4E,73,F7,88,1C)$
$(46,88,1C,4E,EB,04,46,88,1C,4E,C3)")
>c }
b=si, ;☆DEST STR: x,b(si)

;===== Writing onto Buffer with history function =====
:A &00 &01 . ;hist+
:B &01 . ;hist- (1st time buf use, only)



;=============== Reading from Buffer =================
:R
;----- check the buf & get str_length (3)
bx=x, dx=y,
&i("$(53,1F,32,DB,33,F6,8A,04,38,D8,74,04,46,4A,73,F6,C3)")
(si==0) ? {&m("Empty. Cannot write out").}

;----- reading (temporarily onto PS)
ax=x, cx=si+1, si=0, ;set source
bx=gz, di=ps, ;★set destination
&i("$(50,1F,53,07,F3,A4,C3)") ;(4)
&m("%s",ps) ;★
.


; --------------------- LOCAL MACROS ---------------------

00: ;;==== hist 1st move ==== << dest=>dest move >>

;source ds(ax):si, cx=copy times ;
ax=x, si=b, cx=b+1, ;set
;dest es(bx):di, ;
bx=x, di=a+b+1, ;set

&10 ;copy backwards, exec!


01: ;;==== hist 2nd move ==== << src->dest copy >>

;source ds(ax):si, cx=copy times ;
ax=gz, si=pr+a, cx=a+1, ;set
;dest es(bx):di ;
bx=x, di=a, ;set

&10 ;copy backwards, exec!

10: ; --- hist backward copy for reading
&i("$(50,1F,53,07,FD,F3,A4,FC,C3)")


20: ; --- TSR check (5)
&i(3+$)."$
$(52,1F,33,F6,33,C0,B9,CD,20,39,0C,75,0E,83,C6,02)$
$(B9,FF,9F,39,0C,75,04,B8,01,00,C3,C3)"


*

(source 1; str_len2−−ヌル2つまでの距離を測定)
; dx = dbuf segment
; ax = バッファサイズ
; si = (出力)文字列長
; bx used.

START:
push dx ;セグメント設定
pop ds ;同
xor bx,bx ;初期化(ワード)
xor si,si ;初期化(カウンタ)
NEXT:
cmp word ptr [si],bx ;ワードで比較 (ds..0==0)? <--macro語
je FIN ;一致で終了
inc si ;1バイトずつずらす
dec ax ;限界値カウンタをデクリメント
jnc NEXT ;限界値が0に達したら終了。そうでなければNEXT
FIN:
ret


(source 2; str_cpy)
;----- ax (==ds), si, bx (==es), di, cx (length) 受け渡しは5つ
;後ろから cx bytes コピー
;ds:si -> es:di, cx (bytes to be copied, ie. copy times)
;<-- ax,bx,cx,si,di
push ax
pop ds
push bx
pop es
std
rep movsb
cld
ret


(source 3; str_len)
;------------------------------
;search 0 in ds:si (<-- ds==bx)
;--> bx (dbuf seg), dx (max)
;<-- si (counter)
START:
push bx ;ds
pop ds
xor bl,bl ;0
xor si,si ;counter
ABC: mov al,[si]
cmp al,bl
je XYZ
inc si
dec dx
jnc ABC
XYZ: ret


(source 4; str_cpy)
;----- ax (==ds), si, bx (==es), di, cx (length) 受け渡しは5つ
;ただしこれは素直に(Vz仕様のまま)cldなので、上書きのみ。histは無理。
;histはお尻から動かすこと。
;ds:si -> es:di, cx (bytes to be copied)
push ax
pop ds
push bx
pop es
rep movsb
ret


(source 5; TSR check)
; check top 4 bytes of PSP; CD,20,FF,9F on that particular seg.
; <-- dx (check seg)
; --> ax (0:off, 1:on)
push dx
pop ds
xor si,si
xor ax,ax
mov cx,20CDh
cmp [si],cx
jne NG
add si,2
mov cx,9FFFh
cmp [si],cx
jne NG
mov ax,1
ret

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

(2052) 2097やっぱMCBで判断に変更 Buf_Hcpy.def (0.51)  投稿者:文太   2007/01/24(水) 15:45
    2074 番 文太 さんへのコメント    コメント数 1

 なぜか僕の ps は 1024 なのです。どっかの時点でここまで大きくした。オリ
ジナルなんて 256 ですよ。
 で、やっぱこのサイズまでは、というこだわりがあるので、MCBの先頭3バ
イトで常駐確認することにして、1024確保することにしました。(ああ、あ
そこせっかく作ったのに…)

9FBF <-- 1 1024
----- EMS ver4.0 (frame: CF00h) ----- ----- XMS ver2.00 -----

>dump -mx9fbe -s32
0009FBE0 5A BF 9F 40 00 00 00 00-00 00 00 00 00 00 00 00 |Zソ檗............
0009FBF0 CD 20 FF 9F 00 9A C0 00-00 00 DE 01 6A 4D 4B 01 |ヘ ...埖...゛.jMK.

 独り言でした。

 で、超マイナーバーアップな新版2つ。お手間を取らせません。
 長文すぎるので前回とソースに変更のない部分、ニーモニック省略。

=== Buf_Hcpy.def (0.51) by Bunta ===;Dummy Buffer Histcopy
;special thanx to konno, YASAT and Toshiki. m(_B_)m
;thanx to Takahashi's Sabrina, Toshiki's 1kbuf.com and Se's delmem.com.
;ダミーバッファ用ヒストコピー。ブロックでデータ取得(まだ試行段階)。
;普通起動でデータ保存(ヒストリー)、シフトで書き出し(とりあえずPSへ)
;dump -mx9fbe -s32
;dump -mx9fbf -s256

* Macro
50 ^\ "Buf_hcpy"; dummy buffer histcopy

?.
w=$9fbe, ;check seg
x=$9fbf, ;base buf seg
y=1024, ;buf max length

; --- check TSR
dx=w, &20 (ax)?? {&m("1kbuf, not on memory!").}

(ks&1)? >R

(mb)? {ps[=pr, #G ps], >a}

pw[=pr,
&g("*** sending to the dummy buffer ***",30)
pw], (r<0) ?.

:a &Sn(pr) a=r, ;☆SOURCE STR: pr,a
&m("->Buf: %s",pr)


;--- check the buffer & get the strlen2 info ---
; --> si 0:empty; n:len of all str in buffer
dx=x, ax=y,
&i("$(52,1F,33,DB,33,F6,39,1C,74,04,46,48,73,F8,C3)")
;☆DEST STR: x,b(si)
(ax==-1)? {&m("Warning: buffer destroyed.").}
(si)?? >B


;--- if strlen2+new_strlen, too long, discard the oldest str ---
:c bx=x, (a+si+3>y)? { &i("$
$(53,1F,32,DB,4E,8A,04,38,D8,74,0B,4E,73,F7,88,1C)$
$(46,88,1C,4E,EB,04,46,88,1C,4E,C3)")
>c }
b=si, ;☆DEST STR: x,b(si)

;===== Writing onto Buffer with history function =====
:A &00 &01 . ;hist+
:B &01 . ;hist- (1st time buf use, only)



;=============== Reading from Buffer =================
:R
;----- check the buf & get str_length (3)
bx=x, dx=y,
&i("$(53,1F,32,DB,33,F6,8A,04,38,D8,74,04,46,4A,73,F6,C3)")
(si==0) ? {&m("Empty. Cannot write out").}

;----- reading (temporarily onto PS)
ax=x, cx=si+1, si=0, ;set source
bx=gz, di=ps, ;★set destination
&i("$(50,1F,53,07,F3,A4,C3)") ;(4)
&m("%s",ps) ;★
.


; --------------------- LOCAL MACROS ---------------------

00: ;;==== hist 1st move ==== << dest=>dest move >>

;source ds(ax):si, cx=copy times ;
ax=x, si=b, cx=b+1, ;set
;dest es(bx):di, ;
bx=x, di=a+b+1, ;set

&10 ;copy backwards, exec!


01: ;;==== hist 2nd move ==== << src->dest copy >>

;source ds(ax):si, cx=copy times ;
ax=gz, si=pr+a, cx=a+1, ;set
;dest es(bx):di ;
bx=x, di=a, ;set

&10 ;copy backwards, exec!

10: ; --- hist backward copy for reading
&i("$(50,1F,53,07,FD,F3,A4,FC,C3)")


20: ; --- TSR check (5)
0: &i(3+$)."$
$(52,1F,33,F6,33,C0,B9,5A,BF,39,0C,75,0C,83,C6,02)$
$(B1,9F,38,0C,75,03,B8,01,00,C3)"

*


(source 5; TSR check)
; check top 3 bytes of PSP; 5A,BF,9F on that particular seg.
; check top 3 bytes of PSP; CD,20,FF,9F on that particular seg.
; <-- dx (check seg)
; --> ax (0:off, 1:on)
push dx
pop ds
xor si,si
xor ax,ax
mov cx,0BF5Ah
cmp [si],cx
jne NG
add si,2
mov cl,9Fh
cmp [si],cl
jne NG
mov ax,1
NG: ret

=== Buf_Init.def by Bunta ===;buffer initialization
* Macro
50 ^^ "Buf_Init"

x=$9fbf, ;base buf seg
y=1024, ;buf max length

cx=y, bx=x,
&i("$(53,1F,33,FF,32,C0,3B,CF,74,05,88,05,47,EB,F7,C3)")
&m("Dummy buffer, Initialized") .

*


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

(2052) 2105Re: やっぱMCBで判断に変更 Buf_Hcpy.def (0.51)  投稿者:Konno   2007/01/25(木) 00:23
    2097 番 文太 さんへのコメント    コメント数 1

文太さん、delmem 改造できました。(^_^)

メモリの先頭5バイト目に id を埋め込んだので、先頭16バイトは残しますが、
その先は丸々使えて、メモリの開放も出来ます。バッファ1024+16で、1040バイト
にしたので、9FBE から常駐になりますが、DEFのほうは
x=$9FBF, ;dummy buf seg (要1kbuf.com)
y=1024, ;buf max length
この指定で出来ますよ。

小文字コマンドの絡みもあるので、名前を buf1k としました。
buf1k   でメモリに常駐
buf1k r  でメモリ開放です。

ソースはまだスパゲっているので、メールで送ります。

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

(2052) 2108Re^2: やっぱMCBで判断に変更 Buf_Hcpy.def (0.51)  投稿者:文太   2007/01/25(木) 01:00
    2105 番 Konno さんへのコメント    コメント数 2

金野さん

> 文太さん、delmem 改造できました。(^_^)
> メモリの先頭5バイト目に id を埋め込んだので、先頭16バイトは残しますが、
> その先は丸々使えて、メモリの開放も出来ます。バッファ1024+16で、1040バイト
> にしたので、9FBE から常駐になりますが、DEFのほうは

 まだ、内容把握できてませんが、明日の夜に。
 でも、もっと縮んだ?!!! うっひょーーー! もうVzな人たちって努力
を惜しまないっていうか、ケチなんだもん。スキ。キスよりAがスキ、みたく。
 メールは届いてました。m(__)m

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

(2052) 2113thanx for buf1k.com & bufxchg.def (debut or prototype)  投稿者:文太   2007/01/26(金) 00:44
    2108 番 文太 さんへのコメント    コメント数 2

金野さん、

 buf1k.com、ちゃんと仕事してくれてますよ。m(__)m
 常駐を外すとき、メモリを掃除してますか? どうもそんな風に見えたもので。

 完全未完成品ですが、EMS をワークに使うサンプルということで(サンプルな
んか要らないでしょうが)以下をどうぞ。

 完成すると、history.def by m.gannに小判鮫できるはずなんだけど。

 最初にこのままで。次回、マクロのコメントアウト(★部)をとり、完全交換
を試して下さい。そうしないと、バグ、というか、いい加減な作りのせいで、
ダミーバッファに何もないと、名前のとおり、仕様のとおり、愚直にpsを空に
(?)してしまって面白くありません。

 ほんとは BUF_HCPY.DEF から文字列をDバフに送ったりした方が面白いのです
が、色々と調整が必要なのでpsのほうを変えて、試すなら試して下さい。
 必要な調整というのは、マクロ冒頭と TSR チェック部のセグメントです。 ハ
ンドアセンブルできるけど…。


 追伸: #56 技コメントありがとうございまいした。 それで全部解決ではない
と思いますが、でも、とてもおいしいアドバイスだったと、今日、電車の中で思
いつきました。時間かかる奴なんですよ。としきさんの愚直<別領域案と合わせ
た方法で、きっとうまくいくと思います(手つかずだけど)。両方思いつくのに、
僕ならまじめに考えたとして、3カ月はかかっていたでしょう。m(__)m

 buf1k.comですが、あのメッセージだけ嫌なので(rcp32の話みたいだ)、明日、
アセンブルし直してみます。すいませーん。
 できなかったりして。



=== BUFXCHG.def by Bunta ===;DBUFF_PS exchanger
;色々イージーな作りなので、ジョークお試し版という認識で。
* Macro
50 ^^ "bufxchg"

(ef)?? {&m("not enough EMS!").}

w=$9fbd, ;check seg
x=$9fbf, ;base buf seg
y=1040, ;buf max length


;=== check TSR
dx=w, &00 (ax)?? {&m("buf1k, not on memory!").}


;=== get 2 bufs info & check ===
dx=x, si-, ax=y, &01 f=si, ;<f>strlen2 on buf
dx=gz, si=ps, ax=hs, &01 g=si-ps, ;<g>strlen2 on ps
(y-hs>0) ? {m=hs,} ? {m=y,} ;<m>smaller is the norm

(f>m || g>m) ? {&m("What?!!").} ;easy check


;=== get work on EMS ===
&Ea(1) a=r, ;EMS allocation, EMShandle <a>
&Em(a) b=r, ;EMS mapping, segment <b>


;=== exchange dbuf & ps thru EMS

;--copy ps -> EMS
ax=gz, si=ps, cx=g+2, ;set source
bx=b, di=0, ;set destination
&10
; ;--copy dbuf -> ps ;★
; ax=x, si-, cx=f+2, ;set source
; bx=gz, di=ps, ;set destination
; &10
;--copy EMS -> dbuf
ax=b, si-, cx=g+2, ;set source
bx=x, di-, ;set destination
&10

;=== close work on EMS
&Ef(a) ;release EMS

&m("DBuf <-> PS completed").


;* === * === * === * === LOCAL MACROS === * === * === * === *

00: ;---TSR check
&i(3+$)."$
$(52,1F,33,F6,33,C0,B9,5A,BE,39,0C,75,0C,83,C6,02)$
$(B1,9F,38,0C,75,03,B8,01,00,C3)"

01: ;---strlen2
; <-- dx = segment, si = offset, ax = buffersize (serch max)
; --> si = offset
&i("$(52,1F,33,DB,39,1C,74,04,46,48,73,F8,C3)")

10: ;---strcpy; ax:si -> bx:di, cx times
&i("$(50,1F,53,07,F3,A4,C3)") ;(4)

*

(source 1; strlen2−−ヌル2つまでの距離を測定)少し汎用化
; <-- dx = segment, si = offset, ax = buffer size (serch max)
; --> si = offset

START:
push dx ;set segment
pop ds ;
xor bx,bx ;0 (word)
NEXT:
cmp word ptr [si],bx ;cmp by the word (ds..0==0)?
je FIN ;
inc si ;inc by the byte
dec ax ;
jnc NEXT ;jump if not with carryflag
FIN:
ret

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

(2052) 2114Re: thanx for buf1k.com & bufxchg.def (debut or prototype)  投稿者:文太   2007/01/26(金) 00:55
    2113 番 文太 さんへのコメント

>  必要な調整というのは、マクロ冒頭と TSR チェック部のセグメントです。 ハ
> ンドアセンブルできるけど…。

 阿呆!

Buf_Hcpy.def
の冒頭を

w=$9fbd, ;check seg
x=$9fbf, ;base buf seg
y=1040, ;buf max length

にして、

TSRチェック部を

20: ;---TSR check
&i(3+$)."$
$(52,1F,33,F6,33,C0,B9,5A,BE,39,0C,75,0C,83,C6,02)$
$(B1,9F,38,0C,75,03,B8,01,00,C3)"

に差し替え、そしてBuf_HcpyでちゃんとDBに文字列を入れれば、psが消えて
不愉快ということはないはずです。たぶん。

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

(2052) 2116Re: thanx for buf1k.com & bufxchg.def (debut or prototype)  投稿者:Konno   2007/01/26(金) 01:55
    2113 番 文太 さんへのコメント    コメント数 1

>  buf1k.com、ちゃんと仕事してくれてますよ。m(__)m
>  常駐を外すとき、メモリを掃除してますか? どうもそんな風に見えたもので。

??? delmem と違う動作だとしたらバグってるのかも。id の埋め込みの
副作用とか?

>  完全未完成品ですが、EMS をワークに使うサンプルということで(サンプルな
> んか要らないでしょうが)以下をどうぞ。

今度はEMSですか。文太さんのスピードにはとても付いていけません。(^^;
完成版をじっくり試したいと思います。(^^;

>  buf1k.comですが、あのメッセージだけ嫌なので(rcp32の話みたいだ)、明日、
> アセンブルし直してみます。すいませーん。

どうぞどうぞ。ちなみにどんなメッセージがいいんでしょう。私はセンスが
無いもので。

> y=1040, ;buf max length

これ、1024 じゃないんですか?

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

(2052) 2118Re^2: thanx for buf1k.com & bufxchg.def (debut or prototype)  投稿者:文太   2007/01/26(金) 11:12
    2116 番 Konno さんへのコメント    コメント数 1

金野さん

> ??? delmem と違う動作だとしたらバグってるのかも。id の埋め込みの
> 副作用とか?

 いけないマクロの副作用という気がしてきました。訊いておいてよかった。◆

> 今度はEMSですか。文太さんのスピードにはとても付いていけません。(^^;
> 完成版をじっくり試したいと思います。(^^;

 「完成品をじっくり」は、たしかにそうほうが賢明という感じ。ただ問題は完
成しないかもしれない点で…。今日は少し時間とれるのだけど、疲れが溜まって
て。
 そりゃ、そういう無理すれば、溜まるでしょう、若くないんだし、という感じ。

 ただEMSに関しては、誤解してますよ。大昔に(という感じ)としきさんが
言ってたように、ワークとして使う分には、ポインタの概念がある人が &S 関数
を使うようなものです。簡単です。保存バッファにしようとすると、ある意味、
メタレベルに上がってしまうので面倒ですが。
 なーんて偉そうに言ってみたり。天罰が下りそうな予感も、ある。

> >  buf1k.comですが、あのメッセージだけ嫌なので(rcp32の話みたいだ)、明日、
> > アセンブルし直してみます。すいませーん。
> どうぞどうぞ。ちなみにどんなメッセージがいいんでしょう。私はセンスが
> 無いもので。

C:\>buf1k

DELMEM ver0.01
1キロバイト上位メモリから確保しました。 ( R (remove) -> メモリ解放 )



Buf1k installed. For removal, Buf1k R.
とか。

 おとなしく。半角カナというのがバランス悪いような…。元のまま?

> > y=1040, ;buf max length
> これ、1024 じゃないんですか?

 きゃっ! 16引くの忘れてる。これが◆の原因の一つだな。多謝です。m(__)m

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

(2052) 2119Re^3: thanx for buf1k.com & bufxchg.def (debut or prototype)  投稿者:Konno   2007/01/27(土) 01:13
    2118 番 文太 さんへのコメント    コメント数 1

>  いけないマクロの副作用という気がしてきました。訊いておいてよかった。◆

う〜ん、私も結構適当に弄ったので、間違えているところがあるかもしれません。

> C:\>buf1k
> DELMEM ver0.01
> 1キロバイト上位メモリから確保しました。 ( R (remove) -> メモリ解放 )
> ↓
> Buf1k installed. For removal, Buf1k R.

なるほど、すっきりしてますね。いただきます。m(__)m げげ、DELMEMのメッセージ
残ってたか。(^^; DOCを読んでも特に改造禁止みたいな記述も無いし、もう少し
弄ったら石の山にでも捨てるか。

>  きゃっ! 16引くの忘れてる。これが◆の原因の一つだな。多謝です。m(__)m

何か理由があるんだろうなぁと思ってました。(^^;

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

(2052) 2123Re^4: thanx for buf1k.com & bufxchg.def (debut or prototype)  投稿者:文太   2007/01/28(日) 00:26
    2119 番 Konno さんへのコメント    コメント数 1

金野さん

> う〜ん、私も結構適当に弄ったので、間違えているところがあるかもしれません。

 そ、そんなぁ。マクロの冒頭をきちんと整理したら、今のところ大丈夫ですが。

> > C:\>buf1k
> なるほど、すっきりしてますね。いただきます。m(__)m げげ、DELMEMのメッセージ
> 残ってたか。(^^; DOCを読んでも特に改造禁止みたいな記述も無いし、もう少し
> 弄ったら石の山にでも捨てるか。

 捨てないでぇ。
 ずうずうしく「もう少し弄る」の部分ですが、常駐量を1k以外に変更できる
のはやはりおいしいオプションだと個人的には思ってます。僕の使用目的上、常
に上位からがうれしくはありますが。
 でも、せっかくだから、何か積極的に足したいですよね。何かないかなぁ???
 うん、delmem は単位がキロです。 これ、もっと細かく指定できるようにして
欲しいです。 お願いします。memory eater はこれが出来ました。上位指定が確
かできなくて、致命的だったのだけど。 残念なことに、memory eater にはソー
スがありませんが。もちろん、16バイト単位でパラグラフにして丸めてはいま
したが。

EATMEM
http://www.vector.co.jp/soft/dos/hardware/se018057.html

> >  きゃっ! 16引くの忘れてる。これが◆の原因の一つだな。多謝です。m(__)m
> 何か理由があるんだろうなぁと思ってました。(^^;

 まったくの不注意ミスです。m(__)m

 金野アイディアの置換でようやく目途が立ちました。テキストバッファからの
転送という、文太的には、何やってんだかのハイテク。目の前のテキストをメモ
リー上(すでに変だけど)のものとして扱うのって大変ですね。ただテキストバ
ッファ(セグメント)の頭の 0d0a が今度は邪魔ものになってる。おかしいな〜、
計算が合わない。

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

(2052) 2126buf1k v0.1をテスト板に  投稿者:Konno   2007/01/29(月) 01:34
    2123 番 文太 さんへのコメント    コメント数 1

>  捨てないでぇ。

捨ててしまいました。(^^;

buf1k v0.1 です。
buf1k.asm と buf1k.com を同梱しました。
buf1k でメモリの上位に1024のバッファを取ります。実行するたびに1024増えます。
MCBエリアにIDを埋め込んだので、PSP領域を含めた1024バイト丸まる使えます。
buf1k r でメモリを開放します。バッファが複数あっても一度に開放します。

>  うん、delmem は単位がキロです。 これ、もっと細かく指定できるようにして
> 欲しいです。 お願いします。memory eater はこれが出来ました。

これはまだ出来てません。実用上は今のでほぼ足りるのではないかな。
あとは余裕があったらですね。

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

(2052) 2127Re: buf1k v0.1をテスト板に  投稿者:文太   2007/01/29(月) 02:05
    2126 番 Konno さんへのコメント    コメント数 2

金野さん、ありがと!

 ish ボードは以下です>皆さま。
 (上がってるかも、と昼間 url を調べておいたもんね。 ちょっと古だったか
ら、調べるのがけっこう大変だった。ホームページにリンク貼りましょうよ
>金野さん)

http://tamaneko.world.coocan.jp/bbs4/wforum.cgi?no=17&reno=no&oya=17&mode=msgview&fsize=&page=0

 ありがとうございました。MCBに id を持っていってくれて、もう、通じて
るぅ。そうして欲しかったのだけど、ちょっと言えなかった。最初の4しか使っ
てないわけで、あそこ。難しい、あるいはそもそも無理なのかなぁ、と。

 とにかく、落とせましたし、解凍できましたし、常駐と解除もできました。え
ーとですね、あのコンソールでの改行が1つ2つ多いと思うのですが…。Rのあと
にピリオドも欲しいです。

 (失礼をかえりみず、具体的に描くと)
------------------------------------------------------------
C:\>buf1k

buf1k ver 0.10 installed. For removal, Buf1k R


C:\>buf1k R

buf1k ver 0.10 removed


C:\>
------------------------------------------------------------

これには、こうなって欲しい。

------------------------------------------------------------
C:\>buf1k
Buf1k ver 0.10, installed. For removal, Buf1k R.

C:\>buf1k R
Buf1k ver 0.10, removed.

C:\>
------------------------------------------------------------

 ほんと親愛の情を込めてのつもりなのですが、確かc.mosさんがwingさんに
「コンソールファイルの無駄遣い」と言ったことがあったような…。


 まだここまでです。明日、試しますね。m(__)m

 histcopyって大変だぁ、と思いながら、今日も少しはこつこつしました。m(__)m

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

(2052) 2129Re^2: buf1k v0.1をテスト板に  投稿者:文太   2007/01/29(月) 15:50
    2127 番 文太 さんへのコメント    コメント数 2

delmemは何をしている?

 題。あるいは、MCBに関して、金野さんは何をした?

 ようやくどうにかこうにか、疑問の形を見定めて(輪郭を捉えて)、質問がで
きるようになったような気がするので、すいません、教えてやっていただけます
でしょうか。

 疑問は、MCBに書き込まれるオーナー名は何をする? です。

 随分前から何がどうなっているのか分からず、かといって delmem や buf1k、
あるいは 1kbuf のソースが読めるわけではないので(何というか、いちおうト
ライをするだけはしましたが…)、質問すらできなかったわけです。


 まず、vmap.docに以下のようにあります。

> ◇PSPパラメータ内のコマンド名
>
>  DOS4,5では、MCBのオフセット8以降に、コマンド名が自動的に書き
> 込まれます。したがって、VMAPVer2では、これを参照してオーナー名を
> 表示します。

 ということはMCBは MS-DOS が MS-DOS のために書く。ある意味、プログラ
ムが起動されれば自動的に書かれる。MS-DOS4、5では、オーナー名も書かれる。

 (以下、ダンプはいつもMCBを見るため、PSPの1パラグラフ前から。)

C:\>vmap
1391 <-- 1 1648 vwx 1.08b -z2 -l6144 -x1
C:\>dump -mx1390 -s32
00013900 4D 91 13 67 00 00 8D 13-56 57 58 00 00 00 00 00 |M..g....VWX.....

 おお、素直に書かれてる。

C:\>vmap
9F3D <-- 1 1024 delmem
C:\>dump -mx9f3c -s32
0009F3C0 4D 3D 9F 40 00 00 00 00-00 00 00 00 00 00 00 00 |M=檗............

 な、ない。やっぱdelmemが書き換えてる。何のため?
 (コンベンショナルの最上位ですらない、というのもポイント。最上位では、
MCBリンクの最後では、書かれないものなのかも、と思ったことがあったので。)

C:\>vmap
9F7E <-- 1 1024 buf1k ;2重起動で2kB
9FBF <-- 1 1024 ;とっている。
C:\>dump -mx9fbe -s32
0009FBE0 5A BF 9F 40 00 FF 9F 00-07 62 75 66 31 6B 0D 00 |Zソ檗.....buf1k..

 ちゃんと書かれております。vmapが表示できず、MCBリンクの最後であり、
最上位であるにもかかわらず、金野さんは、delmemが上を操作してる部分を消し
て、素直に書き込まれるように、「戻した」。(想像)★

C:\>1kbuf
C:\>vmap
9FBF <-- 1 1024
C:\>dump -mx9fbe -s32
0009FBE0 5A BF 9F 40 00 00 00 00-00 00 00 00 00 00 00 00 |Zソ檗............

 げ、な、ない。僕は、としきさんはdelmemを改造するよりスクラッチから書い
た方が早い、(いつの日にかの)文太の役に立つかも、とスクラッチから書いた
と思う。だから、別にオーナー名を操作する部分を、最低限の仕様のツールで消
したりしなかったと思う。
 では、なぜ、ない?
 きっと、この部分だけdelmemからコピペした?(空想)


 ★とはいえ、常駐解除を機能させるためには、普通PSP内の(MCBでなく)
コマンドラインが写されたところを見て、自分であることを判定してから解
除するのだろうから、ID判定部分を改変したのだろう(想像)。


 間違いがあれば、お教えいただきたいのですが。あるいは、「この知識が足り
ない」とお教えいただければ、もっと幸いです。m(_B_)m

 もちろん、一朝一夕に分かる事柄でないという程度の認識はあります。


追伸:(これが追伸というのも、とんでもないのですが m(_B_)m)
 buf1k.com、ちゃんと仕事してくれてますし、常駐解除もできてます。m(__)m
 問題はまったく発見されていません。

追伸2:常駐解除後にメモリが初期化されている云々は、PSPが綺麗に掃除さ
れているのを僕が誤解したのだ、と理解しています。PSP(の大半?)は
MS-DOS が掃除しますよね。うん、そうだ。delmem でも同じでした。

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

(2052) 2133Re^3: buf1k v0.1をテスト板に  投稿者:としき   2007/01/29(月) 22:34
参照先:http://toshiki.la.coocan.jp/
    2129 番 文太 さんへのコメント    コメント数 1

>  題。あるいは、MCBに関して、金野さんは何をした?

答は#2126にあり。

> MCBエリアにIDを埋め込んだので、PSP領域を含めた1024バイト丸まる使えます。



>  まず、vmap.docに以下のようにあります。
> > ◇PSPパラメータ内のコマンド名
> >  DOS4,5では、MCBのオフセット8以降に、コマンド名が自動的に書き
> > 込まれます。したがって、VMAPVer2では、これを参照してオーナー名を
> > 表示します。
>  ということはMCBは MS-DOS が MS-DOS のために書く。ある意味、プログラ
> ムが起動されれば自動的に書かれる。MS-DOS4、5では、オーナー名も書かれる。

これなんですけどね。
私もちょっと調べてみて根拠資料が見つけられなかったのですが。
なので、以下は各種資料の断片からまとめた推論です。
オーナー名というのは、プログラム起動時に、command.comまたはmsdos.sysが書
き込んでいるようです。つまり、メモリを確保した親プロセス側で書いていると
いうこと。ところが、上位メモリを確保しようとした場合、実際にメモリを確保
するプロセスは親プロセスではなく、delmemなり1kbufです。そして、これらのプ
ログラムにはオーナー名を書き込む機能が実装してありません。なので書き込ま
れない、というのが正解ではなかろうかと。
試しに、delmemでデフォルトというか下位メモリを確保してみて下さい。
この場合はもしかしたら、オーナー名が残っているかもしれません。
無理かな。自前で環境の開放とかいろいろとやっていそうだし。

ちなみに、かの有名なInterrupt Listも見てみました。
手元のバージョンだと、用語集でMCBを探したら「memory control block参照」と
なっていて、memory control blockを見たら「Int21h 52h参照」とたらいまわし
にあって、結局わかった事は

---DOS 4.0+ ---
08h 8 BYTEs ASCII program name if PSP memory block or DR DOS UMB,
else garbage
null-terminated if less than 8 characters

ということだけ。それ以上は英語力の壁もあって詳細不明。
DOS4以降では、PSPなメモリブロックの場合だけ名前が書き込まれる、そ
れ以外のメモリブロックではこの領域はゴミデータ、ということで、delmemなど
で確保した場合はそれ以外のメモリブロックとやらに該当するのでしょう。

>  げ、な、ない。僕は、としきさんはdelmemを改造するよりスクラッチから書い
> た方が早い、(いつの日にかの)文太の役に立つかも、とスクラッチから書いた
> と思う。だから、別にオーナー名を操作する部分を、最低限の仕様のツールで消
> したりしなかったと思う。
>  では、なぜ、ない?
>  きっと、この部分だけdelmemからコピペした?(空想)

あれ?
私、ほとんどのコードはdelmemから引っ張ってきたというか、基本的にdelmemか
ら不要と判断した部分を削除しまくる事によって1kbufを作ったはずです。
確かそう書いたような記憶もあるけど、もはや忘却の彼方。
すなわち、delmemに実装されていない機能は1kbufにもありません。
delmemに実装されていない機能を付与できるのはkonnoさんです。

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

(2052) 2140Re^4: buf1k v0.1をテスト板に  投稿者:文太   2007/01/30(火) 15:31
    2133 番 としき さんへのコメント    コメント数 1

としきさん

 詳細にありがとうございます。
 相当全体が見えたように思います。ポイントだけ引用してみます。

> ところが、上位メモリを確保しようとした場合、実際にメモリを確保
> するプロセスは親プロセスではなく、delmemなり1kbufです。そして、これらのプ
> ログラムにはオーナー名を書き込む機能が実装してありません。なので書き込ま
> れない、というのが正解ではなかろうかと。

 なるほど!

> delmemに実装されていない機能を付与できるのはkonnoさんです。

 で、ここに繋がるわけですね。

> 試しに、delmemでデフォルトというか下位メモリを確保してみて下さい。
> この場合はもしかしたら、オーナー名が残っているかもしれません。
> 無理かな。自前で環境の開放とかいろいろとやっていそうだし。

 無理でした。下位メモリでもオーナー名が残りません。
 しかしそうすると、 やっぱりオリジナル delmem が MCB を弄っていることに
なりますよね。下位からとっても MS-DOS 騙しのプロセスが入るのでしょうか?
というか、入っているはずですよね。だってオーナー名が消えてるので。

> ちなみに、かの有名なInterrupt Listも見てみました。

 だいたい分かりました。う、手元ので文脈を把握しようとしたのだけど…。
 「そこの8バイトの意味は」という文脈ですね。

> すなわち、delmemに実装されていない機能は1kbufにもありません。

 了解です。

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

(2052) 2143Re^5: buf1k v0.1をテスト板に  投稿者:としき   2007/01/30(火) 20:43
参照先:http://toshiki.la.coocan.jp/
    2140 番 文太 さんへのコメント    コメント数 1

>  無理でした。下位メモリでもオーナー名が残りません。
>  しかしそうすると、 やっぱりオリジナル delmem が MCB を弄っていることに
> なりますよね。下位からとっても MS-DOS 騙しのプロセスが入るのでしょうか?
> というか、入っているはずですよね。だってオーナー名が消えてるので。

きっと、delmemって、下位エリアに常駐する時も、きっと自前でメモリの確保を
し直しているのですよ。その際、DOSが書き込んでくれた情報ごと、旧の領域
を開放してしまっているのでしょう。少なくとも、環境変数領域は開放している
のは間違いないので、きっと、本体部分も開放している事と思われます。
で、新たに確保した部分には自分で情報を書き込んでいないのでしょう。

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

(2052) 2145Re^6: buf1k v0.1をテスト板に  投稿者:文太   2007/01/30(火) 22:23
    2143 番 としき さんへのコメント

としきさん

> ここは「1バイト目」からで正解です。
> 'M'か'Z'になるのは0バイト目です。

 ここは了解。僕が間違ってました。m(__)m

> その際、DOSが書き込んでくれた情報ごと、旧の領域
> を開放してしまっているのでしょう。少なくとも、環境変数領域は開放している
> のは間違いないので、きっと、本体部分も開放している事と思われます。

 すいません、金野さんあてにも、同じ「適切な」質問ができるように思ってい
るのですが、「開放してしまう」「旧の領域」とは最初の全メモリ占有時のこと
ではないですよね。64kのときですよね。このときPSP・MCBセットはい
くつ存在していますでしょうか。つまりどこまで MS-DOS は管理していて、どこ
から delmem 自前なのか分からないから「偽装」のからくりが見えないのです。

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

(2052) 2135buf1k の動作  投稿者:Konno   2007/01/30(火) 00:19
    2129 番 文太 さんへのコメント    コメント数 2

文太さん

としきさんが書かれているのがたぶん正解だと私も思います。なので、

>  な、ない。やっぱdelmemが書き換えてる。何のため?
>  (コンベンショナルの最上位ですらない、というのもポイント。最上位では、
> MCBリンクの最後では、書かれないものなのかも、と思ったことがあったので。)

もうお分かりかと思いますが、delmem 1u を実行すると、Vz.com以降の空きメモリに
ロードされます。そして、それ以降の9FFFh までの全てのメモリが使用中になります。
次に、delmem は、自分自身の使用メモリを64kまで縮小します。
その後で、上位1kの領域を確保します。
それから、そのPSP領域に自分自身のPSPの内容をコピーしているのではないかなぁ。
つまり、偽装しているんですね。
その後、PSPの80hにIDを埋め込んでいるようですね。
そして終了します。

> 0009FBE0 5A BF 9F 40 00 FF 9F 00-07 62 75 66 31 6B 0D 00 |Zソ檗.....buf1k..
>  ちゃんと書かれております。vmapが表示できず、MCBリンクの最後であり、
> 最上位であるにもかかわらず、金野さんは、delmemが上を操作してる部分を消し
> て、素直に書き込まれるように、「戻した」。(想像)★

ということで、delmem はMCBを一切操作していないと思います。あ、いや、1バイト目
に、9FBFh を書き込んでいるように見えますが。
・・・うう、ここでミスに気が付いてしまいました。(;_;)

>  DOS4,5では、MCBのオフセット8以降に、コマンド名が自動的に書き
> 込まれます。したがって、VMAPVer2では、これを参照してオーナー名を
> 表示します。

もしかして 1バイトずれている? 試しに1バイト手前にずらしてみたところ、
vmap でめでたく buf1k と表示されました。(^^;;

> 追伸2:常駐解除後にメモリが初期化されている云々は、PSPが綺麗に掃除さ
> れているのを僕が誤解したのだ、と理解しています。PSP(の大半?)は
> MS-DOS が掃除しますよね。うん、そうだ。delmem でも同じでした。

確かにMCBとPSPは全てヌルになっていますね。delmemではメモリの開放を呼び出して
いるだけのようなので、DOSがやっているんでしょうか。


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

(2052) 2141Re: buf1k の動作  投稿者:文太   2007/01/30(火) 17:00
    2135 番 Konno さんへのコメント    コメント数 1

金野さん

> もうお分かりかと思いますが、

 あまり、分かってはいないようですが、でもイメージがだいぶ明瞭になってきました。

> delmem 1u を実行すると、Vz.com以降の空きメモリに
> ロードされます。そして、それ以降の9FFFh までの全てのメモリが使用中になります。
> 次に、delmem は、自分自身の使用メモリを64kまで縮小します。
> その後で、上位1kの領域を確保します。

 この流れは、そういうことか! と膝を打つ気になります。
 ソースのコメントを見ていたときに頭に浮かんだ数々の???。あれらが風船の
ように割れていき…。

> それから、そのPSP領域に自分自身のPSPの内容をコピーしているのではないかなぁ。
> つまり、偽装しているんですね。
> その後、PSPの80hにIDを埋め込んでいるようですね。

 ここが分からないのですが。偽装したから「書き込み直し」という意味でしょ
うか? PSP、80hに書き込むのはプログラム自身でなく command.com か
msdos.sys ですよね。MCBのオーナー名と同じく。もちろん偽装がない標準的
なプログラムがロードされたら、ということですが。

> ということで、delmem はMCBを一切操作していないと思います。あ、いや、1バイト目
> に、9FBFh を書き込んでいるように見えますが。
> ・・・うう、ここでミスに気が付いてしまいました。(;_;)

 う??? えーと、MCB の1バイト目は、'M' か 'Z' です。PSP の3、4バ
イトに「9FBFh」を書き込んでいる、なら通じるのですが?
 ただ、 もし「delmem は MCB を一切操作していない」なら、どうして MS-DOS
5のXPで、 MCBの中に delmem の文字がないのでしょう? やはり MS-DOS
に頼らずに自前でメモリ確保をしているから? でもそうしたら、MCBだって
自分で書かなければならなくなりませんか?
 としきさんの説明と合わせて、といきたいのですが、うまく整合していないよ
うにしか理解できていません。僕の頭に何が足りないのでしょう?
 「PSPを一切操作してない」、これでいいのか…。

(以下ダンプで半角カタカナは桁がずれる原因なので、.に書き直してあります。)
-----------------------------------------------------------------------

9FBF <-- 1 1024

C:\>dump -mx9fbe -s32
      0 1 2 3
0009FBE0 5A BF 9F 40 |Z.檗 MCB
0009FBF0 CD 20 FF 9F |. .. PSP

9FBE1-2 =9FBE PSPのセグメント
9FBF2-3 =9FFF 確保されたメモリの終端セグメント

 「9FBFh を書き込んでいるように見えますが」これって、MCBのことですよね。
じゃやっぱり「MCBを一切操作してない」ってことはないのじゃないでしょうか。
「PSPを一切操作してない」でよいでしょうか。

 しか〜し、
 「その後、PSPの80hにIDを埋め込んでいるようですね」これと矛盾してしまいます。

 ああ、神よ。


 で、質問に戻ります。金野さんは、常駐確認のためのIDの場所をPSP80
hからMCB8バイト目に移しましたでしょうか。そうしてないと言われると、
すっかりわからんちんになってしまうのですが。


> もしかして 1バイトずれている? 試しに1バイト手前にずらしてみたところ、
> vmap でめでたく buf1k と表示されました。(^^;;

0009FBE0 5A BF 9F 40 00 FF 9F 00-07 62 75 66 31 6B 0D 00 |Z.檗.....buf1k..
00013900 4D 91 13 67 00 00 8D 13-56 57 58 00 00 00 00 00 |M..g....VWX.....

 ずれてますね。ただ、これだけじゃないんです。分からないのは。
 ま、僕の理解はどうあれ、新版をあげてくださいね。m(__)m

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

(2052) 2144Re^2: buf1k の動作  投稿者:としき   2007/01/30(火) 21:04
参照先:http://toshiki.la.coocan.jp/
    2141 番 文太 さんへのコメント

新版希望、という点は文太さんと同意見でして。
詳細な解説はkonnoさんからあるでしょうが、気がついたところをいくつか。

>  ここが分からないのですが。偽装したから「書き込み直し」という意味でしょ
> うか? PSP、80hに書き込むのはプログラム自身でなく command.com か
> msdos.sys ですよね。MCBのオーナー名と同じく。もちろん偽装がない標準的
> なプログラムがロードされたら、ということですが。

PSPについてのDOSの挙動は調べていないのですけど。
少なくとも、delmemは、自分自身でPSPの80hに書き込んでいます。

>  う??? えーと、MCB の1バイト目は、'M' か 'Z' です。PSP の3、4バ
> イトに「9FBFh」を書き込んでいる、なら通じるのですが?

ここは「1バイト目」からで正解です。
'M'か'Z'になるのは0バイト目です。
ビッグエンディアンとかリトルエンディアンというやつのからみで混乱している
ように見受けられます。このへんは複雑ですからねぇ。
#でも、文太さんならガリバー旅行記を原語で読んでいそう。

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

(2052) 2146Re: buf1k の動作  投稿者:文太   2007/01/30(火) 22:38
    2135 番 Konno さんへのコメント    コメント数 1

 どう質問すればいいか分かりました。

(1) delmem 1u を実行すると、Vz.com以降の空きメモリにロードされます。
(2) それ以降の9FFFh までの全てのメモリが使用中になります。
(3) delmem は、自分自身の使用メモリを64kまで縮小します。
(4) 上位1kの領域を確保します。
(5) そのPSP領域に自分自身のPSPの内容をコピーしているのではないかなぁ。

 上の5つのステップでMCBとPSPはどうなっているのでしょう?
 (5)が昨晩もまったく読めませんでした。PSPはこの時点でいくつあるんでしょう?

 (1)(2)でMCB、PSP1セット。(MS-DOSが作る)
(3)勝手にやってるんだからMS-DOSは関知しない?
(4)これもdelmemが自前でやってる。
(5)げ、(1)(2)ステップでMS-DOSが作ったものしか存在していない。それをコピー?
 (1)(2)と(5)では場所が違うだけ。で、(1)(2)ステップがとしきさんのいう
 「旧の領域」。またMCBはPSPの在処とMとZだから、ここは自分で書いて
  いる。その際、オーナー名を書くことまでしていない。こういうことでしょう
  か。

しかしこうだとすると、MCBはdelmemが自前で書いていることになりませんか?
っていうか、PSP及び本体の場所を示すのがMCBなら、そこはdelmemが管理し
なくてはMS-DOSが騙せませんよね。

合ってますかねぇ?

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

(2052) 2147Re^2: buf1k の動作  投稿者:Konno   2007/01/31(水) 00:17
    2146 番 文太 さんへのコメント    コメント数 1

文太さん、としきさん、マトレスで失礼します。

> > ここは「1バイト目」からで正解です。
> > 'M'か'Z'になるのは0バイト目です。
>  ここは了解。僕が間違ってました。m(__)m

そ、そうでしたっけ、てっきりまた間違えたかと思いました。(^^;
1か0かというのは難しいですね。(^^;

>  上の5つのステップでMCBとPSPはどうなっているのでしょう?

私も想像で物を言っているので鵜呑みにしないほうが良いですが、

PSPとは、COMファイルの先頭256バイトそのものです。これがそのままロードされると。
だから、delmemが独自に確保した領域にPSPがあるはずがないのです。

MCBはDOSが管理しなければ、メモリの確保も開放もうまく出来ないのは火を見るより
明らかだと思います。だから、M や Z は DOSがセットしているのだと思います。
メモリの確保や開放はINT21hでやる限りは全てDOSが実行・管理していると考えた
ほうがいいでしょう。

delmem で下位メモリのMCBにオーナー名が無いのは謎でしたが、ソースを見ると、
自分自身のプログラムコードを別の場所にコピーしてそこにジャンプしている
ようです。その後で、元のPSP先頭部分からのメモリを、開放、再確保している
のではないかと思われます。

PSPの80hにIDを書き込んでいるのも理由が有りました。コマンドラインの文字列は
MCBの8バイト目から書き込まれますが、ここには8バイトしか入りません。
オプションなど、長くて入りきらない部分はどこへ行くのか、と思ったら、
PSPの80hから続きが書き込まれているんですね。
TAGLIGHT とか、KB16 を見ればそうなっています。
VWX や、VZ はdelmem と同じように自分で80hに書き込んでいるのでしょう。

さて、ここまでで、納得いかない点はありますでしょうか。

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

(2052) 2148Re^3: buf1k の動作  投稿者:Konno   2007/01/31(水) 00:42
    2147 番 Konno さんへのコメント    コメント数 1

> PSPとは、COMファイルの先頭256バイトそのものです。これがそのままロードされると。

うう、おもいっきり間違えていました。PSPはロードされた時にDOSが作っている
んでしたね。なんでこんな思い込みしたかなぁ。(;_;)

まあ、COMプログラムがロードされた時ということで、

> だから、delmemが独自に確保した領域にPSPがあるはずがないのです。

結論のつじつまは合うと思うんですが。(^^;

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

(2052) 2149Re^4: buf1k の動作  投稿者:文太   2007/01/31(水) 01:54
    2148 番 Konno さんへのコメント    コメント数 1

金野さん

 ソース解析等、ありがとうございます。僕は僕の空想の中で割と落ち着くべき
ところに落ち着いてしまっていて、「納得いかない点」は今はとりわけ見つかっ
ていません。明日、また少しゆっくり考え直してみるつもりですが。

> PSPとは、COMファイルの先頭256バイトそのものです。これがそのままロードされると。
> だから、delmemが独自に確保した領域にPSPがあるはずがないのです。

 「おもいっきり外してる」という訂正が入っているのは分かっているのですが、
ただ、この言い方もありではないのでしょうか。普通プログラムって、com モデ
ルでは、org 100h でしょ。 ここ、PSPに入ってね、というつもりなのではな
いですか。まったく外れていますでしょうか。

 あと一点。delmem にはコード自体がない、というのもおかしいですが、結果
としてはコードはなく MS-DOS に頼んで確保したメモリ量だけが大切なプログラ
ムですよね。だから、といっていいのか分かりませんが、PSPも自分の確保し
た領域と一緒にして計算しなくちゃいけませんよね。辻褄合いませんか?

> MCBはDOSが管理しなければ、メモリの確保も開放もうまく出来ないのは火を見るより
> 明らかだと思います。だから、M や Z は DOSがセットしているのだと思います。
> メモリの確保や開放はINT21hでやる限りは全てDOSが実行・管理していると考えた
> ほうがいいでしょう。

 はい、分かってない奴がこういうのもなんですが。ただやっぱり騙してません
か。MS-DOS が作ってくれたMCBを改竄してないでしょうか。ソースにそんな
とこない? いえ、こう思ったのは、常駐方法がオプションで色々あり(サイズ
の小さいのもまとめてとか)、途中で全部とって64kにしてとなると、いくつ
もMCBリンクが MS-DOS によって貼られるよな、これを、たとえば、delmem
の目的にしたがって(最下位、最上位とか)調整するわけでしょ。だったら、M,
Z までは分からないけど、整理してないとおかしい、と空想していたのですが。


 「Vz、VWXは自分でオーナー名を書いてるだろう」僕もそう思うようにな
りました。

> ◇PSPパラメータ内のコマンド名
>
>  DOS3では、TSRが環境エリアを解放すると、コマンド名が取得できなく
> なります。このため、TSRの多くは、PSPのパラメータエリアに、自身のコ
> マンド名をコピーしています。
>  DOS4,5では、MCBのオフセット8以降に、コマンド名が自動的に書き
> 込まれます。したがって、VMAPVer2では、これを参照してオーナー名を
> 表示します。こうなると、パラメータエリアにコピーされたコマンド名が重複し
> て表示される場合がありますから、パラメータエリアの先頭がスペース以外であ
> れば、次のスペースまでをスキップしています。
(vmap.doc)

 こんなドックからです。「環境エリアの解放」がけっこうネックだと思うので
すが、僕にはまだ分かりません。が、この書き方からして、常駐解除が必要なら、
当然、パラミータエリアに自分で書きますよね、きっと。
 これで、としきさん宛てに、「ここに書きたければ書け」という MS-DOS の半
端な親切、と書きました。

PSP 80h

0   1 2 3 4 5 6 7 8 9 A
文字数 パラミータ 文字列 0dh

 がフォーマットですが、「オプションの残り」? ですか? MCBの8バイト目
から(オーナー名)とは連動してませんよね。

taglightって常駐アプリなの?(独り言です)使ってないんですけど。



 あのぅーーー。一番単純な質問。常駐解除のための確認のIDの場所、PSP
からMCBへ変更なさってますよね? してないの〜? (T-T)
 も、もしかして、ぜんぜんとんちんかんなのかなぁ。



> delmem で下位メモリのMCBにオーナー名が無いのは謎でしたが、ソースを見ると、
> 自分自身のプログラムコードを別の場所にコピーしてそこにジャンプしている
> ようです。その後で、元のPSP先頭部分からのメモリを、開放、再確保している
> のではないかと思われます。

 関係ないかもしれませんが、最上位にとったとき、そしてその後ダンプすると、
そのパラミータがPSPの例の80hのところに部分的に書き込まれます。いえ、
delmemが上書きして書き直したみたいに見えました。何度も見た。「カレント
PSP?」とか前に書いたときも見ました。どうも現象の規則性が見えないのですが。

 PSP80hはdelmemが書いてる。根拠もロジックもソース読みもなく、賛成
です。

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

(2052) 2152Re^5: buf1k の動作  投稿者:としき@会社   2007/01/31(水) 13:44
参照先:http://toshiki.la.coocan.jp/
    2149 番 文太 さんへのコメント    コメント数 1

あぅ〜、文太さんの理解が進むにしたがってというか、私のほうもだんだんわか
ってきました。

> ルでは、org 100h でしょ。 ここ、PSPに入ってね、というつもりなのではな
> いですか。まったく外れていますでしょうか。

あっていると思います。

>  あと一点。delmem にはコード自体がない、というのもおかしいですが、結果
> としてはコードはなく MS-DOS に頼んで確保したメモリ量だけが大切なプログラ
> ムですよね。だから、といっていいのか分かりませんが、PSPも自分の確保し
> た領域と一緒にして計算しなくちゃいけませんよね。辻褄合いませんか?

ここはその通りだと思います。

>  はい、分かってない奴がこういうのもなんですが。ただやっぱり騙してません
> か。MS-DOS が作ってくれたMCBを改竄してないでしょうか。ソースにそんな

そんなとこは、私がソースを読んだ限りでは見つけられませんでした。

> とこない? いえ、こう思ったのは、常駐方法がオプションで色々あり(サイズ
> の小さいのもまとめてとか)、途中で全部とって64kにしてとなると、いくつ
> もMCBリンクが MS-DOS によって貼られるよな、これを、たとえば、delmem
> の目的にしたがって(最下位、最上位とか)調整するわけでしょ。だったら、M,
> Z までは分からないけど、整理してないとおかしい、と空想していたのですが。

DOSのファンクションコールを使って調整していますから、全てDOSの管理
下にあるわけです。

> > ◇PSPパラメータ内のコマンド名
> >
> >  DOS3では、TSRが環境エリアを解放すると、コマンド名が取得できなく
> > なります。このため、TSRの多くは、PSPのパラメータエリアに、自身のコ
> > マンド名をコピーしています。
> >  DOS4,5では、MCBのオフセット8以降に、コマンド名が自動的に書き
> > 込まれます。したがって、VMAPVer2では、これを参照してオーナー名を
> > 表示します。こうなると、パラメータエリアにコピーされたコマンド名が重複し
> > て表示される場合がありますから、パラメータエリアの先頭がスペース以外であ
> > れば、次のスペースまでをスキップしています。
> (vmap.doc)

こんな文章があったのね。これはわかりやすい気がする。
文太さんは、これのどこがわかりませんか?
う〜んと、PSPのパラメータエリアというのが80hですよね。
ここに名前を書き込むのはTSRというか各プログラムの仕事です。
DOSが新しいバージョンになっても、ほとんどのTSRはバージョンによって
挙動を変えるということをせずに、PSP80hに書き込み続けています。
そりゃそうですよね、DOS3の時代に作られてその後バージョンアップしなけ
れば当然そうなります。
一方、DOSは新しいバージョンになったので、自分の仕事を変更しました。
つまり、MCB8hにも書き込んでくれるようになりました。
その結果、同一の情報(プログラム名)がダブって記録されています。
vmapは、その両方の情報を取得してしまうのですが、両方表示すると見た目がよ
くないので、小技を使って少しでも見栄えをよくしているわけです。
・・・といったところでよろしいでしょうか。
何がわからないのかわかれば説明できるのですが。

>  あのぅーーー。一番単純な質問。常駐解除のための確認のIDの場所、PSP
> からMCBへ変更なさってますよね? してないの〜? (T-T)

これは、変更しているように私にも思えるのですが、konnoさんの確認待ち。

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

(2052) 2153Re^6: buf1k の動作  投稿者:文太   2007/01/31(水) 18:30
    2152 番 としき@会社 さんへのコメント    コメント数 1

としきさん

> あぅ〜、文太さんの理解が進むにしたがってというか、私のほうもだんだんわか
> ってきました。

 ご謙遜なのか、ご冗談なのかの判別すらつきませんが、そう言っていただける
と、とても嬉しいです。m(__)m
 「あぅ〜」にどういう感情がこもっているのかは分かりませんでしたが。

> >  はい、分かってない奴がこういうのもなんですが。ただやっぱり騙してません
> > か。MS-DOS が作ってくれたMCBを改竄してないでしょうか。ソースにそんな
>
> そんなとこは、私がソースを読んだ限りでは見つけられませんでした。
> DOSのファンクションコールを使って調整していますから、全てDOSの管理
> 下にあるわけです。

 なるほど、これはとても分かりやすい。僕の「分かる」はイメージだけです。
ですから、お二人とは全然違うのですが、それでも「分かった」。
 そもそもストラテジの変更は MS-DOS の想定内(う、この言葉)、と表現して
よいのでしょうか。


> その結果、同一の情報(プログラム名)がダブって記録されています。
> vmapは、その両方の情報を取得してしまうのですが、両方表示すると見た目がよ
> くないので、小技を使って少しでも見栄えをよくしているわけです。
> ・・・といったところでよろしいでしょうか。

 よろしいと思います。これも分かります。

> >  あのぅーーー。一番単純な質問。常駐解除のための確認のIDの場所、PSP
> > からMCBへ変更なさってますよね? してないの〜? (T-T)
> これは、変更しているように私にも思えるのですが、konnoさんの確認待ち。

 確認待ちです。っていうか、そうじゃないと辻褄合いませんよね。
 で、何行目あたりですか? >金野さん いちおうは眺めようとしたのだけど。
 リトルエンディアンなとこでの、金野さんの「あうっ」の意味も分かりました。
 オーナー名の1バイトずれのことです。
 m(__)m

 というわけで、全体的にはさばさばしてしまっています。m(__)m

 つまり分かるべきことと(あくまでイメージ)、それはソース読まなくては分
からないよ、が区別できたらしいです(らしい、ってねぇ、あんた)。それでも、
いちおう書いておくと、 (知ってると思いますが) 、真面目に取り組んでます
(組んできてます)よ。真面目っていうか、ほとんど必死に。


 さて、ヒストバッファと保存バッファの共存を考えなくちゃ。まだあるの?(^^;


 追伸:(誰宛? )ついに『MS-DOS メモリ管理作法』(だっけ?)が図書館に
届きました。国会図書館にもなかったって。

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

(2052) 2154Re^7: buf1k の動作  投稿者:Konno   2007/02/01(木) 00:40
    2153 番 文太 さんへのコメント    コメント数 1

>  あのぅーーー。一番単純な質問。常駐解除のための確認のIDの場所、PSP
> からMCBへ変更なさってますよね? してないの〜? (T-T)

#2126 の buf1k V0.1 の説明で

> MCBエリアにIDを埋め込んだので、PSP領域を含めた1024バイト丸まる使えます。

と書いたのですが、わかりにくかったですかねぇ。その前はPSPの7バイト目あたりに
IDを埋め込んでいたので、この領域の16バイトは使えなかったのだから、MCBへ変更
したのはわかるとおもったんですが。というか、文太さんはダンプで何度も見てるん
だから何が変ったかわかっているはずです。

>  で、何行目あたりですか? >金野さん いちおうは眺めようとしたのだけど。

大体258行目あたりでしょうか。そこだけコメントを書いてみました。

;-----------------------------------------------------------
set_id_mcb PROC ;IDの埋め込み
dec ax
mov es, ax ; MCBセグ
inc ax ;+1でPSPセグ
mov word ptr es:[1], ax ;MCB1バイト目に書き込み
push ax
add ax,word ptr parag_size_get ;バッファサイズパラグラフを
mov di, 5 ;MCB.5に
stosw ;書き込み
mov di, 7 ;MCB.7に
mov al, len_str_id ;IDのサイズを
stosb ;書き込み
mov si, offset str_id ;IDのオフセット
mov cx, len_str_id ;IDのサイズ
dec cx ;-1
dec cx ;-1
rep movsb ; MCB.8からID書き込み

------------------------------------------------------------------------

ここは、delmem ではPSPの80hに書き込むルーチンだったと思います。


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

(2052) 2156Re^8: buf1k の動作  投稿者:文太   2007/02/01(木) 11:14
    2154 番 Konno さんへのコメント    コメント数 1

金野さん

 ご丁寧にどうもありがとうございます。m(__)m

> というか、文太さんはダンプで何度も見てるん
> だから何が変ったかわかっているはずです。

 うーん、これは、すいません、金野さん、想像力が足りませんよ。す、すいま
せん、こんな場面においてさえ暴言を吐いて。何が、何のために変わったか、推
測と想像と空想がごちゃごちゃになるものなんですよ。で、間違う。間違うはず
のない事柄に関して、間違うはずのない人に向かって「間違ってませんか」って
言い出す。「暴言でした」と謝る。そんなもんなんですよ。知らないはずないと
思うのですが。m(__)m
 ここでも「はず」がきつすぎるとは思いますが。

 ソースのコメント付け、ありがとうございました。分かる!!! 嬉しい!!
勢いでオリジナルdelmem読んじゃうか?! ないな、それは、さすがに(~_~;

 でも、理由は明らかでないのですが、何か「分かっちゃったのよ」爽快感に包
まれてしまっています。2日前から? お二人のお陰です。m(_B_)m ありがとう
ございます。うるうる。無気味な幸福感だなぁ。

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

(2052) 2157buf1k v0.2  投稿者:Konno   2007/02/02(金) 00:09
    2156 番 文太 さんへのコメント    コメント数 2

>  うーん、これは、すいません、金野さん、想像力が足りませんよ。す、すいま
> せん、こんな場面においてさえ暴言を吐いて。何が、何のために変わったか、推
> 測と想像と空想がごちゃごちゃになるものなんですよ。で、間違う。間違うはず
> のない事柄に関して、間違うはずのない人に向かって「間違ってませんか」って
> 言い出す。「暴言でした」と謝る。そんなもんなんですよ。知らないはずないと
> 思うのですが。m(__)m

はい、おそらく混乱しているのだろうとは思ってました。だからちょっと変えて、
「 というか、文太さんはダンプで何度も見てるんだから何が変ったかは見ている
はずです。」
のほうがよかったですね。見てはいたが、混乱していたので、あれ?どうだったっけ
となったのかなと。

>  ソースのコメント付け、ありがとうございました。分かる!!! 嬉しい!!
> 勢いでオリジナルdelmem読んじゃうか?! ないな、それは、さすがに(~_~;

私も読めないソースを改造する時はまずコメントを調べながら付けまくります。
そうするとなんとなく全体の流れとかわかってくるものです。それを繰り返して
だんだん覚えてきたと。

>  でも、理由は明らかでないのですが、何か「分かっちゃったのよ」爽快感に包
> まれてしまっています。2日前から? お二人のお陰です。m(_B_)m ありがとう
> ございます。うるうる。無気味な幸福感だなぁ。

こういう時って有りますよね、自分のレベルが一段上がったような感覚。
いよいよ隔離病棟に両足突っ込んだようですね。もう後戻りは出来ません。(^^;
ここは世間の流れとは完全に乖離してますからね。びすたがどすた!!

というのはともかく、テスト板にbuf1k v0.2 をアップしました。
vmap でのオーナー名表示とソースのコメント追加だけですが。

#t18

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

(2052) 2158Re: buf1k v0.2  投稿者:文太   2007/02/02(金) 00:56
    2157 番 Konno さんへのコメント

金野さん

 きたきた!

> 見てはいたが、混乱していたので、あれ?どうだったっけ、となったのかなと。

 そんな感じです。「PSPからMCBに移してくれたら、PSPも全部領域に
使えるんだよなぁ」と夢想していたこともあったわけで。m(__)m

> 私も読めないソースを改造する時はまずコメントを調べながら付けまくります。
> そうするとなんとなく全体の流れとかわかってくるものです。それを繰り返して
> だんだん覚えてきたと。

 なるほど、なるほど。そうやって。Vzのソースはどこからどこまでお済みで
すか、ってずるいか。うーん、「あくまで文字列の操作」とテーマを絞るとする
と、string.asm, char.asm がお勧めですでしょうか。その前に vz.inc でしょ
うけど。
 僕も、大きい声では言えませんが(おい)、1kbuf のファンクションコールだ
け.shdからメモって、プリントアウトはしてあるのですが…。「勉強しろよな」
って恫喝されちゃったし。

 (余談ですが、VWX のソース、あったらよかったですね。でも、あの言語で正
規表現置換を常駐したまま行なうって、やっぱ半端じゃないですね。ソースあっ
ても、手も足も、かな。Cとかだったら当時からライブラリ的に存在してました
けどね。)

> こういう時って有りますよね、自分のレベルが一段上がったような感覚。
> いよいよ隔離病棟に両足突っ込んだようですね。もう後戻りは出来ません。(^^;
> ここは世間の流れとは完全に乖離してますからね。びすたがどすた!!

 もちろん、ビスタな現実など関係ありません。面倒みてきたXPが3台はあり
ますから、マシンには困りませんし。「そろそろビスタに乗り換えたら」とか言
って入手は実に容易。壊れてる2台を直すのが先だったりするし。うーん、でも
困りますねぇ。いえ、ストリング命令を無理やり直訳のポインタで処理しようと
した時としきさんがサンプル書いてくれて、何て言うかロジックの先読みが筋っ
て教えてくれたのです。その時も僕はぶつぶつ文句言ってたのだけど。そして今
回も(こんなこと言えるほど読めてないのですが)、先に特定レジスタを使う処
理に合わせて組み上げていってるのが見えたとき、そしてその意味が金野さんの
コメントで確認できたとき、う、俺にも無理ではないな、と思ってしまった。あ
るいは先行していた思いを確認してしまった。認識は常に再確認として現れる。

> というのはともかく、テスト板にbuf1k v0.2 をアップしました。
> vmap でのオーナー名表示とソースのコメント追加だけですが。

 うふ。落とさせていただきます。m(__)m

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

(2052) 2159Re: buf1k v0.2  投稿者:文太   2007/02/03(土) 14:01
    2157 番 Konno さんへのコメント    コメント数 1

金野さん

 Buf1k02+MASM6なのですが、大昔に出会ったことがあるようなエラーメッセージ
が出ます。
 どう対処するのが正しいのでしょう。お教えいただけますか。

C:\>Ml BUF1K.asm >err.txt

Assembling: BUF1K.asm
BUF1K.asm(348) : error A2071: initializer magnitude too large for specified size
BUF1K.asm(351) : error A2071: initializer magnitude too large for specified size


-----------------------------------------------------------------------------
348
str_usage db LF,"buf1k ver ",VER_NO
db " installed. For removal, Buf1k r.",CR,LF

351
str_remove db LF,"buf1k ver ",VER_NO
db " removed",CR,LF

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

(2052) 2160buf1k@MASM6  投稿者:文太   2007/02/03(土) 21:26
    2159 番 文太 さんへのコメント    コメント数 2

Ml /Zm		;Enable MASM 5.10 compatibility

 でなんとかなりました。驚いたのは、たしかに、(たぶん)lldのせいで、
ファイルサイズが違うこと。
 こ、こんなに。ソース間違えてませんよ。

BUF1K.COM 755 2007-02-01 23:07
BUF1K.COM 695 2007-02-03 18:25 ;文太アセンブル(with lld.exe)

 ただ、あれがどうしていけないのか、が分かりませんね。どう書けっていう
んでしょう?


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

(2052) 2161Re: buf1k@MASM6  投稿者:文太   2007/02/03(土) 22:08
    2160 番 文太 さんへのコメント

 メッセージだけ書き換え成功!

C:\>buf1k
Buf1k ver 0.21, installed. For removal, Buf1k r.

C:\>buf1k r
Buf1k ver 0.21, removed.

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

(2052) 2162Re: buf1k@MASM6  投稿者:Konno   2007/02/04(日) 00:04
    2160 番 文太 さんへのコメント    コメント数 1

文太さん

> Ml /Zm ;Enable MASM 5.10 compatibility
>  でなんとかなりました。驚いたのは、たしかに、(たぶん)lldのせいで、
> ファイルサイズが違うこと。

すみません、MASM6でも確認したつもりが、5.1のobjが残っていたせいで勘違い
してしまいました。m(__)m

VER_NO equ "0.20"
str_usage db LF,"buf1k ver ",VER_NO
str_remove db LF,"buf1k ver ",VER_NO

これでバージョンナンバーを設定してるんですが、この書き方だとMASM6では数値と
してみなされてしまうんですね。

str_usage db LF,"buf1k ver VER_NO"
str_remove db LF,"buf1k ver ","VER_NO"

このように文字列として扱ってやればいいようです。


> BUF1K.COM 755 2007-02-01 23:07
> BUF1K.COM 695 2007-02-03 18:25 ;文太アセンブル(with lld.exe)

う〜ん、こんなに違うとは。空のデータを圧縮しているのだと思いますが、
ファイルサイズを小さくしたいなら、LLD.EXEがいいということですね。

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

(2052) 2163Re^2: buf1k@MASM6  投稿者:Konno   2007/02/04(日) 00:13
    2162 番 Konno さんへのコメント    コメント数 1

> このように文字列として扱ってやればいいようです。

げげげ、アセンブルが通ったと思ったら、VER_NO がそのまま表示されてた。
すみません、いい加減なことを言って。

う〜ん、やっぱり5.1互換でやるしかないかなぁ。

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

(2052) 2164Re^3: buf1k@MASM6  投稿者:Konno   2007/02/04(日) 00:32
    2163 番 Konno さんへのコメント    コメント数 1

> う〜ん、やっぱり5.1互換でやるしかないかなぁ。

わかった!! VZ.INCをみればいいんだ!!

VERSION_MAJOR equ <'t03 testd kVZ '>
MY_VERSION equ <'k08Q5 '>
VERSION equ <'t03k d10 ',MY_VERSION>

VZ.INC ではこんなふうにしていますね。だから、

VER_NO equ <'0.20'>

str_usage db LF,"buf1k ver",VER_NO
str_remove db LF,"buf1k ver ",VER_NO

こうすれば、どちらでも問題なくアセンブルできますよ。
てか、自分で弄っているのにわかってなかったのか、おのれ(゜゜)☆\(--#)バキッ

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

(2052) 2165Re^4: buf1k@MASM6  投稿者:文太   2007/02/04(日) 01:36
    2164 番 Konno さんへのコメント    コメント数 1

金野さん

> わかった!! VZ.INCをみればいいんだ!!

 すべての教科書! ありがとうございます。ものすごく勉強になりました。

 実は、例の固定バッファ・ルーチンをもうちょい洗練させるべく、受け取り先
をいちおう4つ確保しようとして、こんなことになり、

; di=pr, ;set input
; q=pq..134, ;tmpbuf (256up)
; q=pq..135, ;tmpbuf2(256)
; q=pq..136, ;tmpbuf3(wd*2 bytes = 80*2)
; q=pq..149, ;tmpbuf4(256)
; q=pq..137, ;pathbuf (64)
q=pq..138, ;pathbuf2 (64)
di=q,

 Vz ソースディレクトリをグレップしたりしてました。
 変数なんですよ、、読み解くべきは。下手したら読めてしまうかもしれない。
 こ、こわい。深入りしないのが一番だ。でも魔界を見てしまいましたぁ。

 金野さんのせいです。僕の人生をどうしてくれるのです! ………

 寝よ。なんだか人生が楽しくなってしまった。いいのかなぁ。

 僕は、環境変数の勉強をすることにしたのだったんだ。寝よ、寝よ。

 追伸: push,pop の辻褄が合わないことがあんなに恐いことだとはしりません
でした。アセンブラの話。「メモアロ」と1時間、15回くらいつき合ってしま
いました。XPでも、やっぱりめげますよね。全部止まりやがると。
 サブリナがいけないのでも、tmpbuf4に問題があるのでもなく、辻褄が合ってな
かったのでした。

 追伸2:こういうことを軽く言う奴で申し訳ないのですが、そろそろログ上げ
ませんか? はい、自分で管理すべく、巡回ツールについて検討中です。

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

(2052) 2168[全部表示] はほぼFGAL形式  投稿者:Konno   2007/02/04(日) 15:09
    2165 番 文太 さんへのコメント    コメント数 1

>  Vz ソースディレクトリをグレップしたりしてました。

正しい歩みですね。(^^; 私は毎日のようにグレップしてます。(^^;

>  追伸: push,pop の辻褄が合わないことがあんなに恐いことだとはしりません
> でした。アセンブラの話。「メモアロ」と1時間、15回くらいつき合ってしま
> いました。XPでも、やっぱりめげますよね。全部止まりやがると。

OSごと止まったんですか? マクロのプッシュポップは安全装置が有りますからねぇ。
マシン語で固まった時は真っ先に疑うようになりましたね。

>  追伸2:こういうことを軽く言う奴で申し訳ないのですが、そろそろログ上げ
> ませんか? はい、自分で管理すべく、巡回ツールについて検討中です。

もう過去ログに行ってしまいましたが、#1809 からのツリーに書いたように、
この現在のログなら、新着ページの上部の、[全部表示]のリンクからの表示が
ほぼFGALDC形式になっています。このページでファイルメニューの「名前をつけて
保存」を実行し、テキスト形式で保存すれば、NIFP で読めるログが出来ます。

過去ログもツリー上部に、[全部表示]リンクが有ります。
お急ぎの方はこれでどうでしょうか。(^^;
もし、この形式で読めない時は教えて下さい。

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

(2052) 2175Re: [全部表示] はほぼFGAL形式  投稿者:文太   2007/02/04(日) 23:19
    2168 番 Konno さんへのコメント    コメント数 1

金野さん

> 私は毎日のようにグレップしてます。(^^;

 やっぱり。

> 正しい歩みですね。(^^;

 いえ、文太的には…。

> OSごと止まったんですか? マクロのプッシュポップは安全装置が有りますからねぇ。
> マシン語で固まった時は真っ先に疑うようになりましたね。

 いえいえ、MS-DOS窓だけです。マクロの安全装置のありがたみが今頃。
 「全部」っていうのは「窓が」という意味でした。マクロだと下手なことをしても、
死ぬのはVzだけってこともあるじゃないですか。それで、マクロを試しただけなのに
MS-DOSまで死ぬなよ、と。ま、「そのマクロMS-DOSを殺せるのよ、簡単に。マシン語
なんですから」と思い出しました。

 「真っ先に」。m(__)m これが正しい歩みですね。

> もう過去ログに行ってしまいましたが、#1809 からのツリーに書いたように、
> この現在のログなら、新着ページの上部の、[全部表示]のリンクからの表示が
> ほぼFGALDC形式になっています。このページでファイルメニューの「名前をつけて
> 保存」を実行し、テキスト形式で保存すれば、NIFP で読めるログが出来ます。

 おお、ログをまったく読んでないやつで。m(__)m

> 過去ログもツリー上部に、[全部表示]リンクが有ります。
> お急ぎの方はこれでどうでしょうか。(^^;
> もし、この形式で読めない時は教えて下さい。

 まだ落としていませんが、すぐに。何か、今日は急に色々あって。m(__)m
 そういう意図で、FGAL復活だったのですね。冗談だと思ってました。すい
ません。これは嬉しいぞ。

 モバとかでソースなんて読みたくないので、std.inc, vz.inc, main.asm プリ
ントアウトしちゃいましたよ。これから移動の多い季節なので。季節労働者です。


 しかし、うん。まったくもって僭越で突飛な話なのですが。m(__)m
 さっきお風呂で思いついたのです。金野さん、金野さんは何かをオリジナルで
作るべきですよ。べき、なんちゃって。
 でも、ほんと、自分のために。 自分のためだけに。スクラッチから。.com で
も .exe でも .def でも。いえいえ、Vzユーザとしては、Vzを進化させてく
れないと困るのですが、でも、何か自作ものを。そのための改造修行です。
 ほんと、 それこそVzのためにも。 もしかして、僕はVzをなめてるかな?
いや、金野さんは金野さんのために。

 余計なことを、たくさん。失礼しました。m(_B_)m

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

(2052) 2177Re^2: [全部表示] はほぼFGAL形式  投稿者:Konno   2007/02/05(月) 01:11
    2175 番 文太 さんへのコメント    コメント数 1

>  モバとかでソースなんて読みたくないので、std.inc, vz.inc, main.asm プリ
> ントアウトしちゃいましたよ。これから移動の多い季節なので。季節労働者です。

やっぱり正しい歩みだ。(^^; あれ?モバで見ないんですか。高橋さんはLXでVZ.COMを
アセンブルしてましたよ。って私もLXはログ読みにしか使ってないですが。(^^;

>  でも、ほんと、自分のために。 自分のためだけに。スクラッチから。.com で
> も .exe でも .def でも。いえいえ、Vzユーザとしては、Vzを進化させてく
> れないと困るのですが、でも、何か自作ものを。そのための改造修行です。

自作ものを作る目的で改造修行してるならいいんですが、私は何も無いので。
それよりも、今有るものをもっと便利にしたいと言う欲求が強いんですね。

VZもNP2も掲示板CGIも弄ればもっともっとよくなる可能性を秘めていて、しかも
ソース付きなので、わかるところだけ弄っているわけです。ゼロから何かを作る
ほどのスキルは有りませんよ。

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

(2052) 2183Re^3: [全部表示] はほぼFGAL形式  投稿者:文太   2007/02/05(月) 21:40
    2177 番 Konno さんへのコメント

金野さん

> VZもNP2も掲示板CGIも弄ればもっともっとよくなる可能性を秘めていて、しかも
> ソース付きなので、わかるところだけ弄っているわけです。ゼロから何かを作る
> ほどのスキルは有りませんよ。

 面倒な言いがかりに、ご丁寧にどうも。m(__)m
 スキルがない、というのは、正しくないですが。やっぱ、後からついてくるものみ
たいな気がしていますので。
 ま、改造の可能性が面白くて、というので、相手がVzだったりしたら、そうかな、
とも少し思います。僕が何かを言うような事柄でもないし。ただ、なんとなく違うと
ころで違うことをやったら、とふと思ってしまったものですから。それがVzに返って
くるかなと。どうも失礼いたしました。

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

(2052) 2134Re^2: buf1k v0.1をテスト板に  投稿者:Konno   2007/01/29(月) 23:03
    2127 番 文太 さんへのコメント    コメント数 1

>  ish ボードは以下です>皆さま。
>  (上がってるかも、と昼間 url を調べておいたもんね。 ちょっと古だったか
> ら、調べるのがけっこう大変だった。ホームページにリンク貼りましょうよ

そういえばトップページにテスト板などへのリンクが無かったかも。最近は
「タマ猫BBS(リンク集)」からしかアクセスしないもので。
http://tamaneko.world.coocan.jp/tamabbs.cgi

このページはうちの掲示板群の更新情報がわかるのでお薦めです。
このURLをお気に入りに入れておけば幸せになれるかも。(ほんとか)

近々サイトをリニューアルしたいと思っているので、この掲示板やVZの部屋
のURLが変ると思います。トップや上記のURLは変らないので今のうちに
ブックマークしておきましょう。(^^;

>  ありがとうございました。MCBに id を持っていってくれて、もう、通じて
> るぅ。そうして欲しかったのだけど、ちょっと言えなかった。最初の4しか使っ
> てないわけで、あそこ。難しい、あるいはそもそも無理なのかなぁ、と。

どうせやるならここまでやりたいと思ってはいたんですが、今回MCBというものが
少し判ったので、やってみたら出来てしまったわけです。

> ーとですね、あのコンソールでの改行が1つ2つ多いと思うのですが…。Rのあと
> にピリオドも欲しいです。

改行は気にしてませんでした。直しておきます。Rの後のピリオドは紛らわしい
かと思ったんですが、使うのは文太さんだけだろうし、まあいいか。

>  ほんと親愛の情を込めてのつもりなのですが、確かc.mosさんがwingさんに
> 「コンソールファイルの無駄遣い」と言ったことがあったような…。

これ、どこかで読んだような気がしますが、気のせいかなぁ。(^^;

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

(2052) 2139Re^3: buf1k v0.1をテスト板に  投稿者:文太   2007/01/30(火) 01:40
    2134 番 Konno さんへのコメント

金野さん

> このページはうちの掲示板群の更新情報がわかるのでお薦めです。

 ほんとだ。小さい字で内容もある!

> このURLをお気に入りに入れておけば幸せになれるかも。(ほんとか)

 僕は、自作唯一のhtmlファイル、local_home.htmというところで管理しています。
 すでに入ってますから、安心です。

> 近々サイトをリニューアルしたいと思っているので、この掲示板やVZの部屋
> のURLが変ると思います。トップや上記のURLは変らないので今のうちに
> ブックマークしておきましょう。(^^;

 わお。リニューアル。了解です。

> どうせやるならここまでやりたいと思ってはいたんですが、今回MCBというものが
> 少し判ったので、やってみたら出来てしまったわけです。

 けっこう深かったわけですね。向こうの解説も多謝。あっちは明日ゆっくり。
 考えてみれば、僕の資料も古かったんだ。MCB最初4バイト以降も使ってる
わけで(MS-DOS4、5では)。

> > ーとですね、あのコンソールでの改行が1つ2つ多いと思うのですが…。Rのあと
> > にピリオドも欲しいです。
> 改行は気にしてませんでした。直しておきます。Rの後のピリオドは紛らわしい
> かと思ったんですが、使うのは文太さんだけだろうし、まあいいか。

 いいでしょう。コマンドラインにピリオド打ち込む人は、間違ってもこれは使
わない。すると、オーダーメイドの特注品をおねだりしてるんだ…。かたじけな
いっす。m(__)m

 ただ、元々「保存バッファ」だったんですよ。ヒストリーでなく。そういうバ
ッファってあったら便利なのは間違いないんです。だから、用途としては需要が
あってもおかしくはないと思ってます。EMSのハンドルとか、失われてはいけ
ないファイル名情報とか。マクロバッファの自前では消えちゃいますから。需要
する人がいない、というのが問題なんだよな。
 あ、個人的には1キロ全部保存バッファはもったいなすぎる、と思って、逆に、
流れていく効率のよいバッファとなってしまったのでした。どつぼにはまったと
は、間違いなく言えますが。最終的には(?)、ヒストリー部分と保存部分を切
り分けるつもりです。そ、僕は使う気なんです。起動バッチに入れちゃうもん。
これで、psを小さくできるし、ログ履歴用バッファも小さくできて、マクロバ
ッファが少し広がる。現実的な効果は、お、恐ろしく小さいけど…。

> >  ほんと親愛の情を込めてのつもりなのですが、確かc.mosさんがwingさんに
> > 「コンソールファイルの無駄遣い」と言ったことがあったような…。
> これ、どこかで読んだような気がしますが、気のせいかなぁ。(^^;

 うーんと、僕の日本語が酷すぎたのが原因なんでしょうが、金野さんの意図が
読めませんでした。FVCでのやり取りだったと思いますよ。wgrep に関して、
たしか。

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

(2052) 2115Re^3: やっぱMCBで判断に変更 Buf_Hcpy.def (0.51)  投稿者:Konno   2007/01/26(金) 01:37
    2108 番 文太 さんへのコメント    コメント数 1

文太さん

> > メモリの先頭5バイト目に id を埋め込んだので

これは7バイト目だったですね。いいかげんですみませんでした。

> ケチなんだもん。スキ。キスよりAがスキ、みたく。

褒め言葉なのかな? ABCのAってなんだっけ? なんてどうでもいいんですが、

メールへのレスになりますが、公開はDOC読んで著作権とか問題なければ。
としきさんの1kbufほど変れば問題ないでしょうが、今のままではほとんど
delmem のソースそのままなので。

> sein さんの、優れものです。vmap より zmap よりすごい。

meu.com 使ってみました。これはいい!! MCBってPSPの前の16バイトだというのが
よくわかりました。これからはVMAPの代わりに使います。

sein さんって、FORG や NECOシリーズの作者だったんですね。すごいひとだ。

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

(2052) 2117buf1k's ID, MCB, meu.comとか  投稿者:文太   2007/01/26(金) 10:53
    2115 番 Konno さんへのコメント

金野さん

> これは7バイト目だったですね。いいかげんですみませんでした。

0009FBD0 5A BE 9F 41 00 00 00 00-00 00 00 00 00 00 00 00 |Zセ蘗............
0009FBE0 CD 20 FF 9F 00 07 62 75-66 31 6B 0D 00 17 4B 01 |ヘ ....buf1k...K.
b u f 1 k

 ですね。ただ常駐判断は、前のMCBでという方針のままで行くことにしたの
で、TSR check 改変、またかよ、から逃れられました。buf1k 文字列は常駐解除
のためのIDとしてはちゃんと機能を果たすんですからいいですよね。無駄なし。

> > ケチなんだもん。スキ。キスよりAがスキ、みたく。
> 褒め言葉なのかな?

 です、です。何かの車のパーツの宣伝だったと思うけど…。

> メールへのレスになりますが、公開はDOC読んで著作権とか問題なければ。
> としきさんの1kbufほど変れば問題ないでしょうが、今のままではほとんど
> delmem のソースそのままなので。

 たしかに、そうなのかな。

> > sein さんの、優れものです。vmap より zmap よりすごい。
> meu.com 使ってみました。これはいい!! MCBってPSPの前の16バイトだというのが
> よくわかりました。これからはVMAPの代わりに使います。
> sein さんって、FORG や NECOシリーズの作者だったんですね。すごいひとだ。

 すごいっすよ。思わず、メモリ管理がよく分かるようになれる…なりそう…。

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

(2052) 2136Dbuf.def (0.80)  投稿者:文太   2007/01/30(火) 00:47
    2052 番 文太 さんへのコメント    コメント数 1

 やっぱ遊ぶ道具がないとねぇ。出世魚のように((c)YASAT)名前を変えました。
仕様はようやく固まりましたので、残りは0.2です。それは、コードの全面的書
き換えで、当分やるとは思えません。根性ない奴なので。でも、汚ねぇ。
 マクロ技術的には、基礎部分がまったくできてないのに、すげえっす。文太的
でなく、いけないなぁ、と思う。ま、誰か動かしてみてくれたら嬉しいです。

 取り出せないと面白くないので、bufxchgで、psからどうぞ。このbufxchgの
仕様を拡張したら、またはまってしまった。とほほ。

=== Dbuf.def (0.80) by Bunta ===;Dummy Buffer Histcopy

#if0
special thanx to konno, YASAT and Toshiki. m(_B_)m
thanx to Sabrina, Delmem.com, Toshiki's 1kbuf.com and konno's Buf1k.com.

要 Buf1k.com 常駐。
ダミーバッファ用ヒストコピー。窓、ブロック(文字境界、行境界)でデータ保存。
普通起動でデータ保存(ヒストリー)、シフトでカーソル位置に書き出し。
実用性より技術習得とサンプル開拓が開発動機(め、珍しい! 文太!)
実は形にしなければ(どんな形であれ)、許してもらえなさそうな雰囲気が…。

tech notes: iseg copy, histcopy, textbuffer, realtime filesize, MCB & PSP (dos)
Dbuf family: Buf_Init, BufXchg (EMS).
dump -mx9fbe -s64(メモリは常に監視しよう!)
#endif


* Macro
80 ^\ ""; dummy buffer histcopy

?.
;---------- dummyfile name for size info ------------
#if 98 MG
f="a:\tmp\tmp.txt",
#elseif DOSV
f="c:\tmp\tmp.txt",
#endif
;----------------------------------------------------
w=$9fbe, ;check seg (MCB)
x=$9fbf, ;base buf seg
y=1024, ;buf max length

; --- check TSR
dx=w, &20 (ax)?? {&m("buf1k, not on memory!").}

; --- shift branch (On:51; writing out from buffer)
(ks&1)? >51

(mb==1)? >a ;line block
(mb==2)? >b ;string block
>c ;basic no block


; ========= 3 patterns =========

:a ;---line block
o=wn, ;startfile
&05 (r)?? {&m(e).} ;get info thru dummy file
&07 ;bufcheck & get strlen2 of buff
(ax==-1)? {&m("Warning: buffer destroyed.").}
(si)?? {&01 .} ;hist- (1st time buf use, only)
&08 ;buflen adjustment
&00 &01 ;hist+

mx[+, #C (s)? 'n' mx], ;close the dummyfile
&#T(o) ;return to startfile
&d
&m("Many strings stored. OK!").

;===== ----- ===== ----- ===== ----- ===== ----- =====

:b ;---string block
ps[=pr, #G ps],
>d

:c ;---basic no block (window)
pw[=pr,
&g("*** sending to the dummy buffer ***",30)
pw], (r<0) ?.

:d &Sn(pr) a=r, p=gz, q=pr+a, ;<p>seg <q> tail offset <a>strlen1

;=== common for two ===

&07 ;bufcheck & get strlen2
(ax==-1)? {&m("Warning: buffer destroyed.").}

;===== Writing onto Buffer with history function =====
&m("->Buf: %s",pr)
(si)?? {&01 .} ;hist- (1st time buf use, only)
&08 ;buflen adjustment
&00 &01 ;hist+
.

; --------------------- LOCAL MACROS ---------------------

00: ;;==== hist 1st move ==== << dest=>dest move >>
ax=x, si=b, cx=b+1, ;set src; ds(ax):si, cx times
bx=x, di=a+b+1, ;set dest; es(bx):di,
&10 ;exec 'copy backwards'

01: ;;==== hist 2nd move ==== << src->dest copy >>
ax=p, si=q, cx=a+1, ;set src; ds(ax):si, cx times
bx=x, di=a, ;set dest; es(bx):di
&10 ;exec 'copy backwards'

10: ; --- hist backward copy (2) strcpy2
&i("$(50,1F,53,07,FD,F3,A4,FC,C3)")


05: ; --- get sizeinfo of the blocked lines thru status info

(xc>0)? #B l=ln, #B ;
(ln-l>100)? {e="Block, too Big!", (0).}

#k mx[+, #N &?("%s",f) #m mx], #i ;--open and make dummyfile

ps[=pr, ;--replace CRLF w/ $(0)
#56 "\n\n" #m "\n" #m "AY" :g #57 (r)? >g
#^ #< (ct==1)? #g ;top safety
#56 "\n" #m &o($0) #m "AY" :h #57 (r)? >i
ps],


ds[+, #] &Sc(pr,pu+bu,8) ds], ;--get filesize from status
&e(pr) ;=============================
a=r-1, ;<a> src strlen (w/o last nul)
q=a+2, ;<q> tail offset
&e(pr) ;=============================
(a>y)? {e="Too many strings!", (0)} ;
p=wa..9, (1) ;<p> source seg (txtbuf)

07: ;--- check the buffer & get the strlen2 info --- simplify 07&08
; --> si 0:empty; n:strlen2 of buffer (all strings)
dx=x, ax=y,
&i("$(52,1F,33,DB,33,F6,39,1C,74,04,46,48,73,F8,C3)")

08: ;--- if strlen2+new_strlen, too long, discard the oldest str ---
bx=x, (a+si+3>y)? { &i("$
$(53,1F,32,DB,4E,8A,04,38,D8,74,0B,4E,73,F7,88,1C)$
$(46,88,1C,4E,EB,04,46,88,1C,4E,C3)")
>^ }
b=si,

20: ; --- TSR check (5)
&i(3+$)."$
$(52,1F,33,F6,33,C0,B9,5A,BF,39,0C,75,0C,83,C6,02)$
$(B1,9F,38,0C,75,03,B8,01,00,C3)"


;=============== Reading from Buffer =================
51:
;----- check the buf & get strlen (3)strlen1
bx=x, dx=y,
&i("$(53,1F,32,DB,33,F6,8A,04,38,D8,74,04,46,4A,73,F6,C3)")
(si==0) ? {&m("Empty. Cannot write out.").}

;----- reading
ax=x, cx=si+1, si=0, ;set source
bx=gz, di=pr, ;set destination
&i("$(50,1F,53,07,F3,A4,C3)") ;(4)strcpy
&?("%s",pr) .

*

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

(2052) 2137すぐ修正情報m(_b_)m  投稿者:文太   2007/01/30(火) 01:01
    2136 番 文太 さんへのコメント    コメント数 1

112行近辺の

#56 "\n" #m &o($0) #m "AY" :h #57 (r)? >i



#56 "\n" #m &o($0) #m "AY" :h #57 (r)? >h

と差し替えて、ご試用ください。m(_B_)m
たぶん、なかなか発現しないバグだけど、発現してしまったら落ちます。

 えーと行境界ブロックですが、psに入れるのと同じ感覚ですから半角80字
以上の文字列とか入れないでね。そういうのはチェックしていませんから。だい
たいprやpsから取り出すわけで、そういうの想定していません。テキストス
タックじゃないって。

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

(2052) 2138Dbuf.def (0.81)  m(__)m  投稿者:文太   2007/01/30(火) 01:20
    2137 番 文太 さんへのコメント    コメント数 1

=== Dbuf.def (0.81) by Bunta ===;Dummy Buffer Histcopy

#if0
special thanx to konno, YASAT and Toshiki. m(_B_)m
thanx to Sabrina, Delmem.com, Toshiki's 1kbuf.com and konno's Buf1k.com.

要 Buf1k.com 常駐。
ダミーバッファ用ヒストコピー。窓、ブロック(文字境界、行境界)でデータ保存。
普通起動でデータ保存(ヒストリー)、シフトでカーソル位置に書き出し。
実用性より技術習得とサンプル開拓が開発動機(め、珍しい! 文太!)
実は形にしなければ(どんな形であれ)、許してもらえなさそうな雰囲気が…。

tech notes: iseg copy, histcopy, textbuffer, realtime filesize, MCB & PSP (dos)
Dbuf family: Buf_Init, BufXchg (EMS).
dump -mx9fbe -s64(メモリは常に監視しよう!)
#endif


* Macro
80 ^\ ""; dummy buffer histcopy

?.
;---------- dummyfile name for size info ------------
#if 98 MG
f="a:\tmp\tmp.txt",
#elseif DOSV
f="c:\tmp\tmp.txt",
#endif
;----------------------------------------------------
w=$9fbe, ;check seg (MCB)
x=$9fbf, ;base buf seg
y=1024, ;buf max length

; --- check TSR
dx=w, &20 (ax)?? {&m("buf1k, not on memory!").}

; --- shift branch (On:51; writing out from buffer)
(ks&1)? >51

(mb==1)? >a ;line block
(mb==2)? >b ;string block
>c ;basic no block


; ========= 3 patterns =========

:a ;---line block
o=wn, ;startfile
&05 (r)?? {&m(e).} ;get info thru dummy file
&07 ;bufcheck & get strlen2 of buff
(ax==-1)? {&m("Warning: buffer destroyed.").}
(si)?? {&01 >f} ;hist- (1st time buf use, only)
&08 ;buflen adjustment
&00 &01 ;hist+

:f mx[+, #C (s)? 'n' mx], ;close the dummyfile
&#T(o) ;return to startfile
&d
&m("Many strings stored. OK!").

;===== ----- ===== ----- ===== ----- ===== ----- =====

:b ;---string block
ps[=pr, #G ps],
>d

:c ;---basic no block (window)
pw[=pr,
&g("*** sending to the dummy buffer ***",30)
pw], (r<0) ?.

:d &Sn(pr) a=r, p=gz, q=pr+a, ;<p>seg <q> tail offset <a>strlen1

;=== common for two ===

&07 ;bufcheck & get strlen2
(ax==-1)? {&m("Warning: buffer destroyed.").}

;===== Writing onto Buffer with history function =====
&m("->Buf: %s",pr)
(si)?? {&01 .} ;hist- (1st time buf use, only)
&08 ;buflen adjustment
&00 &01 ;hist+
.

; --------------------- LOCAL MACROS ---------------------

00: ;;==== hist 1st move ==== << dest=>dest move >>
ax=x, si=b, cx=b+1, ;set src; ds(ax):si, cx times
bx=x, di=a+b+1, ;set dest; es(bx):di,
&10 ;exec 'copy backwards'

01: ;;==== hist 2nd move ==== << src->dest copy >>
ax=p, si=q, cx=a+1, ;set src; ds(ax):si, cx times
bx=x, di=a, ;set dest; es(bx):di
&10 ;exec 'copy backwards'

10: ; --- hist backward copy (2) strcpy2
&i("$(50,1F,53,07,FD,F3,A4,FC,C3)")


05: ; --- get sizeinfo of the blocked lines thru status info

(xc>0)? #B l=ln, #B ;
(ln-l>100)? {e="Block, too Big!", (0).}

#k mx[+, #N &?("%s",f) #m mx], #i ;--open and make dummyfile

ps[=pr, ;--replace CRLF w/ $(0)
#56 "\n\n" #m "\n" #m "AY" :g #57 (r)? >g
#^ #< (ct==1)? #g ;top safety
#56 "\n" #m &o($0) #m "AY" :h #57 (r)? >h
ps],


ds[+, #] &Sc(pr,pu+bu,8) ds], ;--get filesize from status
&e(pr) ;=============================
a=r-1, ;<a> src strlen (w/o last nul)
q=a+2, ;<q> tail offset
&e(pr) ;=============================
(a>y)? {e="Too many strings!", (0)} ;
p=wa..9, (1) ;<p> source seg (txtbuf)

07: ;--- check the buffer & get the strlen2 info --- simplify 07&08
; --> si 0:empty; n:strlen2 of buffer (all strings)
dx=x, ax=y,
&i("$(52,1F,33,DB,33,F6,39,1C,74,04,46,48,73,F8,C3)")

08: ;--- if strlen2+new_strlen, too long, discard the oldest str ---
bx=x, (a+si+3>y)? { &i("$
$(53,1F,32,DB,4E,8A,04,38,D8,74,0B,4E,73,F7,88,1C)$
$(46,88,1C,4E,EB,04,46,88,1C,4E,C3)")
>^ }
b=si,

20: ; --- TSR check (5)
&i(3+$)."$
$(52,1F,33,F6,33,C0,B9,5A,BF,39,0C,75,0C,83,C6,02)$
$(B1,9F,38,0C,75,03,B8,01,00,C3)"


;=============== Reading from Buffer =================
51:
;----- check the buf & get strlen (3)strlen1
bx=x, dx=y,
&i("$(53,1F,32,DB,33,F6,8A,04,38,D8,74,04,46,4A,73,F6,C3)")
(si==0) ? {&m("Empty. Cannot write out.").}

;----- reading
ax=x, cx=si+1, si=0, ;set source
bx=gz, di=pr, ;set destination
&i("$(50,1F,53,07,F3,A4,C3)") ;(4)strcpy
&?("%s",pr) .

*

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

(2052) 2142Dbuf.def (0.82)  投稿者:文太   2007/01/30(火) 20:13
    2138 番 文太 さんへのコメント    コメント数 1

 またしても、タコバグ。m(__)m
 掲示板で眺めていると、よく見える、、、。よく見つかる、、、。

=== Dbuf.def (0.82) by Bunta ===;Dummy Buffer Histcopy

#if0
special thanx to konno, YASAT and Toshiki. m(_B_)m
thanx to Sabrina, Delmem.com, Toshiki's 1kbuf.com and konno's Buf1k.com.

要 Buf1k.com 常駐。
ダミーバッファ用ヒストコピー。窓、ブロック(文字境界、行境界)でデータ保存。
普通起動でデータ保存(ヒストリー)、シフトでカーソル位置に書き出し。
実用性より技術習得とサンプル開拓が開発動機(め、珍しい! 文太!)
実は形にしなければ(どんな形であれ)、許してもらえなさそうな雰囲気が…。

tech notes: iseg copy, histcopy, textbuffer, realtime filesize, MCB & PSP (dos)
Dbuf family: Buf_Init, BufXchg (EMS).
dump -mx9fbe -s64(メモリは常に監視しよう!)
#endif


* Macro
80 ^\ ""; dummy buffer histcopy

?.
;---------- dummyfile name for size info ------------
#if 98 MG
f="a:\tmp\tmp.txt",
#elseif DOSV
f="c:\tmp\tmp.txt",
#endif
;----------------------------------------------------
w=$9fbe, ;check seg (MCB)
x=$9fbf, ;base buf seg
y=1024, ;buf max length

; --- check TSR
dx=w, &20 (ax)?? {&m("buf1k, not on memory!") .}

; --- shift branch (On:51; writing out from buffer)
(ks&1)? >51

(mb==1)? >a ;line block
(mb==2)? >b ;string block
>c ;basic no block


; ========= 3 patterns =========

:a ;---line block
o=wn, ;startfile
&05 (r)?? {&m(e) .} ;get info thru dummy file
&07 ;bufcheck & get strlen2 of buff
(ax==-1)? {&m("Warning: buffer destroyed.") .}
(si)?? {&01 >f} ;hist- (1st time buf use, only)
&08 ;buflen adjustment
&00 &01 ;hist+

:f mx[+, #C (s)? 'n' mx], ;close the dummyfile
&#T(o) ;return to startfile
&m("Many strings stored. OK!") .

;===== ----- ===== ----- ===== ----- ===== ----- =====

:b ;---string block
ps[=pr, #G ps],
>d

:c ;---basic no block (window)
pw[=pr,
&g("*** sending to the dummy buffer ***",30)
pw], (r<0) ?.

:d &Sn(pr) a=r, p=gz, q=pr+a, ;<p>seg <q> tail offset <a>strlen1

;=== common for two ===

&07 ;bufcheck & get strlen2
(ax==-1)? {&m("Warning: buffer destroyed.").}

;===== Writing onto Buffer with history function =====
&m("->Buf: %s",pr)
(si)?? {&01 .} ;hist- (1st time buf use, only)
&08 ;buflen adjustment
&00 &01 . ;hist+


; --------------------- LOCAL MACROS ---------------------

00: ;;==== hist 1st move ==== << dest=>dest move >>
ax=x, si=b, cx=b+1, ;set src; ds(ax):si, cx times
bx=x, di=a+b+1, ;set dest; es(bx):di,
&10 ;exec 'copy backwards'

01: ;;==== hist 2nd move ==== << src->dest copy >>
ax=p, si=q, cx=a+1, ;set src; ds(ax):si, cx times
bx=x, di=a, ;set dest; es(bx):di
&10 ;exec 'copy backwards'

10: ; --- hist backward copy (2) strcpy2
&i("$(50,1F,53,07,FD,F3,A4,FC,C3)")


05: ; --- get sizeinfo of the blocked lines thru status info

(xc>0)? #B l=ln, #B ;
(ln-l>100)? {e="Block, too Big!", (0).}

#k mx[+, #N &?("%s",f) #m mx], #i ;--open and make dummyfile

ps[=pr, ;--replace CRLF w/ $(0)
#56 "\n\n" #m "\n" #m "AY" :g #57 (r)? >g
#^ #< (ct==1)? #g ;top safety
#56 "\n" #m &o($0) #m "AY" :h #57 (r)? >h
ps],


ds[+, #] &Sc(pr,pu+bu,8) ds], ;--get filesize from status
&e(pr) ;=============================
a=r-1, ;<a> src strlen (w/o last nul)
q=a+2, ;<q> tail offset
&e(pr) ;=============================
(a>y)? {e="Too many strings!", (0).} ;
p=wa..9, (1) . ;<p> source seg (txtbuf)

07: ;--- check the buffer & get the strlen2 info --- simplify 07&08
; --> si 0:empty; n:strlen2 of buffer (all strings)
dx=x, ax=y,
&i("$(52,1F,33,DB,33,F6,39,1C,74,04,46,48,73,F8,C3)")

08: ;--- if strlen2+new_strlen, too long, discard the oldest str ---
bx=x, (a+si+3>y)? { &i("$
$(53,1F,32,DB,4E,8A,04,38,D8,74,0B,4E,73,F7,88,1C)$
$(46,88,1C,4E,EB,04,46,88,1C,4E,C3)")
>^ }
b=si, .

20: ; --- TSR check (5)
&i(3+$)."$
$(52,1F,33,F6,33,C0,B9,5A,BF,39,0C,75,0C,83,C6,02)$
$(B1,9F,38,0C,75,03,B8,01,00,C3)"


;=============== Reading from Buffer =================
51:
;----- check the buf & get strlen (3)strlen1
bx=x, dx=y,
&i("$(53,1F,32,DB,33,F6,8A,04,38,D8,74,04,46,4A,73,F6,C3)")
(si==0) ? {&m("Empty. Cannot write out.") .}

;----- reading
ax=x, cx=si+1, si=0, ;set source
bx=gz, di=pr, ;set destination
&i("$(50,1F,53,07,F3,A4,C3)") ;(4)strcpy
&?("%s",pr) .

*

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

(2052) 2150DbufXchg.def (0.80)  投稿者:文太   2007/01/31(水) 12:25
    2142 番 文太 さんへのコメント    コメント数 1

 タコバグがないことを祈ります。祈ってないで動け! はは。

=== DbufXchg.def (0.80) by Bunta ===;DBUFF_PS exchanger

#if0
ノーマル起動:ダミーバッファとPSを総入れ替え。
シフト起動:メニューにより
 双方向ヒストコピー(追加)と
 ダンプ(テキスト吐き出し。16進ではない)。
history.def by m.gannとの併用がいちおうの目論見。
Dump -mx9fbe -s64
#endif

* Macro
50 ^^ ""

(ef)?? {&m("not enough EMS!") .}

w=$9fbe, ;check seg
x=$9fbf, ;base buf seg
y=1024, ;buf max length

dx=w, &00 (ax)?? {&m("buf1k, not on memory!") .} ;check TSR


;=== get 2 bufs info
c=ps..-1, ;ps real size
dx=x, si-, ax=y, &01 f=si, ;<f>strlen2 on buf
dx=gz, si=ps, ax=c, &01 g=si-ps, ;<g>strlen2 on ps


(ks&1)? >A ;shift branch, menu (Add & Dump)


;=== check the safety of exchange
y[,c[, (y-c>0)? y=c, ;the smaller is the norm (bufsize)
f[,g[, (f-g>0)? g=f, ;the bigger needs to be cared (strlen2)

(g>y) g],f],c],y],
? {&m("Sorry, bufsizes are too different.") .}


;=== exchange dbuf & ps thru EMS ===

&02 ;open EMS
&40 ;copy ps -> EMS
&41 ;copy dbuf -> ps
&42 ;copy EMS -> dbuf
&03 ;release EMS
&m("DBuf <-> PS completed") .


:A ;========== shift menu (HistAdd or Dump) routine ==========

!01 (r<0)?.
(r)>? {>a >b >c >d} ;AddDB, AddPS, DumpDB, DumpPS

;-------------------------------------------------------------------------
:a ;---hist from ps to dbuf ;<f>dbuf_strlen2
;<g>ps_strlen2
fa+,
:x bx=x, (g+f+3>y)? {&05 >x} ;dest_len adjustment

ax=x, si=f, cx=f+1, ;dest move
bx=x, di=f+g+1,
&10

ax=gz, si=ps+g, cx=g+1, ;src move
bx=x, di=g,
&10
&m("ps->dbuf histcpy, OK!") .


;-------------------------------------------------------------------------
:b ;---hist from dbuf to ps ;<f>dbuf_strlen2
;<g>ps_strlen2
(f)?? {&m("Dbuf, empty.") .}

fa-,
:y bx=gz, (g+f+3>c)? {&05 >y} ;dest_len adjustment

ax=gz, si=ps+g, cx=g+1, ;dest move
bx=gz, di=ps+g+f+1,
&10

ax=x, si=f, cx=f+1, ;src move
bx=gz, di=ps+f,
&10
&m("dbuf->ps histcpy, OK!") .

;-------------------------------------------------------------------------
:c ;---dump dbuf
(f)?? {&m("Dbuf, empty.") .}

&02 ;open EMS
&40 ;copy ps -> EMS
&41 ;copy dbuf -> ps
&30 ;===spitting out thru PS
&43 ;copy EMS -> ps
&03 ;release EMS
&m("Dbuf, Dumped.") .

;-------------------------------------------------------------------------
:d ;---dump PS
&30 ;===spitting out PS
&m("PS, Dumped.") .



;* === * === * === * === LOCAL MACROS === * === * === * === *

00: ;---TSR check
&i(3+$)."$
$(52,1F,33,F6,33,C0,B9,5A,BF,39,0C,75,0C,83,C6,02)$
$(B1,9F,38,0C,75,03,B8,01,00,C3)"

01: ;---strlen2
; <-- dx = segment, si = offset, ax = buffersize (serch max)
; --> si = offset
&i("$(52,1F,33,DB,39,1C,74,04,46,48,73,F8,C3)")


02: ;---open EMS work
&Ea(1) a=r, ;EMS allocation, EMShandle <a>
&Em(a) b=r, ;EMS mapping, segment <b>

03: ;---close EMS work
&Ef(a)


05: ;---if src+dest too long, discard the oldest in the dest
;--> dx:seg, si:tail offset
;<-- si:new strlen2 (shorter) of dest

(fa)? si=f, ? si=ps+g,
&i("$
$(53,1F,32,DB,4E,8A,04,38,D8,74,0B,4E,73,F7,88,1C)$
$(46,88,1C,4E,EB,04,46,88,1C,4E,C3)")
}
(fa)? f=si, ? g=si, ;dest: fa+,dbuf ; fa-,ps
;strlen2; f g

10: ; --- backward copy for hist ---
&i("$(50,1F,53,07,FD,F3,A4,FC,C3)")


30: ; --- spitting out PS strings ---
p=ps,
:e &Sn(p) l=r, (r)? {&?("%s",p) #m p+=l+1, >e}


40: ;--copy ps -> EMS
ax=gz, si=ps, cx=g+2, ;src
bx=b, di-, ;dest
&45 ;copy!

41: ;--copy dbuf -> ps
ax=x, si-, cx=f+2, ;src
bx=gz, di=ps, ;dest
&45

42: ;--copy EMS -> dbuf
ax=b, si-, cx=g+2, ;src
bx=x, di-, ;dest
&45

43: ;--copy EMS -> ps
ax=b, si-, cx=g+2, ;src
bx=gz, di=ps, ;dest
&45

45: ;---strcpy; ax:si -> bx:di, cx times
&i("$(50,1F,53,07,F3,A4,C3)") ;(4)


* P
1 "HistAdd or Dump",19,4
"1 PS ==> DBUF"
"2 DBUF ==> PS"
"3 dump DBUF"
"4 dump PS"

*
(source 1; strlen2−−ヌル2つまでの距離を測定)少し汎用化
; <-- dx = segment, si = offset, ax = buffer size (serch max)
; --> si = offset

START: push dx ;set segment
pop ds ;
xor bx,bx ;0 (word)
NEXT: cmp word ptr [si],bx ;cmp by the word (ds..0==0)?
je FIN ;
inc si ;inc by the byte
dec ax ;
jnc NEXT ;jump if not with carryflag
FIN: ret


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

(2052) 2151DBufInit.def  投稿者:文太   2007/01/31(水) 12:33
    2150 番 文太 さんへのコメント    コメント数 1

 祈ること、再び。ファミリーの名前先頭を統一しました。

=== DBufInit.def by Bunta ===;buffer initializer
* Macro
50 ^^ ""

w=$9fbe, ;check seg
x=$9fbf, ;base buf seg
y=1024, ;buf max length

; --- check TSR (for source, see DBUF.DEF)
dx=w, &20 (ax)?? {&m("buf1k, not on memory!") .}

; --- buffer initialization
;<-- dx:seg (from offset 0), cx:times=length.

dx=x, cx=y,
&i("$(8E,C2,32,C0,33,FF,F3,AA,C3)")
&m("Dummy buffer, Initialized") .


20: ; ===== TSR check =====
&i(3+$)."$
$(52,1F,33,F6,33,C0,B9,5A,BF,39,0C,75,0C,83,C6,02)$
$(B1,9F,38,0C,75,03,B8,01,00,C3)"

*

; --- buffer initialization
;<-- cx (times), dx (seg)
mov es,dx
xor al,al
xor di,di
rep stosb
ret

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

(2052) 2155FixedIn & FixedOut  投稿者:文太   2007/02/01(木) 01:29
    2151 番 文太 さんへのコメント

 保存バッファの出し入れです。実は、別にすぐさま深ーく落ちるつもりでもな
いのですが、このプロジェクトに1月で目途をつけるつもりでいたのです。

 その前に。はい、僕はアセンブラで煙草を止めました。これが最大の目論見。
腹が立つことも多いのですが、Vzマクロからのアセンブラ、楽しいですね。完
全にはまってしまいました。ほんとは12月いっぱいのつもりだったのよん、色
々。

 でも、皆さま+アセンブラ+ delmem+1kbuf+buf1k+sabrina のお陰で、たぶん、
ほんとに25年間の喫煙生活に終止符を打てそうです。油断禁物なのだけど。
 アセンブラにも色々あると思う。でも、Vzからやる場合、結局メモリ管理の
話なわけで、そういう意味では、「そうだ、常駐アプリでいいんだ」から始まっ
た文太のアセンブラ道場入門、できすぎているほどよくできた展開でした。別に
明日からアメリカへ行くわけじゃありませんが、としきさんと金野さんには、ほ
んと感謝、感謝です。(YASATさんも、もち。m(__)m)

 余談をちょっと。Vz有段者がやがてアセンブラに手を出す気持ちが、ほんの
少しですが、分かりました。何て言うんだろう、時計を後ろから覗いちゃった感
じかな。我々は徹頭徹尾時間に縛られて生きるよう「近代」に命令されているの
ですが、その後ろ側でギアやモーターが動いているのが見えてしまったみたい。
ああ、面白すぎ。しかし、(たとえばビスタ的な)現実から遊離することも確か
なので、危険でもありますね。


 さて、元に戻って、保存バッファです。ダミーバッファの終端、256バイト
を使います。4つに分けられておりまして、それぞれ0〜3の番号が振られてい
ます。固定(fixed)バッファですから、もちろんヒストリーではありません。

 その前に。

 DbufInit.defは、全部の掃除ですから、以下のままでよいのですが、
w=$9fbe, ;check seg
x=$9fbf, ;base buf seg
y=1024, ;buf max length

 Dbuf.DEFとDbufXchg.DEFの先頭は、
w=$9fbe, ;check seg
x=$9fbf, ;base buf seg
y=768, ;buf max length
 のようにバッファサイズを縮小しておかなければいけません。

 この調整が済みましたら、あとは簡単です。以下のサンプルマクロでお試し下
さい。何かのマクロのサブルーチンとして使われることが想定されています。サ
ブルーチンの形をしてなくてすいませんが。
 ax には、0,1,2,3 を入れます。 これがバッファ番号です。これは個人管理で
すから、どこを何に使ったかは覚えておくなり、マクロの中で対応させるなりし
ましょう。それ以外の入出力はマクロを見て下さい。自分のためではありますが、
詳細に書いてあります。

 バッファのフォーマットは、最初の1バイトにサイズ情報が入っていて、終端
がヌルです。1つのバッファの有効サイズが62バイトで、ちょうどVzが扱え
るファイル名の最大値になっています(色々うまくできてるもんですね)。ファ
イル名を4つ、動かないバッファに管理できるわけですね。
 ああ、62バイト以上かのチェックはしてません。ま、間抜け。そういのは止
めましょう。間違えなければ、エラー処理ルーチンなんて要らないのです。なん
で62かと考えましょう。

 バッファサイズやFバッファの箇所は固定です。ニーモニックの中に入ってし
まってますので外からは調整できません。 でも、ax で4つをちゃんと識別する
はずですので、このほうが使い勝手がよいでしょう(でもないかな)。

 出先は pr になっています。 その辺りがいいのではないでしょうか。tmpbuf4
は、たぶん、止めたほうがいいようです。色々こけました。サブリナ関連なのか
もしれません。それがなければ11時頃には上げられたはずだったのです。

 もちろん、誰も使わないことは知っているのですが、えい、ここまでちゃんと
やったぞい、と言ってみたくて。また、(もちろん)上は、そういう使い方を
僕はする、というだけの話です。でも、ほんと、使うのです!

 バグとか指摘しまくらないでください。しまくらなければ、どうぞ。m(_B_)m


=== FixedOut.def by Bunta ===;
* Macro
50 ^\ ""

w=$9fbe, ;check seg
dx=w, &20 (ax)?? {&m("buf1k, not on memory!") .}

a="1st1st1st1st--------------------------",
&Sn(a) aa=r,
ax=0, dx=gz, si=a, cx=aa, &01

&m("OK!") .


01: &i(3+$)."$
$(8E,DA,33,D2,33,FF,B2,04,F6,E2,05,EF,9F,8E,C0,26)$
$(88,0D,47,F3,A4,32,D2,26,88,15,C3)"
;---- sendout -----------------------------------------------
;<-- input ax:bufseg#(0,1,2,3), dx:seg, si:offset, cx:strlen
;------------------------------------------------------------

20: ; ===== TSR check =====
&i(3+$)."$
$(52,1F,33,F6,33,C0,B9,5A,BF,39,0C,75,0C,83,C6,02)$
$(B1,9F,38,0C,75,03,B8,01,00,C3)"

*

mov ds,dx ;ds:si (vz) -> es:di(buf)
;---init
xor dx,dx
xor di,di
;---set seg from #info
mov dl,4h ;(0,1,2,3)*4
mul dl ;ax,max,12h
add ax,9FEFh ;base seg
mov es,ax
;---write sizeinfo at offset 0
mov es:[di],cl
inc di
;---copy
rep movsb
;---strike nul at tail
xor dl,dl
mov es:[di],dl
ret


=== FixedIn.def by Bunta ===;
dump -mx9FEF -s32
dump -mx9FF3 -s32
dump -mx9FF7 -s32
dump -mx9FFB -s32

* Macro
50 ^^ ""

w=$9fbe, ;check seg
dx=w, &20 (ax)?? {&m("buf1k, not on memory!") .}

ax=0, di=pr, &01
(bx)?? {&m("Fbuf(%d), empty!",ax) .}
&m("%s",pr)


01: &i(3+$)."$
$(BB,01,00,33,F6,33,C9,B2,04,F6,E2,05,EF,9F,8E,D8)$
$(3A,0C,74,07,8A,0C,41,46,F3,A4,C3,33,DB,C3)"
;---- getin ----------------------------
;<-- ax:buf#(0-3), di:output offset
;--> bx: 0=buf empty, 1=buf not empty
;strcpy fbuf(0-3) -> pr; ds:si->es:di
;---------------------------------------

20: ; ===== TSR check =====
&i(3+$)."$
$(52,1F,33,F6,33,C0,B9,5A,BF,39,0C,75,0C,83,C6,02)$
$(B1,9F,38,0C,75,03,B8,01,00,C3)"

*
;---init
mov bx,1 ;check flag
xor si,si
xor cx,cx
;---set seg from #info
mov dl,4h ;(0,1,2,3)*4
mul dl ;ax,max,12h
add ax,9FEFh ;base seg
mov ds,ax
;---check 1st byte
cmp byte ptr cl,[si]
jz OOOPS
;---read strlen
mov byte ptr cl,[si]
inc cx
inc si
;---copy
rep movsb
ret
OOOPS: xor bx,bx ;checkflag 0
ret

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