MacWorks Plus: Lisa に Macintosh を話させる

チャールズ・T・ルカゼフスキー著
サン・リマーケティング社
マックテック・クォータリー
1989年春号 54ページ

Apple の Lisa コンピューターにはチャンスがなかった。

ウィンドウとマウスは時代を先取りしていました。高級スポーツカーの値段は、最低限の設定しかないLisaシステムよりも安かったのです。そして、Lisaの衰退と最近の復活を決定づけた最大の障害は、スティーブ・ジョブズがLisaを欲しがらなかったことであり、それには十分な理由がありました。ジョブズの寵児であったMacintoshというコードネームは、Lisaの1年後に3分の1の価格で発表されました。

Lisaの販売実績は散々だったにもかかわらず、ユタ州ローガンのSun Remarketingをはじめとする数社の努力により、Lisaは今もなお販売、サービス、サポートを受けています。この取り組みにおける私の役割は、Sun Remarketing向けに、MacWorks Plusという新しいLisa用オペレーティングシステムを開発することでした。MacWorks Plusは、LisaでMacintosh Plusを完璧にエミュレートすることを可能にします。これは、64K ROM搭載Macintoshの不完全なエミュレーションであったMacWorksというプログラムの後継です。これはMac技術コミュニティにとって当然の関心事であるため、この記事では旧MacWorksの動作を分析し、新MacWorksの開発で遭遇したいくつかの障害について考察します。

歴史的背景

Lisaユーザーコミュニティとクパチーノの一部オフィスでは、AppleはLisaを廃止しようとしているという主張が広がっています。後知恵で見れば、そのような主張には明らかに経験的な根拠がありますが、もはや真実ではありません。AppleがMacWorks Plusの開発を許可するという新たな姿勢は、ジョン・スカリーの世代交代を改めて示す、喜ばしい証拠です。

Lisa の存続は常に Macintosh にかかっていました。1984 年の初めには、Lisa Office System だけでは Apple の Lisa の在庫を終わらせることはできないと認識され、Lisa は Macintosh で話す必要がありました。そこで、Rich Castro という Apple 社員の空き時間プロジェクトが、正式に MacWorks として位置づけられました。これは 64K ROM の実装であり、Lisa の長方形のピクセルを正方形に変換するアップグレード キットとともに販売されました。Lisa は、10MB のハードディスクに加えて最大 2MB のメモリを搭載できたため、なんとか魅力的なままでした。これは、Mac がわずか 128K のメモリしか搭載しておらず、ハードディスクはどこにも見当たらず、「ディスクを挿入してください」というメッセージが私たち全員の良き友だった当時のことでした。

しかし、Mac Plusの登場により、Lisaは残っていた競争力をほぼすべて失ってしまいました。MacWorksはHFS、Apple Share、そして128K ROMと新しいシステムソフトウェアの機能を利用するプログラムの増加に対応していませんでした。これらの問題は、Sun Remarketingで最も深刻に感じられました。Sunは、Appleから生産終了製品の販売とサービス提供を認可された世界で唯一の企業です。また、しばらくの間、Lisaに関するあらゆる苦情の相談相手でもありました。何らかの対策を講じる必要がありました。

マックワークス

初代MacWorksは、Macintoshオペレーティングシステムを他のコンピュータに移植した最初の例でした。LisaとMacintoshのアーキテクチャは根本的に異なっていました。Lisaはコンテキストスイッチと論理メモリマッピングをサポートするメモリ管理ユニットを搭載していましたが、Macintoshはハードマップされたアドレスラインを使用していました。LisaにはDMAをサポートする拡張スロットが3つありましたが、Macintoshにはそれがありませんでした。Lisaは電源のオン/オフをプログラムできるインテリジェントキーボードプロセッサを搭載していましたが、Macのキーボードはツチブタほどの知能しかありませんでした。LisaにMacintoshの言語を話させるには、Macintoshのハードウェアインターフェースを捨て去り、新しいインターフェースを用意する必要がありました。

もちろん、Appleは既にLisa用のハードウェアインターフェースを用意していました。実際、選択肢はLisa Office System/Lisa WorkshopインターフェースとMonitorインターフェースの2つでした。MonitorオペレーティングシステムはLisaの最初の開発環境でした。これは本質的にApple /// Pascal Workshopの移植版であり、8年前から誰もが知っていて愛用していた、1文字のコマンドラインによるテキストのみの出力を継承していました。AppleがMonitor OSをMacWorksのハードウェアインターフェースとして選んだのには、非常に明確な理由があります。デバイスドライバとそのI/Oコマンドブロックの構造が、Macで使用されているものとほぼ同じだったからです。

こうして、Monitorデバイスドライバ、新たに書き直された割り込みハンドラ、そしてMac Toolboxのソースコードが統合され、MacWorksという製品が誕生しました。この時点でAppleはLisaの設計にも変更を加え、Macintosh XLとして販売を開始しました。ここで注目すべきは、MacWorksの設計に関するこれらの決定が、そのパフォーマンスとMacアプリケーションとの互換性に一定の制限を設け、MacWorks Plusの開発の土台を築いたということです。

モニターオペレーティングシステム

あらゆる種類のMacintoshエミュレータを実行するには、システムが何らかのブートストラップとロード手順を実行し、エミュレータをインストールして検出や上書きから保護する必要があります。また、エミュレータを起動する前に、ソフトウェア環境を可能な限りMacに近づけておく必要があります。

MacWorksはこの問題にうまく対処していませんでした。Monitor OSはMacWorksの基盤で動作していたため、特定のメモリ領域はソフトリスタートの度にそのまま保持する必要がありました。これらの領域のいくつかは、Macが通常トラップディスパッチテーブルなどの独自の情報を配置する低メモリ領域にありました。さらに、Monitorは起動時にファイル管理カーネルを必要としていましたが、MacWorksが独自のカーネルを使用している間はアイドル状態だったため、メモリを無駄にしていました。この問題は、Monitorが使用するブートストラップ技術を分析することで最もよく理解できます。

Lisaは、ROMにオペレーティングシステムを搭載していなかった最後のAppleコンピュータです。Lisaの電源を入れると、ROMには診断テストとブートデバイスの選択に必要なコードしか格納されていません。もちろん、LisaのMMUがエミュレータの物理メモリを実際のMacintoshで想定される$00400000の範囲に容易にマッピングできることを考えると、LisaはMac OSを移植するのに理想的なマシンです。ブートデバイスが選択されると、ROMはそのデバイスのセクタ0をアドレス$00020000にロードし、実行を開始することで、ブートプロセスのステージ0を完了します。

Monitor & MacWorksでは、セクタ0の512バイトのコードは、初期のオペレーティングシステムカーネルをロードする必要があります。このカーネルはディスク上の任意の場所に配置されている可能性があるため、ステージ1のブートコードが参照できる場所にポインタを配置する必要があります。これは、ディスクの2番目のセクタの2番目のワードにオフセットを設定することで実現されます。ステージ1のブートコードはこの値を取得し、2を減算して、デバイスをこのセクタに配置します。次に、アドレス$00020800の8つのセクタをロードし、制御を移します。

モニターのブートプロセスは非常に柔軟ですが、特定のファイルに大きく依存します。すべてのブート可能なモニターディスクには、少なくとも4つのファイル（MON.LOADER、MONITOR.OBJ、CONFIG.DATA、BOOTFILES.DATA）が含まれています。MON.LOADERファイルには、ステージ1のブートコードによってロードされる8つのセクターが含まれており、セクター2のオフセットを使用することで、ディレクトリ検索を低コストで回避できます。ただし、MON.LOADERにはディレクトリ検索コードが含まれており、これを使用して一連のファイルを読み込みます。まず、CONFIG.DATAファイルがメモリページ1に読み込まれます。これは、モニターに必要な初期の低メモリグローバル変数のいくつかを定義します。次に、MONITOR.OBJがメモリのかなり上位から読み込まれます。最後に、BOOTFILES.DATAが読み込まれます。このクリアテキストファイルには、ブートプロセスを完了するために読み込まれる一連のファイル名が含まれています。このファイルのエントリは、1バイトのファイルタイプフィールドと15文字の名前で構成されます。これらのファイルは、出現順にロードされます。これが完了すると、制御は MONITOR.OBJ に移り、モニター OS が起動します。

このアプローチは確かに機能しますが、MacOS への移植において許容できないほどのリソース制限を課してしまいます。最も明白な問題は、ファイル指向のオペレーティングシステムが 2 つ存在し、そのうちの 1 つは起動後にまったく使用されないことです。使用されないコードによってメモリが浪費されるだけでなく、その 2 番目のオペレーティングシステム用のディレクトリなどのオーバーヘッドのために、大量のディスク領域がアイドル状態になります。これはハードディスク上では特に問題となります。オペレーティングシステムを分離するには何らかのパーティション分割が必要になるからです。では、MacWorks は何をするのでしょうか。それは、400KB のディスクの完全なイメージをハードディスクにコピーし、念のため 100KB を追加で必要とするだけです。MacWorks はそもそも約 100KB しか必要としないため、この無駄は莫大なものになります。

このアプローチでは、Macアプリケーションはハードウェア依存のタスクを実行するために2段階の呼び出しを経る必要があるため、パフォーマンスにも制限が生じます。これには、画面への描画、サウンド生成、ストレージデバイスのI/Oなどが含まれます。

Macintoshオペレーティングシステム

Inside Macintosh の低メモリシステムグローバルのリストを真剣に読んだことがあるなら、Macオペレーティングシステムが本当に移植性が高いことが一目瞭然です。「ビーバー、ハードウェア依存のパラメータが全部あるじゃないか！」 「おやまあ、ウォーリー、画面サイズ、ピクセル解像度、デバイスアドレス、割り込みベクター、メモリレイアウト、その他諸々があるんだ。この移植は芽キャベツを食べるより簡単だろう！」

真面目な話、Appleはコンピュータシステム全シリーズで一貫性があり、変更や拡張の可能性が非常に高いオペレーティングシステムを開発するという素晴らしい仕事を成し遂げました。実際、Appleは最初からこれらの特性を活用してきました。このレベルの一貫性を実現するために、Appleは比較的コストのかかる方法を選択しました。それは、各Macintoshの低メモリ領域に集約された構成データベースを置くというものです。ハードコードされていない情報を参照するのにサイクル数がかかるため、コストがかかるのです。しかし、異なるアーキテクチャ上でのオペレーティングシステムの再構成が極めて簡単になるのであれば、コストを気にする人はいないでしょう。

Appleがオペレーティングシステムの移植作業の全てを省いたわけではありません。移植作業は時間がかかり、しばしばフラストレーションの溜まる作業です。しかし、Appleはハードウェア依存のカーネルをmacOSの他の部分から明確に分離することを可能にしています。このカーネルを別のコンピュータ用のカーネルに置き換え、低メモリのグローバル変数を適切に設定すれば、残りの部分は変更する必要がありません。AppleはオリジナルのMacWorksでまさにこれを実現しました。

マックワークスプラス！

1987年後半には、MacWorksに何らかの対策を講じる必要があることは明らかでした。既に述べた問題に加え、MacWorksは初代Macintoshの64KB ROMをベースにしていたため、5.3/3.2以降のシステムソフトウェアは動作せず、ROMとシステムソフトウェアの最新バージョンに依存する多くのアプリケーションも動作しませんでした。また、Sun RemarketingはLisaとHFS向けに800KBのフロッピーディスクドライブを開発していましたが、これらの変更によってメモリ消費量が増加し、ハードディスクのシステムオーバーヘッドが約2倍に増加しました。さらに悪いことに、MacWorksはSunの新しい40MB内蔵ハードディスクのうち、わずか32MBしか使用しませんでした。

MacWorks Plusは、前モデルを悩ませていたパフォーマンスと互換性の問題をすべて解消しました。その成果は、重要な統計データからも明らかです。オペレーティングシステム全体の速度は25%向上し、Quickdraw™の動作は30%から40%高速化しました。システムソフトウェア6.0.​​2は、MultiFinder™を含め、完璧に動作します。MPW 2.0.2、HyperCard 1.2.1、Tops 2.0.1、Lightspeed C 3.0、TMon 2.81、FullWrite 1.0、Excel 1.5、Crystal Quest 2.2など、数多くのアプリケーションも完璧に動作します。さらに、MacWorks PlusはSCSIインターフェースとあらゆるサイズのディスクドライブをサポートしています。

MacWorks Plus の機能強化は、ブートコード、ハードウェアインターフェース、オペレーティングシステムの 3 つのカテゴリに分けられます。ブートコードは完全に書き直されたため、メモリ内の無駄なコードを排除し、同時にディスク消費量を 200K まで削減することができました。Monitor OS で使用されていたマルチファイル方式は廃止され、メモリ管理、マシンの初期化、MacWorks Plus ROM イメージのロードを処理する単一のステージ 2 ローダーが採用されました。このソリューションには、他にも利点があります。まず、オペレーティングシステムのグローバルを保持する必要がないため、ソフトリスタートで使用可能なメモリをすべてクリアできます。以前のオペレーティングシステムの痕跡をすべて消去するという優れたプログラミング手法であることに加え、これは一部のプログラムにとって互換性の確保に不可欠です。次に、さらに重要な点として、すべてのシステムグローバルを適切な場所に配置できるようになりました。たとえば、MacWorks の $00411000 に配置されていたトラップディスパッチテーブルは、適切な場所に移動されました。

2つ目の機能強化は、ハードウェアインターフェースの書き換えでした。これもプロジェクトの中で最も時間を要した部分でした。可能な限りMacWorksのコードをベースに構築し、不足していた制御呼び出しや機能を追加しました。残念ながら、この方法はハードディスクドライバ、AppleTalkドライバ、そしてその他のドライバの一部にしか適用できませんでした。Sony、サウンド、シリアルドライバはゼロから開発しました。MacWorks Plusのすべてのドライバは、現在Inside Macintosh全5巻の仕様に準拠しています。 

64K ROMと128K ROMの非常に顕著な違いの一つ、つまりROMにおけるデバイスドライバの扱いは、新しいハードウェアインターフェースの実装にも大きな影響を与えました。64K ROMでは、ドライバはユニットテーブルにハードベクターがインストールされた単なるコードリソースです。フォントやカーソル、その他のシステム情報も同様に保存されます。しかし、128K ROMでは、Appleはこれらの要素はいずれにせよリソースであるため、リソースとして保存すべきだと判断しました。そのため、Mac Plusの$004176F8から$0041FFFFまでのメモリは、オープンリソースファイルを模倣し、それにアクセスするための特別なフックフラグが$00000B9Eと$00000B9Fに設定されました。

言うまでもなく、ROM リソース ファイル マップも含め、この情報はすべてハードコードされています。$0040001E のロングワードは、ROM リソース ファイル マップの開始を指し示します。このフォーマットは標準マップとは大きく異なります。次にリソース データが始まり、ROM の最後まで続きます。私たちは、デバイス ドライバを実装する最も簡単な方法は、独自の完全な ROM リソース ファイルを生成し、それを MacWorks Plus エミュレーターに追加することだと判断しました。128K ROM に CRSR、FONT、MDEF、WDEF などの汎用リソース タイプをすべて含め、独自のリソース タイプにリンクしました。たとえば、起動時に表示される Sun Remarketing のロゴは、ROM リソース ファイル内に PICT として保存されます。その後、この標準リソース ファイルを ROM イメージ ファイルにレンダリングし、それを MacWorks Plus ROM イメージに追加するために、非常に問題の多いコードが開発されました。私たちはこの手法で大きな成功を収めました。繰り返しになりますが、私たちは、間に合わせの方法でエミュレーションを行って非互換性のリスクを冒すよりも、エミュレーションを完璧にするために少し余分な作業を行うことを選択しました。

パフォーマンスの向上は主にオペレーティングシステムの領域であり、これは拡張機能の 3 番目のカテゴリです。新機能とアップグレード機能の 2 種類があります。新機能には、HFS ファイルマネージャ、SCSI マネージャ、リストマネージャ、および Inside Macintosh Volume IV で導入されたその他すべてのシステムトラップコールが含まれます。アップグレード機能には、Quickdraw コールなど、いくつかの低速なサブルーチンの書き換えが含まれます。これらのオペレーティングシステムの機能強化は、MacWorks Plus とその前身との違いの中で最も目に付くものですが、完了に要した時間も最も短いものでした。ユーザーが目にする MacOS はすべてハードウェアに依存しないため、ほとんど手間をかけずにマシン間で移動できます。たとえば、SCSI サポートは Lisa にとって最も劇的な改善点の 1 つですが、ソフトウェアの観点から見ると、おそらく最も手間がかかりません。SCSI アドレス行が Lisa と Mac でまったく同じ場所にマップされている限り、SCSI をサポートするためのコードを書き直す必要はほとんどありません。

開発者にとっての問題

Macintosh 用に作成したアプリケーションは、1 つの条件を満たす限り、MacWorks Plus で動作するはずです。それは、ルールに従うことです。Inside Macintosh で定められたガイドラインを順守していないソフトウェア パッケージは数多く存在しますが、多大な努力と巧みなシステム パッチのおかげで、今では Lisa 上で動作するようになっています。こうした違反を追跡する専門家になった私の経験では、違反は一般に環境チェックとハードウェア インターフェースの 2 つのカテゴリに分類されます。comp.sys.mac.programmer をご覧になっている方は、非標準の環境チェックに関する私の長々とした批判を既にご覧になっていると思いますので、ここでは簡単に説明します。_SysEnvirons を使用して実行時環境を判定しないアプリケーションは数多く存在します。これは、低メモリ グローバルを読み出す方が速いか、_SysEnvirons が不完全であるためです。良い例としては、新しい Microsoft アプリケーションが実行する、$00500000 にある浮動小数点コプロセッサの直接チェックが挙げられます。

ハードウェアインターフェースは2つ目の問題領域です。例えば、MacのVIAチップを直接参照するアプリケーションがあります。LisaではVIAは別の場所にあるため、それを指す低メモリグローバルも異なります。しかし、Mac PlusのVIAのアドレス$00EFFFFEは、Lisaのスクリーンベースレジスタのアドレスと同じです。ご想像のとおり、これはかなり厄介なクラッシュを引き起こします。

これはLisaの問題であると同時に、Macintoshの問題でもあることを強調しておきます。システムソフトウェア7.0のリリースが間近に迫っており、コンテキストスイッチが現実のものとなり、低メモリグローバル変数への参照が権限違反を引き起こす可能性もあることを考えると、物理環境への依存を可能な限り少なくすることが賢明なプログラミング手法です。Apple Developer Technical Servicesの立場は一貫していないのは事実です。しかし、それ自体が彼らの現在の推奨事項を無視する理由にはなりません。それに、IBMから得られる不正確な技術情報と開発者サポートの完全な欠如よりも、Appleから得られる一貫性のない立場と正確な技術情報の量の方が良いでしょう。

今提示した意見は、Apple Computer から報酬を受け取ったものではありません。

環境チェックとデバッガー

何らかの理由でLisaを使用しているかどうかを判断する必要がある場合、_SysEnvironsはそれを実行しなくなりました。_SysEnvironsはMac Plusを返します。以下の比較が真であれば、Lisaを使用しています。

CMPI.L #’MACW’,$00400040; Lisa check

最後に、MacWorks Plusでのデバッガの使用について少し触れておきます。人気のデバッガであるMacsBug V5.5、Nosy Debugger、TMon V2.xxは、いずれもそのまま使用できます。NosyとTMonは動作に改造の必要がなく、MacsBugはキーボード入力ルーチンの置き換えのみで動作します。これは、特別なバージョンを必要としないため、システム起動時にメモリイメージに対して行われます。もちろん、MacWorks Plusは128K ROMの堅牢な実装であるため、Lisa背面のNMIボタンを押すことでROMデバッガを起動することもできます。

MacWorks Plus! が開発者にとって重要な理由

ソフトウェア開発は、I/O に大きく依存する作業です。プログラマーの生産性は、コンパイル/リンク サイクル時間に反比例する割合で向上します。アプリケーションが堅牢でハードウェアに依存しないことが確実であれば、そのユーザーも恩恵を受けます。Lisa と MacWorks Plus は、この両方の領域で重要な貢献をします。Lightspeed C と MPW の両方をヘビー ユーザとして、私は Lisa と Macintosh SE の速度差にすっかり魅了されました。コンパイル/リンク サイクルが 30 秒以上の場合、Sun 内蔵の 20MB または 40MB ハードディスクを搭載した Lisa は、アクセス レートが 30ms を超えるハードディスクを搭載した SE よりも常に高速です。MPW で MacWorks Plus を最初からコンパイルするには、SE で 20 分、Lisa で 17 分かかります。Lisa は Mac よりも 3MHz 遅いため、I/O の違いはさらに顕著になります。

MacWorks Plusを搭載したLisaは、ToolBox検証スイートとしても価値があり、A/UX™を搭載したMac IIよりもはるかに安価です。12インチの画面は、特に大型モニターとビデオカードが予算に合わない場合、マルチウィンドウ開発システムを効果的に活用するのにまさに理想的です。

謝辞

MacWorks Plusの開発作業はすべて私が担当しましたが、多くの方々に深く感謝しています。彼らなしではMacWorks Plusは実現しませんでした。Sun RemarketingのBob Cook氏とDale Gilbreath氏、AppleのDave Ramsey氏、Dan Allen氏、Steve Schwartz氏、Rich Castro氏、そしてMac ROMチームの皆さん、Dave Heinen氏、Steve Jasik氏、Sam Neulinger氏、そしてBruce Auerbach氏です。最後に、Harold Stuart氏には、コードの提案、Lisaに関するヒント、Lisaに関する不満の共有、人に関するアドバイス、そしてユタ州ローガンでの1ヶ月間、毎日私に新しい発見を与えてくれたことに心から感謝します。

著者について

チャック・ルカゼフスキーは、ミネアポリスに拠点を置くOpen Systems Architects, Inc.™の社長です。同社は、企業顧客向けのコンピュータデータネットワークの計画、導入、管理を行っています。Sun RemarketingでのLisaおよびMacintosh関連の業務に加え、ミネソタ・スーパーコンピュータ研究所のGould高速画像処理システム向けアプリケーションソフトウェアの開発と運用管理に携わり、ミネソタ州セントポール周辺の様々な組織向けにソフトウェアを開発・提供しています。IntelマイクロプロセッサとMotorolaマイクロプロセッサに関する彼の意見は、あくまでも彼自身のものです。