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

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


続く　・・・のか

新しい 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 などでメモリ拡張していると干渉すると思われるので要注意です。

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

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

> 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 ではこの関数使えないですね。
ということで、互換性を考えてこの案は没にします。(;_;) 時間を返せ〜

> ふと、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  も一緒にしてしまいました。
でもまたもや常駐解除が出来ない。(>_<)
プログラムの仕組みがわかってないからでしょうね。(;_;)