Geistburg

ラスイチだそうです。


コレの話ね、念のため。厳密に言うと、本作を含むいくらかの売れ残りがあって、MATRAと提携関係にある現地サークルによって来る10/18（現地時間）にオランダのナイメーヘンで開かれるMSXフェアにて手売りされるらしいが、本稿を読んでる人には関係ない話だわな、フツー。っつーか、この御時世にそんなモノ目当てに渡欧するヤツがいたらホンモノの気狂いだ。とまれ、重ね重ね贖ってくださった奇特な皆様に多謝。

贖ってくださった酔狂な皆様に改めて多謝。

まったく同じ疑問を子どもの時分に抱いていたことを思い出させてもらったので、思い立ったが吉日、MSXのシステムROMを読んで調べてみた。結論から言うと、どうも合理的な理由は見当たらず、当該処理部分を書いた人の気分だったんじゃねーの、という気がしないでもない。

以下、なぜそう結論するか詳論に入る。最初に断っておくと、ざっくりと解析しただけたので、いろいろと見落としはあるかも知れない。

まず、大枠のBASICインタプリンタの動作から。OPENステートメントが検出されると、後続文字列が CAS: / LPT: / CRT: / GRP: のいずれかに一致するかが調べられ、一致した場合、対応するジャンプテーブルのアドレスが得られる。一致しない場合はファイル名と解釈され、然るべき処理系へ移行するが、本論とは関係ないので触れない。

さて、このジャンプテーブルにはOPENされたファイル番号に対して想定される処理……クローズ、シーケンシャルライト/リード、ランダムライト/リード等……に際してどのアドレスに実際の処理が存在するか、が列挙されている。GRPの場合、シーケンシャルライトのみに対応するので、テーブル上のアドレスのほとんどは Illegal function call エラー処理ルーチンへ向いている。つまり、たとえば INPUT #1 を試みると、この記述に従ってIllegal function callになる。

以降、OPENされたファイル番号（AS #1の#1）に対応する入出力時にこのジャンプテーブルが参照される。つまり PRINT #1 すると、後続する文字列＝書き出す文字列、1バイト毎にテーブル上のシーケンシャルライトとして示されているアドレスへのジャンプが起こる。その最終的な行き先は BIOS の GRPPRT(008Dh) になっている。

GRPPRT は、A レジスタに指定された文字コードに対応するフォントパターンを読み出し、ワークエリア GRPACX(0FCB7h) および GRPACY(0FCB9h) に保存されている最終参照座標……これがPRINT #1に先立ってPSET等をする直接の理由……に、そのとき設定されている BASIC のスクリーンモードに応じた方法でフォントパターンを描き出す、という、なかなか凝った造りのBIOSサブルーチンだ。

何が凝っているかというと、たとえば、MSX BASICのみを使っている限りにおいて実用価値がないとは思うが、フォントパターンは CGPNT(0F91Fh) に記録された先頭アドレスを元に読み出されるようになっていて、ここを変更すればデフォルト以外のフォントも使える。しかも、CGPNTはちゃんと3バイトあってスロット指定にまで対応している。

仕掛けとしては、まぁそんなところだ。以下、何故この実装に合理的な理由がない、と判じたのかに触れていく。