z88dk-sccz80でビルドにコケるとなると、あとはz88dk-sdccでどうなるかを見るしか無いんだけど…もう一回試すしかないのかなあ。全然気が進まない。

ん－、printf()だとマズくなる系か（-O0でもコケる）。
とはいえ、putc()の類でも-O1でデバッグプリント突っ込むと却っておかしくなる現象あるし…安全策として-O0で行くしか無いかも。最適化しても32kB超えてるとなると、MSXのROM化しようなんて話も無理になるし（MEGAROM化ってのは流石にちょっと…）。

-O0
-rw-r--r-- 1 uaa users 47652 Apr 13 21:57 IchigoJam_BASIC
-O1
-rw-r--r-- 1 uaa users 36734 Apr 13 21:58 IchigoJam_BASIC
-O2
-rw-r--r-- 1 uaa users 36767 Apr 13 21:57 IchigoJam_BASIC

なんかz88dk-sccz80、最適化にバグ抱えてそうな感じ。ｰO1だとデバッグプリント入れたら逆に動かないんだけどなんなのこれ…

デバッグプリントを有効にすると何故動く…（その割にデバッグプリントの表示がおかしいんだけど…）

お仕事じゃないので最悪の場合は「ぶん投げる」というのが使えるので、まだ気が楽なんですけど…正直このシチュエーションは嫌ですな。端から見ると「ちゃんと動いているソースすら移植できないなんて、レベル低っpgr」な状況ですからね。

tokenizerは確かにz88dk-sccz80でビルドが通るように手を入れているけど、手を入れる前後で相違がないようかなり神経使ってるし今gcc上でテストしても問題無いからこの部分の可能性は高くない気がするんだけど。

うーん、blueMSXだとウォッチポイントは仕掛けられないんだろうか。実際は特定アドレスへの書き込みじゃなく、読みだしたタイミングでブレークかけてステップ実行で追いたいんだけど。

DOS向けに手軽にコード吐ける環境…流石にBruce Evans'は心許ないし、LSI-C試食版って訳にもいかんだろうから…OpenWATCOM辺りを持ち出さないといかんかなあ。gcc-ia16はどうなんだろう。

でもSyntax error in 20ということは行番号はちゃんと認識できてるし、エラー行の内容もちゃんと出ているから…tokenizer辺りの問題なのかなあ。

ん？
int16_t 行番号
int16_t 文字列長
char 文字列[文字列長] ※zero-terminate

の繰り返しは良いんだけど、行番号と文字列長はbigendianで良いのかな？

今更気づいたけどCP/M向けじゃなくMS-DOS上でIchigoJam BASIC動かした方が良かったんじゃ

まずはメモリ上に格納されたBASICのコードが適切かどうかの調査なんだろうか。それ以前に、テスト用のコードをいちいち打つのも面倒なので(file)I/O周りの整備も必要な気が。

ん－む、blueMSXにデバッガが入ってるならそれを使うのが一案か。
blueMSX Debugger http://www.msxblue.com/manual/debugger_c.htm

openMSXでも入ってるようだし、かなり強力な味方になってくれそう。
MSX雑談：openMSX debugger最強説 (2022/11/13) https://note.com/msx_z80_program/n/n0ddf074f8cfc

そーゆう存在が生まれる前に殺すか、生まれたら殺すか、生まれても殺すじゃないですか…

うーん、H8/300向けのgccでint=int16_tな環境に対応できないコードの燻り出しをしようとしたけど、特段何かが引っかかるというようなものは無いですねえ…

アウトロイドのマップとか出てるのか…（また何故にこんなものが…） http://psyzans.com/Testsite/OUTROYD/OUTROYD.html

アレな言い方になるけど、「豊かになる」「ワクワクする」という要素が無いものを単に並べて「どう？未来っぽいでしょ？」とかやられてもaudienceは引くだけですよ。

ん－、Debianでも/usr/sbin/sysctlはありますよ。rootじゃないと呼び出せないパスになっているようですが…

このアカウントは、notestockで公開設定になっていません。

CP/MじゃないじゃんMSX-DOSじゃんというツッコミはあるだろうけど、CP/M互換OSってことでそこは矛を収めてほしい。

IchigoJam BASIC、とりあえずCP/M上で動き出したけど…なんか動作妖しい。こっからデバッグというのが一番大変なんだよなあ。

とりあえず、「CP/M汎用なんだしとりあえず動作するかを見る上ではusleep()なんて無くてもﾖｼ!」というマインドでusleep()の呼び出しをさっくり削除して世に放ってみる。

安い、ただそれだけの理由で缶入りのレモンサワー(7%)ばかり飲んでる。たまにはビールとか飲みたい。

そういえばジン系が今年は流行りなのかなあ。なんか色々スーパーマーケットで見かけるんだけど。

バーボンのハイボールではないよん、という意思表示なんだろうか（とはいえバーボンウイスキーっていう以上、バーボンもウイスキーだよなあ）

Z80最強の資料は日高総裁の記したZ80マシン語秘伝の書、あれしかないと思う…

ていうか何故それがここに転がっているんだ…？
https://archive.org/details/Z80MachineLanguageTec

Z80に限った話をするなら、命令ごとの実行ステート数が出ているのでこれとCPUクロックから計算してコードを書けばそれなりの精度で待ちはできるんですよね。

そしてR800/eZ80だとステート数変わるし、ステート数の計算も面倒だからやりたくない、ただそれだけなんです… :-p

（MSXだったらVDPの1/60sec割り込みがあるので、これを使ったカウンタを利用して待たせちゃえば良いんですけど）

@redbrick 単にμsec単位の待ち…1μsec単位は流石に厳しいだろうからもうちょい粒度粗い単位（でもmsecは粗すぎ）で待てれば十分です。別にマルチスレッド処理をしている訳でもないので、本当にその時間だけ…ループ回して止めるのが手っ取り早いかなと。なにがしかのタイマーがあればそれ使うんですけどね…

Z80で汎用的に使えるusleep()を記述せよ、ってすごく無理ゲーな気がする。クロックが与えられればループを回して時間稼ぎ、ではあるんだろうけど…Z80だけでなくR800でもeZ80でもという話は出てくるだろうし。

まだCortex-M0で汎用的に(ry、の方が良いんじゃないかなあ…SysTick使える可能性が高いし（必ずしも使える訳じゃない、というのが痛いけど）。