パスワードを忘れた? アカウント作成
15051 story

Lisaエミュレータ作者、Ray Arachelianインタビュー@Low End Mac 46

ストーリー by Acanthopanax
不滅のLisa 部門より

airhead 曰く、

皆さんはApple Lisaというマシンをご存知でしょうか。このLisaに魅せられて情報収集・提供を行うとともにエミュレータの製作にとりくみ、8年もの歳月を経て先頃ついに1.0betaをリリースした人物がいます。今回の主役、Ray Arachelian氏です。

今回はお届けするのはLow End MacによるRay Arachelianインタビューの翻訳です。公開の許諾を快くしてくださったLow End MacのTed Hodges氏およびDan Knight氏、そしてRay Arachelian氏に、ここで改めて感謝申し上げます。

なお、Arachelian氏からはRetroMacCastで行われたインタビュー (Podcast) もお知らせいただいたので、こちらもあわせてお楽しみください(別記:m4aファイル内の関連リンク)。

(以下、airhead氏による翻訳)

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、ブログ、ポッドキャスト、催し物など、交流の場はたくさんある。

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

エミュレータ製作の観点から言うと、ハードウェアの詳細な資料、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.

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • Lisaの思い出 (スコア:4, 参考になる)

    by marinkarin (10618) on 2007年04月02日 17時18分 (#1136248)
    Lisaに付属していたLisa Officeは衝撃的でしたね。Rayさんが言っているけど,Lisaにはアプリケーションのアイコンが無い。よーく探すとあるんだけど,ものすごく深い階層に隠されていて,しかもダブルクリックしても起動しない(かったと思う)。代わりに紙の束みたいなアイコンがアプリ毎にあって,その束をダブルクリックするかTear Offを選ぶと,紙が一枚剥がれる。それが1つのドキュメントになって,これをダブルクリックすると対応するアプリが起動するようになっていた。Lisaはクローズドなアーキだったせいもあるけど,アプリとドキュメントの「関連づけ」という概念もなかった。これも言及されているけど,同じ名前のファイルが同じ階層にいくつあってもよかった。このへんは「デスクトップメタファー」に強くこだわっていたのだと思う。

    Lisa Officeは,LisaWrite,LisaDraw,LisaCalcなどのオフィスアプリの集合体で,データをお互いにカット&ペーストできた。たぶんこれもコンシューマに売られたパソコンでは初めてだったはず。当時は「統合ソフト」なんて呼ばれて,IBM-PC でも一大ブームになり,マイクロソフトは Windows を突然発表したり,Visicalc を作っていたところの VisiON,のdBASEで有名な Ashton-Tate の FRAMEWORK とか出たけど,どれもダメでした。結局 IBM-PC 用に生き残った「統合ソフト」は Lotus 1-2-3。一番統合ソフトらしくないのに。

    Lisa Officeってアプリの名前みたいだけど,実際にはマックでいうFinderの機能も一緒になってて,OSと一体化していました。

    あとアップルの悪いくせで,フロッピー(5インチ)が独自のもので,やたら高いメディアを買わないといけなかった。Lisa2になって,マックと同じ3.5インチになった。

    たしか一年かそこら遅れてマックが出たんだけど,アプリアイコンを起動できるは,ショートカットはあるは(Lisaにはショートカットはなかったはず)で,「なんちゅーパソコンみたいなマシンだ」と思ったことを覚えています。
    • by ctrl_alt_meta (19732) on 2007年04月02日 20時37分 (#1136304)
      たしか一年かそこら遅れてマックが出たんだけど,アプリアイコンを起動できるは,ショートカットはあるは(Lisaにはショートカットはなかったはず)で,「なんちゅーパソコンみたいなマシンだ」と思ったことを覚えています。


      アイコンで起動できるパソコンなんて当時有りましたっけ?
      親コメント
      • by marinkarin (10618) on 2007年04月03日 12時26分 (#1136581)
        >アイコンで起動できるパソコンなんて当時有りましたっけ?
        いや,ありません。僕が言いたかったのは「アプリから起動するパラダイム」ってことですね。Lisaは「ドキュメントを操作するパラダイム」だったので。
        親コメント
      • by Anonymous Coward
        た・ま・に・は! Amiga [wikipedia.org]のことも思い出してくださいっ! 正確には、Amigaの登場は1年ほど後ですが。
        • by Anonymous Coward
          つまり元コメントの意図である「パソコンみたい」ってのはAmigaみたいってこと?
    • by Yohsa (2572) on 2007年04月03日 1時31分 (#1136433) 日記
      ショートカット(エイリアス)はSystem7からですぜ。(91年)
      ひょっとしてキーボードショートカット?
      親コメント
    • by Anonymous Coward
      > 代わりに紙の束みたいなアイコンがアプリ毎にあって,その束をダブルクリックするかTear Offを選ぶと,紙が一枚剥がれる。それが1つのドキュメントになって,これをダブルクリックすると対応するアプリが起動するようになっていた。

      これが、アプリアイコンをダブルクリック→無題ドキュメントを開いて起動、に比べてどう便利なのかが理解しかねる
      • by ctrl_alt_meta (19732) on 2007年04月02日 20時49分 (#1136308)
        便利かどうか、というよりは、パラダイムの問題かと。
        後のOpenDocに見られるようなドキュメント中心パラダイムのハシリだと言うことでしょう。

        結局ドキュメント中心パラダイムはOpenDocの挫折とともに一旦の終焉を迎えましたが。
        親コメント
        • by Anonymous Coward
          なるほど

          iTunesみたいなものをドキュメント中心でやると死ねそうと思った
      • by marinkarin (10618) on 2007年04月03日 12時57分 (#1136603)
        >これが、アプリアイコンをダブルクリック→無題ドキュメントを開いて起動、に比べてどう便利なのかが理解しかねる
        マジですか。当時はまだGUIを備えたパソコンは無かったわけで,パソコンは特殊なスキルを身につけた人のツールでした。LisaはEasy-to-use(これを言い出したのもたぶんLisa)を標榜して,「誰にでも使えるパソコン」を目指したのです。パソコンをまったく使ったことの無い人(でもビジネスのスキルのある人)がターゲットでした。そこでAppleがとった手段が「デスクトップメタファー」でした。実際の机の上での作業のようにパソコンが使えれば,パソコンを使ったことがない人でも使えるんじゃないかと。「アプリの起動」なんてのは,専門家以外には理解不能なメタファーですから,Lisaからは排除されたのです。オレが作ったわけじゃないから真相は分らんけど。
        親コメント
        • by Anonymous Coward
          > 「アプリの起動」なんてのは,専門家以外には理解不能なメタファーですから,

          Lisaの設計者はユーザーを低能扱いしていたわけですね。
          • by marinkarin (10618) on 2007年04月04日 0時42分 (#1136873)
            >Lisaの設計者はユーザーを低能扱いしていたわけですね。
            全然違うじゃん。まあACに理解しろってほうが無茶か。
            親コメント
        • by Anonymous Coward
          > 「アプリの起動」なんてのは,専門家以外には理解不能なメタファーですから

          ところで、ワープロ専用機になるとどういう風に考えればいいのですかね。

          電源を入れると「編集」とか「文書整理」とかのメニューが出てきて、
          今で言うワープロソフトは立ち上がっているけれど、そのままでは
          目の前に紙はありませんよね。

          さらに、この機能を選んでからデータ入力、もしくはデータ参照という
          操作体系は、ビデオの録画予約、HDレコーダや携帯電話の操作全般にも
          当てはまるでしょう。

          もっと広い意味で考えると、車の運転も該当するんじゃないですかね。
          • by marinkarin (10618) on 2007年04月04日 17時02分 (#1137271)
            >もっと広い意味で考えると、車の運転も該当するんじゃないですかね
            TRONの坂村さんなんかは「誰でも使えるというのがそもそも幻想で,車の運転のように練習すれば使えるようになればいいのだ」と言ってました。
            Lisaが登場したときにはGUIを持つパソコンはありませんでした。だから「アプリのアイコンから起動」する操作(今のWindowsやMacはみんなそうですが)は比較対象にならなかったのだと思います。内部的には試したのかもしれませんが,少なくとも「ドキュメント中心の操作の方が,より分かりやすい」という結論になったのではないでしょうか。お手本にしたのはXEROXのAlto(のSmalltalk)か,Starあたりらしいけど,あのへんのマシンも「アプリの起動」みたいな操作はありませんよね。
            つまり必要なものはみんな「そこにある」ような操作系がLisaの目指したものなんだろうと思います。紙も計算機も筆も時計もそこにあって,いちいち起動しない(というか起動を意識させず,ドキュメントの作成に集中させる)。

            # ちなみに古いアップルのHIG(Human Inteface Guideline)にはモードに関する記述があって,「アプリは1つのモードである」と書いてあったと記憶しています。
            親コメント
      • by Anonymous Coward
        保存したときに「どこに保存したんだっけ?」というのは割とあると思います。私もたまにやります(汗

        このやり方の場合、そういったことはなくなるでしょう。
      • by Anonymous Coward
        > 代わりに紙の束みたいなアイコンがアプリ毎にあって,その束をダブルクリックするかTear Offを選ぶと,紙が一枚剥がれる。

        確かBTRONも同じ。

        最初に白紙を取り出してから作業を始るようになっている。

        # 使ったことはないけど。
  • ありがとうございます (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2007年04月02日 13時31分 (#1136182)
    翻訳ありがとうございます。作者のわくわくには遠くおよばないですが、読んでいてわくわくしてきました。

    無精なので実際に手を動かすことはあまりないのですが、こういう「ものづくり」の話を見たり読んだりするのは好きです。

    LisaはMacの元になったとか、その程度しか知らないので、ちょっと調べてみようっと。
  • 日本人作者 (スコア:1, 興味深い)

    by Anonymous Coward on 2007年04月02日 13時43分 (#1136187)
    日本人でも何人か(数えるほどの)エミュレータ作者がいるね。彼らに対してのインタビューも聞いてみたい。
    • by Anonymous Coward on 2007年04月02日 21時59分 (#1136329)
      この作者ほどの苦労はしてませんが…

      Z80のフラグ挙動で「不定値」と定義されているものがあります
      ところが実物のZ80では特定の値になるようになっていて(どこのZ80でもそうだったらしい)
      規格どおりにエミュレートしても実際には動かない、というのがありました
      規格外の挙動に依存されるとキツいです

      あと日本人作者の苦労話なら、スパカセの解析 [interq.or.jp]が壮絶でしたね
      特殊機能の嵐で数ヶ月かかったそうです

      親コメント
  • by Anonymous Coward on 2007年04月02日 12時09分 (#1136151)
    色々なエミュレータがありますが作り方の概念とかの本がありましたらお願いします。

    タイマーで切って、命令やらハードの処理をやっていくのだと思いますけど
    色々と高速化ってあると思うのです。興味があるのでできましたらお願いします。
    • by Anonymous Coward on 2007年04月02日 14時33分 (#1136208)
      エミュレータを作る上でネックになるのは、Ray Arachelian氏のお話にもありますがタイミング合わせですね。
      当たり前の話ですけど、実機の各チップは並列に動作しています。場合によっては、わずかにそのタイミングが狂うだけで正常動作しなくなるものもありますので。
      この辺り、いかに手を抜けるか(コーディングの手抜きではなく、タイミング合わせの)が高速化に大きく関わってくるはずです。
      ただ、実機の動作を再現することを目的としたエミュレータは実機以上の速度を出す必要はありませんから、常に速度を求められるVMwareのようなものよりはずっと楽だと思います。
      親コメント
    • by kazooya (6111) on 2007年04月03日 0時00分 (#1136387) ホームページ
      いわゆるエミュレータそのものではなくてVM全般についての本だけど、結構参考になると思います:
      Virtual Machines: Versatile Platforms For Systems And Processes
      http://www.amazon.co.jp/Virtual-Machines-Versatile-Platforms-Architect... [amazon.co.jp]

      # 日本語で読みたい人っていますか?
      親コメント
    • by Anonymous Coward on 2007年04月02日 12時54分 (#1136168)
      具体的な本はしらないんだけど構造的には、
      インタプリタや OS の仕組みがそのまま適用できるはずなので、
      その手の参考書が使えると思う。

      CPU までエミュレートするタイプの完全なエミュレータの場合、
      多分インタプリタと構造的には同じはず。
      従って高速化の技術も JIT とかインタプリタのそれがそのまま使えるはず。

      エミュレートする環境とエミュレータを乗せる環境で CPU が同一である場合、
      例えば VMWare 等は I/O 周りとか主にハードウェアの差異だけをエミュレートしてるらしいけど、
      これは、特権違反、バスエラーやアドレスエラー等の割り込みをフックして
      エミュレートルーチンに飛ばしてるはず。
      これはどちらかと言えば OS の構造に近いんだと思う。
      親コメント
    • by Anonymous Coward on 2007年04月02日 13時39分 (#1136186)
      おすすめできる本は無いけど、既存のエミュレータのコードを読んでみると 良いかもしれない。mame,mess,snes9xのようなゲーム機のエミュレータはかなり 完成されているし、それなりにうまくうごく。 Web上だとこの辺 [infoseek.co.jp]だろうか。あとinfonesの人のところ。
      親コメント
    • 第一人者のMarat氏 [komkon.org]のページはどうでしょうか。
      Z80,6502のソースコードもあり、大変参考になります。
    • MAMEからCPUのコードを拝借してBIOSファイルを食わせる(0番地を指定して走らせる)とそれなりに動くかも。大変なのはそれから先、デバイス系統でしょうか。
    • きっともうすぐ「萌えるえみゅの作り方」ってのが出るから待ってるとよいよ。
  • by Anonymous Coward on 2007年04月02日 23時36分 (#1136373)
    動かす環境手元にないけど(´・ω・`)
typodupeerror

普通のやつらの下を行け -- バッドノウハウ専門家

読み込み中...