編集部から Windows, X-Window, 10周年（月刊ASCII 1987年7月号14）

巻末にある編集部の記事が時代を感じることができたのでスクラップして味わうことにする。

PC-9801オペレーティングエンバイロメント MS-WINDOWS
WINDOWSって何のはなし?
　1983年の春、ちょうど4年程前の話ですが,皆さんは覚えておられるでしょうか.この業界で4年という歳月は,「スッゲー」大昔のような気がしますが,別にアンモナイトやサンヨーチューの話ではありません.Microsoft社がOEM向けにWINDOWSのデモンストレーションを行ったのは,4年前のことです。確か最初のリリース予定は1984年の5月だったのが,1984年の11月に延期されて、次に1985年の6月に延期され,結局ユーザーの手元に届いたのは,1985年の11月だったという,長い長い熟成の期間をおいた,どこぞのウイスキーのようなソフトウェアなのです.
　米国でIBM-PC用のWINDOWSがリリースされたのは,1985年の11月ですが,日本では,PC-9801用のWINDOWSがリリースされたのはそれから1年を経た1986年の10月,どちらのリリースのときも,「別にどうでもいいんじゃないの」という雰囲気があったのですが,最近ようやく「へ～なるほどネ～」という声も聞かれるようになり,WINDOWSもようやく春がきて「ヨチヨチ」歩き出したミヨチャンになったのではないでしょうか.

なんでWINDOWSがいるの?
　さて、4年もかけていったい何のためにWINDOWSを開発したのか,きっと最初の開発を始めた動機は,Apple社のLisaに触発されたんだと思いますが,それでも4年間もかけるなんて「フツー」じゃないと思うのです.そのへんの高層ビルだって,1年もあればできるのに,ソフトウェアの開発にそれだけの期間をかけるのは,やはりそれだけの「ワケ」があるのではないかと考えているわけです.
　WINDOWSは、オペレーティングエンバイロメントなどといわれますが,オペレーティングエンバイロメントとはいったいなんなのかといった疑問もあるかもしれません.これは,コンピュータの利用環境という意味なのでしょうが,「カチカチペロン」(カチカチがマウスのクリックの音で,ペロンがウィンドウが開かれるときの音)と単に画面に表示されているウィンドウのユーザーインターフェイスだけを指しているのではなく,ソフトウェアの仕様やデータの互換性,データの共有,ソフトウェアの流通性,開発環境,といったこともすべて含めたグローバルな環境を意味しているに違いないと、ぼくは考えています.

WINDOWSの特徴
　WINDOWSというソフトウェアは,ちょっとみるとウィンドウが「カチカチペロン」と開かれて,マウスで「こねこね」と操作するという,なんとなく「ヘロヘロ」した雰囲気のするソフトウェアなんですが,そのへんのただウィンドウを開いていればいいというプッツンしたソフトとは,まったく異なったコンセプトを持っており,なかなか「フムフム」といった奥の深いところがあります.要点だけ書いてしまうとなぜかつまんないのですが,おもな特徴としては,次の点があげられます.
●ユーザーインターフェイス
　WINDOWSはマウスを「こねこね」しながら使うのですが,その「こねこね」の仕方が統一されています.WINDOWSやそのアプリケーションでは,いずれのアプリケーションでもこの「こねこね」が同じです。ですから,1つのアプリケーションの「こねこね」に慣れてしまえば,どのアプリケーションでも簡単に「こねこね」できます.
●データの共有
　WINDOWSのアプリケーション間では、データが「ツーカー」です.どのアプリケーションとの間でも,グラフィックデータやテキストデータを「ツーカー」できます.ですから、ファイルのコンバートもいりませんし,「ツーカー」したデータを「ほにゃらら」することもできます.
●ソフトウェアの流通性
　WINDOWSのアプリケーションは、WINDOWSが走っていいるマシンであれば,どのマシンでも「スポポーン」です。IBM-PCでもPC-9801でも,WINDOWSのアプリケーションはデバイスインディペンデントに作成されていますから,「スポポーン」なわけです.
　とまあ、WINDOWSはこのように「びしばし」のソフトウェアですから,そのうちアプリケーションもMacintoshバリのものが登場するでしょう。ぼくはこのWINDOWSには,かなり期待しています.
　とりあえずこの原稿をよんでわけのわからなかった人は,WINDOWSの本をご一読ください。ちゃんとわけのわかるように書かれています。お値段も比較的お安くさせていただきました,どうぞヨロシク.
(今回の「ノリ」が受けないのではないかと結構ふあんがっているnobu-tでした)

受ける受けないではなく、Windowsの開発がすごく難航しているかが伺われた。Macという見本があるのになぜこんなに開発期間が長かったのか。私はこれは8086CPUが悪いからだと考えている。決してマイクロソフトの技術者が能無しなのではないと考える。互換性維持という大義名分がどれだけ技術者に苦労を掛けていたか。言い換えれば、インテルの営業が技術開発方針を決めたからこうなったのだ。売りやすいものを売るならだれでもできる。売りにくいものを売るのが営業の力ではないか。技術者を苦しめることでしか成績を上げられない者たちが憎い。インテルはIA-64で互換性を捨てたではないか。それならもっと早く16bitのときにすべきだったのだ。やっぱり8086が憎い。

次はX-WINDOW

X-WINDOWは今!!
　Xとは,いわゆるpds(パブリック・ドメイン・ソフトウェア)のウィンドウ・システムであり,重ね合わせ可能であること,サーバ/クライアントモデルであること,それからネットワーク対応であるなどの特徴があります。
■Xの基本
　サーバ/クライアントモデルでは,常駐プログラム(サーバ)がハードウェア資源を管理し,それぞれのウィンドウ・アプリケーション(クライアント)は、サーバと通信することで入出力を行います.サーバは巨大になりますが,各クライアントが機種の違いを意識しなくてよくなり,サイズも小さくなります.さらにXの場合,クライアントはネットワークにつながれたどのマシン上のものでもかまいません.また,ほかのマシンにログインしたウィンドウをいくつも開いておくこともできます.
■最新"X"
　Xは,マサチューセッツ工科大学(MIT)と米DEC社の共同研究であるアテナ計画(Project Athena)の成果の1つとして共同開発されたウィンドウ・システムです.現在バージョン11が試運転中ですが、手に入りやすいのはバージョン10のリリース3か4です.
　リリース3と4の大きな違いは、4ではウィンドウにスクロールバーやタイトルバーを付けることができ,アイコンの内容もグレードアップされ,さらにネットワークゲームなどが追加されていることです。ちなみに,メニューライブラリはリリース3ですでにサポートされています。開発はCかCLU言語で行います.
■ワークステーションとパソコン
　まず表x.1をみてください。
　これらが,現在あるさまざまなウィンドウ・システムのおもだったものです.
　さて,これから主流となるものは?というと,X,Sun NeWS,MS-WINDOWS,Mactoolsの4つに絞られるでしょう.
IX vs News
　XとSunNeWSは今,激烈なトップ争いを展開しています.現在のところXが先行していますが(なにしろNeWSは今年の9月にならないと正式版が出てこない)、どちらもサーバ/クライアントモデルを採用しており,通信プロトコルの違いが争点になりそうです.NEWSの方は,Xに比べて高度な制御構造を持っており,Xのプロトコルを取り込むことは容易です.一方XもNEWSのプロトコルを取り込む意向があり,現在かなりシェアが広がっていることや,手に入りやすいので移植作業も進みやすいことなどが,将来に向かっての有利な条件です。
■日本におけるXの現状
　東大の石田晴久教授のグループによる研究と移植が進んでおり,PC9800シリーズ用のサーバ(pds)もリリースされそうです.現在,株式会社SONYの"NEWS",米SunMicroSystemsの"SUN”でXが動いています.
　Xは,OSがUNIXであることを前提としている節もありますので,パソコン用としてはMS-WINDOSが主流になるでしょう.MS-WINDOWは今後Sun NeWSの機能も取り込みますから,そちらも見逃せないところです.

(masao-k)

pds(パブリック・ドメイン・ソフトウェア)とは懐かしい。さて、マイクロソフトのWindows開発が難航しているのにpdsが登場しているのはなぜか。しつこいけど8086じゃないからだ。と言いたかったがPC-9800シリーズ用？まじか。


最後は10周年

10周年を迎えて
　今月号の編集作業もようやく終り,読者の一方々からの反応を心待ちにする時期が近づいてきた。10周年記念号だから,何か特別な企画をたっぷり盛り込みたいそう思いながらスタッフ一同頑張った結果が,この分厚いアスキーである.今月号では、近未来のパーソナルコンピュータ像を探るとともに,パソコンの楽しさを改めて見直したいと考えていた.特集,特別企画を中心に,そうした記事を取り揃えたつもりでもある.とはいえ,それがどこまで表現できたか,そして読者の方々にどう受け止められたかが,大変に気になる.
　10年ものあいだ続いた雑誌を編集していると,ともすればマンネリズムに陥る危険がある.それを救ってくれるのが,読者の方々から届く,各種の反響である.特に,毎日届くアンケート葉書は,編集の指針を考える上で,大変に参考になる.多くのお誉めの言葉もいただくが,中にはきびしい叱咤,激励もある.そして,そういった様々な声が,スタッフの励みにもなり,反省のきっかけにもなる.よく言われることではあるが,本当に雑誌は,読者の声に支えられているものだと思う.
　そうした葉書で最近よく見かけるものに,「月刊アスキーは,もっとオピニオン誌として,明解な意見を打ち出すべきではないか」といった声がある.このところ,注目すべき新製品が続々と登場し,本誌の誌面の多くを,そのレビューに使ってはきた.しかし,編集部の中では、パーソナルコンピュータの新しい使い方,楽しみ方について、つねにディスカッションを重ねている.そして,そうした中から生まれた企画を誌上に掲載するケースも,たびたびあった.一人よがりの主張ではない,パーソナルコンピュータの新しい世界の提案は、当誌の使命と考え,今後も積極的に掲載していきたいと思っている.
　現在の日本のパーソナルコンピュータ業界が,米国のそれに較べて,まだまだ立ち後れているのは事実だろう.そのため、米国から学ぶべきことはまだまだ沢山ある.しかし,当誌では単なるモノマネではなく,日本の状況を踏まえた,独自の視点をもった新しい話題を提供していきたい.
　10周年を迎え,さらに充実した誌面を目指し,スタッフ一同決意も新たにしている.そして,そのためには、読者の方々にも,様々な意見をお寄せいただきたいと考えている.これからも,どうぞよろしく.

土田米一

ASCIIは普通のパソコン雑誌ではなく、総合誌という立ち位置の雑誌だった。だから、まだ見ぬ新技術の開発記事とか未来志向の雑誌だった。そのため、実現しなかった記事もあった。予想だ外れることもあった。34年前は未来予測などすぐに忘れて新型パソコン、CPU、OS、アプリケーションソフトに興味を奪われたため外れたことすら気がつかなかった。こうしてスクラップすると答えが分かっているので上から目線で記事を読み返すことができ面白い。

PC-286 MZ-2861（月刊ASCII 1987年7月号13） TEST ROOM

この号のTEST ROOM からはPC-286とMZ-2861をスクラップする。


PC-286の写真をスクラップする。









互換性の部分をスクラップする。

　PC-286で動作するソフトウェアとして,4月末時点で,エプソン販売から発表されているものは,110種類あり,すべてPC-9801シリーズ用である.セイコーエプソン(株),エプソン販売(株)で動作確認を行ったものであり,「PC-286 MODEL 0ソフトウェア・ハードウェアガイド」として,やはり動作確認されたボードなどの周辺装置とともに販売店で配布される.
　過去,雑誌等で販売ランキングに登場したソフトウェアを中心に確認したとのことであり,一太郎Ver2.1,Multiplan Release2.0,Lotus1-2-3,Candy 2,CTERM,MIFES-98など,PC-9801シリーズ用として良く知られているソフトウェアが名前を連ねている.
　Microsoft CやMASMなどの、標準的なプログラム言語やコンパイラの類などが動作するのは言うまでもない.さらには,日本語MS-WINDOWSや日本語コンカレントCP/M R3.10,PC-UX(Rel2.0)など,日本電気から発売されているOSまで含まれている.
　編集部においても,評価用マシンが到着して以来,さまざまなソフトウェアの実行を試みている.ゲームでは,いくつか動作しないものが出てきているものの,ビジネス系のソフトについては,現在までのところ特に問題のあるものは見あたらないようである.
　むしろ,ソフトウェアの互換性で問題となるのは,市販のソフトウェアではなく,ユーザーの自作ソフトではないかと思われる.
　それは,MODEL 0の現バージョンでは,BASIC ROMや,グラフィックLIOのうちの一部の機能(PAINT,CIRCLE)がリリースされていないことによる.雑誌や書籍などで公開されているグラフィックライブラリの中には,グラフィックLIOに依存しているものが少なくないのである.(株)ライフボートから発売されているユーザープログラム用ライブラリである,CTOOL/98のグラフィック機能も正常に動作しない.
　もっとも,グラフィックを多用したビジネスソフトやゲームソフトの多くは,低速なグラフィックLIOにはほとんど依存していないのが現状である.より正確な互換性の確認については,もう少し時間が必要だろう.

■処理速度は,VMの2倍,VXよりも20%高速
　PC-286を語る上で,それがPC-9801シリーズの互換マシンであることだけでなく,現在,最速に属する16bitパーソナルコンピュータであることを忘れてはならない.
　実際に,いくつかのプログラムを動作させた結果を,この後のベンチマークの項で示す.PC-9801VMに対して2倍,VXに対しては20%高速であるとする,セイコーエプソンの発表を,ほぼ裏づける結果となっているようである.
　また,ビジネスの現場向きに考えられた内蔵マスメモリのラインナップや,処理の高速性は,互換マシンという見方を離れた,このマシンのアイデンティティを主張するものであろう.
　特に高速タイプの40MbytesHDDは、データベース処理などでディスクファイル操作の多いユーザーにとっては是が非でも必要であろう.PC-9801シリーズ用の外部ハードディスクとして数種類の40Mbytesハードディスクが発売されているが(本誌87年6月号参照),高速性とともに,コストパフォーマンスの面でも優れた製品と言える.
　80286CPUを10MHz,ノーウェイトで使用するハードウェア上の方式は,IBMのPS/2シリーズの主力として採用されたこともあり,パーソナルコンピュータのジャンルで,当面の主流となることは間違いない.
　しかし,単なるハードウェアのスペックから新製品を評価することはできないであろう.パーソナルコンピュータは,あくまでもソフトウェアを実行するための「ただの箱」であり,ソフトウェアの実績の上でしか語れないジャンルなのである.
　ユーザーは,既存のソフトウェアを快適に実行し,なおかつ少しでも安価なものが欲しい.PC-286は,この課題を満たそうとする姿勢が明白に伝わってくるマシンである.

知人がPC-286 MODEL 0を買って私達も触らせてもらったが使いたいソフトは皆動いたという記憶だ。ゲームを持っている人もいたが、本数が少ないため動いたという記憶しかない。このため、以後パソコンを買いたいという人にはどんなソフトを使いたいかを聞いて問題がなければPC-286を勧めた。


続いてMZ-2861について


互換性の部分をスクラップする。

　表3に,エラトステネスのふるいをPC-9801各機種と,MZ-2861のMS-DOS上,MZEXを起動後のそれぞれで実行した結果を示す.VXに比較すると,約1.8倍の時間が掛かっている.I/Oが絡むと,この結果がどう変わるかが分からないが,ソフトウェアエミュレータなので,あまり速度は期待できないだろう.
　現在のところ,シャープ側では数本のPC-9801用ソフトについて動作が確認されている.編集部でも何本かのソフトについてチェックしてみたが,動くものもあれば動かないものもあるといった状況である.起動時のオプションの指定によって動いたり動かなかったりするもの,マウスドライバによって動作が変わるものなど、ユーザーがうまく動作させる方法を見つけるには大変な努力が必要となるだろう.指針となるべきマニュアルも1枚の紙を二つ折りにしただけの簡単なもので,具体的にどのソフトのときにはどうするといったことは、一切記述されていない.このあたりを,シャープ側でどう対応するのかで,今後の行方が決定されるだろう.現段階では各サービスセンターの窓口で,ということになっている。
　また互換機にも通じる問題であるが,あるソフトが動かなかったときその責任はどこが持つのかといったことが明確にされていないと,結局泣きを見るのはユーザーである.今のところシャープ側では「ハードウェアとエミュレータまでは責任を持ちますが,アプリケーションのバグに関してはソフトハウスの方にお願いします」ということである.これはこれでもっともな言い分である.試しに,編集部で,リストアップされているソフトハウスに尋ねてみたところ,「PC-9801シリーズ以外の機種での動作は保証しかねる」という答えであった.これではユーザーは文句の持っていきようがない.やはり,シャープの方でこれこれのソフトはこうすると動作します,という情報をきちんと出すべきだろう.
ユーザー層
　 　ターゲットユーザーとして考えられるのは,従来MZ-2500を使っていた人で、そろそろ16ビットマシンが欲しいという人達だろう.この人達にとっては,今までのMZ-2500用のプログラムがそのまま使えるというのは大きな魅力である.また,MS-DOSを使えば,強力な言語プロセッサが数多く使えることになるわけで,そういった意味では大変お買い徳な機械である.ただ残念なことに,今日本で作られているソフトは、MS-DOS用といいつつもその実体はPC-9801用になってしまう.したがってビジネスに使おうとした場合は,アプリケーションの少なさに悩まされることになる.これを少しでも解決するために,エミュレータが添付されているのだろう.しかし,現段階ではまだメーカーも手探り状態といったところだもう少し時間をおいて,メーカーの方針が安定してから再度評価してみたい.

知人にMZ-2500で自作プログラムを仕事に使っていた人がいたが、16bitマシンはPC-98にした。自作プログラムはそのままMZ-2500で使い、ビジネスソフトはPC-98で使っていた。何が何でもパソコンは1台しか持たないという人以外にはMZ-2861を買おうとは思わなかっただろう。

Core Wars（月刊ASCII 1987年7月号12）

Core Wars 面白かった。こいうのが好きだった。将来自分でもCore Warsの猿真似プログラムを作りたいのでスクラップする。

コア戦争を始めよう
　“Core"は,1950年代の初めにMITで実用化された主記憶用の記憶媒体である.小さなビーズ状の磁心の中にワイヤを通した仕掛けであり,高集積度の半導体メモリが一般化した今日も,主記憶装置を“Core"と呼ぶことがしばしばある.
　Core Warsは,すなわち,コンピュータの主メモリ空間を舞台にした戦争ゲームである。
　その基本的な考え方は、あっけないほどシンプルなものだ.
　メモリ空間にA,B2つのプログラムが存在するとしよう.Core Warsのシステムでは,2つのプログラムが同時に実行される.これらのプログラムは,互いに相手のプログラムの動作をストップさせることを目的にしている.つまり,2つのプログラムを戦わせて,最後まで生きていたプログラムが勝ちとなる.
　他のプログラムの動作を止めてしまう(殺す)のは簡単である.そのプログラムの本体を,破壊してしまえばよいのだ.
　たとえば,相手のプログラムの命令部分に数値0の爆弾を落す.MOV命令を使って,即値データの0を相手のプログラムの存在する番地に転送してやればよいのだ.プログラムが破壊されていることを知らずに,その番地を実行しようとしたプログラムは,命令例外のエラーとなり,動作をストップするだろう.
　数値0爆弾を使うもっとも簡単なプログラムとして,図1の一寸法師(DWARF)がよく知られている.
　たかだか4wordからなるこのプログラムは,メモリ空間全体にわたって,5wordおきに数値0爆弾を投下していくものである.CoreWarsのメモリ空間は,通常のコンピュータのそれと異なり,もつとも高い番地(たとえば,7999番地)は,もっとも低い番地(0番地)に,サイクリックに連続している.つまり,8000番地は,0番地と解釈される.
　一寸法師は,こうして自分自身のいる番地の付近にも数値0爆弾を投下することになる.ところが,わずか4word足らずの一寸法師の本体は、ちゃっかり爆弾と爆弾の投下間隔の間に入っているので自分自身の爆弾を浴びることはない.
　一寸法師は,小さくても強力なプログラムである.何の対処もしていない“善良”なプログラムは,例外なくこの爆弾の雨の洗礼を受けてエラー終了してしまうことになるだろう.
　Multiplanも,一太郎も,dBASEも,他のどんな優秀なアプリケーションソフトウェアも,この短いアルゴリズムの敵ではない.
　Core Warsで勝つためには,プログラムは,“Warriors"に変身しなければならないわけである.
　そこでは、プログラムは生き物のように自己の存在を主張し,猛然と他のプログラムに攻撃を仕掛け,あるいは,メモリ上で繁殖しようとするのである.
　さて,Core Warsがマニアの間に知られるようになったのは,その考案者であるA.K.Dewdneyが,3回にわたってScientific American誌の彼のコラムで,これを紹介してからのことである。
　その中で,彼は,Core Warsに似たことは,現実のシステムにおいてもありうるし,これに似たエピソードの中からこのゲームを思い付いたと述べている.また,主記憶容量48KbytesのAppleから,ゼロックス社パロアルト研究所のネットワークシステムまで、さまざまなシステムに見られた,プログラムの興味深い振舞いについても紹介している.
　すなわち,Core Warsの思想的な背景は,まとまったプログラムを書いたことのある人間なら1度はイメージするであろう,1つの可能性についてのものである.
　それは,プログラムとは,機械命令とデータからなる原生生物であり,それ自身のための挙動を示すことができるといった意味合いのものだろう.

プログラム戦士を作るには
　Core Warsでは,A.K.Dewdneyの考えた架空のマシンのアセンブリ言語によって,競技用のプログラムを記述する.それは,表1のような命令セットを持った簡単なアセンブリ言語であり,REDCODEと呼ばれる.
　作られたプログラムは,REDCODEアセンブラによって翻訳され,架空のマシンの上で実行される(図2).そのシミュレータは,MARSシステムと呼ばれる.
　MARSシステムは,同時に2つのプログラムの実行される環境,つまり,疑似的なマルチタスキング環境である.
　また,MARSシステムは,ゲームの進行状況をコンピュータのディスプレイでモニタリングできるばかりか,そこで,簡単なデバッギングも行える.
　本誌では,今回のCore Warsの紹介に続いて,実際にCore Warsを楽しむために,REDCODEアセンブラと,MARSシステムを,誌上で紹介していく予定である.
　このシステムは,ICWS(International Core Wars Society:「ICWS日本支部開設のお知らせ」参照のこと)で提供しているものを移植する.
　すなわち,プログラム戦士を作りたい場合には,REDCODEの文法に従ってプログラムを書けばよいことになる.
　対応機種としては,9月号でPC-9801シリーズ対応版を作成するほか,これと同時かそれ以降で8bitマシンにも移植していく予定である.
　Core Warsの特徴のひとつは,REDCODEのソースレベルでマシンに依存しない点だろう.基本的に,他機種のユーザーともゲームを行うことができる.Z80 CPUのマシンで開発したプログラムが,80286 CPUのマシンで開発したプログラムを破る可能性も十分にある.
　このゲームに参加するプログラマは,MARSシステムという,まったく共通のシステム環境の前にいるわけである.
　ただし,MARSシステムのメモリ空間は,従来,8000番地までであったのが,現在,16K番地,32K番地,および64K番地までの3種類のモデルに拡張されようとしている.その結果,実メモリの小さなマシンでは,大きなメモリ空間のMARSシステムが,簡単に実現できない可能性もある.
　これは,小さなメモリ空間のMARSシステムでは,小さなプログラムの方が有利であり,レーダーや自己修復機能を持つような,シャレたプログラムが作りにくいためのようである.つまり,よりエキサイティングなゲームを楽しむためのマイナーチェンジといったところだろう.IBMPC用の64K番地バージョンは,現在,ICWSでデバッグ中とのこことである.

キリングプログラムの戦略
　それでは,具体的なCore Warsプログラムの素顔を,少しだけ見ていくことにしよう.
　先に,非常に短くて強力なプログラム,一寸法師(DWARF)を紹介した.これよりもさらに短くて,場合によっては、さらに強力なプログラムに小鬼(IMP)がある。
　このプログラムの長さは,実に1命令しかない!それは,次のようなものである。

		MOV		0,1

　REDCODEの文法に従うと,この1命令は,相対番地0の内容を,1番地先に転送することになる.つまり,小鬼は,自分自身を1番地先にコピーし続けるプログラムということになる.
　小鬼は,最大限のスピードでメモリ空間を突っ走る,はなはだ乱暴なプログラムである.このプログラムの通ったあとには,そのコピーが延々と残るだけとなってしまう。やがて,そのスピードにものをいわせ,相手のプログラムを頭から塗りつぶしてしまうわけだ.
　この小鬼への対抗措置として,A.K.Dewdney氏は,小鬼地獄(IMP PIT)と呼ばれるプログラムがあるとしている.それは,次のようなものだ.

	loop	MOV		#0,-1
		JMP		loop

　このプログラムは,即値の0を,1番地前に書き続けるというものである.-すなわち,小鬼がちょうど小鬼地獄の1番地前に自分自身をコピーしたタイミングで,小鬼地獄が1行めの命令を実行すれば、みごと小鬼をやっつけてしまうことができるというわけだ.しかし,このプログラムは、完全とは言えないようである.タイミングが1つずれるとやっかいなことになる.
　小鬼地獄が,小鬼に変身してしまうのだその場合,敵と見方の2重身小鬼となってメモリの中を走りはじめる.小鬼対抗措置としては,Small-C版のMARSシステムの作者であるKvin Bjorke氏によると思われる小鬼返し(ANTI IMP)という,次のアルゴリズムもある.

	init	MOV		#0,-5
	loop	CMP		#0,-6
		JMP		loop
		MOV		#0,-5
		MOV		#0,-6
		MOV		#0,-7
		MOV		#0,-8
		JMP		init

　CMPという命令は,第1オペランドと第2オペランドを比較して,等しくない場合に,次の番地の命令をスキップするというものである.すなわち,このプログラムは次のような動きをする.
　まず,1行めが実行されると,それよりも5番地前を初期化する.これに続く2行で,この番地が書き換えられたかどうかを監視している.もし書き換えられていたら,小鬼,あるいはこれに類するものが来たとして,適当な位置に数値0爆弾を4発ほど食らわせるというわけだ.小鬼返しはCore Warsの考案者の考えた小鬼地獄よりも防御がかたく,ゲームをドローにする可能性が少ない.
　しかし,この小鬼返しに対抗する手段も考えられている.それは,小鬼返し返し(ANTIANTI IMP)と呼ばれる次のアルゴリズムである.

	loop	MOV		4,@leng
		ADD		#1,leng
		JMP		loop
	leng	DAT		5
		MOV		0,1

　何のことはない、これはニセの小鬼で,その素性は一寸法師と同じものである.
　一寸法師といえば,こいつにはどう対処したら良いのであろうか?
　相手が,一寸法師と分かっていれば,一寸法師の数値0爆弾の隙間に入ってしまうか,あるいは,爆弾の落下位置の移動速度と同じスピードで自分自身を複写し,制御を移して行くといった類の手法をとれる.そうするうちに,一寸法師の本体を破壊してしまえば良い.
　しかし,このようなアプローチでは,それほど面白い変化は望めないだろう.
　実のところ,ここに現在のCore Warsの仕様の中で,もっとも興味深い部分が隠されている。

　それは,SPL命令による兄弟プロセスの生成だ
　SPL命令は,そのオペランドで指定した番地に兄弟のプロセスを発生させ,自分自身は,SPLに続く命令を実行し続ける.すなわち,1つのプログラムが,協力しあう2つのプロセスを持つことができるようになるわけである(図3).
　プロセスの数は、1プログラムあたり,最大64個を持つことができる.ただし,プロセスの増加に比例して、プロセスごとの実行速度は低下していくことになるので注意する必要がある.
　兄弟プロセスと実行サイクルの関係によっては,先ほどの小鬼返しも,小鬼に対して完璧な防御力を持つとは限らなくなってくるだろう.
　第1回CoreWarsトーナメントで上位にランキングされたプログラムは,いずれも,このSPL命令を巧妙に使ったものとなっている.
　たとえば,優勝を争った2つのプログラム,CHANG 1とMICEは,それぞれ異なるストーリーのもとに作られたプログラムである.
　CHANG 1は,典型的な戦闘型のプログラムと言えるだろう.それは,3つの兄弟プロセスによるエンジンを持っている.まず,小鬼地獄を本体の前面に防御用のシールドとしており,自分自身も後方に小鬼送出装置を用意している.そして,本体中央から数値0爆弾を効率よく発射するというものだ.
　これに対して,MICEは,わずか7ステップからなる非常に繁殖力のすぐれた,自己増殖型のプログラムであった.SPL命令によって,Core Warsプログラムは,生命力のようなものが,かなり重要となってきたようである.トーナメントの優勝は、次のようなちっぽけなプログラムがさらってしまったわけである(＜は,オートデクリメントのアドレッシングを意味する).

	go	MOV		#12,6
	loop	MOV		@-2,<5
		DJN		loop,-3
		SPL		@3
		ADD		#653,2
		JMZ		+5,-6
		DAT		833

　繁殖力とは逆の意味で,面白い動きをしたのが,次のPARASITEである.このプログラムは,メモリを検索して敵を探すように作られているが,いざ敵を見つけてからの動作は,なかなかユニークである.これは,言ってみればウイルスのようなプログラムである.どのような活動をするか追って見ていただきたい。

		DAT		#11
		DAT		#-2
	go	SPL		5
		JMZ		2,@-3
		SPL		@-4
		ADD		#1,-5
		JMP		-3
		JMZ		2,@-6
		SPL		@-7
		SUB		#1,-8
		JMP		-3

　A.K.DewdneyによるとCore Warsプログラムの次の世代は,環境を感じ取って、具体的な番地を直接攻撃するものであり,破損部分に対する自己修復を行うプログラムでなければならないという
　こうした趣向のプログラムも作られているが,Core Warsのプログラミングは,まだ,スタイルとして確立されておらず,MICEのようなシンプルなプログラムを有利にさせているようである.
　コーディングそのものは,積極的なコメントとラベル付けをすれば,普通のアセンブリ言語程度には書けるようになる.問題は,イマジネーションなのだろう.
　また,実際にREDCODEアセンブリ言語でプログラムを書き,実行してみると,このゲームの魅力の50%以上は,ゲームとしてどちらのプログラムが勝つかといった点ではなく,メモリ空間の上で,アルゴリズムがどのように振舞うかをモニタから観察する点にあることが分かる.
　Core Warsは,文字どおり「コア戦争」として,プログラム同士で熾烈な戦いを行うというベースを持っているものの,「コアの中でたわむれる」という要素も少なからず持っている.そのあたりに,Core Warsというゲームの課題があると同時に,他のどのようなゲームでも期待できない可能性があるのは間違いないだろう.
　より,戦闘的な,あるいは戦略的な,そして美しく、最後まで生き残るだけの柔軟性をそなえたプログラムは,どのようにして作られるだろうか.

1990年のコンピュータ環境 BTRON OS（月刊ASCII 1987年7月号11）

1990年のコンピュータ環境 BTRON OS のコラム記事をスクラップする。

TRONチップの開発状況
　TRONプロジェクトでは,同プロジェクトが提唱するアーキテクチャの能力を最大限に引き出すため,新たなVLSIマイクロプロセッサの開発を進めています.それが,「TRONチップ」と呼ばれるもので,マルチタスク処理やマルチウィンドウ処理などが,効率よく行えるための命令群が用意されています.
　現在,日立製作所(株),富士通株)および三菱電機(株)の3社が,共同でTRONチップの開発を行っています(各社の開発分担は,表1のようになっています).すでに,日立はエンジニアリング・ワークステーション向けの製品を,富士通はミニコン向けの開発をスしており,三菱はパーソナルコンピュータ向けの製品を開発することになっています.そして,これらのチップの総称として「GMICRO」(ジーマイクロ.Global MICROの略)の共通ブランドが使われることになっています.日立が発表しているH32/200の仕様を表2に示しました。
　このように,当初TRONチップは,データおよびアドレス・バスともに32ビットの仕様で登場してきます.しかし,TRONの基本仕様は、アドレス空間の拡大に対応できるように,アドレス,データ・バスともに64ビットまで拡張していくことを前提として設計されており,同プロジェクトは,1990年代には64ビットCPUを発表する計画を持っています.

64ビットCPUという単語に反応してしまった。歴史はTRONチップを抹殺した。まことに残念である。今使っている64bitはAMDが2000年8月に発表し、2003年4月に出荷したAMD64が基本でインテルがそれに乗っかったものだった。インテルは当初IA-64として8086の系譜とは互換性のないCPUを発表したが、結局8086系と互換性を維持したAMD64の軍門に下った。インテル32bitから64bitに移行するとき互換性を捨てるなんて手前遅いんだよ。どれだけインテルの互換性維持に素人プログラマは苦労した、呪っていたかわかってるのか。反省するのが遅すぎる。16bit化のときやってれや。8bit機のソフト資産なんて大してなかったのだから、16bitに移行する時が最大のチャンスだと思っていた。8bit機の価値あるソフトがあったとしても再コーディングすればよかったんだ。当時はその余裕があったはずだ。可能だったはずだ。

TRON OSのアクセスの管理とリアルタイム性
　TRONOSの概論的な部分から一歩踏み込んで,「アクセスの管理とリアルタイム性」についてインタビューしたので,以下に紹介します。
―――動的なデバイスの管理なんですが,非常に多くのタスクがあった場合,たとえば,あるタスクがRAMディスクを使い始めて,もう1つのタスクもRAMディスクを使いたいというときなど,アクセス権の設定の管理はどういうふうにしているんですか.
櫛木　RAMディスクを独占使用したい場合には,占有アクセス権が指定できますし,共有使用の場合は,通常のフロッピーのアクセスと同様に,ファイル管理でアクセスの管理が行われます。
　話は変わりますが,データやプログラムのアクセス管理ということでは,スーパーバイザーモードのデータやプログラムにレベル0,Iを与え,レベル0とIの中で,さらに重要性の高いものをレベル0で動かし,ユーザープロセスはレベル3で動かします(表).これによってマルチプロセスで動きながらも,レベルが違えば,お互いに領域を侵すことはありません.その意味での管理をしています.
　リアルタイム性を得るためのスケジューリングについては,OSはラウンドロビンとリアルタイムイベント駆動とを行っています。ラウンドロビンも行いますし,イベントがあったときには,イベントを優先してイベントキューに入れ,それでプロセスは起動されることになります.
　ですから,イベントは当然,ハードウェアイベントとソフトウェアイベントとがありますから,それで駆動されるプロセスは,形としてはリアルタイムの応答になるわけです.ラウンドロビンを行いながらも,リアルタイム性を優先して処理する.このあたりはUNIXなどになると,ラウンドロビンだけで割り当てを行っていますね.
――たとえば,マルチウィンドウでは,アクティブなプロセスが多数あって,さらにそれに対してイベントが起こるわけですね現在アクティブになっているウィンドウもあれば,イベント待ちのものもある.そういった部分の管理は,かなりたいへんなんじゃないですか.画面上でキーボードのイベント待ち状態になっているときにキーが押されると,イベントキューのなかにイベント待ちが入っていて……どれにイベントを振り分けるかとか,イベント待ちではなくタイマ割り込みが入ってきたときなどの管理は,どうなっているんですか。
安藤　キーボードとポインティングデバイスに関しては,会話権……これは,ユーザーと対話する権利ですが……が常時1つだけしか設定されていません。自分は権利を持っているというのをウィンドウマネージャから知らされるようになっているんです。その間は,ポインティングデバイスおよびキーボードは,自分のもので,どんどんイベントを取れる.
　OSのなかでは,キーの入力も1種のイベントであり,他のイベントと同じように管理しています.普通,キーボード入力でしたら,それを割り込みとしてだけ受け取って,プロセスを動かし出すという処理はしないOSもあると思うんです.それでも,最終的にはキー入力があれば,プログラムが動き出すことになっている.しかし,リアルタイムOSでしたら,キーボードから入力されると,すぐプロセスを呼び出すことになっています.そういった概念を,一般的な汎用OSのなかに取り入れているのだ,と思っていただいてかまわないでしょう。
――普通ですと,UNIX的なプライオリティをつけたラウンドロビンの状態があり,さらにイベントによる駆動があるみたいになりますね.そういうOS上でマルチタスクをしていると,1つのタスクのなかの非常にクリティカルな部分や,イベント割り込み中に,さらにイベント割り込みがあった場合にはどうするのか,というような部分のインプリメントは,たいへんですよね.TRONの場合,このあたりで,今までと、どのくらい違っているのですか.
安藤　キーボードやポインティングデバイスからの入力によるイベント待ちの解除も,ラウンドロビンも,スケジューラにとっては,Iつのプロセススケジューリングの契機として統一的に扱っています.したがって,その他のハードウェア割り込みと同様に,クリティカルな部分でも,排他処理や多重割り込みに対する処理も当然行われています.
　マルチプロセスではいろいろなプロセスが動いていますので,その他の要因,ファイルのI/Oであるとか,それに関する「待ち」の処理は,I/0が終われば、当然それで,I/0処理の間,休止していたプロセスを再起動するなど,プロセスのスケジューリングが行われる.そのへんに関しては一般的だと考えていただいてよいと思います.
櫛木　一般的ではありますが,考えられる限りの,よいスペックはほとんど取り入れている,と言えるんじゃないでしょうか。

ラウンドロビンバッファという用語初めて見たとき、凄く格好いいと思った。ミーハーなアマチュアプログラマだった私はどれほど素晴らしいものかと思ったが、普通だった。素直に考えればそうなるというものだった。

1990年のコンピュータ環境 BTRON OS（月刊ASCII 1987年7月号10）

BTRONマシンの開発者にインタービューした記事をスクラップする。


あおりをスクラップする。

BTRON OSの検証を進める BTRONマシンの開発者に聞く 松下電器株式会社 中央研究所 情報グループ 　松下電器産業が発表したBTRONマシンの実験機は,初めてTRONのアーキテクチャを実現したマシンとして,多くの人々に注目されています。今月は、その開発にあたった中央研究所の技術者に,開発状況と検証内容をインタビューし,技術者から見たTRONの魅力について語っていただきました.
　あわせて,32bit以降のCPUとして関心を集めているTRONチップの概要と,各社の開発状況をお届けします.
　90年代の技術を見越し,次世代の標準アーキテクチャを目指す「TRON」の現状と,今後の動向を探ってみましょう.

はてさてこの時点（34年前）ではTRONはどうだったのか。その後の展開をどう予想又は期待していたのかスクラップする。

――3月に発表されたBTRONマシンの実験機の検証内容と,BTRONのOSの一般的な話という,この2点を中心にうかがいます.
　とりあえず,今回の実験機の目的というか,検証の目的は何だったんでしょうか.
櫛木　BTRONの機能確認ですね.OSの核部,外核部を実際に作ってみて,性能がどのくらい出るか,実際に,メモリサイズ,それからハードウェアの管理において問題がないのかという,もろもろの機能確認をしようというのが目的です.キーボードについても,実際に使ってみての評価をするつもりです.
286の相性と開発環境
――今回搭載した80286CPUとBTRONとの相性はいかがだったんでしょうか.
櫛木　メモリサイズなどで問題になるかな,という懸念もあったんですが,64Kバイトの壁をクリアするように,ラージモデルをサポートできるコンパイラを作り,OS核でも64バイトを超えるデータをサポートできるようにしました.そういう意味からしますと,大きな問題もなく達成できたのではないかと思っています.プロテクトモードなどの使い方についても,BTRONOSとの相性は一応評価できたな、というところです.
　ここで,16ビットと32ビットの差がどこに出るのかということになりますと,1つの問題は,イメージデータなどの大きなデータを扱うと,それだけで64Kバイトを超えてしまうという点です.つまり,連続データで64Kバイトを超えた場合には,286ではプログラムが複雑になってしまうという問題が残っています.これは,今後の課題の1つですね.それから,Lispなどを動かそうとすると,1セグメント64Kバイトの壁,または,16Mバイト空間という制限は,苦しいと思います.これは,一般的に16ビットと32ビットの能力差で,BTRONだからという問題ではないですがね.
――開発の手順は,ハードウェアの設計,コンパイラなどの環境部分の作成,そしてOS部分の作成,という3つが同時に進行していたわけですか.
櫛木　そうですね。だいたい同時進行でやっています。
――開発は,ミニコンなどを使って,クロス開発のようなかたちで進められたんですか。
櫛木　開発システムは,UNIXをベースにしたシステムの上に,クロス開発環境が使えるようになっています.UNIXの上に,Cのクロスコンパイラ,アセンブラ,リンカ,これの標準ライブラリなどを作り,開発マシン上でコンパイル,リンクを行い,それをダウンロードして実験機に持ってくるという方法をとっています.
　当然,セルフにも持ち込めるようにはしていますが,やはり,OSを開発するとなると,能力的に実験機では苦しい.一般に,パソコンで使っているハードディスクでは,やっぱりスピードが遅いわけです.リンクやコンパイルをするのに時間がかかりますから、そういうものは,クロス系で開発しています.
――メモリ管理などは,286のプロテクトモードをそのまま利用しているんですか.
櫛木　そうです.
――画面関係ですが,特別にデバイスを作ったというようなことは……
櫛木　メインに使っている石は,DPUと呼んでいますが,MN8355です.これは松下電器で開発したもので,松下電子工業から発売しているものです.主にBitBltなどのVRAMと,メインメモリ間のメモリ転送を高速にするためのディスプレイコントローラです。独自に,8355を強化するような若干のゲートアレイは追加していますが,特殊なハードウェアを使っているわけではないんです.
――今回の検証の際に,TRONチップの搭載を想定していましたか.
櫛木　TRONチップに対して,出せる範囲での要求は出すようにはしています.しかし,OSの検証という作業から,CPUに対して特殊なスペックを要求するということは,それほどないんじゃないかと思っています.
　ただ,実際にいろいろな検討がなされているなかで,何がいちばん脚光を浴びる機能として採用されるかなど,まだ予断を許さない部分はあるんです.

何か所か専門用語に脚注があったが、それは省略した。34年前は知らなかったが、今は知っている用語だし、ググれば済むことだから省略した。

BTRON OSの特徴と従来OSとの違い
――BTRONOSは,UNIXなどとかなり違ってくると思うんですが,いちばんの違いはどういうところでしょう.
櫛木　いろいろあるんですが,まず,日本語処理などの言語処理機能をOS内部に組み込みました.これによって,言語に依存する処理は統一されます.
　ご存知のように,TRONでは「実身/仮身モデル」というファイルシステムを採用しています.これは、言ってみれば,ネットワーク型のファイルシステムです。一方,UNIXやMS-DOSは,ツリー型の階層型ファイルシテムですから,ここが最大の相違点です.
　また,OSの核自身は,マルチタスクでリアルタイム性を備えています.現時点で発売されているMS-DOSやUNIXの標準バージョンでは、達成されていないことですね.
　マルチウィンドウが,実身/仮身モデルにフィットした形となっているのも,TRONの特徴でしょう.
　BTRONのウィンドウはマルチアクティブになっており,クリッピングが非常に難しくなります.そのため,ウィンドウシステムとグラフィックの描画システムとが互いにリンクして,クリッピングする領域を間違いなく実行できるようになっています.たとえば,他のウィンドウがかぶさった部分には書かない,というように,他のウィンドウがかぶさっていない変則多角形のなかだけに書く,という機能……クリッピング機能を持っているわけです.
　ですから,ウィンドウシステムそのものも,実身/仮身モデルや描画システムとかなりリンクしています.
　MS-DOSですと,MS-WindowsとMS-DOSが分離されていて,ウィンドウのなかに,マルチタスク機能から,描画システムから,全部入ってきますね.これに対してTRONでは,OSとして持つべきマルチタスクの機能と,リアルタイム機能を持ちながら,ウィンドウが独立して,描画システムと連繋している.そういう意味では,自然な形態なんです.
実身/仮身モデルとウィンドウシステム
――実身/仮身モデルとウィンドウシステムとの関係を,もう少し詳しく紹介してください.
小林　実身/仮身モデルによって表示されるウィンドウの構造は,かなり複雑になるんです。単なるオーバーラップウィンドウではなくて,オーバーラップしているウィンドウのなかに,仮身が入っています.さらに,その仮身をウィンドウを通して開けるので,ネスティング構造を持ったウィンドウシステムという性格を持っているんです.
　もう1つの特徴は,リアルタイムOSですので,階層構造を持つウィンドウにおいて,同時描画をどうやって行うかという点が,いまいちばんの問題となっています。
　いままでのウィンドウシステムと比べて,新しく考え出されている点は,マルチウィンドウに同時描画とネスティング構造を加え,かなり複雑なクリッピングも行うという機能です.一体化したウィンドウとして,しかもスピードの落ちないシステムを作るというのが,最大の課題だと思います.
――具体的には,描画プロセスみたいなものが並行して動く,という形態になるんですか。
小林　各プロセスごとに独立していて,各ウィンドウに対して描画する,という作業が可能です.
――OS側で何か書けという命令がプログラムから来たときに,プロセスと描画システムとの間で,どういう形でデータの受け渡しを行っているのでしょうか.
小林　イベントの流れで,だいたい処理ができるようになっています.実際は,「描画環境」というものが,1つ1つのウィンドウごとに設定されていて(図1),これがクリッピング関係のすべてと,TRONの場合はカラー表示ができますので,カラー属性,線属性などの情報を持っています.
　各アプリケーションは、描画環境に対して同時に指令を与えれば,自分の持っているウィンドウに対しては描画できる.ただ,各アプリケーションは,どういうふうにウィンドウが動いているかは知りませんので,ウィンドウマネージャで,それぞれのウィンドウ環境を全部設定してあるわけです。
――つまり,不定型の領域でクリッピングするということですね.これは,なかなかたいへんだったんじゃないですか.Sunワークステーションなどですと,矩形に分割して,その組合せでクリッピング領域を構成していますよね.
小林　実際は,それに近いのですが,TRONでも,矩形に分けて,その小さくなった矩形ごとに描画していきます.ただ,速いので見えないんですが……
――TRONの場合には,あるウィンドウのなかに入っているウィンドウは,その親となるウィンドウからは出られないとというようなことはあるんですか.つまり,ウィンドウ位置の制限みたいなことですが、
小林　それは,あります.子供のウィンドウは,親のウィンドウから出ることはできません.親のウィンドウの枠より外の部分は見えなくなりますが,拡大することはできます. ――親のウィンドウでクリッピングされるということですね.
小林　そうです。
――ウィンドウ間のカット・アンド・ペーストみたいな機能は,ウィンドウマネージャで行っているんですか.
小林　トレイ管理機能(表1)というのがあるんですが,それは一応,各プロセス間で共有できるようになっていますので,任意のプロセスから蓄えられたデータを取っていくことができます.これによって,カット・アンド・ペースト機能のようなものを実現しています.
――このトレイというのは,いわゆるクリップボードみたいなものですね.
小林　そうです.カット・アンド・ペースト機能を実現するには,クリップボードとか,カットバッファとか,いろいろな手法がありますが,TRONでは,現在,スタック方式を考えております.
――場合によっては,ウィンドウが複数のタスクから同時にアクセスされることがありますよね。
小林　その可能性はあります.
――トレイによるデータ交換は,人間が操作する以外にも,タスク間でこれを使うということはあるんですか.
小林　ウィンドウ間のデータ転送は,だいたいは人間の操作に基づくものだと思います。
――ウィンドウ内の基本機能と言いますか,ウィンドウのなかでの簡単な行エディットみたいな部分……バックスペースのときの字詰め,スクロール……といった機能は,ファンクションコールレベルで用意されているのですか.
櫛木　外核機能のなかに、1行のラインエディット機能は入っています.ですから,かな漢字変換も含めて,たとえばグラフのなかに文字列を埋めるという程度のことは全部,ファンクションとして用意しています。ところが,ワープロクラスになって,書式設定もする,頁変えもする,ヘッダーやフッターをつけるということになると,基本文書エディタレベルの話になってきますね。
――いわゆるウィンドウマネージャは、OSの1つ外側のユーザーのアプリケーションと,OSのカーネルの間に入るようになるわけですね.
櫛木　そうですね.ユーザーとカーネルの間ですけれども,ウィンドウは,ソフトウェアの構成上,外核部のなかに入っています(表1).そして,その上にユーザーアプリケーションがきます.システムアプリケーションは,UNIXで言えばviとかshellにあたる,基本エディタやTACL(タックル)がここに入ります。

実身/仮身モデルへの期待
――実身/仮身モデルですが,具体的にどうやって実現しているのですか.
櫛木　このモデルのインプリメンテーションについては,次回の研究会ぐらいに,きちんとした報告をしたいと思っています。
――やはり,このファイルシステムは,パフォーマンスという点からして,今回の開発においてかなりの比重を占めていたんですか.
櫛木　むしろ,比重は,開発よりも検証のほうにあります.実身/仮身モデルは,ネットワーク型のファイルシステムで,非常にユニークなものなんです.それが,ワープロとかOAシステムにおいて,どのように使われていくのかという点が,興味ありますね.そういう使われ方の検証と,それに付随してくる問題点,それ以外にスピード,ファイルシステムそのものの信頼性,などの隠された問題があります.そういった意味で,いま作業を進めています.
――作られた立場からの印象は,どうなんでしょうか。
櫛木　実身/仮身モデルをテストしている段階では,おもてに見える機能がおもしろいなと思いました.また,使い勝手として、文章を作るとか,論文を作るとか,文章のアーキテクチャを作っていくという面ではおもしろいなと思っています.実際,早く使ってみたいですね. ――私たちも,そういうところに注目しています.文章を作っているときは,「参照」という作業が多いんですね.たとえば,あるところを訂正したら,参照したところを全部直したい.こういうケースは,実身/仮身モデルだと簡単に解決できそうですね。でも考えていくと,ファイルの中に他の1つの実身の中に他の実身を指すようなポインタ(仮身)があるというような形では,たいへんじゃないかという印象もあるんです.それから,いちばん元の実身を削除した場合にはどうなるのか,つまり,その段階では実身なり仮身なりをどうやって探していくのか……インプリメントの段階で,このあたりは問題になったんですか.
櫛木　ソフトウェアのアーキテクチャをどう構成するかについて,いろいろと検討しました.最初のアルゴリズムがうまく動いてくれればよいのですが,だめだったら,アルゴリズムそのものを作り変えるということになります.そういう意味で,研究会に報告する前に,いろいろな検証が必要だと思っています.
デバイスファイルの取り扱い
――いまのウィンドウの話に関連したことですが,デバイスファイルという形で,機器やデバイスをまとめていますね.アプリケーション側から,そのデバイスはどのように見えるのでしょうか.UNIXでも,デバイスはデバイスファイルという形になっていて,そこにウィンドウシステムが入ってくると,1つのディスプレイをウィンドウデバイスみたいな形で扱う形式になっていますが,TRONでは,デバイスはどういう形になっていて,どのように管理されているのでしょうか.
安藤　現在は、デバイス名でデバイスをオープンし、そのデバイスへコマンドを送れたり,アクセス権の管理などができます.これらの管理は、デバイス管理部が行っています.また,ダイナミックローディングの機能もありますので,新しいデバイスが加わった段階で,OSが走っていながら,デバイスドライバをローディングしてこられます.そういう意味では、任意の時点でハードウェア構成が追加されても,それに対応することができます.
――動的な機器構成の変更ができる.たとえば,応用プログラムの使用時だけに,RAMディスクを設定することなどが可能であるというわけですね.
安藤　結局、ある時点でダイナミックに指定して,RAMディスクのデバイスドライバを呼び出してくることができるので,可能だという意味です.
――この場合,あるデバイスを,特定のプログラムからしか見えないようにする,といった管理まで行えるのですか.
安藤　ええ,可能です。
――要するに,ある特定のタスクにのみ使えるデバイスみたいな形で,制御できる.
安藤　それも可能ですけれども,オープンにすることも当然できます.
――そうすると,UNIXに非常に似た機能を持っているなという感じなのですが,デバイス管理の具体的な相違点というと,どのあたりになるのでしょう.たとえば,UNIXのデバイスは,どのデバイスも一応ファイルシステムであり,同じように見えますね.一方,TRONでは,デバイスを特定のタスクからしか見えないようにすることもできる.UNIXの場合,いわゆるデバイスのアクセス権を,個々のタスクごとに設定したりしなくてはならないわけですが,TRONは,どういうふうにしているんですか.デバイスの構成に応じたファンクションコールが設定されるみたいな……
安藤　そうですね.デバイスに応じたI/0要求を,個々に出すことができます.したがって,特殊なデバイスであるとか,追記型ディスクであるとか,いろいろなものへの対応が可能になります.
――いわゆる仮想デバイスみたいな,たとえばフロッピーディスクとハードディスクを同じように見るとか,複数のボリュームを1つに見立てるというようなことも可能なんでしょうか.
櫛木　特に,「仮想デバイス」という用語を使っているわけではありません.そういうふうに機能を拡張することは,将来あるかもしれませんが,現時点では、とにかくアプリケーションは,システムコールを使って書く.そして,システムコールの下には,当然,それに相当するファイルシステムやデバイス管理システムがあるという構造になっていますから,そのなかで仮想にするかどうかは,現在検討中です。
――先ほど話題になっていた動的な機器構成の変更についてですが,これは,BTRONの仕様ということですか.
安藤　仕様上は動的な機器構成の変更ができるということになっているのですが,これらはインプリメントに依存しており,これはおもしろい機能だということで,設計時につけ加えたわけです.
――BTRONのインプリメントによっては,こうした動的な機器構成ができないので,あらかじめやっておくという場合もあるわけですね.
安藤　そういう,普通のコンフィグレーション方式もあります.
――坂村先生が,ICカードに個人のデータを入れておいて,それをマシンに入れれば、どこでも同じようにTRONが操作できると言われたのは,そういった部分も含めてということなんですか(本誌6月号「姿を現し始めたTRON」を参 照).
櫛木　そうですね.そういうことも関係してきますね.
　ですから,たとえば,ICカードでコンビネーションを構成するというのは,ICカードでコンビネーションの情報を読み込んで,その内容に応じてデバイスドライバを選択する,というようなことが起きてくる場合があります.もちろん,そういう場合は,それが実現できるように,核部を作っておかなければなりません.

TRON坂村健氏インタビュー（月刊ASCII 1987年6月号6） 「姿を現し始めたTRON」
今読むと大体雰囲気が分かる。34年前はチンプンカンプンだったはずだ。知らない用語を調べ解説を読んでも理解できないことがかなりあった。話は変わるがパソコンがマイコンと呼ばれていた頃知人はフラグという用語がピンとこなかったと言っていた。フラグ＝旗　なのだが、それがCPUの処理結果に係る状態を示すものだと理解するまでハードルがあったと言っていた。コンピュータ用語にはそういうところがある。私はダンプリストがそうだった。ダンプカーが積み荷をドシャーと一気に下すように、メモリの内容を一気に吐き出すということだったのかと理解するまで時間がかかった。なにぶん、私たちは素人、趣味でパソコンを触っていたのだからこういうことにもなるのだ。

BTRONの持つ開発環境
――今回,開発用にCコンパイラを作成されましたね.今後,BTRONで具体的にアプリケーションを開発していく場合にも,Cコンパイラは標準的なものになると見ていいんでしょうか.
櫛木　まあ、いまのところはそういう進み方ですね.坂村先生は,次に新しいシステム記述言語を開発なさる意向のようです.しかし,先に何か使えるランゲージプロセッサがないと仕事が始まりませんので,とりあえずCを使うことになっています.もともとUNIXとかCについては,開発マシンとして使おうということになっていましたし……
安藤　ご存じだと思いますけれど,開発用に作ったCコンパイラでは,データアクセスなどで,farやnearを使い分けており,24ビットまでアドレス空間を広げられます.ところが,すべてをラージモデルというか,大きなアドレスにするとパフォーマンスが落ちて,その結果,アプリケーションプログラムに少々負担がかかるんです.しかし,場合場合に応じてアドレス空間の幅を考えながら,小さな空間であれば、頻繁にアクセスするデータはデフォルトのデータセグメント上に置くというように,プログラムレベルで工夫しています.
――アプリケーションになった場合,最初のうちは小さい絵や文書も,継ぎ足していくうちに大きくなって64Kを超えてしまう場合もあるでしょうし,実身と仮身をどんどんつなげていけば,印刷する際に,全部展開しなくてはいけなくなるほど,非常に大きなデータになってしまう.このように,データは動的に大きくなったり、小さくなったりすると思うんですが,そのあたりはCコンパイラで十分対応しきれるのでしょうか.
櫛木　OSとか外核部を作る段階で,ユーザーのデータを直接触るというケースは,比較的少ないと言っていいでしょう.
　OSの核部と外核部が使うデータのサイズは,だいたい分かりますので,ある程度,そのサイズを予測したうえで作ります。
　アプリケーションプログラムでは,かなりの量のイメージを扱うといったような場合には,farでデータを参照する確率が高いですね.
――共有ライブラリについて伺いますが,これは,複数のタスクからライブラリ部分を共有する.要するに,プログラムという単位とは別に,ライブラリ部分だけ別に置くということですね.
安藤　はい,そうです.

メモリモデル懐かしい。こんなものに注意を払わなければプログラムが書けなかった。プログラムを使っていて80286憎しと怒りがフツフツと沸いてきた。黙ってリニアな1Mを俺に寄越せやこの野郎と思いながらプログラムを書いていた。どんなメモリモデルがあったか調べてみたら
TINY　コード＋データが64Kbytes以内。これは使うことがなかった。
SMALL　コードが64Kbytes以内、データも64Kbytes以内。それぞれ別セグメントを使うので合計128Kbytesまでのプログラムを作れる。
COMPACT　コードが64Kbytes以内、データが64Kbytes以上。これはコードは1つのセグメントしか使えないが、データで複数のセグメントが使える。私は、もっぱらこれでプログラミングしていた。画像データを扱っていたのでデータ領域は大きいのが必要だった。昔々8bit機のころからシミュレーションとかしたかったので目的のプログラムを作る前にデータを圧縮することばかり考えていた。当然、目的のプログラムは完成しなかった。
MEDIUM　コードが64Kbytes以上、データが64Kbytes以内。コードに複数のセグメントが使える。データは1つのセグメントしか使えない。一体どんな用途のプログラムにこれが必要だったのか分からなかった。
LARGE　コードもデータも64Kbytes以上。コードもデータも複数のセグメントが使える。ただし、配列変数のサイズは64Kbytes以内。
HUGE　コードもデータも64Kbytes以上。コードもデータも複数のセグメントが使える。配列変数のサイズは64Kbytes以上でも良い。でかい配列を使う（今から思えば64Kbytes以上の配列がでかいとは昔はなんと貧弱な機械を使っていたのだろうか。今から思えば絶望的になる）
以上が私が知っていたメモリモデル。それ以外に
FLAT　プロテクトモード(32bit)用のメモリモデル。コードとデータが同一のセグメントを使用する。Windows用だとのこと。これは、使ったことがなかった。まあ、Windows用のプログラムを作ったことがないのでしょうがない。フラットなメモリ空間にはあこがれていた。
とにかく80286という腐れCPUは速いプログラムを書くには適していないCPUだった。これも互換性の呪縛によるものだった。もっと早くに8080互換性を諦めれば良かったのに。歴史は私の気に入らない方向に進んできた。

技術者からみたTRON
――技術者の方から見て,TRONを開発することには,どういうメリットがあるんでしょうか.
櫛木　一言で言えば,新しいOSをつくるという機会は,そんなにないと思うんです.そういう意味では非常にありがたい経験ですね。もちろんオリジナルで,自分で勝手に作って自分で使う分には,それは経験できると思うんですが,TRONの場合は,「世の中の標準」という目標があるわけで,その意味で,意義を感じています.
特に,BTRON全体が特徴にしていることですが,マルチメディア対応にしていかなければいけないいままでのOA用のOSは,8ビットや16ビットのキャラクタを扱うことが中心のOSですから,マルチメディアに対応をターゲットとしては考えていなかったわけです.
　それから,操作の標準化を行うという点でやりがいがあります。われわれ開発者は標準化のあるべき姿を分析し,必要な部品を抽出したうえで,それにトライしていかなければなりません.
　あと,実身/仮身モデル.これは,ユーザー側から見れば、妥当なファイルシステムだと思うんです.
　従来の階層構造システムというのは,1つのマシンを複数の人が使ったときに,そのディスクのうち,ここは私の領分,そこまではあなたの領分ですから,ここからそっちは侵しません,という約束が必要となり,このファイルシステムが作られました.こういう形態は,UNIXが代表的ですね。
　UNIXはマルチユーザーシステムですから,ユーザー間でディスクを共同利用するために,ファイル管理システムが作られたのです.
　ところが,このような今までの階層構造システムに対して,実身/仮身モデルは,人間の発想を,もっと機械の側から助けてやろうという考えに基づいたファイルシステムなんです.
　そういう意味では,われわれ自身がユーザーの視点を持ち,本当に欲しいOSを作ろうという立場でやっていると思うんです.そこがある意味で,技術者冥利に尽きると言えますし,ユーザーの視点に立っていることで,真のユーザーとしてのアイデアを入れる余地が無数にありますね.そこが魅力だと思います.
小林　マンマシンインターフェイスを作成した者の立場から言いますと,いままでのOSと違って,TRONのスタンディングポイントは、使う人の方にあるんです.いままでのOSを見ると,UNIXもMSDOSもそうでしたが,パソコンを使っている人たちや、システム設計者,アプリケーション開発者の立場に立ったものが多かったんです.
　TRONは,そのような立場から一歩前進したと言うか、ユーザー側に向かっているコンセプトのOSで,これはおもしろいなと思いながら作っています.

今後の展開
――今回の検証は、どの段階で一段落つくのでしょうか。
櫛木　BTRONマニュアルが正式に発売されるときには,「検証」という役目は当然終わっていることになりますね.ただ,ソフトウェアの内部構造は,いろいろ改良していかなければならないでしょう.
――今回の実験機では,コミュニケーション関係の機能は装備していないようですが,次回は,まずコミュニケーション関連の搭載ということになりますか.
櫛木　いろいろ目白押しじゃないでしょうか.システムアプリケーションもありますし,コミュニケーションもあります.実際の基本的な応用ソフトについても,まだこれからです.いろいろ取り混ぜて,たいへんですね(笑い).
――具体的に,今後の見込みですが,アスキーの読者がBTRONのマシンを触れるというのは,どれぐらい先のことになるでしょうか.
櫛木　これは難しい質問ですね.今のところ,未定なんです.
――だいたい,これから3年ほどありますが、90年代というようなところでしょうか.坂村先生は,本誌のインタビューで,この秋ぐらいからマイクロBTRONで展開……
と言われているんですけれども.
櫛木　そういうムードが高まってくると,事業をする側も早い時期に乗り出す可能性が強くなるわけですね.TRONは,まったく新しいもので,アプリケーションも用意されていない状態からスタートするわけですから,いろいろな工夫をしないと,なかなかしんどい.正面切ってドーンといくわけにもいかないんです.世の中の情勢とか,どのぐらいムードが高まってきたかとか,マイクロBTRONが出たとか,いろいろな要素で決まっていく問題だと思います.
――いま、松下電器さんでは、社内的にBTRONの開発はどのような意味づけで進められているのですか.たとえば,基礎研究の意味あいが強いとか,それとも半分くらいは応用研究のつもりとか,そのあたりはどうですか.
櫛木　どちらも並行に進んでいると言えます.プロジェクトとしては非常にユニークな動きをしていますね.UNIXは,AT&Tの研究室で出来上がってきたし,MS-DOSは,IBMの基本OSに採用されたということで,ビジネス・オリエンテッドの方向で仕様などが決められてきましたね.その点,TRONは,最初にマルチクライアントな呼掛けと動きがあって,まずITRON*18が,電子協*19のマイクロコンピュータ技術委員会から出てきた要求書に基づき,坂村先生が中心になって、動き出したわけです.
　メーカーと大学の産学協同でいきながら,アカデミックな発表と規格を合わせてやっていきましょうということで,メーカー間の整合をとる技術委員会的なものが,産学協同の方向と並行して動いていますね,学会発表込みで、なおかつ,TRON協議会という組織が並行に動いているでしょう.これは,いままでにない動き方じゃないでしょうか.
　こういう技術が生まれる条件というものは,いろいろなものが壁になってしまい,いまや純粋に技術だけで動かされていく状況じゃないですからね。たとえば,UNIXやMS-DOSの将来はどうなるの・かという問題もあるでしょうし,逆に,MS-DOS,UNIXに対する不満という力も働くわけです.つまり,いろいろな要素が絡み合ったなかでの動きということになっていくのじゃないでしょうか.
――産学協同の役割分担は,どういうふうになっているのでしょうか.
櫛木　TRONのコンセプトとアーキテクチャ,仕様は,坂村先生が提唱されて,その後,基本コンセプトに添った仕様になっているかどうか,という見方で,チェックしていくわけです.ビジネスと結びつけるのは企業サイドの仕事になります.
　建物でいうと,建築デザイナーがいて,建物を作るときの構造計算から,材質は何にするという部分は,各建築会社が担当するわけでしょう.そのあたりに,商品化の中心があるわけです.そういう意味ではお互いに補完し合って,私どもも坂村先生の持つ,ユーザーオリエンテッドな見方とアカデミックな追求姿勢に賛同してやっているわけです.また,先生のほうも、メーカーサイドが持っている,作る過程でのノウハウとか,仕様のコンセプトに影響させなければいけない生臭いポイントについては,当然吸収していかれるわけです.そういう意味で,先生の力は非常に大きいものがあります.
　現在では,TRON協議会でTRONに関連する様々な技術移転や普及促進も行っています。産学協同のよい見本ではないでしょうか.
　――きょうは、どうもありがとうございました。

BTRON触りたかった。どうして、私たちの目の前にBTRONが出てこなかったのかスクラップを続けると分かる記事が出てくるかも。全く記憶していないから自然にフェードアウトしたのだろうか。

1990年のコンピュータ環境 大容量FDD 他（月刊ASCII 1987年7月号9）

特集「1990年のコンピュータ環境」から周辺機器の記事をスクラップする。


34年後から見ると、なんでFDD？と特集記事が的外れと思ってしまう。予測とは難しいということが分かる。

実用段階に入った大容量FDD　10Mbytesも2～3年以内に製品化
　1957年に,米国IBMが世界で初めて開発したコンピュータ用のディスクドライブは,その後,30年間で記録密度が1万倍以上に達し,その密度は現在も着実に更新されつつあります.
　中でも,IBM規格以外のサイズだった5.25/3.5インチのフロッピーディスクドライブ(FDD)とメディアの隆盛には,目をみはるものがあります.一昨年までは,16bitマシンの5.25インチFDDの容量は,640Kbytesが上限でしたが,現在では,1～1.6MbytesのFDDが,標準で本体に内蔵されるようになってきています.
　3.5インチFDDでは,2Mbytesのものがサンプル出荷の段階を迎えており,これも1～2年以内には標準的なFDDとして位置付けられることになるでしょう.現在,開発中もしくはサンプル出荷中の3Mbytes以上の大容量FDDは,表1に示した各メーカーが,実用/試作段階を迎えていますが,本稿では,特に記憶容量が10Mbytes以上の3.5/5.25インチFDDに焦点を絞って,その製品化の可能性を見てみましょう.
　10Mbytes以上の大容量FDDは,1Mbytes当たりの単価が1万円以下の低価格なハードディスクドライブ(HDD)が出現し始めた頃から,HDDのバックアップ用機器として,見直そうという風潮が顕著になってきました.加えて,OS/2といった新OSが,80286CPUの全アドレス空間をサポートしているため,大規模なアプリケーションが,より身近なレベルで検討されるようになってきたことも無視できません.こうした大容量FDDが要請される背景を,図1に示してみましょう。
　ここで注目されるのは,やはりソフトウェアの提供媒体としてのメリットや,HDDのファイルバックアップ媒体としての有用性でしょう.たとえば,PC-9801用のLotus1-2-3は,現在,1MbytesのFD4枚で1パッケージになっていますが,大容量FDを利用すれば,それを1枚の中に収納できることになります.また,20MbytesのHDD用バックアップ媒体として10Mbytesの大容量FDを使用すれば,2枚のFDにすべてのデータをバックアップできる可能性が出てきます.
　ユーザー側から大容量FDDを見た場合の可能性は,上記のように十分考えられるのですが,その製品化には,まだ時間がかかりそうです.表1の中で量産段階に入っているFDDは,小西六写真工業の「コニカ10MBフロッピーディスクドライブ」(量産開始したのは今年4月,図2)だけで,ほかは開発中ないしは試作段階のものです.しかし,「実際の製品化は2～3年以内に」というのが,各メーカーのスケジュールになっていることは間違いないようです.では,製品化に際して,現在問題になっている技術的な要素には,どのようなものがあるのでしょうか.
「」

「PC-9801用のLotus1-2-3は,現在,1MbytesのFD4枚で1パッケージになっていますが,」4枚なんて生やさしいものではなかった。Windows3.1は14枚（http://wakentoyamatopc.web.fc2.com/pc/04os2_windows3.html）あった。ユーザは何枚ものFDを入れることは普通のことでFDの大容量化は望んでいなかった。そういえば、与太話と（本当かどうか分からない）して聞いたことがあるがおかしな上司がいてFDは信用できないから読めなくなったときの被害を少なくするため640Kbyteの2DDを使えと指示されたそうだ。2DDは速度も遅くて使いたくなかった。別にこの与太話がユーザはFDの大容量を望んでいなかったという根拠にするつもりはないけど。FDは読めなくなることが結構あったから、信用できなかった。必ず、バックアップを複数取っていた。

10MbytesFDDに求められる技術
　図3は,10MbytesFDDに必要な技術的要素を,1.6MbytesFDDと比較して示したものです.特徴的な技術を,いくつかピックアップしてみましょう.
(1)　磁性体はCo-γ-Fe₂O₃かメタル
　まず,使用するメディアは、既存のCo-γ-Fe₂O₃を磁性体に使ったものではなく,Baフェライト,あるいはメタルを使ったものが必要になってきます(図4を参照).
　FDの容量を単純に上げるには,最大線記録密度,あるいはトラック密度のどちらかを上げる必要があります.どちらか一方を2倍に上げると,記録容量も2倍になるわけですが,Co-γ-Fe₂O₃を使うと,最大線記録密度の上限は30000bpiになってしまいます.ところが,ほとんどの10MbytesFDDは,最大線密度が30000bpiを越えるため,Co-γ-Fe₂O₃を使用できないのです.
　その上,Co-γ-Fe₂O₃は,保磁力がHc=600～650Ｏe(エルステッド)という限界があって,高密度記録に適していません(表2の磁性体の比較を参照).その点,Baフェライトやメタルは,保磁力がHc=750～1500Ｏeというように高く,磁化方向が媒体面に対して垂直方向に配置されているため(既存のCo-γ-Fe₂O₃では水平方向の長手記録),高密度記録に適しているわけです(図5を参照).Baフェライトやメタルなどの垂直磁気磁性体では,3.5インチFDで換算して,50Mbytesまでの記録が計算上では可能とされています.
　ただし,問題点がないわけではありません.Baフェライトは,保磁力の減衰を遅らせるような処理をすると,耐久力が急激に落ちてしまいます.またメタルは,保磁力がHc=1000～1500Ｏeと高すぎるため,データを書き込むための磁場反転が容易にできません.
　こうした問題点を解消しない限り,10Mbytesの3.5インチFDDで,Baフェライトやメタルを磁性体として使うことはむずかしいとされています.前出の小西六写真工業の10MbytesFDDのメディアサイズは5.25インチですから,最大線記録密度も18000bpiと低くなっており,従って磁性体もCo-γ-Fe₂O₃を採用して,上記の問題点を解消しています.
(2) 磁気ヘッドはMn-Znフェライト
　磁気ヘッドは,Ni-Znフェライトを使ったものから,Mn-Znフェライトを使ったものへと移行しつつありますが,実は,前出のメタル磁性体とMn-Znの相性があまり良くないのが欠点になっています.このため,メタル専用のヘッドは,各社が開発中ですが,現在のところ本命視されている材質はないようです.Baフェライトの場合は,Mn-Znフェライトヘッドで対応できます.
(3) ヘッドの位置決めはセクターサーボ
　既存のFDのトラック密度は,だいたい135tpiどまりですが,大容量FDのそれは,ほとんどが300tpiを越えてしまいます.
　トラック密度が200tpiを越えると,FDDのヘッドの位置決めは,ステッピングモ-ターだけでは制御できません.そこでサーボをかけて,セクターごとに書き込んだサーボパターンを検出してやり,それを基にして位置決めを行う必要が出てきます.サーボパターンは、2トラック,あるいは4トラックごとに一定のパターンを繰り返す方式が採用されています.2トラックパターンの場合は,目的のトラックを含む±1トラック以内にヘッドがくると,セクター間ギャップを検出して,ヘッドが次のサーボパターンを確認するようになっています.4トラックの場合は,それが倍の±2トラック以内の範囲で検出します.どちらも実用段階の手前まできていますが,各メーカー間で統一しようという動きは,今のところないようです.
　また,トラック密度が400tpiを越えるような10MbytesFDは,ヘッドの位置決め誤差が,±3.0μm以下という精度を要求されますが,最近では、ソニーが,機械精度±1.0μm以下のリニアステッピングモーターを使って,±2.0μm以下という精度を試作段階で実現しています.

凄い気合の入った技術解説だ。感想としては技術屋が技術を高めていってもそれがお客の要望にあっていないと消える以前に登場することすらできないということなのだ。

10MbytesHDDと変わらない仕様
　以上のような点を踏まえて,あらためてこのクラスのFDDを見ると,平均アクセス時間は,10Mbytes3.5インチHDDの約2～4倍はかかりますが,メディア交換が可能である点,保磁性や動作確度が高い点などが,HDDよりも優れている部分として注目されます.
　また,HDDのデータバックアップ用として使う以外の利用方法も,アプリケーションの大容量化に伴って,検討され始めていることは,冒頭でも述べたとおりです.
　小西六写真工業の5.25インチFDDは,サンプル価格が20万円ですが,量産効果が出れば10万円前後になるでしょう.また,メディアの価格は、1枚3000円程度が見込まれています.ただ,10Mbytes以上の大容量FDDは,ほとんどのメーカーが3.5インチを使って実現する方向で動いているため,本格的な普及という点では疑問が残ります(小西六の場合は,大容量FDD開発の当初から,ターゲットを米国のワークステーション市場においているため,普及というレベルが異なるという点は考慮する必要がありそうですが).国内での大容量FDDの普及サイズは,やはり3.5インチが本命でしょう.
　FDD全般で見ると,今年から来年にかけては,5.25インチFDDの需要がそれほど望めないという予測が出ており,台数ベースでは,900万台程度(本年度予測)の出荷で頭打ちになると考えられています.月産7～8万台でなんとか採算ベースに乗るといわれる5.25インチ市場には,現在十数社が参入していますが,韓国や台湾などの追い上げもあって,今年末には,撤退を表明するメーカーも出てきそうです.
　一方の3.5インチ市場は,本年度320万台の出荷が見込まれており,1～1.6Mbytesクラスを中心に需要はさらに伸びる見込みです.3年後には,5.25インチの生産台数を追い越す,という予測結果も出ています.ちょうどその頃には,10Mbytesの3.5インチFDDも本格的な製品化の時期を迎えているでしょう.

もう台湾、韓国に負け始めていたのか。私も「こうなって欲しい」と思ったことが実現しなかったパソコンの世界だから、記事の筆者の予測が残念だったのは変なことではない。パソコン業界とはそんなものだ。

コラム記事をスクラップする。
「2Mbytesのすぐ後はどうなる？」

　10MbytesFDDは,少なく見積もっても,あと2～3年は製品化に時間がかかりそうですが,それでは3MbytesクラスのFDDはどうなのでしょうか.
　このクラスは、すぐ下位の1.6～2MbytesクラスのFDのデータの読み取り/書き込みができなければ,当初の普及に際しては,支障があります.本来,FDDの大容量化は,既存のデータ資産の継承なくしては考えられないものです.3Mbytesの容量を実現したのに,「MbytesのFDのデータが読めなくなってしまったのでは,せっかくの大容量化の恩恵も半減します.
　下位FDのデータの読み取りは,表1の3MbytesFDDクラスでは実現されているようです.トラック密度を2倍にして,セクターサーボを採用したかわりに,転送速度やFDCを継承したり,最大線記録密度を上げたかわりにトラック密度やサーボ機構を継承したりして,読み取りについてはなんとか保証しています.
　ただ,書き込みの方は,トラック密度を上げているものについては,ヘッドが追従しないために,不可能です.また,トラック密度は同じでも,1Mbytesのメディア自体にバラつきがあるため,条件付きで保証する場合もあるようです.
　大容量になれば,いつかは下位FDのデータを継承できなくなる時期がきます.10MbytesFDDは、1～2Mbytesの読み取りこそできますが,書き込みについては完全に不可能になってしまいます.
　3.5インチFDDの大容量化が進む背景には、5.25インチFDDに比べて3.5インチFDDはそれほど普及していないため、継承する過去の資産もそれほど多くない,という読みもあるようです.

読みは外れたんだよな。メーカーが大容量FDDを搭載しないと広がらないんだよね。外付けドライブで対応なんてユーザは支持しない、金を出さない。

「43社が統一規格として採用した2インチのFDDが商品化」

　アンフォーマット時でIMbytes(片面記憶)と,容量は小さいのですが,そのかわり,サイズが2インチというFDDシステムをソニーが発表しました.
　これは,内外の電機メーカー43社が参加している電子スチルビデオ懇談会でまとめた「2インチ・データディスクシステム」のデータ信号記録フォーマットに準拠したシステムです。もともとは,電子スチルビデオ用の記録用機器/媒体として登場した統一規格なのですが,強力な誤り検出/訂正符号規格(CDと同等のCIRCを持つ)によって,ポータブルワープロやラップトップコンピュータ,OA機器用の外部記憶装置としての需要が見込まれています.
　記憶容量は,最大で10Mbytes程度まで向上させることができるため,大容量FDDの予備軍といえるでしょう.
　価格は,サンプル出荷にもかかわらずFDDが3万8000円,FDが1050円と低価格になっているのが魅力です.

ソニーのデジカメ（34年前は電子スチルカメラと言っていたか）マビカに使っていたかどうか分からない。

最後は「マルチウィンドウOSに対応するグラフィックスプロセッサ」のスクラップ。


コラム記事の「デュアルの上を行くトリプルの出現」

　日本電気とアスキーは,マトリクス形のフレームバッファの構成が容易にできる「トリプル・ポート・グラフィック・バッファμPD42232CU」を共同開発しました.
　μPD42232CUは,256Kbit(32Kワード×8bit)のデュアルRAMポート(ワードアクセスポート,ピクセルアクセスポー-ト),128ワード×8bitのシリアルポートからなるトリプルポートをはじめ,各種レジスタや論理演算回路などを「チップに集積化したフレームバッファ用メモリチップです。
　RAMポートは,×8bit構成のワードアクセスポートと,×8bit構成のピクセルアクセスポートを持っておりμUPD42232CUを複数個分組み合わせることによって,マトリクス状に接続したフレームバッファを構成することができます.
　また,このRAMポートは,フレームバッファのアクセスを容易にする各種レジスタや,256種の論理演算機能を備えているため,コンパクトな画像処理システムを作れます.
　システムの構成としては,解像度640×400ドットのビットマップディスプレイシステムが考えられます.μPD42232CU　1個を「プレーンに割り当てて,24プレーン構成とすると,1670万色の表示が可能になります.

1990年のコンピュータ環境 80386CPU (月刊ASCII 1987年7月号8）

特集「1990年のコンピュータ環境」の 80386CPUについての記事をスクラップする。












以下図表をスクラップする。



まとめ部分では

80386でどう変わる?
　80386を採用することにどんなメリットがあるのでしょうか?まず,単純な理由としては,クロックの違いによる処理速度の向上です.これは,従来の8086のプログラムを走らせても,クロックが16MHzになっているので,その分処理速度が上がります.
　次は,ネイティブモードを使い,80286用のOSを高速で走らせるというものです.これにより今までのほとんどの制限がなくなり,従来のミニコンやワークステーションクラスと同等の能力を持つシステムが構成できます。
　ワークステーションといった比較的「高級」な用途ではネイティブモードによりUNIXおよびそれ相当のOSが使われ,従来のいわゆるパーソナルコンピュータという路線上では「速い8086」といった使い方か,仮想8086モードによるマルチタスク化8086を使うといった用途の2極化により,80386の利用は始まると考えられます.そして80386への移行が終了した時点には,両者は統合され,現在のパーソナルコンピュータクラスでも仮想記憶やマルチタスクが最低条件となる時代がくるのではないでしょうか.

こう書いてあるが、仮想8086モードによるマルチタスク化してMS-DOSアプリを使うとはならなかった。Windows95でやっとDOS窓が使い物になった。まだまだ先のことだった。
　80386CPUはかなり歓迎されて登場したようだ。林　晴比古による解説がブルーバックスになった。

1990年のコンピュータ環境 Windows OS/2（月刊ASCII 1987年7月号7）

月刊ASCII 1987年7月号のスクラップ記事を飛ばしてしまった。続きをここにアップする。


あおり文をスクラップする。

　これまでメインフレームやミニコンの後に続いていたパーソナルコンピュータの進歩も,その処理速度が向上するにつれ,それらと肩を並べ、いまや独自の進歩をしようとしています.
　アメリカではIBMによるPS/2シリーズの発表によりハード,ソフト両面にわたる活性化がみられ,パーソナルコンピュータは新しい時代を迎えようとしています.また,日本ではオープンアーキテクチャであるTRONにおいて,メーカー各社によリ32bitCPUの開発が進められ,ソフトウェア検証のための試作機までもが登場しているといった状況です.
　本特集では,こうした新しい動きをレポートするとともに,新しい時代のパーソナルコンピュータ像を予想します.

予想が当たったか、外れたかではなく、1987年当時どのようにコンピュータ環境を考えていたか、どのようなコンピュータ環境を望んでいたか、期待していたかを知ることが大切だと思うのでここにスクラップする。

まずは

「OS/2とWINDOWSに見るオペレーティングシステムの最新動向」のあおり文をスクラップする。

－充実するユーザーインターフェイスとそのパフォーマンス－
　32bitCPUマシンが登場し始めた昨今,そうしたパーソナルコンピュータには、資源を有効利用できるさらに高度なOSとユーザーインターフェイスが必要となってきます。いままで処理速度や周辺装置の価格などの問題によりパーソナルコンピュータは,一般のコンピュータとして当たり前の機能を持っていませんでした.各種の条件が満たされた今,パーソナルコンピュータは従来のコンピュータが持っていた機能を持ち、さらにその上を行く機能を持ちつつあります.
　ウィンドウシステムによりユーザーインターフェイスが改善され,新しいOSの登場により,仮想記憶やマルチタスクといった環境が提供され始めようとしているのです.
　ここでは,そのような動きを中心に最新のOSおよびその周辺状況を語っていきたいと思います。

まだ80286のMS-DOSがメインだった時代でWindows 2.0 や OS/2 を職場で仕事に使うなんて想定外の時代だった。そうした中、ASCIIは先進的な記事を載せ、Windoesとか触れない一般ユーザに知識を与えてくれた。
以下写真をスクラップする。

Windows 2.0 になってやっとオーバーラップウィンドウがサポートされた。Windows 2.0 とMacの操作感覚はほぼ同じではないだろう。Macが白黒ディスプレイでやっていたことをWindowsがカラーでするにはマシンスペックが悲しいまでに低かった。80286では使い物になるものを作るのは無理だ。





ソフトウェアの画面の紹介だけでは操作感は伝わってこない。「できる」、「可能である」ということと「使える」との間には物凄い壁がある。使えないソフトばかりのWindows 2.0 だったと思う。

次は OS/2 の記事。





まとめの部分の本文をスクラップする。

パーソナルコンピュータOSの進化の方向は?
　現在では,各社とも80286CPUを持つものがメインであり,8086のみのマシンはどちらかというとエントリーマシンといった位置づけです.しかし,今年登場するマシンの主力は多分80386であり,来年には386マシンが主流となるでしょう.この3つのCPUの特性を考えると80286は非常に中途半端な位置にあります.8086つまりリアルモードは世の中の殆どがこのモードのソフトウェアとなっており,その蓄積は膨大なものです。ところが,80286のプロテクトモードは高度なメモリ管理/保護を持っていますが,リアルモードのプログラムで直接I/Oを操作しているものはプロテクトモード下で動かすことができません.
　これに対して80386は仮想8086モードというモードを持っており,仮想記憶/マルチタスクを行いながらその1つのタスクとしてリアルモードのプログラムを直接実行することができます.しかもその中でのI/O操作をエミュレートしてやることでソフトウェアをまったく変更せずにプログラムを実行することも可能なのです.これに加え,80386は80286のプロテクトモードとアッパーコンパチブルなモードがあり,80386ではすべての機能を使わずにOS/2を動かしています(このことから逆にOS/2は80386専用のOSではないともいえます).
　つまり,8086と80386の間はソフトウェア的には非常にスムーズに移行できるわけです.これに対して現在の8086から80286のプロテクトモードへの移行にはソフトウェアの全面的な変更という大きな問題が控えています。
パーソナルコンピュータ用OSの大きな目標
　80286から80386へCPUの世代交代が始まりつつある現在、OS/2にはどんな意味があるのでしょうか?まず,いえることは,現在の動きはIBMとMicrosoftの路線上にあるということです.今後の8086系CPUマシンのOSの動きはとりもなおさずこの両社の路線となることは間違いなさそうです。
　APの形態は,非常に長期的な目でみると,CPUのネイティブモードで動くものが自然であり,仮想記憶やメモリ管理が当たり前のソフトウェア環境となれば,あとはソフトウェアのバイナリレベルでの互換性を保ちつつCPUの能力を上げていくことも可能になります.
　つまり,仮想記憶で動作するといった条件はいずれはすべてのソフトウェアが満たさねばならない条件なのです.ファイルシステムや画面,グラフィックスの互換性/移植性が高まった現在,残されたカベはそれ以外のハードウェア条件,たとえばメモリ容量や動作環境などです。
　仮想記憶などの採用により,これらの条件が満たされなおかついずれ登場するであろうさらに高性能なCPUのことを考えると,こうしたプログラミングのやり方を変更する必要があります.それをいまやってしまおうというのがOS/2の意図なのです.OS/2と同時に発表されたIBMのSAA(System Application Architecture)は,この仕様に従って作られたプログラムがパーソナルコンピュータから大型機までのどのシステムでも動作可能にすることを保証するものです.こうした大型機までをも含むトータルなアーキテクチャのためにはいま,仮想記憶を行うようなアプリケーションに移行する必要があるのです.以上のように考えると今回のOS/2はIBMの戦略が全面に打ち出された製品といえるでしょう.
　しかし,すべてのプログラマ,ソフトウェアハウスがこれに対応できるか,あるいは対応するかどうかはまた別の問題です.さらには,IBMとは違った設計の80386マシンも多数あり,それらがこれですべて終わってしまうわけではありません.つまり,現在のところOS/2+SAAという路線は,まだIBM1社の方針でしかないわけです。5月に発表された日本IBMのパーソナルコンピュータ,PS/55(パーソナルシステム/55)の最上位機種5570を見るならば,そうした方針が顕著に感じられます.この機種は米国IBMの発表したPS/2のモデル80のディスプレイ関係を変更したマシンなのです.しかもOS/2(ただし日本語化されており,アメリカ版とは別バージョン)を採用,この機種を足掛かりとして,いずれ全世界的にパーソナルコンピュータを共通化しようという意図が見えるわけです.
　ユーザーにしてみれば,相変わらずいま使っているようなスプレッドシートやワードプロセッサを使いたいだろうし,すでに持っているソフトウェアを利用したいというのが本音です.こうした欲求とともにマルチタスク化した高度な環境を享受したいというのが現在の最も大きな要求ではないでしょうか?これに対する答えは80386の仮想8086モードです.このモードを使うことで、従来のMS-DOSのAPはほとんどそのままマルチタスク環境に移行できます.つまり,80386の仮想8086モードを使ったOSが一番要求されているのです(図4).
　このように考えると,MS-DOS用のソフトウェアの走るマルチタスクの80386専用OSは今年中にも発売される可能性は高いでしょう.そして当分のあいだOS/2と80386専用OSの共存時代が続き,プロテクトモードのAPが主流を占め、次々世代OSの登場によってこの2つが統合される,というのが今後の動きなのではないでしょうか.これにからんでUNIXやそのウィンドウシステムなどがあり,今年がどうやらパーソナルコンピュータのDOSからOSへの転換の年になりそうです.そしてDOSからOSに転換したあと,OSとしてUNIXやその他のOSとの拮抗が起こるのではないでしょうか.

当時、この記事をきちんと読んでいなかった。自分のパソコン遍歴を振り返り、やはりPC-9801VMのとき買っていれば、80286マシンなんて買うことはなかったのにと深く後悔する。V30は8086じゃないと言い訳して86系に転べば良かったのだ。
　OS/2が80286用のOSで80386用ではなかったことがWindowsに負けた原因だったのだろうか。マイクロソフトが早めにOS/2に見切りをつけたのは80286が中途半端なCPUだと気が付いていたためだろうか。
　それにしてもOS/2はブルーバックスになるほど注目されていたOSだった。80286CPU用として開発されで頑張ったOSだった。下は脇英世氏の「OS/2への招待」である。


この本によれば
（p.5-6）
「OS/2の基本部分は、マイクロソフト社が中心になって作られているようである。
OS/2はビル・ゲーツの誇りであるらしく、「私のオペレーティング・システム」と言っていると伝えられる。ビジュアルなマッキントッシュ的なオペレーティング・システムを作り出すことは1984年のマッキントッシュ登場以来のビル・ゲーツの夢だったらしい。長く予告されたOS/2は、やっと登場しようとしている。今後のOS/2は、おそらく1990年代へ向けて、UNIXより上位シフトして行くことだろう。」とある。
当時はこう考えられていた。まさか、マイクロソフトがOS/2と決別し、WindowsでOS/2を駆逐するとは。マイクロソフトはXENIXとOS/2を肥やしにしてWindowsで成功したように見える。
なんってたってOS.2は天下のビッグブルーが作ったOSだから。Basicを作っていた新参者のマイクロソフトはそんなに評価されていなかった。だってMS-DOSは自社製のOSではなく、シアトル・コンピュータ・プロダクツから買ったものだったし、しかもそれはCP/Mを8086用に移植して手を加えたような製品だった。OSをまともに作ったことのないマイクロソフトが開発した34年前のWindowsは使いものにならなかった。Macができたことを物真似しても、Windowsはやはり物真似レベルだったから。
しつこいけど、「できる」と「使い物になる」とは全く違うのだ。

その他のハードウェア等（月刊ASCII 1987年8月号4）

その他のハードウェア等をスクラップする。

日本IBMが1Mbit DRAMを生産開始

注目すべきは工場が滋賀県の野洲工場というところ。34年前は日本が世界のDRAM工場だった。

Intel社が80486の最終仕様を固める

日本の16bitパソコンの主力が80286で80386がやっと姿を見せたときに80486が最終仕様を固めた。確か、80486はマイクロコードではなく、より高速化するためにワイヤードロジックだったと思う。私は、80386マシンは買わず（経済的に買えず）、80486マシンを買った。

東芝が世界最高速のAI用プロセッサを開発

1秒間に60万回（従来の10倍以上）の推論を実行できるそうだ。34年前の日本は1番を目指して頑張っていた。

富士通，15Kbit PROMを発売

8bit機時代、EPROMを書き換えていたがこの頃は全く触っていなかった。

東芝が高画質のCCDカラーイメージセンサーを開発

記事をみるとビデオカメラ用らしい。デジカメへの利用はまだまだだった。

ソニー，CCD・V90の発売を延期

カメラ一体型の8mmVTR「CCD・V90」で使うCCDが上手く作れなかったとのこと。工場は鹿児島国分工場。日本の工場についてはこうしてメモしておく。


東大，セラミックス系ジョセフソン素子を開発

ジョセフソンコンピュータについての記憶がない。ジョセフソン素子の実用化はどうなったのか。

ベルコアが超電導物質の特性維持方法を開発

超電導についての記事はいまいち信用できない。それは、こうやって記事になったもののうちどれが実用化されたのかが分からないからだ。分からないというか記憶にないからだ。

ソニー，フィリップスがCD-Iの機能仕様作成

CD-Iも34年後にはほとんど消えてしまっている。技術の寿命は短いものだと実感する。

山水電気が光学記憶システムを開発

今は無きオーディオで名をはせた山水電気も34年前は光ディスク開発をするような先進的企業であった。こういうメカニックな部分つまり可動部分がある製品は技術力が必要である。34年後はLSI化されLSIを作る企業は技術力というか莫大な投資ができる経済力が必要だが、製品を作る企業は技術なんて必要なく、半導体を買ってきて組み合わせて一丁上がりの時代だ。
山水電気の倒産は残念だった。

キャビン，3万円台の再生専用ビデオデッキを発売

34年前はビデオレンタル店があり、そこではビデオデッキも貸してくれた。これは、ビデオデッキを持っていない人がビデオを見たいから貸しているというものではなく、当然ビデオデッキは持っているがダビングしたいというお客のためにレンタルデッキがあった。
キャビン工業の再生専用ビデオデッキはダビングしたいというお客を狙ったものだったのだろう。

カシオが32KBメモリの漢字電子手帳を発売

カシオDK-1000の価格は1万4800円。

シャープ，プリンタ付き電卓を発売

EL-1600の価格は5800円