前回、X68kが開発環境を重視したマシンであったことお伝えしました。
開発環境の整ったマシンと言えば、UNIXワークステーションが思い浮かびます。
実際、これは開発者も意識していたようで、Human68kにはUNIXを参考にしながらMS-DOSの（当時のハードウェア水準では）現実的なインプリメントをを行った、と思われるところが数多く見受けられます。
その一つにファイルの拡張子があります。MS-DOSでは多くのアプリケーションが、暗黙の了解によって統一した拡張子を使っていますが、X68kでもそれは同様で
| .x .r .z | 実行ファイル |
| .c .h .s | ソースファイル |
| .o | ソースファイル |
などは統一して使われていました。
この中で注目すべきは .s と .o で、MS-DOSを参考にしたならば .asm .obj となるはずです。.s .o は明らかにUNIXの命名規則です。
こうなって来ると、使う側もUNIXを参考にして開発環境を整え始めます。
前置きが長くなりましたが、今回はユーザーの作り上げた、フリーウェアによる開発環境を紹介いたします。
ファイル名改良 メーカーへのフィードバック 解析ツール マルチタスク
標準環境 UNIXコマンド シェルスクリプト実現 改良シェル BSD
開発環境の中で重要なものを挙げろ、と言われたら、多くの人がエディタと言語を上位にランクするのではないでしょうか。
X68kでも、この２つはかなり初期から開発が進みました。
Human68kには標準でEDというスクリーンエディタが付属するのですが、これは性能的にはかなり不満のあるものでした。
そこで、UNIXで有名なEmacsエディタを小型化した、MicroEmacsが早くから移植されています。のちに本家Emacsも移植されることになるのですが、この後X68kユーザーはEmacs派とED派に分かれることになります（EDも、ユーザーの手によって改良が進みました）
ソースリストがエディット出来るようになると、次はコンパイラが必要です。
Human68kにはXCというコンパイラがあったのですが、これも性能には不満の出るものでした。
無いものは作る。資産０からスタートしたX68kのユーザーの間では、このような風潮が有りました。そして、やがてGNU C Compiler（以下GCC）が移植されます。
XC は幸いにして、コンパイラがアセンブラのソースを出力する方式になっています。MS-DOSの多くのコンパイラに見られるような実行コードを直接出力する形式だったら、GCCの移植は困難だったかもしれません。
しかし、GCCは移植に成功し、後にはX68kに特化して改良が重ねられます。
GCCは素晴らしい性能を発揮しました。GCCでコンパイルされた実行コードは、XCのそれよりも明らかに高速に動作するのです。
しかし、そのためにGCCはXCよりもコンパイルに時間がかかりました。コンパイルに時間がかかると、開発の効率は落ちます。
GCCの改良はもちろん続けられましたが、同時に、実はリンカがかなり時間を浪費して いることがわかりました。
リンカは分割してコンパイルされたオブジェクトをまとめ上げ、実行コードを作り出すためのソフトですが、この設計が「64Kバイト以上のメモリを使わない」ようになっていたのです。どうやらMS-DOSから移植されたらしいのですが、メモリを膨大に持つX68kでは、速度を遅くするだけの制限です。
無いものは作る。市販ソフトの少なかったX68kユーザーの間には、そういう雰囲気が生まれていました。
そういうわけで、「ハイスピードリンカ」（以下HLK）というフリーウェアが生まれます。
このリンカは劇的に実行速度を上げながらも従来のリンカと完全に互換性を保っていたため、置き替えるだけで大幅にコンパイル時間を短縮出来ました。
GCCは徐々に改良されて行きました。その途中で、いくつかの問題点も発見されました 。XCのアセンブラでは、GCCの性能を活かしきれないのです。また、この頃までには従来 のアセンブラのバグも、数件報告されていました。
無いものは作る。再びこの考えで、ユーザーの中から新しいアセンブラが産み出されました。
「ハイスピードアセンブラ」（以下HAS）は、実際には高速性よりも高機能を目指して作られていましたが、HLKと共に開発環境の底辺を支えたい、という願いから同じよ うな名前が付けられたようです。（作者は別の方です）
この後、XCがバージョンアップされ、ソースコードデバッガ（以下SCD）が発表になると、GCC、HAS、HLKともにSCD用の情報を出力できるようにバージョンアップされ、さらにGNU Debuger（以下GDB）が移植されます。
GDBは、ソースコードレベルのデバッグが可能で、しかもデバッグ情報をRS-232Cに接続した端末に出力することでリモートデバッグを可能にするという、高機能デバッガでした。
ソースを作成し、コンパイル・アセンブル・リンクし、デバッグを行う。ここに、すべての環境がフリーウェアで整いました。しかも、それらはすべて市販品よりも高性能です！
実際にはこのときはまだ、XCも「ライブラリのために」必要とされていました。しかし、最終的にはライブラリもフリーで作られることになります。
GCCの移植により、UNIXの優秀なアプリケーションがHuman68kに移植され始めました。
元々Human68kはMS-DOSをUNIXに近づけたような構造をしており、UNIXからソフトを持ち込もうとするのは当然の流れでしょう。
しかし、UNIXからの移植はそれほど簡単なことではありません。そのうちいくつかの問題は、実にばかばかしい理由によるものでした。
理由の１つに、ファイル名の制限があります。UNIXのファイル名は長さも使用出来るキャラクターもほぼ無制限ですが、Human68kではMS-DOSの制限を受け継いでいるのです。
まず、このバグに近い仕様を正すため、 TwentyOne （とぅぇにぃわん）というプログラムが作られました。これを使うとファイル名21文字が、すべて認識されるようになります。
ここで、UNIXのアプリケーションの移植をしていた人々から、TwentyOneの作者に要望が出され、その要望はすぐに取り入れられました。それは、「ピリオドを拡張子との区切り以外でも使えるようにする」という改良でした。
UNIXでは、ファイルを加工した場合に、後ろに拡張子を追加するのが普通です。例えば、test.txt というファイルを圧縮したばあい、test.txt.zip というようになります。
ピリオドをどこでも使えるようにする。ただそれだけで、UNIXから持ち込んだファイルの扱いは楽になり、移植にさらに拍車を掛けたのです。
UNIXとはあまり関係ありませんが、X68kは文字表示が遅いという問題がありました。UNIXのソフトウェアの多くは文字出力を行うのですが、ビットマップ表示を行うX68kは文字の表示に時間がかかってしまうのです。
しかし、「仕方ない」などと思ってしまっては負けです。文字表示用のIOCSエントリをフックして、文字表示速度を改善するソフトが現われました。
TurboConsole はそうしたソフトの先駆けで、文字表示をチューンすると共に、文字フォントを自由に変更できるようにするという拡張を行っています。この時点では、このフォントファイルは独自の物でした。
しかし、その後メーカー純正の IOCS デバイスドライバが発表され、TurboConsoleの機能はすべてメーカー品に取り込まれます。
すべてです。これが重要なところ。なんと、TurboConsoleが独自に定めたフォントファイルまでもが、純正品の規格に採用されたのです！
これは明らかにメーカーがユーザーに歩み寄った瞬間でした。
この後もメーカーとユーザーの間で良い意味での競争は進み、浮動小数点デバイスドライバやFM音源ドライバなども、より高性能なものが産み出され続けました。
これらの改良を行えたのも、ソースコードジェネレータという優れたソフトウェアが存在したからです。
このソフトは、実行ファイルをディスアセンブルし、ジャンプ命令を解釈しながらデータ部分とプログラム部分を分離し、データから文字列を探し出し、再びそれらに間違いがないかプログラムを追いかけ・・・という複雑な動作を繰り返しながら、ほぼ元どおりのアセンブラソースを再現してしまうというものです。
実行ファイルが元々アセンブラで作られていて、デバッグ情報（ラベルなどの情報）を特に削除してなかった場合、まったく元のファイルが再現されるといっても過言ではないほど、高性能のソフトウェアでした。
このソフトウェアの存在により、ほとんどすべての純正ソフトウェアが、ユーザーの手でさらに改良されています。
また、非常に実験的なプログラムでは有りましたが、Human68k でマルチタスクを可能にするプログラムもありました。
Human68kはバージョン２以降、マルチタスク化の布石がなされていて、起動時にシステムが持つタスクリストに登録を行ったプログラムは、バックグラウンドで実行される仕組みが有りました。
このままでは最初から「マルチタスク用に書かれた」プログラムしか複数実行出来ないのですが、 普通のプログラムでも適切な方法で起動させてやる仕組みさえあれば、複数実行できるはずです。そして、まさにそれを行うのが BGDRVキットでした。（OS本体には手を加えていません！ 元々OSの機能を使ってマルチタスク化しているのです）
BGDRV は、プロセス管理がUNIX互換になるように作られたプログラム群で、Human68k をマルチタスクOSに変えてしまいます。ただ、惜しむらくはCPUである68000がマルチタスクを行うには遅すぎたことです。着想はよかったものの、このプログラムはあまり実用になりませんでした。
しかし、シングルタスクOSであった Human68k は、ついにマルチタスクの環境をも手に入れるようになったのです。
Human68kに最初から２種類のシェルが付いていたことはすでに取り上げた通りです。標準的に使われていたシェルはコマンドシェルでしたが、これはMS-DOSとほぼ同じシェルになっていました。
ただし、標準でいくつかの便利なコマンドやドライバが付属しています。
HISTORYドライバは、入力したコマンドを記録しておき後で呼び出したり、ファイル名の補完（途中まで入力したファイル名を、ディスクに存在するファイル名として完成させる）などの機能を持つものでした。
また、SUBSTコマンドは、ドライブを別のドライブのディレクトリとしてアクセス可能 にするドライバでした。
じつは、この２つのプログラムは、UNIXで良く使われるシェルである、CSHに非常に近い環境を提供するためのものなのです。
しかし、中途半端に似せたものはストレスが溜まります。とくに、もっとも使われる操作であろう、「ファイル名の一覧を見る」が、UNIXでは ls なのに対して、Human68kではMS-DOSと同じくDIRだったのが、かなり問題だったようです。
無いものは作る。再びこの精神が発揮されます。さいわいGCCが移植されたこともあり、UNIX生まれのコマンドを移植する作業は急ピッチで進みました。
詳しくは書きませんが、ls, cat, more, less, grep, sed, tar, zip, awk,perl,・・・などなど、日常使うのに困らない程度のコマンドがそろうのに、それほど時間はかかりませんでした。
しかし、ここで別の問題が出てきました。
UNIXでは、awkなどで作られたスクリプト（人間にわかるように書かれたプログラム）を、特別な操作無しに直接実行出来る仕組みがあります。これは一度つかったらやめられない便利な機能なのですが、Human68kではこのようなことは出来ないのです。
そして、この機能が使えないと、UNIXの多くのソフトは魅力が半減してしまいます。
無いものは作る。やがて「実行属性ビットドライバ」などというものが出来上がりました。
これは、Human68kでは未使用だったファイルの属性ビットを書換え、実行属性ビットにすることで、実行属性のついたテキストを直接実行出来るようにしようという、実に大がかりなものでした。
また、UNIXでは１つのファイル内容を複数のディレクトリから参照出来る「リンク」と呼ばれる機能があります。これも非常に便利な機能ですが、これと同じ動作を行えるようにする「シンボリックリンクドライバ」も発表されています。
しかし、ここまで来るとドライバレベルでどうにかするよりも、いっそ新しいシェルを作ってしまった方が使い勝手も良くなります。実際、bash, fishというシェルも作成されました。
fish is shell on human ・・・ 魚は人間の上の貝ですという洒落の利いた一文が載っていました。
これらのシェルはUNIXのシェルのように、ワイルドカードを展開してコマンドラインを作るようになっていました。（MS-DOSやHuman68kの標準的な作法では、ワイルドカードの展開はアプリケーションの責任です）
しかし、Human68kにはコマンドラインの長さ制限が有りましたので、そのままではうまくいきません。そこで、アプリケーションに制限を超えたコマンドラインを渡す作法が確立されました。
この方法は「cshwildlib」ライブラリとして供給され、多くのフリーソフト作者が利用していました。
これらのシェルを使い始めると、ほとんどUNIXと同じ感覚で作業が出来ると言って良い状態でした。
しかしここまできたら・・・そう、お分かりでしょう。現在、X68kにはすでにUNIX(BSD)そのものが移植されています。これは、上位機種であるX68030以上でないと使えないものの、完全なUNIXそのものです。
そして、X68030以上であれば、CPUを 68060 に換装するためのボードまで作られているのです。
今でこそ PC/AT互換機でもLinuxなどのフリーUNIXが注目されていますが、X68kではそ れよりも遥か以前から、UNIX環境を目指して発展してきたのです。
無いものは作る！
そして今も、熱心なユーザーの挑戦は続いています。
このページの誤字脱字発見・情報提供・意見などありましたら、下の一行掲示板へどうぞ。樫樹の広場から全体を見ることも出来ます。