[HOME]  [リストへもどる]  [全部表示 会議室風]  [最新100]  [最新50]   [新着40]    [全部表示 保存用]
新着記事 40

11251VTDOSの vtd_err.log のサイズが超巨大になってた件 投稿者:konno   2024/05/18(土) 23:57
  11226 番 konno さんへのコメント

最近 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 は毎秒30くらい出続けていました。
なんてこった、これでは VTDOSで使えないではないか。(>_<)

この割り込みは、ブラウンデータにも載っていない J31独自機能のようです。
J3100テクニカルブックを発掘したので見ると、カーソル位置のアトリビュート読み込みのよう。
int16h 機能 F6 は、キーバッファのチェックのようです。
Int6F は、ATOK5制御割り込みのようです。

VTDOSには エラーログ抑制オプションとかは無さそうだし、どうしたものか・・・・

    - No.11251 -   [コメント元:11226]     [リストへもどる ]
soft

11250DOSVAXJ3 Build JP240514版 更新 投稿者:konno   2024/05/15(水) 00:34


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

等とすればその窓のタイトルが変わります。
タスクバーの表示も変わるので使い分けに便利です。

わがままな要望に応えてくださった軟式さんに感謝です。

    - No.11250 -             [リストへもどる ]
pre

11249Re^3: VTDOSは 2バイト文字の表示に難有り 投稿者:konno   2024/05/14(火) 22:08
  11248 番 めざら さんへのコメント

としきさん
> なんか昔、1バイト幅の2バイト文字、というのが話題になったようなおぼろげな
> 記憶が。PC-98でしたっけ?

PC98で 2バイト半角というのは聞いたことがあります。

めざらさん
> 大昔のPC8801のN88-BASIC のマニュアルなんか見たら,
> 1/4角文字コードなんて掲載があって凄く笑った。

そんなのもあるんですか、面白いですね。

> 実は,カセットテープの背ラベルとかに割と重宝してたの思い出して,
> なんだか切ないような愛おしさまで感じた。(PC88専用ワープロで対応してた)
> データベースが使えなくて印字で現物管理していた遠い昔の話です。

私も8ビットのパソピア7に漢字パック入れてドットプリンタで漢字印字とかやってたような。
5インチFDDも買っていたので凄い出費でしたが、全部捨ててしまったのは惜しいことしたかなぁ。

    - No.11249 -   [コメント元:11248]     [リストへもどる ]
soft

11248Re^2: VTDOSは 2バイト文字の表示に難有り 投稿者:めざら   2024/05/14(火) 16:47
参照先:http://mezala.la.coocan.jp/
  11247 番 としき さんへのコメント    コメント数 1

文字だとちょっと思い出せないんですが……,
確か罫線で半角の2バイト素片があったように思います。

大昔のPC8801のN88-BASIC のマニュアルなんか見たら,
1/4角文字コードなんて掲載があって凄く笑った。
実は,カセットテープの背ラベルとかに割と重宝してたの思い出して,
なんだか切ないような愛おしさまで感じた。(PC88専用ワープロで対応してた)
データベースが使えなくて印字で現物管理していた遠い昔の話です。
    - No.11248 -   [コメント元:11247]     [リストへもどる ]
soft

11247Re: VTDOSは 2バイト文字の表示に難有り 投稿者:としき   2024/05/13(月) 22:24
参照先:http://toshiki.la.coocan.jp/
  11246 番 konno さんへのコメント    コメント数 1

なんか昔、1バイト幅の2バイト文字、というのが話題になったようなおぼろげな
記憶が。PC-98でしたっけ?

    - No.11247 -   [コメント元:11246]     [リストへもどる ]
soft

11246VTDOSは 2バイト文字の表示に難有り 投稿者:konno   2024/05/13(月) 15:07
  11226 番 konno さんへのコメント    コメント数 1

各種DOS/V系エミュのテキストモードで J31BASIC が動作する仕組みは大体わかりました。
J31BASIC では文字の読み書きなどを BIOSコールで行っていると思われます。
なので、BIOSレベルではほぼ互換なのでテキストが正常に表示出来ていると。

ところが VTDOSの場合、2バイト文字の表示にいくつか問題がありました。

・文字列の中で2バイト文字だけ表示位置が1バイト後ろにズレる。
 その後ろが1バイト文字の場合2バイト文字が表示されなくなる。

・CHR$()で文字表示の場合改行しないと(カーソル点滅で?)最後の文字が消えることがある。
 1バイト罫線文字などでもこの現象は起こる。必ず起こるわけではないのは点滅のせい?

・"日 月 火 水 木 金" これらの文字が特に表示されにくい("土"はそうでもない)
 カレンダーでは必須の文字なのでCHR$()を使って苦労して体裁を整えた。

いずれも結構な難題補間形書くで、どうにかこうにか見た目だけは正常に出来ました。(^^;
VTDOSだけ何故こうなるのかは謎ですね。

ちなみに DOSVAXJ3のVGAモードならカラーグラフィックも表示されます。
640*400 の範囲だけどね。(^^;

    - No.11246 -   [コメント元:11226]     [リストへもどる ]
soft

11245Re^6: A000h VRAM領域と CDBL$() の問題 投稿者:konno   2024/05/12(日) 02:04
  11244 番 としき さんへのコメント

> chr$だと1バイト値しか取れませんからね。
> N88-BASICだとAKCNV$かKNJ$を使う、ということになっているのですが、私、KNJ$って
> 使った記憶がない。これは純粋に文字コードの変換しかしてくれなくて、表示の際には
> もう一手間かかるので。

それらの関数は J31BASICには無いですね。調べてみたら、「0」は、KTN$("0") 
これで区点コードで &K0316 が得られました。この形式なら CHR$() で表わせるようです。
PRINT CHR$(&K0316)
0

&K は定数なので、これではちょっと使えないなぁ。
さらに調べてみたら、「0」は、内部連続コードなら CHR$() で表わせるようです。
その換算表が手元に無いのでさらに調べたら、ASC("0") で連続コードが得られるようです。
PRINT ASC("0")
459

PRINT CHR$(459)
0

おお、これなら使えるかもしれない。0〜9までの数値は

2バイト 区点コード	連続コード
0	&K0316		459
1	&K0317		460
2	&K0318		461
3	&K0319		462
4	&K0320		463
5	&K0321		464
6	&K0322		465
7	&K0323		466
8	&K0324		467
9	&K0325		468

こうなりました。この内部連続コードを使えば配列がいらなくなりますね。
早速 BB$(I) を CHR$(I+459) に入れ替えてみました。
おお、動いた。\(^^)/ ヤッタ-

でも、考えてみたら、TurboBasic ではこの関数使えないですね。
ということで、互換性を考えてこの案は没にします。(;_;) 時間を返せ〜

    - No.11245 -   [コメント元:11244]     [リストへもどる ]
pre

11244Re^5: C000h VRAM領域と CDBL$() の問題 投稿者:としき   2024/05/11(土) 11:11
参照先:http://toshiki.la.coocan.jp/
  11243 番 konno さんへのコメント    コメント数 1

配列方式は、わかり易くていいんですけどね。
やっぱり、初期設定がちょっと手間がかかる気がして。
単なる気のせいなんでしょうけど。

> こんな感じ? 結果はエラーになりました。(>_<)

あぁそうか。
chr$だと1バイト値しか取れませんからね。
N88-BASICだとAKCNV$かKNJ$を使う、ということになっているのですが、私、KNJ$って
使った記憶がない。これは純粋に文字コードの変換しかしてくれなくて、表示の際には
もう一手間かかるので。

    - No.11244 -   [コメント元:11243]     [リストへもどる ]
soft

11243Re^4: C000h VRAM領域と CDBL$() の問題 投稿者:konno   2024/05/11(土) 01:03
  11242 番 としき さんへのコメント    コメント数 1

> ところで、CDBL$()を使わない方法ってどんなものですか?
> Vzでよくやる、$824fを足しこむ、みたいなものかな。

Vzでよくやる、$824fを足しこむ、みたいなやりかたはしてないです。
「0」のコード $30 を「0」のコード $824f に変換ですか、出来そうですね。

私は単純に配列を使ってみました。

DIM BB$(10)
BB$(1)="1"
BB$(2)="2"
BB$(3)="3"
BB$(4)="4"
BB$(5)="5"
BB$(6)="6"
BB$(7)="7"
BB$(8)="8"
BB$(9)="9"
BB$(0)="0"
PRINT BB$(VAL(MID$(TIME$,1,1)));BB$(VAL(MID$(TIME$,2,1)));

これで2桁の2バイト数字表示になります。
VZ式だと配列を使わないで

k!=&h824f
PRINT chr$(k!)

こんな感じ? 結果はエラーになりました。(>_<)

    - No.11243 -   [コメント元:11242]     [リストへもどる ]
soft

11242Re^3: C000h VRAM領域と CDBL$() の問題 投稿者:としき   2024/05/10(金) 13:07
参照先:http://toshiki.la.coocan.jp/
  11241 番 konno さんへのコメント    コメント数 1

> > (2')でもJ3100以外の機械で使うためにCDBL$()を使わなくなった
> こちらですね。

理解できました。ありがとうございます。
ところで、CDBL$()を使わない方法ってどんなものですか?
Vzでよくやる、$824fを足しこむ、みたいなものかな。

    - No.11242 -   [コメント元:11241]     [リストへもどる ]
soft

11241Re^2: C000h VRAM領域と CDBL$() の問題 投稿者:konno   2024/05/10(金) 01:02
  11240 番 としき さんへのコメント    コメント数 1

> (2')でもJ3100以外の機械で使うためにCDBL$()を使わなくなった

こちらですね。
経緯は書いていますが、もう一度整理すると

・元々J3100 で使うために J31BASICでCDBL$()(2バイト数字文字)を使っていた。
・でも、PCがWin95ノートに変わってしまい、J3100のプログラムが動かなくなったので
 TurboBasicに移植して、CDBL$()が使えないので、1バイト数字文字で運用した。
・今回このプログラムを公開するために、2バイト数字文字表示を実現させた。
・その後 J31BASICで各種エミュで動くことが分かったので、CDBL$()(2バイト数字文字)を復活させた。
・だけど CDBL$()を使ったら文字化け。
・結局TurboBasicと同じCDBL$()を使わない方法に戻した

で、文字化け等の原因ですが、J3100と IBM-PCの VGAで同じBIOSコールを使っていても
機能が微妙に違ったり VRAMへの描画形式が違うためと思われます。
VRAM領域は、VGAと J31の画面モード 75 が同じ A000h セグメントなので動くみたいです。
実機では動かないと思っていましたが、エミュでは何故か動くのです。

> 余談ですが、N88-BASICにはCDBL$()という関数はありません。
> 数値型のCDBL()という関数はあります。
> 引数を倍精度型に変換するという関数です。

この関数は J31BASIC にもあります。機能的にも同じようです。

> 積極的には使われない関数であることは間違いありません。

私も使ったことが無いです。(^^;

    - No.11241 -   [コメント元:11240]     [リストへもどる ]
soft

11240Re: C000h VRAM領域と CDBL$() の問題 投稿者:としき   2024/05/09(木) 22:22
参照先:http://toshiki.la.coocan.jp/
  11234 番 konno さんへのコメント    コメント数 1

ごめんなさい、ここのところがよくわからないので解説希望。

> その原因は、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%
とした場合と何が違うのか、あまり知られていません。違いはないのかも。
積極的には使われない関数であることは間違いありません。

    - No.11240 -   [コメント元:11234]     [リストへもどる ]
soft

11239C000h セグメントは間違い、A000h でした。m(__)m 投稿者:konno   2024/05/06(月) 01:56
  11234 番 konno さんへのコメント

> 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アドレスがバラバラですね。

    - No.11239 -   [コメント元:11234]     [リストへもどる ]
pre

11238Re: DOSVAXJ3 Build JP240502 更新 投稿者:konno   2024/05/05(日) 02:37
  11237 番 めざら さんへのコメント

> ……てことで,あまり関係ないかしら(^^;)

あうう、更新の記事を上げようとしたら先を越されてしまいました。(^^;

問題無く動作しますが、特に変化は感じないです、(^^;
この機会にJ31関連でちょっと要望などしてみようかしら。(^^;

    - No.11238 -   [コメント元:11237]     [リストへもどる ]
soft

11237DOSVAXJ3 Build JP240502 更新 投稿者:めざら   2024/05/05(日) 00:19
参照先:http://mezala.la.coocan.jp/
   コメント数 1

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

・J-3100 モードの場合、int 10h ah=02h のカーソル位置指定で bh のページ番号は使用せず常に 0 となるよう修正しました。
・J-3100 の int 10h ax=8200h でスクロールモードを変更した後に画面クリアするよう修正しました。
・macOS 上での SDL-IM+ の不具合を修正しました。

……てことで,あまり関係ないかしら(^^;)
    - No.11237 -             [リストへもどる ]
soft

11236Re^6: LXCLND.DEF の祝日変更対応版 投稿者:konno   2024/05/03(金) 22:01
  11235 番 めざら さんへのコメント

> > 疑似カーソルって、Shift+カーソルキーで () の日を移動出来るんですね。
> メニュー表示中のコマンドキーを受けるもののうち,以下の四つですね。
> (#37)	{ r=7, &11 }
> (#38)	{ r=7, &12 }
> (#a)	{ r=1, &11 }
> (#f)	{ r=1, &12 }

なるほど、詳細な解説ありがとうございます。
これなら改造も出来そうな気がしてきました。(やらないけど。(^^;)

> メニューアイテムの書換えというのはトンでもなく面倒なわけで,
> オリジナルのnomad版ではテキストに書き出すという手法をとっていたため
> konnoさんのようにキーを押しっぱなしにしたりする人(^^;はとても使えなかった。

い、いやぁ、、、そんなことは・・・ない、と思いますです。(^^;
実際のところ今カレンダ表示をモードによって分岐を変えるので四苦八苦してます。
とんでもないスパゲッティが出来上がりつつあり、ソースでごまかせるのかと。(^^;

> あ,元に戻って,「日付」というのは保持している値なので,あまり意味はなく,
> 「当日」を指示されたときだけリセットするというイメージですね。

これ、勘違いしていました。疑似カーソルの意味がやっとわかりました。
スケジュールとのリンクとか日付出力とかでこの機能が必要だったのですね。

    - No.11236 -   [コメント元:11235]     [リストへもどる ]
pre

11235Re^5: LXCLND.DEF の祝日変更対応版 投稿者:めざら   2024/05/02(木) 13:17
参照先:http://mezala.la.coocan.jp/
  11233 番 konno さんへのコメント    コメント数 1

> 疑似カーソルって、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さんなんか,メニューで十字カーソルですぜ。
そんな面倒なコードをよく書くものだなぁとひたすら感心します。

あ,元に戻って,「日付」というのは保持している値なので,あまり意味はなく,
「当日」を指示されたときだけリセットするというイメージですね。
    - No.11235 -   [コメント元:11233]     [リストへもどる ]
pre

11234C000h VRAM領域と CDBL$() の問題 投稿者:konno   2024/05/01(水) 17:48
  11226 番 konno さんへのコメント    コメント数 2

新しい STIME では、TIMER.DAT にタイマー画面を退避させています。
J31用BASICコンパイラを動作させてみると、その画面がおかしい。
ぐちゃぐちゃになっているのです。

TurboBasic では、48桁 23行で以下のように表示されます。
1行目は、d-他の受け渡しに使っています。

 1             1 
>                                               
 1日 17:16:31   0: 0: 0    0: 0: 9        
                                                
  中略
                                                
     1日 17:16:33   0: 0: 0   0: 0: 7     


J31BASIC では、各エミュごとに全部違っています。

VTDOS 4/13
13 把  0Oマ: 4Sマ: 4Sツ   8:12'45    0: 0:19        
                                                
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

VTDOS 4/21
21日^@^@02:38:31  0: 0: 0   0: 6:48 ^@^@^@^@^@^@
                                                
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

VTDOS 5/1
 1日  17:22:54  0: 0: 0   0: 0: 8       
                                                

最初は2バイト文字が変に文字化けして、背景のスペースがヌルになっています。
現在は正常表示になっていますが、ここまでするのに一苦労でした。

DOSVAXJ3 VGAモード
12日cc 1PP6UU:2QQ9XX:1PP0OO   0  8:40:54 0: 0: 3
                                                
ロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロ
ロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロロ

DOSVAXJ3 J31モード
13日日 0011:0077:4477   0: 0'26    0: 0:13        
                                                
                                                
MS-DOS Player
13日c 0O0O:5T3R:3R0O   0: 0' 0    0: 0:11        
                                                
                                                
このように、どのエミュでも2バイト文字が化けたり2重になったりしています。
その原因は、J31BASIC の CDBL$() という、1バイトの数字を2バイト文字に変換する関数でした。
元々は J3100 でこの関数を使って表示していたので元に戻してみたらこうなったということです。
しかたがないので、TurboBasic と同じやり方に戻しました。

背景の空白が ヌル文字になったり、DOSVAXJ3 VGAモード では、$DB で埋められています。
これは、VRAM領域のメモリの状況によると思われます。
C000h セグメントは VGAの領域で確保されていると思いますが、初期化の問題なのかな。
VTDOS では、TPAEXT などでメモリ拡張していると干渉すると思われるので要注意です。

ともかく、動くのが不思議な状態なので、このまま使うのがよろしいようです。
                                                

    - No.11234 -   [コメント元:11226]     [リストへもどる ]
pre

11233Re^4: LXCLND.DEF の祝日変更対応版 投稿者:konno   2024/05/01(水) 16:02
  11232 番 めざら さんへのコメント    コメント数 1

> > 表示月を移動しても同じ日付に () が付いたままになっていますね。
> 日付出力のために疑似カーソルを表示しています。
> これは当日であるとは限らないです。(当日は[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 ----

こうなると全く読めないので追及は諦めます。(^^;

    - No.11233 -   [コメント元:11232]     [リストへもどる ]
pre

11232Re^3: LXCLND.DEF の祝日変更対応版 投稿者:めざら   2024/04/30(火) 08:26
参照先:http://mezala.la.coocan.jp/
  11231 番 konno さんへのコメント    コメント数 1

> 表示月を移動しても同じ日付に () が付いたままになっていますね。

日付出力のために疑似カーソルを表示しています。
これは当日であるとは限らないです。(当日は[TAB]入力直後の表示)

    - No.11232 -   [コメント元:11231]     [リストへもどる ]
soft

11231Re^2: LXCLND.DEF の祝日変更対応版 投稿者:konno   2024/04/29(月) 23:16
  11230 番 めざら さんへのコメント    コメント数 1

> わたしもオリ・パラ関連特別措置法による移動は無視しました。

これは Wikipedia でも参考程度になっていますね。

> 四月と五月は敢えて弄りませんでした。祝日名を表示するわけでもないので。

そうなんですよね、表示は同じなんですが、オリジナルでも分けているところがありましたので。

ところで、今回 LXCLND.DEF で気が付いたところがあります。
中央のカレンダに今日の日付が () に囲われてわかりやすくなっていますが
表示月を移動しても同じ日付に () が付いたままになっていますね。

これはバグという見方もできますが、仕様かもしれないと思いました。
このマクロはスケジュール管理のために月を変えてカレンダを参照しやすくなっています。
その時、今日は何日だっけ?と思うこともありそうなので、その確認になるかなと。
なので、この仕様はこのままにしておきます。

STIME でも現在の日付に色付けしていますが、改編時バグって毎月同じ日付に色がついて
修正に苦労したりして。いや、年取って頭が働かなくなっただけなんですけどね。(^^;

う、そういえば今日は祝日なのに今日の日付が赤になっていない。(>_<)
うーん、直せるかしら・・・(^^;

    - No.11231 -   [コメント元:11230]     [リストへもどる ]
soft

11230Re: LXCLND.DEF の祝日変更対応版 投稿者:めざら   2024/04/29(月) 07:36
参照先:http://mezala.la.coocan.jp/
  11228 番 konno さんへのコメント    コメント数 1

わたしもオリ・パラ関連特別措置法による移動は無視しました。
四月と五月は敢えて弄りませんでした。祝日名を表示するわけでもないので。

    - No.11230 -   [コメント元:11228]     [リストへもどる ]
soft

11229STIME.EXE Ver 240428 投稿者:konno   2024/04/28(日) 22:21


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では動かないので注意してください。

    - No.11229 -             [リストへもどる ]
soft

11228LXCLND.DEF の祝日変更対応版 投稿者:konno   2024/04/27(土) 23:07
   コメント数 1

STIME のカレンダ表示などを弄っていて、LXCLND.DEF と表示を比べてみたら
2月23日とか12月23日など違っている日がいくつかありました。
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


    - No.11228 -             [リストへもどる ]
pre

11227STIMEでリアルタイムのタイマー 投稿者:konno   2024/04/24(水) 22:01


ココログからの転載記事です。
http://tamaneko2.cocolog-nifty.com/vz2/2024/04/post-6e6da8.html
これは、TurboBasic の STIME です。
先にこちらを上げないといけないので。(^^;


STIMEでリアルタイムのタイマー機能を追加しました。
きっかけは白内障の手術です。
術後点眼薬を3種類1日に4回または2回挿すことになりました。
3種類を5分間隔で、4時間以上空けて1日に4回を毎日3カ月間続けるのです。

忘れっぽい私は、STIMEのタイマー機能を使えば点眼管理が楽になると思ったのですが
キーを押した時に経過時間を表示するだけの簡易タイマーなので、あまり便利に思えません。
経過時間をリアルタイムに表示出来れば便利だろうと思い、機能追加しました。

STIME41 画像参照

以前はこのように2系統のタイマーを2列表示していましたが
リアルタイマーは上下2系統にし、黄色で表示します。

STIME51 画像参照

これで5分間隔の点眼は便利になったのですが、4時間以上経過したかわかりにくいので
アナログ時計にマーキングすることを思いつきました。

STIME556 画像参照

黄色の丸が [F06] で、ピンクの丸が [F07] です。
時計の丸枠に掛かっている丸は短針の位置で時間を示します。
時計の丸枠の内側の丸は長針の位置で、分を示します。

やってみると、分の表示はごちゃごちゃしてわかりにくいですね。
そこで、5分とか指定時間が経過したらカラー表示で知らせるビジブルベルを追加。

STIME557 画像参照

指定所間を経過するとカラーバーを色を変化させて表示します。

[ESC] でカラー表示のビジブルベルを解除できます。
時間など各種設定のために、STIME.DAT で設定できるようにしました。

MS-DOS Playerではこのように表示します。

STIME558 画像参照

これだとPC画面の隅に1文字分でも表示させておけばほかの作業中でもわかります。

これはいい!

    - No.11227 -             [リストへもどる ]
soft

11226J31用BASICコンパイラの各エミュ対応沼 投稿者:konno   2024/04/23(火) 01:23
   コメント数 3

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

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


続く ・・・のか

    - No.11226 -             [リストへもどる ]
pre

11225Re^13: SQRの単精度と倍精度の表示検証ソース 投稿者:konno   2024/04/17(水) 23:21
  11224 番 としき さんへのコメント

> 鶴亀算は整数演算です。
> 何だろう、何と勘違いしたんだろう。おいらにはわからない。

あう、多分整数演算の事だと思います。(>_<)
私は算数も数学も苦手というか、数字の計算や記憶が全くダメなんですね。
だからパソコンにやらせようと思うのです。(^^;

    - No.11225 -   [コメント元:11224]     [リストへもどる ]
soft

11224Re^12: SQRの単精度と倍精度の表示検証ソース 投稿者:としき   2024/04/17(水) 02:14
参照先:http://toshiki.la.coocan.jp/
  11223 番 konno さんへのコメント    コメント数 1

konnoさん、なんか他のものを連想している。

> 鶴亀算みたいなものでしたっけ? 結構面倒くさいんですよね。

鶴亀算は整数演算です。
何だろう、何と勘違いしたんだろう。おいらにはわからない。

    - No.11224 -   [コメント元:11223]     [リストへもどる ]
soft

11223Re^11: SQRの単精度と倍精度の表示検証ソース 投稿者:konno   2024/04/16(火) 23:58
  11222 番 としき さんへのコメント    コメント数 1

> もっとも世の中には、既知のバグどころか未知のバグまで再現したエミュレータと
> いうものもある模様。実機で新たなバグが発見されてから、エミュレータでも同じ
> バグが発現した、なんて話もあるようで、とても不思議。こういうのが、いわゆる
> 「完璧なエミュレータ」というやつでしょう。なぜ作れるんだろう。

それはきっと、リバーs^ ・・・ いや、なんでもないです。(^^;

> 実は私、実数演算についてはちょっとだけやかましい。
> #2066とか#10367にも書いたけど、大昔、8ビットマシンの時代、実数演算のマシン語
> ルーチンを書いてハンドアセンブルしていたもので。
> といっても四則演算だけですけどね。

鶴亀算みたいなものでしたっけ? 結構面倒くさいんですよね。
丁度 DANNYさんの浮動小数演算ライブラリを目にしていたので見てみました。
ASMは1531行ありましたね。
バイナリは恐らく2千バイトくらいになるのかなぁ。

J3100用BASICコンパイラの続報も書かなくてはいけないのでこの辺で。

    - No.11223 -   [コメント元:11222]     [リストへもどる ]
soft

11222Re^10: SQRの単精度と倍精度の表示検証ソース 投稿者:としき   2024/04/16(火) 12:22
参照先:http://toshiki.la.coocan.jp/
  11221 番 konno さんへのコメント    コメント数 1

> ということは、そのバイナリコードは BIOS.ROM の中なのではないですか。

確かに .LIB のファイルのサイズが小さ目というところから、実際に LIB がやって
いることは ROM の中身の呼び出しのみ、という可能性は高そうです。

> この結果を忠実に再現するために、

ある意味、この結果「だけ」を忠実に再現している、という感じ。
もし「実機を忠実に再現」するのであれば、169は合成数と表示される必要がある。
この点がなされない限り、実機に対するエミュとしての完成度は今一歩、という
ところで終わってしまいそうです。
もっとも世の中には、既知のバグどころか未知のバグまで再現したエミュレータと
いうものもある模様。実機で新たなバグが発見されてから、エミュレータでも同じ
バグが発現した、なんて話もあるようで、とても不思議。こういうのが、いわゆる
「完璧なエミュレータ」というやつでしょう。なぜ作れるんだろう。

> 互換BIOS を作ったのは、著作権の問題回避の為なので、

これはそのとおりだと思いますが、その一方で、実数のバイナリ表現というものは
ある意味で規格化されているわけです。つまり、実数演算とかバイナリと十進数の
変換とかの部分は世の中にいくらでもサンプルコードとかライブラリとかのフリーで
使えるものが存在しているわけで、そしてそういうものを使えば少なくとも著作権の
問題は回避できるはず。さらに、その手のコードって世界中の人が見ているわけです
から、精度を落とす方向にいじることは少ないのではないかなぁ。というか、わざと
精度を落とす、なんてことに時間をかけるくらいならとっととリリースしてくれよ、
という気もする。
もちろん、そういうものを使わずに1からコードを書いていたら、十分な精度を確保
できていなくても不思議はないけど。
あ、でも、ありうるかな。
倍精度のほうが現在のありふれたものとは内部表現が異なっているようだから、そちら
のほうに合わせて、ということはあるかも。



実は私、実数演算についてはちょっとだけやかましい。
#2066とか#10367にも書いたけど、大昔、8ビットマシンの時代、実数演算のマシン語
ルーチンを書いてハンドアセンブルしていたもので。
といっても四則演算だけですけどね。

    - No.11222 -   [コメント元:11221]     [リストへもどる ]
soft

11221Re^9: SQRの単精度と倍精度の表示検証ソース 投稿者:konno   2024/04/16(火) 00:04
  11220 番 としき さんへのコメント    コメント数 1

> 続報をいただいたことで、誤解は氷解しました。

紛らわしい表現で誤解させてしまい申し訳ないです。
とりあえずホッとしました。

> > 単精度の精度もわざと落としているように見えます。

考えてみたら、これは表示だけなのかもしれませんね。
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は、細部の再現性にこだわったエミュという評価があるようなのですが
先のサンプルプログラムの結果は忠実に再現していますね。(^^;

    - No.11221 -   [コメント元:11220]     [リストへもどる ]
soft

11220Re^8: SQRの単精度と倍精度の表示検証ソース 投稿者:としき   2024/04/15(月) 13:56
参照先:http://toshiki.la.coocan.jp/
  11219 番 konno さんへのコメント    コメント数 1

> もしかしたら誤解させてしまったかもしれません。
> 他のエミュとは、98エミュ以外の、J31とかDOS/V系のエミュのことです。

はい、誤解しました。
続報をいただいたことで、誤解は氷解しました。

> NECのN88BASICは、あちこち変えているようですが、

うん、まぁ、その前のN-BASICからの互換性というのがありますからね。
そちらのほうでいろいろと変えていたところはあるかもしれません。

> 単精度の精度もわざと落としているように見えます。

こちらについてはどうなんだろう。
そうではないというわけではなく、根拠不足というか、これまでのところでは、私
にはそう思えるだけの挙動はないような気がしています。
ということで、ちょっと調べてみました。
まず、単精度は4バイトであらわす実数、倍精度は8バイトであらわす実数。
これは、調べた範囲では、どこも同じみたい。80年代の8ビットパソコンのBASIC
でも、21世紀の64ビットパソコンのCコンパイラでもおおむね一緒。
ところが、倍精度のほうが、最近の国際規格とN88BASICで異なるみたい。
#11164に書いたように、N88BASICでは倍精度の扱える上限は 1.7*10^38 ですが、
最近の規格では 1.8*10^308 まで扱えるらしい。
一方で単精度の方は最近の規格でも 1.7*10^38 で同じ。
内部表現についても、仮数部23ビット、指数部8ビット、符号1ビットという部分
に変化はない。
でも、だからN88の単精度では精度を落としていないかというといささか怪しいと
いうか断言はできない。
なにかというと、十進数との変換部分。
#11135にも書きましたが、仕様としては有効桁7桁、出力のときは7桁目が四捨五入
されて6桁で表示、となっているわけですよ。でも、他の処理系では例えば、有効桁
7桁で表示も7桁、となっているかもしれない。もしそうであれば少なくとも見かけ
の精度は落ちているわけです。あるいは、他の処理系では、7桁目で四捨五入では
なく切り捨て表示となっているかもしれないし。
ただ、あまりにも他のマシンと差があるようであれば、当時、大騒ぎになっている
のではないかなぁ。あの時代、ネットはなくてもパソコン雑誌はあったし、8ビット
のころはともかく16ビットの時代はパソコン通信もあったし。
ということで、とりあえず現時点では根拠不足としてkonnoさんのご意見に賛同は
しないでおきます。
#つまり、何かあればすぐに意見は変わる

ただ、エミュという意味では、よく言われる「バグまで再現した」というものが評価
が高いわけで、現状、実機と差異が出るエミュは、完成度としてはもう一歩、という
のが現実的な評価だと思われます。

    - No.11220 -   [コメント元:11219]     [リストへもどる ]
soft

11219Re^7: SQRの単精度と倍精度の表示検証ソース 投稿者:konno   2024/04/15(月) 01:15
  11218 番 としき さんへのコメント    コメント数 1

> NP2と他のエミュで差が出る、というところは一つの突破口かも。
> 少なくともNP2以外のエミュは仕様どおりではないということで、バグ報告は可能
> だと思います。おそらく、四捨五入するときの桁数を誤っていると想定されます。
> 仕様上は、有効桁7桁、出力のときは7桁目が四捨五入されて6桁で表示、という
> ことになっているのですから。

もしかしたら誤解させてしまったかもしれません。
他のエミュとは、98エミュ以外の、J31とかDOS/V系のエミュのことです。
今回 NP2以外の98エミュは確認していません。同じ結果になると思ったので。

ということで、ANEX86 や T98-NEXT のN88コンパイラ、インタプリタでも確認しました。
結果は NP2と 表示は全く同じでした。

> どうも、本来は7桁以上は格納してはいけないものを7桁以上格納している、その上
> 7桁以上で比較してはいけないものを7桁以上で比較している、というように見える
> わけですよ。

これが実際どうなのかはわかりませんが、BASICのルーツは MSのGW-BASICだと思います。
T-BASICなどは漢字処理を覗けば恐らくほとんどそのままの互換性だと思っているのですが
NECのN88BASICは、あちこち変えているようですが、単精度の精度もわざと落としているように見えます。
その辺がエミュでの誤動作の原因になっているのではないかと愚考します。

> konnoさんは、例えばバルーンパンチなんてゲームを覚えておられませんかね。
> シーソーに乗った人が交互にジャンプして上のほうで動いている風船を割っていく、
> というゲームです。

私はこの手のゲームはあまりやっていないので覚えていません。

> ときどき、当たり判定がバグっているゲームというのが話題になることがありますが、
> あれっていうのはもしかしたら、小数と整数の比較の際の誤差の問題かも。そして、
> 実機だと正常に動いていたのにエミュだとおかしい、というゲームなどがあった場合、
> それこそこのような小数の誤差の可能性は高いかも。

今回のことを踏まえるとそう考えられますね。

> もちろん、倍精度を使えば誤差は少なくなりますが、リアルタイムの計算の場合、
> 倍精度だとやっぱり重くなるので、たいていは単精度を使うでしょうし。

N88BASICは8ビット時代の互換性重視ではないかと思いますが、8ビットの貧弱なCPUで
ゲームの速度を上げるためにわざと単精度の桁を落としたのではないかと思います。
そして、16ビット版になっても互換性のためにそこを変えることが出来なかったのかも。

    - No.11219 -   [コメント元:11218]     [リストへもどる ]
soft

11218Re^6: SQRの単精度と倍精度の表示検証ソース 投稿者:としき   2024/04/14(日) 12:14
参照先:http://toshiki.la.coocan.jp/
  11216 番 konno さんへのコメント    コメント数 1

> NP2でやってみた結果です。
> 他のエミュの結果は全て以下の数値でした。
> 表示は全く同じなので、おかしくないということですね。(違う!)

NP2と他のエミュで差が出る、というところは一つの突破口かも。
少なくともNP2以外のエミュは仕様どおりではないということで、バグ報告は可能
だと思います。おそらく、四捨五入するときの桁数を誤っていると想定されます。
仕様上は、有効桁7桁、出力のときは7桁目が四捨五入されて6桁で表示、という
ことになっているのですから。
なので、以後は、NP2と実機の差異をどうするか。
どうも、本来は7桁以上は格納してはいけないものを7桁以上格納している、その上
7桁以上で比較してはいけないものを7桁以上で比較している、というように見える
わけですよ。
print usingを使う以外に、何かいい方法はあるかなぁ。


実際、この程度の小数の誤差がどの程度影響するかはわかりませんがね。
でも、もしかしたら、昔からゲームなんかでも使われている可能性はあるわけで。
konnoさんは、例えばバルーンパンチなんてゲームを覚えておられませんかね。
シーソーに乗った人が交互にジャンプして上のほうで動いている風船を割っていく、
というゲームです。
このゲームで飛んでいる人間は、まるで重力で引かれるような感じで頂点に向かって
減速して、また落下するときは加速するわけです。このゲームに限らず、まるで重力
に引かれたような動きをする、だとか、慣性が働いているようになかなか加速しない
上に速度が乗ったらすぐには止まれない、といった動きをするようなゲームでは、
もしもそれなりに理論的なアルゴリズムを使うならば、物体の位置決定に二次関数を
使う必要があるわけです。実際に使っているアルゴリズムがどこまで理論的に正しい
ものになっているかはわかりませんけどね。
そして、二次関数を解くためにはSQR関数が必要。
あるいは、ゲームによっては三角関数を使っているものもあるかもしれない。
そして、画面のXとYの座標は当然整数。
ときどき、当たり判定がバグっているゲームというのが話題になることがありますが、
あれっていうのはもしかしたら、小数と整数の比較の際の誤差の問題かも。そして、
実機だと正常に動いていたのにエミュだとおかしい、というゲームなどがあった場合、
それこそこのような小数の誤差の可能性は高いかも。
もちろん、倍精度を使えば誤差は少なくなりますが、リアルタイムの計算の場合、
倍精度だとやっぱり重くなるので、たいていは単精度を使うでしょうし。

    - No.11218 -   [コメント元:11216]     [リストへもどる ]
soft

11217DOSVAXJ3 JP240410 20行表示がおかしい? 投稿者:konno   2024/04/13(土) 23:28
  11212 番 めざら さんへのコメント

> それで、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が対応できていないのかしら?
やっぱり軟式さんに聞いてみようかな。

    - No.11217 -   [コメント元:11212]     [リストへもどる ]
pre

11216Re^5: SQRの単精度と倍精度の表示検証ソース 投稿者:konno   2024/04/13(土) 22:03
  11215 番 としき さんへのコメント    コメント数 1

> これ、実はN88のマニュアルに載っているサンプルです。
> そして、仕様上のこの実行結果は
> 
> 1.23456789  1.23457
> 
> となるべきなのだそうです。

NP2でやってみた結果です。

 1.23456789    1.23457

表示は全く同じですね。やっぱり表示と内部の数値がズレているのかなぁ。
他のエミュの結果は全て以下の数値でした。

 1.23456789    1.234568

98エミュの表示が上の数値で内部的には下の数値だとしたら、計算が合わないのも合点ですね。
でも何故こうなるのかがわからないので、とっても気になります。

> もしエミュでこうならないとしたら、それはどこかがおかしい。
> エミュの作者に調査を依頼してもいいかも。

表示は全く同じなので、おかしくないということですね。(違う!)

> N88BASICでは、言語仕様として、THEN節に空文を許します。
> つまり、THEN のときは、何もせずに、次の行に進むことになります。
> これ、#11169で触れているとおりです。

なるほど、つまり想定どうりということですね。

    - No.11216 -   [コメント元:11215]     [リストへもどる ]
pre

11215Re^4: SQRの単精度と倍精度の表示検証ソース 投稿者:としき   2024/04/13(土) 01:13
参照先:http://toshiki.la.coocan.jp/
  11209 番 としき さんへのコメント    コメント数 1

> とりあえず、試したいことリスト。

試してきました。

> #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で触れているとおりです。

    - No.11215 -   [コメント元:11209]     [リストへもどる ]
pre

11214Re: DOSVAXJ3 JP240410 更新 投稿者:konno   2024/04/11(木) 21:05
  11212 番 めざら さんへのコメント

> 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

# 伝説巨神 出でよん 発動編(壮絶な戦いになりそうな悪寒)

    - No.11214 -   [コメント元:11212]     [リストへもどる ]
pre

11213Re^6: SQRの単精度と倍精度の表示検証ソース 投稿者:konno   2024/04/11(木) 20:13
  11211 番 としき さんへのコメント

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

実行結果(数値は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

    - No.11213 -   [コメント元:11211]     [リストへもどる ]
pre

11212DOSVAXJ3 JP240410 更新 投稿者:めざら   2024/04/11(木) 05:56
参照先:http://mezala.la.coocan.jp/
   コメント数 2

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

build JP240410 (2024/4/10)
・J-3100モードが動作していなかったのを修正しました。
・Linux, macOS でビルドできなくなっていたのを修正しました。

……ということなんで,われわれにはあまり関係ないかな(^^;
    - No.11212 -             [リストへもどる ]
soft