> 最大値はもっといけるかもですが、時間的に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 の窓を閉じればいいんだし。(^^;

> 上のほうから見ていって、まず気がついたのが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もありそうです。
移植するなら、他の素数プログラムが良いと思います。
私のは全く実用的でないので。(^^;
これからアップしますね。

> 自己流で改造したので間違いがある可能性はあります。

プログラムの中身はぜんぜん読めていませんが。

> ・起動時オプション 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

こんな感じで無理やり強制的にループの制御変数の値を書き換えてしまう、という
ワザが使われていました。

> ソースリスト冒頭のコメントで
> '  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

> だって、#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 という構文に引っ張られたような・・・(^^;

> オリジナルの 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 

こんな感じで十分だと思う。

> なるほど、MODって関数なんですね。
> N88-BASICでは演算子なんですけどね。

あう、MOD は演算子でしたね、失礼しました。

> これをそのままN88-BASICに移植すると、こんな感じかなぁ。
> 実行していないので、そのまま動くかどうかはわかりません。

> TurboBasicって、MOD関数またはMOD演算子ってないんですか？

もちろんありますが、32767以上は駄目みたいです。

> あと、NEXTの後ろの変数って省略できないんですか？
> でもコンパイラ言語だからあんまり関係ないのか。

省略できると思います。指定した方がわかりやすいと思うので。

> ８ビットのBASICのころは、NEXTの後ろの変数を省略するとマイクロ秒の単位で速く
> なると信じられていて、だから私も省略するのが癖になっているのですよ。

コンパイラ言語ではあんまり関係ないのかもしれないなと思います。

> 高速化といえば、最初のFORの直下のIF文。
> これはループの中に入れておくのはもったいない。
> だって、１回しか比較する必要がないものを何回も比較することになるわけだから。

これはその通りですね、最初の FOR文はいらなかったですね。
うっかりしていました。(^^;
 SOSU のソースから切り貼りしたのをそのまま残してしまったのかなぁ。(^^;

> これですね、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 はオプションの数字で、カウントがこの数字以上になったら次の数字ぶん表示しない
という感じですかね。ほとんど意味がないようですが。(^^;

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 などを使うのが良いのでしょうね。

> 自宅に戻ったらアップロードしたいな。

アップロードしました。

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 なので、素数では無いと思います。
今日は眠いのでこれ以上の調査は明日以降ということで。(^^;

> > 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 

２〜３秒遅くなりましたね。これが関数とサブルーチンの速度差と思われます。
思ったよりも差が無いなぁ、というのが感想です。(^^;

素数のネタはこの辺でしまいにしたいところですね。

実家に来ています。
まず、先日アップしたあのプログラムをそのまま実行したのですが

> 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の精度疑惑も晴れたので、９８エミュの検証が必要そうですね。

> これは驚きです！　ということは、９８エミュの問題か、ファイルが壊れているか

エミュの問題、というのは考え易いところです。
が、ファイルの破壊となった場合、そんな精度に関係するところが絶妙に壊れる、
というのはなかなか考えにくい。
ただ、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のコンパイラと
インタプリタで同じ結果になります？
あと、インタプリタとコンパイラでバージョンは同じですか？

> その場合は、その定数表の一部だけが間違っているとか精度が足りないことが発生
> しうるわけです。でも、これって、三角関数とか対数関係の関数で使うワザだった
> ような気がする。
> 平方根でも使うことがあるのかなぁ。

原因が分かったような気がします。
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のコンパイラと
> インタプリタで同じ結果になります？

同じ結果になります。上の実験はインタプリタではしてないですが。

> あと、インタプリタとコンパイラでバージョンは同じですか？

同じだと思います。起動メッセージが同じなので。
日付は少し違いますね。

自分で実験できないのにあれこれ言って申し訳ありません。

> 条件を色々変えて試しても結果は変わらなかったのですが、ひとつだけ
> N88P.BAS
> ところがオリジナルを若干修正した以下
> PN88.BAS

N88P.BASとPN88.BAS、konnoさん的には「若干修正」かもしれませんが、内部的には
もしかしたら大幅な修正かもしれません。
そこで結果を教えていただきたいのが、

> PN88.BAS
> 110  defdbl a-z                                 '倍精度指定

ここを単精度指定にしたらどうなるか、ということ。
とても興味があります。

> > 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に問題が有るかどうかは、実機で確認する以外にわからないと思います。

> 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 が同じ数値ですね。
これでなにかわかるでしょうか。

> ということで、今回の結果を出した検証プログラム、#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があるの
ですが、これ、コンパイラだとあったほうがいいのですか？
それとも他の事情？
いえ、うちのインタプリタだと、必ず最後に入力プロンプトの「?」がはいるのが
うざいというかうっとうしくて。

> ループの最後というか、誤判定されるわけですよね。
> その、最後とそのもうひとつ前というか、単精度型と倍精度型でどうなっているのか
> 見たいな、ということです。

実行結果（数値は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が対応できていないのかしら？
やっぱり軟式さんに聞いてみようかな。

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は基本グラフィックモードだけなので、@でテキスト文字用に使い分けできます。

他にもあったかもですが、僅かの変更でコンパイラは通るようになり、動き始めました。
だが本当の地獄はこれから始まるのであった。


続く　・・・のか