10878/10877 BQO00549 konno Re: ある現象
( 1) 23/07/26 22:43 10877:めざらさんへのコメント コメント数:2
> マクロバッファのオフセットアドレス $2225【付近】が書き換わる。
> 起動時からそのようなので「書き換わる」は正確ではないかもしれません。
> 実行環境によって別のコードになるものの,場所は同じ。
これはヤバいですね、メインのマクロを読み込む時点でおかしくなるのでしょうか。
> 【経緯】(明記しない場合は VTDOS 環境)
> いつの時点からは不明だが,内部マクロの実行がエラーで停止し判明。
> Buftour.def でマクロバッファを確認すると,# が P になっていた。
私今アルツか暑いせいで全て忘れているような状態です。(^^;
Buftour.def でマクロバッファを確認は、どういう手順でしたっけ?
> 同じバッチで起動する dosvaxj3 環境では,同じ場所が U になっていた。
これはプラットフォームの問題ではなくVZの問題と思われますね。
> K07V6J (2023-05-19)
> K07V6H (2023-03-14)
> ともに同様の振る舞いでした。
他のVZでは問題なしということでしょうか。
マジで色々忘れているので、再現手順とか色々ご教授願います。m(__)m
他の方の情報もあればありがたいです。
10879/10877 CXB00940 としき Re^2: ある現象
( 1) 23/07/26 22:48 10878:konnoさんへのコメント
参照先:http://toshiki.la.coocan.jp/
> 私今アルツか暑いせいで全て忘れているような状態です。(^^;
> Buftour.def でマクロバッファを確認は、どういう手順でしたっけ?
同じく、確認方法がわかりません。
私の場合、忘れている、ではなく、最初から知らないと思う。
ばふつあなんて、使ったことがないかもしれない、というくらい。
ということで、
> マジで色々忘れているので、再現手順とか色々ご教授願います。m(__)m
私も同じく。
どの環境とどのバージョンなら再現しない、という報告ぐらいは上げられると
思います。
10880/10877 DGF01024 めざら Re^2: ある現象
( 1) 23/07/27 07:49 10878:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
10881/10877 BQO00549 konno Re^3: ある現象
( 1) 23/07/27 22:39 10880:めざらさんへのコメント
> 起動してメニューが表示されたら,Offset(メニューの最下部)を選択し,
> 入力窓で「$2200」のようにアドレスを入力すると,メッセージラインに
> 該当するアドレスがら64バイトのメモリを可読文字で表示します。(終了は Q )
ありがとうございます。
最初メニューに Offset が無いなぁと思ったら、次ページだったのですね。(^^;
ふーむ、このアドレスはインスタント窓で $2225 を入れた時の表示と同じみたいですね。
DUMP.DEF の窓で $2200 でも同じみたいです。
これから色々試してみます。
> ちなみに以下のモジュールメニューを組み込むと,ばふつあをより便利に使えます。
> http://mezala.la.coocan.jp/vz/workshop/mkoban.html#mdlmenu
> (ちょっと宣伝 (^^;)
これは機能が高度すぎて今の私には使いこなせそうもないです。(^^;
まあぼちぼちとリハビリします。(^^;
10882/10877 BQO00549 konno Re: ある現象の絞り込み
( 1) 23/07/29 00:21 10877:めざらさんへのコメント コメント数:1
今のところ再現とか出来ていません。
再確認ですが
> いつの時点からは不明だが,内部マクロの実行がエラーで停止し判明。
これは、VZを K07V6J (2023-05-19) に入れ替えてから出るようになったのでしょうか。
高橋版やそれ以前のKVZでは現象が出ないのでしょうか。
> Buftour.def でマクロバッファを確認すると,# が P になっていた。
> (具体的には,#T が PT になっていたので,そこで停止した。)
> 同じバッチで起動する dosvaxj3 環境では,同じ場所が U になっていた。
この現象と
> 内部マクロの順序を入れ替えると,当該マクロ(拡張[F03])は正常に動作。
> しかし,一方で別のマクロが書き換わることが判明。場所は $2225 付近で同じ。
> こちらは拡張^F で #f が #P に書き換わっており,実害を伴うことに。
> dosvaxj3 環境では #f が #U に書き換わっていた。パターンは同じ。
この現象は、ともに同じアドレスが
VTDOSは、 P に書き換わる
dosvaxj3 は、U に書き換わる
ということですね。環境の違いでアドレスか数値に違いが出るように見えますね。
現象が VZ.DEF で出ているとすれば、同じ環境で試してみたいです。
よろしければそのVZ.DEF をメールでいただけないでしょうか。
10883/10877 DGF01024 めざら Re^2: ある現象の絞り込み
( 1) 23/07/29 09:42 10882:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
再現できないということでしたので,VZT以降のバージョンでいくつか試し,
t03k2 ok
k06v ok
k07j ok
k07p ok
k07s5 ok
k07t2 ok
k07v6d NG
K07v6h NG
k07v6i NG
……という結果を得ました。手元の結果を見る限り,k07v 以降ですね。
最近は VZ だけでいくつもファイルを開いて作業するということはなかったため,
拡張[F03]に割り当てた機能を使う機会がなくて気づかなかったと思われます。
同じ環境になるよう,インクルード含め一式お送りします。
VZ.DEF は実害の少ない一世代前に戻してあります。
63 [F03] "" ;Pick Text (220) ;Close, reOpen, Quit
(s||wc<1)?.
ss-, wl[7, #T wl],
手元の環境では,↑の # が P に置き換えられ,実行すると左下に
PTwlとエラー表示してマクロの実行を停止します。
10884/10877 BQO00549 konno Re^3: ある現象の絞り込み
( 1) 23/07/29 22:52 10883:めざらさんへのコメント コメント数:1
> 同じ環境になるよう,インクルード含め一式お送りします。
> VZ.DEF は実害の少ない一世代前に戻してあります。
メールでいただきました。ありがとうございます。
再現が上手くいかないので、マクロを丸ごと入れ替えてしまいました。(^^;
うう、非常に使いづらいですぅ。(>_<)
やっぱりVZは自分の環境が一番というか、他人のVZ環境は使えない体なのでせうか。
この結果、ほぼ同じアドレスになったのですが、入れ替わりは見つかりません。
そのかわり、別の奇妙な現象が出ています。詳細は後ほど。
> 再現できないということでしたので,VZT以降のバージョンでいくつか試し,
> k07t2 ok
> k07v6d NG
> K07v6h NG
> k07v6i NG
> ……という結果を得ました。手元の結果を見る限り,k07v 以降ですね。
VZk07t02 はVZのバグ修正テスト版ですよね、それでは異常が出ないのですか。
自作、改作アプリの放置部屋にある VZT-P.COM も試してもらえるとありがたいです。
> ss-, wl[7, #T wl],
> 手元の環境では,↑の # が P に置き換えられ,実行すると左下に
> PTwlとエラー表示してマクロの実行を停止します。
再現環境のインスタント窓で $2225 を入れると、"#Twl" が表示されました。
DUMP.DEF で見てもこの周辺は異常が見つからなかったです。
10885/10877 BQO00549 konno 別の奇妙な現象
( 1) 23/07/30 00:34 10884:konnoさんへのコメント コメント数:1
> この結果、ほぼ同じアドレスになったのですが、入れ替わりは見つかりません。
> そのかわり、別の奇妙な現象が出ています。詳細は後ほど。
さて、別の奇妙な現象なのですが
めざらさんのマクロで再現環境にしたVZでは
" 2" の文字列、つまり、スペース+2 の文字列の色が暗い青になってしまうのです。
文字列の色を変えるのは、TAGLIGHT.EXE くらいです。
関連マクロは動作していないので、素のTAGLIGHT.EXE がやっている
可能性がありますが TAGLIGHT.PAT にそのような設定はしていません。
TAGLIGHT.PAT の 1文字が変わってもそういう動作になる設定はありません。
めざらさんのマクロで再現環境にしたVZでは高橋版VZでも同じ症状になりました。
VTDOSの最新環境の中で VZ.COM を入れ替えただけなので、バッチから変えればまた違うかも。
うちの環境では、メインメモリ上のどこかを書き換えているのかもしれません。
# じょじょに奇妙な冒険は続くのか・・・
ハッ! スタンドに攻撃されている!? (゚゜)☆\(--#)バキッ
10886/10877 DGF01024 めざら Re: 別の奇妙な現象
( 1) 23/07/31 09:41 10885:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
" 2" 20h 32h ということですね。
うちでは部分的に属性が変わるという現象はないですね。まさしく謎です。
書換えの現象も見られないんですよね。同じ DEF なのに?!
> うちの環境では、メインメモリ上のどこかを書き換えているのかもしれません。
そのようにお考えになる理由を少しだけ説明していただけますか?
コンソールの設定ということですよね。
ただ,VTDOS と DOSVAXJ3 で(同一ではないが)同様の現象がみられるので,
どこを切ったらネタが出てくるのか分かるような分からないような……
謎ですねぇ……
10887/10877 BQO00549 konno Re^2: 別の奇妙な現象
( 1) 23/07/31 21:15 10886:めざらさんへのコメント コメント数:1
> " 2" 20h 32h ということですね。
そうなりますね。もちろん検索文字列でもありません。
> 書換えの現象も見られないんですよね。同じ DEF なのに?!
書換の現象の代わりに上記の謎現象が起こったのではないかと考えています。
そうすると、メモリのどこかを壊しているのではないかと考えたわけです。
> コンソールの設定ということですよね。
TAGLIGHT.EXE の挙動と思っていましたが、VZの設定で、上記文字列が
コントロールコードとして書換られたら同じ現象になるかもですね。
そうなると、VZの中で問題が出ていることになるので、この可能性が高いかも。
> ただ,VTDOS と DOSVAXJ3 で(同一ではないが)同様の現象がみられるので,
> どこを切ったらネタが出てくるのか分かるような分からないような……
うちでは、DOSVAXJ3 では現象が表面上は見られませんでした。
また、環境を少し変えただけで VTDOS でも同じ現象は無くなりました。
その代わり、VZにまた別の変な挙動が出てきたようです。
当初 VZのバグ対策パッチが原因かと思ったので、パッチ版のテストをお願いしたのですが
パッチ版で現象が出なければ、最近の私家版VZが原因の可能性が高いと思ったのです。
今は可能性を一つ一つ絞り込んでいくしかないと思っています。
10888/10877 DGF01024 めざら Re^3: 別の奇妙な現象
( 1) 23/08/01 07:29 10887:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
当面は,書換え先(…がただの1箇所だけとの希望的仮定ですが…)のアドレスが
非ヒストリ自前バッファに当たるよう内部マクロの配置を工夫するしかないかな〜。
手元の環境だけしか現象が出ないのでは解決の緒にもならないので,
当面は工夫しつつ様子を見ようと思います。
あ,製品版サンプルDEFにでっかい自前バッファを配置して,本当に1箇所なのか
検証してみるってのも一歩かな。それなら簡単だし。
10889/10877 BQO00549 konno 修正テスト版
( 1) 23/08/02 22:09 10888:めざらさんへのコメント コメント数:1
> 手元の環境だけしか現象が出ないのでは解決の緒にもならないので,
> 当面は工夫しつつ様子を見ようと思います。
一つ思い当たる所に気が付きました。
私家版は10#さんのルーチンを導入しているのですが、LFNの一時バッファが
260Bytes あるので、そこを tmpbuf4 で代替していました。
色々見ていると、STKHLP の記述で
> tmpbuf4
> ・256 バイトのテンポラリ領域。(ラインバッファの直後)
> ラインバッファあふれのチェック用領域。
> ・&z 等のマクロ組込時以外は比較的自由に使用できる。
> > pn..-26
こう書いてありました。
> ・&z 等のマクロ組込時以外は比較的自由に使用できる。
マクロの組込で tmpbuf4 を使うと不具合が出る可能性があるのですね。
私は無意識に不具合を回避するようにしていたのかもしれません。
めざらさんの VZ.DEF に pn..-26 (tmpbuf4)を使う記述があったので気が付いたのです。
10#さんのルーチンに戻した版をメールで送りますので試してみてください。
10890/10877 DGF01024 めざら Re: 修正テスト版
( 1) 23/08/03 17:36 10889:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
テスト版をわざわざお送りくださり,ありがとうございます.
早速試してみたところ,書き換わるという状況は変わりませんでした.
ただ,ちょっと不思議なのが,見かけ上(……と言うのか,マクロファイルの)は
書き換わる位置が変わらず,当該マクロを実行すると停止する同じ症状ですが,
書き換わるアドレスが変わって 2329h 付近になりました.だいぶ違う……(?_?)
ある位置からの相対アドレスは変わっていないけれど,マクロバッファの使い方が
変わったということでしょうか.マップで見ると,システム領域が500バイトほど
増えているのですね.ああ,LFN の一時バッファをそこに取ったということ?
10891/10877 BQO00549 konno Re^2: 修正テスト版
( 1) 23/08/03 23:43 10890:めざらさんへのコメント コメント数:1
> 早速試してみたところ,書き換わるという状況は変わりませんでした.
残念、これは関係なかったですか。
でも tmpbuf4 はどこで使われるかわからないので、この方向にしようと思います。
> ただ,ちょっと不思議なのが,見かけ上(……と言うのか,マクロファイルの)は
> 書き換わる位置が変わらず,当該マクロを実行すると停止する同じ症状ですが,
> 書き換わるアドレスが変わって 2329h 付近になりました.だいぶ違う……(?_?)
> ある位置からの相対アドレスは変わっていないけれど,マクロバッファの使い方が
> 変わったということでしょうか.
書き換わる位置が変わらないということは、マクロ内での挙動なのですかね?
書き換わるアドレスが変わって 2329h 付近になったのは一時バッファの影響でしょう。
> マップで見ると,システム領域が500バイトほど
> 増えているのですね.ああ,LFN の一時バッファをそこに取ったということ?
そうなんですが、260バイト のはずが 500バイト増えてるとは、位置が悪いのかなぁ?
実行ファイルのサイズ増加分も含んでいるのかしら?
実は、10#さんのルーチンでは、MAIN.ASM の pn.11 の後ろになっています。
11 wsplit0 db 0 ; pn.11
GDATA lfntmp, db, <MAXPATH+1 dup(0)> ; ## 10# mod 260 LFN maxpath
この後ろも ポインタで参照されそうだと思ったので、繋がりが切れていると思われる
EXPR.ASM のローカルデータの後ろに置きました。
もしかしたら副作用があるかもしれませんね。
10892/10877 DGF01024 めざら Re^3: 修正テスト版
( 1) 23/08/04 08:43 10891:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
取り急ぎ発言修正を。
> 260バイト のはずが 500バイト増えてるとは、位置が悪いのかなぁ?
ごめんなさい,ざっくりしたマップを見て適当に言いましたが,260バイトですね。
256を超えたので2区画取ったように見えてしまっただけです。
手元では直前の版の mh が $E0F で,テスト版の mh が $F13 でした。
版によって絶対アドレスが変わるので,以後 mh+$1416 付近と言うことにします。
試しに念のため mh+$1416 を確認してみていただけるでしょうか。
10893/10877 BQO00549 konno Re^4: 修正テスト版
( 1) 23/08/04 20:12 10892:めざらさんへのコメント コメント数:1
> ごめんなさい,ざっくりしたマップを見て適当に言いましたが,260バイトですね。
> 256を超えたので2区画取ったように見えてしまっただけです。
なるほど、そういうことですか、了解です。
> 手元では直前の版の mh が $E0F で,テスト版の mh が $F13 でした。
> 版によって絶対アドレスが変わるので,以後 mh+$1416 付近と言うことにします。
> 試しに念のため mh+$1416 を確認してみていただけるでしょうか。
うちの環境では、mh は $F7B でした。そのせいか、mh+$1416 に文字化けはありませんでした。
試しに $F13+$1416 を見たら "・:r(lx)?{#s(ct>" と中黒になっていて、ここは VZ.DEF の 510行目
61 ^A "" ;Line Top m.gann;[\] back str
?. (ks&1)?{ #a :r (lx)?{ #s (ct>2+ck)?>r #d }. }
↑
ここみたいです。"#a" が中黒($8145)に文字化けしていますね。
63 [F03] "" ;Pick Text (220) ;Close, reOpen, Quit
(s||wc<1)?.
ss-, wl[7, #T wl],
↑
めざらさんのここより13行手前が文字化けしているようですね。
私の環境では挙動がおかしいので他にも不具合があるようです。
これを手掛かりに調べてみます。
10894/10877 DGF01024 めざら Re^5: 修正テスト版
( 1) 23/08/04 23:49 10893:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
> うちの環境では、mh は $F7B でした。そのせいか、mh+$1416 に文字化けはありませんでした。
> 試しに $F13+$1416 を見たら "・:r(lx)?{#s(ct>" と中黒になっていて、ここは VZ.DEF の 510行目
ちょっと分からないのですが,mh が $F7B になる版はどれですか? 超私家版?
mh が $F13 になるのは k07v6k(20230802) なので,さらにシステム領域が増えた版ということですか?
(めざらはカンチガイしているのか…… mh はいずれの環境でも版固有の値をとるのではないのか……)
いずれにしても,マクロバッファ書換えの症状は存在するということですね.
ただ,2バイト書き換わっているというのは新しい症状のように思います.
わたしの手元では1バイトの書換えで収まっているので,より重い症状のような……
10895/10877 BQO00549 konno Re^6: 修正テスト版
( 1) 23/08/05 00:14 10894:めざらさんへのコメント コメント数:1
> ちょっと分からないのですが,mh が $F7B になる版はどれですか? 超私家版?
> mh が $F13 になるのは k07v6k(20230802) なので,さらにシステム領域が増えた版ということですか?
> (めざらはカンチガイしているのか…… mh はいずれの環境でも版固有の値をとるのではないのか……)
すみません、あまりに使いずらいので自分のDEFをインクルードするために BM を変えていました。m(__)m
元のDEFにしたら、mh が $F13 になりました。
結果、mh+$1416 に文字化けが出ました。
"・wl],:P&p&u(r)("
うう、何故中黒になるのかはわかりません。
これらの結果を踏まえて調べてみます。m(__)m
10896/10877 DGF01024 めざら Re^7: 修正テスト版
( 1) 23/08/05 07:51 10895:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
そんなに言うほど使いにくいですかね〜.(笑)
基本的なキーアサインは変えていませんが,因みにどこに一番違和感が?
それはともかく,ですが
ばふつあで,その中黒に合わせて [UP](コード表示)してみてください.
本当に中黒(8145h)なのか,未定義コード(例えば 8259h など)なのか確認できます.
未定義コードが中黒で表示されるフォントの場合がある(結構多い)と思われるので,
そこはきっちり確認した方がよいかと思います.
10897/10877 BQO00549 konno Re^8: 修正テスト版
( 1) 23/08/05 17:08 10896:めざらさんへのコメント コメント数:1
> そんなに言うほど使いにくいですかね〜.(笑)
> 基本的なキーアサインは変えていませんが,因みにどこに一番違和感が?
マクロのキーアサインが色々違うし、私は Fキーで覚えているので他人のVZはわからないのです。
めざらさんは OUTLAW派のようですが、私は EXMENU がメインなのです。
私はバフツアもわからないので DUMP.DEF を使いたいのですが、起動法がわからない。(>_<)
めざらさんのVZ.DEFの [F03] の後ろに 起動キーを書きました。(^^;
> ばふつあで,その中黒に合わせて [UP](コード表示)してみてください.
> 本当に中黒(8145h)なのか,未定義コード(例えば 8259h など)なのか確認できます.
えーと、この操作がわからないです。
VZのバグパッチ版は関係ないことはわかりました。
現在VZの版の特定の絞り込みをしています。
10898/10877 DGF01024 めざら Re^9: 修正テスト版
( 1) 23/08/05 23:33 10897:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
> めざらさんは OUTLAW派のようですが、私は EXMENU がメインなのです。
OUTLAW は記述が簡易にできるからなのですが,EXMenu はわたしもよく使いますよ.
もっとも最近は [ESC]^ で呼び出すことが結構多いですね.
(高橋版ベースならインクリメントサーチのできるファイラなので楽)
割り当てたキーアサインよりファイル名の方が直感的だったりするので.
> えーと、この操作がわからないです。
ばつつあのマニュアルを読んでいただければよいわけですが……
メッセージラインに表示されたコード範囲の一番最初(左端)に該当部分を
合わせるために \[←]/\[→] で 1バイトずつスライド表示して調整します.
メッセージラインの最初にその「中黒」を持ってこられたら [UP] でコードを確認.
[DOWN] で元に表示に戻せます.(DUMPでも分かるでしょうけど)
10899/10877 BQO00549 konno Re^10: 修正テスト版
( 1) 23/08/06 01:26 10898:めざらさんへのコメント コメント数:1
> もっとも最近は [ESC]^ で呼び出すことが結構多いですね.
> (高橋版ベースならインクリメントサーチのできるファイラなので楽)
そうか、 [ESC]^ でしたね、これがわからなかったのでした。アルツじゃ〜
> ばつつあのマニュアルを読んでいただければよいわけですが……
す、すみません、お手数をおかけして。m(__)m
> メッセージラインに表示されたコード範囲の一番最初(左端)に該当部分を
> 合わせるために \[←]/\[→] で 1バイトずつスライド表示して調整します.
> メッセージラインの最初にその「中黒」を持ってこられたら [UP] でコードを確認.
> [DOWN] で元に表示に戻せます.(DUMPでも分かるでしょうけど)
出来ました! これですね。
2329h:'・=88h=136 '・'=5488h=21640=21640 ・wl],:P&p&u(r)(r)>!{(#t-c2&r)>C
中黒のコードは 5488h ですね、DUMP でも同じでした。
CTRL.DEF で $8854 は以下になりました。見た目は中黒($8145)と同じですね。
・
10900/10877 DGF01024 めざら k07v系におけるマクロバッファ書換え位置確定?
( 1) 23/08/06 07:47 10899:konnoさんへのコメント コメント数:2
参照先:http://mezala.la.coocan.jp/
> 2329h:'・=88h=136 '・'=5488h=21640=21640 ・wl],:P&p&u(r)(r)>!{(#t-c2&r)>C
#T(23h 54h)が 88h 54h になりますか…… 2バイトではなく 1バイト書換えですね.
……ということであれば,相対的な書換え位置は確定ということで OK ?
書換え位置は変わらず,ちょっとした環境の違いで異なる値になるということかな.
他の方の環境で mh+$1416 はどうなっているでしょうか.
[ESC]@ などで即席確認できますので,見ていただけるでしょうか?
konno さんも,ご自身の環境で確かめてみてください.
わたしは検証用として製品版DEFに巨大自前バッファを配置して,
mh+$1416 以外に書換えが発生していないか確認してみようと思います.
10901/10877 DGF01024 めざら k07v系の問題ではないのか?
( 1) 23/08/06 10:20 10900:めざらさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
ううう,製品版DEFで起動すると,書換えが確認できませんでした.(?_?)
以下,やってみた手順を示します.
1 製品版DEFに手を加えずに k07v6k で起動(vz/vzibmjなど)
書換えを確認できず.(mh+$1416 は vzfl.def のマクロエリア最後の方を指す)
2 製品版DEFのBMのみ30000に書換えて同様に起動
書換えを確認できず
3 製品版DEFのマクロエリアの最後に自前バッファを配置して起動
44 ""
01:"$(00,20)$[8192]"
上記の自前バッファを,矩形ブロック呼出マクロ(43)の直後に配置
書換えを確認できず
周辺はすべてヌルで埋められているまま.
う〜ん...いよいよわからなくなってきた.
k07v6系の問題ではないということ??
他に検証方法を思いつかないなぁ……
10902/10877 DGF01024 めざら 結局一時しのぎで
( 1) 23/08/06 11:39 10901:めざらさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
VZ.DEF の内部マクロの配置を入れ替えて,Pに書き換わる位置をずらし,
「Swap Text」のタイトルを持つマクロのタイトル文字列の p の位置に
mh+$1416 が来るように調整しました.結果→「SwaP Text」に.(笑)
あーあ,ほんとに一時しのぎだなぁ……
10903/10877 BQO00549 konno Re: k07v系におけるマクロバッファ書換え位置確定?
( 1) 23/08/06 23:40 10900:めざらさんへのコメント コメント数:1
> ……ということであれば,相対的な書換え位置は確定ということで OK ?
> 書換え位置は変わらず,ちょっとした環境の違いで異なる値になるということかな.
VZ.COM の各種バージョンで試してみたら、アドレス違いのバージョンもありました。
2018/10/07 19:12 62,664 vzk75e.com mh+$13f0=$2303
62 ^F "" ;Line End m.gann;[\] next spc
?. (ks&1)?{ (ct<3)?#f :r #d (ct>2+ck)?>r. }
↑
21F9: 72 23 64 28 63 74 3E 32-88 63 6B 29 3F 3E 72 2E r#d(ct>2・k)?>r.
"+"($2B) → $88
2017/09/09 09:28 62,666 vzk7t5.com mh+$13f2=$2305
62 ^F "" ;Line End m.gann;[\] next spc
?. (ks&1)?{ (ct<3)?#f :r #d (ct>2+ck)?>r. }
↑
2203: 2B 63 88 29 3F 3E 72 2E-7D 23 66 00 3F 18 01 FF +c・)?>r.}#f・?・・・
"k"($6B) → $88
2017/09/06 22:39 62,644 vz-5.com mh+$13dd=$22f0
?. (ks&1)?{ (ct<3)?#f :r #d (ct>2+ck)?>r. }
↑
21E3: 00 06 FF 00 3F 2E 28 6B-73 26 31 29 3F 88 28 63 ・・・・?.(ks&1)?・(c
"{"($7B) → $88
基本的に VZK07T5 以降で現象が起きているようですが、アドレスが違いますね。
上記の例では、置き換わるコードの一桁目が "$B" で共通しているのが興味深いですね。
ビットの下4桁が 1011 ですね。
あと、例外もありました。
2015/11/04 00:36 62,262 vzk7t2a.com mh+$13af=$22c2
61 ^A "" ;Line Top m.gann;[\] back str
?. (ks&1)?{ #a :r (lx)?{ #s (ct>2+ck)?>r #d }. }
↑
21B5: 73 26 31 29 3F 7B 23 88-3A 72 28 6C 78 29 3F 7B s&1)?{#・:r(lx)?{
"a"($61) → $88
これは中身を見てみないとなんともいえないですね。
ビットは 0001 か・・・
"#"($23) 0011 うーむ・・・
10904/10877 BQO00549 konno Re: 結局一時しのぎで
( 1) 23/08/06 23:49 10902:めざらさんへのコメント
> VZ.DEF の内部マクロの配置を入れ替えて,Pに書き換わる位置をずらし,
> 「Swap Text」のタイトルを持つマクロのタイトル文字列の p の位置に
> mh+$1416 が来るように調整しました.結果→「SwaP Text」に.(笑)
ぷっ・・・ 思わず笑ってしまいました。(゚゜)☆\(--#)バキッ
いや、冗談抜きで上手いですね。(^^;
> あーあ,ほんとに一時しのぎだなぁ……
私家版VZ が原因の可能性があるのでご迷惑をおかけします。m(__)m
10905/10877 DGF01024 めざら Re^2: k07v系におけるマクロバッファ書換え位置確定?
( 1) 23/08/07 07:39 10903:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
色々試していただき,ありがとうございます.
その環境って,わたしがお送りした DEF なわけだと思いますが,
konno さんの手元の環境では書換えは発生していないということでしょうか?
VZ の版が関係はするようだ(特定の版グループで発生)ということではあるけれど,
トリガーになっているのは,めざらの設定ということなのでしょうか.
それとも,いずれの環境でも発生しているけれど単に気付かないだけなのか……
謎は深まる……
手元の VZ.DEF は一通り眺めたのですが,自己書換えするようなコードないんですよ.
10906/10877 BQO00549 konno Re^3: k07v系におけるマクロバッファ書換え位置確定?
( 1) 23/08/08 02:34 10905:めざらさんへのコメント コメント数:1
> その環境って,わたしがお送りした DEF なわけだと思いますが,
> konno さんの手元の環境では書換えは発生していないということでしょうか?
はい、めざらさんの DEF です。
私の DEF では表面上は出ていないですが、わかりません。
めざらさんの DEF では他の現象も出ました。
2017/09/09 09:23 62,666 vza.com
この版などいくつかの版では、書換は確認できません。
そのかわり、マクロモジュールの破壊が起こる場合があります。
VZ起動してファイルを読み込んで、[ESC]M でマクロモジュールメニューを出すと
┏━ Modules <free:20002/30269> ━━━━━┓
┃ ! vz.def v1.6 6479 ┃
┃ fl.def v1.6 569 ┃
┃ outlaw.def (v2.20) 999 ┃
┃ automenu.def 778 ┃
┃ ex 790 ┃
┗━━━━━━━━━━━━━━━━━━━━┛
こうなっていますが、free 表示がおかしいですね。これで
DUMP.DEF のファイルを開いて、^k^ で再カスタマイズすると
┏━ Modules <free:-9609/658> ━━━━━━┓
┃ ! vz.def v1.6 33303 ┃
┃ E Dump.def 5923 ┃
┗━━━━━━━━━━━━━━━━━━━━┛
こうなります。他のモジュールが消えて free がマイナスになりました。
この free 表示には
10 "Modules <free:$BM/$x>",40,0
このシステムメニューで、変数 x を使っていますよね。
5 [ESC]M @M "Module Menu" ;Yushi local:H・ear
x$fdfb+bm-pn..-26, ; dc15#5267 m.gann
ここで変数 x を設定していると思います。
このルーチンは私も意味も分からないまま使っています。
この定数 $fdfb って何なのでしょう?
ちなみに、再カスタマイズルーチンは
56 ^K^ "Install"
?. P(0)
この後ろの方にマクロを追加してみました。
80 @^ "~" "〜" .
これでマクロサイズが少し増えたので試すと
Modules <free:20002/30255>
となり、DUMP.DEF を ^k^ で再カスタマイズすると
┏━ Modules <free:14079/24332> ━━━━┓
┃ ! vz.def v1.6 6492 ┃
┃ fl.def v1.6 569 ┃
┃ outlaw.def (v2.20) 999 ┃
┃ automenu.def 778 ┃
┃ ex 790 ┃
┃ E Dump.def 5923 ┃
┗━━━━━━━━━━━━━━━━━━━━┛
こうなって正常に出来ました。
# どうなっているんじゃ〜〜
10907/10877 DGF01024 めざら Re^4: k07v系におけるマクロバッファ書換え位置確定?
( 1) 23/08/08 18:24 10906:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
あははは.そうなのですか……
わたしの手元では,そういうこと起こったことは一度たりともないですけどね.(笑)
> この定数 $fdfb って何なのでしょう?
BM を最大値で設定するために使用する定数です.
その数値には,そんなに厳密な意味はなくて,たぶん手作業で BM 設定値の
最大値は何になるのか実験して得た値だと思われます.(あくまで想像)
他のルーチンでは,x$fdfd+m+bm-pn..-26-2, ;限界Bmの計算(max 0-2) なんてのも.
> # どうなっているんじゃ〜〜
わたしもどうなっているのかわかりません.
他の人の環境では何が起こるかわかりませんね,楽しい!(笑)
10908/10877 BQO00549 konno Lf+ が原因か?
( 1) 23/08/09 01:15 10907:めざらさんへのコメント コメント数:1
> BM を最大値で設定するために使用する定数です.
> その数値には,そんなに厳密な意味はなくて,たぶん手作業で BM 設定値の
> 最大値は何になるのか実験して得た値だと思われます.(あくまで想像)
これはオリジナルVZ で得た値なのですよね。他のVZではズレるとかないでしょうか。
> > # どうなっているんじゃ〜〜
> わたしもどうなっているのかわかりません.
どうも、Lf+ の場合に起こるようです。
2バイト文字の処理とかで誤動作しているのかなぁ?
私は Lf- で使っているので気が付かなかったようです。
というか、普通は Lf- で、必要な時に Lf+ にするのではと思っていました。
めざらさんの DEF では、ファイラーで "V" のトグルで LFN の切り替えしないので。(>_<)
10909/10877 DGF01024 めざら Re: Lf+ が原因か? (確認しました)
( 1) 23/08/09 08:20 10908:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
> これはオリジナルVZ で得た値なのですよね。他のVZではズレるとかないでしょうか。
それは制作者たる konno さんが一番よくご存知のことかと思いますが……
いずれにしても計算上最大値に応じて設定した BM が何らかの理由でエラーになれば,
「メモリが足りません」の場合は設定値を減らすだけのことですから.
m.gann師の vzx/vzz を使用して BM 最大値で常駐するとかなら影響は即出ますが,
計算上最大値 x はあくまでも「表示」ですから大した影響はないかと思います.
> どうも、Lf+ の場合に起こるようです。
試しに,Lf- で起動したところ症状が出ませんでしたが,起動後にファイラーを
ロングに切り替えて再度確認したら,書換え症状が発生しました.
> というか、普通は Lf- で、必要な時に Lf+ にするのではと思っていました。
わたしは高橋版での Lf 新設以降,一貫して Lf+ です.無効になっていた時期も
ありますが,konno さんが復活してくれる前から特にいじっていなかったかと.
> めざらさんの DEF では、ファイラーで "V" のトグルで LFN の切り替えしないので。(>_<)
そういえば,わたしはファイラー最上段のメニューを無視してましたね.(笑)
ロング表示の新設以降,ファイラーコマンドの #V は意味が変化しました.
旧横分割(超ショート表示)をロング表示が乗っ取ったからです.
それでもファイラー表示中に Lf を切り替えても再表示の必要があるため,
#V の繰り返しによる表示リフレッシュのために必要ではあったのですね.
それをワンキーで済ませるため,lf!, #V #V を仕込んで L で呼んでいます.
他の表示変更とも共有した再表示(#U)させるルーチンをさらに呼んでいます.
あ,脇道に逸れましたが,原因が判明したということは修正されるってことですね.
ばんざーい.\(^o^)/ (以前と Lf 関連ルーチンが異なるわけ?)
……いや,それにしても,Lf 原因ってよく分かりましたね.
常時+のわたしには永久に分からなかったな,絶対.
10910/10877 BQO00549 konno Re^2: Lf+ が原因か? (確認しました)
( 1) 23/08/10 01:17 10909:めざらさんへのコメント
> m.gann師の vzx/vzz を使用して BM 最大値で常駐するとかなら影響は即出ますが,
> 計算上最大値 x はあくまでも「表示」ですから大した影響はないかと思います.
めざらさんの DEF で vzx やってみたら、bm29991 になりました。
29991-bm-pn..-26, = 14656 = $3940
x=$3940 にすると、free 表示が 29991 になります。
> 試しに,Lf- で起動したところ症状が出ませんでしたが,起動後にファイラーを
> ロングに切り替えて再度確認したら,書換え症状が発生しました.
やはり Lf が原因なのでしょうかね。
> そういえば,わたしはファイラー最上段のメニューを無視してましたね.(笑)
そ、そんなぁ、め、めざらさ〜ん。(;_;)
> それをワンキーで済ませるため,lf!, #V #V を仕込んで L で呼んでいます.
おお、L でLFN切り替え出来ました。\(^^)/ ヤッタ-
> あ,脇道に逸れましたが,原因が判明したということは修正されるってことですね.
> ばんざーい.\(^o^)/ (以前と Lf 関連ルーチンが異なるわけ?)
い、いやぁ、修正できるかどうかは・・・ (^^;;
> ……いや,それにしても,Lf 原因ってよく分かりましたね.
オプションの違いかと思って、OPT_LST を見比べたら、LF+ に??? となったのです。(^^;
10911/10877 BQO00549 konno 原因はロングファイラー
( 1) 23/08/16 21:18 10877:めざらさんへのコメント コメント数:2
タイトルで終わってもいいかな・・・ (゚゜)☆\(--#)バキッ
・・・というわけにもいかないので、解明のいきさつを書いてみます。(^^;
各種VZで調べると、k07s5 (2009-12-12)までは出ず、k07t (2010-01-04)以降現象が出ます。
k07t の目玉はロングファイラーなんですよね。
とりあえず、main open text inst など各種ASM を k07s5 のと入れ替えても現象は変わらず。
filer.asm を入れ替えたら現象が出なくなりました。やっぱりロングファイラーか?
ここで入れ替わる文字コードに注目しました。
めざらさんの DEF では、"P" コードは $50 = 80 WD=80
私の DEF では、 "・" コードは $88 =136 WD=136
そうです、この数字は、WD の値なのでした。
ロングファイラーのルーチンでは、WD の値をローカルワークに入れてやり取りしていました。
そのローカルワークの値をコードセグメントのつもりでスタックセグメントに書き込んでいたようです。
だから LF+ で現象が出ていたわけです。
大ポカをやらかしていました。(>_<)
めざらさん、みなさま、バグバグなVZに気づかず公開していて申し訳ございませんでした。m(__)m
めざらさんのおかげでバグに気が付きました。ありがとうございました。m(__)m
10912/10912 BQO00549 konno VZk07v6k (2023-08-16)
( 1) 23/08/16 23:52 コメント数:1
VZk07v6k (2023-08-16)バグ修正で更新しました。
見つけてくれためざらさんに感謝です。m(__)m
k07v6k (2023-08-16)
・k07t からのロングファイラールーチンにバグ有、マクロバッファ内が書き換わっていました。
・LFN処理のバッファを tmpbuf4 から 別メモリに取りました。その分サイズが増えています。
・[ESC]i ファイル挿入時のVZの不具合を修正してみた (検証中)
※BL1024*3 だとファイル内容が壊れます。(全てのVZで起こるバグなのでこの設定は危険)
詳細は掲示板を読んでください。不具合を見つけたら掲示板に報告願います
ダウンロード vzkv6k.lzh ver1.60k07v6k (2023-08-16版 ) new!
ソース差分 2023-08-16 50,642bytes k07v6ks.lzh new!
VZの部屋にあります。
10913/10877 CRG00666 文太 Re: 原因はロングファイラー
( 1) 23/08/17 00:18 10911:konnoさんへのコメント コメント数:1
す、すごい!
konnoさん
>とりあえず、main open text inst など各種ASM を k07s5 のと入れ替えても
>現象は変わらず。filer.asm を入れ替えたら現象が出なくなりました。
>やっぱりロングファイラーか?
やったこと(泥縄、「まだやれることはある!」作戦)、大筋は理解できました。
>ここで入れ替わる文字コードに注目しました。
>めざらさんの DEF では、"P" コードは $50 = 80 WD=80
>私の DEF では、 "・" コードは $88 =136 WD=136
>そうです、この数字は、WD の値なのでした。
詳細は分かりませんが、ファイラでもWD使うんだ。filer2.asmでなく。
dos/vですものね。
>そのローカルワークの値をコードセグメントのつもりでスタックセグメントに
>書き込んでいたようです。
セグメントの話は分かりませんが、仕留めたんだ。
おめでとうございます。
すごいです、本当にすごいです。
とんでもなく暑い夏ですが、konnoさん、、、、好きです!
10914/10877 BQO00549 konno Re^2: 原因はロングファイラー
( 1) 23/08/17 01:15 10913:文太さんへのコメント
> やったこと(泥縄、「まだやれることはある!」作戦)、大筋は理解できました。
私は素人なのでプロのようにデバッガを駆使してとか出来ませんので。(^^;
> 詳細は分かりませんが、ファイラでもWD使うんだ。filer2.asmでなく。
> dos/vですものね。
ファイラーの窓枠の幅は、80桁固定なんですよね。WD=80 という定数を使っています。
ロングファイラー実現のためには WD をそのまま使えないので、fl_wd というローカルワークに窓幅を入れたのです。
pushm <ax,es> ; ##k
clr ax ;
mov es,ax ;
mov al,byte ptr es:[dosscrn_sx] ; ##156.123
mov fl_wd,al ;
fl_wd に DOSの幅の数値を入れたのですが、これだと SSセグメント(マクロバッファ)に入ったみたいなのです。
mov cs:fl_wd,al ;
このように、 CS: を付ければ書き込み先がコードセグメントに指定されるのでした。
> とんでもなく暑い夏ですが、konnoさん、、、、好きです!
わ、私には妻が・・・(゚゜)☆\(--#)バキッ
もちろんこれは冗談ですが、私も皆さんが好きです。
よかったら試してみてね。♪
10915/10877 DGF01024 めざら Re: 原因はロングファイラー
( 1) 23/08/17 18:51 10911:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
> そうです、この数字は、WD の値なのでした。
なるほど.設定が同じはずなのに VTDOS と DOSVAXJ3 で異なる値になったのは
WD の違いだったわけですね.いや,よくわかったねー!
10916/10912 DGF01024 めざら Re: VZk07v6k (2023-08-16)
( 1) 23/08/17 21:20 10912:konnoさんへのコメント
参照先:http://mezala.la.coocan.jp/
K07V6K 動作を確認しました.
はっきりとした原因が判明していただけに,完全に修正されたと思われます.
お疲れ様でした.ありがとうございました.
10917/10877 BQO00549 konno Re^2: 原因はロングファイラー
( 1) 23/08/18 01:23 10915:めざらさんへのコメント
> なるほど.設定が同じはずなのに VTDOS と DOSVAXJ3 で異なる値になったのは
> WD の違いだったわけですね.いや,よくわかったねー!
なるほど、そこが違ったのですね、原因がわかってみれば納得です。
わかったのは、めざらさんが DEF環境を提供してくれて再現が出来たからですね。
"P" の文字コードとかヒントは最初からあったのですよね。
私は基礎も勉強せずに我流で今までやってきていたので、今回のようなことになったのでしょう。
最近になって基礎から勉強し直しているので少しはわかるようになったのかもしれません。(^^;
今までバグバグなVZでご迷惑をかけていて申し訳ありません。m(__)m
10918/10918 BQO00549 konno mogura.def のおかげ
( 1) 23/09/15 01:12 コメント数:1
暇、じゃなくて夏バテで何もやる気が起きないので、ゲームを弄ってみました。
たまたま目に入った mogura.def をやってみましたが、動作がおかしい。
KVZ以外では正常に動いているみたいなのですが、KVZのバグ?
不具合の内容は
・ステータスラインの色消しが効いていない
・終了時に WE 編集画面幅が 2 になってしまう
現象から見てプッシュポップの不具合とか?
KVZのかなり初期まで同じ現象になります。げげげ
・・・・あれ? これってもしかして、
#if kVZ
の分岐の不具合、たぶんオープンイベントマクロの不具合?
調べてみるとやはりオープンイベントマクロの不具合でした。
1 "!Open"
#if kVZ
Vu-,as112,ao224,ar176,
&Sf(nm,'.') (r)?? { ts="\x ^[EOL#%(]", Ew-,Eu-, }
p[, p=r,
&So(".hte",p) (r)?{ Vu+,as~,ao~,ar~,ts="\x ^\0/\0",Ew+,mr128, >A }
(ne=='LE'||ne=='TE')?{ Vu+,as~,ao~,ar~,ts="\x ^\0/\0",Ew+,mr128, >A }
#endif
p[, p=r,
:A p],
こんなことをやっていました。
これでは設定していない拡張子のオープン時、プッシュポップが狂ってしまいます。(>_<)
うげぇ、今までこんな状態で使っていたんだ・・・・
ということで、mogura.def のおかげでマクロのバグを発見出来ました。
ありがとうございます。m(__)m
# このゲーム、点数がマイナスになっちゃうので悲しい。(;_;)
w150, を w600, にすると間延びした感じで・・・
[ESC] を押してもすぐに終わらないので、改造出来ないかしら・・・
そうそう、mogura.def とは、めざらさん作のもぐらたたきゲームです。m(__)m
10919/10918 DGF01024 めざら Re: mogura.def のおかげ
( 1) 23/09/15 18:49 10918:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
その現象って,もぐらに限らないような気もしますが,修正のきっかけとなったので
あれば,まぁ,よかったのかもしれません。
> # このゲーム、点数がマイナスになっちゃうので悲しい。(;_;)
それが本来の設定ですから……あ,あれ? Score マイナス 1604 ですと?
連打したのにマイナス?! おかしいなぁ……お手つき扱いなのかな。
でも,ヒットがなければそのステージでゲームオーバーになるわけだから,
何かが変なんだなぁ……なんだろう。あはは,わかんないや。(笑)
> [ESC] を押してもすぐに終わらないので、改造出来ないかしら・・・
すぐに終わらせたい場合,何もしなければそのステージで終わるはずです。
10920/10918 BQO00549 konno Re^2: mogura.def のおかげ
( 1) 23/09/16 00:03 10919:めざらさんへのコメント
> その現象って,もぐらに限らないような気もしますが,修正のきっかけとなったので
> あれば,まぁ,よかったのかもしれません。
いやあ、不具合にはあっていたかもですが、ずっと気が付かなかったのです。(^^;
てっきり KVZ のバグかと思って焦りました。<(^^;)
> > # このゲーム、点数がマイナスになっちゃうので悲しい。(;_;)
> それが本来の設定ですから……あ,あれ? Score マイナス 1604 ですと?
> 連打したのにマイナス?! おかしいなぁ……お手つき扱いなのかな。
VTDOS などエミュではキーの取りこぼしなどがあるかもしれません。
r の値は変数に保存した方がいいかもしれませんね。
> でも,ヒットがなければそのステージでゲームオーバーになるわけだから,
> 何かが変なんだなぁ……なんだろう。あはは,わかんないや。(笑)
(^^; (^^; (^^;
> > [ESC] を押してもすぐに終わらないので、改造出来ないかしら・・・
> すぐに終わらせたい場合,何もしなければそのステージで終わるはずです。
ちょっと弄ってみたら止まらなくなる場合がありました。(>_<)
ムズイです。(^^;;
10921/10921 BQO00549 konno VZ改造人間誕生から20年
( 1) 23/09/16 23:40 コメント数:2
気が付けば私がVZ改造人間になってから20年が過ぎてしまいました。
そのきっかけは2003年4月にVAIO XP を買ったことです。
WindowsXPのDOS窓は高橋版VZのファイラーでLFNが使えないのでした。
ガーーーーーン!!!
ではこの時の顛末を替え歌風に
(DOSの終焉が)迫る〜ショック!!
(VZのソース解読は)地獄のASM
(だけど何かが出ちゃう)我等の前には黒い画面
(改造のためなら平気なの)VZ世界の平和を守るため
ゴーゴー・レッツゴー
輝くマシン語
今だーー「ジャンプ!」
ここだー「分岐ック!」
画面ファイラー
画面ファイラー
ロング名ファイラー
かくして7月に高橋版VZのLFNパッチを引っ提げてメジャーデビューしたのでした。
まあ、これだけなら唯のパッチ屋で終わったのですが
8月、南十字星を見て★に憧れ、アイドルデビューしてしまいました。
こうしてまた一人 VZ改造人間が出来上がったのでした。(^^; ヒィー
10922/10921 CXB00940 としき Re: VZ改造人間誕生から20年
( 1) 23/09/17 12:47 10921:konnoさんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
> 気が付けば私がVZ改造人間になってから20年が過ぎてしまいました。
なるほど、改造される側ではなく改造する側なわけですね。
すると「konnoなにがしは改造人間である」とナレーションで流れているときに
メスを振るう側がkonnoさんで、手術台の上でジタバタしているのは手足の生えた
黒本、とか。あぁ、イメージが膨らむ。
10923/10921 DGF01024 めざら Re: VZ改造人間誕生から20年
( 1) 23/09/17 13:40 10921:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
替え歌にすると,盛ってるなぁ〜って感じですが,
そこここに散りばめられ仕込まれたネタの数々。
さすがです。
10924/10921 BQO00549 konno Re^2: VZ改造人間誕生から20年
( 1) 23/09/17 23:23 10922:としきさんへのコメント
> なるほど、改造される側ではなく改造する側なわけですね。
私もMS軍団の支配に下り、しかたなく改造に手を染めることになってしまいましたが
今では改造せずにはいられない体にされてしまいました。(^^;
> すると「konnoなにがしは改造人間である」とナレーションで流れているときに
> メスを振るう側がkonnoさんで、手術台の上でジタバタしているのは手足の生えた
> 黒本、とか。あぁ、イメージが膨らむ。
うわ、どんなイメージですか。(^^;
勉強不足だったですが、原作は人間の自由を守るために戦っているのですね。
私も黒い画面ライターとして、V7号を作り上げました。
行け、V7号、テキをやっつけろ!
10925/10921 BQO00549 konno Re^2: VZ改造人間誕生から20年
( 1) 23/09/17 23:45 10923:めざらさんへのコメント
> 替え歌にすると,盛ってるなぁ〜って感じですが,
いやあ、妄想話は盛ってなんぼですから。(^^;
> そこここに散りばめられ仕込まれたネタの数々。
替え歌を考えていると次々に余計なことが浮かんでしまうんですぅ。(゚゜)☆\(--#) ビョーキジャ
10926/10926 DGF01024 めざら DOSVAXJ3 230919 更新
( 1) 23/09/20 09:29 コメント数:1
参照先:http://mezala.la.coocan.jp/
DOSVAXJ3 が更新されていました。
更新内容は
----------------------------------------------
build JP230919 (2023/9/19)
・拡張 CGA テキストモード 73h, 71h に対応しました。
・PC-DOS 付属のエディタ(E, TE)でカーソル表示がおかしかったのを修正しました。
----------------------------------------------
7月更新に比べると,それほど VZ に関係することはないですかね。
(CGAって LX くらいしか浮かびませんが,そもそも DOS なわけで……何かな)
いずれにせよ,作者様に感謝です。
10927/10926 BQO00549 konno Re: DOSVAXJ3 230919 更新
( 1) 23/09/20 23:07 10926:めざらさんへのコメント
> DOSVAXJ3 が更新されていました。
めざらさん、お知らせいただきありがとうございます。
昨日か一昨日、軟式さんのサイトを覗いたんですが更新されていないなーと思っていました。(^^;
今日見ても更新されていなくて、更新ボタンで見られました。\(^^)/ ヤッタ-
> 7月更新に比べると,それほど VZ に関係することはないですかね。
> (CGAって LX くらいしか浮かびませんが,そもそも DOS なわけで……何かな)
LX専用のテキストアプリとかが動くんですかね?
モード切替を試してみると、CHEV 71 とかではモード70 になってしまって切り替え出来ない?
CHEJ 71
これでモード71 に切り替わりました。
見た目は 70 と変らないですね。(^^;
今のところ使い道はわからないです。
> いずれにせよ,作者様に感謝です。
同感です、ありがたく使わせてもらいます。
# 携帯端末は、ATOK8 が使える 200LX が一番文字入力しやすかったですね。(゚-゚)トホイメ