Lisaエミュレータ作者、Ray Arachelianインタビュー
Ted Hodges - 2007.03.13

先日僕はある重要な人物にインタビューするという、大変な栄誉に預かることができた。彼の名はRay Arachelian、Apple Lisa Emulatorの作者その人である。彼がいなければLisaを持っていない人にLisa Office Systemの動作を見せる方法はなかったかもしれない。

Lisaエミュレータについて詳しくは前回のコラムをご覧いただきたい。

Ted Hodges: よろしくRay。調子はどうでしょう？

Ray Arachelian: 順調だよ。次のリリースの準備をしているところで――この水曜日あたりになると思うけど、これが最初のベータになる――ピースが納まっていくごとに胸の高まりも増すばかりだよ。

Ted: あなたがLisaと関わりをもつようになって、どのくらいになるんでしょうか？

Ray: 初めてLisaを手に入れたのは1989年だね。最初の頃はMacWorksを使ってMacとして使っていたんだ。それがきっかけでHackintosh IIcx（PCケースに収めたIIcxのマザーボード、など）を組んだりもしたし、それ以来すっかりMacのとりこになってしまった。Macを長年にわたって何台も買ってきたのも、それがきっかけさ。

最初はLisaの歴史的重要性も、他のオペレーティングシステムを動かせるということもわかってなかったんだけど、FidoNetなどのBBSネットワークでLisaオーナーと話しているうちに、自分の持っているものが大した宝石だとはっきりしてきてね。Lisaの本当のオペレーティングシステムを探すのに、Steve Hatleにはずいぶんお世話になったよ。

Ted: 初めてLisaに触れたのはいつのことでしょうか？

Ray: 僕は一番初めにやったアルバイトで技術係をやってたんだ。学校が終わってからの典型的2時間だね。僕はブルックリン工業校に通ってて、中等部だったか高等部だったか、って頃。ニューヨーク市教育委員会の、教員向けトレーニングセンターでの仕事で、2つか3つあった教室にはいろんな種類のPCとかApple IIとかMacとかCommodoreとか、そういったものが一杯置いてあった。

ある日、廊下のガラクタ置き場になっているところに見慣れないマシンが放ってあるのを見かけてね。Appleロゴが入ってるし、Macの一種だろうと思ったんだ、マウスも一緒にあったしね。以前研究室でMac Plusで遊んだことがあったから、そのマシンに興味を引かれたんだ。

そいつのことをボスに訊いたんだけど、Lisaっていう言葉を耳にしたのはそれが初めてだった。彼は持っていってもいいと言ってくれて、ハードディスクドライブもくれた。2週間もすると電源が死んじゃったけど、彼は僕のためにわざわざ新しいのを注文してくれて、おまけにMacWorksのフロッピーまでくれたんだ。

で、これはDOSとかWindows 3.1とかの頃の話なんだけど、それらと比較してMac XLが動いてるLisaってのは素晴らしいマシンだった。それをタダで手に入れたんだから、自分の幸運が信じられないぐらいだったよ。

その何週間か何ヶ月か後、これまたゴミ箱行きが決定している壊れたLisaを2台持ってる先生がいたんだけど、僕に要るかと訊いてきた。そのうち1台をなんとか動くようにして、もう1台はバラバラに剥いて捨てた。こうして僕はほぼ完全なLisaを2台とそこそこのスペアパーツを手に入れたってわけさ。

一年後、仕事場ではXenix 286が使われていた。これも幸運だったな、XenixにはLisaで動くバージョンもあったし、それでUnixを独習することができたから。この頃には僕はHackintoshを組んでいて、メインマシンとして使っていた。

Ted: Lisaは何台持っていました？

Ray: 3台、そのうち1台は修理できるような状態じゃなかったけど。そのうち再利用できる部品を取っておいてたんだけど、残念ながらケースとCRTは、すごく狭いアパートに住んでて空き場所が全然なかった頃に捨てちゃったよ。

Ted: Lisaエミュレータを書こうと思ったきっかけは？

Ray: 1997年の暮れ、家の大掃除をしてるときに、一度持ってるマシン全部の電源を入れてようと思ったんだ――ソフトウェアの更新とかOSのパッチ充てとかでよくやってることだけどね。で、2台のうちの1台はどうしても電源が入らない。ウェブを調べまわっていくつかの部品を見つけることはできたけど、部品を見つけるのは以前より難しくなっているみたいだった。

さすがに僕も、うちにあるLisaがいつまでも動きつづけるわけじゃないし、交換部品の供給もどんどん厳しくなっていくと気づいてね。この頃には当然ながら僕も、Lisaの歴史的重要性について十分に認識していた。Lisaの生年月日はMacよりも前だしvMac emulatorがリリースされた（間もない頃だった）から、多分Lisaのエミュレータを書くのはそれほど面倒じゃないだろう、と思っちゃったんだ。我が勘違いここに極まれり、だね。

幸運にも僕は、長年にわたってLisaの情報を大量に集めていたDavid T. Craigを見つけることができた。実際のLisa開発者に連絡を取ってみるとか、彼はそういった助言も数多くしてくれた。振り返ってみると、このプロジェクトでは先導者役に困らなかったね。このエミュレータは彼の助けなくして存在し得なかっただろう。

その他にも、名前を明かすことはなかったけど、長年にわたって期待以上の貢献をしてくれた人たちもいたよ。

Ted: このエミュレータを書くうえでの困難はどれほどだったのでしょうか？

Ray: 想像してたよりもはるかに困難だったね――というのも幸いしたのかな、なにしろ、実際にどれだけの困難が待ち受けているかを分かっていたら、始める前にあきらめていたかもしれないし。

当時、Cはおおよそ理解してた。大学の課程でも習ったし、うちにあるMacをあちこち覗きまわってたから、68000についてもわかっていた。あちこちで小さなDOSプログラムをいくつか書いてたし、今はもうないけど、MacのためのBBSを書いたりもした。Unixを熟知していたけど、それはシスアドの観点からだったな。X Window system向けプログラムの書き方については知らなかったし、エミュレータはそういう技術をまとめて学ぶのにうってつけの口実に思えたんだ。

半年から1年かければそこそこ動くものができて――おそらく完成させるにしてもせいぜい2年、なんて思ってたんだよね。

Ted: エミュレータ製作はどういう風に進んでいったのでしょうか？

Ray: 最初の段階にやったことは、Lisaの資料を全てスキャンしてオンラインに置くことだった。そうしておけば家にいなくても見ることができるし、おまけに取り扱いも楽になる、というのが主な理由だよ。当時僕はロングアイランド鉄道で朝晩通ってたんだけど、コーディングのほとんどはその中でやっていたし、電子版の資料が理想的だったんだ。

それからというもの、それを何度も読み返すのが続いたな。コンピュータの資料をどんどんさかのぼっていくと、最近のコンピュータ用語に使われる表現では辻褄が合わないところが出てくるし、コードを書く前にまず、物事をすみずみまで明確に理解しておかないといけない。Lisaの資料はそれほど厄介じゃなかったけど、まるで資料の研究をしているような感じだったよ。

どのエミュレータにも共通する部分はある。CPUはまさに、その全ての中核だ。当時は68Kエミュレータを探し回っても数はあまりなかった。UAEコアがだいたいできている程度。

ほとんどJITコンパイラという理由でエミュレータ界のある人が推していたのが、Generatorのコア。当時デスクトップの主流は200MHzのマシンだったし、速度を稼いでくれるならなんでも重要だった。ゲストCPUの1命令をエミュレートするにはホスト側で10-40命令かかるから、5MHzのマシンの場合だと、インタープリタ上のCPUを動かすのに最低でも100MHzのCPUが必要で、I/Oなど他のことのためにもある程度余裕を残しておかないといけない。

メモリに関しては全く簡単、マシンのメモリと同サイズの配列を用意するだけ。

LisaのMMU（メモリ管理ユニット）には追加の複雑なレイアもあり、これによって全てのメモリアクセスに対して大掛かりに聞き耳をたてることができるようになっていた。MMUコードをいかに最適化して書き直すかについては、相当な時間を費やして考えさせられたよ。現在のコードにあるのは、MMUの完全な書き直しの3度目になると思う。後になってみると、最近のマシンはかなり速くなっているから書き直す必要はなかったんじゃないかとは思うけど。

2001年末ごろまで、僕のエミュレータからはまとまった量のものを取り出せずにいた。これはエミュレータの常でね、惜しいところまで来ないと大した成果は得られないものなんだ。ROM内の起動時テスト (POST) ルーチンの出力を何とか取り出すことができたんだけど、それでディスプレイルーチンに誤りがあるのがわかって、すぐさまそこを直した。

これこそが一番最初のエウレカ！の瞬間だったんだ。

次に、フロッピーのエミュレーションを動作するようにしなきゃならなかった。ROMだけを見てたらそこはあまり関係ない部分だしね。

第二のエウレカ！の瞬間は、LisaTestを途中まで立ち上げられるようになった頃のことだった。おそらくI/OシステムのどこかかMMUが壊れていたんだろう。

幸いにもLisaにはいくつものOSと、さっき言ったLisaTestがあり、I/O部分に対して健全性検査を行うことができた。I/O部分の大半がLisaTestの徹底検査を通るようになっても、Lisa Office System (LOS) を起動させることができずにいた。それでLisa Monitorを立ち上げてみることにしたら、それもMacWorksもXenixも、当時のままに動くじゃないか。実際のLisaで動いてたし問題あるはずがない。

Arachelian氏より補足

Lisa MonitorとはLisaのごく初期のオペレーティングシステムの名称で、LisaTestやMacWorksの製作はこの上で行われた。いわゆる機械語モニタのことではなく、Lisa開発環境Lisa Pascal Workshopに含まれていた機械語モニタはLisaBugと呼ばれていた。なお、Xenixについては現在も完全動作するまでには至っておらず、立ち上がりはするがログインやシェルは現れない。

2003年になると、僕はCPUコアにバグがあるんじゃないかと疑うようになっていて、僕が使っていたCPUコアであるGeneratorの作者、James Ponderに連絡をとってみた。彼は、彼が気づいていたshift/rotateオペコードのバグについて教えてくれたが、まだ運が巡ってきたわけじゃなかった。

僕はテスタープログラムを組むことにしたんだけど、それには本物の68Kマシンが必要だった。Unixが動いて、その上で68Kコードに加えてGenerator CPUコアそのものをアセンブル・実行できるものがいいし、となればGCC (GNU Compiler Collection) ツール集が挙がってくる。OpenBSDかLinuxをIIsiにインストールすることを考えたけど、これにはFPUが無いからさらに困難だとわかった。

幸いにも僕はNeXTstationを持っていたし、これなら要件を満たしている。そこでエミュレータからCPUコードを抜き出して小テストスイートプログラムを書き、それらをまとめて実行する接着シェルスクリプトも書いた。テストの実行には丸一週間かかり、大量のバグ除去に役立ったんだ。

後になって気づいたんだけど、68040で動いているCPUエミュレータコードとIntelマシンで動いている同じコードとでも差異があって、そのバグを取り除くには例のテスターをLinux x86で動かして68040の出力と比較しなきゃならなかった。前回のテストでの68040の結果を圧縮保存しておいたのはラッキーだったな。

それでもまだLOSを動かすだけの幸運は巡ってこない。そこで僕は作業に戻ってI/Oシステムにもう少し手を加えて、シリアルポートハンドラであるZ8530のコードに着手したんだ。

ようやく僕はLisaのMMUを適正に機能させる魔法を見つけた。2006年7月のことだ。こいつはハードウェアの非公開機能を利用してたんだ。コードが何をしようとしているか、エミュレータ上のハードウェアで何をできずにいるのか、これを較べて調べてなかったら見つけられなかっただろうな。

LOSをインストーラディスクから起動できるようになると、今度はハードディスクドライブのコードを書かなきゃいけなかった。それ無しのLisaはそれほど便利じゃないしね。

エミュレータのコードが完成したのは2006年9月頃のことだった。僕はX Window UIを取っ払うことにしてて、WindowsやOS Xといった他のオペレーティングシステムに移植するのに役立つFOSSはないかとネットを探し回ってた。wxWidgetsは要件を満たしている。僕はwxWidgets本を買ってきて一週間かけてむさぼるように読み、新UIのコーディングを始めた。

当初僕は最初のリリースを、（1983年の）Lisaの最初のアナウンスに合わせて1月19日にしたかったんだけど、別の特別な日、1月24日の直前まで満足に動くものにすることができなかった。最初のリリースは相当バギーだったし、追加リリースを必要としていた。アルファテスト品質にも達していなかったし、それはプレビュー名義にしたんだ。実際、開発版だしね。

次のリリースは1.0のベータで、その後バグフィックス版をいくつか出すことになると思うよ。

Ted: このエミュレータを書くのにかけた期間はどのぐらいなんでしょうか？

Ray: だいたい8年。止めたいと思ったことも何度もあったけど、なんとか自分を納得させてきたし、納得できなくても続けるように無理やり強いてきたね。コンピュータの歴史の本をたくさん読んだり、何ヶ月かおきに『Pirates of Silicon Valley（バトル オブ シリコンバレー）』を観たり――目標に専念させてくれるものなら何でも取り入れたよ。

通り抜けられないと思うような個所は一つもなかったけど、別のレイアに難題が持ち上がったり、他のところに間違いがあるとほのめかすなんてことはしょっちゅうあった。いくつかの通行止めは結構厳しい問題だったけど、大半は難しくなかったな。

出だしを間違えて袋小路、なんてのも結構あった。一番始めの頃には自作のCPUコアをいじくりまわしててGeneratorに切り替えるまでの2、3ヶ月を無駄にしたし。生のX Windowコードを勉強して書くことにも、さらに3ヶ月無駄にした。（僕が始めた頃、いいツールキットに限って有料だった。GTKやKDEはなかったし――少なくとも僕はその存在を知らなかった。） Xの自家製ウィジェットを書くなんて不要な作業の塊だよね。

もちろん、仕事とか家族とか、実生活の都合でエミュレータの作業をまったくしない時期も何ヶ月かあったしね。

Ted: このエミュレータはどのように動作しているのでしょうか？

Ray: たいていのエミュレータがそうであるように、その心臓部はCPUコアだ。（エミュレータには）いろんなタイプがあって――もっとも一般的な（そしてもっとも遅い）のはインタープリタ。ゲストCPUへの命令をフェッチして、デコードして、それから実行する。

Generatorで使われているコアは、それよりもちょっと上手くやってる。命令をフェッチしたら、デコードした後、命令で使われているパラメータとそれについての情報、つまり各フラグを計算するか否かなどをキャッシュするんだ。こうしておくことで、そのコードが次回実行されるときに格段に素早く実行できる。

GeneratorのコアにはARMホスト用JIT (Just in Time) コンパイラもある。だけど、僕のところではその機能を使っていない。

もっと最近のCPUコアは完全JITコンパイルをサポートしていて、それを使えば実行速度は大幅に改善する。だけど、Generator CPUコアはLisaEmのMMUに緊密に接続されているから、コアの変更は選択肢にはならないんだ。少なくとも、大規模な再設計なしにはね。

CPUはこれぐらいにして先に進もう。I/Oシステムはハードウェアのドライバを書くことと非常によく似ている。シリアルポートドライバとかパラレルポートドライバとか、そういったものを書くのと同じような感じ。ただしドライバの「逆向き」だけどね、なにしろ作ろうとしてるのはハードウェアの振る舞いであって、ドライバじゃないから。結果として仮想のI/Oハードウェアは方向転換し、ホスト側オペレーティングシステムで相当するアナログ部分を見つけ出す。例えば、フロッピーのあるセクタへの書き込みは、そのデータの、あるファイルの所定の場所への保存を意味することになる。

I/Oサブシステムの多くはオートマトンを書くことで対処できる。ハードウェア間のマルチタスクを実現するためにスレッドの分離などをする必要はないんだ。

難易度はハードウェアによって様々だ。色々あるLisaオペレーティングシステムもそれぞれやり方が異なっている。VIA 6522（パラレルポート）だと、以後ポートを入出力のどちらに使うかを指定するディレクションマスクをセットして、1バイト書き込む、そうするとそのバイトが直ちにポートに送られる。もう一つのやり方は、値をポートに書き込んでからディレクションを切り替えるんだけど、ディレクションを切り替えないといつまで経ってもポートに送られない！ ハードウェアの柔軟性が増すにしたがってそのエミュレータを書くのも難しくなるんだ。そういうメソッドを全部サポートしなきゃならないからね。

VIA

Versatile Interface Adapter（汎用インターフェイスアダプタ）。6522はMOS Technology社6502ファミリのI/Oポートコントローラで、CommodoreやApple III、Macintoshなどに使われていた。

Lisaのハードウェアは、ちょっと変わった作りになっていた。例えば、ある特定のI/Oアドレスの読み出しをすると変化が起きてしまう！ 書き込みがあったんじゃないかと思ってしまうんだけど、そのアドレスに触れただけで変化する、少しばかり直感に反するものなんだよね。もちろん、そういう機能のエミュレート自体はたやすい。お次は、エミュレート難度の順にいうと、VIAかCOPS（クロック/キーボード/マウスを扱うコントローラ）、それからZ8530シリアルコントローラ。Z8530は相当手のかかるケダモノでね。完全エミュレートは試みもしなかったけど、その機能を利用できる程度にはエミュレートしたよ。

MMUそのものは基本的にはいたってシンプルなんだけど、これを利用してあらゆるメモリやI/Oの参照に遅延が入るようになっていた。これの最適化されたエミュレーションをいかに設計するかについては、腰を据えて熟考しなきゃならなかった。僕が思いついたのはMMUテーブルをCPUコアのIPCと結びつけるキャッシングシステムだ。これは大量のメモリ操作を要求するしフットプリントが他のエミュレータよりも大きくなるんだけど、パフォーマンスにおける収穫はそれだけの価値がある。

きっちりやるのが一番難しいのはタイミングだ。このエミュレータは今もまだ上手くできていないんだけど、これはつまり、あまりに速くとかバラバラの順番でとか、事が起こる状況次第で動作したりクラッシュしたりする、ってことなんだ。これは、割り込みなどがいつ発生するかを伝えるタイミング情報の入った優先度付きキューで対処できると思う。

Lisaの資料は膨大だ――それでも完全に網羅しているわけじゃないし、誤認を生じやすい部分もある。実行中のコードがしようとしていることを観察しなきゃいけないのはもちろんのこと、資料に書いてあることを無視しちゃったほうがいい場合もある。なにしろ、ハードウェアガイドを書いた人は読者としてエミュレータ作者まで想定してたわけじゃないんだし。シリアルナンバーのハードウェアが実際にどのように動作するかなど、中には隠さなければならなかった情報もあるだろう。

フィニッシュラインに到達するには、あらゆるもののトレースログを取っておかなければいけないし、その中で何を探せばいいのかを理解しておかないといけない。トレースログには、実行された全ての命令、CPUの全てのレジスタ、発生した可能性のあるI/Oなど――基本的には特定の時点に起こった全ての事が、要したCPUサイクルとともに記載される。実行時間1分のトレースログでさえ、優に数ギガバイトにもなるんだ。トレースログを読み始めて数時間もすれば、探しているものを絞り込む方法のコツをつかんで、それに役立つツールを作るようになるよ。

ログを何ギガも通して読むのは大して面白いもんじゃないけど、やる価値は大いにある。ソフトウェアが何をしようとしているかを、素早く把握できるからね。おまけに、ソフトウェアのどの部分がアセンブリ言語で書かれていてどの部分がコンパイラで生成されたのか、どこの効率が良くてどこが悪いのか、そんなことまでわかってしまう。これは68000のウィザードが書いたコード、これはビギナーが書いたコードって見分けがつくようになるよ。

スタックにパラメータを出し入れしてまでほとんど同じことをやる別の関数を呼んで、それでどれだけのオーバーヘッドが浪費されているかさえ分かってない人も多いんだよね。トレースログにかかれば、それもあからさまに暴かれてしまう。最近のアーキテクチャにしたって、特にオブジェクト指向プログラミングに要因があるんだけど、このオーバーヘッドの弊害を相当受けているよ。CPUとメモリシステムのスループットの高さで目立たなくなってはいるけど。

大抵のソフトウェアプロジェクトでは、開発作業が20%、デバッグが80%ってところだ。エミュレータでは多分もっとひどいんじゃないかな、というのは完成間近までまるで結果が得られないからね。結果が得られるようになっても、エミュレータを動作し始めたところから実際に稼動するまで持っていくのには、相当な時間がかかるものなんだ。

Ted: 「Lisaの技術」の歴史を保護することの重要性については、どのようにお考えですか？

Ray: Lisaだけじゃなくほとんどのコンピュータについて、その歴史を保存することは重要だと思う。Lisaはコンピューティング史に残る非常に重要なマイルストーンになることができたけど、記憶にとどめておくべき技術が込められたコンピュータは数多くある。

発生期にある技術のほとんどに共通することだけど、たいていカンブリア爆発というものがあって、何百という――場合によっては何千もの――種類のシステムが登場して、市場シェアを奪い合うことになる。マイクロコンピュータの世界では、1970年代後期から1980年代中期にかけてこの構図が見られたよね。市場はそれらのマシンに進化を促す力にあたるものを加え、当然ながらそれらの大半は死に絶えてしまうことになる――僕たちが保護しようとしているのは、まさにそれなんだ。その多くは興味深い機能を備えていて、それぞれがコンピュータ史家に教えを授けてくれる。

ここで大きな問題があるんだけど、それらのシステムの技術資料の入手が、すでに保存されているものを除いてどんどん難しくなっている。例えばBitsaversは、そんなシステムの資料を収集して保護に役立てようと試みている。これは必ずしもそれらをエミュレートするという目的だけのためじゃなくて、歴史的理由のためでもあるし、そしてまたアンティークハードウェアの所有者がそれらを保存するのに有益でもあるんだ。

技術資料の入手が容易になった側面もあるけど、それはデータ保護に努めている人たちの取り組みがあってこそであり、Commodore 8bit系列のようなよく知られたシステムに限ってのことなんだ。

ソフトウェアライブラリの保護も必要だ。あいにく古いメディアは動作するドライブの数の減少とともにアクセスしづらくなってきている。機械部品は真っ先にお亡くなりになるし、ゴムは経年劣化し、歯車類は潰れ、グリスだったものは糊になり、コンデンサは液漏れして基板を傷める、といった具合。

長期的にみれば、古いコンピュータはいずれ死に絶える。最近の相当部品とかコンデンサの交換なんかで結構やって行けるもんだけど、ゴムローラーや特注ギアの交換はほぼ不可能だ。

だからそれら全てがコンピュータ史家の関心の的になっている。幸いにも、古いコンピュータとその歴史の保護に関心を持っている人は大勢いる。メーリングリスト、ウェブBBS、ブログ、ポッドキャスト、催し物など、交流の場はたくさんある。

• Google Groups: LisaList
• ClassicCmp Mailing Lists
• Bitsavers
• Retrobits Podcast
• 68k Macintosh Liberation Army Forums
• Vintage Computer Festival
• RetroMacCast
• MARCH - Mid-Atlantic Retro Computing Hobbyists

まだまだ何十とあるはずだし、ひょっとすると何百とあるかもしれないね。

エミュレータ製作の観点から言うと、ハードウェアの詳細な資料、ROM、それにソフトウェアダンプが必要になる。回路図は大いに役立つね。企業の多くは自社の技術をプロプライエタリと見ていて、自社ハードウェアに関する資料を一切公開しない。彼らが廃業したり製品の廃止を考えたりすると、資料は公開されず、そのシステムは時の経過とともに失われる危険にさらされてしまう。

例えば、他にも色々あるんだけど、僕はNeXTstationエミュレータの製作をやってみたいと思ってる。なんでわざわざ、OS XってNeXTstepの替わりがあるのに、と言う人もいるかもしれないけど、両者を見較べてみると、Mac 128と最新のIntel duo Mac Proの場合と同じくらい違いがあるよね。

新しいMacBookを持っていても、古いMacのソフトウェアを動かしたくなることだってあるんじゃないかな。NeXTstationの話に戻ると――プロプライエタリのハードウェアだから資料は見けられそうにない。だからオブジェクトコードを逆アセンブルしなきゃならない。資料がないと、何もかもがリバースエンジニアリング――こいつは険しい道だ。

僕はかなりツイてたし、必要な資料を入手することができた。だけど他の多くのマシンは、情報不足のために失われてしまっているんだ。

Ted: 僕には、Lisaが非常に先進的なマシンであるように思えます。ある意味、現在僕たちの周りにあるものと較べても進んでいます。これについてはどうお考えですか？

Ray: Lisaのハードウェアはそれほど面白味があるってわけじゃないんだよね。僕に言わせてもらうと、少なくとも他の同クラスのマシンと比較した場合には。Lisaのハードウェアにも非常に独特で興味を引くところがいくつかあるんだけど、Lisaの魂の鍵になっているのはやはりそのソフトウェアなんだ。なにも同じものを造るのは簡単なんて言ってるわけじゃなくて、むしろ他のミニコンにも匹敵するぐらいなんだけどね。

Lisaのハードウェアの興味深い部分を紹介しよう。技術者たちは、Lisaの設計時期に登場したばかりの真新しいCPU、68000を使った。当初MMUを動かすことは考えられていなかったが、彼らは何とか動作させるところまでこぎつけた。彼らは元々Xerox AltoにカスタムメイドのビットスライスCPUを載せたようなものにしようと考えていたんだ。彼らは、きわめて少ないチップでグラフィックを表示させる非常にシンプルな方法を考案しており、もっとも複雑な部分でもほんの少しのROMで制御されていた。Xerox Starでこれに類似するシステムは、43Hzというリフレッシュの遅さに対応する燐光体を使ったモニタを必要としていた。

Arachelian氏より補足

Xerox Starで表示に使われていた遅いハードウェアではリフレッシュレートを上げることができず、フリッカーを抑えるために長残光の燐光体を用いた特別なCRTを必要としていた。Lisaはこの問題を解消しており、通常のCRTを使用していた。

Lisa自体は、それ以前にHPでおそらくはミニコンピュータに携わっていた技術者によって作られた。Lisaはミニコンだ、あるいはほとんどそうだという人もいるかもしれないね。ハードウェア機能を装備するためにLisaにはいくつものCPU/マイクロコントローラ（68000、6504、COPS）が搭載されていた。

基板やそのコネクタクリップの中には、PDP系列といった他のミニコンのハードウェアを連想させるものがある。Lisaの物理的設計は、ハードウェアの交換をとても簡単にできるようになっていた。この観点からいって、相当に練られた設計だったんだ。ミニコンとは違って、Lisaはシングルユーザーマシンとして作られていたけどね。でもやはり、ユーザーに中を触らせようとしない閉ざされたシステムのMacとは対照的だ。Macは明らかに、設計からしてマイコンなんだよね。

ソフトウェアに目を移すと、ほとんどUnixのような感じなんだけど、大半はPascalで書かれていて68000アセンブリ言語も大量にある。ボンネットを開けてみるとOSにはマルチプロセス、メモリ保護、仮想メモリ、パイプ、データ共有などが完備されている。このどれを取っても同時代のミニコンピュータに引けを取らないよ。

歴史的な真の輝きを見せているのは、そのUI設計だ。LOS UIの背景にある研究とアイデアこそ、歴史的観点から特筆すべきものだね。Lisaはそれ以前のものと様々な面で異なっていた。それ以降に登場したあらゆるものと違っているとも言えるだろう。

確かに、PARC以来のコンセプトに基づいた工夫もたくさんあるんだけど、Lisaのデザイナーはさらに多くのものを作り出している。アイデアの大半はMicrosoft Windows 1.xや2.xにコピーされたし、Macで歳月をかけて発展していったものもあるけど、それらは興味深い工夫じゃないな。僕の考える興味深い機能がコピーされていたら普通に目にするものになっていただろうし、それゆえに期興味深くないかも知れないけどね。

Ted: LOSには、その後のオペレーティングシステムに備わることはなかったものの備えているべき機能があったかと思いますが、これについてはどうでしょうか？ あるとすればどれでしょう？

Ray: 間違いなくあったね。「文書中心の」デスクトップというアイデアは今時のデスクトップとは別世界だ。今でも文書を取り扱うわけだけど、アプリケーションを基準にして考えてるよね。例えば、「このメモを」ではなくて「このMicrosoft Word文書を誰々に送る」って感じじゃないかな。

Lisaは違っていた。文書を基準にして考えて取り扱えるようになっていたんだ、アプリケーションではなくてね。システムはその機構を隠すよう設計されていた。これは、手続き型プログラミングとオブジェクト指向プログラミングの差に似ていると思う。Lisaのデスクトップは文書に対して行動を取れるようになっていたんだ。文書とそのアイコンは、最近のものよりもずっと密接に関連付けられていて、抽象性は薄かった。いってみれば名詞のようなもので、動詞ではなかったんだ（アプリケーションが動詞にあたる）。

例えば、メモを書くのにLisaWriteの起動なんてしない。LisaWriteの版権はAppleにありますなどと書かれたスプラッシュ画面が出てきて流れを妨げたりしない。隅っこに飛び出てパタパタとうるさいペーパークリップもない。文書にどのテンプレートをコピーするかなんて訊いてきたりしない。

ただ「LisaWrite」便箋を一枚引っぺがして書き始めるだけでいいんだ。補給品入れから紙を一枚取ってきて書きこむのと大して変わらないよね。これは、表計算プログラムのLisaCalcなどといった他のプログラムにも当てはまる。もちろん、最近のOSと同様、文書間のコピー・ペーストもできた。

文書のコピーを作ると、ファイルはまったく同じファイル名で出てくる！ これは今じゃ考えられないよね。最近のデスクトップは「～のコピー」ってことを示す名前に変えてしまう。もちろんこれは表面上のトリックで、しいて言うならデスクトップに表示されるファイル名とディスクに保存されるファイル名が異なるからだけど。でもユーザーにはこれで通じるし、肝心なところは考慮してある。

5MBのハードディスク全体をバックアップするには、そのアイコンを400Kフロッピーにドラッグするだけでいい（推測ではテープのアイコンにも――Lisaのテープドライブは見たことがないので、僕の想像だけど）。そうするとデスクトップ自身がファイルを複数のフロッピーに分けてコピーしてくれて、他にもありますかと訊いてくる。その上、フロッピーのサイズよりも大きいファイルをドラッグすると、それを複数のフロッピーに分割してくれるんだ。

文書の一部が入ったフロッピーを挿入すれば、他のフロッピーも必要だと言ってきて、ファイルを再構成してくれる。これも全て、簡潔さと一貫性を保つという意図が込められてのことなんだ。繰り返すけど、別個のバックアッププログラムを動かさなくていいし、すべてがまさしく文書中心になっていたんだ、プログラム中心ではなくてね。

一日の終わりにLisaをシャットダウンするときも、Lisaは開いたもの全てを記憶しててディスプレイ上の位置を保存する。電源を入れなおすと、全てを置かれていた場所に正しく戻してくれる。デスクの幻影はきちんとその姿を保っているんだ。実生活でいうと、月曜日に仕事場に戻ったときに電卓や時計が机の引出しに仕舞われてたり書類が散らかってたりしたら、気分良くとはいかないんじゃないかな。

今じゃ、Adobe Acrobatファイルとかウェブページを開いて途中まで読んで閉じた場合、後日開きなおしてもどこまで読んだのかはわからなくなってしまう。これ、じれったいよね。確かにハイバネーションやスリープモードを使えば回避できるけど、コンピュータを再起動した場合はやはり見失ってしまう。コンピュータはそれぐらいやってくれてもいいはずだよ、Lisaがやってたようにね。

残念ながらOS XもWindowsもそこまでやってくれない。僕個人の話をすると、場所を維持しておくのは仕事の流れの上で重要だから、できるだけ再起動を避けるようにしている――だけどそうすると、そう頻繁に触らない文書にもメモリ/スワップ領域を消費させられてしまう。

Lisaはおそらく、ソフトウェア制御の電源ユニットを備えた最初期のマシンの一つに挙げられるだろう。強制電源断スイッチなんてなかった。電源スイッチは、OSの関与の及ぶ間はキーボードにあるスイッチと同じように振舞ったんだ。これはMacではIIシリーズまで、PCでは1995年以降まで無かった。

Lisaは当時としては非常に先進的だった。LOS 3.xを載せればマルチタスクマシンになり、完全なオフィススイートの入った最近のマシンが持つ機能のほとんど全てをこなしたんだ――25年も前に。

Ted: 他にこれを言っておきたいということはありますか？

Ray: 理想を言えば、Lisaでも他のエミュレータでもかまわないんだけど、マシンを実際に使ったときとまったく同じものをエミュレータで体験してみたいな。これはまず無理だろうね、僕たちが気づいていない物理的フィードバック系はたくさんあるから――キーボードやマウスの感触だとか、最新の液晶ディスプレイにはないCRTモニタのフリッカーなどなど。

スキンとかサウンドエフェクトとかの領域で近づけることはできるけど、どこまでいっても完璧にはならない。体験の史的正確さこそが、このゲームでの得点につながるんだ。

「Lisaはいつでも私の憧れの、手の届かない存在でした、でもこれで当時そのままのものを手にすることができます」という溢れんばかりの喜びが詰まった電子メールを受け取るのは、何物にも替えがたいことだ。僕が費やした時間が全て報われたって実感させてくれるよ。

Ted: Ray、我々Low End Mac全員を代表してお礼申し上げます。僕は、あなたが本当に素晴らしいことを成し遂げたと確信していますし、こうしてお話できたのも光栄に思っています。ありがとう！

Ray: 喜んで。ありがとうTed。

"Interview with Ray Arachelian, Creator of the Lisa Emulator" by Ted Hodges, Mar. 13, 2007.
Vintage Mac Living articles copyright ©2005-07 by Ted Hodges. Entire Low End Mac site copyright ©1997-2007 by Cobweb Publishing, Inc., unless otherwise noted. All rights reserved. Japanese translation published under permission from copyright holders.