MSX用のCP/Mを昔持っていたような気がするかすかな記憶

確実に覚えているのはSHARP X1系のパソコンとそれようのCP/Mを持っていました。
機種名は覚えていませんが、X1 turboⅢか、X1 turbo Z Ⅲか、そんな感じの名前でした。
もうすでにX1の時代は終わっていて、中古で安く売っている時期に買いました。
ほとんど使うことはなく電源を入れたこともあまりありませんでした。
思い出せないのは、MSX用のCP/Mを持っていたような持っていなかったような。
検索すればMSX用のCP/M自体は存在しますが、検索しても私が当時日本で普通に入手できたような情報が出て来ないので多分、そんなものは持っていなかったのだとは思います。
でも、なぜ持っていたような記憶がかすかにあるのかが不思議なんです。
もし持っていたとすればCP/M単体で売られていたのではなくて、何かのソフト(多分コンパイラ系)がCP/Mを同梱して売っていてそのCP/Mの上で動いていたような気がします。
可能性としてはTurbo Pascalぐらいしか思いつきませんがTurbo Pascalは買った記憶がないし使った記憶もなくどんなものか想像もつかないぐらいなので絶対違いそう。
そしてTurbo PascalのMSX版がCP/M同梱だった記述は検索しても見つかりません。
では、MSX用のCP/Mを持っていたような気がするというかすかな記憶はどこから来たのでしょうか。
果たして、CP/Mを同梱したMSX用の市販ソフトは存在したのでしょうか?

他に思い出せないことは、
Small-CというC言語コンパイラと、Small-MacというSmall-Cでも使えるアセンブラとリンカを確かに買った記憶があります。
しかし、いったいどのパソコン向けに売られていた思い出せません。
CP/M用として5インチフロッピーディスクで売られていたのでしょうか?
今、検索してみてもSmall-Cの当時のことがほとんど出てこなくて良く分かりません。
買った記憶が本当に正しいのか不安になってきました。

BDS Cの純正ライブラリのみでMSXプログラム

BDS Cの純正ライブラリのみのMSXプログラムで可能なことを考えてみたいと思います。
純正ライブラリで設定を変えて再アセンブルもしくは再コンパイルしていない場合は、OSはMSX-DOSに限定されます。
MSXでCP/Mがもし動けばCP/Mでもいいです。
一応MSX2用のCP/Mはあるらしいですがほとんどの人はMSX-DOSを使ってCP/Mは使っていないし欠点はあっても使う利点は特にないかと思います。
機種固有機能を使っていないCP/Mシステムコールを使ったプログラムはMSX-DOSでもたいがい動きます。
BDS Cには、peek()、poke()、imp()、outp()、bdos()、kbhit()という便利な関数がデフォルトであるので別途、特殊なライブラリを用意しなくてもMSXを含む各種機種固有の機能をある程度使えます。
また、MSX-DOSはエスケープシーケンスが使えるので、printf()やputchar()などのC言語標準関数を使って文字カーソルの移動、画面の文字クリア、文字カーソルの形状指定、文字カーソルの表示のオン・オフなどができます。
例えば、エスケープシーケンスを使ったMSX-BASICのLOCATEに相当する指定位置への文字カーソルの移動は次のようになります。


void locate(x,y)
int x;
int y;
{
  printf("%cY%c%c",0x1b,32+y,32+x);
}
void main()
{
  locate(5,10);   /* X座標5、Y座標10の位置に文字カーソルを移動 */
}

peek()はMSX-BASICのPEEKに相当し、pokeはMSX-BASICのPOKEに相当し、番地を指定したメモリアクセスの読み書きができます。
MSXにはシステムワークエリアというものがあり、そこをpeek()で読むことでMSXの状態を得たり、そこにpoke()で書き込むことでMSXを操作することができます。
例えば、文字のカーソル移動はエスケープシーケンスを使わなくても、ワークエリアを書き換えることでも実現できます。
例えば、MSX-BASICのLOCATEに相当することをワークエリアの書き換えですると以下のようになります。
void locate(x,y)
int x;
int y;
{
poke(0xf3dc,y);
poke(0xf3dd,x);
}
void main()
{
locate(5,10); /* X座標5、Y座標10の位置に文字カーソルを移動 */
}
inp()は、MSX-BASICのIMPに相当しI/Oポートの読み込みができます。
outp()は、MSX-BASICのOUTに相当しI/Oポートの書き込みができます。
これらの関数でジョイスティックの入力を調べたりVDPをアクセスしてグラフィックを扱うこともできるかも知れません。
ただ、それをするのは難しいし、用途によっては速度が遅くなり現実的ではありません。
Z80アセンブリ言語で書かれたライブラリを使うほうが現実的でしょう。

kbhit()はキーボードのキーが押されているかどうかを調べる関数です。
bdos()は元々はCP/Mのシステムコールを呼ぶ関数でMSX-DOSのシステムコールにも使えます。
kbhit()でキーボードのキーが押されていると判断された時にbdos()でMSX-DOSのシステムコールの8番などの一文字入力機能を呼び出せば、多分、MSX-BASICのINKEY$に相当する入力待ちなしの位置文字入力機能を実現できると思います。
もうひとつ、INKEY$相当の機能を実現できそうな方法は、システムワークエリアのNEWKEY(FBE5H)を、peek()関数で読んでキーボードマトリクスを得て自作関数を作ることです。
C言語が、INKEY$に相当する標準関数を持っていないのは痛いところです。

BDS Cの標準ライブラリのみでMSXのプログラムを作ることを考えてみましたが、
でもまあ私はZ80アセンブリ言語でMSXライブラリを自作します。

BDS Cでの開発の準備中

BDS Cでの開発をしようとしていますが、今は足りない開発ツールの自作で止まっているところです。
他にはMSXライブラリの作成もしている途中です。
MSX-DOS上だけで動けばよいとは思っていなくてMSX-BASICのOS上(フロッピーディスクまたはカセットテープ)でも動くようにしたいと考えています。
できればROMカートリッジも。
まだROMカートリッジは試したこともないので実現可能かどうかはなんともいえません。
BASICのOS上では現在自作のBDS C用MSXライブラリが不足していて(MSX-DOSで動作するがBASIC-OSでは動作しない関数が多々ある)まともに使えませんが機能を限定すれば自作プログラムをBASIC-OS上で起動させることはできるようになりました。
大昔に作っていたMSX-BASIC-OS向けのBDS Cライブラリは消失しているので作り直しです。

MSXのROMカートリッジ向けソフトを作るには?

MSXエミュレーターでのROMカートリッジ用ソフトをBDS Cで作れないかなとふと思いました。
ROMカートリッジ向けソフトの利点は、C-BIOSというフリーのMSX互換BIOSに唯一対応することと、ROMカートリッジ用のソフトはディスクBASIC-OS上でマシン語(C言語からのコンパイル結果含む)のソフトを作るより最大プログラムサイズが大きく使えるメモリも多くなり、
さらに、MSX-DOSというOSを添付して配布したりユーザーに用意させる必要がなく、
フロッピーディスクもカセットテープもなくても動くと利点が大きいです。
欠点はMSX-DOSのほうがメモリマップが全部RAMでROMとRAMの区別がない分、メモリを有効に使えることと、MSX-DOSのシステムコールが使えないかも知れない。
(フロッピーディスクが使える状態ならMSX-DOSのシステムコールは使えるのでしょうか?)
C-BIOSはBASICインタプリタはなくフロッピーディスクにもカセットテープにも対応していません。
ROMカートリッジ向けソフトの問題は個人で作った例があまりないというか聞いたこともないような感じで作り方があまり知られていないことです。
どうやったらROMカートリッジ向けソフトが作れるのでしょうか。
MSXテクニカルハンドブックの記述及び簡単な解析をした結果では
先頭に0x41,0x42(アスキーコードで “AB”の2バイト)を書き、
次の2バイトに必要なら初期化ルーチンアドレス、BASIC-OSに戻らず無限ループするソフトならここでプログラム先頭に飛んでもよく、必要ないなら0x00,0x00で埋める。
残り12バイトを 0 で埋めて(0x41,0x42,初期化ルーチンアドレス2バイトを含めて16バイト)
17バイト目(メモリアドレス0x10)からプログラムが始まり、メガROM(64KB)でない普通のROMサイズは32KBで、64KBのRAMではメモリアドレス0x8000 から0xFFFFがRAMになり、
BIOSの呼び足しはMSX-DOSから呼び出す方法と同じスロット切り替えをすると思っていましたが、やってみたらできなくて
よく考えたら、スロット切り替えの1CHなどのBIOSの番地はROMカートリッジだと自分のプログラム部分でそこをCALLしてもBIOSが呼ばれるわけがないです。
かといって、MSX-DOSがやっているようにBIOSを呼べるようなルーチンをどこかに置くということは難しいです。
諦めようと思います。

BDS Cで、MSXのBASICのOSで動くプログラムを作る

BASICは一般にはOS扱いされていませんがここではOSと考えることにして話をします。
BDS CはデフォルトではCP/Mまたはその互換であるMSX-DOS、MSX-DOS2の上で動くプログラムを生成します。
でも実際はROM化したり、MSX-DOS(2)のないMSXで動くプログラムも作れます。
私が昔作ったMSXのプログラムの一部が最近出てきて、そのうちのブロック崩しゲームは、BASICのOSの上で動くものもBDS Cで作っていました。
MSX-DOSで動くものしか作った記憶がなく、そんなことをしたなんて忘れていました。
MSXではBASICのOSで動くソフトのメモリのユーザーエリアは20000バイトほどしかありません。
MSX-DOSを使うと、メモリのユーザーエリアがなんと50000バイトぐらいに増えます。
大きなプログラムを作るとなるとMSX-DOS(2)でないと厳しいです。
MSX-DOSではBASICが入っているROMをRAMに割り当てているので使えるメモリ容量が倍以上に増えるのです。
言語としてのBASICを使うならRAMを半分食いつぶしてでもBASIC-ROMをメモリ空間に入れる必要がありますがC言語を使う場合は要りません。
だったら、MSX-DOSで動くソフトを作るべきとなりそうですが、あまりメモリを使わずMSX-DOSの機能も使わないソフトはMSX-DOSを使わないほうがよいかも知れません。
なぜかというと、今のエミュレーターでMSXのプログラムを動かす時代では、MSX-DOSを自作ソフトに添付して配布しないと使う側は動かせない場合があります。
まあ配布すればいいんでしょうがMSX-DOSの著作権がどうなっているのかという懸念が少しあります。
(時代が時代ですのでもう価値がないと思われていて訴えられることは有り得なさそうですが。)
そして、MSX-DOSを使わないほうが若干ですが起動時間が速いかも知れません。
で、どうすればBDS CでBASICのOSで動くソフトを作れるのでしょうか。
調べているところですがすごく面倒くさいです。
まずランタイムライブラリのC.CCC(ソースはwork/CCC.ASMで、source/CCC.ASMではない)をソースを変更して再アセンブルしなくてはいけません。
CC.COM に -m オプションを与えて、
CLINK.COMに、-l -e -t オプションを与えないといけないみたいです。
それらのオプションは数値を指定しないといけないものもあり、どうすればいいのか考えないといけません。
過去の私をこれをやり遂げたことがあるのですが、全然記憶にはありません。
まさか、こんなことをやったことがあるなんてという感じでびっくりしています。
今やろうしてできるかなあ。めんどくさいなあ。

MSXの自作ソースが一部見つかりましたが

はるか昔の過去に自作したMSXのソースの一部が出てきて、これは大いにMSX開発につながることなんですが、
それでも最新ではないし一部ということで、昔できていたことができず残念です。
もう一回作ればいいというわけにはいきません。
作り方がわからないんです。
もう一度作り方を調べればいいような気もしますが、調べたんですがやはり分からない。
もっと時間をかければできるかも知れませんが労力対効果を考えなくてはいません。
また日本国外に住んでいるためMSXの情報を得るのはほぼインターネットのみになり不利です。
今見つかる情報はBASICがほとんどです。
BASICを使わない開発方法(C言語+アセンブラまたは、アセンブラのみ)をしていた私には今見つけられる情報のほとんどは無意味です。
過去の私は単純なソフトしか作ってなかったわりには、時間をかけて得たMSXのノウハウを持っていたようです。
あれから数十年経った今、プログラミング技術はかなり向上しているとは思いますが、MSXに限っては初心者レベルに戻っています。
C言語は昔よりできるし、Z80アセンブラも今でも覚えているようですがMSX固有のことが今は昔ほど分かりません。
ソースを無くしたのが問題でした。
ソースを無くしてしまえば、今まで積み重ねたノウハウも一瞬で失ってしまうということでしょう。
MSXは市場から消えたとかなり昔に判断したの開発資料を残す努力はせずに長い間気にもしていませんでしたが。

BDS C Ver 1.60 の文字列に半角カタカナを通すには

BDS Cは昔から「デフォルト」では文字列に8ビット文字を使えません。
(8ビット目、つまりMSBがマスクされてかならず0になるという意味。)
BDS C Ver 1.50aと、α-C Ver 1.51にはバイナリを書き換えて対応させる方法が知られていましたが、現在無料公開されているVer 1.60には出回っている情報がありませんでした。
そこでBDS C Ver 1.60で半角カタカナを使えるようにする方法を自力で解析しました。(需要がないのは百も承知ですが)
全角も通るだろうけどSJISだと16進の5Cを含む文字は無理かも。(例えば「表」の字とか)
BDS C Ver 1.60 の文字列に半角カタカナを通すには、CC.COMをバイナリエディタで(0から数えて)29D4番目の7FをFFに変更します。
あるいは、(0から数えて)29D3番目からの2バイト、E6,7F を、00,00に書き換えてもいいと思います。(試してない)
BDS C Ver 1.60はソースも公開してあるのでソースを変更してアセンブルすることも可能です。
ソースからアセンブルには、CCC.ASMの1988行の「stripp: ani 7fh」の7fhの部分を0ffh に変更する。
つまり、「stripp: ani 0ffh」に変更する。
(ani 0ffhは、演算結果が変わらないコードなので、「ani 7fh」の部分を削除してもいいと思います。試していませんが)
気をつけないといけないのは、0ffhでなく、ffhに変更するとコンパイルできないバイナリを出力してしまう。
(先頭に0がついてないと数値ではなく番地を示すラベルと判断される。)
あとは、必須ではないかも知れないが、CC.ASMの17行の「zsystem equ true」を「zsystem equ false」に変更する。
これを変更しない場合はZSYSTEM版のBDS Cを出力するらしいですが、ZSYSTEM版って何?
CC.COMをアセンブルする方法は、ソース付属のCP/M上で動くアセンブラのLASM.COMで「lasm cc.ccz c:」とコンパイルするとCC.HEXを出力する。
CC.HEXはインテルヘキサファイルなのでなんらかの方法でバイナリに変換する。
変換ソフトによっては先頭に256バイト(16進で100)のゴミができるので、それを削除する必要があるかも知れない。
CP/M及びMSX-DOSのソフトは、16進で100番地からプログラムが始まると決まっています。
なぜかは知りませんが、ソースからアセンブルしたCC.COMのバイナリと、バイナリ公開されているCC.COMはバイナリが一致しません。
どちらも動作しているのでどちらでもいいとは思いますが。
古いバージョンも含めて、まとめると次のようになります。
“7bit-String to 8bit-String” patch for BDS C
BDS C v1.60 “CC.COM” binary file 29D4H, 7F to FF.
BDS C v1.50a “CC.COM” binary file 26C7H(memory 27C7H), 7F to FF.
α-C(alpha-C) v1.51 “CC.COM” binary file 26F1H(memory 27F1H), 7F to FF.

source file patch.
(if choose binary patch then no need source file patch)
BDS C v1.60 make from source file
“CCC.ASM” 1988 line “stripp: ani 7fh” to “stripp: ani ffh” or “stripp:”
“CC.ASM” 17 line “zsystem equ true” to “zsystem equ false”
assemble on CP/M “lasm cc.ccz c:”

過去のMSXの自作ソフトの一部を入手できました。

過去にTAKERUでも販売されていた「MSXフリーソフトウェア100選」に収録されていた自作ソフトを入手できました。
自作ソフトだけではなく「MSXフリーソフトウェア100選」自体を入手できました。
私が作っていたソフトは四つ収録されていますがひとつはZ80逆アセンブラで、他の三つはくだらない底辺レベルのゲームです。
この四つは全て、「BDS C」というC言語コンパイラで作っています。
その自作ゲームのうち、ひとつはソースも公開していたようで(覚えてなかった)ソースまで手に入れられてかなりうれしいです。
ソースの入手は想定外でした。ただ、古いバージョンのソースなのが残念です。
1991年に作ったようです。(覚えてなかった)
そのゲーム三つは、底辺レベルだったのですが、
MSXプログラミングでは、BASICかマシン語またはその両方の組み合わせでゲームを作るのが主流の方法で、C言語で作られた個人作成のゲームは珍しく、C言語でも作れるということも示す意味はあったと思います。
私はMSXの末期からMSXユーザーになりました。
1991年は日本の大手メーカー発売としてMSXの最後の機種が発売された年で、こんな時代になってからMSXに参戦してプログラムを作っていたというのは先見性がなかったのかも知れません。
ただし、BASICではなくC言語を中心とした開発をしていたのでプログラミングの知識の多くは無駄にはなりませんでた。
この部分は先見性があったと思います。
その後、オールアセンブリ言語でも作ってみたいと思って、一作だけアセンブリ言語のみで作った簡単なシューティングゲームを作りました。
完成したころにはMSXがほぼ終わっている状態だったので作っても意味はなく、作成で得たプログラミング技術もほぼ全てが無駄になるような感じでした。
残念なことにソースファイルどころか実行ファイルもパソコン通信の終焉と同時になくしてしまって二度と手に入れることはできないでしょう。
かといって、同等の物をいちから作る気力はもうありません。

自分が昔作ったソース見たんですが、ひどいソースでお恥ずかしいです。
ループの使い方を知らないころに作ったようで、関数呼んでループさせていてこれだとしばらくするとスタックオーバーフローで暴走すると思います。
一応、ソースがあったものはソースは直しました。
動作確認はこれからです。
ソースがないものは、どのように作っていたかは覚えてないのでわかりません。