(11226)
11226：
J31用BASICコンパイラの各エミュ対応沼
投稿者：
konno
2024/04/23(火) 01:23
コメント数 4
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は基本グラフィックモードだけなので、@でテキスト文字用に使い分けできます。
他にもあったかもですが、僅かの変更でコンパイラは通るようになり、動き始めました。
だが本当の地獄はこれから始まるのであった。
続く ・・・のか
(11226)
11234：
C000h VRAM領域と CDBL$() の問題
投稿者：
konno
2024/05/01(水) 17:48
11226 番 konno さんへのコメント コメント数 2
新しい 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日涇珣c １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日珣 ０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 などでメモリ拡張していると干渉すると思われるので要注意です。
ともかく、動くのが不思議な状態なので、このまま使うのがよろしいようです。
(11226)
11239：
C000h セグメントは間違い、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アドレスがバラバラですね。
(11226)
11240：
Re: 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 -
このTreeへ
コメント元:11234 へ
[リストへもどる]
soft
(11226)
11241：
Re^2: C000h VRAM領域と CDBL$() の問題
投稿者：
konno
2024/05/10(金) 01:02
11240 番 としき さんへのコメント コメント数 1
> (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 にもあります。機能的にも同じようです。
> 積極的には使われない関数であることは間違いありません。
私も使ったことが無いです。(^^;
- No.11241 -
このTreeへ
コメント元:11240 へ
[リストへもどる]
soft
(11226)
11242：
Re^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 -
このTreeへ
コメント元:11241 へ
[リストへもどる]
soft
(11226)
11243：
Re^4: C000h VRAM領域と CDBL$() の問題
投稿者：
konno
2024/05/11(土) 01:03
11242 番 としき さんへのコメント コメント数 1
> ところで、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!)
こんな感じ？ 結果はエラーになりました。(>_<)
- No.11243 -
このTreeへ
コメント元:11242 へ
[リストへもどる]
soft
(11226)
11244：
Re^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 -
このTreeへ
コメント元:11243 へ
[リストへもどる]
soft
(11226)
11245：
Re^6: A000h VRAM領域と CDBL$() の問題
投稿者：
konno
2024/05/12(日) 02:04
11244 番 としき さんへのコメント
> 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 ではこの関数使えないですね。
ということで、互換性を考えてこの案は没にします。(;_;) 時間を返せ～
(11226)
11246：
VTDOSは 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 -
このTreeへ
コメント元:11226 へ
[リストへもどる]
soft
(11226)
11247：
Re: VTDOSは 2バイト文字の表示に難有り
投稿者：
としき
2024/05/13(月) 22:24
参照先：http://toshiki.la.coocan.jp/
11246 番 konno さんへのコメント コメント数 1
なんか昔、１バイト幅の２バイト文字、というのが話題になったようなおぼろげな
記憶が。PC-98でしたっけ？
- No.11247 -
このTreeへ
コメント元:11246 へ
[リストへもどる]
soft
(11226)
11248：
Re^2: VTDOSは 2バイト文字の表示に難有り
投稿者：
めざら
2024/05/14(火) 16:47
参照先：http://mezala.la.coocan.jp/
11247 番 としき さんへのコメント コメント数 1
文字だとちょっと思い出せないんですが……，
確か罫線で半角の2バイト素片があったように思います。
大昔のPC8801のN88-BASIC のマニュアルなんか見たら，
1/4角文字コードなんて掲載があって凄く笑った。
実は，カセットテープの背ラベルとかに割と重宝してたの思い出して，
なんだか切ないような愛おしさまで感じた。（PC88専用ワープロで対応してた）
データベースが使えなくて印字で現物管理していた遠い昔の話です。
- No.11248 -
このTreeへ
コメント元:11247 へ
[リストへもどる]
soft
(11226)
11249：
Re^3: VTDOSは 2バイト文字の表示に難有り
投稿者：
konno
2024/05/14(火) 22:08
11248 番 めざら さんへのコメント
としきさん
> なんか昔、１バイト幅の２バイト文字、というのが話題になったようなおぼろげな
> 記憶が。PC-98でしたっけ？
PC98で 2バイト半角というのは聞いたことがあります。
めざらさん
> 大昔のPC8801のN88-BASIC のマニュアルなんか見たら，
> 1/4角文字コードなんて掲載があって凄く笑った。
そんなのもあるんですか、面白いですね。
> 実は，カセットテープの背ラベルとかに割と重宝してたの思い出して，
> なんだか切ないような愛おしさまで感じた。（PC88専用ワープロで対応してた）
> データベースが使えなくて印字で現物管理していた遠い昔の話です。
私も8ビットのパソピア７に漢字パック入れてドットプリンタで漢字印字とかやってたような。
5インチFDDも買っていたので凄い出費でしたが、全部捨ててしまったのは惜しいことしたかなぁ。
- No.11249 -
このTreeへ
コメント元:11248 へ
[リストへもどる]
soft
(11226)
11251：
VTDOSの vtd_err.log のサイズが超巨大になってた件
投稿者：
konno
2024/05/18(土) 23:57
11226 番 konno さんへのコメント コメント数 2
最近 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には エラーログ抑制オプションとかは無さそうだし、どうしたものか・・・・
- No.11251 -
このTreeへ
コメント元:11226 へ
[リストへもどる]
soft
(11226)
11252：
DOSVAXJ3の超巨大ファイルで C:の空きがゼロになった件
投稿者：
konno
2024/05/21(火) 00:15
11251 番 konno さんへのコメント
> ふと、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 しました。
その結果、３分の１くらい空きができました。（大丈夫なのか）
その後は問題なく動作しているようなので、まあいいか。(^^;
(11226)
11253：
エラーが出るなら元を絶ってしまえばいいじゃない
投稿者：
konno
2024/05/22(水) 00:14
11251 番 konno さんへのコメント
> 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 も一緒にしてしまいました。
でもまたもや常駐解除が出来ない。(>_<)
プログラムの仕組みがわかってないからでしょうね。(;_;)
(11226)
11361：
J3VT.COM VTDOS対応常駐プログラム
投稿者：
konno
2024/07/19(金) 22:45
11226 番 konno さんへのコメント
VTDOS で J31BASICコンパイラプログラムを問題なく動作させる常駐プログラム
J3VT.COM が出来ました。
以下、J3VT.DOC から
J31 BASIC BIOS VTDOS SUPPOT Ver0.03 by H/konno 2024-07-19
J3VT.COM VTDOS で J31BASICコンパイラプログラムを問題なく動作させる常駐プログラム
J31BASICコンパイラの実行ファイルを VTDOS で実行させると、大量のエラーログが発生します。
このプログラムは、エラーになる割り込みを横取りして問題なく実行させる常駐プログラムです。
・エラーログが発生する割り込み
INT10h ah,85h ディスプレイ割り込み、大量に発生する
INT10h ah,88h
INT10h ax,0012h
INT16h ah,f6h キーボード割り込み
INT16h ah,050h
INT16h ah,01ch
INT16h ah,020h
INT6Fh ATOK5割り込み
これらの割り込みを横取りしてなかったことにします。
INT6Fh は ax,00ffh でリターンさせて、J31コンパイラで常駐チェックに使っています。
公開プログラムには、J3VT が常駐していなければメッセージを出して終了させるルーチンを入れます。
・使い方
J3VT 実行するたびに常駐／解除します。BAT の中でJ31プログラムの前後に使います。
J3VT S Sオプションで常駐すると解除されない。VZ常駐前に常駐させるオプションです。
J3VT R Rオプションで Sオプションの常駐でも常駐解除します。
※ J31BASICコンパイラのプログラムでは、VRAM アドレスに A0000 ～ AFFFF を使用します。
VTDOS の設定で、TPAEXT=1 の場合、A0000 ～ AFFFF を空きメモリ領域とするのでメモリ競合が起こります。
競合は他のプログラムでも起こりうるので、必ず TPAEXT=0 又は無指定にしてください。
使用して何か問題が有った場合掲示板で報告いただければできる範囲で対応します。
・ソースについて
ソースの常駐／解除ルーチンは4本以上の複数のソースを参考にしたので公開しても問題ないかと。
問題が有れば削除します。
- No.11361 -
このTreeへ
コメント元:11226 へ
[リストへもどる]
soft