#4 ソフトウェアの柔軟性

はじめに

　#3 の話と関連して、ソフトウェアの柔軟性について少し書いておきたいと思います。

ソフトウェアは柔軟か？

　ハードウェアよりも柔軟性が高いのは間違いないですが、では何でも柔軟に変えていいかというとそうでもない、というのが私の認識です。
　もっともユーザーに近いところにあるアプリケーションソフト（例えばゲームソフトだとか、ワープロソフトだとか、そういう後から追加して動かすソフトのことです。）は、そのアプリケーションソフトの責任元がある程度柔軟に修正することは可能でしょう。バグ修正だけではなく、昨日の追加や削除。ただ、販売時に「これができる」と売り文句にしていた機能を、販売・リリース後に削除してしまうのは、理由の如何にかかわらず、購入者は「不誠実」と感じるのではないでしょうか。そういう意味では、アプリケーションソフトでさえ、何でもかんでも柔軟に変えていいわけではないといえると思います。
　次によりシステムに近いミドルウェアや、OSや、BIOSのあたりはどうでしょうか？定義した通りに動かないものを、定義通りに戻すバグ修正は既存のPC等でも普通に行われています。一方で、その上で動作するアプリケーションとの取り決めであるプロトコルや API が、コロコロ変わってしまったらどうでしょう？仮にシステムアップデートに伴って API が変わってしまうと、そもそもその API を使っていたアプリケーションは、すべてまともに動作しなくなってしまいます。

ファームウェア

　MSX の BIOS は、昔の MSX の ROM に格納されているプログラムのことを指しますが、広義には、その BIOS が規定している API も含まれているわけです。BIOS を拡張して新規格を作る場合、その BIOS の API もしっかり吟味して、長期にわたって使えるように設計してからリリースしなければなりません。
　API がしっかり規定されているからこそ、その上で動作するアプリケーションを作れるわけです。これがリリース後にコロコロ変わってしまうようでは、それは私は「まだ規格として未完成」と認識します。
　ネット接続や I2Cデバイスの制御に関しては、まずは API をしっかり「長期にわたって使えるように設計」してから、できれば相応の技術力を持っている人たちによって粗探しをして、穴をふさいでしっかりしたものに仕上げて、そこから本リリース、そうしないとダメだと思っています。

アプリケーション

　同じことをハードとソフトのどちらでやった方が簡単か？と言われれば、ソフトでやる方が簡単でしょう。でも、それはアプリケーションソフトを組むのが簡単という意味ではありません。
　より高度なことをやるために、低レベルな制御は簡単に行える。だから、ソフトはより高度なことを実現するために、複雑な演算を行ったりするわけです。
　そして、その土台を支えるのがハードウェアによる支援であり、BIOS による支援であり、ミドルウェアによる支援なわけです。この土台となる部分が崩れて、アプリケーションを載せていた部分が変わってしまうと、アプリケーションはすぐにただのゴミデータに変化してしまいます。そんな環境に、アプリケーションを作りたいと思う人がいますか？と言われれば、一部のもの好きだけで、ほとんどの人が避けると思います。
　なので、システムを提供する側は、最低限、API やプロトコルというアプリケーションとの接続部分は、厳格に定めたうえでリリースする必要があり、ソフトウェアによる実装でありながら、実際はハードウェア的な厳密さを要求される緻密な作業だと思っています。

ネット接続

　MSXにおけるインターネット接続は、既に海外で作られており、MSX愛好家の中では使われている人も多いです。GR8NET や、SX-2 等にも内蔵されていますね。UNAPI 等という名前がついています。
　Nextor で有名な Konamiman氏が取りまとめておられます。

　これと API をそろえるだけで、既存のネット関連のツール類が色々使えるようになるわけですから、この UNAPI に特別何か問題がない限りは、これと互換性を持たせておいた方が、いろいろ好都合です。
　そのうえで、パスワードをどこにどのように保存するか？、リモートデスクトップのように画面を飛ばすにはどうしたらいいか？というのを共存できるようにしっかり作っておかないと、まだまだこれからも続く MSX ライフに役立つものになりません。

I2C等

　I2C, SPI, UART は、従来 MSX では、明確に API規定したものがあるかは知りませんが、膨大な数のデバイスがリリースされている中で、それらを初期の段階から幅広く使える、あるいはユーザー側で何かを頑張れば最初はサポートしていなかったデバイスをサポートできるようになるような仕組み、をしっかり考えていかないといけないと思います。

まとめ

　そういうわけで、MSXを末永く使っていきたいからこそ、こういう泥臭い部分をしっかり詰めていく必要があると思っていますし、十分に詰まっていない状態でリリースしてはいけないと思っています。そういうリリースは、カートリッジでやって実験するのはアリだと思いますが、本体に入れてしまうとその後の後継機も全部それを継承しなければいけなくなる。一度崩したら、MSXそのものを危うくする。私はそう思うのです。