この記事は、ココログからの転載です。
http://tamaneko2.cocolog-nifty.com/vz2/

DOSVAXJ3のVGAで動くアナログ時計とカレンダのアクセサリをアップします。

きっかけは、最近文字が見えづらくなって、デジタル文字の時間がパッと読めなくなったことです。
大きなアナログ時計がパソコンで常駐出来ればなぁ・・・・

そうだ！　昔作った時計のアクセサリがあるじゃないか！
DOSVAXJ3で常時表示させておけば便利かも。

ということで、この古いプログラムの復活計画が始動したのでした。、
お茶を1分蒸らす時やカップ麺の3分などチェックできるタイマー機能もあります。(^_^)

現状データファイルの置き場所指定できないので、カレントに全部置いて使ってください。
DOSVAXJ3を起動したら、chev jp して、ファイル群のあるフォルダをカレントにしてから起動してください。

STIME.EXE を起動すると
このようにアナログ時計を表示します。

[F1]キーを押すと
このように大きなカレンダを表示します。
休日も表示します。

[F2]キーを押すと
このように、次月まで表示します。
誕生花と日程も表示されました。
これらは2度キーを押さないと表示しないようで、バグですね。まあおまけですので。

[PGDN]を押すと、押すたびに時計が拡大します。
[PGUP]を押すと、押すたびに時計が縮小します。

[ALT]+[F2]を押すと、秒針が太くなります。
[ALT]+[F4]を押すと、時分針が青くなります。
青い色を付けると、色が残ることがあります。
また、色付きの時は秒針が十字の位置で消えることがあるので太い秒針を用意しました。
SIN,COSの計算精度かPAINTの影響か、DOSVAXJ3 との相性か、わからないです。

簡易タイマーも2系統あるので、作業時間をチェックするとかに使えます。

簡易的な機能説明書も同梱したので、色々弄ってみてください。

自作、改作アプリの放置部屋 　に置いてあります。

いくつか間違いなど修正したのでファイルを差し替えました。11月18日版をお使いください。

todayx.bat は、実際には today2.bat で動いていたので、表記やファイル名を today2 に統一しました。

sedit.bat は、常駐VZから STIME.EXE を起動して BAT でVZを呼ぶと上手く動かないようです。
JED などのフリーのエデイタを指定してください。
常駐VZで上手く動かす方法、ありましたっけ？

＃　常駐VZを使いたいのに本末転倒のような。(^^;

konnoさん

　いー感じ。楽しそう。
　昨晩『AWAKE』という将棋ソフト開発についての映画をNetflixでみて、
今日、これを見て、ああ、プログラミングしたい、と久しぶりに思いました。
　いろいろいろいろあって、konnoさんが認知症になる前に（僕も続きまーす！）
いっぱい聞きたいのだけど、ううう、残念。
　たぶん、僕がやりたい技術がつまってるソフト。テキストファイルを読み込んで
表示、なんですよね。ベーシックも楽しそう。
　とはいえ、ベーシックだとライブラリーモジュールとか方言とか、いろいろある
んでしょうね。
　dosvaxが敷居、高い、、、。
　WinMEをはやく直さないと、、、。DOS機、はやく作りなおさくちゃ、、、。
　ぶぶぶぶ、の文太でした。
　もうちょい沈んでます。m(__)m

　うん、常駐Ｖｚで使えないと、、、。敷居たかそうだなぁ、、、。

文太さん、お元気そうでなによりです。

> 　昨晩『AWAKE』という将棋ソフト開発についての映画をNetflixでみて、

面白そうですね、私も昔ポケコンBASICでオセロの対人ゲームのソースを改造して
対コンピュータのオセロを作ったことがあります。恐らく世界最弱のアルゴリズムです。(^^;
私自身がオセロ弱いもので。(^^;
ソースは恐らくもう無いと思われます。もったいないことをしたなぁ・・・

> 今日、これを見て、ああ、プログラミングしたい、と久しぶりに思いました。

私もBASICのソースを弄っていて、やっぱりこういうのが好きなんだなぁ、と思いました。(^^;

> 　いろいろいろいろあって、konnoさんが認知症になる前に（僕も続きまーす！）

私も色々あって健康不安などもあるし、ボケも進んでいきそうなので、備忘録など書いています。

> 　たぶん、僕がやりたい技術がつまってるソフト。テキストファイルを読み込んで
> 表示、なんですよね。ベーシックも楽しそう。
> 　とはいえ、ベーシックだとライブラリーモジュールとか方言とか、いろいろある
> んでしょうね。

あ、ソースいりますか。汚いけど参考になるならソースもアップしようかな。
古い雑誌の例題ソースなどは弄って公開しても問題ないですよね。(^^;

> 　dosvaxが敷居、高い、、、。

軟式さんのサイトから最新のdosvaxをダウンロードして展開したらフォルダそのままで使えます。
#10764： Re^2: DOSVAXJ3 (2023/4/14) 更新 投稿者： konno 　 2023/04/15(土) 
#10765： DOSVAXJ3の dosboxj.conf 設定例 投稿者： konno 　 2023/04/15(土)
あたりが設定の参考になると思います。簡単ですよ。(^^;

> 　うん、常駐Ｖｚで使えないと、、、。敷居たかそうだなぁ、、、。

とりあえず JED を入れてみました。結構使えそうです。(^^;
本来は自作のエデイタもどきと連携していたんですがね。(^^;

STIME.EXE 説明書	Ver 8.231116

DOSVAXJ3のVGAで動くアナログ時計とカレンダのアクセサリです。
現状データファイルの置き場所指定できないので、カレントに全部置いて使ってください。
DOSVAXJ3を起動したら、chev jp して、ファイル群のあるフォルダをカレントにしてから起動してください。


・STIME.LZH に同梱されているファイル
STIME.EXE	実行ファイル
STIME.TXT	このファイル
SEDIT.BAT	SEDIT.BATで指定したエデイタ(非常駐VZなど）で各種設定表を編集
TODAY2.BAT	TODAY2.BATで指定したCNFファイルでTODAYを実行 （歴史データ大型版表示など）
HOLIDAY.DAT	休日データ。TODAY のデータに準じている？　新しい祝日形式には対応していません。
SCHEDULE.DAT	日程データ。表示のバグがあるので実用ではないです。
FLOWER.TBL	誕生花　TODAY のデータを流用。使えるかは？


・ファンクションキーなどの機能

F1:ｶﾚﾝﾀﾞｰ 	当月の大きなカレンダーを表示
F2:ｶﾚﾝﾀﾞ2 	当月の大きなカレンダーと次月を表示
F3:ｶﾚﾝﾀﾞ3 	月を指定してカレンダーを表示
F4:日程 	SEDIT.BAT で指定したエデイタでスケジュール表SCHEDULE.DATを編集
F5:TODAY  	TODAY.EXE があれば TODAY を実行
F6:Time1  	タイマー１の表示。押すたびに経過時間を表示
F7:Time2  	タイマー２の表示。押すたびに経過時間を表示
F8:日時変 	日時の変更。DOSVAXJ3では時間の変更不可
F9: CLS  	画面をクリアして時計表示
F10: END 	終了

[SHIFT]
F1:MS-DOS 	終了
F3:Bio   
F5:TODAY2  	TODAY2.BAT で別の設定（TODAY3.CNFなど) でTODAYを実行
F7:Vmap 	VMAP.COM があれば VMAP を実行

[CTRL ]
F1:sys  	終了 （DOSVAXJ3 ではキーマップ表示？）
F2:HR   	

[ ALT ]
F1:end    	終了
F2:秒針2  	秒針表示を2本線に
F3:秒針1  	秒針表示を1本線に
F4:長針青  	時分針を青色表示
F5:長針透 	時分針を色無しで表示

[PGUP]  	押すたびにアナログ時計を縮小表示
[PGDN]  	押すたびにアナログ時計を拡大表示


・バグ、更新履歴
※　日程表示はカレンダ表示を2度押さないと表示しないバグ有り
※　DOSVAXJ3で負荷が100％になるのでキー入力ループで INT28 INT2F(AX1680)を入れた。
※　DOSVAXJ3でカーソルが表示しないのでグラフィックで疑似カーソル使用。

konnoさん

>私もBASICのソースを弄っていて、やっぱりこういうのが好きなんだなぁ、と思いました。(^^;
　この感じがジンジン伝わってきて、僕もけっこう幸福感かんじましたよ。

>私も色々あって健康不安などもあるし、ボケも進んでいきそうなので、備忘録など書いています。
　ガンガンいってください、というか、ぼちぼちぼつぼち行ってください！

>あ、ソースいりますか。汚いけど参考になるならソースもアップしようかな。
　いいですね！

>古い雑誌の例題ソースなどは弄って公開しても問題ないですよね。(^^;
　ない！　に一票！
　ソースがどんな見栄えなのか、想像もつかないんですよね。
　時計とカレンダーは実は完全に別物で、時間だけファンクションコール（これを
呼ぶモジュール？）、カレンダーはテキストから読み込んで表示、これらを合体させて
ファンクションキーで切り替える、とか想像したのですが。
　（この合体と切り替えが難しそう、と思いました）−−−とんちんかんなこと
言ってても怒っちゃやーよ。動かせてないのですから。

　アナログ時計の秒針を進めるのとかは、既存モジュールあり？　ああいう（？）
グラフィックなのは考えたことがない、、、。

>> 　dosvaxが敷居、高い、、、。
>軟式さんのサイトから最新のdosvaxをダウンロードして展開したらフォルダそのままで使えます。
　い、いつか、やります。vtdosもまともに使えてない、、、。

>> 　うん、常駐Ｖｚで使えないと、、、。敷居たかそうだなぁ、、、。
>とりあえず JED を入れてみました。結構使えそうです。(^^;
　僕も柔軟になりまして、これでいいじゃん、とも思いましたよ。JED, 16bit のフリー
エディタ。いいじゃないの。
　ただ、今日、久しぶりに「やっぱＶｚだろう」とか思っちゃたんですよね。
　いいですよ、このエディタ。Ｖｚっていうんですけど、

　俺の体（あるいは頭）、まだ大丈夫なのか？　とか思いながらも、
のんびりのんびり、ぐてぐてぐてぐて、いきましょう！
　ありがとうございます。m(__)m

> 　時計とカレンダーは実は完全に別物で、時間だけファンクションコール（これを
> 呼ぶモジュール？）、カレンダーはテキストから読み込んで表示、これらを合体させて
> ファンクションキーで切り替える、とか想像したのですが。

時間は time$ というシステム変数を使います。00:00:00 ( 時:分:秒 ) 文字列の形で入っています。
カレンダーは計算だけで表示できます。祝日データをテキストから読み込んで表示します。
VZマクロのカレンダーと同じことをやっています。言語形式が違うだけです。

> 　（この合体と切り替えが難しそう、と思いました）

合体は私の得意技です。無駄な部分を無くし変数を統一して最適化するのは結構大変ですが。(^^;

> 　アナログ時計の秒針を進めるのとかは、既存モジュールあり？　ああいう（？）
> グラフィックなのは考えたことがない、、、。

オリジナルの例題には秒針はありませんでした。

200 Y!=PI!-T2*PI!/30		'分針
210 Z!=PI!-(T1*60+T2)*PI!/360	'時針

オリジナルの記述です。コメントは私がつけたものです。
これを参考にして、秒針を追加したのです。

10390 X9!=PI!-T3*PI!/30: '秒針
10400 X!=X9!:	'秒針

文字盤の文字も、拡大縮小するためにドットデータを自分で作ったみたいです。（覚えていない）(^^;
時計も万年カレンダーもソースは1ページ以内で出来ているので打ち込みは大した手間ではなかったです。
改造部分で何倍にも膨らんでしまって今では何をやっているのか調べるのも容易ではないです。(^^;

> 　俺の体（あるいは頭）、まだ大丈夫なのか？　とか思いながらも、
> のんびりのんびり、ぐてぐてぐてぐて、いきましょう！

マイペースで行くのが一番ですね。
プログラミングはストレス発散のため！
＃　でもそれがストレスを生むという説も。(^^;

konnoさん

　ご丁寧にいろいろとありがとうございます。
　おもしろい！
　おもしろかったから、電脳組社製の「BASIC/98 for DOS/V」（注１）という
ベーシックのマニュアルとか、QBasic By Example とかの本をもってきてしまいました。
　まずＤＯＳ機を復活させないと、ベーシック・プログラムのインストールすら
できない、、、。
　dosvaxは？　敷居、たかし。気力が、、、。

　最初に。
>プログラミングはストレス発散のため！
>＃　でもそれがストレスを生むという説も。(^^;
　趣味ですよ、趣味。仕事も何にも関係ない。しかし仕事がらみだと、嫌になっても
根性で最後まで走るという動機があったりもしますが。（注２）
　パソピア、高いねぇ。でも、格好いいですねぇ。

　以下、というか全部、独り言みたいなものです。

　で、T-Basicというのは、Turbo Basicということですか？　ボーランド製？
　深い意味はありませんが、以下に、書法がそれぞれあるんだろうな、とか思い。

>時間は time$ というシステム変数を使います。00:00:00 ( 時:分:秒 ) 
>文字列の形で入っています。
　さすがベーシック。システム変数を呼ばれたら中でファンクションコール
してくれるんだ。Ｖｚのファイラで、「Ｋ」とやると「ディレクトリ作成ファンク」
を呼んでくれるのと同じですね。
　time$, date$。システム変数に「$」を末尾につけるのは、どこも同じみたい、、、。

>VZマクロのカレンダーと同じことをやっています。言語形式が違うだけです。
　この辺り、弱いですねぇ。読んだことないなぁ。
　基本的に、時計やカレンダーはＰＣの外でよい、という考えできております。
あれ？　データの読み込みと描画なの。

>合体は私の得意技です。無駄な部分を無くし変数を統一して最適化するのは結構大変ですが。(^^;
　うん、既存のものに付加機能を足すのは、うん、けっこう大変そうだ。

>200 Y!=PI!-T2*PI!/30		'分針
>210 Z!=PI!-(T1*60+T2)*PI!/360	'時針
　「!」は、ユーザ変数のマーキングですよね、きっと。使われなくなったLET
ステートメント。「!」最初、何かと思った。
　「T1」「T2」「T3」も、ユーザ変数ですよね？　？？？
　（行番号がまだ入ってる、、、。そうしないと、ベーシックのソースらしくない？
　　行番号ジャンプとかするの？）

>10390 X9!=PI!-T3*PI!/30: '秒針
>10400 X!=X9!:	'秒針
　「X9」の「9」の意味は想像できる。とりあえず「9」
　正確にではないですが、「30」とか「360」での割り算は、アナログで、円の中での
角度でしょうね。

>文字盤の文字も、拡大縮小するためにドットデータを自分で作ったみたいです。（覚えていない）(^^;
　これです！　やっぱそうなのかぁ！　やってみたい！

>時計も万年カレンダーもソースは1ページ以内で出来ているので打ち込みは大した手間ではなかったです。
>改造部分で何倍にも膨らんでしまって今では何をやっているのか調べるのも容易ではないです。(^^;
　うううう、大変そう。
　でも、気持ちも状態も経緯も、いちおう想像できます。意外に太るのよ。

　でも、とにかく。
　部屋の整理、心の整理、そしてＤＯＳ機復活作戦が優先順位となっております。
すみませぬ。


（注１）後継ソフト（ベーシック）がWin11で動きます、というのを社のサイトで
見つけた。がんばっておられますなぁ。世の中にニーズがあるんですねぇ。

（注２）どうでもいい注。例の『AWAKE』という将棋ソフト開発映画で、「ソフト作りたい！」
と思った主人公は、「プログラミング研究会」に入部します（大学生）。
　主人公は、元プロを目指した棋士。が、プログラミングは、ど素人。
　入部場面で書かされる自己紹介用データシートには、名前などのほか「使用言語」
という欄がある。彼は、「日本語」と書く。
　で、本を３冊渡される。「全部暗記してきて」。暗記完了。テスト合格。次、５冊。
そして、ついに、将棋ソフトが動き出す、、、。
　動機なんですよね。将棋学習の場面もプログラミング学習の場面も、雰囲気はほぼ同じ。
あふれる情熱。圧倒的な集中力。
　もう僕には残ってないかなぁ、という感想、、、。
　のんびりいこう！　ストレスためない程度にがんばろう！　という結論。

　上、ちゃんとＶｚで書きました。えばるこっちゃないぞ。
　あ、ソース、上げてください！

> 　で、T-Basicというのは、Turbo Basicということですか？　ボーランド製？

これは東芝製BASICという意味だと思います。元はMSのGW-BASICを日本語化したのでしょう。

> 　「!」は、ユーザ変数のマーキングですよね、きっと。使われなくなったLET
> ステートメント。「!」最初、何かと思った。

「!」は浮動小数点型の変数という指定です。
「%」は整数型の変数という指定です。同じ名前でもこれをつけると別の変数となります。

> 　「T1」「T2」「T3」も、ユーザ変数ですよね？　？？？

そうです。頭がアルファベットでシステム変数以外なら自由に名前が付けられます。

> 　（行番号がまだ入ってる、、、。そうしないと、ベーシックのソースらしくない？
> 　　行番号ジャンプとかするの？）

初期のBASICインタプリタは行番号が必須でしたが、最近のはいらないようですね。

> 　正確にではないですが、「30」とか「360」での割り算は、アナログで、円の中での
> 角度でしょうね。

その通りです、ちなみに、「PI!」は浮動小数点型のシステム変数で、3.14159 という円周率です。
（記憶で書いたけど合っているかな (^^;）

> 　でも、とにかく。
> 　部屋の整理、心の整理、そしてＤＯＳ機復活作戦が優先順位となっております。

私も同じです。(^^;　他にも懸案事項が山済みで。ヽ(^^;)ｵｲｵｲ

> （注１）後継ソフト（ベーシック）がWin11で動きます、というのを社のサイトで
> 見つけた。がんばっておられますなぁ。世の中にニーズがあるんですねぇ。

あの時代を生きた世代は BASIC が友達みたいなものなのかも。(^^;

> 　動機なんですよね。将棋学習の場面もプログラミング学習の場面も、雰囲気はほぼ同じ。
> あふれる情熱。圧倒的な集中力。

まさに、あの頃の情熱と集中力はもう戻らないのか・・・・

> 　もう僕には残ってないかなぁ、という感想、、、。
> 　のんびりいこう！　ストレスためない程度にがんばろう！　という結論。

結局長く続けるにはこれが一番！　ですね。(^^;

> 　あ、ソース、上げてください！

ただいまコメントを整理中です。(^^;
汚くて恥ずかしいけど揚げちゃいますね。(^^;

文太さんはＤＯＳ機復活ですか。
私はＸＰマシン復活中です。
生きているマシンはいくつかあるのですが、やっぱり画面サイズとかいろいろあって。
それはさておき。
かつてはN88-BASICがネイティブ、とか言っていた私としては、この辺の話題にも
足跡を残しておきたいかな、と。
なので、いろいろと散文を書き散らかします。

電脳組の「BASIC/98」は、for FMRを持っています。
ポケ３での動作確認のためだけに購入しました。
ざっくりと見た範囲では、きちんとポケ３でも動きました。
まだどこかにしまってあるはずだけど、どこにあるかなぁ。部屋に喰われた。
ちなみに、言語仕様は、かなりN88-BASICに近かったと記憶しています。
私の記憶が確かなら、その当時、後継を名乗れそうなほどN88-BASICに言語仕様が
近かった処理系が二つあって、そのうちのひとつが「BASIC/98」だったような。
ん〜、記憶が怪しい。

> 　dosvaxは？　敷居、たかし。気力が、、、。

これ、konnoさんもおっしゃっていますが、動かすだけなら敷居はないも同然。
解凍して実行ファイルを起動するだけですから、DOS窓を動かすのと比べていったい
何が違うのか、ぐらいの感覚。


以下、BASICのお話。
基本的に東芝のT-BASICとＮＥＣのN88-BASICはそこそこ似ているはずですが、konno
さんのお話だと、やっぱりちょっと違うみたい。
まず、おそらく同じであろう部分。もしかしたら違うかもしれないけど。
変数は、コードが実行されて初めて領域が確保されます。
この辺はインタプリタ言語であるawkやperlも同じはず。
だから、マイクロ秒の単位で時間を稼ぎたいプログラムの場合、プログラムの途中で
領域を確保する時間が惜しいということで、プログラム冒頭でたとえばゼロを代入
するなどして、そこで領域を確保しておく、なんて技を使っているコードも見かけ
ました。
変数の型については、接尾辞をつけなければ、デフォルトで実数型。
「!」をつければ明示的に実数型。
「$」だと文字列型、「%」だと整数型、「#」だと倍精度実数。
デフォルトを変えることもできました。
「DEFINT A-C」と宣言すると、頭文字がAからCで始まる変数は接尾辞なしで整数型。
「DEFSTR D-F」と宣言すると、頭文字がDからFで始まる変数は接尾辞なしで文字列型。

ここまではT-BASICとN88-BASICで同じ部分。
一方、なんとなく違ってそうなのがシステム変数。
N88-BASICにも、TIME$とDATE$はありました。
でも、円周率を表すシステム変数はありません。
なので、自分でプログラムの最初の方で、例えば「PI=3.14」とか代入していました。
だから、人によって、コードで使われている円周率が異なっていたり、円周率を表す
変数名がPIだったりPAIだったりと一定していなかったり。

あぁ、なんだってこんな、いにしえのBASICの文法解説をしているんだろう（笑）。

私もオセロのプログラムを作りかけていて、いまだに完成していないのですが。

> 面白そうですね、私も昔ポケコンBASICでオセロの対人ゲームのソースを改造して
> 対コンピュータのオセロを作ったことがあります。恐らく世界最弱のアルゴリズム

これ、とっても気になります。
どういうアルゴリズムだったか、覚えておられます？
ちなみに、私の作ろうとしていたのは、俗に優先順位法というアルゴリズムです。
全てのマスに１から６０までの優先順位をふって、優先順位の高い方から置けるか
判定して、置ければそこに置く、というやつ。なので、優先順位のふり方次第で、
それなりに強かったり全く弱かったり、となります。たとえば、四隅の優先度が
一番低かったら弱くなる、ということで。
そういえば、８ビットの昔も昔、PC-8001用のオセロと対戦したことがあるのです
が、えらく強かったなぁ。
こいつはロジック部分がフルアセンブラで、おまけに残り１０手になった時に残りの
手をすべて読み切る仕様となっていて、そこだけちょっと待ち時間が長かったのです
が、それでもほんの数十秒。
今のパソコンなら、１手ごとに最後まで読み切ることもできるのでしょうね。

> でも、円周率を表すシステム変数はありません。
> なので、自分でプログラムの最初の方で、例えば「PI=3.14」とか代入していました。
> だから、人によって、コードで使われている円周率が異なっていたり、円周率を表す
> 変数名がPIだったりPAIだったりと一定していなかったり。

あれ？　と思って確認してみたら、「PI!」は自分で設定していました。(>_<)
STIME.bas のソース

10080 X1=77-SC!*2:PI!=3.14159:
 
結局、円周率を表すシステム変数は無いというのが正解だったようです。
確認もしないで間違ったことを言って申し訳ないです。m(__)m

> あぁ、なんだってこんな、いにしえのBASICの文法解説をしているんだろう（笑）。

BASIC地獄、いやさ、天国への道はまだまだこれからですよ。(^^;

> 私もオセロのプログラムを作りかけていて、いまだに完成していないのですが。

おお、良いですね。こういうのはアルゴリズムを考えるのも楽しいですよね。
としきさんはオセロ強いですか？　私はヘタの横好きで。(^^;

> > 面白そうですね、私も昔ポケコンBASICでオセロの対人ゲームのソースを改造して
> > 対コンピュータのオセロを作ったことがあります。恐らく世界最弱のアルゴリズム
> 
> これ、とっても気になります。
> どういうアルゴリズムだったか、覚えておられます？

全く覚えていないんですよ。(;_;)
もしかしたらカセットテープにソースが残っているかもですが、今では取り出す方法が・・・
ああ、本当に諸々捨てないで取っておけば良かったなぁ、と思う今日この頃です。(;_;)

> ちなみに、私の作ろうとしていたのは、俗に優先順位法というアルゴリズムです。
> 全てのマスに１から６０までの優先順位をふって、優先順位の高い方からおけるか
> 判定して、置ければそこに置く、というやつ。なので、優先順位のふり方次第で、
> それなりに強かったり全く弱かったり、となります。たとえば、四隅の優先度が
> 一番低かったら弱くなる、ということで。

何となくそれに近い考え方で作ったような気がします。
でも出来たのは、世界最弱のコンピュータオセロでした。(>_<)
私自身が頭が悪いせいですね。(;_;)

> そういえば、８ビットの昔も昔、PC-8001用のオセロと対戦したことがあるのです
> が、えらく強かったなぁ。

将棋でもオセロでも、強い人がアルゴリズムを考えることで本当に強いものが出来るのでしょうね。

STIME.EXE は古いプログラムゆえ、カレンダは新祝日法に対応していません。
日曜が祝日の場合に月曜が振替休日になるようには作っているみたいですが。

で、コメントの整理中にふと、カレンダマクロが対応しているから見てみようかと思ったのです。
CALENDAR.DEF　Yushi さんのモノクロ版カレンダー拡張wanama版は全く理解できませんでした。
LXCLND.def　　Emmettさんのカレンダーは祝日データに工夫がしてありました。

72:	;---- holiday definition -----------------------------------------
	; (6) 日付の位置に半角大文字アルファベットを書くと「？回目の？曜日」
	;     を指定したことになる（回数の数値は A==1, B==2, ...を意味し、曜日
	;     は A==日曜日, B==月曜日 ... を意味すると解する）。

	hh..1  =  "1874>0=1;1874>1948=3;1949>1999=15;2000>0=BB",


これは1月の祝日データですが、注目すべきは後半の成人の日。

	1949>1999=15;	1949年から1999年までは、15日固定
	2000>0=BB",	2000年以降は、B（2回目の）B（月曜日）

この形式は使える！
HOLIDAY.DAT に早速入れてみました。

01/15 1948-1999 成人の日
01/BB 2000-2099 成人の日

これで同じように解釈させれば出来るはず！
と思ったのですが、マクロが全然読めなくて、解釈する部分もわかりません。(;_;)
どうしよう・・・・

> としきさんはオセロ強いですか？　私はヘタの横好きで。(^^;

中学生のころまでは、クラスで３番くらいの強さでした。
でも、大人になったら、平均よりちょっと強いくらい、でしょうか。

> > ちなみに、私の作ろうとしていたのは、俗に優先順位法というアルゴリズムです。
> 何となくそれに近い考え方で作ったような気がします。
> でも出来たのは、世界最弱のコンピュータオセロでした。(>_<)

これ、世間には優先順位のサンプルがいくらでもあったはずなので、そういうのを
そのまま実装すればそこまで弱くはならないはず。
例えば、乱数で手を打つプログラムを作ったら、強い時と弱い時がある、気分屋と
いうか不安定な強さになるだろうし。
本当に安定して弱いプログラムなら、むしろそのアルゴリズムを教えてほしい。
いや、マジで。

> 将棋でもオセロでも、強い人がアルゴリズムを考えることで本当に強いものが出来る

８ビット当時の最強は森田オセロだったはず。
私が対戦したのは、もしかしたらそれかもしれない。
もう覚えていませんが。

> > あぁ、なんだってこんな、いにしえのBASICの文法解説をしているんだろう（笑）。
> BASIC地獄、いやさ、天国への道はまだまだこれからですよ。(^^;

うふふふふ〜。
では、もうちょっと文法解説。
PC-8001のN-BASICでは、変数名には２文字までしか使えませんでした。
３文字以上の変数名を使おうとした時にエラーになるのか、それとも最初の２文字
しか認識されず、３文字目が異なる変数名も同一の変数として認識されるのかは
覚えていません。
これが、同じ８ビットマシンでも、PC-8801のN88-BASICでは４０文字まで使えました。
ただ、変数名を長くするとそれだけメモリを消費するというデメリットがあったため、
長い変数名は自粛される傾向がありました。
一方、PC-8001よりも古いシャープのMZ-80のBASICでの変数名の最大長はわかりません
が、当時のパソコンサンデーのテキスト（まだ持っている）を見ると、５文字程度の
変数名を使ったプログラムリストが掲載されているので、その程度の長さまでは対応
していたようです。
東芝の場合、PASOPIA7はPC-8801以降の発表だったはずなので、PASOPIA初代向けは
ともかく、16ビット対応などの後期のT-BASICなら長い変数名にも対応していると
思います。
つまり、何が言いたいかというと、もしプログラムをリライトする機会があれば、
意味の分かる長い変数名を使いましょうよ、ということ。
どっかのエディタのマクロじゃないんだから。

新祝日法対応のためには指定した曜日を計算して特定する必要があります。
私の頭では全く思いつきません。(;_;)
困ったときのめざら資源、探したらありました！　＼(^^)／ ｱｯﾀ-
めざら資源＞VZマクロ工房＞文字列出力関連＞七曜でふ−簡易版日付印字器

sitiyo.def
3:	;指定日の曜日を算出（ツェラーの式）
	(m<3)?{ y--, m+=12, }
	w=((y+ y/4+ y/400+ (m*13+8)/5+ 1- y/100) +d -1) %7,

なるほど、指定日の曜日を算出する、ツェラーの式というのがあるのですね。
マクロをBASICに置き換えてみました。式はほぼそのままですね。

'a1=1〜4(週)	
'a2=1〜7(曜日)
ww=0
for d=1 to 31
if m<3 then y=y-1:m=m+12
w=((y+ y/4+ y/400+ (m*13+8)/5+ 1- y/100) +d -1) mod 7
if w=a2 then ww=ww+1
if ww=a1 then dd=d:goto 30612
next d
30612 return


実際に実装したルーチンも貼り付けます。

30611 '指定日の曜日を算出（ツェラーの式）
AA1=ASC(MID$(A$,4,1))-64					'1〜4(週)	
AA2=ASC(MID$(A$,5,1))-64					'1〜7(曜日)
WW9=0
M9=YASM(YMAX)							'該当祝日の月
Y9=YEAR								'該当祝日の年
for D9=1 to 31
  if M9<3 then Y9=Y9-1:M9=M9+12					'sitiyo.def
  W9=((Y9+ Y9/4+ Y9/400+ (M9*13+8)/5+ 1- Y9/100) +D9 -1) MOD 7	'ツェラーの式
  'W9=(Y9+ Y9/4+ Y9/400+ (M9*13+8)/5+ D9- Y9/100) MOD 7		'同等の式？
  if W9<>AA2 then 30613						'曜日が一致するまで日を進める
  WW9=WW9+1							'曜日が一致したら週を進める
  if WW9<AA1 then 30613						'週が一致するまで進める
  YASD(YMAX)=D9:goto 30614					'日が確定したらデータに入れる
30613 next D9
30614 'print co9;a$;" ";Y9;M9;AA1;AA2;W9;D9			'debug
return


コメントを書くとフローのミスにも気が付きやすいですね。(^^;
一応動くようになったのですが、何故か年を変えても今年の年で計算してしまいます。(>_<)
どうしよう・・・

続く・・・のか

森田オセロ！　懐かしいですね。
いや，懐かしいと感じるのは「森田」なのかな……森田将棋の。

ゲームの話題になると夏の虫のように吸い寄せられてしまいますね。

わたしがずっと移植したいと思っているのが XLIS のモノクロ版です。
XLIS とは Zumi氏作成の落ち物で，モノクロ版は色の代わりに形状（●▲■★◆◎）
（カラー版 →　http://ozuma.o.oo7.jp/old_game/game/xlis/ ）
作れるとは思うのですが，なかなかまとまった時間と気分が重なりません。

ほかに，ゲームではないですが，迷路を作成するマクロ。
BASICで示されたサンプルもあると思いますが，グラフィックスと罫線の違いもあり
なかなか手を着けられないでいます。

もしかして，老人ホームにブチ込まれた後の楽しみになるのでは？とも思うこのごろ。

> > としきさんはオセロ強いですか？　私はヘタの横好きで。(^^;
> 
> 中学生のころまでは、クラスで３番くらいの強さでした。
> でも、大人になったら、平均よりちょっと強いくらい、でしょうか。

それなら確実に私より強いでしょうね。(^^;

> これ、世間には優先順位のサンプルがいくらでもあったはずなので、そういうのを
> そのまま実装すればそこまで弱くはならないはず。

うーん、その当時はオセロゲームの参考書とか見ていなかったもので。(^^;

> ８ビット当時の最強は森田オセロだったはず。
> 私が対戦したのは、もしかしたらそれかもしれない。

有名だったですね、私などパーフェクト負けを食らうほどででしょう。
ところで、VZマクロでもオセロゲームがあったかと見てみました。

VZOTO.DEF v.1.20 ====> 91.9.9 糧 丞 
これは９８用とJ31用があり、J31で動かしてみましたが、途中で動かなくなってしまいました。
NP2の98エミュで98版も試しましたが罫線が表示しない？　結局出来ませんでした。
VZ1.57用だからでしょうか、何が悪いのかわかりません。

OTHELLO.def v2.0 ======== by 愛して癒して
これはVz Editor ver 1.6x用ですが、罫線などおかしくて動きませんでした。
過去ログを見ると、としきさんが質問されていて、YASATさんが答えてくれていました。

> 07941/08074 xxxxxxxx  YASAT            RE:OTHELLO ができない
> (14)   03/04/23 21:31  07938へのコメント

> 7行目
>         je[-,mi[=2,ep[+,wt[,jd[-,co[4,#]

> 93行目
>         (wx-1) {' '} (wy) {#m}

> 　このゲーム、先攻で中途完勝パターンがあります。

> 　なんでこの修正したんだったかなあって思っていたら、過去ログでした。
> 　nifty:FGALDC/MES/14/1284


おお、この修正で動きました。＼(^^)／ ﾔｯﾀ-
1ゲームやって、39対25でなんとか勝ちました。(^^;
私の作ったやつより確実に強いですね。(^^;

とりあえずこのアルゴリズムで組んでみたら良さそうですね。
その先は参考書を頼るしかないのかな。

> つまり、何が言いたいかというと、もしプログラムをリライトする機会があれば、
> 意味の分かる長い変数名を使いましょうよ、ということ。
> どっかのエディタのマクロじゃないんだから。

(^^;  (^^;  耳がいた、いや、汗が。(^^;
私って3文字以上の英語のスペルは中々覚えられないのですよ。(^^;
その点 VZのマクロは記号みたいですが、だいたい2文字なので安心感が。(^^;

> 私って3文字以上の英語のスペルは中々覚えられないのですよ。(^^;

英語はやめて、６文字程度のローマ字にしましょう。



いきなり余談ですが。
昔の経済学って、ケインズだろうがマルクスだろうが、人間は合理的に行動する、
という前提で論理展開されていました。
でも、決してそんなことはないというか、不合理なことは結構多い。
そこで提唱されたのが行動経済学という学問。
ようは、いろいろな判断だとかお金の使い方を心理学の面から分析するものです。

そして、実はプログラム工学だとかソフトウェア工学というものにも、かなり昔から
心理学的な分析は取り入れられていて。そもそも、それらの学問は、どうすれば品質
のよい、すなわち間違えにくいプログラムを書けるか、という学問なのですが、これ
は裏を返すと、人間はどういうときに間違えるか、という、まさに心理学的な分析
から始まっているわけです。
そして、研究の結果、たとえば、長くて意味のわかりやすい変数名を使いましょう、
なんて話になってきたわけです。
ただし、これはあくまでも、一般的なプログラム作成の話。
たとえば、複数人で作る場合、とか。
一人で作る場合でも、そんなに時間をかけず、一気呵成に作り上げる場合とか。
ワンライナーあたりが該当するかな。
つまり、よく言われる「明日の自分は赤の他人」に至らないような状況の場合。
仮に、既存のプログラムを改造するぐらいなら、常に一から新しいプログラムを作る
というのであれば、過去のプログラムを見返すこともないでしょう。
ただし、繰り返しになりますが、これはあくまでも、一般的なプログラム作成の話。
このため、現在では、仮に
「俺は変数名に３文字までしか使わない」
と主張するプログラマがいたとすると、その人は暗に
「俺は一般的ではない、短い変数名でも良いプログラムを書ける天才なんだ」
と豪語しているに他ならない、というのが世間の捉えかた。
もれなく生暖かい目がついてくることでしょう。
とはいえ、中学２年生ぐらい頭が柔軟な人ならそれも可能なのかもしれません。
私はもう無理だなぁ、そんな主張はできない。頭は固いし恥ずかしいし。
この年になってから黒歴史は量産したくないし。

XLISって知らなかったのですが、コラムスのようなゲームですね。
落ち物でいうと、PC-98のDOSでは「ぽろりす」をずいぶんやりました。
http://ozuma.o.oo7.jp/old_game/game/porolith/
こいつには、作者謹製のANSI版があって、モノクロ環境でも実行できたはず。
そういえば、ポケ３では試したことはない。
けど、画面サイズを考えると、絶対に目が死にそう。
試すもんか。

アナログ時計とカレンダのアクセサリ 11月24日版です。
画像はココログの記事で見てください。
http://tamaneko2.cocolog-nifty.com/vz2/2023/11/post-bf98e3.html

今回の更新内容は

・新祝日法に対応したつもり。
・見栄えも多少直しました。
・カレンダー大の日付の文字を2バイト数字にして見やすく。
・キーによるカレンダーの年月変更機能追加。
・MSDOS Player でもカレンダー表示出来ます（chej jpの時）
・今回からソースも付けます。


新祝日法への対応はEMMETさんとめざらさんのマクロを参考にしました。
先人の知恵に感謝です。m(__)m

カレンダー大の日付の2バイト数字は、TBASICのころは出来ていたのです。
PRINT CDBL$(RIGHT$(STR$(I),2)) 
のように半角文字を2バイト文字に変換するコマンドが使えたのです。
ターボBASICは英語版なのでそんなものは無く、移植時に半角数字にしたのでした。
今回一念発起して対応しましたので、興味ある方はソースを見てください。

キーによるカレンダーの年月変更機能追加は、カレンダマクロで出来ているので
このくらいは出来ないと張り合えないなぁ、と思ったのです。（張り合ってどうする）(^^;

F11: 前月 	前月のカレンダーを表示
F12: 次月 	次月のカレンダーを表示
[Ctrl]+[←]	前年のカレンダーを表示
[Ctrl]+[→]	次年のカレンダーを表示

本当は [Ctrl]+[F11〜F12] で前年と次年のカレンダーを表示したかったのですが、
DOSVAXJ3 ではこのキーが（BIOSレベルで）反応しないのでしかたなくこうしました。

なお、変更前のソースを大量にコメントしているので非常に見づらいです。
TAGLIGHT.EXE をお使いの方は TAGLIGHT.PAT に

#BASIC用
:BA,
A	'	\C\$

これを追加すれば非常に見やすくなります。
TAGLIGHT.PAT についてはバッファ制限があるので近々記事を書くつもりです。


自作、改作アプリの放置部屋 　に置いてあります。

> 英語はやめて、６文字程度のローマ字にしましょう。

ローマ字ならいくらでも長い名前を書けますよ。(^^;
jugemujugemugogounosurikire

お。意外と良いかもしれませんね、でもなんだか恥ずかしいような。(^^;

> そして、研究の結果、たとえば、長くて意味のわかりやすい変数名を使いましょう、
> なんて話になってきたわけです。

その長い名前が覚えられないからこうなってしまったのです。(;_;)
英語は嫌いじゃぁ〜！

> この年になってから黒歴史は量産したくないし。

そんな風に思っていた時期もありました・・・
私の半生は黒(画面)歴史なので。
どうせみんな死ぬんだし、だったら恥ずかしい黒(画面)歴史を晒しちゃえ
ということで今回の企画を出したわけです。（完全後付け）

> わたしがずっと移植したいと思っているのが XLIS のモノクロ版です。
> XLIS とは Zumi氏作成の落ち物で，モノクロ版は色の代わりに形状（●▲■★◆◎）

XLIS は知りませんでしたが、モノクロ版の記号はどこかで見たような気が・・・
ん？　これって、Emmettさんのさめがめに似ているような。(^^;
さめがめは何度か遊んでみましたが面白いですね。(^_^)

> （カラー版 →　http://ozuma.o.oo7.jp/old_game/game/xlis/ ）

覗いてみたら、98版のゲームなんですね。NP2 で動くかしら。

> もしかして，老人ホームにブチ込まれた後の楽しみになるのでは？とも思うこのごろ。

う、うーん、(^^;

＃　俺たちに明日は無い、だから今日のテーマに生きるのだ！　なんちて

実家に置きっぱなしだったVistaマシンと、自宅で時々使っているXPマシンが相次いで
壊れまして。それぞれ、それなりに使うということで修復している最中。とはいえ、
Vistaマシンのほうはまだほとんど手付かずですが。

さて、何とか動き出してきたXPマシンのほうで、気になったのでこの時計を動かして
みました。このマシン、一応VTDOSの古いバージョンも入っていたような気もします
が覚えていません。DOSVAXは入れていなかったはず。
とりあえず、command.comで動かしたら、DOS窓状態で起動したにもかかわらず自動
で全画面に遷移して、きちんとアナログ時計が動きました。
ALT+RETで窓状態にすると、グラフィック関係は全滅ですね。時計の針もそうだし、
カレンダーの罫線だとか時計の枠だとか。
「VGAで動く」とうたっているソフトが動かないので、窓状態はやっぱりちょっと
本当のVGAとは違うみたい。

気になったことがいくつか。
まず、公開時の圧縮ファイルの形式。
最近のアンチウィルスソフトはLZH形式を正しくチェックできないということで、
最近では一般向けに公開されるファイルにはあまり使われなくなっています。
ベクターがLZHでの新規の受付を停止したのは何年前だったかなぁ。
さすがに公開済みのものを再パッキングするほどのことはないと思いますが、
次回からはZIP形式の使用がお勧め。
もちろん、赤の他人にはなるべく使ってほしくない、という希望があるならLZHの
ほうがいいかもしれません。

次、ソースリストについて。
ざっくり読んで、こんなものを処理できる処理系があるんだ、と驚きました。
これ、何でコンパイルしたんでしょうか。QBASIC？
いや、昔ながらの行番号つきの大文字の部分と、行番号なしの小文字の部分が混在
しているものを処理できるなんて、本当、びっくりしました。
慣れれば、あとからパッチを当てた部分がわかりやすいのかもしれません。
でも、慣れていないもので、ちょっと違和感が大きい。
行番号なしの部分でもマルチステートメントがある。できるんだ。
冒頭の「$INCLUDE」というおまじないは知らない。
これは処理系固有のおまじないなんだろうなぁ。
一応、環境変数の取得関数はあるようなので、この辺を工夫すればデータファイルの
置き場所も指定できそうですね。
あと、ON ERROR GOTOが頻出しますが、飛び先をきちんと変えている。
すなわち、有効利用している。こんなコードはじめてみた。すごい！
私、エラー処理なんてひとつしかないようなコードしか書いたことがないもので。

最後。
前にも書いたことですが。
このツリーも、返信フォームの上の部分だけ、ツリー表示が乱れている。
何とかしてほしいというか、何とかできないのならコードをさらしてほしい。

> このツリーも、返信フォームの上の部分だけ、ツリー表示が乱れている。
> 何とかしてほしいというか、何とかできないのならコードをさらしてほしい。

と、書いたところですが。
#10961を書き込んで、今、読み直してみると、ツリーの乱れ方が変化している。
#10961を書き込む前。（タイトル部はとしきによって省略しています）

- 関連一覧ツリー （先頭の番号をクリックするとツリー全体を一括表示します）
▼ 10933.VGAで動くアナログ時計とカレンダのアクセサリ
　 ┣10934.Re: VGAで動くアナログ時計とカレンダのアク
　 ┗10935.Re^2: VGAで動くアナログ時計とカレンダのア
　 ┃　┗10936.Re^3: VGAで動くアナログ時計とカレンダ
　 ┃　　┣10938.Re^4: VGAで動くアナログ時計とカレン
　 ┃　　┗10939.Re^5: VGAで動くアナログ時計とカレン
　 ┃　　┃　┗10940.Re^6: VGAで動くアナログ時計とカ
　 ┃　　┃　　┣10941.Re^7: VGAで動くアナログ時計と
　 ┃　　┃　　┣10942.Re^7: VGAで動くアナログ時計と
　 ┃　　┃　　┃┣10944.BASIC道への入り口 - konno 2
　 ┃　　┃　　┃┣10948.Re: BASIC道への入り口 - とし
　 ┃　　┃　　┃　┗10952.Re^2: BASIC道への入り口 -
　 ┃　　┃　　　　┗10953.Re^3: BASIC道への入り口 -
　 ┃　　┃　　　　　┗10956.Re^4: BASIC道への入り口
　 ┃　　┗10943.オセロ - としき 23/11/22-01:14
　 ┃　　　┗10945.Re: オセロ - konno 23/11/23-00:13
　 ┃　　　　┗10947.Re^2: オセロ - としき 23/11/23-
　 ┃　　　　　┣10950.Re^3: オセロ - めざら 23/11/2
　 ┃　　　　　┣10954.Re^4: オセロ - としき 23/11/2
　 ┃　　　　　┃┗10957.Re^4: オセロ - konno 23/11/
　 ┃　　　　　┣10951.Re^3: オセロ - konno 23/11/23
　 ┣10937.VGAで動くアナログ時計とカレンダのアクセサ
　 ┗10946.新祝日対応のデータ形式 - konno 23/11/23-0
　 　┗10949.曜日を算出する ツェラーの式 - konno 23/
　 ┣10955.アナログ時計とカレンダのアクセサリ 11月24

ところが、#10961を書き込んだあと。

- 関連一覧ツリー （先頭の番号をクリックするとツリー全体を一括表示します）
▼ 10933.VGAで動くアナログ時計とカレンダのアクセサリ
　 ┣10934.Re: VGAで動くアナログ時計とカレンダのアク
　 ┃┗10935.Re^2: VGAで動くアナログ時計とカレンダの
　 ┃　┗10936.Re^3: VGAで動くアナログ時計とカレンダ
　 ┃　　┣10938.Re^4: VGAで動くアナログ時計とカレン
　 ┃　　┃┗10939.Re^5: VGAで動くアナログ時計とカレ
　 ┃　　┃　┗10940.Re^6: VGAで動くアナログ時計とカ
　 ┃　　┃　　┣10941.Re^7: VGAで動くアナログ時計と
　 ┃　　┃　　┣10942.Re^7: VGAで動くアナログ時計と
　 ┃　　┃　　┣10944.BASIC道への入り口 - konno 23/
　 ┃　　┃　　┗10948.Re: BASIC道への入り口 - としき
　 ┃　　┃　　　┗10952.Re^2: BASIC道への入り口 - k
　 ┃　　┃　　　　┗10953.Re^3: BASIC道への入り口 -
　 ┃　　┃　　　　　┗10956.Re^4: BASIC道への入り口
　 ┃　　┗10943.オセロ - としき 23/11/22-01:14
　 ┃　　　┗10945.Re: オセロ - konno 23/11/23-00:13
　 ┃　　　　┗10947.Re^2: オセロ - としき 23/11/23-
　 ┃　　　　　┣10950.Re^3: オセロ - めざら 23/11/2
　 ┃　　　　　┃┣10954.Re^4: オセロ - としき 23/11
　 ┃　　　　　┃┗10957.Re^4: オセロ - konno 23/11/
　 ┃　　　　　┗10951.Re^3: オセロ - konno 23/11/23
　 ┣10937.VGAで動くアナログ時計とカレンダのアクセサ
　 ┣10946.新祝日対応のデータ形式 - konno 23/11/23-0
　 　┗10949.曜日を算出する ツェラーの式 - konno 23/
　 ┗10955.アナログ時計とカレンダのアクセサリ 11月24
　 　┗10961.Re: アナログ時計とカレンダのアクセサリ 

#10961を書き込むことによって、#10941あたりからの乱れ方が大幅に改善している。
ツリー最後の#10955前後はまだ乱れているけど、乱れ方が変化している。
この辺、コードを追いかける際の手がかりになるかも。

> とりあえず、command.comで動かしたら、DOS窓状態で起動したにもかかわらず自動
> で全画面に遷移して、きちんとアナログ時計が動きました。

XPのDOS窓全画面で動きましたか。
元々Win95ノートPCの小さい画面で使うため、全画面にして使っていたのです。

> ALT+RETで窓状態にすると、グラフィック関係は全滅ですね。時計の針もそうだし、
> カレンダーの罫線だとか時計の枠だとか。
> 「VGAで動く」とうたっているソフトが動かないので、窓状態はやっぱりちょっと
> 本当のVGAとは違うみたい。

ターボBASICは古いので、VGA対応してるかどうか。VGAでも何とか動くという感じです。
グラフィックモードは、chej 12  相当です。
DOS窓で chej 12 と打つと、全画面になると思います。

Win98MEのリブレットで確認してみました。
DOS窓で起動すると一瞬全画面になりますが、すぐにDOS窓に戻ります。
小さなデジタル時計が表示されているだけの状態ですね。
ここで、ALT+RET すると全画面になりグラフィックモードで動作しますね。

最新の版はデジタル時計を全角表示して、全画面では毎秒カウントします。
ところがDOS窓では、２秒ごとに表示しますね。
DOS窓では疑似マルチタスクが優先するため描画処理が追い付かないのかも。

> 最近のアンチウィルスソフトはLZH形式を正しくチェックできないということで、
> 最近では一般向けに公開されるファイルにはあまり使われなくなっています。
> 次回からはZIP形式の使用がお勧め。

なるほど、検討してみます。

> もちろん、赤の他人にはなるべく使ってほしくない、という希望があるならLZHの
> ほうがいいかもしれません。

今時DOSを使うもの好きは、LZHに馴染んでいると思ったのですが、やっぱりZIPがいいのかなぁ。(^^;

> ざっくり読んで、こんなものを処理できる処理系があるんだ、と驚きました。
> これ、何でコンパイルしたんでしょうか。QBASIC？

ボーランドのターボBASIC です。すぐに消えたので、幻のコンパイラかも。(^^;

> いや、昔ながらの行番号つきの大文字の部分と、行番号なしの小文字の部分が混在
> しているものを処理できるなんて、本当、びっくりしました。

やってみたらできたので、そういうものかと思っていました。
大文字と小文字を区別する処理系もあるようですね。移植するときには直さなくては。(^^;

> 冒頭の「$INCLUDE」というおまじないは知らない。
> これは処理系固有のおまじないなんだろうなぁ。

これは、ターボBASICのコンパイラ版固有みたいです。

50 $DYNAMIC

これが、東芝BASICのコンパイラ版固有みたいですが、元がMS系なので、MSも同じかも。

> 一応、環境変数の取得関数はあるようなので、この辺を工夫すればデータファイルの
> 置き場所も指定できそうですね。

環境変数を設定すればできそうですが、ちょっと面倒ですよね。
実行ファイルと同じフォルダから自動的に設定ファイルを読めればいいなと思うんですが。
とりあえずは環境変数を設定するようにしてみますか。

> あと、ON ERROR GOTOが頻出しますが、飛び先をきちんと変えている。
> すなわち、有効利用している。こんなコードはじめてみた。すごい！
> 私、エラー処理なんてひとつしかないようなコードしか書いたことがないもので。

これ、３か所に分かれているのは、３つのプログラムを合体させたからです。(^^;
統合化していない超手抜きの悪い例ですね。(^^;

> このツリーも、返信フォームの上の部分だけ、ツリー表示が乱れている。
> 何とかしてほしいというか、何とかできないのならコードをさらしてほしい。

検討します。m(__)m

> #10961を書き込むことによって、#10941あたりからの乱れ方が大幅に改善している。
> ツリー最後の#10955前後はまだ乱れているけど、乱れ方が変化している。
> この辺、コードを追いかける際の手がかりになるかも。

なるほど、見てみますね。
でも今まで何度も見ているのにわからなかったので、やっぱりとしきさんにも見てもらおうかなぁ。

#  記事閲覧t  #

のルーチンだけ切り出してメールで送ります。

宜しくお願いします。

メールは受け取りました。
が、受け取っただけで、まだ中身はぜんぜん見ていません。

> 今時DOSを使うもの好きは、LZHに馴染んでいると思ったのですが、

その点はまったく同感なのですが

> やっぱりZIPがいいのかなぁ。(^^;

自動でウィルスチェックをしてくれない、という部分をどう捉えるか。
konnoさんを信用できる・信用している人ならLZHでもダウンしてくれると思います。
が、konnoさんをよく知らない赤の他人ならどうするか、という点が疑問。

> ボーランドのターボBASIC です。すぐに消えたので、幻のコンパイラかも。(^^;

ありましたね。
この処理系は、私も触ったことがありません。

> 50 $DYNAMIC
> これが、東芝BASICのコンパイラ版固有みたい

REMがついていたので素通りしていました。
これって、REMがなければ、どういうことをするコマンドなんですか？

> 実行ファイルと同じフォルダから自動的に設定ファイルを読めればいいなと思う

なんかありそうですけどね。
ＣとかPascalなんかでは、コマンドラインのゼロ番目が実行ファイルのフルパス名、
みたいなことになっていたような気がするので、コマンドラインの取り出し方法を
調べてみるのがいいかも。

> メールは受け取りました。
> が、受け取っただけで、まだ中身はぜんぜん見ていません。

私も見れていないのでお手すきの時にでもお願いします。m(__)m

> 自動でウィルスチェックをしてくれない、という部分をどう捉えるか。
> konnoさんを信用できる・信用している人ならLZHでもダウンしてくれると思います。
> が、konnoさんをよく知らない赤の他人ならどうするか、という点が疑問。

そうですね、次からはなるべく ZIP にするようにします。

> > 50 $DYNAMIC
> REMがついていたので素通りしていました。
> これって、REMがなければ、どういうことをするコマンドなんですか？

マニュアルが腐海の底に沈んでしまっているので、NETで検索してみました。
FreeBASIC MetaDynamic
https://makoto-watanabe.main.jp/freebasic/PgMetaDynamic.html#start
このページの解説が近いような気がします。

> 配列を割り当てる方法を変える、メタコマンド
> 
> 構文:
> '$Dynamic
> または
> rem $Dynamic
> 
> 記述:
> '$Dynamic は、以降に宣言する全ての配列が可変長である、と指定する、メタコマンドです。配列が、添字数が定数指定で宣言されていても、そうでなくてもです。
> この指定は、モジュールで、'$Dynamic を使ったそれ以降の部分に対して有効です。$Static を使って、'$Dynamic 指定を無効にすることができます。

うーむ、REM は必要だったみたいですね。(^^;
多分、エディタで編集領域を拡大するために使ったのだと思いますが、今では覚えていません。(>_<)
なんせ、インタプリタ時代は、3万文字程度が限界で、ガベージコレクションで止まっていたので。(>_<)
コンパイラになっても4万文字程度だったかもですが。(^^;

> ＣとかPascalなんかでは、コマンドラインのゼロ番目が実行ファイルのフルパス名、
> みたいなことになっていたような気がするので、コマンドラインの取り出し方法を
> 調べてみるのがいいかも。

なるほど、PEEK関数でメモリは読めるかもしれないので、チャレンジしてみます。

> FreeBASIC MetaDynamic
> https://makoto-watanabe.main.jp/freebasic/PgMetaDynamic.html#start
> このページの解説が近いような気がします。

なるほど、理解できました。
N-BASICとかN88-BASICでは、DIMで配列宣言をしないで配列を使うと、デフォルトで
配列の添え字は10まで使えたはず。OPTION BASEで添え字の0が使えるかどうかを決定
するという、あまり使われていない機能もありますが。
だけど、これを宣言しておけば、デフォルトで11以降の添え字が使えるということの
ようですね。
ただ、N88-BASICの場合、DIMで配列宣言をしない配列を使うと、例えば要素数が3個
しか必要ない配列でも10個分の要素のメモリが確保されてしまい、メモリが無駄に
なるから必ず配列宣言をしましょう、みたいな事が言われていました。当然、大きな
配列が必要なときは配列宣言は必須でしたし、結論としては、いついかなる場合も
配列宣言をしましょう、みたいな話になっていたように記憶しています。
そういう環境に慣れていたので、AWKやPerlのような、動的に配列がみょ〜んと確保
されるような処理系に始めて触れたときには違和感が強かったものです。もし私が
N88-BASICからいきなりこの$DYNAMIC構文のあるBASICに触れたら、そんな比ではない
ほどの違和感を感じまくったことでしょう。

ところで、この構文が使われているということからの推測すると、元々のコードは
QuickBASICで書かれていたということでしょうか。
そして、REMは必須であったと。

> なるほど、PEEK関数でメモリは読めるかもしれないので、チャレンジしてみます。

FreeBASICのサイトを検索したところ、この処理系だと、COMMAND(0)という関数で
実行ファイル名が取得できるようです。ただ、フルパスが取得できるかは、私には
よくわかりませんでした。
また、このページのQuickBASICとの違いの注記で、QBは引数をとらないとある。
ということは、TIME$で時刻の全体が取得できるように、COMMANDでコマンドライン
の引数全体が取得できるようになっているらしい。
ターボBASICがどうなっているかわかりませんが、QB同様であった場合、例えば空白
の入ったフォルダから起動したようなときに、実行ファイルのパスの取得は難しく
なるかもしれない。

書きかけの返信をうっかりセーブし忘れて消してしまいました。(>_<) うう、、


> N88-BASICからいきなりこの$DYNAMIC構文のあるBASICに触れたら、そんな比ではない
> ほどの違和感を感じまくったことでしょう。

私もN88-BASICからTBASICに移植したときは、違いに戸惑いましたね。
当時、「各種BASICの違い」みたいな記事があって、参考に成りました。どこ行ったかなぁ。

> ところで、この構文が使われているということからの推測すると、元々のコードは
> QuickBASICで書かれていたということでしょうか。

元々はTBASIC(7) です。それからTBASIC(16) → コンパイラ版 → TURBO BASIC ですね。
MS系のBASICだから構文がほぼ同じなのでしょう。

> そして、REMは必須であったと。

ですね。メタコマンドみたいなものでしょうか。

> FreeBASICのサイトを検索したところ、この処理系だと、COMMAND(0)という関数で
> 実行ファイル名が取得できるようです。ただ、フルパスが取得できるかは、私には
> よくわかりませんでした。

COMMAND という関数はTURBO BASIC には無いようです。
類似の関数もわからないのでちょっとできなそうですね。

> 当時、「各種BASICの違い」みたいな記事があって、参考に成りました。

うちの、1985年ごろのベーマガに、その手の記事がありました。
ただ、多くの機種を対象としていた関係で、１機種あたりの分量はたいしたことは
ありませんね。だから

> 元々はTBASIC(7) です。

TBASIC(7)に、この構文があるということも載っていないし。

> COMMAND という関数はTURBO BASIC には無いようです。
> 類似の関数もわからないのでちょっとできなそうですね。

Turbo Pascalだと、予約語としてParamStr。
Ｃ言語だと、デフォルトでargvとargc。ただしこれは予約語ではなく、ただの慣例。
とはいえ、正当な理由なくこの慣例を破ると、各方面からけちょんけちょん。
最近のVisual BasicというかVB.NETではCmdArgsだけど、これが予約語か慣例かは
わからない。

このあたりのキーワードでドキュメントを検索するくらいかなぁ。
コンパイル可能な処理系でコマンドライン引数を取得できないって、ありえないと
思うのですが、これはちょっと私が固定観念にとらわれすぎているかも。

> うちの、1985年ごろのベーマガに、その手の記事がありました。
> ただ、多くの機種を対象としていた関係で、１機種あたりの分量はたいしたことは
> ありませんね。

もしかしたら私もその本を読んだのかもしれませんね。

> だから
> > 元々はTBASIC(7) です。
> TBASIC(7)に、この構文があるということも載っていないし。

TBASIC(7)に、この構文はありません。時計アクセサリプログラムのルーツという意味で書いていました。
$DYNAMIC は、TBASICのコンパイラ版の構文だったと思います。Turbo BASIC ではどうだか確認できていません。

> コンパイル可能な処理系でコマンドライン引数を取得できないって、ありえないと
> 思うのですが、これはちょっと私が固定観念にとらわれすぎているかも。

コマンドライン引数を取得する関数はあります。
111 FILE$=COMMAND$

ただ、command(0) のようにコマンドラインのゼロ番目は取得できないようなので。
マニュアルが見つかるまでは色々試してみます。

STIME.EXE 12月08日版をアップしました。

DOSVAXJ3 の VGAで動くアナログ時計とカレンダのアクセサリです。
NCPATH= でデータファイルの置き場所を指定してください。末尾に "\" が無ければ追加します。

DOSVAXJ3 を起動したら、chev jp でVGAモードにして、STIME.EXE を起動してください。
MS-DOS Player では、chej jp でVGAモードにします。文字のデジタル時計とカレンダのみ表示します。
VTDOS では動作しません。

画像は
http://tamaneko2.cocolog-nifty.com/vz2/


更新履歴

231208	環境変数 NCPATH でデータファイルの置き場所を指定。指定無しならカレント
	春分、秋分の日を自動計算
	デジタル時計とカレンダ大の文字を2バイト文字に。
	[↑↓]キーで前年・次年  [←→]キーで前月・次月のカレンダーを表示

これでカレンダマクロに対抗できるでしょう(笑）

[←→]キーで前月・次月のカレンダーを連続で何年分もやるとエラーになります。
もしかしたらループのつじつまが合っていないのかも。
バグ入りなので、ご使用は自己責任でお願いします。

自作、改作アプリの放置部屋に置いてあります。


春分、秋分の日を自動計算する計算式は ネットから拾いました。

> Excelでこれらの日付を求めるには、以下のようにDATE関数とINT関数を数式に組み合わせます。
　春分の日

=INT(20.8431+0.242194*(年-1980))-INT((年-1980)/4) 

　秋分の日

=INT(23.2488+0.242194*(年-1980))-INT((年-1980)/4)


この式がそのまま使えました。ありがたいです。


追記

記事のタイトルと内容の日付を間違えていたのを訂正しました。
m(__)m

■ VTDOS+CKWV 環境で Google IME を起動すると落ちる

気が付いたのは昨日。

・[変換]キーに割り当てた IME 起動キーを押したら即座に VZ が終了した。
・一旦，Windows(10) を再起動してみたが，状況は変わらない。
・[変換]だけでなく，ALT+[半/全|漢字] または [半/全|漢字] でも同様。
・以下のマクロで IME を起動しても，やはり即座に終了。
1 @B "feponoff" &j(0) &m("OFF") (mg.-9)??{ &j(10) &m("ON") }
・VZ を終了させたのちの DOSプロンプトでも同様に落ちる。

Google IME を Microsoft IME に変更すると，いずれも落ちなくなった。

DOSVAXJ3 (JP23707) では不具合は再現しなかった。

∴ VTDOS+CKWV 環境で Google IME を使用した場合の現象と考えられる。

皆さんの環境では，同様の現象は見られませんか？

> ■ VTDOS+CKWV 環境で Google IME を起動すると落ちる

私は Google IME を使っていないので、インストールしてみました。
設定はすべてデフォルトですが、変換はATOKモードにしました。(^^;

VTDOS155+CKWV11 では、メニュー枠がチラチラと瞬いて見えないほかは普通に使えるようです。
VTDOS155+CKWV12 では、メニュー枠がチラチラしますが見えてはいて、普通に使えるようです。
この辺もCKWVの更新理由なのかも。というか、Google IME を使うには CKWV12 が必須ですね。(^^;
どちらもVZ窓が出ている状態で Google IME をインストールしました
VZは、k07v6k 常駐です。

> ・[変換]キーに割り当てた IME 起動キーを押したら即座に VZ が終了した。

キー割当はなにか別のソフトを使ったのでしょうか。
もしかしたらこのへんが関係している可能性も考えられるので。
って、あれ？　普通に[変換]キーで漢字ON／OFFできるんですね。(^^;

> ・以下のマクロで IME を起動しても，やはり即座に終了。
> 1 @B "feponoff" &j(0) &m("OFF") (mg.-9)??{ &j(10) &m("ON") }

当方では問題なく起動します。

> ・VZ を終了させたのちの DOSプロンプトでも同様に落ちる。

これも問題ないですね。
この文章はVZで書いています。

> DOSVAXJ3 (JP23707) では不具合は再現しなかった。

念のため DOSVAXJ3 でも試してみましたが、問題ないようです。
ここからは DOSVAXJ3 のVZで書いています。

> ∴ VTDOS+CKWV 環境で Google IME を使用した場合の現象と考えられる。

めざらさんの環境では問題が出ているんですね、何が原因かわからないですね。

わざわざインストールしての確認ありがとうございます。
どうやら，うちの環境だけのようですね。

突然の発現なのでよくわからないのですが，ともかく少し様子を見てみます。

> STIME.EXE 12月28日版をアップしました。

会社の環境だったので、あまり時間がとれず、状況が詰め切れていないので、あまり
参考にはならないかもしれませんが、とりあえずのご報告。
DOSVAXは、今年の７月のバージョンです。
会社なので、Vzも大昔に持ち込んだ高橋版をそのまま使っています。
だからなのか、それとも単に設定をつめていないからなのか、Vzは常駐使用できて
いません。非常駐なら、それなりにきちんと動いてくれているというか、少なくとも
不具合は認識していません。

この環境で非常駐VzのコマンドラインからSTIMEを起動すると、最初は普通に時計を
表示して、特に問題なく動いています。
この状態からファンクションの１〜３を押してカレンダーを表示させると、一応
カレンダーは表示します。が、その下側に「[Enter]キーを押してください。」と
表示され、その表示に従ってEnterを押すと、そこでプログラムが終了してしまい
ました。
ま、こんなこともありました、ということで。

ところで、年の瀬になったら、１２月８日版がリリースされるのでしょうか。

> ところで、年の瀬になったら、１２月８日版がリリースされるのでしょうか。

ああ！　日付を間違えていて気が付きませんでした。
気づかせてくださってありがとうございます。m(__)m

ココログの記事のタイトルと内容の日付を間違えていたのを訂正しました。
掲示板のタイトルも訂正しときます。(^^;

> この状態からファンクションの１〜３を押してカレンダーを表示させると、一応
> カレンダーは表示します。が、その下側に「[Enter]キーを押してください。」と
> 表示され、その表示に従ってEnterを押すと、そこでプログラムが終了してしまい
> ました。

これは環境変数 NCPATHを通していない場合のエラー処理が出来ていないようですね。
修正します。m(__)m

> どうやら，うちの環境だけのようですね。

VTDOS+CKWV 環境では何とか使えるようですが、素のVTDOS では問題ありでした。
VZ編集画面の最下行のファンクション表示
    ﾌｧｲﾙ  窓換  文換  窓割   記憶  検索  置換  ｶｯﾄ    ｲﾝｻｰﾄ helpﾞ ﾍﾟｰｼﾞ  ﾀｸﾞ

これが、Google IME を入れたら、サジェストなんたらとか

Google 日本語入力インジケータウインドウ  置換  ｶｯﾄ    ｲﾝｻｰﾄ helpﾞ ﾍﾟｰｼﾞ  ﾀｸﾞ

このような表示が張り付いて消えません。(>_<)
サジェストなんたらは、設定で無効にしたら予測変換が出来なくなるようだし。
MS-DOS Player でも同じ状態だったので、これは無理です。(>_<)

切り替えて使おうかと思いましたが、ウザいのでアンインストールしちゃおうかしら。
Windows IME（のATOKモード）に慣れたのもあり、こちらの方が使いやすいと感じました。（^^;

前回のコメントの質問に応えていなかったことがあるので，まとコメで。

わたしが Google IME を愛用している理由は，
・賢い……と言うか，わたしが必要としている固有名詞(人名)に強い
・カスタマイズが簡単で，キーの割当てがかなり自由
・上記のキー設定をテキストファイルで出力でき，他のPCにインポート可能
・変換候補選択キーに数字とローマ字を選べ，後者ならホームポジション維持可能
……といったところです。起動キー[変換]も他のツールを使わずに指定しています。

konno さんのおっしゃる最下行への表示の張り付きとかサジェスト云々が邪魔
という状況に陥ったことは一度もありません。ごく自然に使えていました。

数ヶ月前から変換候補の表示順が少し変わってしまって少しストレスはあるものの，
期待する候補が出なかったり固有名詞に弱くて著名人名も候補に出てこないような
他の IME をメインにしようとは思わないです。【あくまでも個人の感想です】

当面は，dosvaxj3 環境メインで VZ を使おうと思います。


入力するデータの種類によって IME を使い分けるのが賢い使い方だと思いますし，
慣れた入力方式やキーバインドが可能ならそこに安住するのは自然ですから，
決して konno さんの感覚／感触を否定するわけではありません。

> わたしが Google IME を愛用している理由は，
> ・賢い……と言うか，わたしが必要としている固有名詞(人名)に強い
> ・カスタマイズが簡単で，キーの割当てがかなり自由
> ・上記のキー設定をテキストファイルで出力でき，他のPCにインポート可能
> ・変換候補選択キーに数字とローマ字を選べ，後者ならホームポジション維持可能
> ……といったところです。起動キー[変換]も他のツールを使わずに指定しています。

こうしてみると、良いことづくめのようですね。私ももう少し試してみようかしら。

> konno さんのおっしゃる最下行への表示の張り付きとかサジェスト云々が邪魔
> という状況に陥ったことは一度もありません。ごく自然に使えていました。

VZでIMEを制御出来ていない環境がこの問題の共通点のようですね。
冷静に考えると、運用上はほとんど問題にならないようです。(^^;

> 数ヶ月前から変換候補の表示順が少し変わってしまって少しストレスはあるものの，
> 期待する候補が出なかったり固有名詞に弱くて著名人名も候補に出てこないような
> 他の IME をメインにしようとは思わないです。【あくまでも個人の感想です】

それぞれに長所や短所があるから、結局は個人の好みで選べばいいんでしょうね。

> 当面は，dosvaxj3 環境メインで VZ を使おうと思います。

dosvaxj3 は私がよく使う一部のキーバインドに問題が有るので、今はサブ窓になっています。(^^;

> 入力するデータの種類によって IME を使い分けるのが賢い使い方だと思いますし，
> 慣れた入力方式やキーバインドが可能ならそこに安住するのは自然ですから，
> 決して konno さんの感覚／感触を否定するわけではありません。

Google IME をインストールする時に、既定のIMEにしたら、切り替えてもすぐに戻ってしまうような。(>_<)
既定の設定を変えられないし。(;_;)
一旦アンインストールして既定のチェックを外そうとしたらPCの再起動になるし。(>_<)
で、既定のチェックを外したら、Google IME に切替が出来なくなりました。(>_<)

＃　どうなっとるんじゃ〜！！　(-_-ﾒ)

　 STIME.EXE Ver 231212 に更新しました。

・DOSVAXJ3 の VGAで動くアナログ時計とカレンダのアクセサリです。
・NCPATH= でデータファイルの置き場所を指定してください。末尾に "\" が無ければ追加します。
・PATH が通っていないとカレントから読み出しますが、無い場合は祝日情報が表示されません。

・DOSVAXJ3 を起動したら、chev jp でVGAモードにして、STIME.EXE を起動してください。
・MS-DOS Player では、chej jp でVGAモードにします。文字のデジタル時計とカレンダのみ表示します。
・VTDOS では動作しません。

23-12-12
・NCPATH が通ってなくてデータファイル読めない場合エラー終了していたのを警告表示に修正。


自作、改作アプリの放置部屋に置いてあります。

いやいや，良いことずくめというわけないじゃないですか。
メリットだけは挙げましたが，ストレスを感じるところを挙げてませんからね。

・部首名入力ができない(MSは部首名[F05]で可能)
・(最近)句読点や中黒を入力したいのに余計な感嘆符が大量に候補に出てくる

こういう長短を考えて，必要なときはすぐ切り替えられるようにしています。
MS IME も昔に比べればとても賢くなっていますよね。


> dosvaxj3 は私がよく使う一部のキーバインドに問題が有る

この問題点はどこかに書いてありましたっけ？　共有したいです。
試用程度にしか使っていなかったもので実感がありません。


> ＃　どうなっとるんじゃ〜！！　(-_-ﾒ)

一旦，落ち着きましょうか。(笑)
Windowsの　設定＞言語＞キーボード　(入力方式の切り替え)
　入力言語のホットキー　(テキストサービスと入力言語)
　→ 入力言語を切り替える　左Alt＋shift
　　IME ごとにキーシーケンスを設定することもできます。(不要だけど)


上記「入力方式の切り替え」の最初の項目に，
「アプリウィンドウごとに異なる入力方式を設定する」
というのを見つけたので，当面これを適用しておきます。
VZ で固有名詞をたくさん入力するということはないので。
(一応，うまいこと制御できています)

> ・部首名入力ができない(MSは部首名[F05]で可能)

これはあまり使っていませんが、たまに使うかもしれないので、使える方がいいですね。

> ・(最近)句読点や中黒を入力したいのに余計な感嘆符が大量に候補に出てくる

これは困るかも。(^^;　私はよく中黒を使うので。(^^;

> こういう長短を考えて，必要なときはすぐ切り替えられるようにしています。
> MS IME も昔に比べればとても賢くなっていますよね。

切り替えると操作系の癖が変わるので、却って戸惑いそうですね。(^^;
普段は MS の IME で、必要な時だけ切り替えればいいのかな。

> > dosvaxj3 は私がよく使う一部のキーバインドに問題が有る
> この問題点はどこかに書いてありましたっけ？　共有したいです。
> 試用程度にしか使っていなかったもので実感がありません。

#10960：DOSVAXJ3 備忘録  のツリーで今纏め中です。
・chev 内部コマンドでモード切替が上手くいかない場合がある？
　その場合、chej.exe を使うのがよさそう。
・dosvaxj3 起動時に NumLk が OFF になってしまう。
・Fキーなどの一部のキーバインドが使えない。
　現在纏め中です。(^^;

> 一旦，落ち着きましょうか。(笑)

一応落ち着いたのでまた試してみようという気になっています。(^^;

> Windowsの　設定＞言語＞キーボード　(入力方式の切り替え)
> 　入力言語のホットキー　(テキストサービスと入力言語)
> 　→ 入力言語を切り替える　左Alt＋shift
> 　　IME ごとにキーシーケンスを設定することもできます。(不要だけど)

これは試していませんでした。やってみます。

> 上記「入力方式の切り替え」の最初の項目に，
> 「アプリウィンドウごとに異なる入力方式を設定する」
> というのを見つけたので，当面これを適用しておきます。
> VZ で固有名詞をたくさん入力するということはないので。
> (一応，うまいこと制御できています)

なるほど。当面これで運用してみますね。

2024年が明けました。
今年は元旦から能登で大地震があったりして、大変な年になりそうです。
亡くなられた方々のご冥福をお祈りいたします。

そんな世相を鑑みて簡単な御挨拶で済ませてしまいますが
今年もよろしくお願いします。


＃ うう、年末の無理が祟ったか、風邪をひいてしまいました。(ﾟ゜)☆＼(--#)ﾅﾆﾓｼﾃﾅｲﾀﾞﾛ
　　喉は痛いし食欲もなく、1日おじや1杯でしのいでいます。(;_;)

konnoさん

　あけましておめでとうございます。
　バタバタ、ヨロヨロしていて、新年のご挨拶が遅れました。
　まあ、けっこうゆっくりしてるのですけどね。
　年末年始は、一生懸命、１日１時間のダラダラ散歩ができましたし。
　白内障の手術、無事にいってくれることを祈っています。

　まだまだ部屋と頭と心の整理に忙しく（違うな、やりたくないのだろう！）
ＰＣ（Ｖｚ＆ベーシック＆ＤＯＳエミュ）方面はさっぱりですが、昨年の
konnoさんのご活躍には刺激を受けました。
　まだまだＤＯＳ＆Ｖｚでいきましょう！　僕はその気ですよ！

松の内ぎりぎりですが，明けましておめでとうございます。

いろいろな意味で大変な年になりそうな予感がしますが，
思うべきことは思い，言うべきことは言い，淡々と過ごしたいと思います。

今年もよろしくお願い申し上げます。

辰年ですが立ちません，下から支えようと思う今日このごろ。

文太さん、今年もよろしくお願いします。

> 　年末年始は、一生懸命、１日１時間のダラダラ散歩ができましたし。

長生きするには散歩が良いですよね、私も風邪の病み上がりで息切れしてます。(;_;)

> 　白内障の手術、無事にいってくれることを祈っています。

お気遣いありがとうございます。OFF会楽しんでくださいね。

> 　まだまだ部屋と頭と心の整理に忙しく（違うな、やりたくないのだろう！）
> ＰＣ（Ｖｚ＆ベーシック＆ＤＯＳエミュ）方面はさっぱりですが、昨年の
> konnoさんのご活躍には刺激を受けました。
> 　まだまだＤＯＳ＆Ｖｚでいきましょう！　僕はその気ですよ！

この年になって振り返ってみると、昔取った杵柄しか残ってないんですよね。
私の場合それがVZとBASICだったということです。
これからは自分の痕跡を残すためにやりたいことだけやっていきますよ。

そんな1年にみなさんでしていきましょう。

めざらさん、今年もよろしくお願いします。

> いろいろな意味で大変な年になりそうな予感がしますが，
> 思うべきことは思い，言うべきことは言い，淡々と過ごしたいと思います。

事件、事故も多いので、巻き込まれないように注意深く、慎重にして、1年無事に乗り切れるといいですね。

> 辰年ですが立ちません，下から支えようと思う今日このごろ。

なにやら意味深な書き込みですね。(^^;
私も急速な老化現象を感じて、アレなんですが、
今年の抱負というか、やりたいことの一つに、お願いがあります。
別発言で書きますね。

めざらさん、としきさん
突然ですがお二人にメール送ります。

もう16年前になりますが、うちの掲示板の検索を、全ログの改行またぎ検索に改造しました。

#2794：掲示板の検索機能強化 　投稿者：konno 　 2008/01/04(金)
#2821：掲示板の改行跨ぎ検索 　投稿者：konno 　 2008/01/12(土)

おかげさまで検索が非常に便利になりましたが、実はこの時野ざらし言と板塀にも
全ログ検索を導入してほしいと思っていたのですが、反応が薄くそのままになっていました。
今年は一念発起して、全ログ検索ルーチンをメールで送りつけることにしました。(^^;


find.cgi　は、wforum.cgi の中の2つのサブルーチンを抜き出したものです。

#  検索フォーム  #
sub find {

#  検索実行  #
sub search {

この2つのルーチンを置き換えるか名前を変えて追加するかして試してみてください。
エラーが出なければたぶん問題なく動作していることと思います。
内容は好きなように改変してください。

この全ログの改行またぎ検索を是非お二人の掲示板に導入してもらいたく、無理やり送りつけてしまいました。
なにとぞよしなに。m(__)m

konno さん

細かな理由はメールにて返信しましたが，
要は「気が向いたらネ」ということで．(^^;

> 要は「気が向いたらネ」ということで．(^^;

はい、気が向かれましたらよろしくです。(^_^)

野ざらしのアーカイブが進んでいないというご指摘も頂戴したので，
もう十年以上も放置していたログを上げようとしたところ，
過去ログに破損と番号の重複があることが判明してしまいました。(^^;

いきさつとしては，ちょっと長くなるやつですが……

Web Forum の確定した過去ログをnifty形式にするマクロで整形し，
Siさんの LOGSORT で整列させようとしたところ，
ヘッダの形式が異なるからダメよ……というメッセージで停止してしまいます。
で，いまさら Si さんのお手を煩わせるわけにもいかないと考えたので，
仕方なく LOGSORT.DEF を作ったわけですが，さて処理しようとしたとき
何を考えたのか間違えて元のWFログを指定してしまいました。それなりに待った挙げ句
何も出力されないので，なぁぜ・なぁぜ？と思ったら整形前の元ファイル。
それが判明した瞬間，なんなら元のWFログをソートすればよいのではと気づきました。
だって，先頭に発言番号のある1行1アーティクルなんですから……何故気づかなかった！？

どうせ HSORT を使うのならと三つの元ログをマージして処理したら，これが一瞬です。
しかし，三つも一遍に統合して並べたのにそれなりに空き番号があるではないですか。
実は，番号が飛ぶのが嫌で嫌で，掲示板利用者が自分で削除したような場合，
ログを編集して番号を詰めているんですよ。そういう性分だから仕方がない。
スパムも削除した後に番号をわざわざ詰めているんです。面倒ですけど。
要は，ある人が発言削除したとき，番号を埋めようとログを編集している最中に
その当人がコメントを書き直して書き込むということが発生していたのが原因です。
（ふつうの勤め人は書き込まないような時間帯だったので最悪のタイミングだった）

さて，どうしようかな。重複した一方を削除するのが簡単だけど，
とりあえず空き番号を割り当てられないか検討してみることにします。

そんなわけで，アーカイブも少々先送りという事情を長々と説明しました。

なんでこんなにクドクドしているかというと，ログソート及び空き番号列挙という
ふたつのマクロを久々に仕立て上げたのに，まるで無駄骨になってしまったから。
ちょっとしたリハビリでした，はい。……そんで飲んじゃった。ってわけ。

現時点では非公式版となっている2008年版の logsortw の存在を教えていただき，
実行してみたところ，ヘッダ不正問題は解決し，めでたく重複発言番号ありの
エラーによって停止しました。(笑)

さて，どうしようかな。
それに絡んでと思われるログ破損（一部消失）もあるので悩み中。
ログは固定されちゃっているので，ゆっくり考えればいいかな。

有難うございます＆御免なさい ＞ konnoさん

> 現時点では非公式版となっている2008年版の logsortw の存在を教えていただき，
> 実行してみたところ，ヘッダ不正問題は解決し，めでたく重複発言番号ありの
> エラーによって停止しました。(笑)

メールでのやりとりで、たまたまだったのですが、解決できたようでなによりです。

> さて，どうしようかな。
> それに絡んでと思われるログ破損（一部消失）もあるので悩み中。
> ログは固定されちゃっているので，ゆっくり考えればいいかな。

考えることは老化防止にいいですね。(^^;
私は全ログ検索出来てからは過去ログのアーカイブはこだわらなくなりました。
過去にやったことをなかなか思い出せなくなり、シナプスが繋がるよりも速く
全ログ検索で知りたい結果が出るので、もはやクラウドブレインです。
ブレインスモッグじゃないよ。(^^; ﾀﾌﾞﾝ

> それに絡んでと思われるログ破損（一部消失）もあるので悩み中。

ログの一部消失って、何とかなりました？
いや、一瞬だけ野ざらしに何やら書かれていたようですが、現在では削除済みの
ようなので。
なくなったのがどこかにもよりますが、その気になれば、野ざらしに具備されている
スパム対策用の強烈ログから復帰できる部分があるかもしれません。

あらっ，見られちゃってますね。(笑)
こちらに書くのも変なのですが，流れということでご勘弁ください，konnoさん。

ログをソートしてみたら，3882番から3909番が消失していることに気付いたのですね。
対応する時期としては 2011年のあの大震災の直前にあたる時期だったため，
1個以上のスレッドを現行ログから過去ログに移動するタイミングで，
震災に起因する突然の停電などに巻き込まれたに違いないと思いました。
Internet Archive にも前後数年が保存されておらず，スレッドのタイトルも不明。

ところがですね，手元の古〜いバックアップに残っていたのですよ。
そのバックアップが2012年2月の現行ログのバックアップだったので，
震災などの影響はまったくなかったと考えられるわけです。
そんなわけで消失告知を削除したという経緯です。

いやぁ，バックアップって取っておくものですね。

そもそもバックアップを日々保存していた理由が，
スパムが書き込まれたときに直前バックアップで上書きすると超ラクチンだから。
そのためにも定期的にバックアップをしようとしようと改めて思った次第です。

それでも，現時点で過去ログが不備な状態なので，何とかしないと，
たとえ「気が向いて」も全ログ検索機能を取り込めないという状況なんですね。

> そもそもバックアップを日々保存していた理由が，
> スパムが書き込まれたときに直前バックアップで上書きすると超ラクチンだから。

うちの板塀も、同じ理由でまめなバックアップは取っていたのですがね。
目的が目的なんで、バックアップの保存場所は同一サーバー内。
つまり、サーバーマシンがお亡くなりになると一蓮托生。
なので、現在ではそれはやめて、定期的に、lacoocanの非公開エリアにバックアップ
しています。

> そのためにも定期的にバックアップをしようとしようと改めて思った次第です。

定期的に何かをしようと思ったら、コンピュータに仕事をさせましょう。
私は、Windows純正のタスクスケジューラに仕事をさせています。
コマンドラインからサーバにアクセスするftpスクリプトを書いて、それをバッチで
呼び出していますが、そのバッチをタスクスケジューラに登録しています。
これであとはタスクスケジューラの設定次第で、月に１回だろうが週に１回だろうが、
裏で自動的にお仕事をしてくださっています。

確かにタスクスケジューラを使うと手間がないのかもしれませんね。
うちの場合は，常時起きているPCがないのと，日常の必要性もないので，
書き込みのあったタイミングでバックアップすることで十分に思います。

> うちの場合は，常時起きているPCがないのと，日常の必要性もないので，

ここがポイントか。
たとえば、週に１回、日曜の午前１０時、とかに設定する。
普段の日曜なら午前１０時にはPCを使っていない。
でも、ごくまれに、たとえばお天気の事情なんかで立ち上げていることもあるかも
しれない。
とすると、両方のアンド条件で、平均して月に１回のバックアップ達成、とか。
ここはあくまでも平均なんで、３週連続バックアップが行われたり、３ヶ月もの間
バックアップされなかったり、ということもおきえますが。
この辺、自分のPCの使い方と条件設定次第で、いかようにもできるかと。

実際の話。
常時起きているPCはないけれど，常時起こすことのできるPCはあります。
メインマシンは「休止状態」が有効なので，その気になれば制御可能です。
ただ，野ざらしの書込み頻度は五日に一度。
日常的に自動バックアップの必要性はないんじゃないかな〜

頻度の捕らえ方とか、まじめさが違うのかもしれない。
月に１度のバックアップでも頻繁だと感じるか。
週に１度でも、まれなことだと感じるか。
何らかのトリガを元に、必ずバックアップしないとまずいと思うか。
バックアップがないせいで復旧が困難を極めても、まぁいいかで済ませるか。

私自身は昔、PC-98でDOSのころは月に１回、HDDをフルバックアップしていました。
現在、Windowsになったら、フルバックアップなんて数年に１回。
堕落したものです。

頻度はまぁ，痛い目に遭った回数の反映か，性格かというところでしょうか。
ただ，痛い目というのは忘れやすいことも確かで，それこそ命の危険とか，
命よりも大事なデータ（そんなものあるのか？）とかでないと……とも思えます。

バックアップって，ふつうは自分で時間をかけて作成したものをするもので，
要するに時間にかける保険ですね。カネで買えるものは正直どうでもいい。
……はずなのですが，年金生活ともなると，そうも言い切れないわけで。

実際の話。
定期的にバックアップしているのは，メインの NAS。
これには USB で HDD が繋いであり，毎日夜中に自動バックアップしています。
また，半月に一度くらいの頻度で，サブの NAS 及びサブのデスクトップに繋いでいる
USB 接続の外付け HDD の二箇所にフルバックアップしています。
（フルと言ってもエロ動画なんかのディレクトリは対象外ですが）

前者は疑似ミラーですが，後者ニ個所は追加バックアップ。
メインから削除されたものも残っています。
ある意味安心なのですが，容量逼迫の原因なので，管理が面倒です。
少なくとも重複ファイル検索ツールをときどき使う必要があります。
（ディレクトリ名を変更したり，移動したものは重複してゆく）

その一方で，日々作成しているデータファイルのバックアップは怠っている状態。
今回のとしきさんとのやり取りで，そこ何とかしようか……と自覚しました。
要するに，もっともバックアップしなければならないファイルを放置していて，
メインのラップトップが逝ったら数ヶ月分の作業が失われる可能性があるということ。
ここは自動化や習慣化を考えなければいけないでしょうね。
腰を上げるきっかけを作ってくださり，有難うございました。

今までとしきさんに何度も指摘されていた msgview 個別発言のツリーのバグですが
としきさんに私の msgview.cgi を見て頂き、修正していただきました。
おかげさまでツリー表示は完璧になりました。＼(^^)／ ﾔｯﾀ-

としきさん、ありがとうございました。m(__)m

いやぁ、何とか動いてくれたようで助かりました。
一応、かなり複雑なツリー構造も含め、一通りの動作確認はしていますがね。
何せ、使ったデータが、うちの板塀のデータですから。
どんなチェック漏れがあるやら、想像もつきません。
というか、コードを書いた人が想像できないところにバグが忍び込むわけで。
そのうち、異常なパターンが発覚したら、そのたびに直すしか。
だって私、konnoさんのコードを読みきって修正したわけではなく。
正常な出力のallreadと異常なmsgviewを比較しただけなんで。
どういうロジックでツリーを出力しているのか、いまだによくわかっていない。
ま、動けば正義、というのはあるわけで。
とはいえ、動かないとき、だとか、動かなくなってしまったとき、のことを考えて
プログラミングしておいたほうが、いろいろと楽ができるとは思いますけど。
かつて、２０年ぐらい前だったかな、同じ職場にいた人で、この人は楽をしたくない
のかな、わざと難しくなることを好んでいるのかな、マゾっ気があるのか？　と
思わせられる人がいたことを思い出したりしました。

としきさん

> いやぁ、何とか動いてくれたようで助かりました。

としきさんのチェックなら間違いないと思っていました。
ありがとうございました。

> 一応、かなり複雑なツリー構造も含め、一通りの動作確認はしていますがね。
> 何せ、使ったデータが、うちの板塀のデータですから。
> どんなチェック漏れがあるやら、想像もつきません。

なるほど、人任せではなく自分でもチェックはした方がいいということですね。
お送りいただいた msgview3.cgi と自分の wforum.cgi で比較してみました。
wforum.cgi
		($no,$re,$lx,$sub,$eml,$url,$nam,$dat,$msg,$lt,$ho,$pw,$wrap,$oya,$sml,$com) = split(/<>/);
		$j++;
		if ($in{'oya'} == $oya) { push(@new,$_); 

msgview3.cgi
		($no,$re,$lx,$sub,$eml,$url,$nam,$dat,$msg,$lt,$ho,$pw,$wrap,$oya,$sml,$com) = split(/<>/);
		if ($in{'oya'} == $oya) { push(@new,$_); 
			$j++;

うげ、$j++; の位置が分岐前から分岐後になってる！！
他にも $mx=0; が追加されたり "}" の位置が、if の前になったりしていますね。
違いはこのくらいでしょうか。

実は昨日から STIME.EXE のソースを弄っていたのですが、うまく動かなくて・・・
色々調べたら、変数の設定を if 分岐の前にやっていたのが原因でした。(>_<)
どうやら私は分岐で躓く傾向があるようです。

> とはいえ、動かないとき、だとか、動かなくなってしまったとき、のことを考えて
> プログラミングしておいたほうが、いろいろと楽ができるとは思いますけど。

メールで言っていた、インデントや不要なコメントなどですね。
これからは気を付けるようにします。

> かつて、２０年ぐらい前だったかな、同じ職場にいた人で、この人は楽をしたくない
> のかな、わざと難しくなることを好んでいるのかな、マゾっ気があるのか？　と
> 思わせられる人がいたことを思い出したりしました。

うう、私のソースってそんなふうに見えているのですか・・・　(;_;)

実は私自身、$mxの初期化漏れってそんなに影響があるとは思っていませんでした。
でも、なんかうまく行かなかったので、わりと早い目に追加しました。
そして、$jは配列の添え字。
配列を設定する側で添え字のインクリメントが間違っていたため、配列を読み出す
部分で配列の正しい位置にアクセスしてもデータが取り出せず、未定義の情報で
条件判断するはめになってしまい、"┃"と空白のどちらを出力するかという部分が
うまくいっていなかったのでした。

> メールで言っていた、インデントや不要なコメントなどですね。

不要なコメントの部分、あれはほんと、まるで迷彩のような。
軍事用語でもありますが、私がコードを読んだ第一印象は、マージャン漫画での
この言葉。そして、ＳＦへのマジレスでよくある、透明人間は回りを見ることが
できないとの説から、光学迷彩を放った本人（konnoさん自身）が迷彩にやられて
しまった、という感じも受けました。

インデントのほうはねぇ。こちらはちょっと長くなります。
これは、コーディングスタイルとかいって、スタイル、つまり美学の領域。
美学って確か、文太先生の専門だったような気もする。
それはさておき。
たとえば、最近のkonnoさんのＢＡＳＩＣのコード。
最近いじった部分がわかるほうが良い、と思う人なら、昔のコードの部分は行番号
があって大文字、最近いじった部分は行番号無しで小文字にする、とか。一方で
統一感があったほうが美しいと思う人なら、全て大文字で行番号つきに統一、と
いろいろな考え方があるわけです。
でも、どの立場に立とうが、プログラムの論理構造、つまり順次・選択・反復と
いった構造をわかりやすくするためには字下げしかありません。既に３０年以上
前から、これは当たり前のこととされています。昭和６０年ごろに書かれた本には
「いまや字下げをしないプログラマは・・・」などという記述があったりします。

えぇと、いい機会だから書いてしまおうかな。
上記の本の紹介。#10398でも書いていますね。

林晴比古著「BASICによるプログラミングスタイルブック」
ISBN4-930795-28-1
定価1800円
昭和60年12月25日初版発行

私の持っているのは昭和61年11月の第4刷。
この本が出る2年位前からOh!PCに掲載されていたものがまとめられたのですがね。
この本が出た前後で、Oh!PCに掲載されるサンプルコード、特に学習用の講座などの
コードはみんな、なだれを打って、という感じで、読みやすいコードになりました。
その後、ベーマガのコードはあまり変わったようには見受けられませんでしたが、
ASCIIやI/Oのコードは、数年後には少し変わったかも。


> うう、私のソースってそんなふうに見えているのですか・・・　(;_;)

ま、私がとりわけぐうたら、と言うのもありますが。
プログラムを作るのって、結果が欲しいから作るものだと思っております。
なので、過程は楽をしたい。つまり、デバッグは楽なほうがいいと思っています。
だけど、あのコードは、なんかわざわざデバッグそのものを楽しむためのコードの
ような。
「デバッグ楽しいなぁ〜(;_;)」という経験の多寡でも考え方は変わるかも。

> 実は私自身、$mxの初期化漏れってそんなに影響があるとは思っていませんでした。
> でも、なんかうまく行かなかったので、わりと早い目に追加しました。
> そして、$jは配列の添え字。
> 配列を設定する側で添え字のインクリメントが間違っていたため、配列を読み出す
> 部分で配列の正しい位置にアクセスしてもデータが取り出せず、未定義の情報で
> 条件判断するはめになってしまい、"┃"と空白のどちらを出力するかという部分が
> うまくいっていなかったのでした。

うう、やっぱり基本がわかっていないとこういうミスを出しやすいのですね。
今回 BASICでも同じようなところで躓いて直すのにえらく時間がかかってしまいました。

> 不要なコメントの部分、あれはほんと、まるで迷彩のような。
> 軍事用語でもありますが、私がコードを読んだ第一印象は、マージャン漫画での
> この言葉。そして、ＳＦへのマジレスでよくある、透明人間は回りを見ることが
> できないとの説から、光学迷彩を放った本人（konnoさん自身）が迷彩にやられて
> しまった、という感じも受けました。

私も義体化が進んできたので、バトーのようになるのでしょうか。（違）
BASICではコメントを緑に表示しているので、マジで迷彩服のようになってます。(^^;

> 上記の本の紹介。#10398でも書いていますね。
> 林晴比古著「BASICによるプログラミングスタイルブック」

うう、いまさら聞けないBASIC みたいに微妙な・・・　見かけたら読んでみたいですね。(^^;

> だけど、あのコードは、なんかわざわざデバッグそのものを楽しむためのコードの
> ような。
> 「デバッグ楽しいなぁ〜(;_;)」という経験の多寡でも考え方は変わるかも。
　　　　　　　↑　　　　　↑
ククッ、、思わず吹いてしまいました。
まさに私のことを的確に言い当てているような。(^^;

追伸というか。
きちんと理解できていないというのもあって。
もしかしたら、$mxの初期化って、それほど重要ではないかもしれない。
ただ、少なくとも、allreadのほうでは初期化してあったような。
それに、初期化しておいて害になることもないし。

> > 上記の本の紹介。#10398でも書いていますね。
> > 林晴比古著「BASICによるプログラミングスタイルブック」
> うう、いまさら聞けないBASIC みたいに微妙な・・・　

私には、文体が引っかかるんですよ。
ただ、この時代のコンピュータの本を書く人って、特徴的な文体の人が何人かいて。
もう一人、ナツメ社あたりからアセンブラか何かの本を出していた人で、どうにも
文体が肌に会わなかった人がいたような記憶もある。
さて。
よく見たらタイトルが微妙に違う。
「BASICによるプログラミング・スタイルブック」
と、中黒があるのが正解。
章立ては

STEP1 基本を知る
STEP2 型にはめる
STEP3 サブルーチンの整理
STEP4 視点を変える
STEP5 工夫に、工夫を

となっている。中身に文法解説はほとんどない。
章の中の各節は、抜粋ですがたとえば

１　BASICの能力を見直そう
５　字下げをしよう
９　意味のわかる変数名にしよう
12　ブロック構造にしよう
15　マルチステートメントは上手に使おう
16　空白を入れよう
19　行番号をそろえよう

といった項目が46個あり、各節の中でそれぞれ根拠と共に例示がなされている。
当時の普通科高校生でも十分読める文章でしたから、文章としては今なら中学生
にも理解できると思う。いや、BASICのほうを解説してやらんとダメか。


さて、それでは、ちょっと一休みして。
つぎはいよいよ、konnoさんご希望の、掲示板検索ルーチンに取り掛かってみますか。
って、いつ開始するか全くめどは立っていませんが。

　ククッ、、思わず吹いてしまいました。
　会話の意味がまったく分からない。これが日本語であることは認知して
おりますが。

　それより、おお、そんな会話があったのか、１年ちょっと前。すごい
記憶力　＞としきさん。もちろん、検索したのは分かりますが。
　というわけで、 林晴比古著『BASICによるプログラミング・スタイルブック』
を図書館で探してみましょう。（注）

解説：まったく本腰が入ってませんが、僕は BASIC に興味をもっている
のですね。だから、この前のオフ会にも岡田元治さんの BASIC コンパイラの
マニュアル・プリントアウトを持って行ったのです。「ハノイの塔」の
コード・プリントアウトとともに。

　学習は「ハノイの塔」とは何か？　から始まる予定。まだ始まらない……。

>小さい円盤の上に大きいものを重ねることはできない。 [補説]フランスの数学者
>リュカによって1883年に考案された。 発売時に、アジアに伝わるパズルという
>架空の設定で宣伝されたため名付けられた。

　という語源だそうです。ベトナムはベトナム戦争の前までフランスの
植民地でした。日本もほぼ瞬間的に植民地化しましたけれど。
　ああ、インパール作戦。

konnoさん、
　konnoさんのお祈りのおかげで、例の地獄の作業、あの日のうちに終わりました。
いまは次の修羅場に備えております。ふらっふらになった記憶は新しいのですが、
そのとき、ちゃんと konnoさんに感謝し、お祈り返しもいたしました。m(__)m

鈴木康弘大先輩、
　お初です！　いらっしゃいませ！！！　Win7マシンでパーティション切り、ＤＯＳ
（FAT16）ドライブ！！！　やるぅ。
　「Ｖｚマクロほんとの入門」の作者さんですよね！！！　お世話になりました。

　江戸地方、今日は晴れです。（う、孝義さんだった。弟さん？）


（注）しかし、こういうのばっかですねぇ、＞己。_Software Tools in Pascal_は、
Ｖｚ黒本の隣に鎮座している。ここから１メートル以内。

> もしかしたら、$mxの初期化って、それほど重要ではないかもしれない。
> ただ、少なくとも、allreadのほうでは初期化してあったような。
> それに、初期化しておいて害になることもないし。

変数の初期化は最近の速いCPUでは特に必要かもしれませんね。
初期化してないせいでタイミングが狂い挙動がおかしくなることもありそうで。

> よく見たらタイトルが微妙に違う。
> 「BASICによるプログラミング・スタイルブック」
> と、中黒があるのが正解。

内容の紹介を見て、読んでみたくなりました。
ちょっと前までは本を読む気にもならなかったのが、目が復活したら読書欲も復活？

> さて、それでは、ちょっと一休みして。
> つぎはいよいよ、konnoさんご希望の、掲示板検索ルーチンに取り掛かってみますか。
> って、いつ開始するか全くめどは立っていませんが。

おお、期待しています。(^_^)
ログ形式が同じならそのまま動くのではないかと思っています。

> 　学習は「ハノイの塔」とは何か？　から始まる予定。まだ始まらない……。

「ハノイの塔」って、再帰のサンプルとしては非常に有名。
プログラム初心者に再帰を説明するのは「ハノイの塔」かフィボナッチ数列か、
というくらい。再帰を使ったほうがシンプルなものって、実生活ではあまり
見かけませんからね。
また、再帰でできるものは必ずループでもできるらしい。
なので、再帰からループへコードを変更するための題材にも使われるらしい。
で、ループならどうということもないのですが。
８ビットパソコンの時代のBASICでは、再帰というものが使えませんでした。
なので、そこでわざとループを使わず、いかに擬似的な再帰を実現するか、という
のも、ちょっと気取ったプログラマたちの力試しの例題に使われていたりして。
ま、再帰が使えない、という意味ではVzのマクロも同様。
だけど、Vzのマクロでも「ハノイの塔」はしっかりあるわけで。
結局、アルゴリズムなんて、どんな言語で実現しようが大差はないはず。
もちろん、向き不向きはあるでしょうが。

DOSVAXJ3 240130版が更新されました。
以下更新内容です。

build JP240130　(2024/1/30)
[sdl] windowposition の位置指定が画面モード変更でも有効になっていたのを修正しました。


想像ですが、windowposition は本来画面モード設定時の位置情報なのでしょうね。
私の使い方では起動時のみ指定した位置に固定されているほうがありがたいです。
作者様に感謝です。

としきさん、

　詳細にありがとうございます。もともと「再帰」を狙ってあのサンプルを
選んだわけではなくて、単に「BASIC って読みやすいね。英語じゃん」という
だけだったのですが、この際ですから、「再帰」と「ループ」がどう違うのか
分かってやろうじゃないの、という気分になっています。
　多謝です。

　とはいえ、もうちょい待って。次々いろいろ起こるのですよねぇ、、、。
とほほ。

　ま、岡田元治さんのコンパイラに通るコードは、構造化もできるし、
「再帰」もできるし、十分にモダンなもの、ということですね。
　あ、マニュアルにね、FortranとかPascalとか出てきて（もちろん、
過去と歴史の話として）、そしてＣは出てこなくて、そうですかぁ、よい
ですねぇ、その語り口というものでした。
　まったく無駄話をしない学者肌な方ですが。

　行くぞ、ハノイ！　３月あたり。「ハノイへ行ってみよう！」とかいう
タイトルで、少しは勉強してから、再帰いたします。

　ありがとうございます。

　そうそう、BASIC のユーザ変数に「型」がある、そのトークンがある、
というけっこう前の解説にも感謝していました。重ねてありがとうございます。

　血糖値（糖尿）のあとは、胃がんか？　やれやれ。
　長生きするぞ！

　どうでもよい追記です。書くのを忘れていました。少し古い話。
　近場のも都立のも、図書館にはありませんでした。ＰＣ関係の古い本って
わりと廃棄される可能性が高いような印象。
　というわけで、いちおう古書店をサーチ。ビンゴ！　送料込み \1220 。
　こうして、書庫の肥やしが、いえ、さらなる幸福コレクションがもう１冊、
本棚に追加される予定です。今日か明日には、着くのではないかしら。
　ま、どうでもよいことですが。

有り難いですね．
こういうちょっとしたことが毎回だとストレスになってしまう可能性があるので，
実に嬉しい更新です。位置情報保存を要望してくださった konno さんにも感謝。

> 本棚に追加される予定です。今日か明日には、着くのではないかしら。

もう届いていそうですね。
ま、気が向いたら本文を読みましょう。
推理小説でもありませんから、結末から読まなくても大丈夫。
＃おいこら
とりあえず、序文と目次くらいは読んでおいてもいいかも。
内容に対する批判はあったかもしれないけど、文体が合わない、というのは私くらい
のものでしょう。あ、でも、雰囲気が合わなくて上村さんの本に手を出さなかった、
というのはめざらさんでしたっけ。
そして、私の場合、文体ではなく内容のほうは、とても勉強になりました。
本文で作者は

> だから、筆者の書くプログラムは使用する言語がBASICだろうがCだろうがPascal
> だろうが、ほとんど同じスタイルをしている。

と書いていますが、私も、BASICだろうがPerlだろうがVzマクロだろうが、ほとんど
同じようなスタイルのプログラムになっています。この辺はまさに、この本からの
影響でしょう。

文太さん

> 　行くぞ、ハノイ！　３月あたり。「ハノイへ行ってみよう！」とかいう
> タイトルで、少しは勉強してから、再帰いたします。

ハノイの塔の話題が出たので、見てみたら VZマクロと Turbo Basic のサンプルソースにありました。

Turbo Basic のはそのままコンパイルできて、USモードで実行出来ました。
プレート 17枚でも数秒で完了するほど高速で、目に見えないので ウエイトを入れました。
自分好みの改造が整ったら公開しようかな。？

VZマクロは、軟体にある田野村さんのマクロで、プレート12枚まで実行出来ますが、流石に遅いです。
枚数を 14枚まで増やしたり、高速化の改造をして、ある程度形になりました。
秒数の比較

		　オリジナル　　　	　改造
数n	回数i	W80*25	W136*35		W80*25	W136*35

12	4095	89秒	95秒		47秒	52秒
13	8191					112秒
14	16383					240秒

　　　　↑
1枚増えるごとに約２倍の回数というのが面白いですね。

さて、これらのマクロや BASIC（実行ファイルのみ）をアップしたら
文太さんの勉強にかえって邪魔になってしまうかな。(^^;


＃　タイトル変更した。これで安心。(^^;;

　ハノイへようこそ、じゃないな。
　手を動かさず、クチばっかり動かしている文太です。
　目で活字を追うだけの日常は、まだまだ続くのですが。
　あ、体ぜんぶを使って、雪かきはしましたよん。

　さてさて、良書だろうと思います。ちらちら眺めただけですが。

>私も、BASICだろうがPerlだろうがVzマクロだろうが、ほとんど
>同じようなスタイルのプログラムになっています。

　こうなるでしょうね、この抽象度の高さだと。
　えーと、あれだけ詳細に内容を紹介していたので、あ、わたくしに
買えと仰ってる、と誤解したのです。これは、konnoさんが勧められて
いる本でした。
　が、僕も楽しくよめそうですよ。BASICのコードを覚えながら。

　konnoさんが勧められている点とは違いますが（？）、−−ごめん
なさい、長すぎて引用できません　＞konnoさん−−、たとえば、
p.231。まあ、広義に文体と言ってもいいですが、この作者の読者
への姿勢みたいなのは、僕も鼻につきました。僕は、何かを伝える
人が偉そうなのは好きです。僕に何かを教えてくれる人はみな先生で、
「先生はいつも偉い、絶対的にエライ」と思っています。

　が、ここ、しつこい。「自己満足におちいり、自己陶酔にひたる」。
ここでお仕舞でいい。この上の段落も４行ぐらい削除したい。この
段落も残り全部カットしたい。説教がうるさすぎ、という印象ですね。
　具体的に中身のあることを語れ。

　ま、これも一度はまると、このムチが快感、となることもあるので、
こちらの気分次第という面もあろうかと思いますが。

　と、同調して批判的なことを書きましたが、これがなければ、という
気持ちです。ゆっくり３回読む価値はあるな、と思っています。

　本を手に取れる人にしか通じない書き方でごめんなさい。
　konnoさん、僕はちょっと時間がかかりそうですので、熱いうちに、
としきさんに借りてみましょう！

　田野村さんでしたか、そんな記憶がおぼろげにありましたが……。
　あの人、そういう本格的な王道を生きた人でしたね。
　が、僕の手、動かず。

タイトルに合わせてこちらにレスします。

ハノイの塔のマクロ関連情報を得ようとnifty会議室の過去ログを検索しましたら
としきさんの書き込みがありました。

> 18134/19000 PEB03250  としき           再帰マクロ
> (15)   01/03/24 00:49                     コメント数：2
> マクロで再帰を使う実験をしてみました。
> = フィボナッチ数
> 
> では、ついでにもう一つ。
> 昔、再帰が使えない N88-BASIC で使った、配列を擬似的なスタックとして使うと
> いう技をマクロで使ってみました。別にスタック領域が足りない訳でもないのだ
> から、素直な push pop でもいいと思いますが。
> = ハノイの塔

今回はソースは省略しますが、#11066 の としきさんの書き込みを思い出しました。

> プログラム初心者に再帰を説明するのは「ハノイの塔」かフィボナッチ数列か、
> というくらい。再帰を使ったほうがシンプルなものって、実生活ではあまり
> 見かけませんからね。
> また、再帰でできるものは必ずループでもできるらしい。
> なので、再帰からループへコードを変更するための題材にも使われるらしい。

23年前に実際にマクロコードを書いていたのですね。流石です。

> で、ループならどうということもないのですが。
> ８ビットパソコンの時代のBASICでは、再帰というものが使えませんでした。
> なので、そこでわざとループを使わず、いかに擬似的な再帰を実現するか、という
> のも、ちょっと気取ったプログラマたちの力試しの例題に使われていたりして。
> ま、再帰が使えない、という意味ではVzのマクロも同様。

この再帰というのが私はいまいち理解できていなくて。
BASIC で言えば、サブルーチンの中でそのルーチンの先頭に飛んで条件を満たすまで繰り返す。
みたいな感じでいいのかしら。
実際VZマクロでもそういう動作をしているように思いました。

としきさんのコード、わかりやすそうですね。
いつか使わせてもらうかもしれません。

雪は夜更けすぎに、雨へと変わるだろう、サイレ（以下略）

俺は何を歌っているのだ。
いやぁ、２月５日は深夜、２３時ごろになって大雪も峠を越えて、みぞれか雨か、
というものが弱く降ってくるだけになったので、そこから雪かき開始。
だって、６日は日勤で出社しないといけないのだもの。
結局、１時間あまり汗を流して、自宅前の道路の雪は概ね撤去。
撤去した雪のほとんどは、自宅の庭に放り込みました。他に置く場所がないから。
多少は側溝にも押し込みましたけどね。
それから入浴して就寝は２時過ぎ。
だけど、夜通し続いた落雪の音がまるで爆撃のようで、一晩中まんじりとせず。
６日は普通に５時起きして、いつもより５分早く６時前には出社。眠い。
ちなみに、７日も日勤なので５時起き予定。
あぁ、掲示板に書き込んでる余裕なんてない。はず。
７日も眠そうだ。


それはさておき。

> 　さてさて、良書だろうと思います。ちらちら眺めただけですが。

以前にも書きましたが、内容については、王道も王道。
重箱の隅はともかく、全体的には、あまり批判できない。

ところで、この本、雑誌連載をまとめたものです。
不定期連載みたいな形で、１年ぐらいに渡って書かれたものだったかと。
当然、読者からの感想みたいなものが編集部に届くわけですよ。
そんな中に「これはもはや宗教だ」みたいな内容が混じっていたことがあったらしい。
でも、決してそんな事はない。
他のえらい学者さんたちが唱えたことのBASICでの実装例をひたすら紹介しているだけ
の、単なる工学の本です。
ただ、対象とする読者層の設定には苦労したと思う。
だって、中身は大学の学部情報科の初級クラス。
だけど、実際にその雑誌を読んでいる人や読んでほしい人といったら、プログラムを
専門としていないけど業務命令その他でプログラムを作成するハメになった社会人
から小中学生まで、多岐に渡るわけです。そして、それら全ては素人前提。
いわば、英語の先生が、大学英文科で教えるような正当な文法を、小学生から社会人
までをすべて対象とする１冊の教科書を作る、みたいなもので、ある程度の無理が
発生するのは当然かもしれません。そして、そのしわ寄せとか作者へのプレッシャー
といったものが、どこかで発現してもおかしくはないと思います。
だけど、雑誌連載時も否定的な意見は届いたはずだけど、そこそこ少ないはず。
なぜなら、連載継続とか単行本出版という結果に至ったわけだから。
ということは、ある程度の成功と推測してもいいんでしょうね。

としきさん

　雪かきと落雪の爆撃への守り（寝れんぞ）、お疲れ様でした。
　すごいなぁ、その体力。うらやまし。

>他のえらい学者さんたちが唱えたことのBASICでの実装例をひたすら
>紹介しているだけの、単なる工学の本です。

　はい、「構造化は BASIC でも十分できる」という本ですね。
　「えらい学者さんたち」とは、クヌース、カーニハン、リッチー、
ダイクストラ、Ｎ・ヴィルトなんて人たちです。
　プログラミングって何？　と思ったことのある人なら、聞いたこと
のある名前たち。
　王道。
　（僕的には、〔少し嘘かもしれないけど〕榊原さんがsyoさんに
教えていたことの反復、という印象でした。自己評価、高すぎかな？）

　僕としては、ここ３年くらい、楽しく考えてきたこと（Fortran, Pascal,
Ratforなどを題材に）が、きれいに整理されてるな、というのが
『プログラミング・スタイル』についての最初の感想でした。

>いわば、英語の先生が、大学英文科で教えるような正当な文法を、
>小学生から社会人までをすべて対象とする１冊の教科書を作る、
>みたいなもので、

　あまり良い比喩とは言えないかと愚考いたします。そんなの、まず
僕には無理で、嫌だ、そんな仕事、やらないからね、と言うような
問題設定。

　でも、初出雑誌が何だったか思い出せませんが、やっぱり
「プログラミングって何？」という興味と動機のある人たちが読者
だったんじゃないのかな、と想像します。
　「動いた、楽しい！」という経験がある人たち。

　おお、Ｃも出てきた。林先生、この時期にコンピュータの全体像を
把握されていらっしゃったのですね、と思いました。
　この本の初版は、「昭和６０年１２月」＝１９８５年。僕の本は、
２刷（昭和６１年）。僕が、将来まさかＰＣ方面に関心をもつなんて、
夢にも思わなかった時代の本。

　すごい本ですね。自信はありませんが、色あせない本です。

> 　あまり良い比喩とは言えないかと愚考いたします。そんなの、まず
> 僕には無理で、嫌だ、そんな仕事、やらないからね、と言うような
> 問題設定。

確かによい比喩ではないと思う。
でも、ならどう例えればよいかというと、あまり思いつかない。
文太さんは知っていると思うけど、私、あまり例え話が得意ではないので。

ちなみに、初出雑誌は、当時の日本ソフトバンク社の月刊「Oh!PC」。
当時のソフトバンクが出していた、いわゆる機種別誌というヤツですね。
広告によると、当時は他に
月刊「Oh!MZ」
隔月刊「Oh!FM」
季刊「Oh!HC」「Oh!55」
などといった雑誌が出ていたようです。
最初の掲載は1983年10月。本棚から引っ張り出してきました。
懐かしいですね。というか、しまいこまれず本棚にあると言うのがなんとも。
最初の掲載時は、まだその後が続くとは思われておらず、特集扱いでした。
あ〜、読み直しているうちにだんだん思い出してきた。
最初のうちは、それほど文体にも引っ掛かりを覚えなかったんですよ。
単なる、淡々とした文章だ、と言うだけで。
なので、単行本化されたときも大して加筆されていないという評判を聞いたもので、
なら雑誌掲載記事は全て持っているわけだからわざわざ買うには及ばないな、と判断
して、すぐには購入しなかったのですよ。ただ、やはり毎回大きいサイズの雑誌を
引っ張り出すよりは小さくまとまった単行本のほうがいいという判断で、最初に発売
されてから２〜３年ぐらいしてから購入したのでした。
だから、私の持っているのは昭和61年11月の第４刷。
たぶん、62年か63年になってから買ったはず。

上記、1983年10月号の目次をみると、以下のような記事があります。
まず、目次で特集の次に並んでいるのは、海外のCG展示会の記事。
次が「新作ゲーム画面集」。やっぱりみんな、ゲームが好きなんですよ。
ついで「超大型オリジナルプログラム第１部」としてPC-9801用の家計簿プログラム
が「パーソナルバランスシート」なる大仰なタイトルで載っている。
これは連載というより、複数回掲載の初回、という感じ。
そして「４つのBASICへの入門」というサブタイトルのついている講座。おそらく、
NECの各機種用のBASICの差異の解説まで踏み込もうとしているのではないかなぁ。
でも、このときはまだ第３回。
さらに「マシン語超入門講座」や「機械語熟語集」といった連載では８ビットのZ80が
対象。
「ミニフロッピーの活用法」という連載もあるけど、この号は番外編で、拡張メモリ
をフロッピー的に扱うソフトが掲載。ま、RAMディスクですね。しかも、これの対象は
８ビットパソコンであるPC-8001とPC-8801。他の号をみていないけど、この連載が
そもそも８ビットパソコン対象なのかも。
そして、ハードウェア工作の「PC工作入門」は、この号ではPC-9801用の記事だけど、
それまでの記事はみんな８ビットパソコン用だったらしい。
さらに、機種別のページも、取り上げられているのは８ビットマシンだけ。
つまり、業務にもバリバリ使える１６ビットパソコンは、まだまだ黎明期。
この時期のこの雑誌が、ソフトウェア工学の、ある意味で理論的な記事を掲載すると
いうのは、少なくともニーズとしては顕在化していないはず。
というか、ミスマッチもいいところ。
また、商業的な意味では冒険というか、よく掲載に踏み切ったものだと思います。
そして実際、このときか２回目の掲載のときか、連載陣の一人がけんかを吹っかけた
というか婉曲に批判したけど、そもそもけんかにならず、逆にその人の連載が終了
するハメになっていたり。さすがに打ち切りではなく、最終回まで掲載されたけど。

ということで

> 「プログラミングって何？」という興味と動機のある人たちが読者
> だったんじゃないのかな、と想像します。

これはどうなんだろう。
konnoさんならあのころのベーマガとかの雰囲気を覚えているかもしれない。
みんな、いかに自分のアイディアを実装するかしか考えていないような感じ。
なので、その先、というか、どうすれば効率的にバグなく実装できるか、などという
ところまでは思い至っていないんですよ。
特にゲームなんかはある意味で一発勝負のようなところもあったし。

> > 「プログラミングって何？」という興味と動機のある人たちが読者
> > だったんじゃないのかな、と想像します。
> 
> これはどうなんだろう。
> konnoさんならあのころのベーマガとかの雰囲気を覚えているかもしれない。

このころベーマガとか読んでいたかは覚えていませんが、BASICはやってましたね。
当時円弧と直線の交点だったかを求めるのに方程式がわからなくて困ってしまい
ポケコンのBASICで２分法というのを使って、それですました記憶があります。(^^;

> みんな、いかに自分のアイディアを実装するかしか考えていないような感じ。
> なので、その先、というか、どうすれば効率的にバグなく実装できるか、などという
> ところまでは思い至っていないんですよ。

まさにそのとおりで、プログラムを組めば仕事が楽になるという思いで必死でした。

パソピア１６を見つけた時は、「こいつ、動くぞ」とつぶやきながらマニュアルをめくり
「武器はないのか」と見たら、BASIC で動いているのがわかり、自分でテキをやっつける
武器を作り、大危険に突入していったのでした。(^^;

DOSVAXJ3 では Ctrl+[F01] は Key Mapperに割り当てられていて
今まで それで運用していたんですが、もうどうにも我慢できなくなり
Mapper の起動キーを変更することにチャレンジしました。

DOSVAXJ3 の作者からいただいたメールの内容を以下に貼り付けます。

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

　ファンクションキーと Ctrl 等の組み合わせについては DOSBox の機能
に割り当てられており、そのままでは入力されません。
　Ctrl-F1 でキーマッパーを表示し、機能名をクリックして Del をクリッ
クすると機能を削除できます。詳しくは下記を参照してください。Clipboard
は DOSVAXJ3 独自機能です。
https://www.dosbox.com/wiki/Special_Keys
キー割当  機能名
Ctrl-F1   Mapper
Ctrl-F4   Swap Image
Ctrl-F5   Screenshot
Ctrl-F6   Rec Wave
Ctrl-F7   Dec Fskip
Ctrl-F8   Inc Fskip
Ctrl-F9   ShutDown
Ctrl-F10  Cap Mouse
Ctrl-F11  Dec Cycles
Ctrl-F12  Inc Cycles
Alt-F10   Clipboard
Alt-F12   Speedlock

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

Alt-F10 で Clipboard から張り付けが出来るのは良いですね。
Alt-F11 が空いているので、そこに Mapper を割り当てたいと思います。

さて、wiki を見てもキーマップの変更の仕方がよくわからなくて試行錯誤した結果
mapperj.map ファイルを作ってそれを編集するのが一番わかりやすそうです。
手順は

１．Ctrl-F1 で Mapper を表示させます。
２．[Save]ボタンをクリックすると DOSVAXJ3 のフォルダに mapperj.map が出力されます。
３．mapperj.map ファイルを開き、4行目

hand_mapper "key 282 mod1" 

これを

hand_mapper "key 293 mod2" 

こう変更します。

  key 282 は [F01]
  key 293 は [F11]
  mod1 は Ctrl
  mod2 は Alt

これで、Alt+[F11] で Mapper が表示されるはずです。
Ctrl+[F01] はフリーになり、VZで使えるようになるはず。

っと思ったら、VZで動かない。(;_;)
あれえ？ と思ったら、VZ.DEF で無効にしてたという。(>_<)
VZ.DEF を元に戻したら VZで使えるようになりました。＼(^^)／ ﾔｯﾀ-
やれやれです。<(^^;)

> ■ VTDOS+CKWV 環境で Google IME を起動すると落ちる

今朝，Windows 10 のアップデートが(勝手に)行われたのですが，
上記現象は発現しなくなりました。

結局，原因はわからずじまいでしたが，Windows のせいだった……
……という結論にならざるを得ないですね。

……と思ったら，Google IME の候補一覧がちらちら消えてしまう現象に対処する
タスクマネージャからレンダラーをリセットするという方法が効かなくなってしまい，
なんともはや使いにくいという状況に陥っているところであります。
ところが，これは VZ の方は問題なし。最高！＼(^o^;)／

> まさにそのとおりで、プログラムを組めば仕事が楽になるという思いで必死でした。

最近konnoさんが公開されたBASICのコードを見ても、必死さはにじみ出ている感じ。
だけど

> 「武器はないのか」と見たら、BASIC で動いているのがわかり、自分でテキをやっつける
> 武器を作り、大危険に突入していったのでした。(^^;

作った武器が手作りの竹やり同然、かもしれず。
＃この艦では勝てない･･･

先般、見せていただいたPerlのコードなんかも、工夫の跡は見て取れるのですが、
これ以上、どこにどう手を入れてよいかわからない。
いや、高度に完成されて手を入れる余地がない、という意味ではなく。
ちょっと手を入れたらすべて崩壊しそうなジェンガというか砂上の楼閣というか。
ソフトウェア工学の教育を受けていないから仕方ないのですが。
全面的なリファクタリングをしたくなってしまう。
逆にいうと、konnoさん、伸びしろは無限大。
今からでもきちんとソフトウェア工学の基礎を勉強してみるのも一興かと。
 

> 今朝，Windows 10 のアップデートが(勝手に)行われたのですが，

２〜３日前、Windows7の電源を入れたら、アップデートが行われました。
まだやってたんだと、ちょっとびっくり。
それはともかく、久しぶりというか、Win7の挙動を忘れていまして。
アップデート後、シャットダウンを求めてくるのは当たり前、なんですが。
私の記憶では、更新して再起動というのがあったはずなんですね。
でも、終了オプションにそういう選択肢がない。
普通に再起動を選択したら、更新が当たってくれていない。
つまり、更新して終了という選択肢が出続けてくれやがる。
仕方なく、一旦終了を選んで、落ちてから再び電源投入。
なんかめんどくせ〜。

> 作った武器が手作りの竹やり同然、かもしれず。

ランボーなら竹槍でテキを全部やっつけられるかも。(^^;
私はランボーではないので、乱暴なコードになってしまうのです。

> ちょっと手を入れたらすべて崩壊しそうなジェンガというか砂上の楼閣というか。
> ソフトウェア工学の教育を受けていないから仕方ないのですが。

まったくそのとおりです。
なんせ自分で昨日書いたコードが読めないのですから。(-_-;)

> 今からでもきちんとソフトウェア工学の基礎を勉強してみるのも一興かと。

最近物忘れが地方レベルになってきてるので、難しいですね。(^^;

> 最近物忘れが地方レベルになってきてるので、難しいですね。(^^;

アップル認定の世界最高齢のプログラマは現在８８歳だとか。
そういう人にkonnoさんのせりふを聞かせたら「最近の若い者は〜」とか言いそう。

それはさておき。
konnoさんに勉強してもらってきれいなコードを書いてもらいたい、というのは決して
konnoさんのためではなく。
ざっくりレベルで、今のままのkonnoさんがバグのありそうなコードを３つ書き上げる
のに要する同じ所要時間で、勉強したkonnoさんならバグのなさそうなコードを５つは
書き上げられそう、という見積もりをしたのですよ。
つまり、それだけアウトプットの質・量が向上すると、私を始めみんながうれしい、
ということ。つまるところ、私利私欲なわけですよ。
あるいは、先日BASICのコードを公開されたように、今後はオープンソースの方向に
舵を切っていく、とか。

古いところにぶら下げを御免なさい。

> CALENDAR.DEF　Yushi さんのモノクロ版カレンダー拡張wanama版は
……を見て，そう言えば令和対応ってどうなってたっけ？と思ったら何処にも
情報が出ていなかったので，野ざらし言#5481 に使用中のを貼り付けておきました。

機能は変わらずデータ追加だけなので版に変更はありませんが，
何か識別子がないと紛らわしいため v1.08wm と仮表示してあります。


和生師匠は元気にしてますかねぇ……
……と言うことがあまり現実的でないことは承知しています。

以前，うちの大根と秩父の杓子菜漬をお送りしたところが大層なお返しをいただいて
尻込みしてしまい，その後ほとんど連絡も途絶えてしまっているのですが，
お便りくらいは出してもばちは当たらないですよね。……暖かくなったら……

> アップル認定の世界最高齢のプログラマは現在８８歳だとか。
> そういう人にkonnoさんのせりふを聞かせたら「最近の若い者は〜」とか言いそう。

うう、それを言われたら弱音を吐けないではないですか。(^^;
まあ、何故か今は色々プログラミング欲が出てきて同時に2〜3種のコードを見てたり。(^^;

> ざっくりレベルで、今のままのkonnoさんがバグのありそうなコードを３つ書き上げる
> のに要する同じ所要時間で、勉強したkonnoさんならバグのなさそうなコードを５つは
> 書き上げられそう、という見積もりをしたのですよ。
> つまり、それだけアウトプットの質・量が向上すると、私を始めみんながうれしい、
> ということ。つまるところ、私利私欲なわけですよ。

そ、そんなこと言われたって木に登ったりなんかしないんだからね！ (^^;

> あるいは、先日BASICのコードを公開されたように、今後はオープンソースの方向に
> 舵を切っていく、とか。

私はあくまで個人的な趣味でやっているので、その辺は変わらないかもしれないです。

> > CALENDAR.DEF　Yushi さんのモノクロ版カレンダー拡張wanama版は
> ……を見て，そう言えば令和対応ってどうなってたっけ？と思ったら何処にも
> 情報が出ていなかったので，野ざらし言#5481 に使用中のを貼り付けておきました。

めざらさん、ありがとうございます。
うちの BASIC カレンダーも2月23日が平日のままだったので、データを更新しました。

02/23 2024-2099 天皇誕生日  (令和天皇)

> 機能は変わらずデータ追加だけなので版に変更はありませんが，
> 何か識別子がないと紛らわしいため v1.08wm と仮表示してあります。

結構修正箇所が多いのですね、これはもう VerUP レベルですね。

> 和生師匠は元気にしてますかねぇ……
> ……と言うことがあまり現実的でないことは承知しています。

みなさん音沙汰がないので、卒業されたのならいいのですが。
私は Emmett さんの LXCLND.DEF を愛用しているので、Vector の VZマクロ関連を覗いてみました。
私の VZk07p 2005年 のが最新になっていました。(^^;
うーん、まだパスワード更新出来るなら、新しい版と入れ替えようかな。
うちのホームページのURLももう繋がっていないので、リンクを新しくしないと。(^^;

> お便りくらいは出してもばちは当たらないですよね。……暖かくなったら……

ぜひともよろしくお願いします。m(__)m

MS-DOS Player が立て続けに更新されていました。
http://takeda-toshiya.my.coocan.jp/msdos/index.html

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

2024/2/19
strcpy_s()で、指定したバッファ長よりも長い文字列をコピー元として指定したときに、
例外0xc0000417が発生することがあるようです。
ひとまずstrncpyで処理をするように対策をいれました。

2024/2/18
cracyc様のforkから、更に修正を取り込ませていただきました。
INT 67h, AX=5B00h/5B01h/5B04hについて、BHに00h以外を指定したときにエラーを返すようにしました。
MDA（Monochrome Display Adopter）をサポートしました。
その代わりに、コンベンショナルメモリの上限がB8000hからB0000hとなり、32KBだけ減少しています。
（それでも、VGAのVRAMがない分だけ、通常の環境より64KB大きいのですが）
CRTC, Status Registerも、MDAのアドレスでアクセス出来るようにしたのと、同期信号を50Hzにしました。

2024/2/15
cracyc様とroytam様のforkから、修正を取り込ませていただきました。
FCBを使ったファイルアクセスと、MAME版i386コアのFPU周りの例外の修正などです。
また、MAME版i386コアのDAA/DAS/AAA/AAS/AAM/AAD命令を、DOSBoxの実装を基に修正しました。
Pentium4版で、testi386.exeが実機と同じ結果が得られるようになっています。

NP21/WのI386コアを、ver0.86 rev92 beta2相当に更新しました。
また、ビルド時のワーニングが出ないように修正しました。

環境変数のアクセス時に、正しくない環境テーブルを参照したときのチェックを強化しました。
最近のビルドでtesti386.exeが動かなくなっていた問題が解決しています。
メモリアクセスの処理を効率化しました。
基本メモリ、拡張メモリ、予約領域（VRAMなど）の順に、少ない条件分岐でアクセスできるようにしています。
微妙に処理速度が上がっているかもしれません。

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

主にメモリやCPU関係の修正のようです。
処理速度が上がっていたらうれしいですね。
作者様に感謝します。

TurboBasicで素数を表示、カウントするテストプログラムを作りました。
DOSVAXJ3 や MS-DOS Player の JP モードで動きます。

自己流で考えて作ったので間違いがある可能性はあります。
指定範囲は２０から １０万まです。配列数や時間的な限界がこの辺ということで。
一応、1000 までは 合っていました。

Wikipediaを見ると
--------------------------------------------------------------------------
最も素朴な方法は、2 から √n 以下の素数まで順番に割っていく、試し割り法と呼ばれる方法である。
n が √n 以下の全ての素数で割り切れなければ n は素数である。
試し割り法は、n が大きくなるに従って、急速に速度が低下するため、実用的ではない。
--------------------------------------------------------------------------

私が考えた方法は、どうやらこの方法と同じようですね。
１万を超えると急速に速度が落ちて、１０万くらいが限界のようなので。(^^;


　 SOSU4.EXE Ver.240220

・DOSVAXJ3 の VGAで動く 素数表示テストです。
・DOSVAXJ3 を起動したら、chev jp でVGAモードにして、SOSU4.EXE を起動してください。
・MS-DOS Player では、chej jp でVGAモードにすれば動作します。
・VTDOS では動作しません。
・ソースも付けます。
・1000までは合っていると思いますが、それ以上は保証できないので表示しません。
・1000を超えたら 数字や時間情報を SOSU.DAT に追加出力します。
・数字が大きくなると急速に速度が落ちるので、初めは 100くらいから始めてください。

・更新履歴
2024-02-20 公開用に色々弄りました。
2024-02-17 とりあえず作成？

　動作保証はでき無いので実行は自己責任で。　　

自作、改作アプリの放置部屋に置きました。
http://tamaneko.world.coocan.jp/execom.htm

ハノイの塔マクロ HANOI.DEF を改造しました。
オリジナルは、T.Tanomura さんの名作です。作者様に感謝です。


===== hanoi_k.def ハノイの塔 =====

; ハノイの塔マクロ HANOI.DEF
; （VZ Editor version 1.5/1.6 共通）
; (C) T.Tanomura, 1992/7/5, 1994/7/31
;   h.konno 2024-02-22  円盤の枚数 1〜15 に改造、速度アップ


【機能】
　ハノイの塔の問題を解きます。

【用法】
　編集モードで起動し、円盤の枚数として 1〜15 の数を入力してください。
ハノイの塔の問題を知らない方は、最初は 3 にするといいでしょう。

【補足】
　'Q' を押すと、中止になります。★##k
　'G'（＝go）を押すと、残りの移動を一気に行います。
　マクロの連続実行を中止するには [ESC] を押せば止まります。★##k
　マクロを中断したり実行後おかしくなったらオプション初期化してください。
　改造して速度が倍近く上がっています。（当社比）★

下のリンクをクリックすると hanoi_k.def のソースが表示されます。
当社の新リンク機能です。(^_^)

#txt:hanoi_k.def 

BBSのオートリンク機能を応用して新リンク機能が出来ました。(^_^)
#11098 で使っています。

ソースは、wforum.cgi の最後の方

#--------------#
#  自動リンク  #
#--------------#
sub auto_link {

#	#txt:FILE  text macro doc etc
	$_[0] =~ s/(^|[\x81-\x9F\xE0-\xFC][\x40-\x7E\x80-\xFC]|[^0-9a-zA-Z\/\#\"]+)#txt:([A-Za-z0-9_-]+\.[A-Za-z0-9]+)/$1<a href='http:\/\/tamaneko.world.coocan.jp\/bbs\/count\/count.cgi?mode=download;target=http:\/\/tamaneko.world.coocan.jp\/vz\/$2' title='Text'>#txt:$2<\/a>/g;

このように、サーバーのフォルダに置いたファイル名を指定すれば $2 の変数に置き換えて表示出来ます。
書式は

#txt:ファイル名

この機能を実現することでいくつかのメリットがあります。

・長いソースファイルも５文字のコマンド＋ファイル名の直リンクで手軽に見ることができる。
・長いソースを張り付けて掲示板の閲覧性を損ねることを防げる。
・長いソースを張り付けてコピペするよりこのリンクを右クリックで即ファイル保存のほうが楽かも。
・長いソースやドキュメント類を見たくない人にも優しい。
・リンク済みのファイルは誰でも記事中に直リンクして手軽に参照できるので便利。
・手持ちのソースやドキュメント類を記事中で参照希望のメール送付等は前向きに検討します。
・オートリンクにカウンタを仕込んであるので閲覧数を確認できる。

この機能を思いついた動機は、上に書いていますが、本当は個人的趣味で不純なので内緒。(^^;

この機能が便利だと思ったらぜひとも他の掲示板でも採用願いたいです。(^^;

> ハノイの塔マクロ HANOI.DEF を改造しました。
> オリジナルは、T.Tanomura さんの名作です。作者様に感謝です。

実行してみました。gコマンドの速度は速いですね。
ただ、画面の表示が正しくないです。何が悪いのかな。
konnoさんのところではきちんと表示されているのでしょうから、私の環境かな。
Tanomuraさんのマクロは、正しく表示されています。

で、まぁ、マクロコードを読もうとしたのですが。
あきらめました。
なぜって、コードとコメントの混在で。
一応、読もうと努力はしたんですよ。
だけど、例えばコードの最初のほう、属性などのいくつかの変数をプッシュする
コードがコメントアウトされていて、でもその理由が明記されているわけでもなし、
明記せずとも暗黙で理解できるようなコードでもなし。
まぁ、コード本体というか内部ではこれらの属性が変更されていないからプッシュ
されていないのだろうな、とは想像できますが、ならばなぜ、わざわざ記載した
上でコメントアウトされているのか、全くの謎。
おそらく、konnoさん的にはこういうコードが理解しやすいのでしょう。
でも、申し訳ない、私は脱落しました。
もっとも、世の中には、いわゆる「汚いコード」というのがいくらでもあって、
そういうのに比べればkonnoさんのコードは、まだまし、といったところでしょう。

実行してみたところ，数回の移動でコマンドラインに降り，最終的に VZ が落ちました。
（「落ちた」は正確ではなく，VZの子プロセスから離脱……かな。戻れず強制終了。）

まず，最初にきれいに積み上がっていないです。

次のコードがあります……
 #E #m #[ &k
……が，実行中にコマンドラインに降りるのは何故なのですか？
ここの意図についてコメントがないので，想像もつきませんが……

> なぜって、コードとコメントの混在で。

（外野の言い訳になってしまうけれど）他の方のプログラムを改造する場合，
わたしも元の行をコメントアウトした上で，改造コードを記載してしまいます。
「ここをこうしたよ」ということを明示しているつもりなんですよね。
そういうのは，プログラミングに慣れた人には嫌われるのでしょうか。

田野村さんはタブを使わず4字下げだったので，それをそのまま行にコメントすると，
字下げが4の倍数にならずにグチャグチャした印象を与えてしまいますね。

> 属性などのいくつかの変数をプッシュするコードがコメントアウトされていて、
> でもその理由が明記されているわけでもなし、

グローバル変数のプッシュ／ポップの辻褄を合わせる努力をするよりも，
ローカル変数にしてしまえば他に影響はないという考え方なのでしょう。

ただ，はっきり言ってしまうと，典型的な「スパゲティ」になっているコードを
改善する気がない表明とも受け取られかねないわけで，見た目の印象以上に
コードを追う気力を失わせることはままあることかもしれないと思います。(自省)

上記は，自分への反省とか注意喚起という意味あいの方が強いかもしれません。

それより，わたしがちょっと引いたのは，
「マクロを中断したり実行後おかしくなったらオプション初期化してください。」
かな。

中断が予想される場合は，その処理を入れておくのがふつうかなと思います。
（まぁ，&k で拾う場合は終了処理が無理なことも多いんですけどね。）

> 実行してみました。gコマンドの速度は速いですね。
> ただ、画面の表示が正しくないです。何が悪いのかな。
> konnoさんのところではきちんと表示されているのでしょうから、私の環境かな。

試していただきありがとうございます。
画面表示は具体的にはどんな感じになるのでしょうか。

> Tanomuraさんのマクロは、正しく表示されています。

Tanomuraさんのマクロの回数の数字だけ増やしても80*25画面で平気で動作しますね。
環境に左右されないようしっかり作られているのは流石です。

> で、まぁ、マクロコードを読もうとしたのですが。
> あきらめました。
> なぜって、コードとコメントの混在で。

す、すみません、公開するなら修正前の不要なコメントは消すべきでしたね。
修正して差し替えます。m(__)m

> 実行してみたところ，数回の移動でコマンドラインに降り，最終的に VZ が落ちました。
> （「落ちた」は正確ではなく，VZの子プロセスから離脱……かな。戻れず強制終了。）

げげ、これはヤバいですね、オプション絡みでしょうか。
スタートして直ぐと終了時に時間計測のためにコマンドラインに降りていますが
移動中は関係ないし、もしかして EP かなぁ。
時間計測部分はコメントにします。

> まず，最初にきれいに積み上がっていないです。
オリジナルで問題無いなら何かのオプションの影響ではないかと思いますが・・・

>  #E #m #[ &k
> ……が，実行中にコマンドラインに降りるのは何故なのですか？
> ここの意図についてコメントがないので，想像もつきませんが……

上に書いたように時間計測のために追加したのをそのままにしていました。
プロンプトを $t$p$g にして時間表示させ、マクロの実行時間を測定しています。
これが悪さをしている可能性があるのでこの部分はコメントにします。
不完全なままアップしてすみませんでした。m(__)m

めざらさんのところでも同じようですが、うちも最初が正しく積みあがっていません。

> わたしも元の行をコメントアウトした上で，改造コードを記載してしまいます。
> 「ここをこうしたよ」ということを明示しているつもりなんですよね。
> そういうのは，プログラミングに慣れた人には嫌われるのでしょうか。

コメントアウトされているのが全て改造前、ということがわかれば私はOKです。
それでも見づらいことは見づらいので、プログラミングに慣れた多くの人は嫌う
かもしれない。
概ね、プログラミングの世界では、例えばバグの混入を避けるなどの目的で、可読性
というものが重視されます。これもある種の理想論なんで、現実にはメモリ量とか
速度とかを目的として最適化というものも行われますが、でも最適化は最後の段階。
実際、遅いのはアルゴリズムが悪いことが多いので、アルゴリズムの見直しを行い、
それでも所要の性能が出ない場合に最適化する、というのが通常の段取り。

そういう潮流なので、コードが読みやすいことが尊ばれるのですよ。
ある種、読みやすさは正義、みたいな。
そして、読みやすくするためにはどうするか、という様々な研究もあって。
その中に、余分な情報は少なければ少ないほうが良い、というのもあります。
余分な情報は正しい認識を阻害する、ということから、私は迷彩という表現を使って
います。そして、このコードは何をする、というコメントなら多くの場合問題はない
のですが、旧のコードと新のコードが並列されていて、単にコメントアウトされて
いるだけ、という場合、混乱を招きやすいのではないかなぁ。
だって、行の途中を読んでいて、その行がコメントであるか確認するために行の先頭
に視線を戻して、という手間が発生するので、少なくとも私には心理的負担。

あるいは、例えばウィルスなんかだと「コードの難読化」なんていう技術が使われて
いたりします。つまり、わざと読みづらくすることにより、どういう挙動を示すか
わからないようにしているのですが、だから一部の口の悪いプロのプログラマーは
「そんなウィルスのようなコードを書くな」
などと後輩に指導して、もはやこの表現はパワハラ案件だという冗談もあるくらい。

> > 属性などのいくつかの変数をプッシュするコードがコメントアウトされていて、
> > でもその理由が明記されているわけでもなし、
> グローバル変数のプッシュ／ポップの辻褄を合わせる努力をするよりも，
> ローカル変数にしてしまえば他に影響はないという考え方なのでしょう。

すごい、きちんと読まれたのですね。
もう私、プッシュポップをしていないということは、これらは内部では使われて
いないんだ、というところでそれ以上読むことをあきらめていました。

> それより，わたしがちょっと引いたのは，
> 「マクロを中断したり実行後おかしくなったらオプション初期化してください。」
> かな。

私は逆というか、この表現を見た瞬間、画期的だと思いました。
積極的にオプションを初期化するって発想がなかったもので。
でも、過去の多くのコードを見てきためざらさんがそういう反応をするということ
は、これはいわゆるマクロ師的には邪道なのかもしれませんね。

まず、うちの環境では、めざらさんのところと違い、落ちたことは一度もありません。

> 画面表示は具体的にはどんな感じになるのでしょうか。

円盤が３枚のときの初期画面。（右側省略）

■
             ■■
■■■
 ~~~~~~~~~~~~~~~~~~~

円盤が３枚のときのgコマンドでの終了画面。（右端まで）

■  ■
                                                             ■■
■■■■■■      ■■■
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

円盤の表示位置が正しくないようですが、空白での上書き消去は正しく行えているので
ゴミが残っている、というようにも見えます。

> （外野の言い訳になってしまうけれど）他の方のプログラムを改造する場合，
> わたしも元の行をコメントアウトした上で，改造コードを記載してしまいます。
> 「ここをこうしたよ」ということを明示しているつもりなんですよね。

そのとおりなんですが、私の場合統一性が無く文字通りぐちゃぐちゃになってました。
流石にこのままアップしたのは不味かったですね。m(__)m

> 田野村さんはタブを使わず4字下げだったので，それをそのまま行にコメントすると，
> 字下げが4の倍数にならずにグチャグチャした印象を与えてしまいますね。

これは公開を考えたら統一するべきでしたね、修正します。m(__)m

> > 属性などのいくつかの変数をプッシュするコードがコメントアウトされていて、
> > でもその理由が明記されているわけでもなし、

修正前のコードをコメントして残すなら理由を明記するべきでしたね。

> グローバル変数のプッシュ／ポップの辻褄を合わせる努力をするよりも，
> ローカル変数にしてしまえば他に影響はないという考え方なのでしょう。

そのとおりですが、実際には不具合が出たようで、難しいですね。

> ただ，はっきり言ってしまうと，典型的な「スパゲティ」になっているコードを
> 改善する気がない表明とも受け取られかねないわけで，見た目の印象以上に
> コードを追う気力を失わせることはままあることかもしれないと思います。(自省)

m(__)m  m(__)m  m(__)m

> それより，わたしがちょっと引いたのは，
> 「マクロを中断したり実行後おかしくなったらオプション初期化してください。」
> かな。
> 中断が予想される場合は，その処理を入れておくのがふつうかなと思います。

中断とは、マクロを Ctrl Break などで強制的に止めるという意味だったのですが
このマクロは止まらないみたいですね。
なので、中止のコードを追加したのですが、そうするとプッシュポップの辻褄が合わなくなります。
変なところにポップしてメモリを壊すよりは変数保存のプッシュポップをやめるのがいいかと。
プッシュポップの辻褄が合わなくてもマクロを終了したら SP は初期化するかな。
と思ったのです。

不要なコメントを整理してコードも見直しますのでしばしお待ちください。m(__)m

> > 画面表示は具体的にはどんな感じになるのでしょうか。
> 
> 円盤の表示位置が正しくないようですが、空白での上書き消去は正しく行えているので
> ゴミが残っている、というようにも見えます。

げげ、これはひどいバグですね。すみませんでした。m(__)m
80*25の画面でスペースがはみ出てしまってますね。
途中で数値変更して確認していませんでした。お恥ずかしい。m(__)m

諸々修正して再アップします。しばしお待ちください。m(__)m

ハノイの塔マクロ HANOI.DEF 改造の差し替え版です。
オリジナルは、T.Tanomura さんの名作です。作者様に感謝です。

バグバグの物を上げてしまいすみませんでした。m(__)m
コメントも整理しました。
これでめざらさんのところで問題なく動きますように。(-人-)


下のリンクをクリックすると hanoi_k.def 差替え版のソースが表示されます。

#txt:hanoi_k.def 

ふつうに実行できました。

結局，何が問題だったのか分からないままでしたが……

> ふつうに実行できました。
> 結局，何が問題だったのか分からないままでしたが……

問題なさそうで、ホッとしました。(^^;
コマンドラインに降りたのがまずかったと思い、EP0 にしたくらいですが
多分違いますよね。(^^;
ともあれ良かったです。(^_^)

いや、ほとんどT/Oで申し訳ない。
酔ってるもんで。

> いや、ほとんどT/Oで申し訳ない。
> 酔ってるもんで。

あ、全然気が付きませんでした。(^^;

おめでとうございます。（って、自分に言うか）

> ハノイの塔マクロ HANOI.DEF 改造の差し替え版です。

やっと試すことができました。
きれいに動いています。
ただ、うちでは、マシンのせいなのか、konnoさんのところほどTanomura版との差は
大きくなっていません。１２枚で、Tanomura版だと４５秒強、konno版だと３５秒弱、
といったところです。
なお、実行したのはVTDOS、画面サイズは横８０桁、縦５０行です。
でも、konnoさんのところでは、画面サイズで実行速度が変わる、というのは面白い
ですね。速度が画面サイズに依存しないようにする、という改造もいいかも。

> TurboBasicで素数を表示、カウントするテストプログラムを作りました。

中身を見させていただきました。
どうも解せない部分がいくつか。
冒頭、「DEFINT A-Z」と宣言されています。
これはいわば、ある意味お約束のようなものかもしれません。
でも、実際にコードの中で使っている変数は、整数の範囲外までサポートするため
実数型。だもので、いちいち実数指定の「!」が必要になっています。
これ、冒頭の整数宣言を外してしまったほうがよくありませんか？
コード全体をざっくり見た範囲で、整数型の変数は末尾の時間計測ルーチンで使って
いる変数ぐらい。なら、こちらのほうに整数指定をするほうがいいような。

で、尻尾から見ていって。
9050行、もしIERLが10000より大きければ、THENそのとき10000となっていますが、
THEN直後の数値はその行番号へのジャンプ。でも10000行ってないのですが、これで
いいのですか？
って、これ、コメント文になっているぅ〜！
またぞろ、konnoさんお得意の迷彩にやられちまったぜ。

9030行、「RESUME 9032」となっていますが、RESUME文て指定した行番号に処理を
飛ばす、という挙動だったはず。この処理系ではその他の副作用があるかもしれない
のですが、このステートメント、本当に必要ですか？
あ、ERRとERLがクリアされてしまうとかあるのかな。
であってもなくても、わざわざIERRとIERLに代入せず、そのまま表示してしまえば
余分な変数も使わずに済むし、コードはよりシンプルになる気がする。
ま、私のような処理系の挙動を把握していない人向けのコメントは不要として、
処理系の挙動を知っている人ですら疑問を抱きそうな部分にはきちんとコメントを
つけたほうが言いと思う。

と、言うところで、根性と時間がつきました。
今日のところはそんなところで。

> やっと試すことができました。
> きれいに動いています。

無事に動いたようでなによりです。(^_^)

> ただ、うちでは、マシンのせいなのか、konnoさんのところほどTanomura版との差は
> 大きくなっていません。１２枚で、Tanomura版だと４５秒強、konno版だと３５秒弱、
> といったところです。
> なお、実行したのはVTDOS、画面サイズは横８０桁、縦５０行です。

うーむ、差が少ないのは気になるところですね。私の各種環境で比較してみました。

VTDOS　　　　　　　org　 69秒
VTDOS　　　　　　　kon　 33秒
CKWV+VTDOS　　　　 org　 63秒　　80*25
CKWV+VTDOS　　　　 org　 69秒　　136*34
CKWV+VTDOS　　　　 kon　 33秒　　80*25
CKWV+VTDOS　　　　 kon　 36秒　　136*34
DOSVAXJ3 64　　　　org　 70秒
DOSVAXJ3 64　　　　kon　 34秒
M Player pen4_x64　org　171秒
M Player pen4_x64　kon　 71秒

ckwv のが時間が掛かると思いましたがそうでもないですね。

> でも、konnoさんのところでは、画面サイズで実行速度が変わる、というのは面白い
> ですね。速度が画面サイズに依存しないようにする、という改造もいいかも。

移動のたびに &d で全画面表示しているので大画面の方が不利かと思いましたが
オリジナルでも大画面の方が遅いですね。
MS-DOS Player は画面表示が遅いのかな、また検証してみます。

> 冒頭、「DEFINT A-Z」と宣言されています。
> これはいわば、ある意味お約束のようなものかもしれません。
> でも、実際にコードの中で使っている変数は、整数の範囲外までサポートするため
> 実数型。だもので、いちいち実数指定の「!」が必要になっています。
> これ、冒頭の整数宣言を外してしまったほうがよくありませんか？
> コード全体をざっくり見た範囲で、整数型の変数は末尾の時間計測ルーチンで使って
> いる変数ぐらい。なら、こちらのほうに整数指定をするほうがいいような。

全くその通りです、手抜きのために既存のルーチンを stime などから寄せ集めたもので。
冒頭の「DEFINT A-Z」も、
 ON ERROR GOTO 9000:DEFINT A-Z
このように、エラールーチンにくっ付いていたのをそのままにしていたのでした。

> 9050行、もしIERLが10000より大きければ、THENそのとき10000となっていますが、
> THEN直後の数値はその行番号へのジャンプ。でも10000行ってないのですが、これで
> いいのですか？
> って、これ、コメント文になっているぅ〜！
> またぞろ、konnoさんお得意の迷彩にやられちまったぜ。

これも同じで、エラー処理が無いといきなり終了するので、とりあえず張り付けたのでした。
としきさんは、TAGLIGHT.EXE はお使いではないですか。
コメントなどが色分けされて非常に見やすくなります。って言い訳。

> 9030行、「RESUME 9032」となっていますが、RESUME文て指定した行番号に処理を
> 飛ばす、という挙動だったはず。この処理系ではその他の副作用があるかもしれない
> のですが、このステートメント、本当に必要ですか？
> あ、ERRとERLがクリアされてしまうとかあるのかな。
> であってもなくても、わざわざIERRとIERLに代入せず、そのまま表示してしまえば
> 余分な変数も使わずに済むし、コードはよりシンプルになる気がする。
> ま、私のような処理系の挙動を把握していない人向けのコメントは不要として、
> 処理系の挙動を知っている人ですら疑問を抱きそうな部分にはきちんとコメントを
> つけたほうが言いと思う。

これも同じ手抜きで、以下同文。m(__)m

MS-DOS Player の更新でメモリ関連が速くなったかもしれないので、
素数計算 SOSU4 で、各CPUのエミュレーション速度を計測してみました。


23-12-14版                      24-02-19版
PC1  MS-DOS Player 231214       PC1  MS-DOS Player 240219   
                                                            
ia32_x64                        ia32_x64                    
Number = 10000      0: 0' 3     Number = 10000     0: 0' 2  
Number = 20000      0: 0' 9     Number = 20000     0: 0' 6  
                                                            
                                pentium4_x64                
  無し                          Number = 10000     0: 0' 5  
                                Number = 20000     0: 0'14  
                                                            
i486_x64                        i486_x64                    
Number = 10000      0: 0' 4     Number = 10000     0: 0' 2  
Number = 20000      0: 0'14     Number = 20000     0: 0'14  
                                                            
i386_x64                        i386_x64                    
Number = 10000      0: 1'40     Number = 10000     0: 1'39  
Number = 20000      0: 5'31     Number = 20000     0: 5'27  
                                                            
i286_x64                        i286_x64                    
Number = 10000      0: 0'45     Number = 10000     0: 0'50  
Number = 20000      0: 2'29     Number = 20000     0: 2'42  
                                                            
v30_x64                         v30_x64                     
Number = 10000      0: 0'43     Number = 10000      0: 0'45 
Number = 20000      0: 2'21     Number = 20000      0: 2'30 
                                                            
ia32_x86                        ia32_x86                    
Number = 10000      0: 0' 3     Number = 10000      0: 0' 3 
Number = 20000      0: 0' 9     Number = 20000      0: 0' 9 
                                                            
                                pentium4_x86                
  無し                          Number = 10000      0: 0' 6 
                                Number = 20000      0: 0'20 
                                                            
i486_x86                        i486_x86                    
Number = 10000      0: 0' 6     Number = 10000      0: 0' 6 
Number = 20000      0: 0'18     Number = 20000      0: 0'18 
                                                            
i386_x86                        i386_x86                    
Number = 10000      0: 2' 4     Number = 10000      0: 2'13 
Number = 20000      0: 6'51     Number = 20000      0: 7'22 
                                                            
i286_x86                        i286_x86                    
Number = 10000      0: 0'47     Number = 10000      0: 0'56 
Number = 20000      0: 2'33     Number = 20000      0: 3' 6 
                                                            
v30_x86                         v30_x86                     
Number = 10000      0: 0'36     Number = 10000      0: 0'45 
Number = 20000      0: 2' 2     Number = 20000      0: 2'28 
                                

こうしてみると、新しい版が少し速くなっているようですね。
でも i286 以下では逆に旧版より遅くなっているような。
計算式のアルゴリズムとの相性もあるかもです。
私が間違えてる可能性もあります。

i386 以下は CPU エミュレーション率が高いのか、遅くなっていますが
特に i386 が突出して遅いのが気になります。

CPUエミュレーションのルーチンはいくつか種類があると思いますが、
速さより正確さを優先した結果ということでしょうか。
うーん、この結果を武田さんに送ってみようかなぁ。

新しい版の ia32_x64 がメモリ速度では良さそうですね。
みなさん、CPUを選ぶときはこの表も参考にしてね。

私のようなずぼらと違って、konnoさんはまめな人なのか。
私の場合、何回も登場する実数型変数にいちいち型指定の接尾辞をつけるくらいで
あれば、何とかしてそれを省略できる方法を考えたりするわけですよ。打鍵数の節約
を含めて。そして、DEFINTの型指定範囲をどうにかできないか、というのが最初の
候補になる。
あるいは、konnoさんは昔の遅いインタプリタ時代のBASICに苦しめられた経験が
少ない、とか。
少しでも速度を稼ごうと思ったら、ループの中で多用される変数を整数型にする、
というのは基本として、もし実数型不可避となったら、短い変数名にしたり、とか、
いちいち型指定の接尾辞をつけずに済ませようとしたり、とか考えるわけです。
今回のコンパイラでは大丈夫、と読みきってそうしているのであれば、私の言って
いることは余計なお世話なので、大変申し訳ない。

手抜きというか楽をするために既存のルーチンをかき集める、というのは私もよく
やるし正しい行いだとは思いますが、でも、寄せ集めのそれらのルーチンがそれぞれ
何をやっているか把握しないでただくっつけるだけだと、しつこく取れないバグの
巣窟になることが多い。それはあとからボディブローのように効いてきて、トータル
では全く楽にならない、むしろ複雑になる、というのが非常によくある結末。
やっぱりkonnoさん、深層心理では楽をすることを嫌っているとしか思えない。
私のように、骨の髄まで楽をする事を考える人間とは大違い。
あるいは、バグが取れたという結果よりもバグ取りという過程のほうが好き、とか。
世間一般の多くのプログラマは、コーディングが楽しいとか完成してきちんと動いた
ときに満足感を感じる、という人のほうが多いらしいし、私もそうなのですが、何が
楽しいかなんていうのは当然ながら人それぞれ。
いつまでたっても動かないプログラムを永遠にデバッグしているのが楽しい、という
人がいたっておかしくないし、実際にkonnoさんのコードを見ると、konnoさんは
そういうタイプに見える。
プログラムが簡単に完成したらつまらないんでしょう。

TAGLIGHTは、HTMLの編集が楽になりそうなんで気にはなっているんですけどね。
色物はあんまり好きではないんですが、導入したほうがいいかなぁ。
でも、最終的なプログラムコードは、そういうものに依存するべきではないと思う。
ま、これは私の個人的な意見なんで、異論は認める。
私、昔はBASICだったし、あるいはポケ３でコードを組んでいたこともあって、白黒
がデフォルト。紙とペンでコーディングするときも、せいぜい赤ペン止まり。
プロのプログラマだと、紙とペンでコーディングする場合でも多色のマーカーを
使っていた、なんていう話は聞いたことがあります。
だから、以下のような替え歌ができたんだ、そうです。

　胸につけてるマーカーで修正
　自慢のデバッガでバグを撃つ
　派遣の会社から僕らのために
　来たぞ我らのプログラマー

２０年とか３０年前に聞いた歌詞なんで、もはやうろ覚え。
元歌に沿って、替え歌のほうも３番とか４番まであったはず。
上記の１番も、１行目はたぶん間違いないと思うけど、２行目以降はかなり妖しい。
だからなんだ、という話ですが。

TurboBasicで素数を表示、カウントするプログラム SOSU5 に更新しました。
DOSVAXJ3 や MS-DOS Player の JP モードで動きます。

自己流で考えて作ったので間違いがある可能性はあります。
指定範囲は２０から ３０万まです。配列数や時間的な限界がこの辺ということで。
一応、300000 までは 合っていると思います。

今回指定数を3倍までにし、速度アップもしました。
起動時オプションで動作変更できます。


SOSU5.ZIP　サイズ 30297bytes　 24-02-27 new!

　 SOSU5.EXE Ver.240227

・DOSVAXJ3 の VGAで動く 素数表示テストです。
・DOSVAXJ3 を起動したら、chev jp でVGAモードにして、SOSU4.EXE を起動してください。
・MS-DOS Player では、chej jp でVGAモードにすれば動作します。
・VTDOS では動作しません。
・ソースも付けます。
・300000までは合っていると思いますが時間が掛かりすぎるので注意。
・数字や時間情報を SOSU.DAT に追加出力します。
・起動時オプション 1 で S000.DAT に素数を出力します。
・起動時オプション 2 で 表示もファイル出力もしません。カウントのみ。
・数字が大きくなると急速に速度が落ちるので、初めは 100くらいから始めてください。

・更新履歴
2024-02-27　V5　バグ取りや速度アップやファイル出力など。
2024-02-20　V4　公開用に色々弄りました。
2024-02-17　V1　とりあえず作成？

　動作保証はでき無いので実行は自己責任で。　　

http://tamaneko.world.coocan.jp/execom.htm

> 私のようなずぼらと違って、konnoさんはまめな人なのか。

逆に私はずぼらで、としきさんはマメな人だと思っていました。

> 私の場合、何回も登場する実数型変数にいちいち型指定の接尾辞をつけるくらいで
> あれば、何とかしてそれを省略できる方法を考えたりするわけですよ。打鍵数の節約
> を含めて。そして、DEFINTの型指定範囲をどうにかできないか、というのが最初の
> 候補になる。

昔は私もそういうことを考えていた気がします。今は劣化して考えられなくなっただけかも。

> あるいは、konnoさんは昔の遅いインタプリタ時代のBASICに苦しめられた経験が
> 少ない、とか。

としきさんには私はそう見えるわけですね。
私は私なりに遅いインタプリタでいかに処理速度を上げるかで必死だったんですけどね。
そのために「スーパーBASIC」という本を買って、色々参考にした覚えがあります。

> 少しでも速度を稼ごうと思ったら、ループの中で多用される変数を整数型にする、
> というのは基本として、もし実数型不可避となったら、短い変数名にしたり、とか、
> いちいち型指定の接尾辞をつけずに済ませようとしたり、とか考えるわけです。

昔はそういう考えが基本的にあったと思います。今は何も考えていないですね。(^^;

> 今回のコンパイラでは大丈夫、と読みきってそうしているのであれば、私の言って
> いることは余計なお世話なので、大変申し訳ない。

コンパイラになって、変数名の長さとか関係なくなってあまり気にしなくなったのはあります。

> 何をやっているか把握しないでただくっつけるだけだと、しつこく取れないバグの
> 巣窟になることが多い。それはあとからボディブローのように効いてきて、トータル
> では全く楽にならない、むしろ複雑になる、というのが非常によくある結末。

確かにその通りですが、私はとりあえず動くのを優先に考えてしまう癖があるようです。

> やっぱりkonnoさん、深層心理では楽をすることを嫌っているとしか思えない。

これは無いと思いますが、そう見えるのですか。

> 私のように、骨の髄まで楽をする事を考える人間とは大違い。

私にはそうは見えなかったり、考え方が人それぞれなゆえですかね。

> あるいは、バグが取れたという結果よりもバグ取りという過程のほうが好き、とか。

私はバグが無い方がいいし、バグ取りは基本嫌です。

> いつまでたっても動かないプログラムを永遠にデバッグしているのが楽しい、という
> 人がいたっておかしくないし、実際にkonnoさんのコードを見ると、konnoさんは
> そういうタイプに見える。

見え方は人それぞれですから、しかたがないですね。

> プログラムが簡単に完成したらつまらないんでしょう。

そういう境地になれたらいいなとは思います。絶対になれないので。

> TAGLIGHTは、HTMLの編集が楽になりそうなんで気にはなっているんですけどね。
> 色物はあんまり好きではないんですが、導入したほうがいいかなぁ。

Windowsの高機能エデイタは大抵色分け機能を持っていますね。
そういうのを使ってみたいとは思うのですが、VZの使い勝手は別格と思うので。

> だから、以下のような替え歌ができたんだ、そうです。

替え歌がさくっと出来るのもクリエイターならではですね。(^_^)

コードからにじみ出てくる人柄なんて当てにならない、というのが結論でしょうか。

> 逆に私はずぼらで、としきさんはマメな人だと思っていました。

この辺は相対的なものもありますがね。
親戚一同から学生時代の友人、会社での知り合いにいたるまで、他人からの評価
では、世間一般の平均からすると私はずぼらの範疇に入るらしい。マスコミなんか
の報道やネットニュースを参照することによる自己評価でも、やっぱり私はずぼら
だと思っています。
うちの父はマメな人でしたが、うちの母は
「うちの子供たちはみんな私の血を継いだ」
なんていっていて、自分でもそのとおりだと思っています。

> 昔は私もそういうことを考えていた気がします。今は劣化して考えられなくなっただけかも。

> 昔はそういう考えが基本的にあったと思います。今は何も考えていないですね。(^^;

もしかしたら、この辺がキモなのかも。
私も、最近になってプログラミングのスタイルが変わったというところはありません
けどね。かつては、特にインデントの桁数で、いろいろと変遷があったはず。
昔、N88-BASICでは、タブ幅が８桁固定で、さすがにこれは下げすぎだと思い、面倒
だったけど、空白３桁のインデントで、一生懸命スペースバーを叩いていた。
学生時代、PascalはTurboPascalと大学の大型機を使ったけど、両方でソースを統一
したくて、確かインデントは６桁。
その後、TurboCとVisualCの統合環境では、何桁だったかなぁ。
とくに、VisualCに触れたことって、ほとんど一瞬のようなものだったし。
両方とも、確か４桁だったと思うけど、全く自信なし。
その後すぐにVzに触れて、拡張子ごとにタブを４桁と８桁に設定できるようになって、
今ではこれなしにはいられない。

> 確かにその通りですが、私はとりあえず動くのを優先に考えてしまう癖があるようです。

あ〜、なんとなくわかるような。
なんと言えばいいかな。
私の場合は「長期的ずぼら」とか「ライフサイクルずぼら」。
konnoさんの場合は「近視眼的ずぼら」。
なので、konnoさん、トータルでの労力がかえって増えてしまうと思う。

SOSU5 の速度アップとバグ取りですが、他の素数計算プログラムを参考にしました。
旧版は、一桁の素数を決め打ちでやっていました。

for i!=2 to 10
  if i!=2 then gosub print1:co!=co!+1:co1%(co!)=i!
  if i!=3 then gosub print1:co!=co!+1:co1%(co!)=i!
  if i!=5 then gosub print1:co!=co!+1:co1%(co!)=i!
  if i!=7 then gosub print1:co!=co!+1:co1%(co!)=i!
next i!

これを全部コメントにして、２だけ決め打ちにしました。
さらに、偶数チェックを FOR STEP 2 で出来ることがわかり、以下のように

i!=2:gosub print1 :co!=co!+1:co1%(co!)=i!		'★ 2は素数に決め打ち
a!=0
for i!=3 to no!-1 step 2				'★ 偶数をスキップ
loop1:
'  no1$=str$(i!)					'★ FOR steo 2 の
'  le=len(no1$)						'★スキップにより
'  a!=val(right$(no1$,1))				'★この4行が
'  b!=int (a!/2):if b!=a!/2 then i!=i!+1:goto loop1	'★要らなくなった
  gosub loop2		'
next i!

これで少し速度アップ出来たようです。

SOSU4.EXE
Number = 50000 	  0: 0'34 	Prime Number = 5133 
SOSU5.EXE
Number.50000	  0: 0'32 	Prime Number = 5133 

うーん、誤差範囲かな。(^^;
あとは配列の見直しで、10万までだったのを30万まで拡大出来ました。
速度的にも

Number.300000	  0:12'20   Prime Number = 25997 

12分もかかるので、この方式はこの辺が限界ですね。(^^;
さて、次はもっと速い別のアルゴリズムにしましょう。

MS-DOS Player がまた更新されていました。
http://takeda-toshiya.my.coocan.jp/msdos/index.html

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

2024/2/28
INT 21h, AX=4404h/4405h/440Ahを修正しました。
BXでハンドルを指定するか、BLでドライブを指定するか、間違えて処理していました。
AX=440Ahはハンドル指定、AX=4404h/4405hはドライブ指定に修正しています。

内蔵デバッガを改良しました。
プロテクトモード時のコードページの処理を修正しました。
また実行トレースに、各命令を16bit/32bitのどちらで実行したか記録するようにしました。
（V30の場合は8080モードか否かを記録）
Uコマンド、UTコマンドで正しく命令を表示できるようになっているかと思います。

roytam様のforkを参考に、conhost-v2のクラッシュ対策を入れました。
カーソルが最後の行にあるときにウィンドウサイズを変更するとクラッシュし易いようです。
また未確認ですが、Windows NT4.0 / 2000で動作するための修正も取り込んでいます。

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

VZにはあまり影響無さそうですが、更新が続いていることに感謝します。

MS-DOS Player の更新で CPU速度の変化が気になったので、
素数計算 SOSU4 で 各CPUのエミュレーション速度計測しました。

23-12-14版                      24-02-19版  24-02-28版
MS-DOS Player 231214            240219      240228
                                         
ia32_x64                        ia32_x64    ia32_x64 
Number = 10000      0: 0' 3     0: 0' 2     0: 0' 3  
Number = 20000      0: 0' 9     0: 0' 6     0: 0'10  
                                         
i486_x64                        i486_x64    i486_x64 
Number = 10000      0: 0' 4     0: 0' 2     0: 0' 5  
Number = 20000      0: 0'14     0: 0'14     0: 0'18  
                                         
i386_x64                        i386_x64    i386_x64 
Number = 10000      0: 1'40     0: 1'39     0: 1'56  
Number = 20000      0: 5'31     0: 5'27  
                                         
i286_x64                        i286_x64    i286_x64 
Number = 10000      0: 0'45     0: 0'50     0: 1' 4  
Number = 20000      0: 2'29     0: 2'42  

最新版の速度計測は手抜きですが、少し遅くなったような気がします。
条件判定などが増えたからでしょうか。

sosu5.bas を読ませてもらっています。
まだ冒頭のほうだけなんですけどね。

で、質問。
配列の確保で
dim co1%(32700)
と宣言されています。
その少しあとで入力プロンプトだと思いますが
  PRINT "Prime Number (20 TO 327000)";
とあったり
    if no!>327000 then inp1
となっているのですが、これはそれぞれ値は正しいのですか？
いや、似たような数値なので、ミスタイプを疑ってみました。
というか、できればこういうのは変数に定義したほうがよろしいかと。
例えば、

max=32700
dim co1%(max)
  PRINT "Prime Number (20 TO "; max*10; ")";
    if no!>max*10 then inp1

みたいなコードになっていれば、いらぬ疑問は招かないかと。
バグの混入も防止できるし。
アセンブラですら数値を定義して名前をつけるという機能があるのに、高級言語の
BASICでそういう機能を使わないのはもったいないと思う。
また、最近のＣ言語なんかでは、文法書に、この手の即値はマジックナンバーであり
使うことは悪い習慣だと書かれてしまっているらしい。そうだろうねぇ。

> 配列の確保で
> dim co1%(32700)  と宣言されています。
> その少しあとで入力プロンプトだと思いますが
>   PRINT "Prime Number (20 TO 327000)";
> とあったり
>     if no!>327000 then inp1
> となっているのですが、これはそれぞれ値は正しいのですか？

正しくはないというか、適当です。(^^;

> いや、似たような数値なので、ミスタイプを疑ってみました。
> というか、できればこういうのは変数に定義したほうがよろしいかと。

配列の数字と入力最大値とは関連はありません、たまたま同じ数値にしただけです。
なので、例題のようには出来ないです。

> バグの混入も防止できるし。
> アセンブラですら数値を定義して名前をつけるという機能があるのに、高級言語の
> BASICでそういう機能を使わないのはもったいないと思う。
> また、最近のＣ言語なんかでは、文法書に、この手の即値はマジックナンバーであり
> 使うことは悪い習慣だと書かれてしまっているらしい。そうだろうねぇ。

ご意見に従い、入力の最大値は max! にしてみました。
なるほど、修正が楽になりますね。
SOSU5 で最終と思っていましたが、修正ついでにもっと限界まで攻めてみました。

dim co1%(32766)			' これ以上は64Kオーバーエラー

  max!=1000000
  PRINT "Prime Number (20 TO ";max!;")";

最大値はもっといけるかもですが、時間的に100万までにしました。(^^;
こんどこそ打ち止めです。(^^;

TurboBasicで素数を表示、カウントするプログラム SOSU5 に更新しました。
DOSVAXJ3 や MS-DOS Player の JP モードで動きます。

自己流で考えて作ったので間違いがある可能性はあります。
指定範囲は２０から １００万まです。配列数や時間的な限界がこの辺ということで。
一応、1000000 までは 合っていると思います。

今回指定数を100万までに拡大しました。
起動時オプションで動作変更できます。


SOSU6.ZIP　サイズ 30299bytes　 24-03-01 new!

　 SOSU6.EXE Ver.240301

・DOSVAXJ3 の VGAで動く 素数表示テストです。
・DOSVAXJ3 を起動したら、chev jp でVGAモードにして、SOSU4.EXE を起動してください。
・MS-DOS Player では、chej jp でVGAモードにすれば動作します。
・VTDOS では動作しません。
・ソースも付けます。
・1000000までは合っていると思いますが時間が掛かりすぎるので注意。
・数字や時間情報を SOSU.DAT に追加出力します。
・起動時オプション 1 で S000.DAT に素数を出力します。
・起動時オプション 2 で 表示もファイル出力もしません。カウントのみ。
・数字が大きくなると急速に速度が落ちるので、初めは 100くらいから始めてください。

・更新履歴
2024-03-01　V6　指定できる最大値を100万までに拡大。
2024-02-27　V5　バグ取りや速度アップやファイル出力など。
2024-02-20　V4　公開用に色々弄りました。
2024-02-17　V1　とりあえず作成？

　動作保証はでき無いので実行は自己責任で。　　
http://tamaneko.world.coocan.jp/execom.htm

> 最大値はもっといけるかもですが、時間的に100万までにしました。(^^;

SOSU6.EXE の実行時間です。

SOSU6.EXE
Number.10000	  0: 0' 2   Prime Number = 1229 
Number.100000	  0: 1'40   Prime Number = 9592 
Number.400000	  0:23'20   Prime Number = 33860 
Number.600000	  0:52'55   Prime Number = 49098 
Number.1000000	  1:52'40   Prime Number = 78498 

これだけ時間が掛かりますが、他の計算プログラムと結果は一致しています。
うっかり計測開始してしまったときは、Ctrl+Break で止まる設定ならあるいは。(^^;
まあ、いざという時は DOSVAXJ3 の窓を閉じればいいんだし。(^^;

MS-DOS Player がまた更新されていました。
http://takeda-toshiya.my.coocan.jp/msdos/index.html

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

2024/3/2
INT 21h AH=43h, BL=08hが、BL=06hと同じ動作になっていた問題を修正しました。

内蔵デバッガを改良しました。
Rコマンドでレジスタ以外にフラグの値の変更もできるようにしました。
また、V30のディスアセンブラを、i386用のディスアセンブラと統合しました。
V30専用命令以外で正しく認識されない命令があったのが解決しています。
レジスタ名も標準的な名前で表示されるようになっています。

conhost-v2のクラッシュ対策の改良と、WindowsNT 3.51/4向けの修正をしています。

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

クラッシュ対策とは、最近のWindowsのIMEの問題などでしょうか。
エミュレータ作者の影の苦労がうかがわれますね。
更新に感謝です。

> TurboBasicで素数を表示、カウントするプログラム SOSU5 に更新しました。

N88-BASICもあらかた忘れ始めているので手元のDISK BASICのリファレンスを見ながら
ですが、TurboBasicはやっぱりかなり違うようです。
上のほうから見ていって、まず気がついたのがLOCATE文。
  LOCATE 1, 26, ,1
というのがありましたが、N88では引数は３つまで。
つまり、カンマの数は２つまででした。
次がCOLOR文。
  COLOR 14, 0
とありますが、N88では最初の引数は0から7までだけでした。
２番目と４番目の引数なら14も使えるようです。

あ、なんか、消し忘れのようなもの見つけてしまった。
a!=0
ってあるんですが、この変数、他では使われていないっぽい。

あ〜、なんか、N88-BASIICに移植したくなってきた。
といっても、動作環境は手元にはない。
実家にはDOS BASICはあるはずだけど、DOS BASICとDISK BASICって何が違っていたか
もう思い出せない。
ちょっと無謀だな。

> どんなチェック漏れがあるやら、想像もつきません。

いやぁ、やっぱりまだ何かおかしいですね。
#11097とか#11098からのツリーの、本来「┗」でなければいけないところがいくつか
「┣」になっていますね。
OKなところとNGなところの条件から追いかけてみましょう。
とはいえ、今日はもう終わり。
明日以降でね。

> 上のほうから見ていって、まず気がついたのがLOCATE文。
>   LOCATE 1, 26, ,1
> というのがありましたが、N88では引数は３つまで。
> つまり、カンマの数は２つまででした。

Turbo Basic と TBasic のマニュアルが腐海から救い出せました。
思いもよらぬところの奥底に沈んでいました。(^^;
それによると、LOCATE 文の引数は 5個まであります。

LOCATE 縦位置,横位置,カーソル表示スイッチ,カーソル開始位置,カーソル終了位置

私がN88系と違うと思ったのは、縦と横が逆なところです。
他の構文は、横、縦なので、間違えやすいですね。MS系の歴史でしょうか。

> 次がCOLOR文。
>   COLOR 14, 0
> とありますが、N88では最初の引数は0から7までだけでした。
> ２番目と４番目の引数なら14も使えるようです。

これもMS系と大きく違うところですね。
詳しくは以下略。(^^;

> あ、なんか、消し忘れのようなもの見つけてしまった。
> a!=0
> ってあるんですが、この変数、他では使われていないっぽい。

う、消し忘れてましたね。(^^;

> あ〜、なんか、N88-BASIICに移植したくなってきた。
> といっても、動作環境は手元にはない。
> 実家にはDOS BASICはあるはずだけど、DOS BASICとDISK BASICって何が違っていたか
> もう思い出せない。
> ちょっと無謀だな。

ネットには、N88系準拠のフリーなBASICもありそうです。
移植するなら、他の素数プログラムが良いと思います。
私のは全く実用的でないので。(^^;
これからアップしますね。

> #11097とか#11098からのツリーの、本来「┗」でなければいけないところがいくつか
> 「┣」になっていますね。

見てみましたが、これは正しいツリーだと私は思います。
うちのツリーは横幅を狭くしたくて見た目がいまいちなのです。(^^;

TurboBasicで素数を表示、カウントするプログラム PRIME2.EXE です。
元にしたのは、十進BASIC に入っていた サンプルソースです。

https://hp.vector.co.jp/authors/VA008683/
ここのダウンロードページの Windowsアーカイブ版の中の
　BASIC7868.zip (1,292,876バイト)を落として展開すると
Mathフォルダがあり、その中にある
PRIME.BAS 　319bytes
を Turbo Basic で動くように改造しました。

特徴は、処理が非常に速く、桁数の制限がほぼ無いことです。
DOSVAXJ3 や MS-DOS Player の JP モードで動きます。

自己流で改造したので間違いがある可能性はあります。
指定範囲は２０から １億までにしました。
起動時オプションで動作変更できます。


PRIME.ZIP　サイズ 30299bytes　 24-03-01 new!

　 PRIME2.EXE Ver.240301

・DOSVAXJ3 の VGAで動く 素数表示テストです。
・DOSVAXJ3 を起動したら、chev jp でVGAモードにして、PRIME2.EXE を起動してください。
・MS-DOS Player では、chej jp でVGAモードにすれば動作します。
・VTDOS では動作しません。
・ソースも付けます。
・20000000までは実行できると思います。
・数字や時間情報を SOSU.DAT に追加出力します。
・起動時オプション 1 で P000.DAT に素数を出力します。
・起動時オプション 2 で 表示もファイル出力もしません。カウントのみ。
・起動時オプション 100以上で 指定した数字で間欠カウント表示。若干速くなるかも。
・数字が大きくなると時間が掛かるので、初めは 1000くらいから始めてください。

・更新履歴
2024-03-03　V2　バグ取りやファイル出力やオプション追加など。
2024-02-27　V1　とりあえず作成

　動作保証はでき無いので実行は自己責任で。　　
http://tamaneko.world.coocan.jp/execom.htm

> 見てみましたが、これは正しいツリーだと私は思います。

あれ？
うちとkonnoさんのところでは、表示のされ方が違うのかな？
そんなことはないと思うけど。

たとえば、#11097から始まるツリーの#11117とか#11126が、本来は「┗」でなければ
いけないけれど「┣」になっているように見えます。
これ、konnoさんのところでは正しく「┗」になっているのか。
それとも私の勘違いで「┣」が正しいのか。
ちょっと混乱しています。

> 自己流で改造したので間違いがある可能性はあります。

プログラムの中身はぜんぜん読めていませんが。

> ・起動時オプション 1 で P000.DAT に素数を出力します。
> ・起動時オプション 2 で 表示もファイル出力もしません。カウントのみ。

ソースリスト冒頭のコメントで

'  IF DSP=1 THEN 	print			'画面出力
'  IF DSP=1 THEN 	print out dat		'ファイル出力
'  IF DSP=2 THEN 	no print		'カウントのみ

となっているのですが、これはコメントが間違っているのかな。

LOCATEなんていう、割と基本的なところからして違うものなのですね。

> LOCATE 縦位置,横位置,カーソル表示スイッチ,カーソル開始位置,カーソル終了位置
> 
> 私がN88系と違うと思ったのは、縦と横が逆なところです。
> 他の構文は、横、縦なので、間違えやすいですね。MS系の歴史でしょうか。

えと、LOCATEが縦、横の順というのは、Turbo Basic と TBasic の両方ですか？
それともどちらかだけ？
ちなみに、N88の場合は

LOCATE 横位置,縦位置,カーソル表示スイッチ

だけです。
カーソルの開始位置、終了位置ってなんだろう。
横長のカーソルを表示できるのかな。
それとも、その制限の範囲にカーソルがこない場合は表示されない、とか。

> 移植するなら、他の素数プログラムが良いと思います。

konnoさんの新しいのもリリースされたし、そっちを狙おうかな。
とりあえず、SOSU6の方を移植するとなると気になる部分がひとつ。
もしかしたら16ビットのBASICでは改善されているかもしれませんが。

loop2:			' 数値を確定した素数で割り切れれば合成数
  for ii!=1 to co!-1
    b!=int(i!/co1%(ii!)):if b!=i!/co1%(ii!) then noflg=1:goto lpend2
  next ii!
lpend2:

8ビット時代のBASICでは、こういうループの脱出方法をは推奨されなかった。
FORのループを完了させずに途中で脱出すると、スタックにデータが詰みあがった
ままになってしまうのだそうで。
たしか、新しくRUNするとクリアされるのだったかなぁ。
もしかしたら、明示的にCLEARというコードを書かないとクリアされなかったかも
しれない。
この辺は処理系によって違うかもしれないし、当時のBASICのリストを見ると、DEFINT
と同様、ソースの先頭でおまじないのようにCLEARを入れているものが多かったので、
この辺で混同している部分もあるかもしれない。
で、結局どうするのがよいかというと

*LOOP2
FOR II!=1 TO CO!-1
    IF INT(I!/CO1%(II!))=I!/CO1%(II!) THEN NOFLG=1:II!=CO!-1
NEXT

こんな感じで無理やり強制的にループの制御変数の値を書き換えてしまう、という
ワザが使われていました。

> たとえば、#11097から始まるツリーの#11117とか#11126が、本来は「┗」でなければ
> いけないけれど「┣」になっているように見えます。

あうう、リンク先をそのまま見ていました。頭が他に行っていたみたいです。(>_<)
 msgview のツリーは「┣」になっていますね。失礼しました。m(__)m
 何が悪いのかはわかりません。m(__)m

> ソースリスト冒頭のコメントで
> '  IF DSP=1 THEN 	print			'画面出力
> '  IF DSP=1 THEN 	print out dat		'ファイル出力
> '  IF DSP=2 THEN 	no print		'カウントのみ
> となっているのですが、これはコメントが間違っているのかな。

コメントの間違いにコメントするなんて、鬼畜ですぅ。(;_;)
もちろん1行目は ゼロのつもりだったんですぅ。
日付や指定範囲などもおかしいような気がするけど気にしない。(^^;

> > LOCATE 縦位置,横位置,カーソル表示スイッチ,カーソル開始位置,カーソル終了位置

見直したらおかしなところに気が付きました。
  LOCATE 1, 26, ,1
とありますが、おしりの１はカーソル開始位置なので、終了位置が無い？
これも元は何かのサンプルソースで
  LOCATE 1, 26, ,1 '%CursorOff
多分これが元だと思います。
TBasicのマニュアルでは、終了位置を省略すると開始位置と同じ数値が入るらしいですが
このコメントでは、カーソルオフになっていますね？　わからん。
サンプルが間違えているかもですね。(^^;

> えと、LOCATEが縦、横の順というのは、Turbo Basic と TBasic の両方ですか？

両方です。TBasicはもろMS系だと思いますが、TurboBasicもMS系準拠ということですかね。

> カーソルの開始位置、終了位置ってなんだろう。

カーソルの高さ指定だと思います。TBasicでは、0が上で 15が下みたいです。


> FORのループを完了させずに途中で脱出すると、スタックにデータが詰みあがった
> ままになってしまうのだそうで。

うげ、これは知らなかったです。ヤバイかも・・・(>_<)
STIME でたまに問題が出るのはこれかもしれないですね。

> FOR II!=1 TO CO!-1
>     IF INT(I!/CO1%(II!))=I!/CO1%(II!) THEN NOFLG=1:II!=CO!-1
> NEXT
> こんな感じで無理やり強制的にループの制御変数の値を書き換えてしまう、という
> ワザが使われていました。

これも良くやっていますが、これからはループを抜ける時は気を付けます。

>  何が悪いのかはわかりません。m(__)m

私にも何が悪いのか、今のところは全くわかっていません。
一応、１月にkonnoさんにお送りしたコードを再び引っ張り出してみました。
そして、うちの板塀の現行ログを表示してみたのですが、全て正常な表示に見える
のですよ。かなり複雑そうなツリーであっても。
う〜ん、まさかデータというかログファイルのほうに原因があるのか？
それとも、私がkonnoさん的なコードに転記する際にどこかを誤ったとか。
いささか複雑というか統一性に欠けたコーディングスタイルでしたから。
あるいは、konnoさんがご自分でコードをきれいにしようとして失敗したとか。

一応、ざっくりみたところ。
msgviewの中で「┗」「┣」が表示されるルーチンは以下のような感じ。

if ($tx[$lx] == 0 && $lx != 0) { print "┗"; }
else {
    $jj=1;
    while ( $tlx[$j+$jj] > 0 ) {
        if ( $tlx[$j] == $tlx[$j+$jj] ) { $jj=0; last; }
        if ( $tlx[$j] > $tlx[$j+$jj] ) { $jj=1; last; }
    $jj++;
    }
    if ( $jj == 0 ) { print "┣"; }
    elsif ($lx != 0 ) { print "┗"; }
}

一方で、正しく表示される一括表示のツリー表示部分は以下のような感じ。

if ( $tx[$lx] == 0 ) { print "┗"; }
else {
    $jj=1;
    while ( $tlx[$j+$jj] > 0 ) {
        if ( $tlx[$j] == $tlx[$j+$jj] ) { $jj=0; last; }
        if ( $tlx[$j] > $tlx[$j+$jj] ) { $jj=1; last; }
        $jj++;
    }
    if ( $jj == 0 ) { print "┣"; }
    else { print "┗"; }
}

条件式が違うじゃない。
何でこんなところを見落としたんだろう。
テストデータというか板塀のデータで正常に表示されていたからだろうなぁ。

ということで、もしかしたらこれでうまくいくかも。
もうkonnoさんのところでも不要なコメントは全部落としているでしょうから、場所は
すぐに見つかることでしょう。
とりあえず試してみてください。

> これも元は何かのサンプルソースで
>   LOCATE 1, 26, ,1 '%CursorOff
> 多分これが元だと思います。
> TBasicのマニュアルでは、終了位置を省略すると開始位置と同じ数値が入るらしいですが
> このコメントでは、カーソルオフになっていますね？　わからん。

値を省略するとカーソルオフなんですかね。
N88だと、最後のパラメータなんでよく省略されていましたが、省略時は単にそれ以前
の値を引き継いでいました。

> カーソルの高さ指定だと思います。TBasicでは、0が上で 15が下みたいです。

あ、横方向ではなく、１つの文字の中の縦方向でしたか。
ということは、開始位置が0、終了位置を1と指定すると、アッパーラインのような感じ
になるということですね。これはVzのCiとCoみたいに変更できるということですから、
使い方によっては便利かもしれない。

> > FORのループを完了させずに途中で脱出すると、スタックにデータが詰みあがった
> > ままになってしまうのだそうで。
> うげ、これは知らなかったです。ヤバイかも・・・(>_<)

いや、昔のインタプリタの時代の話ですから。
コンパイル型言語なら大丈夫なんじゃないかなぁ。
ただ、ループをまわす回数が増えても問題がないのに、ループの回数そのものが少ない
にもかかわらず、そのループを呼び出す回数が増えると問題が出るという、謎の不具合
につながることがあって。
苦労させられた人はそれなりにいるはず。


ところで、それよりも、変なことに気がつきました。
#11097によると

> 最も素朴な方法は、2 から √n 以下の素数まで順番に割っていく

とあるのですが、コードの中にSQRT関係の関数がないようです。
これ、本当にこのアルゴリズムであっていますかね。
例えば、23が素数であるかを確認するためには√23以下の素数、つまり2と3で確認
すれば事足りるわけです。
コードを追いかけていませんが、まさか、5とか7でも割っているから余計に時間が
かかっている、ということはないでしょうか。

> あるいは、konnoさんがご自分でコードをきれいにしようとして失敗したとか。

私は頂いたソースをそのまま張り付けただけだったと思います。(^^;
今見たら私のバグバグなトンでもコードのコメントがそのまま大量に残っていますね。(^^;
よくこの状態で修正できたと感心します。いや、ありがたいです。

> msgviewの中で「┗」「┣」が表示されるルーチンは以下のような感じ。
> if ($tx[$lx] == 0 && $lx != 0) { print "┗"; }

ここは探してみたところ、以下のようになっていましたが修正しました。

#       if ($tx[$lx] == 0 && $lx != 0) { print "┗"; }
        if ( $tx[$lx] != 0 ) { print "┣"; }
    ↓
	if ( $tx[$lx] == 0 ) { print "┗"; }

     elsif ($lx != 0 ) { print "┗"; }
    ↓
     else { print "┗"; }

最初下の1行だけ修正しましたが変わりませんでした。
それで上側も修正したら、キチンとツリー表示出来ました。＼(^^)／ ﾔｯﾀ-

> もうkonnoさんのところでも不要なコメントは全部落としているでしょうから、場所は
> すぐに見つかることでしょう。

不要なコメントはまだそのままですが、これを機に削除しようと思います。(^^;
本当にありがとうございました。m(__)m

> 値を省略するとカーソルオフなんですかね。
> N88だと、最後のパラメータなんでよく省略されていましたが、省略時は単にそれ以前
> の値を引き継いでいました。

試しに
LOCATE 1, 26, ,10
にして実行してみたら、カーソル高さが半分くらいになっていました。
省略時はそれ以前の値を引き継ぐようですね。

> コンパイル型言語なら大丈夫なんじゃないかなぁ。
> ただ、ループをまわす回数が増えても問題がないのに、ループの回数そのものが少ない
> にもかかわらず、そのループを呼び出す回数が増えると問題が出るという、謎の不具合
> につながることがあって。
> 苦労させられた人はそれなりにいるはず。

やっぱりむやみにループを抜けるのは避けた方が良さそうですね。

> ところで、それよりも、変なことに気がつきました。
> #11097によると
> > 最も素朴な方法は、2 から √n 以下の素数まで順番に割っていく
> とあるのですが、コードの中にSQRT関係の関数がないようです。

気が付いてしまいましたか、そうです、私はWikiを見ないで自分で考えたのです。
素数を調べるには確定した素数で割ればいいんじゃないかと思ったのです。
それで配列に確定した素数を入れたのですが、数字が大きくなると割る回数が増えるので
時間が掛かったのでした。

> これ、本当にこのアルゴリズムであっていますかね。

PRIME2.EXE は、SQR関数を使っているので、これが本来のアルゴリズムなのでしょうね。
でも結果は一致していたので、考え方はあながち間違ってはいなかったかなと思います。

> 例えば、23が素数であるかを確認するためには√23以下の素数、つまり2と3で確認
> すれば事足りるわけです。
> コードを追いかけていませんが、まさか、5とか7でも割っているから余計に時間が
> かかっている、ということはないでしょうか。

その通りですね、ですから、SOSUシリーズは私の個人的仮説の実験だったのです。(^^;
PRIME.BAS のサンプルは学校でも使える模範的コードなのだと思います。

> それで上側も修正したら、キチンとツリー表示出来ました。＼(^^)／ ﾔｯﾀ-

無事に正常表示になりましたね。よかったよかった。

> 今見たら私のバグバグなトンでもコードのコメントがそのまま大量に残っていますね。(^^;
> よくこの状態で修正できたと感心します。いや、ありがたいです。

だから前にも言ったけど、ほとんど迷彩のような。
あたかも、プログラムからバグを除去することを拒むかのような。
このコードを書いた人は、プログラムの完成を見ることなく、永遠にデバッグのぬるま湯に
浸かっていたいのか。
と、誤解してしまいそうなわけですよ。誤解ですよね？
＃本心だったらいやすぎ


コメントが多いというのは、決して悪くはないんですよ。
問題は、それが何を意味しているかがわからないこと。
例えば、コードの右側のほうに
「この行のコメントをはずすと××になる」
とか
「※参考　○○氏のコード」
などときちんと記載されていればいいのですよ。
あるいは、ymfcstなんかでも採用されているような感じで
「★マークの５行のコメントをはずすとほにゃらら」
みたいなものとか。
要は、konnoさんのコードの場合、有効な情報が全くないのがイマイチ。

プログラムにおけるコメントって、コンピュータではなく人間に対して書くものですから、
人間に対して意味のない情報は少ないほうがいい。
私も、プロの書いたコードなんてあんまり見たことがありませんが、まずは目標として
コードだけで、つまりコメント全くなしで、ここは何をやっているかがわかるような
ものを目指すらしい。そうすれば、そもそもコメントを入れなくてすむから。
おおむね、人はみな横着ですからね。コメントを考える手間も省きたいわけですよ。
ただ、それはある種の理想。そんなものが実現することはまずない。
ということで、次善の策。コメントだけを追いかけることで、そのコードが何をやって
いるかがわかるようにする。
つまり、それなりにプログラムを読んできた経験のある人の場合、初めて触れる言語で
あっても、コメントのあるコードであれば、まずコメントを読む。
私も、Vzのマクロを勉強するとき、ikubohさんだったかな、もう忘れましたが、誰かの
マクロコードのコメントを見て勉強した記憶があります。

ということで、必要なコメントはバシバシ入れましょう、ということでした。

> コメントの間違いにコメントするなんて、鬼畜ですぅ。(;_;)

いや、なんとなく間違っていそうだとは思ったけど、確信がもてなかったのですよ。
だって、#11135で

> ・起動時オプション 1 で P000.DAT に素数を出力します。
> ・起動時オプション 2 で 表示もファイル出力もしません。カウントのみ

とはあったけど、起動時オプション 0 があるとは書いてなかったもので。

> 日付や指定範囲などもおかしいような気がするけど気にしない。(^^;

日付や範囲指定については、まだ見てもいない。
それより気になった部分がいくつかあって。
例えば、表示する素数の数の入力を求めるプロンプト、日本語の部分がコメント
になっていますが、これはなぜそうしているのか、とか。
メインというか j のループからは結構強引な脱出をしているな、とか。
そのループのコメントの「i;:c=c+1」っていったいなんだろう、とか。
outputのコメント、なんで素数が１個でも10000000個でも時間が同じなのかな、
とか。もしかしたら違うのかもしれないけど、この表現ではそれ以外の意図は
読み取れない。
タイマーのサブルーチンの冒頭、謎のif文がコメントアウトされているけど、
これはいったいなんだろう、とか。

一般にコードの概要をつかむにはコメント文が有効のはずなんだけど、全く有効に
見えない気がする。

> このコードを書いた人は、プログラムの完成を見ることなく、永遠にデバッグのぬるま湯に
> 浸かっていたいのか。
> と、誤解してしまいそうなわけですよ。誤解ですよね？
> ＃本心だったらいやすぎ

もちろん誤解ですよ。(^^;　ただ世の中変人が多いのでそういう人もいるかも。（いねえよ）

> コメントが多いというのは、決して悪くはないんですよ。
> 問題は、それが何を意味しているかがわからないこと。

超絶ハイテク技などはそういうコメントが欲しいものですね。

> 要は、konnoさんのコードの場合、有効な情報が全くないのがイマイチ。

うう、これは BASIC コードのことを言っているのですよね。
アセンブラやVZマクロにはかなりコメントを入れているつもりです。(^^;

> ということで、次善の策。コメントだけを追いかけることで、そのコードが何をやって
> いるかがわかるようにする。

これは上で書きましたが、BASICは自分で読めるものだからあまりコメントを入れないのですね。
でも後で読むと何をやっているのかわからなくなってしまっています。(>_<)
ということで、今はサブルーチンのタイトルや説明、各行のコメントを
なるべく入れるようにやっている最中です。(^^;
達人のコードにコメントが無いのは必要を感じないからなんでしょうね。

> 私も、Vzのマクロを勉強するとき、ikubohさんだったかな、もう忘れましたが、誰かの
> マクロコードのコメントを見て勉強した記憶があります。
> ということで、必要なコメントはバシバシ入れましょう、ということでした。

ikubohさんなど達人のマクロはコメントがないと何をやっているのか全く分からないレベルですからね。
私もこれからは他人が読むことを念頭に入れてコメントを入れるようにします。

＃　昨日の自分は他人と言いますからね。(ﾟ゜)☆＼(--#) それはおのれじゃ

> だって、#11135で
> > ・起動時オプション 1 で P000.DAT に素数を出力します。
> > ・起動時オプション 2 で 表示もファイル出力もしません。カウントのみ
> とはあったけど、起動時オプション 0 があるとは書いてなかったもので。

お察しの通りオプション 0 はありません。(^^;
あ、P000.DAT も S000.DAT の間違いですね。P000 は PRIME2 の方でした。(>_<)

> 例えば、表示する素数の数の入力を求めるプロンプト、日本語の部分がコメント
> になっていますが、これはなぜそうしているのか、とか。

最初日本語で書いたけどUSモードだと表示しないとか色々面倒なのでコメントにしてしまい
そのまま放置してました。(^^;

> メインというか j のループからは結構強引な脱出をしているな、とか。

これは良くない抜け方でしたね、気が向けば直します。(^^;

> そのループのコメントの「i;:c=c+1」っていったいなんだろう、とか。

これは元は PRINT文だったのを、PRINT1: というサブルーチンに変更したので

  IF j>SQR(i) THEN gosub PRINT1 i;:c=c+1	' 素数
             ↓
  IF j>SQR(i) THEN gosub PRINT1  'i;:c=c+1	' 素数

こういうように、コメントで手抜きをしてました。(^^;
まあ、飛び先でやってることをコメントに残したとも言えなくもないし。(^^;

> outputのコメント、なんで素数が１個でも10000000個でも時間が同じなのかな、
> とか。もしかしたら違うのかもしれないけど、この表現ではそれ以外の意図は
> 読み取れない。

'Number.1	    0: 0' 4 	Prime Number = 9592 
'Number.10000000	    0: 0' 4 	Prime Number = 9592 

これですね、Prime Number が同じということでお察しください。(^^;
手抜きの残骸だったのかなんなのか、今はもうわからないです。(^^;

> タイマーのサブルーチンの冒頭、謎のif文がコメントアウトされているけど、
> これはいったいなんだろう、とか。

これも借り物のルーチンの残骸ですね。他人に見せることは全く意識してないのです。

> 一般にコードの概要をつかむにはコメント文が有効のはずなんだけど、全く有効に
> 見えない気がする。

私のソースはこんなのばっかりなので、元々は公開する気も無かったんですがねぇ。(^^;
出来る範囲で改善するようにします。m(__)m

オリジナルの prime.bas のソースはこれだけです。

INPUT n
IF MOD(n,2)=0 THEN
  IF n=2 THEN PRINT "素数" ELSE PRINT "合成数"
ELSE
  FOR i=3 TO SQR(n) STEP 2
    IF MOD(n,i)=0 THEN EXIT FOR 
  NEXT i
  IF i<=SQR(n) THEN PRINT "合成数" ELSE PRINT "素数"
END IF
END


IF 〜 ELSE 〜 END IF をうまく使ってシンプルでエレガントですね。
TurboBasic で同じやり方はわからなかったので、自分なりに改造したのが以下

FOR i=2 TO n 
  IF i=2 THEN gosub PRINT i;:c=c+1		' 2 素数
  i2=i/2:i3=int(i/2):IF i2=i3 THEN goto EXIT2	' 合成数
  FOR j=3 TO SQR(i) STEP 2			' 偶数をスキップ
    i2=i/j:i3=int(i/j):IF i2=i3 THEN goto EXIT1 ' 合成数
  NEXT j
EXIT1:
  IF j>SQR(i) THEN gosub PRINT i;:c=c+1		' 素数
EXIT2:
NEXT i:i=i-1

としきさんにループの抜け方が強引と言われたけど、うーむ・・・

    IF MOD(n,i)=0 THEN EXIT FOR 
ここは
    i2=i/j:i3=int(i/j):IF i2=i3 THEN goto EXIT1 ' 合成数
             ↓
    i2=i/j:i3=int(i/j):IF i2=i3 THEN i=i+1	' 合成数
にすればよかったのかな。
つい、EXIT という構文に引っ張られたような・・・(^^;

> > 要は、konnoさんのコードの場合、有効な情報が全くないのがイマイチ。
> うう、これは BASIC コードのことを言っているのですよね。

BASICもそうですが、先日お送りいただいたperlのコードも含めて、です。

> ということで、今はサブルーチンのタイトルや説明、各行のコメントを
> なるべく入れるようにやっている最中です。(^^;

うん、まぁ、最終的な完成品を作るにあたってそういうことは必要ですけどね。
私のような横着な人間はどうするかというと、プログラムを作る前に、日本語で
設計します。そして、その設計をそのままコードの中にコメントとして残しておく。
例えば、今回のkonnoさんのprime2.basを作ろうとするなら、私の書きそうな設計
は以下のような感じ。

　初期設定
　求める素数上限入力
　メインルーチン（サンプルコードを最大限流用）
　終了処理（キー入力待ち必須）

　出力サブルーチン
　ファイル出力
　エラー終了ルーチン（自作の××からコピペ）
　タイマールーチン（自作の○○からコピペ）

こんな感じで設計ができたら、あとは切った貼った、コピペできないところは仕方
ない作るか。
という風にするわけです。
そうすれば、わざわざコメントを書くということはなくなります。
その上、設計をじっと見つめて、例えば、出力部分はもうちょっと整理できそうだ、
とか、エラーのルーチンはそのままコピペだとイマイチかも、みたいなことも考え
付いたりするわけですよ。
そういえば昔、どこかに似たようなことも書いた気が、と思って検索したら。
nifty:FGALDC/MES/15/#19030
に似たようなことを書いていた。
そうか、ikubohさんではなくてEmmettさんのマクロで勉強したのか。

いろいろなことを書きましたが。
結論は、楽をしましょうよ、ということに尽きるわけで。

> BASICもそうですが、先日お送りいただいたperlのコードも含めて、です。

そうでした、直してもらったばかりなのに perl のことを忘れていました。m(__)m

> 私のような横着な人間はどうするかというと、プログラムを作る前に、日本語で
> 設計します。そして、その設計をそのままコードの中にコメントとして残しておく。
> 例えば、今回のkonnoさんのprime2.basを作ろうとするなら、私の書きそうな設計
> は以下のような感じ。

なるほど、これをそのまま各ルーチンのタイトルに使うのですね。
私は手を付けてからどうするか考える癖があるみたいで、
今すぐこのスタイルに切り替えるのは難しそうです。(^^;
でも参考になりました。やってみたいと思います。

> そういえば昔、どこかに似たようなことも書いた気が、と思って検索したら。
> nifty:FGALDC/MES/15/#19030
> に似たようなことを書いていた。
> そうか、ikubohさんではなくてEmmettさんのマクロで勉強したのか。

そうでしたか、実は私も「コメントの多いマクロ」で Emmettさんを思い出してました。(^^;
その Emmettさんの発言を見ると

> 》　僕は、マクロを書く時はとりあえずグローバルマクロからとにかく書き始めます。
> 》  僕は、アルゴリズムを最初にどこかにメモしておいて、それに従ってプログラム
> 》  を組んで行くということはやったことがありません。いつでもいきなり、グロー
> 》  バルの１行目から、じかに書き始めます。

私とおんなじですね。(^^;
それに対してとしきさんも

> あぁ、なるほど、やっと Emmett さんのマクロ作法がわかったような気がします。
> 基本的な考え方としては、私も Emmett さんとほとんど変わりません。
> とっても安心しました。

このように同意していますが、その後に

> でも、大きく異なるところは、私の場合、仮想プログラム言語というかメタ言語
> というか、まぁ日本語のようなもので書いているのです。で、大体まとまったら
> マクロに翻訳する、と。

こう書いていますね。やっぱりスタイルが違うと感じます。(^^;
もちろん、としきさんの方が正統派だと思います。

> いろいろなことを書きましたが。
> 結論は、楽をしましょうよ、ということに尽きるわけで。

楽をする、という意味では、としきさんのような正統派のやりかたが良いと思います。
それが出来ない私は、やっぱり楽をしようと思っていないのかもですね。(^^;
それよりも早く頭の中のアイデアをコードにしたいという欲求が強いのでしょう。(^^;
＃　そうしないとアイデアが消えてしまいそうだから。(^^;;

多分、最大というか基本的な違いはここ。

> それよりも早く頭の中のアイデアをコードにしたいという欲求が強いのでしょう。(^^;
> ＃　そうしないとアイデアが消えてしまいそうだから。(^^;;

私はアイディアをコードではなく日本語で考えている、ということ。
だから、日本語でメモをしている。
逆に言うと、ナイスなコードを思いつく、ということはあんまりなさそうです。

あと、前述のEmmettさんとの対話の部分、読み直して、もしかしたら私に誤解が
あったかもしれないというのがkonnoさんの指摘で気がついた。

> > 》  僕は、アルゴリズムを最初にどこかにメモしておいて、それに従ってプログラム
> > 》  を組んで行くということはやったことがありません。いつでもいきなり、グロー
> > 》  バルの１行目から、じかに書き始めます。
> 
> > あぁ、なるほど、やっと Emmett さんのマクロ作法がわかったような気がします。
> > 基本的な考え方としては、私も Emmett さんとほとんど変わりません。
> > とっても安心しました。
> 
> このように同意していますが、その後に

このときの薄らぼんやりとした記憶では、私、サブルーチンから書き始めるのでは
なく、全体の大枠から書き始める、という意味でEmmettさんと同じだな、と感じた
ように覚えています。
確かにこの部分、解釈によってはいろいろと怪しいかもしれない。

> 私はアイディアをコードではなく日本語で考えている、ということ。
> だから、日本語でメモをしている。
> 逆に言うと、ナイスなコードを思いつく、ということはあんまりなさそうです。

うーむ、私もアイデアが浮かんだ時点では、コードではなく日本語な気もしますが
コード的な、パズルのピース的な漠然としたイメージなのかもしれませんね。

> このときの薄らぼんやりとした記憶では、私、サブルーチンから書き始めるのでは
> なく、全体の大枠から書き始める、という意味でEmmettさんと同じだな、と感じた
> ように覚えています。
> 確かにこの部分、解釈によってはいろいろと怪しいかもしれない。

普通、枝葉であるサブルーチンから書き始める人はいませんよね。(^^;
私も Emmettさんの書き込みを読み直したら、何か違う気がしてきました。

> 》  いつでもいきなり、グローバルの１行目から、じかに書き始めます。

ここ、私なら始めに類似したプログラムを探してそれを修正して使おうとします。
ゼロから書き始めるなんて面倒だと思うので私はほとんどやったことがないのですよ。
＃　それが改造人間の定めなのさ・・・・　ルルルー・・・

いいかげん、タイトルを変えるべきだということに遅まきながら気がつきました。
いまさら、という気も大いにしますが。
そして、たいそうな内容を書くわけでもない。

> ここ、私なら始めに類似したプログラムを探してそれを修正して使おうとします。
> ゼロから書き始めるなんて面倒だと思うので私はほとんどやったことがないのですよ。

類似したプログラムが見つからないとき、というのも私の場合はたまにある。
ん〜、最近はあんまりそういうこともありませんが。
例えば、野ざらし言#569 からのツリーで作ったマクロ。
こういう案件、konnoさんはあまり手を出さないということでしょうか。
私も最近はそういうことがなくなったということは、年をとったせいかも。
いかんなぁ。

> オリジナルの prime.bas のソースはこれだけです。

なるほど、MODって関数なんですね。
N88-BASICでは演算子なんですけどね。

> INPUT n
> IF MOD(n,2)=0 THEN
>   IF n=2 THEN PRINT "素数" ELSE PRINT "合成数"
> ELSE
>   FOR i=3 TO SQR(n) STEP 2
>     IF MOD(n,i)=0 THEN EXIT FOR 
>   NEXT i
>   IF i<=SQR(n) THEN PRINT "合成数" ELSE PRINT "素数"
> END IF
> END

これをそのままN88-BASICに移植すると、こんな感じかなぁ。
実行していないので、そのまま動くかどうかはわかりません。

100 INPUT N
110 IF N MOD 2=0 THEN 120 ELSE *ELSE1
120     IF N=2 THEN PRINT "素数" ELSE PRINT "合成数"
130     GOTO *ENDIF1
140 *ELSE1
150     I=3
160     WHILE (I<=SQR(N)) AND (N MOD I<>0)
170         I=I+2
180     WEND 
190     IF I<=SQR(N) THEN PRINT "合成数" ELSE PRINT "素数"
200 *ENDIF1
210 END

解説すると

・MODは演算子に変更した。
・110行目のTHENの行番号は省略できたかもしれない。
　つまり、NULLの行番号が許容されるのなら、その場合は単に次の行に制御が移る。
・ループの脱出条件が複数あるので、FORループからWHILEループに変更した。


> TurboBasic で同じやり方はわからなかったので、自分なりに改造したのが以下

TurboBasicって、MOD関数またはMOD演算子ってないんですか？
あと、NEXTの後ろの変数って省略できないんですか？
でもコンパイラ言語だからあんまり関係ないのか。
８ビットのBASICのころは、NEXTの後ろの変数を省略するとマイクロ秒の単位で速く
なると信じられていて、だから私も省略するのが癖になっているのですよ。
高速化といえば、最初のFORの直下のIF文。
これはループの中に入れておくのはもったいない。
だって、１回しか比較する必要がないものを何回も比較することになるわけだから。

> i=2:gosub PRINT i;:c=c+1		' 2 素数
> FOR i=3 TO n 

こんな感じで十分だと思う。

> いいかげん、タイトルを変えるべきだということに遅まきながら気がつきました。

私も途中で思ったのですが、まあいいかと。(^^;

> 類似したプログラムが見つからないとき、というのも私の場合はたまにある。
> ん〜、最近はあんまりそういうこともありませんが。
> 例えば、野ざらし言#569 からのツリーで作ったマクロ。
> こういう案件、konnoさんはあまり手を出さないということでしょうか。

そういう案件も多いと思います。その場合でも入出力など使えるルーチンは切り貼りで済まします。
そういえばテレビドラマ「ガリレオ」の教授は思いついたらいきなり数式を書きなぐっていましたね。
そういうやり方ができるのは、c.mosさんくらいではないかと。

> 私も最近はそういうことがなくなったということは、年をとったせいかも。

私も年を取って、昔のやり方でしか出来なくなったような気がします。
BASICのソースは普通大文字で書きますが、最近小文字の行を混在させてますよね。
そこは、自分で一から書いているよという自己主張なのかもしれません。(^^;

> なるほど、MODって関数なんですね。
> N88-BASICでは演算子なんですけどね。

あう、MOD は演算子でしたね、失礼しました。

> これをそのままN88-BASICに移植すると、こんな感じかなぁ。
> 実行していないので、そのまま動くかどうかはわかりません。

> TurboBasicって、MOD関数またはMOD演算子ってないんですか？

もちろんありますが、32767以上は駄目みたいです。

> あと、NEXTの後ろの変数って省略できないんですか？
> でもコンパイラ言語だからあんまり関係ないのか。

省略できると思います。指定した方がわかりやすいと思うので。

> ８ビットのBASICのころは、NEXTの後ろの変数を省略するとマイクロ秒の単位で速く
> なると信じられていて、だから私も省略するのが癖になっているのですよ。

コンパイラ言語ではあんまり関係ないのかもしれないなと思います。

> 高速化といえば、最初のFORの直下のIF文。
> これはループの中に入れておくのはもったいない。
> だって、１回しか比較する必要がないものを何回も比較することになるわけだから。

これはその通りですね、最初の FOR文はいらなかったですね。
うっかりしていました。(^^;
 SOSU のソースから切り貼りしたのをそのまま残してしまったのかなぁ。(^^;

> あう、MOD は演算子でしたね、失礼しました。

？？？
オリジナルの prime.bas では関数になっていますよね。
ということは、十進BASICでは関数である、ということだと思いますが？
もしかしたら演算子にもあるかもしれませんけどね。

> > TurboBasicって、MOD関数またはMOD演算子ってないんですか？
> もちろんありますが、32767以上は駄目みたいです。

N88-BASICのリファレンスでは、演算前に小数点以下は切り捨てられるとはあります
が、上限については記載がありません。試してみたいところではあります。

> これですね、Prime Number が同じということでお察しください。(^^;
> 手抜きの残骸だったのかなんなのか、今はもうわからないです。(^^;

いや、konnoさんがわからないくらいですから、私にも察することはできません。
それはさておき。
マジでN88-BASICに移植することを考えています。
で、まだ逐語的な変換には手をつけていないのですが。
気になったのがここ。

if dsp=1 then print#1,"":gosub 1010
if n>2000 then gosub 1000			'output

dsp=1 かつ n>2000 のときは２回出力されるようなんですが、これって仕様的に
なんとなく妙な気がします。これで正しいのですよね？
あと、変数 j2 と j3 も、何をやっているのかよくわからない。
この２つを足し算しているところもあるし。

> オリジナルの prime.bas では関数になっていますよね。
> ということは、十進BASICでは関数である、ということだと思いますが？
> もしかしたら演算子にもあるかもしれませんけどね。

あうう、キチンと読んでいませんでした。
てっきり私がまた間違った言い方をしてしまったのかと。(^^;

> > > TurboBasicって、MOD関数またはMOD演算子ってないんですか？
> > もちろんありますが、32767以上は駄目みたいです。
> N88-BASICのリファレンスでは、演算前に小数点以下は切り捨てられるとはあります
> が、上限については記載がありません。試してみたいところではあります。

十進BASICで関数を使っているのは、MOD に制限があるからかも。
思いついて TurboBasicでテストプログラムを作ってみました。

'tmod.bas
screen 0
print " input ";:input a					'
OPEN "mod.dat" FOR append AS#1			'ファイル出力
print "  a    MOD i ","2bytes "," Froat   "," a / i"
for i=2 to 5
  bb=int((a/i-int(a/i))*i+.5)			' MOD 代替式
  print a;"mod";i,a mod i,bb,a/i 
  print#1, a;"mod";i,a mod i,bb,a/i '
next
print "  a     \  i","2bytes "," Froat   "," a / i"
for i=2 to 5
  cc=int(a/i)					' \ 代替式
  print a;" \ ";i,a \ i,cc,a/i  '
  print#1,a;" \ ";i,a \ i,cc,a/i  '
next

PRINT#1,""
CLOSE#1
100 '入力待ち
print "  push eny key  ";
a$=input$(1)
if a$="" then 100
end

結果

　 a  MOD/\ i  2bytes        Froat         a / i"
 32767 mod 2   1             1             16383.5 
 32767 mod 3   1             1             10922.33333333333 
 32767 mod 4   3             3             8191.75 
 32767 mod 5   2             2             6553.4 
 32767  \  2   16383         16383         16383.5 
 32767  \  3   10922         10922         10922.33333333333 
 32767  \  4   8191          8191          8191.75 
 32767  \  5   6553          6553          6553.4 

 32768 mod 2   0             0             16384 
 32768 mod 3  -2             2             10922.66666666667 
 32768 mod 4   0             0             8192 
 32768 mod 5  -3             3             6553.6 
 32768  \  2  -16384         16384         16384 
 32768  \  3  -10922         10922         10922.66666666667 
 32768  \  4  -8192          8192          8192 
 32768  \  5  -6553          6553          6553.6 

 32769 mod 2   0             1             16384.5 
 32769 mod 3  -2             0             10923 
 32769 mod 4   0             1             8192.25 
 32769 mod 5  -3             4             6553.8 
 32769  \  2  -16384         16384         16384.5 
 32769  \  3  -10922         10923         10923 
 32769  \  4  -8192          8192          8192.25 
 32769  \  5  -6553          6553          6553.8 

これを見るとやはり 32768 以上では MOD も ￥ も使えないようですね。
実は今 STIME のタイマーで計算がバグって困ってたんですが、これが原因だったようです。
テストプログラム作成は無駄ではなかった。(~~;

> マジでN88-BASICに移植することを考えています。
> で、まだ逐語的な変換には手をつけていないのですが。

私も気になったので、NP2 でやってみました。(^^;
N88BASIC.EXE は画面がピンクになって動かないみたいです。(>_<)
BASIC.COM がコンパイラなんですね。無事コンパイルしたのを実行したら、
入力した数字が素数かどうかを表示するのですね。(^^;

> 気になったのがここ。
> if dsp=1 then print#1,"":gosub 1010
> if n>2000 then gosub 1000			'output
> dsp=1 かつ n>2000 のときは２回出力されるようなんですが、これって仕様的に
> なんとなく妙な気がします。これで正しいのですよね？

もちろんまずいです。(^^;　いい加減なだけでした。

> あと、変数 j2 と j3 も、何をやっているのかよくわからない。
> この２つを足し算しているところもあるし。

これですね。

810 if i<j2 then return 			'dsp2でカウント表示
j2=j2+j3  
820 LOCATE 5,1:PRINT i;	'

j2 は表示するまでのカウント数かな？
j3 はオプションの数字で、カウントがこの数字以上になったら次の数字ぶん表示しない
という感じですかね。ほとんど意味がないようですが。(^^;

お彼岸の墓参りの相談で実家に顔を出してきました。
その折に、３０分ほどですが、PC-98に触れて。

> これをそのままN88-BASICに移植すると、こんな感じかなぁ。
> 実行していないので、そのまま動くかどうかはわかりません。

動きました。
細かくはチェックしていませんが、概ね、一発完動。
一発完動教徒なら、このくらい当たり前、というかもしれませんけどね。

> ・110行目のTHENの行番号は省略できたかもしれない。
> 　つまり、NULLの行番号が許容されるのなら、その場合は単に次の行に制御が移る。

あ、ここが省略できるかは確認してこなかった。
次に行ったときには確認してこよう。といいつつ、忘れそうだけど。

次の週末、金曜日から土曜日にかけて実家に泊まることになったので、それまでには
prime2.basのN88-BASICへの移植を終わらせたいなぁ。

> マジでN88-BASICに移植することを考えています。
> で、まだ逐語的な変換には手をつけていないのですが。

ぼちぼち、移植を始めています。

・コマンドラインオプションは取得できないので、プログラム冒頭で入力するように
　した
・まず真っ先にやったのは、locateのxとyの総入れ替え
・N88-BASICでは、実数型も倍精度型も扱える上限は 1.7*10^38 で差がないため、
　変数は全て単精度実数に変更
　→実は覚えていなかったけど、FOR文のカウントに使うループ変数に倍精度型は
　　使えないのだとか。マニュアルに明記してあった
・私の趣味でファイル番号指定の「#1」の前には全て半角空白を入れた
　（たぶん、文法的には不要だと思うけど覚えていない）
・#11160で私が指摘した謎の２つのif文はdsp=1のほうだけ残した
・ファイル出力の際に、ループ内でいちいちOPEN/CLOSEするのは非効率的だと思う
　ので、最初で開いて最後に閉じるだけにした

今の所はそんな感じ。
とりあえず、机上デバッグでどこまでできるか。
忘れていることが多すぎるなぁ。

MOD と \ の有効範囲テストを NP2 でやってみました。
結果は 32767 を超えると オーバーフローエラーになりました。
また、N88BASICでは行番号が必要で、タブは使えなかったので
以下のようにプログラムを修正しました。

10 'N88mod.bas
14 print " input ";
20 input a                              '
30 OPEN "mod.dat" FOR append AS#1                       'ファイル出力
40 print "  a    MOD i ","2bytes "," Froat   "," a / i"
50 for i=2 to 5
60   bb=int((a/i-int(a/i))*i+.5)                        ' MOD 代替式
70   print a;"mod";i,
72   if a>32767 then print "over! ", else print a mod i, '32767 over
74   print bb,a/i 
80   print#1, a;"mod";i,
82   if a>32767 then print#1,"over! ", else print#1, a mod i, ' 32767 over
84   print#1, bb,a/i '
90 next i
100 print "  a     \  i","2bytes "," Froat   "," a / i"
110 for i=2 to 5
120   cc=int(a/i)                                       ' \ 代替式
130   print a;" \ ";i,
132   if a>32767 then print "over! ", else print a \ i, ' 32767 over
134   print cc,a/i  '
140   print#1,a;" \ ";i,
142   if a>32767 then print#1,"over! ", else print#1, a \ i, ' 32767 over
144   print#1,cc,a/i  '
150 next i
160 PRINT#1,""
170 CLOSE#1
180 '入力待ち
190 print "  push eny key  ";
200 a$=input$(1)
210 if a$="" then 180
220 end


エラーになるのと不正な結果になるのとどっちが良いかはともかく
MOD と \ の有効範囲は 普通は 32767 までのようですね。
だから素数のような桁数が多くなる計算は UBASIC などを使うのが良いのでしょうね。

> また、N88BASICでは行番号が必要で、タブは使えなかったので
> 以下のようにプログラムを修正しました。

うわぁ、ものすごく違和感がある見た目のプログラムになるんだな。
最大の理由は、おそらく、行番号のあるBASICにもかかわらず、コードが小文字だと
いうところからくるものだと思います。
行番号の不要なBASICなら小文字のコードでも全く違和感は感じないんですけどね。
どうやら、完全に、行番号のあるBASICは大文字、という感性に毒されている模様。
あと、もしかしたら些細かもしれないけど、行番号が等間隔ではないところにも、
まぁまぁ違和感を感じる。これは、同じN88であっても、インタプリタ型と違って
コンパイラ型の場合、テキストエディタでソースを書くことになるわけですから、
行番号の振り直しには手間がかかりますので、ある程度は仕方ないか。

ちょっとここで、行番号に関する昔話でも。
日本では、８ビットパソコンの草創期から、BASICのリストでは、行番号は10から
始まって10番ごと、というのがデファクト。なぜ10番ごとかというと、コードの追加
をする場合、その間の番号が使えるから、ということのようです。これは、日本に
BASICがやってくる前から、そういうのが普通だったらしい。
ただ、コードを追加すると当然、それは10番ごとにはならない。
そこで、BASICインタプリタにはRENUMというコマンドが用意されました。
renumberの略で、要するに行番号を振りなおしてくれるわけです。
これはNECのBASICにもシャープのBASICにもあったので、おそらく、東芝のBASICにも
あったのではないかなぁ。そしてたぶん、どこのものもほとんど同じだと思いますが、
NECの場合はデフォルトで、新しく付け直した行番号の開始番号は10からで、間隔も
10ごとに付け直してくれました。
コンパイラの場合は当然、こういう便利な機能があるわけではありませんから、番号
の振り直しは自前で人間がやらなければならないので、いろいろと面倒。

その後、BASICでもループなどをきちんとインデントするのが当たり前の時代になる
と、ここで問題になったのが、行番号の桁数。せっかくインデントを整えても、
90から100とか、990から1000といった行番号の桁数が変わるところでインデントが
崩れてしまう。そこでどうするかというと、例えば990行までに収まらないプログラム
なら1000行からはじめればよい、ということになりました。この部分、私ならなにも
10番間隔にこだわらず5番間隔でもいいじゃないか、それこそ最終的な完成形はもう
これ以上追加削除をしないということを強調する意味で1番間隔でいいのではないか、
と思うのですが、どうも世の中の大勢は10番間隔が好きみたい。
あと、間隔はいくつでもいいのですが、プログラムの最初から最後まで等間隔は
守るべき、というのも世間の多数派のようです。というか、RENUMコマンドを使えば
必然的に等間隔になるわけです。ここで例えば、いろいろとコードを追加した際に
その部分を追加したということを目立たせるためにあえて残すべき、という流派の
人もいたらしいですが、これはその後、少数派になりました。なぜかというと、
当時のBASICの編集画面だと、最近のテキストエディタと違い、それが何行目かと
いうことが表示されないわけです。ここで、例えば200行に GOTO 800 とあれば、
もし10番ごとの等間隔なら、ジャンプの飛び先はプログラムリスト上で60行先に
なるわけで、プリントアウトされた紙で追いかけやすい、という実利的な理由が
あったわけです。

と、いうことで。
もしBASICのプログラムをインタプリタに読み込ます機会があったら、RENUMコマンド
をかけた結果を保存しておくべきでしょう。

> うわぁ、ものすごく違和感がある見た目のプログラムになるんだな。
> 最大の理由は、おそらく、行番号のあるBASICにもかかわらず、コードが小文字だと
> いうところからくるものだと思います。

なるほど、そう言われればそんな感じもしますが、私はもう気にしてなかったので。(^^;

> 行番号の不要なBASICなら小文字のコードでも全く違和感は感じないんですけどね。
> どうやら、完全に、行番号のあるBASICは大文字、という感性に毒されている模様。

私はbasic歴が長いので、他の言語が小文字なのに違和感を感じました。今は無いですね。

> そこで、BASICインタプリタにはRENUMというコマンドが用意されました。
> renumberの略で、要するに行番号を振りなおしてくれるわけです。
> これはNECのBASICにもシャープのBASICにもあったので、おそらく、東芝のBASICにも
> あったのではないかなぁ。そしてたぶん、どこのものもほとんど同じだと思いますが、
> NECの場合はデフォルトで、新しく付け直した行番号の開始番号は10からで、間隔も
> 10ごとに付け直してくれました。

TBasicインタプリタは、RENUM 開始行番号,旧行番号,増分  となっています。
開始行番号は、新しくつける先頭の行番号の数値を指定します。
旧行番号は、付け替える初めの行を指定します。
でも私は使ったおぼえが無いですね。試したことはあるかもですが。

私の場合、行番号を振り直すと逆に頭の中のソースのイメージが壊れて混乱してしまう
気がしたので使わなかったのかもですね。再印刷もなかなか出来なかったし。(^^;

> と、ここで問題になったのが、行番号の桁数。せっかくインデントを整えても、
> 90から100とか、990から1000といった行番号の桁数が変わるところでインデントが
> 崩れてしまう。そこでどうするかというと、例えば990行までに収まらないプログラム
> なら1000行からはじめればよい、ということになりました。

これ、私はインデントなどしてなかったので、全く気になりませんでしたね。(^^;
だから今回のテストプログラムも １０番から付けてしまったのです。(^^;

> 必然的に等間隔になるわけです。ここで例えば、いろいろとコードを追加した際に
> その部分を追加したということを目立たせるためにあえて残すべき、という流派の
> 人もいたらしいですが、これはその後、少数派になりました。

どうやら私は少数派のようですね。(^^;

> 当時のBASICの編集画面だと、最近のテキストエディタと違い、それが何行目かと
> いうことが表示されないわけです。ここで、例えば200行に GOTO 800 とあれば、
> もし10番ごとの等間隔なら、ジャンプの飛び先はプログラムリスト上で60行先に
> なるわけで、プリントアウトされた紙で追いかけやすい、という実利的な理由が
> あったわけです。

私がNCプログラムを書いていた当時は、紙にプログラムを手書きしてからタイプライタに打ち込む形でした。
それが面倒に感じたのでパソコンに直接打ち込むスタイルを私が始めたのです。
紙テープに出力、印刷する時は行番号を N001 の形に自動変換していたので
もしかしたら行番号は RENUM していたかもしれません。もう忘れてしまいました。
私にとっては行番号は飾りでした。
＃　偉い人にはそれがわからんのですよ。

それで狭い画面で行番号を頼りに確認するのが煩わしくて、スクリーンエデイタを欲したのです。
当時スクリーンエデイタといえば、ワードマスターとか１０万以上もするようなのしか無かったと思います。
それで、結局自作のBASICインタプリタ用スクリーンエデイタもどきを作ったのでした。
そのために買ったのが、パソピア７だったという。(^^;
それが J3100SL に変わったころ、PSE や VZエデイタが出てきたのでした。

> もしBASICのプログラムをインタプリタに読み込ます機会があったら、RENUMコマンド
> をかけた結果を保存しておくべきでしょう。

その機会があればやってみたいと思います。
NP2 では、BASIC.COM は動かないみたいですが、これがインタプリタなのですよね。

> 私はbasic歴が長いので、他の言語が小文字なのに違和感を感じました。

私もBASIC歴はそれなりに長いのですがね。
複数言語に触れたというのが大きな違いでしょうか。

> TBasicインタプリタは、RENUM 開始行番号,旧行番号,増分  となっています。

これはN88-BASICでもN-BASICでも同じです。

> でも私は使ったおぼえが無いですね。試したことはあるかもですが。

ここは逆というか、私は使いまくりでした。
特に便利に使っていたのが、GOTOの飛び先の行番号が実在しないときにはエラーを
表示してくれる機能。行の追加・削除を頻繁に行う場合には、これは必須という
くらいに便利でした。

> 私の場合、行番号を振り直すと逆に頭の中のソースのイメージが壊れて混乱してしまう
> 気がしたので使わなかったのかもですね。再印刷もなかなか出来なかったし。(^^;

この辺はよく理解できない。ということは、私の場合はあまり行番号に依存しないで
ソースをイメージしていたのかな。つまり、私にとっては、行番号なんて単なる飾り
だった、とか。
＃私は偉くないから。

> これ、私はインデントなどしてなかったので、全く気になりませんでしたね。(^^;
> だから今回のテストプログラムも １０番から付けてしまったのです。(^^;

ここは私にとって大きな違い。
BASICでもバグの入りにくいコードを書こうと思っていたのでインデントしまくり。

> どうやら私は少数派のようですね。(^^;

別に少数派だからといって恥じる必要はさらさらありませんけどね。
ただ、多数派の言い分としては、そちらのほうがバグ取りがしやすい、というもの。
実際、私の経験からも、多数派のほうが正しそうな気がする。
ということで、バグ取りに悩まされたくないので、私も行番号をそろえていました。
あくまでも、実利優先、ということで。

宿直の際にものすごく多忙で。
１時間半ぐらいしか仮眠を取れなかったのですが、帰宅後すぐに実家から墓参り。
墓までの往路はいささか危なかったのですが、それでもおおむね安全運転。
墓掃除その他もろもろですっかり眠気は取れて、実家への復路はほぼ問題なし。

それはさておき、現在、実家です。

> > ・110行目のTHENの行番号は省略できたかもしれない。
> あ、ここが省略できるかは確認してこなかった。

省略できることを確認しました。
これでまた少しコードサイズが節減。

> ぼちぼち、移植を始めています。

ん〜、なんとなく動いているっぽい。
といいつつ、特にファイル書き込みの部分はろくに動作確認をしていないのだけど。

・N88-BASICだと、デフォルトは白黒モードなので、COLORでの色表示がうまくない。
　→おやくそくのCONSOLEでカラーモードにした。
・時間表示の部分、私の趣味で分と秒の間もコロンにした。
・エラー処理ルーチンの最後、CLSがあるとエラーで終わったことがわからなく
　なりそうだったので、これは除去した。

明示的にkonnoさんのコードに手を加えたのはこんなところかな。
あとは、各行にきちんと行番号をつけてやれば完成。
自宅に戻ったらアップロードしたいな。

> 別に少数派だからといって恥じる必要はさらさらありませんけどね。
> ただ、多数派の言い分としては、そちらのほうがバグ取りがしやすい、というもの。
> 実際、私の経験からも、多数派のほうが正しそうな気がする。
> ということで、バグ取りに悩まされたくないので、私も行番号をそろえていました。
> あくまでも、実利優先、ということで。

考えてみたら行番号必須のBASICインタプリタはプログラム言語全体では少数派なんですよね。
行番号付きのBASICインタプリタは作ったその場ですぐ実行できる初心者向きのお手軽な言語だと思います。
だから今でも教育用には使われているのでしょう。
本格的なプログラム言語には行番号は無いので、ラベルでジャンプしますよね。VZマクロも。

ということで、N88BASICなどと共用する場合を除いて行番号は無くす方向で行きたいと思います。
インデントは読みやすくなるのでなるべく心がけるようにします。

> 自宅に戻ったらアップロードしたいな。

アップロードしました。

tp://toshiki.la.coocan.jp/prime88.zip

期間限定。そのうちに削除します。

> といいつつ、特にファイル書き込みの部分はろくに動作確認をしていないのだけど。

こんな短いコードなのに、全ての条件分岐を網羅するホワイトボックステストは
行っていない。面倒になっちゃって。あぁ、横着。
とはいえ、画面表示とファイル出力の、最低限のチェックはしたので、少なくとも
一部はPC-98のDOS BASICで動作確認済み。
GOTOとGOSUBのジャンプはほとんどラベル化したので、行番号はなくても論理構造は
理解可能なはず。konnoさんのお持ちのTurboBasicなら、例えばcols.defのようなもの
を使って全ての行番号を削除しても、もしかしたらコンパイル可能かも。
ラベルの文法が違うからダメ、かな。

あと、もしかしたらほんのちょっとだけ高速化するかもしれない技術を一つ、導入
してみました。

1360     IF INT(I/2)*2 = I THEN *EXIT2
1380         WHILE (J<SQR(I)) AND (INT(I/J)*J<>I)

ここ、多くの処理系では割り算よりも掛け算のほうが速いと聞いたことがあるので、
割り算を２回するのではなく掛け算と割り算の組み合わせに変更してみました。
これでどのくらい早くなるかは測定していないからわからない。
処理系によっては、むしろ遅くなったりして。
konnoさんオリジナルのロジックよりは、使う変数も少なくなっている分だけ速く
なってるかもしれないけど、こんなもん、最近のコンパイラなら最適化してくれる
でしょ、という範囲かもしれない。
あとはまぁ、PC-88などの８ビットマシンならDMAを停めるとか、ナノピコ秒単位で
速度を稼ぐためにインデントを全て削除してマルチステートメント化するとか、
他にもいろいろと思いつく技はいくつかありますけどね。そこまではしていません。

> アップロードしました。
> tp://toshiki.la.coocan.jp/prime88.zip

早速落として NP2 で動かしてみました。
#11162 で
> BASIC.COM がコンパイラなんですね。
なんて書きましたが、正しくは BACICC.COM でした。
BASIC Compiler ということなのですね。(^^;

B.BAT
basicc %1.bas %1.exe %1.lib
%1.exe

これを見て間違いに気が付きました。(^^;

さて、実行してみてまず気が付いたのは、変数 MAX の表示が
1E+08
になっていました。浮動小数点の表示形式ですね。

1070 MAX=100000000#

えーと、定数の末尾に # を付けているのは倍精度指定なのですか？
変数 MAX は単精度のように思われます。

> > といいつつ、特にファイル書き込みの部分はろくに動作確認をしていないのだけど。

オプション指定 1 で ファイルがキチンと出来ました。
ただ、素数の個数が私のと違いますね。

p1000.DAT
Number.1000	  0: 0' 0   Prime Number = 168 

n1000.DAT　　N88
Number.1000	  0: 0: 1   Prime Number = 169 

どちらかがカウント数を間違っているかと思い、VZで比較したら

p1000.DAT
 167 
 173 

n1000.DAT　　N88
 167 
 169 		※ この行が多い
 173 

169 は、13*13=169 なので、素数では無いと思います。
今日は眠いのでこれ以上の調査は明日以降ということで。(^^;

> えーと、定数の末尾に # を付けているのは倍精度指定なのですか？
> 変数 MAX は単精度のように思われます。

おっしゃるとおりです。
変数を全て単精度指定に変更するときに修正をもらしたようです。
ただ、こちらは大勢に影響がありませんが

> 169 は、13*13=169 なので、素数では無いと思います。

こっちは大問題ですね。仕様どおりの挙動をしないのですから。
倍精度から単精度に精度を落としたことが悪いのか、それとも割り算と掛け算の
誤差の問題か。
いつ調査できるかわかりませんが、解決は図りたいと思います。

> > 169 は、13*13=169 なので、素数では無いと思います。
> 
> こっちは大問題ですね。仕様どおりの挙動をしないのですから。
> 倍精度から単精度に精度を落としたことが悪いのか、それとも割り算と掛け算の
> 誤差の問題か。

私は当初 NP2 のCPUエミュレーション等のバグを疑いました。
それで、anex86 でも試したのですが、結果は同じ。98NEXT では固まってしまいました。

次に疑ったのが、BASICコンパイラが壊れていないか。
1988/08/24  00:00            61,440 BASICC.COM
中身が壊れているることもありうるので、98実機での結果が知りたいところですね。

条件を色々変えて試しても結果は変わらなかったのですが、ひとつだけ

N88P.BAS
100 INPUT N
110 IF N MOD 2=0 THEN 120 ELSE *ELSE1
120     IF N=2 THEN PRINT "素数" ELSE PRINT "合成数"
130     GOTO *ENDIF1
140 *ELSE1
150     I=3
160     WHILE (I<=SQR(N)) AND (N MOD I<>0)
170         I=I+2
180     WEND 
190     IF I<=SQR(N) THEN PRINT "合成数" ELSE PRINT "素数"
200 *ENDIF1
202 input a
210 END

このプログラムでは、169 は「素数」と表示されます。
ところがオリジナルを若干修正した以下

PN88.BAS
100 'pn88.bas 
110  defdbl a-z                                 '倍精度指定
1000 INPUT n
1010 IF (n MOD 2)=0 THEN IF n=2 THEN PRINT "素数" ELSE PRINT "合成数"
1020 j!=sqr(n) 'ELSE
1030   FOR i!=3 TO SQR(n) STEP 2
1040     IF n MOD i!=0 THEN *EXIT1 
1050   NEXT i!
1052   *EXIT1
1060   IF i!<=SQR(n) THEN PRINT "合成数";i!;j! 
1062   IF i!>SQR(n) THEN PRINT "素数";i!;j!
1070 input a 'END IF
1080 END

このプログラムでは、169 は「合成数」と表示されます。
違いは、変数全体を倍精度にし、FOR 文の変数を単精度にしただけかな。
＃　うーん、これを反映させても改善しない。何故だー！　(;_;)

> ここ、多くの処理系では割り算よりも掛け算のほうが速いと聞いたことがあるので、
> 割り算を２回するのではなく掛け算と割り算の組み合わせに変更してみました。
> これでどのくらい早くなるかは測定していないからわからない。
> 処理系によっては、むしろ遅くなったりして。

なるほど、そういうやり方もあるのですね。
このプログラムで 10000 指定の実行結果は

Number.10000	  0: 0:30   Prime Number = 1233 

このソースを私の FOR 文のに置き換えてみた結果は

Number.10000	  0: 0: 8   Prime Number = 1233 

実行時間が短縮されました。
コンパイラでは最適化でインタプリタと違う結果になるようです。
どこがどう効いたかわからないので、変更ソースを上げます。

1320 *START
1330 TM$=TIME$
1340 I=2:GOSUB *PRINT1
1350 FOR I=3 TO N                                        '★
1360  ' IF INT(I/2)*2 = I THEN *EXIT2                    '☆
1362   i2=i/2:i3=int(i/2):IF i2=i3 THEN goto *EXIT2      ' 合成数
1370 '    J=3                                            '☆
1380 '    WHILE (J<SQR(I)) AND (INT(I/J)*J<>I)           '☆
1382      FOR J=3 TO int(SQR(I)) STEP 2                  '★ 偶数をスキップ
1390 '      J=J+1                                        '☆
1392        I2=I/J:I3=INT(I/J):IF I2=I3 THEN GOTO *EXIT1 '★ 合成数
1400 '      WEND                                         '☆
1402      NEXT J                                         '★
1404      *EXIT1                                         '★
1406 '     if i=169 then print "   13 =";i;sqr(i);j:goto *exit2
1408 '     IF i=169 then if J=SQR(I) THEN *EXIT2
1410      IF SQR(I)<J THEN GOSUB *PRINT1
1420   *EXIT2
1430 NEXT I
1440 I=I-1

ちなみに、VGA版の結果は

Number.10000	  0: 0' 1   Prime Number = 1229 

結果の素数の数が 4 違いますね。

---  N88  --- 
 169 	13*13
 5041 	71*71
 6241 	79*79
 9409 	97*97

10000 で 4 箇所 合成数が含まれています。
何が原因かわからないです。

不具合の原因がわかりました。
SQR() 関数の結果判定に問題が有ったようです。

PRIME98.BAS

1320 *START
1330 TM$=TIME$
1340 I=2:GOSUB *PRINT1
1350 FOR I=3 TO N                                   '
1360   i2=i/2:i3=int(i/2):IF i2=i3 THEN *EXIT2      ' 合成数
1370      j2=int(SQR(I))                            '
1380      FOR J=3 TO j2 STEP 2                      ' 偶数をスキップ
1390        I2=I/J:I3=INT(I/J):IF I2=I3 THEN *EXIT2 ' 合成数
1400      NEXT J                            
1410    IF J>SQR(I)+.0001 THEN GOSUB *PRINT1        '★
1420 *EXIT2
1430 NEXT I
1440 I=I-1

このように、SQR() に +0.0001 を足したら問題が解消されました。
計算精度の問題か、最小桁が切り捨てられているのでしょうか。
いくつ足せばいいのか桁を変えて試してみました。

1410    IF J>SQR(I)+.000001 THEN GOSUB *PRINT1		ng
Number.10000	  0: 0:29   Prime Number = 1233 
169  5041  6241  9409 	ng

1410    IF J>SQR(I)+.00001 THEN GOSUB *PRINT1		ng
Number.10000	  0: 0:30   Prime Number = 1232 
5041  6241  9409 	ng

1410    IF J>SQR(I)+.0001 THEN GOSUB *PRINT1		ok
Number.100000	  0: 2:29   Prime Number = 9592 

どうも N88BASIC の問題のような気がしますが、実機でどうなるか知りたいですね。

あ、これはまずい。

> このプログラムで 10000 指定の実行結果は
> Number.10000	  0: 0:30   Prime Number = 1233 
> このソースを私の FOR 文のに置き換えてみた結果は
> Number.10000	  0: 0: 8   Prime Number = 1233 
> 実行時間が短縮されました。

この差は大きすぎる。プログラムに間違いがあるから。

> 1382      FOR J=3 TO int(SQR(I)) STEP 2                  '★ 偶数をスキップ
> 1390 '      J=J+1                                        '☆

ここのところ、STEP 2 なんだから、J=J+2 でなければならない。
単純にループ回数が2倍になってしまう。
ということで、おそらく、30秒は15秒ぐらいまで短縮できるはずだけど、それでも
やっぱり8秒までは縮まらないと思う。

SQR関数の精度のほうは、どうしようかな。

SQRの計算を自前で出来ないか検索してみました。
「本の虫」のサイトの「平方根のアルゴリズム 」
https://cpplover.blogspot.com/2010/11/blog-post_20.html

ここがわかりやすかったのでここから引用します。
-----------------------------------------------------------

ここで使うのは、バビロニア人の方法（Babylonian method）と呼ばれている、歴史あるアルゴリズムである。
この方法は、手動でも、プログラミングでも、非常に簡単に計算できる、大変便利で汎用的なアルゴリズムである。
しかも、速度もそれほど遅くない。 

double sqrt( double s )
{
    double x = s / 2.0 ; // Is there any better way to determine initial value?
    double last_x = 0.0 ; // the value one before the last step

    while ( x != last_x ) // until the difference is not significant
    { // apply Babylonian method step
        last_x = x ;
        x = (x + s / x) / 2.0 ;
    }
    
    return x ;
}

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

これを TurboBasic に置き換えたテストが

3000 ' SQR1.BAS
3010 'defdbl a-z
3020 screen 0
3030 cls
3040 input s
3050 x = s / 2.0  '; // Is there any better way to determine initial value?
3060 lastx = 0.0 '; // the value one before the last step
3070 '    while ( x != lastx ) '// until the difference is not significant
3080 'loop1:
3090        lastx = x 
3100        x = (x + s / x) / 2.0 
3110   if   x <> lastx  then 3080 'loop1
3120   print "SQR(";s;")=";x,lastx
3130   input a
3140 end

3020行をコメントにすれば N88BASIC でも動作します。
これをサブルーチンにして PRIME88.BAS に貼り付けて

1320 *START
1330 TM$=TIME$
1340 I=2:GOSUB *PRINT1
1350 FOR I=3 TO N
1360     IF INT(I/2)*2 = I THEN *EXIT2
1370         J=3
1375         s=I:gosub 3050:s=xx                '★
1380         WHILE (J<s) AND (INT(I/J)*J<>I)    '★
1390             J=J+1                          '★★
1400         WEND
1410         IF J>s THEN GOSUB *PRINT1          '★
1420     *EXIT2
1430 NEXT I
1440 I=I-1

この結果は
Number.10000	  0: 0:14   Prime Number = 1229 

おお、素数が合ってるし、時間が半分になりました。
SQR()関数を2回実行していたのをサブルーチン1回にしたのが効いたみたいです。

さらに、★★ のところを
1390             J=J+2                          '★★
このように +2 に変更した結果
Number.10000	  0: 0: 9   Prime Number = 1229 

おお、時間がさらに短縮して、FOR文のループとほぼ同じになりました。
ちなみに FOR文のソースにこのサブルーチンを組み込んだら
Number.10000	  0: 0:11   Prime Number = 1229 

２〜３秒遅くなりましたね。これが関数とサブルーチンの速度差と思われます。
思ったよりも差が無いなぁ、というのが感想です。(^^;

素数のネタはこの辺でしまいにしたいところですね。

> これを TurboBasic に置き換えたテストが

えと、whileのループをifのジャンプに変更したのはなぜでしょうか。
こちらのほうが速いのですか？

> 素数のネタはこの辺でしまいにしたいところですね。

そうですね。
明日、３１日に実家へ行くので、時間が取れたら実機でいくつか試したいところ。
実は、父の命日が３１日なんですよ。
ただ、日が近いということで、多くの場合、墓参りはお彼岸に集約されています。
天候だとか諸事情でお彼岸に墓参りできないときだけ命日に墓参り、と言う感じ
なのですが、まぁいろいろと存在しない事情をでっち上げて実家に顔を出すところ
まではアポイント済み。ただ、時間が取れるかどうかは別問題なんで。
 

実家に来ています。
まず、先日アップしたあのプログラムをそのまま実行したのですが

> Number.1000	  0: 0' 0   Prime Number = 168 

うちのN88-BASICでは、素数の数が168になりました。
169は素数としてカウントされませんでした。
どうやらSQR関数、うちの環境のほうが精度が高いらしい。
ちなみに、ファイル出力ではなく画面表示で、所要時間は0秒〜1秒くらい。
あまり違いはないですね。

とりあえず時間切れ、続きは後ほど。

続いて、先日上げたプログラムのまま、すなわち、SQR関数の部分もいじらず、
変数Jのカウントアップも1ずつのままで10000までの結果。

> Number.10000	  0: 0' 1   Prime Number = 1229 

素数の数は1229と出ました。やっぱりうちの環境では誤差がないみたい。
ちなみに、所要時間は、画面表示だと12秒、ファイル出力だと13秒。
これはいささか直感と記憶に反している。
記憶だと、画面表示のほうがスクロールアップに時間がとられるので遅くなったはず
なのですがね。ま、でも、誤差の範囲。

次、変数 J のカウントアップを J=J+2 としたら所要時間は7秒まで短縮。
やっぱりループ回数が２倍というのは大きかった模様。
素数の数は1229なので、計算誤差の問題もないですね。

ところで、うちのBASICインタープリタは1987年製のVer5.0というやつです。
konnoさんのところの版数とかはわかりますか？

実家での検証、最後。

> ここ、多くの処理系では割り算よりも掛け算のほうが速いと聞いたことがあるので、
> 割り算を２回するのではなく掛け算と割り算の組み合わせに変更してみました。
> これでどのくらい早くなるかは測定していないからわからない。

メインのループを

1350 FOR I=3 TO N
1360     IF INT(I/2)*2 = I THEN *EXIT2
1370         J=3:I2=I/J:I3=INT(I/J)
1380         WHILE J<SQR(I) AND I2<>I3
1390             J=J+2:I2=I/J:I3=INT(I/J)
1400         WEND
1410         IF J>SQR(I) THEN GOSUB *PRINT1
1420     *EXIT2
1430 NEXT I

こうやって、割り算2回で20000までの素数を求めたら21秒で2262個。
元のままの、割り算と掛け算だと17秒、2262個。
うん、やっぱりうちでは、誤差というには差が大きいくらい、掛け算のほうが早い
模様。


以上、レス元が分散して申し訳ありませんが、実家での検証３連発でした。

> えと、whileのループをifのジャンプに変更したのはなぜでしょうか。
> こちらのほうが速いのですか？

私は while文をあまり使わないので、無意識に 慣れた IF文に変えてしまってました。(^^;
オリジナルのソースに wend を入れるだけでしたね。(^^;

#11179 で書きましたが
> ちなみに FOR文のソースにこのサブルーチンを組み込んだら
> Number.10000	  0: 0:11   Prime Number = 1229 
> ２〜３秒遅くなりましたね。これが関数とサブルーチンの速度差と思われます。

同じ条件では、while文の方が速いと思われます。
そこで、このサブルーチンの while と FOR で比較してみました。

FOR文     Number.100000   0: 2:51   Prime Number = 9592 
WHILE文   Number.100000   0: 2:47   Prime Number = 9592 

１０万で4秒の差でした。思ったよりも差が小さかったですね。
SQR １回あたり７〜１０回程度のループで済んでいるから差が小さいのでしょう。

> なのですが、まぁいろいろと存在しない事情をでっち上げて実家に顔を出すところ
> まではアポイント済み。ただ、時間が取れるかどうかは別問題なんで。

お手間を取らせて申し訳ないですが、よろしくお願いします。

ここにまとレスします。

> > Number.1000	  0: 0' 0   Prime Number = 168 
> うちのN88-BASICでは、素数の数が168になりました。
> 169は素数としてカウントされませんでした。
> どうやらSQR関数、うちの環境のほうが精度が高いらしい。

これは驚きです！　ということは、９８エミュの問題か、ファイルが壊れているかですね。

> ちなみに、所要時間は、画面表示だと12秒、ファイル出力だと13秒。
> これはいささか直感と記憶に反している。

TurboBasic でも同じような結果です。画面表示は遅いというのは思い込みなのでしょう。

> ところで、うちのBASICインタープリタは1987年製のVer5.0というやつです。
> konnoさんのところの版数とかはわかりますか？

88-BASIC(86) Compiler version 6.0 
1988/08/24  00:00            61,440 BASICC.COM

うちで使用したコンパイラ版はこれですね。

> こうやって、割り算2回で20000までの素数を求めたら21秒で2262個。
> 元のままの、割り算と掛け算だと17秒、2262個。
> うん、やっぱりうちでは、誤差というには差が大きいくらい、掛け算のほうが早い
> 模様。

なるほど。やはり掛け算が速いのですね。

> 以上、レス元が分散して申し訳ありませんが、実家での検証３連発でした。

お忙しい中色々検証していただき、ありがたいです。
N88BASICの精度疑惑も晴れたので、９８エミュの検証が必要そうですね。

以前N88BASICが動かなかったT98-NEXT で再挑戦しました。
コンパイラ版が動かなかったのはメモリ不足だったようです。
ATOK8がメインメモリに居座っていたので削除したら動きました。(^^;
ただし、BATのオプションが効かなくて、ソースファイル名を手打ちしました。(^^;
結果はほかのエミュと同じで駄目でした。

インタプリタも、実機ROMにチェックを入れたら動きました。
結果はやっぱり駄目でした。
98エミュは全滅です。

うーむ、このバージョンの N88BASIC に問題がある可能性があるのでしょうか。

> これは驚きです！　ということは、９８エミュの問題か、ファイルが壊れているか

エミュの問題、というのは考え易いところです。
が、ファイルの破壊となった場合、そんな精度に関係するところが絶妙に壊れる、
というのはなかなか考えにくい。
ただ、N88(86)では使っていない技術だとは思いますが、いくつかの処理系では、
関数の速度と精度向上のため、全てを計算で求めるのではなく、大きな定数表を
使う場合がある、と聞いたことはあります。とはいっても超巨大というほどの表
ではなく、引数のいくつかに分解して、それぞれの結果を足すとかかけるとかで
速度と精度を両立させます。
その場合は、その定数表の一部だけが間違っているとか精度が足りないことが発生
しうるわけです。でも、これって、三角関数とか対数関係の関数で使うワザだった
ような気がする。
平方根でも使うことがあるのかなぁ。

> 88-BASIC(86) Compiler version 6.0 
> 1988/08/24  00:00            61,440 BASICC.COM

これ、頭のNが欠けているのは転記ミスですよね。
実は、私の記憶でも、88年のVer6が最終版、ということになっているからです。
そして私の手元には87年のVer5しかないわけですが、バージョンアップするかどうか
という判断に際して、どこが変わったかという情報がなくてバージョンアップを
しなかった、というおぼろげな記憶があります。
ところでkonnoさんのところでは、TurboBasicではなく、N88BASICのコンパイラと
インタプリタで同じ結果になります？
あと、インタプリタとコンパイラでバージョンは同じですか？

こちらの掲示板での過去ログ表示で気がつきました。
[全部表示 会議室風]のリンクを押して表示される発言の中に、そのログのトップの
ツリーのルートの発言が含まれていないようです。
具体的には

過去ログ26では#10734
過去ログ25では#10632
過去ログ24では#10229
・・・
過去ログ2では#974
過去ログ1では#418

が表示されないようです。
ご確認をお願いします。

> その場合は、その定数表の一部だけが間違っているとか精度が足りないことが発生
> しうるわけです。でも、これって、三角関数とか対数関係の関数で使うワザだった
> ような気がする。
> 平方根でも使うことがあるのかなぁ。

原因が分かったような気がします。
N88BASIC(86) では、FOR文が倍精度では動かないので単精度でやって NG だったのですが
1030 defdbl A-Z　と変数を倍精度にし、FOR文の I だけ I! で単精度でやってみました。

1340 I=2:GOSUB *PRINT1
1342 i=3
1350 FOR I!=3 TO N
1360     IF INT(I/2)*2 = I THEN *EXIT2
1370         J=3
1380         WHILE (J<SQR(I)) AND (INT(I/J)*J<>I)
1390             J=J+1
1400         WEND
1410         IF J>SQR(I) THEN GOSUB *PRINT1
1420     *EXIT2
1422 i=i+1
1430 NEXT I!
1440 I=I-1

他は変えていませんが、このプログラムでは 169 が表示されず、正常になりました。
＃ 汚れていたのは SQR(I) だったんです。（By now shika）

変数 I が倍精度だと数値の比較が正常なのに、単精度だと 表示は整数でも内部の計算がズレる模様。
想像ですが、例えば比較計算は倍精度で、表示は単精度に丸められているとか。

> > 88-BASIC(86) Compiler version 6.0 
> > 1988/08/24  00:00            61,440 BASICC.COM
> これ、頭のNが欠けているのは転記ミスですよね。

はい、そうです。失礼しました。m(__)m

> ところでkonnoさんのところでは、TurboBasicではなく、N88BASICのコンパイラと
> インタプリタで同じ結果になります？

同じ結果になります。上の実験はインタプリタではしてないですが。

> あと、インタプリタとコンパイラでバージョンは同じですか？

同じだと思います。起動メッセージが同じなので。
日付は少し違いますね。

> こちらの掲示板での過去ログ表示で気がつきました。
> [全部表示 会議室風]のリンクを押して表示される発言の中に、そのログのトップの
> ツリーのルートの発言が含まれていないようです。

げげげ、・・・・・・

確認しました。しばしお待ちください。m(__)m

「妙だな」というのは、どこぞの小学生のよく言うせりふですが、それはさておき。
#11164にも書きましたが、N88だと単精度でも倍精度でも上限は同じです。
また、演算速度が単精度の方が速いという理由から私は全て単精度でやっているの
ですが、konnoさんが倍精度を選ばれている理由は何ですか？
他のBASICだと上限が違うとかあるのでしょうか。

さて、私のコードでは全て単精度でやっています。なので、精度変換の問題は出ない
はず。実際、うちでは問題が出ていません。
でも、#11173では、同じコードで問題が出ているということです。
なので、これは精度変換の問題ではないと思われます。


> 他は変えていませんが、このプログラムでは 169 が表示されず、正常になりました。

このプログラムだと、単精度の I! と倍精度の I の両方でカウント処理が発生します。
倍精度の I だけ使って WHILE のループにしたほうがいいような気がします。


> 想像ですが、例えば比較計算は倍精度で、表示は単精度に丸められているとか。

N88のマニュアルでは、異なる型同士での演算の場合は高い精度のほうに合わせて
行われるとのこと。これは比較演算でも同じはず。

で、私の疑っていた、konnoさんのところのコンパイラとインタプリタのバージョン
違いという疑いは晴れたので、するとあとは、私のところのバージョンとkonnoさん
のところのバージョンが異なる、という問題は残ります。
とりあえず、出発点は#11173。同じコードなのに結果が異なる、ということ。
あ、重要な問題がある。
私がもしかしたら、アップしたのとは異なるコードを実行していた可能性。
実はこの可能性が一番高いかも。

自分で実験できないのにあれこれ言って申し訳ありません。

> 条件を色々変えて試しても結果は変わらなかったのですが、ひとつだけ
> N88P.BAS
> ところがオリジナルを若干修正した以下
> PN88.BAS

N88P.BASとPN88.BAS、konnoさん的には「若干修正」かもしれませんが、内部的には
もしかしたら大幅な修正かもしれません。
そこで結果を教えていただきたいのが、

> PN88.BAS
> 110  defdbl a-z                                 '倍精度指定

ここを単精度指定にしたらどうなるか、ということ。
とても興味があります。

> > [全部表示 会議室風]のリンクを押して表示される発言の中に、そのログのトップの
> > ツリーのルートの発言が含まれていないようです。
> 確認しました。しばしお待ちください。m(__)m

ううう、3日間腐海暗闇の中で藻掻いていました。(;_;)

wforum.cgi を色々弄ってみましたがどうやってもルート発言が表示されません。(>_<)
仕方がないので過去ログの先頭に改行を追加してみたら表示されました。
うげぇ、今までの苦労は何だったんだ・・・・

唯の改行だとツリー表示にゴミが表示されるので、現行ログの形式でダミーを入れました。

0001<>00.00.00.00<>1097421569<>
番号　IPアドレス　書き込み時間（古ければスキップ？）

このように、書き込み時間が古ければ自動的にスキップしてくれるようです。
この処理をどこでやっているのかはわかりません。
色々弄った版はツリー表示がおかしくなったので、修正前のに戻したら直りました。

結局 cgi は弄らずに、過去ログ形式を変更することで解決しました。(-_-;) ﾔﾚﾔﾚﾀﾞｾﾞ
何かおかしなところに気が付いたら教えてください。m(__)m

> #11164にも書きましたが、N88だと単精度でも倍精度でも上限は同じです。
> また、演算速度が単精度の方が速いという理由から私は全て単精度でやっているの
> ですが、konnoさんが倍精度を選ばれている理由は何ですか？

N88 は FOR文のカウントに倍精度が使えない制限があるようです。
それで単精度でやったら問題が出たので、倍精度でやり直してみたという経緯です。

> さて、私のコードでは全て単精度でやっています。なので、精度変換の問題は出ない
> はず。実際、うちでは問題が出ていません。
> でも、#11173では、同じコードで問題が出ているということです。
> なので、これは精度変換の問題ではないと思われます。

私は N88BASIC の特定のバージョン（V6.0）の問題なのではないかと疑っています。
もちろん ９８エミュの問題の可能性も排除できないので実機で確認したいのです。

> > 他は変えていませんが、このプログラムでは 169 が表示されず、正常になりました。
> このプログラムだと、単精度の I! と倍精度の I の両方でカウント処理が発生します。
> 倍精度の I だけ使って WHILE のループにしたほうがいいような気がします。

私は while の入れ子は特に間違えやすいので、FOR文でやりました。
結果は同じになると思います。

> N88のマニュアルでは、異なる型同士での演算の場合は高い精度のほうに合わせて
> 行われるとのこと。これは比較演算でも同じはず。

なるほど、それで謎の挙動がわかったような気がします。
比較の実験結果をあげてみます。

> > PN88.BAS
> > 110  defdbl a-z                                 '倍精度指定
> 
> ここを単精度指定にしたらどうなるか、ということ。
> とても興味があります。

丁度良いテストプログラムを作ったので上げます。

3000 ' SQR88.BAS
3010 'defdbl a-z
3012 defsng a-z
3020 'screen 0
3030 cls
3040 input s
3042 OPEN "SQR.dat" FOR OUTPUT AS #1
3046 cc=0
3050 x = s / 2.0  '; // Is there any better way to determine initial value?
3060 lastx = 0.0 '; // the value one before the last step
3070 'while ( x != lastx ) '// until the difference is not significant
3090      lastx = x 
3100      x = (x + s / x) / 2.0 
3112      cc=cc+1
3114      print x;lastx,cc
3116      print#1, x;lastx,cc
3110  if   x < lastx  then 3070
3120  print "SQR(";s;")=";x,lastx,cc
3122  print#1, "SQR(";s;")=";x,lastx,cc
3124  close
3130  input a
3140 end

このプログラムで、TurboBasic の結果は

単精度
 43.25              84.5                   1 
 23.57875633239746  43.25                  2 
 15.37311267852783  23.57875633239746      3 
 13.18316555023193  15.37311267852783      4 
 13.00127220153808  13.18316555023193      5 
 13                 13.00127220153808      6 
 13                 13                     7 
SQR( 169 )= 13   13      7 回

倍精度
 43.25              84.5                   1 
 23.57875722543352  43.25                  2 
 15.37311286945074  23.57875722543352      3 
 13.18316604902914  15.37311286945074      4 
 13.00127244856782  13.18316604902914      5 
 13.00000006226796  13.00127244856782      6 
 13                 13.00000006226796      7 
 13                 13                     8 
SQR( 169 )= 13   13       8 回

倍精度の方が収束するのに１回多く掛かっています。
どちらでも計算は倍精度でやっているのがわかります。
一方、N88BASIC の結果は

単精度
 43.25            84.5             1 
 23.5788          43.25            2 
 15.3731          23.5788          3 
 13.1832          15.3731          4 
 13.0013          13.1832          5 
 13               13.0013          6 
 13               13               7 
SQR( 169 )= 13  13    7 回

倍精度
 43.25              84.5                   1 
 23.57875722543353  43.25                  2 
 15.37311286945074  23.57875722543353      3 
 13.18316604902914  15.37311286945074      4 
 13.00127244856782  13.18316604902914      5 
 13.00000006226796  13.00127244856782      6 
 13                 13.00000006226796      7 
 13                 13                     8 
 13                 13                     9 
SQR( 169 )= 13   13      9 回

おや、単精度の場合は SQR の計算も単精度なのか、それとも表示だけなのか？
倍精度では収束したのにさらにもう１回多く計算しています。？？？
この結果は、WHILE 文にしても同じでした。
そして、単精度の時だけ 169 が素数と誤判定しているのです。

このことから私は、「＞」や「＞＝」などの比較式で単精度の時だけ誤差が出ていると疑ったのです。
V6.0に問題が有るかどうかは、実機で確認する以外にわからないと思います。

> 仕方がないので過去ログの先頭に改行を追加してみたら表示されました。

この現象から見ると、過去ログと現行ログでの分岐に問題がありそうですね。
まさかと思いますが、そもそも分岐していない、とか。

> この処理をどこでやっているのかはわかりません。

もともとこのルーチン、作ったのはkonnoさんですから。
作った本人がわからないようではどうしようもありません。
もう大丈夫だとは思いますが、不要なコメント、とかいう目くらましにやられて
いる、ということはないでしょうか。

とりあえず、今のところは問題ないような感じです。

> N88 は FOR文のカウントに倍精度が使えない制限があるようです。

そです。
これはマニュアルにも明記されている仕様です。

> それで単精度でやったら問題が出たので、倍精度でやり直してみたという経緯です。

なるほど、いきさつが理解できました。

> 私は N88BASIC の特定のバージョン（V6.0）の問題なのではないかと疑っています。

現時点では、私もこの線が濃厚だと思っております。

> 私は while の入れ子は特に間違えやすいので、FOR文でやりました。

BASICを極めたいのならWHILEは避けて通れません。
私もかなり錆付いてはいますが、まだkonnoさんより私のほうが、BASICに関しては
一日の長がありそうな感じ。

> 結果は同じになると思います。

いや、結果の問題ではなく速度の問題。
加算するのはループカウンタだけでいいでしょう、ということです。

> 3000 ' SQR88.BAS

これ、あとで私も検証してみます。最短で今日の午後。

> このプログラムで、TurboBasic の結果は

> どちらでも計算は倍精度でやっているのがわかります。

ダウト。

> 単精度
>  43.25              84.5                   1 
>  23.57875633239746  43.25                  2 

> 倍精度
>  43.25              84.5                   1 
>  23.57875722543352  43.25                  2 

もうここですでに値が異なります。
すなわち、表示だけ倍精度、という可能性が濃厚。

> おや、単精度の場合は SQR の計算も単精度なのか、それとも表示だけなのか？

N88の場合、仕様では、引数の型が結果の型、ということになっています。
このプログラムでは、2.0 という単精度型で割り算をしています。
ここを 2# としてみたら、もしかしたら違いが出てくる可能性があります。

実家に来ています。
うちの母、風邪気味だというのに買い物に行きたいのだとか。
母と同居しているうちの弟、免許すら持っていないので、その手の案件は私が対応。
ということで、まもなく連れ出されてしまいますが、その前に。

まず、うちのN88BASIC、コンパイラはありません。
タイムスタンプは以下。

N88BASIC EXE       161,280 87-10-30    0:00
N88BASIC LIB       178,176 86-08-14   13:51

ん〜、ライブラリのほう、もしかしたらバージョンが古いかも。
そして、この環境で

> 丁度良いテストプログラムを作ったので上げます。
> 3000 ' SQR88.BAS

このプログラムを load して list をみたら、

3050 X = S / 2!  '; // Is there any better way to determine initial value?
3100      X = (X + S / X) / 2! 

と、自動で変換されてしまっていました。
もしかしたらkonnoさんのところでも、この手の意図せざる自動変換が発生している
かもしれません。当然、コンパイラのほうでも。
一度、インタプリタのほうで list をたたいて、自動変換の有無を確認されたほうが
いいでしょう。

そして、読み込ませてすぐに run させたら、あれ？
konnoさんのところと実行結果が異なる。
何が異なるって、途中経過が一切表示されない。妙だな。
よくリストを見たら、結果表示がループの外に出ている。
こういうトリックはやめて欲しいけど、でも私も良くやるので人のことは言えない。
とりあえず、3110行の if 文を3123行に持ってきて、ここで時間切れ。

続きは帰宅後。
何時ぐらいになるかなぁ。

> 続きは帰宅後。

続きです。

> よくリストを見たら、結果表示がループの外に出ている。
> こういうトリックはやめて欲しいけど、でも私も良くやるので人のことは言えない。

違う。
結果表示が改行されず、同一行に上書きされているような感じ。
つまり、トリックは私が仕掛けた、ということで。
大変失礼しました。
そして、私が悪かったにもかかわらず

> とりあえず、3110行の if 文を3123行に持ってきて、ここで時間切れ。

こんなことをやったから、出力書式がめちゃくちゃ。
とりあえず、konnoさんと同じような書式にVzでそろえた結果です。

単精度2.0
 43.25  84.5   1 
 23.5788  43.25              2 
 15.3731  23.5788            3 
 13.1832  15.3731            4 
 13.0013  13.1832            5 
 13  13.0013   6 
 13  13        7 
SQR( 169 )= 13               13            7 

倍精度2.0
 43.25  84.5   1 
 23.57875722543353  43.25    2 
 15.37311286945074  23.57875722543353      3 
 13.18316604902914  15.37311286945074      4 
 13.00127244856782  13.18316604902914      5 
 13.00000006226796  13.00127244856782      6 
 13  13.00000006226796       7 
 13  13        8 
 13  13        9 
SQR( 169 )= 13               13            9 

念のため、2! のところを全て 2# にしてみたけど、結果は同じでした。

どうも、見たところ、結果は全て同じ。
収束したのに１回多くループを回っているところも同じ。
にもかかわらず、うちの環境では、169は素数にならない。
まだアップしたままのprime88.zipを再度落としてみて、ファイル比較して同じもので
あることも確認済み。そして、名前を変えて、新しく落としたほうを実行してみて
169が素数にならないことも確認済み。

何じゃこりゃ。

> > 仕方がないので過去ログの先頭に改行を追加してみたら表示されました。
> 
> この現象から見ると、過去ログと現行ログでの分岐に問題がありそうですね。
> まさかと思いますが、そもそも分岐していない、とか。

うう、そのまさかでした。(>_<)

	open(IN,"$logfile") || &error("Open Error: $logfile");
	$top = <IN>;

こうなっていたところを
#	$top = <IN>;
	$top = <IN> if ($in{'act'} ne "past");

こう変更したら今までの過去ログファイルのままでも正常になりました。
うう、これも試していたのに弄りすぎておかしくなっていたようです。(>_<)
アドバイスありがとうございました。m(__)m

訂正、ではないような。
補足、かな。

> > よくリストを見たら、結果表示がループの外に出ている。
> > こういうトリックはやめて欲しいけど、でも私も良くやるので人のことは言えない。
> 
> 違う。
> 結果表示が改行されず、同一行に上書きされているような感じ。
> つまり、トリックは私が仕掛けた、ということで。

結果表示が上書きのよう、というのはそのとおりなんですが。
結果表示がループの外、というトリックは、やっぱりkonnoさんだった。

#11195より

> 3070 'while ( x != lastx ) '// until the difference is not significant
> 3090      lastx = x 
> 3100      x = (x + s / x) / 2.0 
> 3112      cc=cc+1
> 3114      print x;lastx,cc
> 3116      print#1, x;lastx,cc
> 3110  if   x < lastx  then 3070
> 3120  print "SQR(";s;")=";x,lastx,cc
> 3122  print#1, "SQR(";s;")=";x,lastx,cc

これ、行番号順に並んでいないじゃないのよさ。
BASICの場合、行番号順に実行されるわけですから、実行時には

> 3070 'while ( x != lastx ) '// until the difference is not significant
> 3090      lastx = x 
> 3100      x = (x + s / x) / 2.0 
> 3110  if   x < lastx  then 3070
> 3112      cc=cc+1
> 3114      print x;lastx,cc
> 3116      print#1, x;lastx,cc
> 3120  print "SQR(";s;")=";x,lastx,cc
> 3122  print#1, "SQR(";s;")=";x,lastx,cc

となるわけでして。
まったくもう。
前にも書いたと思いますが、もうちょっと行番号の並びとかインデントに気を配って
プログラムを書いていただけないでしょうか。
バグが混入し易くなりますよ、と、繰り返しお伝えしていますよね。
こうやって、残り少ない人生を無駄にしてしまうわけですから。

でも、このプログラムだと、N88なら、ループ内での途中表示は全くないはず。
つまり、#11195の結果は出ないはず。
すると、あの結果はどうやって出したのだろう。
結果の出たあと、プログラムを書き換えてからアップした？
違う処理系での結果をN88での結果と間違えて書いた？



それはさておき。
ゆっくり入浴していたときにつらつらと思い出したこと。
大学時代の情報処理初級の授業で、丸め誤差と打切り誤差、桁落ち、情報落ちの
違い、なんてことをやったわけですよ。もはやほとんど覚えていませんがね。
そして、そういった誤差をなくすための方法として多倍長精度演算というのがある、
ということも思い出しました。こいつをやるとてきめんに遅くなるのですが、誤差も
非常に少なくなる。多倍長用のuBASICというのを知ったのは、確か私が大学を卒業
した直後ぐらいだったか。
多倍長っていうのは、例えば、１バイトに数字一桁しか格納しない、という方法。
実際の実装では、そんなことやっていたらメモリ効率が悪いので、１バイトに０から
99までの２桁の数字を格納する、なんていうのが多いかな。８６のアセンブラにも
それようの命令があったんじゃないかな、BCD演算、というやつ。Z80にはあった
ような気がする。
そしてアセンブラにあるくらいだからBASICにもあるわけでして、もしかしたら上記
のuBASICがそうだったかもしれないけど、10進BASICという実装があったはず。

で、話を戻して、誤差。

> 3110  if   x < lastx  then 3070

こいつを

> 3110  if   x < lastx  then print "div=",lastx-x:goto 3070

とやってみたらどうでしょう。
１回多くループするところで、いったい何がおきているのか見えてくるかも。

まとレスで失礼します。

> ダウト。
> >  23.57875633239746  43.25                  2 
> >  23.57875722543352  43.25                  2 
> もうここですでに値が異なります。
> すなわち、表示だけ倍精度、という可能性が濃厚。

うう、眠くてよく見てませんでした。(>_<)
表示だけ倍精度、が正解のようですね。(^^;

> N88の場合、仕様では、引数の型が結果の型、ということになっています。
> このプログラムでは、2.0 という単精度型で割り算をしています。
> ここを 2# としてみたら、もしかしたら違いが出てくる可能性があります。


> このプログラムを load して list をみたら、
> 3050 X = S / 2!  '; // Is there any better way to determine initial value?
> 3100      X = (X + S / X) / 2! 
> と、自動で変換されてしまっていました。

なんと！　インタプリタでは精度指定の無い定数は自動的に単精度になるのですね。

> もしかしたらkonnoさんのところでも、この手の意図せざる自動変換が発生している
> かもしれません。当然、コンパイラのほうでも。
> 一度、インタプリタのほうで list をたたいて、自動変換の有無を確認されたほうが
> いいでしょう。

T-98NEXT で確認しました。やはり自動変換されます。

> よくリストを見たら、結果表示がループの外に出ている。
> 結果表示が上書きのよう、というのはそのとおりなんですが。
> 結果表示がループの外、というトリックは、やっぱりkonnoさんだった。

げげ、他のソースからコピペして行番号を変えるのを忘れてました。m(__)m
申し訳ないです。m(__)m

> 前にも書いたと思いますが、もうちょっと行番号の並びとかインデントに気を配って
> プログラムを書いていただけないでしょうか。
> バグが混入し易くなりますよ、と、繰り返しお伝えしていますよね。
> こうやって、残り少ない人生を無駄にしてしまうわけですから。

インタプリタを弄るのはもう何十年ぶりなもので、うっかりやらかしてしまいました。m(__)m
気を付けます。m(__)m

> でも、このプログラムだと、N88なら、ループ内での途中表示は全くないはず。
> つまり、#11195の結果は出ないはず。

3110番を 3118 に変更すれば正常に出力されると思うのですが
私が何か勘違いしている？

> > 3110  if   x < lastx  then print "div=",lastx-x:goto 3070
> とやってみたらどうでしょう。
> １回多くループするところで、いったい何がおきているのか見えてくるかも。

重複部分は以下のようになりました。

div 6.226795723485168D-08  13  13          8 
div 2.220446049250313D-16  13  13          9 
SQR( 169 )= 13               13            9 

比較はほぼ間違いなく単精度でしょうね。(^^;

> 重複部分は以下のようになりました。
> div 6.226795723485168D-08  13  13          8 
> div 2.220446049250313D-16  13  13          9 

これ間違っていました。m(__)m　　正しい数値を各社で比較します。

-----　単精度  -----
N88BASIC
div= 1.27316E-03             13                  13.0013            6 
TurboBasic
div= 1.272201538085938E-003  13                  13.00127220153808  6 
T-BASIC
div= 1.272201538085938E-003  13                  13.00127220153808  6 

N88BASICは精度もいまいちな感じですね。


-----  倍精度  -----
N88BASIC
div= 1.272386299866479D-03   13.00000006226796   13.00127244856782  6 
div= 6.226795723485168D-08   13                  13.00000006226796  7 
div= 2.220446049250313D-16   13                  13                 8 
div= 0                       13                  13                 9 

TurboBasic
div= 1.272386299866923E-003  13.00000006226796  13.00127244856782   6 
div= 6.226795790098552E-008  13                 13.00000006226796   7 
div= 0                       13                 13                  8 

T-BASIC
div= 1.272386299866479D-03   13.00000006226796  13.00127244856782   6 
div= 6.226795745689628D-08   13                 13.00000006226796   7 
div= 0                       13                 13                  8 

全部違うと思ったら、6回目の N88 と T が同じ数値ですね。
これでなにかわかるでしょうか。

いろいろと見えてきたようです。

> N88BASICは精度もいまいちな感じですね。

私が仕様を知っているのはN88だけですが、N88に関していえば、まさに仕様どおり。
N88の単精度は、６桁までしか表示されないのですよ。
そして、計算されるのは７桁目まで。
他の処理系の単精度は１６桁も表示されるのですね。


> -----  倍精度  -----
> これでなにかわかるでしょうか。

いくつかわかることがあります。
まず、N88から。
前回の単なる出力結果だと、x も lastx も13で等しいのに次のループに回っている
のが不思議に思えました。でも実際には 2.220446049250313D-16 だけの差があった
わけであり、次のループに回っているのが正当でした。一方で、あまりにも差が
少なすぎたのでしょう、表示は13で打ち切られてしまっている。
ここ、私が前に書いたように print using を使えば、もしかしたら表示されていた
可能性はあります。

つぎ、TurboBasic。
N88やT-BASICだと、単精度指数の表記はEですが、倍精度指数はDを使っています。
でも、TurboBasicは、倍精度でもEで表示されている。
なんか違和感。これが仕様なんだろうなぁ。
ちなみにEは指数（exponent）の略といわれています。Dは倍（double）の略らしい。
なお、表記は同じでも値は異なっているので、計算そのものはきちんと倍精度で
行われている模様。
ところで、Wikipediaによると、指数表示でEを使うのは国際規格らしい。
実際、Excelとかでもそうなっているし。
もしかしたら倍精度でDを使うって、日本のどこかが始めたことかも。
NECとかシャープとか。
昔のMS-BASICでそうだったのかもしれないけど。

そして、T-BASICを含めて、細かい桁数の計算ではいくらかの精度差が発生すること
がわかります。
今回の話題の出発点の169が素数になってしまうという問題も、konnoさんのところの
エミュ環境のN88で起こっている話ですから、うちの実機のPC98だと、konnoさんの
ところのN88とは結果が異なる可能性がありそう。
ということで、今回の結果を出した検証プログラム、#11195に載っているものと
大体同じものだと思いますが、念のため、もう一度示してください。重要なのは表示
でして、同じような表示にしたいので表示部は必須。
なにとぞよろしくお願いします。

> ということで、今回の結果を出した検証プログラム、#11195に載っているものと
> 大体同じものだと思いますが、念のため、もう一度示してください。重要なのは表示
> でして、同じような表示にしたいので表示部は必須。

DOSVAXJ3 の32ビット版をJ31モードにして TBasicインタプリタが起動できました。
結構互換性があるのね。
それで、ソースをリナンバーしてみました。
 RENUM 3000
これで、3000 から始まる行番号にキチンと並べ替えられました。＼(^^)／ ﾔｯﾀ-
ではそのソースを貼り付けます。

3000 ' SQR-3.BAS
3010   DEFDBL A-Z
3020  'defsng a-z
3030 'screen 0
3040 CLS
3050 INPUT S
3060 OPEN "SQR.dat" FOR OUTPUT AS #1
3070 CC=0
3080 X = S / 2!  '; // Is there any better way to determine initial value?
3090 LASTX = 0! '; // the value one before the last step
3100 'while ( x != lastx ) '// until the difference is not significant
3110      LASTX = X 
3120      X = (X + S / X) / 2! 
3130      CC=CC+1
3140      PRINT "div=";LASTX-X, X,LASTX,CC
3150      PRINT#1,"div=";LASTX-X, X,LASTX,CC
3160  IF   X < LASTX  THEN 3100
3170  PRINT "SQR(";S;")=";X,LASTX,CC
3180  PRINT#1, "SQR(";S;")=";X,LASTX,CC
3190  CLOSE
3200  INPUT A
3210 END

このままで J31 と PC-98 で動くと思います。

> このままで J31 と PC-98 で動くと思います。

ありがとうございます。
次に実家に行ったときに、このコードを走らせたいと思います。
これをこのまま、といいたいところですが、おそらく、ファイル出力のところ、
OUTPUTはAPPENDに変更させていただく予定。

あと、もともとの#11175に立ち返って。

> 条件を色々変えて試しても結果は変わらなかったのですが、ひとつだけ
> N88P.BAS
> ところがオリジナルを若干修正した以下
> PN88.BAS

#11192にも書きましたが、内部的には若干の修正ではない可能性があります。
なので、しつこくてもうしわけありませんが

> PN88.BAS
> 110  defdbl a-z                                 '倍精度指定
> ここを単精度指定にしたらどうなるか、

この結果を教えてください。
よろしくお願いいたします。

> > 110  defdbl a-z                                 '倍精度指定
> > ここを単精度指定にしたらどうなるか、
> この結果を教えてください。
> よろしくお願いいたします。

もちろん 169 が素数と表示されます。
元々単精度でそういう表示になるところから始まった話題ですから。
色々試していった結果結構ソースが変わってしまいましたが。(^^;

ところで、USING を使ってみたら違いが表示されました。

1000 'pn88.bas 
1010 ' defdbl a-z                                 '倍精度指定
1020  'defdbl n                                 '倍精度指定
1030  OPEN "SQR.dat" FOR OUTPUT AS #1
1040 INPUT N
1050 IF (N/2 <> INT(N/2))=0 THEN IF N=2 THEN PRINT "素数" ELSE PRINT "合成数"
1060 J!=SQR(N) 'ELSE
1070   FOR I!=3 TO SQR(N) STEP 2
1080     IF N/I! = INT(N/I!) THEN 1100 '*EXIT1 
1090   NEXT I!
1100 '  *EXIT1
1110    PRINT USING  " .##################";I!-SQR(N) '.14
1120    PRINT#1, USING  " .##################";I!-SQR(N) '.14
1130   IF I!<=SQR(N) THEN PRINT "合成数";I!;J! 
1140   IF I!<=SQR(N) THEN PRINT#1, "合成数";I!;J! 
1150   IF I!>SQR(N) THEN PRINT "素数";I!;J!
1160   IF I!>SQR(N) THEN PRINT#1, "素数";I!;J!
1170 INPUT A
1180 END


この結果は

 .000001907350000000
素数 13  13 

このように単精度の時
I!-SQR(N)
で誤差が表示されました。
倍精度ではゼロになりました。

98実機ではどうなるでしょうね。

> もちろん 169 が素数と表示されます。

ちょっと残念というか、当然と思えることがおきなければそれも手がかりになる
かな、と思っていたわけですよ。
それで、しつこくお尋ねしていた次第。

> ところで、USING を使ってみたら違いが表示されました。

やっぱりそうでしたか。

> 98実機ではどうなるでしょうね。

とりあえず、試したいことリスト。
すでに試し済みのものもあるかも。

#11208のpn88.bas、倍精度と単精度
#11175のPN88.BASでNを単精度にしただけのもの
そして、#11175のN88P.BASの改造版、以下。

N88P0410.BAS
100 INPUT N
110 IF N MOD 2=0 THEN ELSE *ELSE1
120     IF N=2 THEN PRINT "素数" ELSE PRINT "合成数"
130     GOTO *ENDIF1
140 *ELSE1
150     I=3
160     WHILE (I<=SQR(N)) AND (N MOD I<>0)
165         PRINT I,SQR(N)
170         I=I+2
180     WEND 
190     IF I<=SQR(N) THEN PRINT "合成数" ELSE PRINT "素数"
200 *ENDIF1
210 END

これも、Nを単精度と倍精度にしたものの２つ。
今のところ、思いつくのはこのくらい。
あ、そうだ、konnoさんのコードだとプログラム終了のところに必ずinputがあるの
ですが、これ、コンパイラだとあったほうがいいのですか？
それとも他の事情？
いえ、うちのインタプリタだと、必ず最後に入力プロンプトの「?」がはいるのが
うざいというかうっとうしくて。

> そして、#11175のN88P.BASの改造版、以下。
> N88P0410.BAS

これ、実行してみました。NP2 では、169 は素数と表示されました。

> あ、そうだ、konnoさんのコードだとプログラム終了のところに必ずinputがあるの
> ですが、これ、コンパイラだとあったほうがいいのですか？

コンパイラでは終了すると画面が消えてしまい、表示の確認が出来ないのですよ。
インタプリタでは消えないんですが、ソース共通化のために入れています。

> これ、実行してみました。NP2 では、169 は素数と表示されました。

あ〜、いやいや、そこではなくて。
いや、そこなのか？
＃どっちだよ

ループの最後というか、誤判定されるわけですよね。
その、最後とそのもうひとつ前というか、単精度型と倍精度型でどうなっているのか
見たいな、ということです。

プログラム最後のinputについては了解しました。
やはり、環境によって、こういう差異が発生するものなのですね。
想像はできても、実際にお話を聞けたことがありがたいというか。

DOSVAXJ3 が 240410版に更新されました。
以下更新内容です。

build JP240410　(2024/4/10)
・J-3100モードが動作していなかったのを修正しました。
・Linux, macOS でビルドできなくなっていたのを修正しました。

……ということなんで，われわれにはあまり関係ないかな(^^;

> ループの最後というか、誤判定されるわけですよね。
> その、最後とそのもうひとつ前というか、単精度型と倍精度型でどうなっているのか
> 見たいな、ということです。

実行結果（数値はVTDOSの結果を張り付けたが表示は同じ）
? 169
 3             13
 5             13
 7             13
 9             13
 11            13
 素数

NP2の結果は単精度型は「素数」、倍精度型は「合成数」と表示だけ違います。

110番の THEN ELSE はこれでいいんでしょうか。
まあ 2 の表示を省いたのだと思うけど。

> 110 IF N MOD 2=0 THEN ELSE *ELSE1

> DOSVAXJ3 が 240410版に更新されました。

更新されていたのですね、お知らせいただきありがとうございます。

> build JP240410　(2024/4/10)
> ・J-3100モードが動作していなかったのを修正しました。
> ・Linux, macOS でビルドできなくなっていたのを修正しました。

うげ、今ちょうど J31モードを使っている所なんですよね。
それで、3月15日に更新があったのは知っていたのですが、32ビット版は落としてなかった。OTL
ちなみに、3月15日の更新内容は

---------------------------------------------------------------
build JP240315　(2024/3/15)

    J-3100 ビデオモード 64h (640×400 2色 文字 80×20)に対応しました。
    MS-DOS/V 6.2 をイメージファイルからブートした場合に jkeyb.sys の /106 設定が有効にならず
    英語キーボード配列になっていたのを修正しました。
    [dosbox] kanjikey を追加しました。漢字キーを ALT+半角全角、半角全角、右 ALTに割り当てる事ができます。
    int 21h ah=5ch に対応しました。Windows 3.1 用の MS-Office が起動可能になります。
    内蔵 BIOS 割り込みのエントリアドレスを F000:C000 以降に変更しました。

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

> J-3100 ビデオモード 64h (640×400 2色 文字 80×20)に対応しました。

これは、20行表示モードが使えるということかと思って VZJ31の ^KL でやってみました。
が、白画面が真っ黒になって、縦400ドットが、480ドットに伸びました。
カーソルは動きますが、文字は全く表示されません。
もう一度 ^KL で元に戻りましたが、これは使えないようです。
CHEV 64 でも同じ結果です。
黒画面はどうも VGA ぽいですね。

うーん、私の設定か解釈が間違っているのでしょうか。軟式さんに聞いてみようかしら。

それはともかく、これがきっかけで J31 用のBASICコンパイラを試してみたら
なんと！　生成した実行ファイルが VTDOS で動くではないですか。＼(^^)／ ﾔｯﾀ-
MS-DOS Player と同じく テキスト表示だけなら問題なく動作します。
この実行ファイル一つで、VTDOS、MS-DOS Player、DOSVAXJ3のVGA,J31モード全部動きます！！

> ……ということなんで，われわれにはあまり関係ないかな(^^;

関係ないどころか、埋もれていたお宝が完全復活しました！！
それだけではなく、今までのエミュの壁を突破できる切り札として蘇ったのです！！

これはめざらさんのおかげですね。ありがとうございます。
としきさんとの素数プログラムのやりとりも助けになっています。
軟式さんの J31モードのまめな更新のおかげで、古代の遺産が復活出来ました！
みなさまに感謝です。m(__)m

＃　伝説巨神 出でよん 発動編（壮絶な戦いになりそうな悪寒）

> とりあえず、試したいことリスト。

試してきました。

> #11208のpn88.bas、倍精度と単精度

pn88単精度
 .000000000000000000
合成数 13  13 

pn88b倍精度
 .000000000000000000
合成数 13  13 

> #11175のPN88.BASでNを単精度にしただけのもの

合成数と出ました。

> そして、#11175のN88P.BASの改造版、以下。

単精度でも倍精度でも同じ、

 3             13 
 5             13 
 7             13 
 9             13 
 11            13 
合成数

と出ました。単精度でも倍精度でも同じです。
うむ、興味深いぞ。

> 190     IF I<=SQR(N) THEN PRINT "合成数" ELSE PRINT "素数"

Iも13、SQR(N)も13なのだから、合成数と表示されるのが正当。
そして実際、うちでは想定どおり動いています。
ところが、konnoさんのところでは、単精度型ではこの比較式が成り立たず、ELSEに
落ちてしまっている。そして、倍精度型ではきちんと動いている。
なんか、エミュの挙動がおかしいとしか思えない。
前にも書きましたが、N88BASICの仕様では、関数の結果は引数と同じ型になることに
なっています。つまり、Nが単精度ならSQR(N)の結果も単精度のはず。だから、小数点
以下の細かいところの値が出てくることがおかしい。
もしかしたら、次のような簡単なプログラムでも、実機とエミュで差が出たりして。

10 A#=1.23456789#
20 B!=A#
30 PRINT A#,B!

これ、実はN88のマニュアルに載っているサンプルです。
そして、仕様上のこの実行結果は

RUN
1.23456789  1.23457

となるべきなのだそうです。
もしエミュでこうならないとしたら、それはどこかがおかしい。
エミュの作者に調査を依頼してもいいかも。



追伸
#11213

> 110番の THEN ELSE はこれでいいんでしょうか。
> 110 IF N MOD 2=0 THEN ELSE *ELSE1

N88BASICでは、言語仕様として、THEN節に空文を許します。
つまり、THEN のときは、何もせずに、次の行に進むことになります。
これ、#11169で触れているとおりです。

> これ、実はN88のマニュアルに載っているサンプルです。
> そして、仕様上のこの実行結果は
> 
> 1.23456789  1.23457
> 
> となるべきなのだそうです。

NP2でやってみた結果です。

 1.23456789    1.23457

表示は全く同じですね。やっぱり表示と内部の数値がズレているのかなぁ。
他のエミュの結果は全て以下の数値でした。

 1.23456789    1.234568

98エミュの表示が上の数値で内部的には下の数値だとしたら、計算が合わないのも合点ですね。
でも何故こうなるのかがわからないので、とっても気になります。

> もしエミュでこうならないとしたら、それはどこかがおかしい。
> エミュの作者に調査を依頼してもいいかも。

表示は全く同じなので、おかしくないということですね。（違う！）

> N88BASICでは、言語仕様として、THEN節に空文を許します。
> つまり、THEN のときは、何もせずに、次の行に進むことになります。
> これ、#11169で触れているとおりです。

なるほど、つまり想定どうりということですね。

> それで、3月15日に更新があったのは知っていたのですが、32ビット版は落としてなかった。OTL

実は寝室のPCでダウンロードしていました。(^^;
ダウンロードだけして寝落ちしてそのまま忘れていたようです。(^^;;
ということで

> build JP240410　(2024/4/10)
> ・J-3100モードが動作していなかったのを修正しました。

これがどういうことかと疑問だったので確認してみました。
・・・J31モードにすると、起動中に固まってしまいました、(>_<)
そういうことでしたか・・・

> > J-3100 ビデオモード 64h (640×400 2色 文字 80×20)に対応しました。
> これは、20行表示モードが使えるということかと思って VZJ31の ^KL でやってみました。
> が、白画面が真っ黒になって、縦400ドットが、480ドットに伸びました。
> カーソルは動きますが、文字は全く表示されません。
> もう一度 ^KL で元に戻りましたが、これは使えないようです。
> CHEV 64 でも同じ結果です。

これ、CHEJ 64 だとモードが変わりました。
CHEV コマンドに反映されていないみたいです。デジャブのような。(^^;

D:\NC>chev 64

V - Video mode information    R1.0  (C)ChaN,1993

Current Video Mode = 74h
Screen Size        = 80x25
Character Height   = 16
VRAM Mode          = A/N
VRAM Address       = B800:0000 (Real VRAM)

それで、CHEJ コマンドを試したら

D:\NC>chej 64
CHEJ.EXE <MultiMode CHEV> ver 6.10 by Natrium.

J-3100(DCGA)、日本語環境に切り替えました。
現在のビデオモードは 64h です。

V - Video mode information    R1.0  (C)ChaN,1993

Current Video Mode = 64h
Screen Size        = 80x20
Character Height   = 20
VRAM Mode          = A/N
VRAM Address       = B800:0000 (Real VRAM)

おお、画面モードが 20行に変わりました。
それで、VZJ31 の編集画面を見ると
行数は 25行のまま、アンダーラインカーソルも追随します。
点滅カーソルは 20行になったようで、下に行くほどズレます。

うーむ、これは VZが対応できていないのかしら？
やっぱり軟式さんに聞いてみようかな。

> NP2でやってみた結果です。
> 他のエミュの結果は全て以下の数値でした。
> 表示は全く同じなので、おかしくないということですね。（違う！）

NP2と他のエミュで差が出る、というところは一つの突破口かも。
少なくともNP2以外のエミュは仕様どおりではないということで、バグ報告は可能
だと思います。おそらく、四捨五入するときの桁数を誤っていると想定されます。
仕様上は、有効桁７桁、出力のときは７桁目が四捨五入されて６桁で表示、という
ことになっているのですから。
なので、以後は、NP2と実機の差異をどうするか。
どうも、本来は７桁以上は格納してはいけないものを７桁以上格納している、その上
７桁以上で比較してはいけないものを７桁以上で比較している、というように見える
わけですよ。
print usingを使う以外に、何かいい方法はあるかなぁ。


実際、この程度の小数の誤差がどの程度影響するかはわかりませんがね。
でも、もしかしたら、昔からゲームなんかでも使われている可能性はあるわけで。
konnoさんは、例えばバルーンパンチなんてゲームを覚えておられませんかね。
シーソーに乗った人が交互にジャンプして上のほうで動いている風船を割っていく、
というゲームです。
このゲームで飛んでいる人間は、まるで重力で引かれるような感じで頂点に向かって
減速して、また落下するときは加速するわけです。このゲームに限らず、まるで重力
に引かれたような動きをする、だとか、慣性が働いているようになかなか加速しない
上に速度が乗ったらすぐには止まれない、といった動きをするようなゲームでは、
もしもそれなりに理論的なアルゴリズムを使うならば、物体の位置決定に二次関数を
使う必要があるわけです。実際に使っているアルゴリズムがどこまで理論的に正しい
ものになっているかはわかりませんけどね。
そして、二次関数を解くためにはSQR関数が必要。
あるいは、ゲームによっては三角関数を使っているものもあるかもしれない。
そして、画面のＸとＹの座標は当然整数。
ときどき、当たり判定がバグっているゲームというのが話題になることがありますが、
あれっていうのはもしかしたら、小数と整数の比較の際の誤差の問題かも。そして、
実機だと正常に動いていたのにエミュだとおかしい、というゲームなどがあった場合、
それこそこのような小数の誤差の可能性は高いかも。
もちろん、倍精度を使えば誤差は少なくなりますが、リアルタイムの計算の場合、
倍精度だとやっぱり重くなるので、たいていは単精度を使うでしょうし。

> NP2と他のエミュで差が出る、というところは一つの突破口かも。
> 少なくともNP2以外のエミュは仕様どおりではないということで、バグ報告は可能
> だと思います。おそらく、四捨五入するときの桁数を誤っていると想定されます。
> 仕様上は、有効桁７桁、出力のときは７桁目が四捨五入されて６桁で表示、という
> ことになっているのですから。

もしかしたら誤解させてしまったかもしれません。
他のエミュとは、98エミュ以外の、J31とかDOS/V系のエミュのことです。
今回 NP2以外の98エミュは確認していません。同じ結果になると思ったので。

ということで、ANEX86 や T98-NEXT のN88コンパイラ、インタプリタでも確認しました。
結果は NP2と 表示は全く同じでした。

> どうも、本来は７桁以上は格納してはいけないものを７桁以上格納している、その上
> ７桁以上で比較してはいけないものを７桁以上で比較している、というように見える
> わけですよ。

これが実際どうなのかはわかりませんが、BASICのルーツは MSのGW-BASICだと思います。
T-BASICなどは漢字処理を覗けば恐らくほとんどそのままの互換性だと思っているのですが
NECのN88BASICは、あちこち変えているようですが、単精度の精度もわざと落としているように見えます。
その辺がエミュでの誤動作の原因になっているのではないかと愚考します。

> konnoさんは、例えばバルーンパンチなんてゲームを覚えておられませんかね。
> シーソーに乗った人が交互にジャンプして上のほうで動いている風船を割っていく、
> というゲームです。

私はこの手のゲームはあまりやっていないので覚えていません。

> ときどき、当たり判定がバグっているゲームというのが話題になることがありますが、
> あれっていうのはもしかしたら、小数と整数の比較の際の誤差の問題かも。そして、
> 実機だと正常に動いていたのにエミュだとおかしい、というゲームなどがあった場合、
> それこそこのような小数の誤差の可能性は高いかも。

今回のことを踏まえるとそう考えられますね。

> もちろん、倍精度を使えば誤差は少なくなりますが、リアルタイムの計算の場合、
> 倍精度だとやっぱり重くなるので、たいていは単精度を使うでしょうし。

N88BASICは8ビット時代の互換性重視ではないかと思いますが、8ビットの貧弱なCPUで
ゲームの速度を上げるためにわざと単精度の桁を落としたのではないかと思います。
そして、16ビット版になっても互換性のためにそこを変えることが出来なかったのかも。

> もしかしたら誤解させてしまったかもしれません。
> 他のエミュとは、98エミュ以外の、J31とかDOS/V系のエミュのことです。

はい、誤解しました。
続報をいただいたことで、誤解は氷解しました。

> NECのN88BASICは、あちこち変えているようですが、

うん、まぁ、その前のN-BASICからの互換性というのがありますからね。
そちらのほうでいろいろと変えていたところはあるかもしれません。

> 単精度の精度もわざと落としているように見えます。

こちらについてはどうなんだろう。
そうではないというわけではなく、根拠不足というか、これまでのところでは、私
にはそう思えるだけの挙動はないような気がしています。
ということで、ちょっと調べてみました。
まず、単精度は４バイトであらわす実数、倍精度は８バイトであらわす実数。
これは、調べた範囲では、どこも同じみたい。８０年代の８ビットパソコンのBASIC
でも、２１世紀の６４ビットパソコンのＣコンパイラでもおおむね一緒。
ところが、倍精度のほうが、最近の国際規格とN88BASICで異なるみたい。
#11164に書いたように、N88BASICでは倍精度の扱える上限は 1.7*10^38 ですが、
最近の規格では 1.8*10^308 まで扱えるらしい。
一方で単精度の方は最近の規格でも 1.7*10^38 で同じ。
内部表現についても、仮数部２３ビット、指数部８ビット、符号１ビットという部分
に変化はない。
でも、だからN88の単精度では精度を落としていないかというといささか怪しいと
いうか断言はできない。
なにかというと、十進数との変換部分。
#11135にも書きましたが、仕様としては有効桁７桁、出力のときは７桁目が四捨五入
されて６桁で表示、となっているわけですよ。でも、他の処理系では例えば、有効桁
７桁で表示も７桁、となっているかもしれない。もしそうであれば少なくとも見かけ
の精度は落ちているわけです。あるいは、他の処理系では、７桁目で四捨五入では
なく切り捨て表示となっているかもしれないし。
ただ、あまりにも他のマシンと差があるようであれば、当時、大騒ぎになっている
のではないかなぁ。あの時代、ネットはなくてもパソコン雑誌はあったし、８ビット
のころはともかく１６ビットの時代はパソコン通信もあったし。
ということで、とりあえず現時点では根拠不足としてkonnoさんのご意見に賛同は
しないでおきます。
＃つまり、何かあればすぐに意見は変わる

ただ、エミュという意味では、よく言われる「バグまで再現した」というものが評価
が高いわけで、現状、実機と差異が出るエミュは、完成度としてはもう一歩、という
のが現実的な評価だと思われます。

> 続報をいただいたことで、誤解は氷解しました。

紛らわしい表現で誤解させてしまい申し訳ないです。
とりあえずホッとしました。

> > 単精度の精度もわざと落としているように見えます。

考えてみたら、これは表示だけなのかもしれませんね。
N88BASICは、インタプリタもコンパイラも中間コードの LIB を使用しているように見えます。
ということは、そのバイナリコードは BIOS.ROM の中なのではないですか。

私の手持ちのNP2の BIOS.ROMは、実機のものではなく、互換BIOS かもしれません。
その互換BIOSを作る時、N88BASICの仕様に忠実に作るために、#11215 の

> 10 A#=1.23456789#
> 20 B!=A#
> 30 PRINT A#,B!
> 
> これ、実はN88のマニュアルに載っているサンプルです。
> そして、仕様上のこの実行結果は
> 
> RUN
> 1.23456789  1.23457
> 
> となるべきなのだそうです。

この結果を忠実に再現するために、わざと内部数値まで桁落ちさせたのではないかと疑い始めました。
つまり、問題なのは、互換BIOS.ROM なのかもしれないと思うようになりました。

これは、実機を持たない人たちにとって無くてはならない非常にありがたい福音ですが
互換BIOS を作ったのは、著作権の問題回避の為なので、バイナリレベルで違うものでなければならないわけです。
もしかしたら、この部分がそのための直せない生贄だったりして。あくまで妄想ですが。

> ただ、エミュという意味では、よく言われる「バグまで再現した」というものが評価
> が高いわけで、現状、実機と差異が出るエミュは、完成度としてはもう一歩、という
> のが現実的な評価だと思われます。

NP2は、細部の再現性にこだわったエミュという評価があるようなのですが
先のサンプルプログラムの結果は忠実に再現していますね。(^^;

> ということは、そのバイナリコードは BIOS.ROM の中なのではないですか。

確かに .LIB のファイルのサイズが小さ目というところから、実際に LIB がやって
いることは ROM の中身の呼び出しのみ、という可能性は高そうです。

> この結果を忠実に再現するために、

ある意味、この結果「だけ」を忠実に再現している、という感じ。
もし「実機を忠実に再現」するのであれば、169は合成数と表示される必要がある。
この点がなされない限り、実機に対するエミュとしての完成度は今一歩、という
ところで終わってしまいそうです。
もっとも世の中には、既知のバグどころか未知のバグまで再現したエミュレータと
いうものもある模様。実機で新たなバグが発見されてから、エミュレータでも同じ
バグが発現した、なんて話もあるようで、とても不思議。こういうのが、いわゆる
「完璧なエミュレータ」というやつでしょう。なぜ作れるんだろう。

> 互換BIOS を作ったのは、著作権の問題回避の為なので、

これはそのとおりだと思いますが、その一方で、実数のバイナリ表現というものは
ある意味で規格化されているわけです。つまり、実数演算とかバイナリと十進数の
変換とかの部分は世の中にいくらでもサンプルコードとかライブラリとかのフリーで
使えるものが存在しているわけで、そしてそういうものを使えば少なくとも著作権の
問題は回避できるはず。さらに、その手のコードって世界中の人が見ているわけです
から、精度を落とす方向にいじることは少ないのではないかなぁ。というか、わざと
精度を落とす、なんてことに時間をかけるくらいならとっととリリースしてくれよ、
という気もする。
もちろん、そういうものを使わずに１からコードを書いていたら、十分な精度を確保
できていなくても不思議はないけど。
あ、でも、ありうるかな。
倍精度のほうが現在のありふれたものとは内部表現が異なっているようだから、そちら
のほうに合わせて、ということはあるかも。



実は私、実数演算についてはちょっとだけやかましい。
#2066とか#10367にも書いたけど、大昔、８ビットマシンの時代、実数演算のマシン語
ルーチンを書いてハンドアセンブルしていたもので。
といっても四則演算だけですけどね。

> もっとも世の中には、既知のバグどころか未知のバグまで再現したエミュレータと
> いうものもある模様。実機で新たなバグが発見されてから、エミュレータでも同じ
> バグが発現した、なんて話もあるようで、とても不思議。こういうのが、いわゆる
> 「完璧なエミュレータ」というやつでしょう。なぜ作れるんだろう。

それはきっと、リバーs^ ・・・　いや、なんでもないです。(^^;

> 実は私、実数演算についてはちょっとだけやかましい。
> #2066とか#10367にも書いたけど、大昔、８ビットマシンの時代、実数演算のマシン語
> ルーチンを書いてハンドアセンブルしていたもので。
> といっても四則演算だけですけどね。

鶴亀算みたいなものでしたっけ？　結構面倒くさいんですよね。
丁度 DANNYさんの浮動小数演算ライブラリを目にしていたので見てみました。
ASMは1531行ありましたね。
バイナリは恐らく２千バイトくらいになるのかなぁ。

J3100用BASICコンパイラの続報も書かなくてはいけないのでこの辺で。

konnoさん、なんか他のものを連想している。

> 鶴亀算みたいなものでしたっけ？　結構面倒くさいんですよね。

鶴亀算は整数演算です。
何だろう、何と勘違いしたんだろう。おいらにはわからない。

> 鶴亀算は整数演算です。
> 何だろう、何と勘違いしたんだろう。おいらにはわからない。

あう、多分整数演算の事だと思います。(>_<)
私は算数も数学も苦手というか、数字の計算や記憶が全くダメなんですね。
だからパソコンにやらせようと思うのです。(^^;

STIME のTurboBasic用のBASICソースを J31BASICに逆移植しました。
元々は J3100で開発、運用していたので、動くようになるまで1時間も掛かりませんでした。
ところが、その後の各エミュでの挙動が違いすぎてその対応は非常に困難なものでした。
まるで底なし沼に落ちたような、藻掻けば藻掻くほど深くなるその深淵は、地獄か。

ということで、地獄から生還した私の地獄巡り体験記(違う)改造遍歴を書いてみたいと思います。(^^;
始めに両コンパイラの違いの説明です。
ソースの冒頭

TurboBasic
1  'STIME5  Menu   1994-08-10 96-05-27 97-9-12 98-04-23 09- 24-04-21
10 'TB
50 REM $DYNAMIC
55 $INCLUDE "REGNAMES.INC"

J31BASIC
1  'STIME6  Menu   1994-08-10 96-05-27 97-9-12 98-04-23 09- 24-04-22
10 'J31
50 REM $DYNAMIC
55 rem '$INCLUDE "REGNAMES.INC"

1994年頃は J3100で運用していましたが、Windows95が出てPCもWinノートに変わりました。
DOSの画面モードは VGAになり、J31用のプログラムは動かない。(>_<)
仕方なく手持ちのTurboBasicに移植することに。それが恐らく 96年以降の日付。

50行は J31用の設定ですが、TurboBasicでも同じようです。REM も含めてメタコマンドか。
55行は、TurboBasic用で、J31コンパイラではエラーになります。

55 '$INCLUDE "REGNAMES.INC"
55 rem $INCLUDE "REGNAMES.INC"

実は上のどちらにしてもエラーになるので、REM ' としてやっとコメントになりました。

後はテキストカラー属性指定かな。
TurboBasicは、
COLOR 7,0	グラフィックモード
COLOR 7,0,0	テキストモード

J31
COLOR 7,0	グラフィック
COLOR @7,0,0	テキスト

"@" だけの違いのように見えますが、実は TurboBasicでは文字の反転はテキストモードだけ
つまり、SCREEN 0 の英語テキストモードでしか使えないようです。
J31は基本グラフィックモードだけなので、@でテキスト文字用に使い分けできます。

他にもあったかもですが、僅かの変更でコンパイラは通るようになり、動き始めました。
だが本当の地獄はこれから始まるのであった。


続く　・・・のか

ココログからの転載記事です。
http://tamaneko2.cocolog-nifty.com/vz2/2024/04/post-6e6da8.html
これは、TurboBasic の STIME です。
先にこちらを上げないといけないので。(^^;


STIMEでリアルタイムのタイマー機能を追加しました。
きっかけは白内障の手術です。
術後点眼薬を３種類１日に４回または２回挿すことになりました。
３種類を５分間隔で、４時間以上空けて１日に４回を毎日３カ月間続けるのです。

忘れっぽい私は、STIMEのタイマー機能を使えば点眼管理が楽になると思ったのですが
キーを押した時に経過時間を表示するだけの簡易タイマーなので、あまり便利に思えません。
経過時間をリアルタイムに表示出来れば便利だろうと思い、機能追加しました。

STIME41 画像参照
 
以前はこのように2系統のタイマーを2列表示していましたが
リアルタイマーは上下2系統にし、黄色で表示します。

STIME51 画像参照

これで５分間隔の点眼は便利になったのですが、４時間以上経過したかわかりにくいので
アナログ時計にマーキングすることを思いつきました。

STIME556 画像参照
 
黄色の丸が [F06] で、ピンクの丸が [F07] です。
時計の丸枠に掛かっている丸は短針の位置で時間を示します。
時計の丸枠の内側の丸は長針の位置で、分を示します。

やってみると、分の表示はごちゃごちゃしてわかりにくいですね。
そこで、５分とか指定時間が経過したらカラー表示で知らせるビジブルベルを追加。
 
STIME557 画像参照

指定所間を経過するとカラーバーを色を変化させて表示します。

[ESC] でカラー表示のビジブルベルを解除できます。
時間など各種設定のために、STIME.DAT で設定できるようにしました。
 
MS-DOS Playerではこのように表示します。

STIME558 画像参照
 
これだとPC画面の隅に1文字分でも表示させておけばほかの作業中でもわかります。

これはいい！

STIME のカレンダ表示などを弄っていて、LXCLND.DEF と表示を比べてみたら
２月２３日とか１２月２３日など違っている日がいくつかありました。
STIMEの HOLIDAY.DAT を見てみると

02/23 2020-2099 天皇誕生日  (令和天皇)
12/23 1989-2018 天皇誕生日  (平成天皇)

なるほど、最近変更された祝日に LXCLND.DEF が対応してないのですね。
STIME のバグでなくてほっとしました。(^^;

見たついでに、LXCLND.DEF の祝日テーブルを修正しました。
LXCLND.DEF には HOLIDAY.DAT のデータ形式で参考にさせてもらいましたからね。

LXCLND.DEF  431行目

72:	;---- holiday definition -----------------------------------------

;	hh..2  =  "1874>1948=11;1967>0=11",
	hh..2  =  "1874>1948=11;1967>0=11;2020>0=23",

;	hh..4  =  "1874>1948=3;1928>0=29",
	hh..4  =  "1874>1948=3;1928>1988=29;1989>2006=29;2007>0=29",

;	hh..5  =  "1949>0=3;1985>0=4;1949>0=5",
	hh..5  =  "1949>0=3;1985>2006=4;2007>0=4;1949>0=5",

	hh..8  =  "2016>0=11",

;	hh..10 =  "1874>1948=17;1966>1999=10;2000>0=BB",
	hh..10 =  "1874>1948=17;1966>1999=10;2000>2019=BB;2020>0=BB",

;	hh..12 =  "1989>0=23",
	hh..12 =  "1989>2018=23",


該当する HOLIDAY.DAT の祝日は

02/23 2020-2099 天皇誕生日  (令和天皇)

04/29 1948-1988 天皇誕生日 （昭和天皇）
04/29 1989-2006 みどりの日
04/29 2007-2099 昭和の日

05/04 1985-2006 国民の休日
05/04 2007-2099 みどりの日

08/11 2016-2099 山の日

10/10 1966-1999 体育の日
10/BB 2000-2019 体育の日
10/BB 2020-2099 スポーツの日

12/23 1989-2018 天皇誕生日  (平成天皇)

修正した LXCLND.DEF を VZマクロの部屋に置きました。
以下の直リンクでも見ることができます。

#txt:LXCLND.DEF

STIME.EXE Ver 240428 を「自作、改作アプリの放置部屋」に置きました。

STIME5.ZIP　サイズ 84098bytes　 24-04-28 new!

　 STIME.EXE Ver 240428

・DOSVAXJ3 の VGAで動くアナログ時計とカレンダとタイマーのアクセサリです。
・NCPATH= でデータファイルの置き場所を指定してください。末尾に "\" が無ければ追加します。

・DOSVAXJ3 を起動したら、chev jp でVGAモードにして、STIME.EXE を起動してください。
・MS-DOS Player では、chej jp でVGAモードにします。文字のデジタル時計とカレンダのみ表示。
・VTDOS では動作しません。
・タイマーモード(6)の時は[F03]や[←]キーで小窓のカレンダー当月を表示します。
・ビジブルベルは[F06]だけの機能です。STIME.DAT で動作設定します。[ESC]でカラー表示消去。

STIME5　24-04-28
　240428　タイマーモード(6)の時は[F03]や[←]キーで小窓のカレンダー当月を表示。
　240315　指定時間経過でビジブルベル タイマー画面復帰
　240306　アナログ時計にタイマーのマーキング 設定ファイル STIME.DAT で各種設定可能に
　240202　タイマーの時間表示文字を大きく・経過時間をリアル表示、スリープモードにも対応。
STIME4　23-12-12
　231212　NCPATH が通ってなくてデータファイル読めない場合エラー終了していたのを警告表示に。
　231208　環境変数 NCPATH でデータファイルの置き場所を指定。指定無しならカレント
　春分、秋分の日を自動計算
　デジタル時計とカレンダ大の文字を2バイト文字に。
　[↑↓]キーで前年・次年 [←→]キーで前月・次月のカレンダーを表示

　動作保証はでき無いので実行は自己責任で。　　


※今回は DOSVAXJ3 で TOUCH を使いファイルの日時を合わせました。
　使い慣れたDOSツールが使えるのは気持ちいいですね。
　今回の版は TurboBasic でコンパイルしています。
　VTDOSでは動かないので注意してください。

わたしもオリ・パラ関連特別措置法による移動は無視しました。
四月と五月は敢えて弄りませんでした。祝日名を表示するわけでもないので。

> わたしもオリ・パラ関連特別措置法による移動は無視しました。

これは Wikipedia でも参考程度になっていますね。

> 四月と五月は敢えて弄りませんでした。祝日名を表示するわけでもないので。

そうなんですよね、表示は同じなんですが、オリジナルでも分けているところがありましたので。

ところで、今回 LXCLND.DEF で気が付いたところがあります。
中央のカレンダに今日の日付が () に囲われてわかりやすくなっていますが
表示月を移動しても同じ日付に () が付いたままになっていますね。

これはバグという見方もできますが、仕様かもしれないと思いました。
このマクロはスケジュール管理のために月を変えてカレンダを参照しやすくなっています。
その時、今日は何日だっけ？と思うこともありそうなので、その確認になるかなと。
なので、この仕様はこのままにしておきます。

STIME でも現在の日付に色付けしていますが、改編時バグって毎月同じ日付に色がついて
修正に苦労したりして。いや、年取って頭が働かなくなっただけなんですけどね。(^^;

う、そういえば今日は祝日なのに今日の日付が赤になっていない。(>_<)
うーん、直せるかしら・・・(^^;

> 表示月を移動しても同じ日付に () が付いたままになっていますね。

日付出力のために疑似カーソルを表示しています。
これは当日であるとは限らないです。（当日は[TAB]入力直後の表示）

> > 表示月を移動しても同じ日付に () が付いたままになっていますね。
> 日付出力のために疑似カーソルを表示しています。
> これは当日であるとは限らないです。（当日は[TAB]入力直後の表示）

疑似カーソルって、Shift+カーソルキーで () の日を移動出来るんですね。
凄いテクニックです。ソースを見てみました。

LXCLND.DEF 189行目以降

10:	;---- make menu --------------------------------------------------

	pr..15 = "$$3($$7",		;right of today
	pr..16 = "$$3)$$7",		;left of today

ここが多分メニューの中で () を表示するところでしょうか。
実際のメニュー表示はその下のマシン語かな。

10:	;---- mklxclnd.asm ----

こうなると全く読めないので追及は諦めます。(^^;

新しい STIME では、TIMER.DAT にタイマー画面を退避させています。
J31用BASICコンパイラを動作させてみると、その画面がおかしい。
ぐちゃぐちゃになっているのです。

TurboBasic では、48桁 23行で以下のように表示されます。
1行目は、d-他の受け渡しに使っています。

 1             1 
>                                               
 1日 １７:１６:３１   0: 0: 0    0: 0: 9        
                                                
　　中略
                                                
     1日 １７:１６:３３   0: 0: 0   0: 0: 7     


J31BASIC では、各エミュごとに全部違っています。

VTDOS 4/13
13 把  ０Oマ: ４Sマ: ４Sツ   8:12'45    0: 0:19        
                                                
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

VTDOS 4/21
21日^@^@０２：３８：３１  0: 0: 0   0: 6:48 ^@^@^@^@^@^@
                                                
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

VTDOS 5/1
 1日  １７：２２：５４  0: 0: 0   0: 0: 8       
                                                

最初は2バイト文字が変に文字化けして、背景のスペースがヌルになっています。
現在は正常表示になっていますが、ここまでするのに一苦労でした。

DOSVAXJ3 VGAモード
12日���cc １PP６UU:２QQ９XX:１PP０OO   0  8:40:54 0: 0: 3
                                                
ﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛ
ﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛ

DOSVAXJ3 J31モード
13日日 ００１１:００７７:４４７７   0: 0'26    0: 0:13        
                                                
                                                
MS-DOS Player
13日�c ０O０O:５T３R:３R０O   0: 0' 0    0: 0:11        
                                                
                                                
このように、どのエミュでも2バイト文字が化けたり2重になったりしています。
その原因は、J31BASIC の CDBL$() という、1バイトの数字を2バイト文字に変換する関数でした。
元々は J3100 でこの関数を使って表示していたので元に戻してみたらこうなったということです。
しかたがないので、TurboBasic と同じやり方に戻しました。

背景の空白が ヌル文字になったり、DOSVAXJ3 VGAモード では、$DB で埋められています。
これは、VRAM領域のメモリの状況によると思われます。
C000h セグメントは VGAの領域で確保されていると思いますが、初期化の問題なのかな。
VTDOS では、TPAEXT などでメモリ拡張していると干渉すると思われるので要注意です。

ともかく、動くのが不思議な状態なので、このまま使うのがよろしいようです。
                                                

> 疑似カーソルって、Shift+カーソルキーで () の日を移動出来るんですね。

メニュー表示中のコマンドキーを受けるもののうち，以下の四つですね。

(#37)	{ r=7, &11 }
(#38)	{ r=7, &12 }
(#a)	{ r=1, &11 }
(#f)	{ r=1, &12 }

これらのキーを受け取ったときに「日付」を再設定します。
再設定する値は現在の値に1日（左右）か7日（上下）を増減して再表示します。

再表示のしかたについては，多くのカレンダーマクロで当日の背景色を変えたり
括弧でくくったりするのとまったく同じで，メニューアイテムへの埋込みです。
（括弧の場合は前後の空白に上書きすることになりますが）

メニューアイテムの書換えというのはトンでもなく面倒なわけで，
オリジナルのnomad版ではテキストに書き出すという手法をとっていたため
konnoさんのようにキーを押しっぱなしにしたりする人(^^;はとても使えなかった。

Yushiさんはメモリ（ラインバッファ）上に出力することと機械語化で高速化し，
Emmettさんは機械語化をさらに徹底的に行なって超高速化しています。

メニュー内でカーソルを動かすというのは確かに高度なテクニックですが，
（アセンブラに馴れ親しんでいるkonnoさんには釈迦に説法に違いないのですが）
とにかくひたすら面倒な「低級」テクニックとも言えると思います。

Yushiさんなんか，メニューで十字カーソルですぜ。
そんな面倒なコードをよく書くものだなぁとひたすら感心します。

あ，元に戻って，「日付」というのは保持している値なので，あまり意味はなく，
「当日」を指示されたときだけリセットするというイメージですね。

> > 疑似カーソルって、Shift+カーソルキーで () の日を移動出来るんですね。
> メニュー表示中のコマンドキーを受けるもののうち，以下の四つですね。
> (#37)	{ r=7, &11 }
> (#38)	{ r=7, &12 }
> (#a)	{ r=1, &11 }
> (#f)	{ r=1, &12 }

なるほど、詳細な解説ありがとうございます。
これなら改造も出来そうな気がしてきました。（やらないけど。(^^;）

> メニューアイテムの書換えというのはトンでもなく面倒なわけで，
> オリジナルのnomad版ではテキストに書き出すという手法をとっていたため
> konnoさんのようにキーを押しっぱなしにしたりする人(^^;はとても使えなかった。

い、いやぁ、、、そんなことは・・・ない、と思いますです。(^^;
実際のところ今カレンダ表示をモードによって分岐を変えるので四苦八苦してます。
とんでもないスパゲッティが出来上がりつつあり、ソースでごまかせるのかと。(^^;

> あ，元に戻って，「日付」というのは保持している値なので，あまり意味はなく，
> 「当日」を指示されたときだけリセットするというイメージですね。

これ、勘違いしていました。疑似カーソルの意味がやっとわかりました。
スケジュールとのリンクとか日付出力とかでこの機能が必要だったのですね。

DOSVAXJ3 が 240502版に更新されました。
以下更新内容です。

・J-3100 モードの場合、int 10h ah=02h のカーソル位置指定で bh のページ番号は使用せず常に 0 となるよう修正しました。
・J-3100 の int 10h ax=8200h でスクロールモードを変更した後に画面クリアするよう修正しました。
・macOS 上での SDL-IM+ の不具合を修正しました。

……てことで，あまり関係ないかしら(^^;)

> ……てことで，あまり関係ないかしら(^^;)

あうう、更新の記事を上げようとしたら先を越されてしまいました。(^^;

問題無く動作しますが、特に変化は感じないです、(^^;
この機会にJ31関連でちょっと要望などしてみようかしら。(^^;

> C000h セグメントは VGAの領域で確保されていると思いますが、初期化の問題なのかな。
> VTDOS では、TPAEXT などでメモリ拡張していると干渉すると思われるので要注意です。

C000h セグメントはパソピア16 でした。思い込みで間違えました。m(__)m
J3100用BASICコンパイラでは、画面モード 75 (SCREEN 4) でカラーモードが使えます。
J3100テクニカルブックによるとこのモードでは VRAM領域 A000h - AFFFh となっています。

確認のために STIME実行中に SHELL で画面情報を見てみました。

・DOSVAXJ3 J31
CHEJ.EXE <MultiMode CHEV> ver 6.10 by Natrium.

現在 DOS/V(Normal)、日本語環境です。
現在のビデオモードは 03h です。

V - Video mode information    R1.0  (C)ChaN,1993

Current Video Mode = 03h
Screen Size        = 80x25
Character Height   = 19
VRAM Mode          = APA
VRAM Address       = C741:0000 (Virturl VRAM)


・DOSVAXJ3 VGA
現在 DOS/V(Normal)、日本語環境です。
現在のビデオモードは 03h です。

Current Video Mode = 03h
Screen Size        = 80x25
Character Height   = 19
VRAM Mode          = APA
VRAM Address       = C679:0000 (Virturl VRAM)


・VTDOS
現在 DOS/V(V-Text)、日本語環境です。
現在のビデオモードは 70h です。

Current Video Mode = 70h
Screen Size        = 110x35
Character Height   = 12
VRAM Mode          = A/N
VRAM Address       = D000:0000 (Real VRAM)


・MS-DOS Player
現在 DOS/V(V-Text)、日本語環境です。
現在のビデオモードは 75h です。

Current Video Mode = 75h
Screen Size        = 80x25
Character Height   = 22
VRAM Mode          = A/N
VRAM Address       = B800:0000 (Real VRAM)


うーむ、どのエミュも A000h - AFFFh の領域は使用していないようですが
VRAMアドレスがバラバラですね。

ごめんなさい、ここのところがよくわからないので解説希望。

> その原因は、J31BASIC の CDBL$() という、1バイトの数字を2バイト文字に変換する関数でした。
> 元々は J3100 でこの関数を使って表示していたので元に戻してみたらこうなったということです。
> しかたがないので、TurboBasic と同じやり方に戻しました。

(1)J31BASICではCDBL$()を使っていた
(2)でも何らかの理由でJ3100ではCDBL$()を使わなくなった
(3)だけどやっぱりCDBL$()を使ったら文字化け
(4)TurboBasicと同じCDBL$()を使わない方法に戻した

という理解でよろしいのでしょうか。それとも

(1)J31BASICではCDBL$()を使っていた
(2')でもJ3100以外の機械で使うためにCDBL$()を使わなくなった
(3)だけどやっぱりCDBL$()を使ったら文字化け
(4)TurboBasicと同じCDBL$()を使わない方法に戻した

こっちの理由かな。
つまり、(2)なのか(2')なのかで違いがあるかも、というお話。


余談ですが、N88-BASICにはCDBL$()という関数はありません。
数値型のCDBL()という関数はあります。
引数を倍精度型に変換するという関数です。
文例として
A#=CDBL(256%)
なんていうのが載っていますが、仮に
A#=256%
とした場合と何が違うのか、あまり知られていません。違いはないのかも。
積極的には使われない関数であることは間違いありません。

> (2')でもJ3100以外の機械で使うためにCDBL$()を使わなくなった

こちらですね。
経緯は書いていますが、もう一度整理すると

・元々J3100 で使うために J31BASICでCDBL$()(２バイト数字文字）を使っていた。
・でも、PCがWin95ノートに変わってしまい、J3100のプログラムが動かなくなったので
　TurboBasicに移植して、CDBL$()が使えないので、１バイト数字文字で運用した。
・今回このプログラムを公開するために、２バイト数字文字表示を実現させた。
・その後 J31BASICで各種エミュで動くことが分かったので、CDBL$()(２バイト数字文字）を復活させた。
・だけど CDBL$()を使ったら文字化け。
・結局TurboBasicと同じCDBL$()を使わない方法に戻した

で、文字化け等の原因ですが、J3100と IBM-PCの VGAで同じBIOSコールを使っていても
機能が微妙に違ったり VRAMへの描画形式が違うためと思われます。
VRAM領域は、VGAと J31の画面モード 75 が同じ A000h セグメントなので動くみたいです。
実機では動かないと思っていましたが、エミュでは何故か動くのです。

> 余談ですが、N88-BASICにはCDBL$()という関数はありません。
> 数値型のCDBL()という関数はあります。
> 引数を倍精度型に変換するという関数です。

この関数は J31BASIC にもあります。機能的にも同じようです。

> 積極的には使われない関数であることは間違いありません。

私も使ったことが無いです。(^^;

> > (2')でもJ3100以外の機械で使うためにCDBL$()を使わなくなった
> こちらですね。

理解できました。ありがとうございます。
ところで、CDBL$()を使わない方法ってどんなものですか？
Vzでよくやる、$824fを足しこむ、みたいなものかな。

> ところで、CDBL$()を使わない方法ってどんなものですか？
> Vzでよくやる、$824fを足しこむ、みたいなものかな。

Vzでよくやる、$824fを足しこむ、みたいなやりかたはしてないです。
「0」のコード $30 を「０」のコード $824f に変換ですか、出来そうですね。

私は単純に配列を使ってみました。

 DIM BB$(10)
 BB$(1)="１"
 BB$(2)="２"
 BB$(3)="３"
 BB$(4)="４"
 BB$(5)="５"
 BB$(6)="６"
 BB$(7)="７"
 BB$(8)="８"
 BB$(9)="９"
 BB$(0)="０"
PRINT BB$(VAL(MID$(TIME$,1,1)));BB$(VAL(MID$(TIME$,2,1)));

これで２桁の２バイト数字表示になります。
VZ式だと配列を使わないで

k!=&h824f
PRINT chr$(k!)

こんな感じ？　結果はエラーになりました。(>_<)

配列方式は、わかり易くていいんですけどね。
やっぱり、初期設定がちょっと手間がかかる気がして。
単なる気のせいなんでしょうけど。

> こんな感じ？　結果はエラーになりました。(>_<)

あぁそうか。
chr$だと1バイト値しか取れませんからね。
N88-BASICだとAKCNV$かKNJ$を使う、ということになっているのですが、私、KNJ$って
使った記憶がない。これは純粋に文字コードの変換しかしてくれなくて、表示の際には
もう一手間かかるので。

> chr$だと1バイト値しか取れませんからね。
> N88-BASICだとAKCNV$かKNJ$を使う、ということになっているのですが、私、KNJ$って
> 使った記憶がない。これは純粋に文字コードの変換しかしてくれなくて、表示の際には
> もう一手間かかるので。

それらの関数は J31BASICには無いですね。調べてみたら、「０」は、KTN$("０") 
これで区点コードで &K0316 が得られました。この形式なら CHR$() で表わせるようです。
PRINT CHR$(&K0316)
０

&K は定数なので、これではちょっと使えないなぁ。
さらに調べてみたら、「０」は、内部連続コードなら CHR$() で表わせるようです。
その換算表が手元に無いのでさらに調べたら、ASC("０") で連続コードが得られるようです。
PRINT ASC("０")
459

PRINT CHR$(459)
０

おお、これなら使えるかもしれない。０〜９までの数値は

2バイト 区点コード	連続コード
０	&K0316		459
１	&K0317		460
２	&K0318		461
３	&K0319		462
４	&K0320		463
５	&K0321		464
６	&K0322		465
７	&K0323		466
８	&K0324		467
９	&K0325		468

こうなりました。この内部連続コードを使えば配列がいらなくなりますね。
早速 BB$(I) を CHR$(I+459) に入れ替えてみました。
おお、動いた。＼(^^)／ ﾔｯﾀ-

でも、考えてみたら、TurboBasic ではこの関数使えないですね。
ということで、互換性を考えてこの案は没にします。(;_;) 時間を返せ〜

各種DOS/V系エミュのテキストモードで J31BASIC が動作する仕組みは大体わかりました。
J31BASIC では文字の読み書きなどを BIOSコールで行っていると思われます。
なので、BIOSレベルではほぼ互換なのでテキストが正常に表示出来ていると。

ところが VTDOSの場合、2バイト文字の表示にいくつか問題がありました。

・文字列の中で2バイト文字だけ表示位置が1バイト後ろにズレる。
　その後ろが1バイト文字の場合2バイト文字が表示されなくなる。

・CHR$()で文字表示の場合改行しないと(カーソル点滅で?)最後の文字が消えることがある。
　1バイト罫線文字などでもこの現象は起こる。必ず起こるわけではないのは点滅のせい？

・"日 月 火 水 木 金" これらの文字が特に表示されにくい("土"はそうでもない)
　カレンダーでは必須の文字なのでCHR$()を使って苦労して体裁を整えた。

いずれも結構な難題補間形書くで、どうにかこうにか見た目だけは正常に出来ました。(^^;
VTDOSだけ何故こうなるのかは謎ですね。

ちなみに DOSVAXJ3のVGAモードならカラーグラフィックも表示されます。
640*400 の範囲だけどね。(^^;

なんか昔、１バイト幅の２バイト文字、というのが話題になったようなおぼろげな
記憶が。PC-98でしたっけ？

文字だとちょっと思い出せないんですが……，
確か罫線で半角の2バイト素片があったように思います。

大昔のPC8801のN88-BASIC のマニュアルなんか見たら，
1/4角文字コードなんて掲載があって凄く笑った。
実は，カセットテープの背ラベルとかに割と重宝してたの思い出して，
なんだか切ないような愛おしさまで感じた。（PC88専用ワープロで対応してた）
データベースが使えなくて印字で現物管理していた遠い昔の話です。

としきさん
> なんか昔、１バイト幅の２バイト文字、というのが話題になったようなおぼろげな
> 記憶が。PC-98でしたっけ？

PC98で 2バイト半角というのは聞いたことがあります。

めざらさん
> 大昔のPC8801のN88-BASIC のマニュアルなんか見たら，
> 1/4角文字コードなんて掲載があって凄く笑った。

そんなのもあるんですか、面白いですね。

> 実は，カセットテープの背ラベルとかに割と重宝してたの思い出して，
> なんだか切ないような愛おしさまで感じた。（PC88専用ワープロで対応してた）
> データベースが使えなくて印字で現物管理していた遠い昔の話です。

私も8ビットのパソピア７に漢字パック入れてドットプリンタで漢字印字とかやってたような。
5インチFDDも買っていたので凄い出費でしたが、全部捨ててしまったのは惜しいことしたかなぁ。

DOSVAXJ3 Build JP240514版　(2024/5/14)が更新されました

内容は

build JP240514　(2024/5/14)

    タイトルバーに表示する文字列を指定する [sdl] titlebar が有効になっていなかったのを修正しました。
    タイトルバーに表示する文字列を変更するコマンド title を追加しました。
    macOS Sonoma 上での SDL-IM+ の不具合を修正しました。


[sdl] セクションで

titlebar          =
　　　　　↓
titlebar          = DOS/V

このように変更すると、窓のタイトルバーに表示されて、DOS/V モードか J31 モードか判別しやすくなります。
私は常時複数窓を開けて使い分けているので、コマンドラインで

title J31

等とすればその窓のタイトルが変わります。
タスクバーの表示も変わるので使い分けに便利です。

わがままな要望に応えてくださった軟式さんに感謝です。

最近 Cドライブの空き容量が急激に減少してほとんど無くなってきました。
色々不要なファイルを削除したり移動させても追いつきません。

ふと、VTDOSのエラーログ、vtd_err.log を確認してみたら、、、げげぇ、なんと！！
ギガ越えの超巨大ファイルになっているではないですか！！　なんじゃこりゃぁ！！
その原因は、J31BASICコンパイラの実行ファイル、STIME.EXE でした。

2024-04-16 10:01:41 STIME(09BA) 1876:4778 'サポート外 VIDEO BIOS(Int10h) 機能: AX=8500'
2024-04-16 10:01:42 STIME(09BA) 1876:47F1 'サポート外 VIDEO BIOS(Int10h) 機能: AX=8582'
2024-05-08 07:47:20 STIMEJ(2797) 433A:5982 'サポート外 KEYBOARD BIOS(int16h) 機能 F6'
2024-04-16 10:02:00 STIME(09BA) 1876:4D68 'サポート外 Int6F'

このようなエラーログが延々と出続けていたのです。
特に、Int10h AX=8500 〜 AX=8582 は毎秒３０くらい出続けていました。
なんてこった、これでは VTDOSで使えないではないか。(>_<)

この割り込みは、ブラウンデータにも載っていない J31独自機能のようです。
J3100テクニカルブックを発掘したので見ると、カーソル位置のアトリビュート読み込みのよう。
int16h 機能 F6 は、キーバッファのチェックのようです。
Int6F は、ATOK5制御割り込みのようです。

VTDOSには エラーログ抑制オプションとかは無さそうだし、どうしたものか・・・・

> ふと、VTDOSのエラーログ、vtd_err.log を確認してみたら、、、げげぇ、なんと！！
> ギガ越えの超巨大ファイルになっているではないですか！！　なんじゃこりゃぁ！！
> その原因は、J31BASICコンパイラの実行ファイル、STIME.EXE でした。

このVTDOSのエラーログを削除しても Cドライブの空き容量の減少が止まりません。
そして、ついに Cドライブの空き容量がゼロになってしまいました。
その時ふと、DOSVAXJ3のフォルダを覗いてみたら、capture フォルダが出来ていて
こんな感じになっていました。げげぇ！！！

2024/04/26  05:15     5,866,799,616 stime_000.wav
2023/04/10  16:46             7,343 dosbox_000.png
2023/04/10  16:54         1,892,112 dosbox_000.wav
2023/04/10  16:54             7,202 dosbox_001.png
2024/03/06  14:10             5,300 stime510_000.png
2024/03/06  07:40         2,311,592 stime510_000.wav
2024/03/06  07:41         4,845,752 stime510_001.wav
2024/03/06  13:51         1,952,792 stime510_002.wav
2024/03/06  13:57        52,911,756 stime510_003.wav
2024/03/06  13:58         6,592,112 stime510_004.wav
2024/03/06  14:00        23,988,684 stime510_005.wav
2024/03/06  14:10        46,314,040 stime510_006.wav
2024/03/06  14:33       158,472,688 stime510_007.wav
2024/03/06  14:33         5,609,564 stime510_008.wav
2024/03/09  23:59     3,240,653,264 stime_000.wav
2024/03/09  23:59         1,792,092 stime_001.wav
2024/03/09  23:59            66,900 stime_002.wav
2024/03/09  23:59         1,114,112 stime_003.wav
2023/04/10  16:54         1,892,112 dosbox_000.wav

※ これはもう１台のPCの中身。件のデータはもっと巨大で、緊急事態につき速攻で削除しました。

どうやら DOSVAXJ3 の機能キーを不用意に押してしまったようです。

キー割当  機能名
Ctrl-F5   Screenshot
Ctrl-F6   Rec Wave

この辺のキー割り当てを弄ったので、その時に押してしまったと思われます。

＃　C部の空き丸ごと消滅だと！
　　良くわからないものを無理して使うからよ・・・

PCの警告が出て、Cドライブのクリーンアップが推奨されたので、しかたなく OK しました。
その結果、３分の１くらい空きができました。（大丈夫なのか）
その後は問題なく動作しているようなので、まあいいか。(^^;

> 2024-04-16 10:01:41 STIME(09BA) 1876:4778 'サポート外 VIDEO BIOS(Int10h) 機能: AX=8500'
> 2024-04-16 10:01:42 STIME(09BA) 1876:47F1 'サポート外 VIDEO BIOS(Int10h) 機能: AX=8582'
> 2024-05-08 07:47:20 STIMEJ(2797) 433A:5982 'サポート外 KEYBOARD BIOS(int16h) 機能 F6'
> 2024-04-16 10:02:00 STIME(09BA) 1876:4D68 'サポート外 Int6F'
> 
> このようなエラーログが延々と出続けていたのです。

これを何とかしないと J31BASICコンパイラは使い物にならないですね。
それで考えたのは、常駐プログラムでこれらの割り込みを横取りして無効化すること。

私がいつもお世話になっている、アセンブラ入門のサイトから
トップ-> アセンブラ 第2章-> 第2章.メモリー管理-> 2-7. 常駐プログラム(TSR)
https://programmer.main.jp/assembler2/assembler10.html

このページの、「HOOK21」完成版(?) のソースを元に、INT10h でやってみたら出来ました。
ところが常駐解除が出来ないのです。
色々やってみてわかったのは、ソースの解放チェックルーチンで

STAY_CHEK:
	mov	ax,3521h
	int	21h             	;割り込みベクター取得

	mov	ax,es           	;解放できるかのチェック
	dec	ax
	mov	es,ax
	mov	di,8
	cld
	mov	si,offset PRCNAME
;	mov	cl,7			;★ cl ではうまくいかない、
	mov	cx,7			;★ cx ならうまくいく

	repz	cmpsb            	;名前が一緒かのチェック
	or	cx,cx
	jz	_STAY
	stc                     	;解放できない
	ret
_STAY:                           	;解放できる
	clc
	ret

★印のところの cl を cx に変えたら常駐解除できました。

＃ 汚れていたのは ch だったのです。

これで調子に乗って、INT16h  INT6Fh  も一緒にしてしまいました。
でもまたもや常駐解除が出来ない。(>_<)
プログラムの仕組みがわかってないからでしょうね。(;_;)

どうも、新着情報のページの表示がおかしいですね。
すぐにプッシュアウトされてしまいそうなので具体的に言うと、野ざらし言の
新着情報の部分、野ざらし言#5602の発言のところ。
ざっくり見てみたところ、野ざらし言#5602の発言本文の中のリンク情報を
拾って、偽のリンク情報を無理やり構築している模様。

ご確認いただけると幸いです。

> 新着情報の部分、野ざらし言#5602の発言のところ。
> ざっくり見てみたところ、野ざらし言#5602の発言本文の中のリンク情報を
> 拾って、偽のリンク情報を無理やり構築している模様。

ああ、本当だ、おかしいですね。
掲示板の形式とか変わったのでしょうかね。
見てみます。

掲示板の形式が変わったわけないじゃないですか。(笑)
ただ，うちだけの問題なのかな。

例えば，こちらで似たようなリンクを書き込んでみると……(^^;

#5601：Re^14: 近況報告 めざら 2024/05/25(Sat)
http://mezala.la.coocan.jp/bbs/noz/wforum.cgi?mode=msgview&page=0&no=5601&reno=5600&oya=5561

あるいは，
http://mezala.la.coocan.jp/bbs/noz/wforum.cgi?mode=allread&no=5561#N5602
みたいにハッシュが付いているリンクの場合とか。

違うなぁ……

あれ？　今度は VTDOS BBS の新着へのリンクが消えちゃったな。
消えたと言うか，a要素リンク内の値を括るダブルコーテーションが閉じていない？
<tr><td><a href="http://tamaneko.world.coocan.jp/bbs/http://mezala.la.coocan.jp/bbs/noz/wforum.cgi?mode=allread&amp;no=5561#N5602' target='_blank' rel='noopener noreferrer' target='_blank' rel='noopener noreferrer'>???????e?[?}</a></td><td>11256</td></tr>
新着情報そのものは取得しているみたいだけれど，ダブルコーテーションの出力エラーで該当行以降が表示されないのと，他のBBSの不思議なリンクも中途半端に含まれていますね。
もしかして弄っている途中でしたか？

なるほど、めざらさんの実験で、なんとなく見えてきたようです。
konnoさんの使われているコードって、１つ分の発言全体から、ある特定の形式の
URLを手がかりにして、本文だのなんだの不要なところを消して、<tr>から</tr>に
はさまれた形に変換しているのでしょう。
ここで使ってるのは正規表現置換と見た。置換一発か複数発かはわかりませんが。
でも、今回、その特定の形式に該当してしまうURLが１つの発言に複数含まれて
しまった、ということかと。
今までは、仮にURLがあっても、その特定の形式に該当するものではなかったので
発病しなかった、のではないかなぁ。
なので、正規表現を駆使して、何番目に該当するものだけ残す、みたいにすれば
解決しそうな気がする。

ハズレかな。