当時の状況を記そう。
当時、ホビープログラマが最初に使う言語は BASIC だった。
8bit 機では、OS は存在して無くて、起動すると ROM に入っている BASIC が動き始める、というのが普通だった。
シャープ製マシンは ROM に入ってなかったけど、本体を買うと BASIC が付属している点は変わらない。
16bit でも BASIC が付属しているのは当たり前だった。
PC98 は、PC88 の BASIC 互換マシンとして作られた。当然 ROM BASIC もあるし、DISK BASIC 、DOS BASIC もある。
X68k にも、X-BASIC が付属した。
今となっては、当時の BASIC の環境は忘れられかけている。
文法は、今でも残っているね。BASIC という言語自体は残っている。
でも、「環境」としては、今と全然違う。
BASIC は OS と、エディタと、デバッガと、実行環境が混然一体となったものだった。
ソースコードをエディットしている最中に、命令の動作詳細を知りたくなったとする。
その時は、その場で命令を実行してみることができる。
実行して、動作を確認して、納得したらソースコードに組み込む。
プログラムが出来たら全体を実行してみるが、途中でエラーで止まってしまったとしよう。
原因調査のため、止まったあたりのソースコードを表示する。
どうも、そこで使われている変数の内容がおかしい気がする。
その場で、変数の内容を表示する命令を打ち込むと、命令が実行され、変数の内容が表示される。
こうやってデバッグを進めることができる。
この環境、プログラムに不慣れな初心者にとって、めちゃくちゃ使いやすかった。
ただ、非常に大きな欠点があって、プログラムの実行速度が遅かった。
いつでもコマンドを実行できる、というのは、コマンドを解釈して実行する機構があるためだ。
そして、プログラムはこれを連続して動かしている。文法解釈をいちいち行いながら動くので、遅いのだ。
一応、BASIC コンパイラというものもあった。
先に書いたように、BASIC はエディタとデバッガと実行環境を総合したような環境で、この環境自体が大きい。
完成したプログラムを BASIC コンパイラに通すと、OS から起動できる実行形式のプログラムを生成してくれる。
この際、速度も改善する。
でも、そもそも BASIC って、初心者にはわかりやすい反面、コンパイラで速度を上げたりしにくい構造だったのね。
PC98 の DOS BASIC の場合、コンパイラを通しても速度は３倍程度にしかならなかった。
X68k の X-BASIC は、当時の他のコンピューターの BASIC とは、文法面から少し異なっていた。
とはいえ、BASIC ではある。先に書いたような、エディタとデバッガと実行環境が統合されたような、初心者でも使いやすい環境は実現されていた。
この、「少し異なる文法」がミソだ。
当時は、パソコンユーザーにはまだ C言語はあまり普及していない。
しかし、X-BASIC の文法は、C言語に非常に近いものだったのだ。
そして、SHARP 純正の C 言語が発売される。
このセットには、X-BASIC のプログラムを C に変換するプログラムが含まれていた。
もちろん、Cコンパイルすれば、機械語の実行ファイルになる。
これは素晴らしい「BASIC コンパイラ」だった。
先に、BASIC は文法を解釈しながら実行する、と書いた。
それに対し、C 言語は、文法解釈を先に行い、結果として「CPU が直接理解できる」機械語プログラムのファイルを生成する。（この作業をコンパイルと呼ぶ）
結果として、プログラムの実行時には、余計な動作が一切入らない。
このため、非常に高速に動くのだ。
PC98 の BASIC コンパイラのような３倍程度ではなかった。
ちゃんと速度を測ったことは無いけど、超高速。機械語として動作するからね。
初心者が気軽にプログラムを作り始め、最終的に十分な速度で動作するプログラムを作れたんだ。
これは、他のパソコンにはない環境だった。
さて、実行速度が速ければプログラムが組めるようになるか、というと、そんなことは無い。
ゲームを作りたいと思ったら、キャラクターを表示しないといけない。
PC98 の BASIC でも、画面に描いたキャラクターを動かすくらいのことはできた。
でも、全てをグラフィックとして扱う必要があった。
キャラクターを描いて、消して、少しずれたところにまた描いて、の繰り返しだ。これで動いて見える。
ただ、「消して」のところで、背景も消える。
「描いて」のところでも、キャラクターを含む矩形全体を描くので、キャラクターの周囲が四角く消えてしまう。
背景があるような華やかなゲームを作るのは、BASIC では事実上無理だった。
じゃぁ、一念発起して機械語を勉強してみようか…とすると、急に高い壁が立ちはだかる。
詳細を書くと長くなるので、過去に書いた記事を紹介しておこう。
BASIC でキャラクターを扱うときは、このことを気にしないでいいようになっている。
でも、機械語だと知らないとダメだ。
適当にグラフィックを扱うと、周囲のドットを破壊してしまうので、それを解消するプログラムが必要だった。
とにかく、ゲームを作りたくてキャラクタを動かそうとすると、それだけでも大変だった。
これ、ゲームに限った話ではない。
ちょっとグラフィックを扱うツールを作ろうと思ったら、マウスカーソルとか、選択範囲とかでグラフィック表示が必要だ。
しかし、処理対象のグラフィックを壊すわけにはいかない。
一旦グラフィックをメモリに退避したり、いろいろ複雑なプログラムを作る必要がある。
もっというと、これは PC98 に限った事情だが、画面を構成する情報を「設定」出来ても「読出し」できないものがあった。
画面を構成する、4096色中 16色のパレットは、設定専用で読み出せないのだ。
ということは、「現在表示している画面を加工して、セーブ」という操作はできない。
グラフィックを加工するフィルタを作りたければ、それだけで、ファイルの読み込み、グラフィック圧縮フォーマットの展開、画像加工、グラフィックの圧縮、ファイルの書き出し、までをセットで作る必要がある。
初心者が何かしようと思っても、余りにも壁が高い。
それが当時の、普通のパソコン環境だった。
X68k には、こうした制約がなかった。
キャラクターを動かしたいなら、スプライトを使えば良い。
動かす際に、以前描いたものを消す、というような操作は必要ないし、背景を壊す心配もない。
周囲だって、適切に「透明」として背景を見せてくれる。
グラフィックを扱いたいなら、１ドットは１ワード(16bit) に対応していた。
１ドットを構成するメモリが、他のドットと共有されることは無い。
さらに、グラフィックを複数重ね合わせることもできたので、グラフィックの範囲指定などで枠を表示しても、グラフィックを壊さない。
こちらも詳細は過去の記事に譲ろう。
とにかく画面関係が豊富で、扱う際に何かに気をつけないといけない、というような制約が少なかった。
（全くないとは言わない）
先に書いたように、グラフィックを加工するプログラムを作りたい、とする。
画像の読み込みと書き出しは、すでに存在しているプログラムに任せることができた。
操作パレットや範囲指定の枠表示などは、表示中のグラフィックに影響を与えないように描けた。
グラフィックの操作は、１ドット単位でメモリの読み書きを行えばよいだけ。
あとは、処理の中心となる「加工」部分をどう作るか。
このアイディアだけに集中すればよい。
初心者でも、自分が作りたいプログラムを作りやすい環境だったんだ。
もう一つ、OPM ドライバの話を書いておこう。これは大発明だったと思う。
また BASIC の話に戻ってしまうのだが、日本のパソコンのBASICは、音楽演奏機能が充実していた。
これ不思議で、海外のパソコンには見られないんだよね。過去に調べたことがある。
ともかく、日本ではパソコンの楽しみの一つに音楽演奏があり、パソコン用の、文字の組み合わせで楽譜を表現する「MML」と呼ばれる記法が出来上がっていた。
当時の MML を使った演奏は、BASIC の中に組み込まれていたのだけど、演奏中は他の動作が止まるのが普通だった。
非力な CPU では、そうしないと演奏のテンポとかを保証できなかったからだろう。
ところが、X68k の MML 機能はそうではなかったんだ。
演奏を開始すると、演奏を続けたままプログラムの動作を続行してしまう。
これにより、ゲームに BGM が付けられた。
最初は BASIC の中だけの機能だったのだけど、すぐに音楽機能は「OPM ドライバ」という名前で切り離され、OS 標準機能の一部になった。
これにより、「全ての」プログラムが、気軽に BGM をつけられるようになったんだ。
これもまた、素人がゲームを作る上では強力な、超強力な機能だった。
他の PC でゲームを作ろうと思ったら、速度を確保することが難しく、キャラクターを表示することが難しく、BGM をつけることも難しい。
この問題が、最初から解決していたのが X68k という環境だ。
だから、素人でも作品を作れたし発表できた。
ゲームに限らず、自分が興味を持つ分野だけを、集中して取り組めた。
それ以外の部分は、すでにあるものを使えばいい。
「大根おろしPRO68k」とか、当時有名な PDS だった。
今でもインパクトで覚えている人が多いようだ。
内容見ると、超くだらない。白い四角をマウスで動かして、画面中央の「おろし金」にこすりつけると、四角が小さくなって白い点々が増える。ただそれだけ。
でも、おろし金のギザギザと、白い点々と、四角い「大根」はちゃんと重ね合わせ処理が行われているのね。
X68k だから別画面に描いているだけだと思う。でも、PC98 でこれを作ろうと思ったら大変な処理になる。
こうした「思いつきの冗談」みたいなものでも、すぐにプログラムが組めてしまう。
そして、もう一つ。重要なピースがある。
X68k は、市販ソフトがほとんどなかった、ということだ。
パソコンを使って何かをしようと思ったら、普通はそれができるソフトを探すだろう。
でも、X68k には市販ソフトがなかった。探すことすらできなかった。
じゃぁ、自分で作るしかない。
仕方がないからやるだけだし、自分用だから多少出来が悪くても構わない。
先ほど書いたように、BASIC でもそれなりのものが作れてしまうのが、X68k だった。
とにかくプログラムを作ってみて、目的を達成する。
そして、自分が困っているのだから、こんなプログラムでも使う人がいるかもしれない、と、当時流行し始めたパソコン通信にアップロードする。
もしくは、雑誌 Oh! X に投稿する。ディスクマガジン電脳倶楽部に投稿する。
X68k にはとにかくソフトがなかった。多少出来が悪くても、動くだけでありがたい。
電脳倶楽部の編集長も、「動いているプログラムは良いプログラム」と言っていた。
多少出来が悪くたって、ないよりはある方がずっといいのだ。
そうか。出来が悪くても、ある方が良いのか。
これが、X68k の当時のユーザーの認識だったと思う。
だから、自分が何か作ったら、出来が悪くても、恥ずかしげもなく公表する。
そういうソフトを見た人は、そのレベルでいいんだ、と、また出来の悪いソフトでも公表する。
この、とにかく公表するし、みんながそれをありがたがる、という構図は、現代でもなかなか見られない。
これが、良いスパイラルを産む。
公表して、みんなにありがたがられた人は、また何か作ったら公表しようと思う。
次の作品へのモチベーションになる。
そうして作品を作り続ける。作り続けるうちに、技術も上がり、もっと良いものを作れるようになる。
X68k のソフトウェア環境は、こうしてユーザーたち自身の手で作られていった。
これが、「無いものは作る」と呼ばれる文化の正体だ。
決して、技術力の高い人間が、なんでも作ってきた、というような文化ではない。
仕方がないから出来の悪いものでも作り、公開し、泥臭く環境を整えていった文化だ。
結果として、すごい人を育てる良い環境になった。
でも、最初からすごかったわけではない。
最後に、今の初心者が X68kZ を使ったら、同じように上達できるか？ ということについて。
当時「使いやすかった」と言われる環境だから、今から自分も何か作ってみたい、という人は少なからずいるようだ。
しかし、ここまで読んでくれた人には、答が分かると思う。
「プログラムを作りやすい」というのは、あくまでも当時の他のパソコンに比較しての話。
今なら、何も古いマシンのエミュレータを使う必要はない。
Unity とかを始めて見るのがいいだろう。初心者の内は Scratch でもいい。
どちらも、他の人に作品を公表しやすい環境だ。
X68k がそうであったように、出来が悪くても恥ずかしげもなく公表し、評価をもらえることが大切だと思う。
プログラムに限らない。絵でも音楽でも、今は昔に比べてずっと公表しやすい。
ただ、なんでも有難がられた X68k と違い、今はソフトも情報もあふれている。
出来が悪いと容赦なく叩かれるし、ちょっと初心者に厳しい環境かもしれない、とは思う。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |