プログラマーのために

X68kの周辺ペリフェラルはMacに近い思想をもっていたのですが、ソフトウェアはMacとは正反対でした。

Macは開発者に負担を強いても使用者が楽を出来るようにシステムが設計されているのですが、X68kは

開発者は最大のユーザーである

という考えで、開発のしやすさが重視されています。


今回は、エンドユーザーに近い方からコンピューターの内部に向けて、ソフトウェアの構造を眺めて行きましょう。

(今回、話の都合上文字だらけです。視覚的につまらなくて申し分けない)

目次

X-BASIC

XC

Human68k

 コマンドシェル ビジュアルシェル SX-WINDOW

IOCS


X-BASIC

X68kには標準でBASICが添付していました。これは当時のパソコンでは普通のことです。

しかし、X68kのBASICは普通のBASICではありませんでした。構造化を強く意識し、拡張性を重視した構造だったのです。

BASICの文法は、BASICというよりはむしろC言語に近いものです。先頭に行番号がつき、インタープリタではありますが、

  • 変数使用前に宣言が必要(しなくてもよい)
  • 変数の宣言時の初期化が可能(配列も初期化可能)
  • ローカル変数をもった関数呼び出しが可能
  • 複数行にわたる IF〜ELSE〜構文や、SWITCH〜CASE〜BREAK構文が使用可能
  • BNFにしたがった文法

など、C言語を強く意識した構造をもっています。

だいたい、行番号はスクリーンエディットの必要上ついている程度で、実際にはプログラム中ほとんど使用されません。わざわざ「行番号を取り除いてアスキーセーブ」「行番号をつけながらロード」を行う命令まで用意されていたくらいです。


BASICはOS上で動作するアプリケーションとして設計されていました。そして、その起動時には設定ファイルにしたがって外部関数ファイルを読み込むようになっています。

外部関数ファイル自体は通常アセンブラで記述されるのですが、このように関数をBASIC本体とは別に用意することで、ユーザーが自由にBASICを拡張出来るようになっています。


また、BASICで使われる機能のいくつかでは、実際の処理はデバイスドライバが行っていました。

そのためそれらの機能はBASIC以外からも使用可能です。


実際には発売当初はBASICの内部で処理が行われていましたが、後にいくつかのデバイスドライバに切り分けられました。

具体的には、FM音源を制御するためのMMLの解釈はすべてデバイスドライバが行っていましたし、PCMの再生もデバイスドライバの仕事でした。

いまではこれらのデバイスをデバイスドライバで制御するのは当然なのですが、X68kの時代には非常に珍しく、そのような仕組が純製品で用意されていたことが、のちに大きな流れを作ることになります。


XC

ホビーパソコンのなかでは、X68kのC言語普及率は飛び抜けて高いものでした。

当時、通常のホビーユーザーはBASICを使用していたため、他の機種ではC言語が発売されていたとしても、普及率はそれほど高くなかったのですが・・・


その理由は、上に紹介したX-BASICがC言語に近い構造をもっていたことにあります。なんと、X68kの純正C言語であるXCでは、BASICのコンパイルが可能なのです。

BASICのコンパイルは、BASIC to C コンバータがCに変換したソースをコンパイルすることで行われます。そのため、細部の動作は微妙に変わることもありました。


BASICコンパイルの必要上、BASICには不可欠なグラフィックライブラリが充実しており、これも他機種のC言語とは一線を画していました。

当時はまだC言語はホビーユーザーの物ではなく、グラフィックどころか文字を扱うライブラリですら十分にそろっていなかった時代です。(ANSI-Cの制定よりも前です)


XCのCコンパイラはアセンブラのソースを吐き出すタイプのもので、自動的にアセンブラ、リンカが起動して実行ファイルを作り出します。この構造が、後々X68kに重要な流れを作り出すことになります。

ファームウェアレイヤー図  ここでシステムの構成の概観を示しておこう。

 Human68kはMS-DOS時代のOSなで、現在のOS構成に比べるとかなりごちゃごちゃしている。(あまりにごちゃごちゃなので、この図は正しくない)
 X-BASICやXC、各種のシェルはアプリケーションにあたる。ただし、後述するSX-WINDOWはHuman68kのアプリケーションでありながら、それ自体がOSだ。
 アプリケーションはOSを無視してハードウェアを制御することが多い。これを行儀が悪いと見るか自由で楽しそうと見るかは感性の問題だ。


Human68k

OSであるHuman68kは、MS-DOSに酷似した構造をもっています。CPU管理はシングルプロセスですし、メモリ管理も単純に「最も大きなメモリブロックをプロセスに占有させる」というものです。(ですから、MS-DOSと同じように、メモリを取得する際には不要メモリを一度返還する必要があります)

しかし、CPUである68000には8086の様な「メモリセグメント」は存在しません。メモリはすべてリニアにつながっていますから、MS-DOSのようにメモリモデルで苦しむこともないのです。


また、Human68kのファンクションは、C言語での呼び出しを想定して設計されています。

そのため各機能にはC言語の類似関数の名前がつけられていますし(putc、gets、malloc、exitなど)、パラメータはスタック渡しです。また、文字列の終端は文字コード 0で表わすようになっていました。(MS-DOSでは文字コード36、'$'が終端)


コール方法自体はCPUのFライン未実装命令を利用していますので、$FFnnという2バイトの数値を埋め込むだけです。nnには機能番号が入ります。

XCにはアセンブラ用のマクロが付属していて、

DOS  PUTC

などと記述するだけで該当機能が呼び出せるようになっていました。


初代X68kには、システムディスクの「福袋」ディレクトリに、このマクロとアセンブラが入っていました。そのため、この呼び出し方法は統一された方法として誰もが使っており、アセンブラのソースリストも非常に読みやすくなっていました。

Human68kはバージョン3まで作られましたが、もっとも長い期間安定して使われていたのはバージョン2です。

バージョン2にはマルチタスクOSを目指したと見られる準備がいたるところに見られたのですが、結局バージョン3でもマルチタスク化はなされませんでした。

(ただし、これを利用してマルチタスク処理を行うフリーウェアはありました。詳しくは次回取り上げる予定です)


前回も書いたようにHuman68kには最初からシェルが2つ、のちにもう1つ用意されていました。これはMS-DOS等と違い、シェルとカーネルがきちんと分離していることを意味します。

この3つのシェルを簡単に説明しておきましょう。

コマンドシェル

MS-DOSのCOMMAND.COMに相当するシェルです。最も一般的に使われたシェルでしょう。


X68kではテキスト画面にビットマップを使用し、4プレーン重ねることで16色を表示できるようになっていましたが、コマンドシェルでは(というか、X68kでは)文字表示にこのうち2プレーンしか使っていませんでした。

そのため色は4色(白・黒・青・黄)しか出なかったのですが、残りの2面にはマウスカーソル・ソフトウェアキーボード・電卓などを表示することができます。

特にいつでもキー一発で呼び出せる16進電卓はプログラマーには便利で、計算結果をそのままキー入力として送ることも出来ました。


グラフィック画面とは干渉せずにマウスカーソルなどを表示することも出来るため、コマンドシェルからはグラフィックを扱うプログラムも簡単に作ることができました。

ビジュアルシェル

VisualShell  MacintoshのFinderに見た目を似せたシェルです。見ためが似ているだけでAPIが用意されているわけではなく、ただのシェルにすぎません。

 つまり、ファイルの操作やアプリケーションの起動など、コマンドシェルと同等の操作は可能ですが、起動されたアプリケーションは独自の環境で動くために操作環境が統一されるわけではありません。

SX-WINDOW

SX-Window  左はSX-WINDOWの画面(一部)。
 グレーのイメージで統一されているが、モノクロ写真ではない。 中央に写っているのはサンプルゲームのピンボール。その左に写っているのは電卓である。

4代目のX68kである、X68000 EXPERT IIと一緒に発表されたこのシェルは・・・すでにシェルの枠を超えた物となっています。

MS-DOSのWindowsに相当するソフトで、Human68kの機能を拡張し、マルチタスクを可能にし、統一されたAPIで統一された操作環境を作り出します。


Human68kではFライン未実装命令がコールに使われましたが、SX-WINDOWではAライン未実装命令がAPI呼び出しに使われます。

 内部的にはMacintoshに酷似しているという裏話もあったようですが、操作環境の面ではMacintoshやWindowsに負けない部分もあり、むしろNeXTに近いという評価もあります。(今でも他のOSに採用して欲しいような、便利なアイデアも多数ありました)

しかし、10MHzの68000、2MByteのメモリ空間では処理が重く、ほとんど使われることもなく消えていくこととなりました。


掃除機アイコン 家電のシャープらしく、ファイルを捨てるアイコンが「掃除機」だったりというのも、いまでは笑い話です。


IOCS

X68kでは、内部ROMのプログラムをIOCSと呼びます。一般にはBIOSと呼ばれるものと同一です。

さて、IOCSもDOSと同じようにC言語からの呼び出しを強く意識した構造をしています。とはいえ、さすがにこちらはスタック呼び出しではなく、レジスタにパラメーターを入れてソフトウェア割り込み(trap #15)を掛けることで行います。


この呼び出しもまた、アセンブラのマクロとして統一的な方法が準備されていました。


X68kはテキスト画面がビットマップなので、文字の描画ルーチンなどはIOCSレベルで用意されています。また、漢字ROMは16dotと24dotの2種類が用意されていますが、それらの文字パターンもIOCSで読み出すことが可能です。


今までにお伝えしたユニークな周辺ペリフェラルの制御・・・フロッピーディスクのオートイジェクトやアラーム起動の設定、スプライト表示、テキスト画面の高速コピー命令、DMA転送などのX68kのハードウェアを簡単に使うためのルーチン群も多数用意されていました。


X68kのロゴの下には、パーソナルコンピューターではなく、「パーソナルワークステーション」と書き込まれています。 X68000ロゴ


ワークステーションといえばUNIXを連想しがちですが、本来の言葉の意味からすれば、「作業場所」として耐えうるだけの環境であればワークステーションを名乗って問題はないはずです。

そして、X68kは、確かに個人で持てるワークステーションでした。決して性能は高いものではないかもしれませんが、ここまで開発環境に気を使ったパソコンは、X68kの前にも、後にもないでしょう。


さて、次回はそんななかでユーザーが作り出したソフトウェアを、一部でも紹介したいと思います。

ソフトウェアを扱い始めるとどの機械でも膨大な量になってしまうのであまり扱わないことにしているのですが、X68k当時の熱気を伝えるには、これらの話を避けて通るわけにはいきませんから。

(ページ作成 1997-07-06)
(最終更新 1999-04-01)

前記事:X68kのハードデザイン     戻る     次記事:X68kのフリーソフト
トップページへ

-- share --

0000

-- follow --




- Reverse Link -