MSX追懐記

とにかく公私共々忙しいです…。

帰宅も遅いし、帰ってきてからプログラミングする意欲がわかないくらい疲れてる…。
そのため、なかなか「売り」側が完成しない。

久しぶりにがっつりロジック組んでるせいか、マシン語の暴走が多い…。
先日の上限オーバーにすぐ気づかなかったのも、普段から暴走させまくってたので、今回もそうだろうと考えてしまったのもあります。
暴走の理由の大半は、やはり「PUSH」と「POP」。
非常に便利な命令ですが、制約が厳しい。
制約を守らないと、すぐ暴走・リセットします。

主な制約は、
制約�@　PUSHで退避した分だけPOPで戻さなければいけない。
制約�A　PUSHした内容をCALL命令で飛んだ先でPOPしてはいけない。
まぁ、理屈が分かっていれば当然なんですけどね。

今回の「店屋」のように、条件が多く、ジャンプ命令を多用するロジックになると、どうしても飛んだ先で「POP」の回数が合わなくて暴走するという、今更な初心者的な事を繰り返しています…。

今回3Dロールプレイングゲーム作ってて気付いたんですが、私はマシン語でフロッピーディスクを制御したことがありませんでした。
おおー、驚愕の事実です。

そういえば、ファイルの読込などは全てBASICで行ってからマシン語コールしていたので、そう言われればそうかも。
ロールプレイングゲームなんかも、マップ変更する度に一度BASICに戻ってた気がします。

特にやり方が分からないとかの理由で、そうしていた訳ではありません。
それで困らなかったので、する必要がなかった、しようと思わなかった。というのが、正直なところです。

うーん、確かにマシン語からどうやってファイルを読み込むのか、知識として持っていない…。
今更そんな事に気付くとは…。
一度マシン語からディスク制御できるか試してみます。
上手くいったらLaboratoryのテーマに挙げようかな。

これが出来れば当時の自分を超えるのか！？

MSXの良さって何だろう？
私はMSXとWindowsでしかプログラミングした事がないので大層な回答は出来ません。
しかし、SCREEN2のような独特な不便さ（8ドット毎2色）や、SCREEN1.5のような柔軟さはとても好きです。
MSX2のSCREEN5のような、解像度は低いが完全なグラフィックモードだと、今となってはMSXらしさがないと思うのは私だけでしょうか？

今回、本当に久しぶりにMSXで3Dロールプレイングゲームを作っていて感じたのですが、速度やらメモリやら画像やらの制約だらけの中での製作が、とても楽しく感じます。
逆に目新しささえ感じます。
MSX2で、SCREEN5以降を使うとMSX1での制約からはかなり解放されますが、私的にはMSXで開発する意味がなくなるので使いません。
もし、MSX2の機能を使うとしても、コナミの「スペースマンボウ」のようにSCREEN1.5を使い続けると思います。

画像出典: 『GameFAQS』　スペースマンボウ　MSX2版
https://gamefaqs.gamespot.com/msx/917251-space-manbow/images?pid=917251&img=6

色（16色→512色中16色）とSPRITE（横4枚並んだら5枚目以上は消える→8枚）、メモリ（VRAMの空き容量をメモリ化）の制約が外れるだけでも大きいです。

なにより、SCREEN5以降を使いゲーム製作するくらいなら、MSXではなくWindowsでゲーム制作します。

前回のLaboratoryテーマ��25「SCREEN2のグラフィックをFONTデータにして扱いたい」で公開した「SC2toFNT」を利用すれば、「写真取り込みで簡単にアドベンチャーゲーム制作できるんじゃないかしら？」と、思ってしまいました。

昔はMSXに画像を取り込む手段がなかったので、思いつきもしませんでしたが、今ならフリーの写真画像サイトが大量にあり、それをMSXのSCREEN2に落とし込め、かつ、「SC2toFNT」で、FONT化できます。
（FONT化できないと、今回のメッセージウィンドウが利用できないので、それはそれで面倒…。）

早速、アドベンチャーゲームに使えそうな画像を、ちょっと探してみました。
まぁ、有名どころは「ゆんフリー写真素材集」。
フリーに使える写真が、大量です。
管理人様、素敵なサイトをありがとうございます。

風景写真を使って、無人島脱出アドベンチャーなんて、簡単そうですね。
Laboratoryテーマ��23「コマンドを選択肢メニューを開いて、選択したい」を公開したら、コマンド選択が可能になるので、一度簡単なアドベンチャーゲームのサンプルでも作ってみます。

現在、プログラム開発する際、マシン語のコードやBIOSを調べるのに使っているのは、Web上の物ばかりです。
以前書いた「MSX ポケットバンク」シリーズの「くじけちゃいけない！マシン語入門」はマシン語を思い出すには役立ったけど、いざプログラム実践してみると、載っていないコードのオンパレード。（2023年3月1日記事参照「マシン語習得へ」）
早々に諦め、詳しいマシン語マニュアルを探しました。
まず欲しいなと思い探したのが、私がMSXゲーム開発当時、最後に使っていたアスキー出版刊行の「MSXマシン語入門講座」。

画像出典: 『ヤフオク！』
https://page.auctions.yahoo.co.jp/jp/auction/o1070251487

ヤフオクにあったけど、やっぱりすごい高値で取引されてる…。
やむ無し、Web上の記事で我慢するか…。
そこで見つけたのが、下の2つの情報系サイト。

この2つのサイトで、すべて賄えてしまいました。
両サイトの管理人様、素晴らしいサイトを、ありがとうございます。

前回、MSXturboRと他のゲーム専用機との価格について書きましたが、私の記憶となんか微妙に時期のズレがあったので調べてみました。


うーん、やっぱりMSXturboRが話題になった1990年10月には、スーパーファミコンって発売されていなかったんだ…。
専門学校1年生の頃に、友人宅でPCエンジンCD-ROM²で遊んだ記憶しかないのはそういう事か…。
納得。
しかし、MSXturboR発売直後にスーパーファミコンなんか発売されたら、そりゃ勝てないよね…。

以前にも書きましたが、本業が忙しく、難易度の高いロジックを含むサブルーチンの開発が、なかなかにキツイ…。
簡単なロジックなら、サクサク作れるので苦ではありませんが、現在制作中の3Dダンジョンロールプレイングゲームでのドラクエ風メッセージ表示や、メニュー選択（特にこっち）はなかなかなロジックです。
昔にもロールプレイングゲームを作っていたので、それを改良して…。と、思っていたのが大間違い。
やはり、サブルーチンとして公開するのと、完全組み込み型のプログラムでは難易度が違います。

まず、見易くしなくてはいけない。
これは言わずもがな、コメント細かく入れたりします。
次に、ある程度纏めなくてはいけない。
これが結構大変、昔なら以前書いたようにバグがあれば適当にバグを改訂したロジックを他のアドレスに組んで、バグのある部分からそこへ飛ばして終わり。だったのですが、公開するとなるとあちこちに飛ばす訳にはいきません。
第一、見難くなります。
バグが見つかると、そのルーチン内で直して、飛び先全部見直して…と、非常に大変です。（ハンドアセンブルの宿命…。）
また、昔はちょっと異なるだけのロジックがあった時、大きなロジックでも別々に組み込んでいました。
当然、容量の無駄です。
そこも公開にあたり、共通部分をサブルーチン化するなどして纏めています。
うーん、これも地味に大変です…。

ですので、昔のロジックはほぼ使えないので、一から組んでる状態です。

当然1日で開発できる訳ないので、「MSX回顧録」などで時間潰して、その間に開発を進めている状態です。
睡眠時間削って…。
そろそろ毎日更新は難しいかな…。
まぁ、「MSX回顧録」の溜まってる記事がなくなったら必然的にそうなりますね…。
でも、自分の性格上、毎日更新止めてしまうと、更新間隔がどんどん広がりそうで怖い…。

昔制作したゲームの公開にあたり、「SOLGER」以降「.BIN」ファイルのBASICソースがない。
これまでに公開した分も、エンディングのクレジット、実名で載ってるので全部「J-J SOFT」に書き換えてから公開しています。
しかし、ソースがなければ書き換えられない。
と、なるとバイナリエディタか、アセンブラ（逆アセンブル）使うしかないね。
と言う訳で、適当に探しました。

便利なバイナリーエディタ見付けました！
「TINY BINFILE EDITOR for MSX」です。

直接フロッピーディスクの中身を書き換えるので、バックアップを取ってからいじるようにしましょう。
MSX-DOS上で動作するので、MSX-DOS必須です。
MSX-DOSのディスクに「TINY BINFILE EDITOR for MSX」をコピーして使用します。

おぉ、MSX-DOSなんて、いつ以来だろう…。
昔はノーブランドの2DDのフロッピーディスク、頻繁に壊れてたので、バイナリーエディタでインデックスいじって無理やり復旧させたりしてました。
懐かしい…。

以前、Laboratoryにて簡易BGM演奏ルーチンを公開しました。（2023年7月13日記事参照「Laboratoryテーマ��14「簡単にBGMを鳴らしたい」」）
「簡易」と付いているからには、「本格的なのはなかったの？」と言う質問もあると思います。

実はあったのです。

前回、「この機能はありません」と言った機能をすべて搭載した優れものでした。

【機能一覧】

※ タイ・スラーは付けずとも勝手に繋がるので機能なし。

なぜ使っていないか？
理由はいくつもあります。
例えば、ゲーム制作仲間の作曲担当が「MuSICA」使いだった事。
「MuSICA」以外にも優秀なツールが沢山出回っていた事など。
中でも決定的なのは、「私が作曲した曲は、これだけの機能が要らなかった。」事です。
機能を使わないのに、プログラムが非常に長いこのルーチンを使うメリットは何もなかったのです。
因みにBGMデータはMMLをコンパイルせず、MMLのまま演奏可能でしたので、BGMデータは多少短くて済みました。

結局日の目を見る事がなかったルーチン、また機会があれば公開するかも？（要らんか…。）

ハンドアセンブルの弱点として、飛び先指定の大変さを以前に書きました。（2023年6月1日記事参照「ハンドアセンブル」）
そこで、私はプログラム上で計算し易いように工夫をしています。
何をしているかと言うと、自作サンプルを見ていただければ一目瞭然。

1行のDATA文にコードを8バイトしか書かないようにしています。
1行が8バイト、16進数で&H08。
2行で16バイト、16進数で&H10。
要するにアドレスを数える際、2行毎に10、20、30…と数えてく訳です。（上に行く場合はF0、E0、D0…）
最後1行余ったら、8を加えます。
そして、右に1つ移動したら+1、左なら-1すると言うように数えます。


ただ、これでも問題があります。
1つのロジックを1ブロックとしていますが、1ブロックの最後の行、プログラム終了から次のブロックまでの間に「00」が入ります。

これは単純にプログラムを見易くするための工夫です。
しかし、言ってしまえば無駄です。
MSXのように容量が少なく、制約の多い機種ならなおさら。
しかし、これがあるおかげでロジック追加になった際、この空きを利用してジャンプ命令を入れられます。

うーん、でもアセンブラ使えばその辺の事は気にする必要はありません。（そもそもアドレス指定が不要。）
現状、プログラミングする際、ニーモニック（LD A,01、ADD 02等）を思い浮かべてそれをマシン語コード（3E,01、C6,02等）に変換しているので、アセンブラに移行するのはそれほど苦ではありません。
ただ、やはりアセンブラを起動して、マシン語プログラムをロードし、アセンブリしてから、BASICプログラムをロードして実行...までの手順が、手間に感じてしまう。
今なら全部BASICプログラムだけですからね。

うーん、今更やり方変えるのも面倒だしなぁ...。
まぁ、何か支障が出るまではこのままのスタイルでいきます。