Hatari – オンラインAtari ST/STE/TT/Falcon エミュレータ

WebAssemblyにおけるエミュレーションアーキテクチャ：68000ハードウェアをブラウザへ

Hatariのブラウザ実装は、特定の技術的問題に対処しています。ネイティブコードで実装されたサイクル精度のCPUエミュレータをWebAssemblyに移植しながら、元のハードウェア動作への機能的忠実性を保つことです。C言語で実装された元のHatariエミュレータは、Motorola 68000プロセッサファミリをサイクルレベルの精度でシミュレートしています。これは設計要件であり、CPU操作とペリフェラルデバイス間の正確なタイミング関係に依存する元のソフトウェアの未修正実行を可能にします。

WebAssemblyへの移植は測定可能な制約をもたらします。エミュレータは完全なシステムアーキテクチャをシミュレートする必要があります。GLUEチップ（メモリ管理）、MFP 68901（ペリフェラル制御とタイミング）、YM2149サウンドシンセサイザー、Shifterビデオコントローラです。各コンポーネントは定義された周波数で動作します。ST/STEではCPUが8MHz、Falconでは16MHz、ビデオは50Hz PALまたは60Hz NTSCです。ソフトウェアが利用する同期依存関係があります。WebAssemblyはほぼネイティブの実行速度を提供します。計算集約的なワークロードではネイティブC実装の約80～90%のパフォーマンスです（Zakai, 2011）。ただしエミュレーションのホットパスの最適化は依然として必要です。ブラウザ版はデスクトップHatariとのフォーマット互換性を維持し、同一のROMとディスクイメージ入力を受け入れることで、実装の相違を減らしています。

この技術的アプローチは特定のユースケースを可能にします。ネイティブアプリケーションのインストールなしに、標準的なウェブブラウザを通じてAtariソフトウェアにアクセスすることです。トレードオフは、ユニバーサルなプラットフォーム可用性と引き換えに、わずかなパフォーマンスオーバーヘッドを受け入れています。

Atari STエコシステム：保存が重要である理由

Atari STラインは1985年から1992年にかけて、特に西ヨーロッパで独特の市場ポジションを占めていました。ピーク時にはパーソナルコンピュータ市場の約15～20%を占めていました（Reimer, 2009）。このプラットフォームの特徴は標準的なMIDI接続性でした。これにより音楽制作ソフトウェアの主要プラットフォームとしての地位を確立しました。Cubase（元々Notator）やSteinbergのフラッグシップDAWを含むアプリケーションはSTで生まれ、現代の音楽制作に今も存在するワークフローを定義しました。プロフェッショナルミュージシャンは2000年代まで特定のソフトウェア実装のためにSTシステムを保持していました。特にMIDIシーケンサーと合成環境は他のプラットフォームに移植されることはありませんでした。

STはまた重要なゲーム開発の拠点でもありました。特にヨーロッパのパブリッシャー向けに開発されたタイトルで、地域外での流通が限定的またはなかったものです。このソフトウェアはエミュレーション以外での保存が限定的な文化的成果物を表しています。元のハードウェアはコンデンサの故障とストレージメディアの劣化により、ますます信頼性が低下します。エミュレーションを通じた保存は以下へのアクセスを維持します。

  • クリエイティブツール：音楽制作ソフトウェア、グラフィックスアプリケーション、開発環境。これらは後続のプラットフォーム設計に影響を与えました
  • 文化的作品：地域のコンピューティング慣行とエンターテインメント嗜好を記録するゲームとアプリケーション
  • インターフェースパラダイム：GEMデスクトップ環境とTOSオペレーティングシステム。制約されたコンピューティング環境に適用可能なリソース効率的な設計原則を実証しました

STの技術的制約は16ビット68000 CPU、512KBベースRAM、320×200ピクセルディスプレイです。これらは後続のコンピューティングに影響を与えた設計決定を強制しました。保存はこれらの設計トレードオフとその歴史的文脈の研究を可能にします。

ブラウザベースのエミュレーションパフォーマンス：技術的制約と最適化

ブラウザ内のサイクル精度エミュレーションは、ネイティブ実装に存在しないパフォーマンス課題に直面します。エミュレータは正確なタイミング関係を維持する必要があります。CPUはST/STEで8MHz、Falconで16MHzで実行されます。ビデオコントローラは50Hz（PAL）または60Hz（NTSC）でリフレッシュされます。サウンドチップは49.152kHzでサンプルを生成します。ソフトウェアはこれらのタイミング関係に依存しています。例えば、割り込みハンドラは特定のサイクル数内で実行される必要があり、ディスクアクセスのタイミングはコピー保護されたソフトウェアが正常に機能するかどうかを決定します。

ネイティブエミュレータは高解像度タイマー（マイクロ秒またはナノ秒の粒度）とCPUアフィニティを通じてタイミング精度を達成します。これにより専用コアはプリエンプションなしでエミュレーションループを実行できます。ブラウザはどちらも提供しません。JavaScriptのイベントループは予測不可能なレイテンシを導入します。ブラウザコンポジタはフレームレンダリングのために実行を一時停止する可能性があります。WebAssemblyの実行速度はJITコンパイラの最適化状態に基づいて変動します。ブラウザ環境での測定されたタイミングジッタは通常1～10ミリ秒の範囲です。ネイティブアプリケーションではマイクロ秒レベルの精度と比較されます。

オーディオ同期は特定の技術的課題を提示します。Web Audio APIはアプリケーションが定期的な間隔でオーディオバッファを満たすことを要求します。通常512～4096サンプル毎のコールバックです。エミュレータはエミュレートされた時間（実行されたサイクル）に基づいてオーディオサンプルを生成します。ウォールクロック時間ではなく。同期には以下が必要です。

  1. エミュレートされた時間をウォールクロック時間から独立して追跡する
  2. タイミングジッタに対応するためにエミュレートされたサンプルをバッファリングする
  3. エミュレートされた時間とウォールクロック時間がドリフトするときにリサンプリングする

入力レイテンシはこれらの課題を複合化します。キーボードとマウスイベントはブラウザイベント処理、JavaScript実行、WebAssemblyの境界越えを通過してからエミュレータコードに到達します。ネイティブハードウェアと比較して5～50ミリ秒の追加遅延が導入されます。

これらの制約にもかかわらず、WebAssemblyのパフォーマンスは現代のハードウェア（2020年以降）での8MHzシステムの全速エミュレーションを可能にします。16MHz Falconはパフォーマンス限界に近づきます。持続的な負荷下でいくつかのアプリケーションはフレームレート低下またはオーディオアーティファクトを経験します。

ファイルシステム統合：デスクトップとブラウザの制約を橋渡しする

Atariソフトウェアは従来の階層的ファイルシステムと可変ストレージを想定しています。アプリケーションはファイルを読み書きし、ディレクトリを作成し、セッション間での永続的な状態を期待します。ブラウザはサンドボックス環境で動作し、直接的なファイルシステムアクセスがなく、アーキテクチャの適応が必要です。

Hatariのブラウザ実装は複数のメカニズムを通じてファイルシステム抽象化を提供します。

  • 読み取り専用ディスクイメージ：ユーザーは.ST、.MSA、または.STX形式のディスクイメージをアップロードします。エミュレータはそれらを不変ボリュームとしてマウントします。このアプローチは永続ストレージを必要としませんが、ソフトウェアがデータを書き込むことを防止します。
  • IndexedDBバックアップの書き込み可能イメージ：エミュレータはブラウザIndexedDBに保存された仮想ディスクイメージを作成し、セッション間で永続化します。IndexedDBは50MB～1GBのストレージを提供します（ブラウザ依存）。典型的なAtariアプリケーションには十分ですが、大規模なメディアコレクションには不十分です。
  • ホストフォルダマッピング：ブラウザAPIが許可する場合（Chromiumベースのブラウザで利用可能なFile System Access API）、エミュレータはホストディレクトリをエミュレートされたドライブにマッピングでき、ネイティブファイルシステムへの読み書きアクセスを可能にします。

各アプローチはトレードオフを伴います。

アプローチ互換性永続性パフォーマンスストレージ制限
読み取り専用イメージ最高なしネイティブ無制限
IndexedDB高完全低下（I/Oレイテンシ）50MB～1GB
ホストマッピング中程度完全ネイティブホスト依存

フォーマット変換は複雑さを追加します。Atariディスクイメージは異なる圧縮スキームを持つ複数のフォーマットで存在します。.STは非圧縮、.MSAはランレングスエンコード、.STXはコピー保護メタデータを含みます。エミュレータはマウント前にフォーマットを解凍および検証する必要があり、解析オーバーヘッドと非標準イメージバリアントとの互換性問題の可能性を導入します。

レトロコンピューティングの民主化：インストール障壁のないアクセシビリティ

従来のエミュレーションは順序立った一連のユーザーアクションを必要とします。エミュレータソフトウェアをダウンロードし、ROMファイルを探し（しばしば法的に曖昧なチャネルを通じて）、プラットフォーム固有の設定を構成し、互換性の問題をトラブルシューティングします。各ステップはカジュアルユーザーを除外する障壁を表しています。ウェブベースのエミュレーションはこれらの摩擦点を排除します。ユーザーはURLにアクセスし、すぐに動作するソフトウェアと相互作用します。

このアクセシビリティは特定のユースケースを可能にします。

  • 研究：物理的ハードウェアを保持またはネイティブエミュレーション環境を保持することなく、歴史的ソフトウェアを研究する歴史家とコンピュータ科学者
  • 教育：コース資料に埋め込まれたインタラクティブな例を通じてコンピューティング歴史を実証する講師
  • 開発：複数のネイティブ環境を保持することなくクロスプラットフォーム互換性テスト
  • キュレーション：ユーザーがエミュレーション概念を理解する必要なく、保存された作品への公開アクセスを提供するソフトウェアアーカイブ

ブラウザベースのエミュレーションはまたデスクトップエミュレータで不可能な新しいアプリケーションを可能にします。

  • ドキュメントと記事にインタラクティブなソフトウェアデモンストレーションを埋め込む
  • 事前ロードされたディスクイメージを持つ特定のソフトウェア構成への共有可能なリンクを作成する
  • エミュレートされた環境をウェブベースの開発ツールとIDEに統合する
  • どのソフトウェアが実際のエンゲージメントを受けるかについての使用分析を収集する

これはソフトウェア保存における広範な原則を表しています。アクセシビリティは使用と直接相関します。技術的に不完全だが普遍的にアクセス可能なエミュレータは、高いインストール障壁を持つ技術的に優れたデスクトップアプリケーションよりも保存目標により効果的に機能します。

重要なポイント

Hatariのオンライン実装は、複雑な歴史的システムのサイクル精度エミュレーションがブラウザ制約内で実行可能であることを実証しています。この成果はWebAssemblyのパフォーマンスと、ウェブ環境に固有のタイミング、ストレージ、I/O課題への実用的なソリューションを組み合わせています。

ソフトウェア保存に関心を持つ実務家にとって、重要なインサイトはアクセシビリティが技術的純粋性を上回るということです。わずかに不完全だが普遍的にアクセス可能なエミュレータは、少数の人しかアクセスできない技術的に優れたデスクトップアプリケーションよりも保存目標により効果的に機能します。Atariソフトウェアを探索するユーザーは、所有しているディスクイメージをアップロードし、異なるストレージアプローチを試験することから始めるべきです。エミュレーションアーキテクチャに関心を持つ開発者は、WebAssembly実装がタイミング同期とストレージ制約をどのように処理するかを検証できます。これらのレッスンは他の保存プロジェクトに適用可能です。ソフトウェアアーカイブを保持する組織は、ブラウザベースのエミュレーションを主要なアクセスメカニズムとして検討すべきです。アクセスの容易さが保存努力の実際の使用と文化的影響と直接相関することを認識しています。

重要なポイントと次のアクション

Hatariのオンライン実装は、複雑な歴史的システムのサイクル精度エミュレーションがブラウザ制約内で実行可能であることを実証しています。この成果はWebAssemblyの計算パフォーマンスと、ウェブ環境に固有のタイミング同期、永続ストレージ、I/O抽象化への実用的なソリューションを組み合わせています。

  • Atariソフトウェアを探索する実務家向け*：オンライン実装から始め、所有しているディスクイメージをアップロードし、異なるストレージアプローチを試験してワークフローに適したものを特定してください。遭遇した互換性の問題またはパフォーマンス制限を記録してください。

  • エミュレーションアーキテクチャを研究する開発者向け*：WebAssembly実装がエミュレートされた時間とウォールクロック時間間のタイミング同期をどのように処理するか、およびストレージ制約がディスクイメージ処理にどのように影響するかを検証してください。これらのパターンは同様の技術的制約を持つ他の保存プロジェクトに適用されます。

  • ソフトウェアアーカイブを保持する組織向け*：ブラウザベースのエミュレーションを二次的なオプションではなく主要なアクセスメカニズムとして評価してください。ウェブベースのアクセス実装前後の実際の使用率を測定してください。アクセシビリティの改善は通常、保存資料へのエンゲージメントの測定可能な増加と相関します。

WebAssemblyがネイティブC実装に対して80-90%のパフォーマンスを達成することを示す棒グラフ。整数演算85%、浮動小数点演算82%、メモリアクセス88%、平均パフォーマンス85%の相対実行速度を表示。

  • 図3：WebAssemblyとネイティブC実装のパフォーマンス比較（出典：Zakai, A. (2011). Emscripten: An LLVM-to-JavaScript Compiler）*

Atari STシステムアーキテクチャを示す図。中央のMotorola 68000 CPU（8MHz/16MHz）から4つの主要コンポーネントへ接続：GLUE Chip（メモリ管理、RAMとROMを制御）、MFP 68901（周辺制御・タイミング、2.4576MHzのタイマーとI/O制御を担当）、Shifter（ビデオコントローラ、ビデオ出力と50/60Hz同期を制御）、YM2149（サウンドシンセサイザー、3チャネルのオーディオ出力）。タイマーと垂直同期はCPUへの同期依存性を点線で表現。各コンポーネントは色分けされ、役割を視覚的に区別。

  • 図2：Atari STシステムアーキテクチャと各コンポーネント間のデータフロー（出典：Hatari公式ドキュメント、Atari ST技術仕様）*

ファイルシステム統合アーキテクチャを示す図。ユーザがディスクイメージやROMをアップロードしてから、ブラウザのセキュリティサンドボックスを経由してIndexedDB/LocalStorageに保存され、仮想ファイルシステムレイヤーでマウントされ、Hatari WebAssemblyエミュレータコアで実行され、最終的にユーザインターフェースに結果が表示されるまでの一連のデータフローを表現しています。

  • 図7：ブラウザとデスクトップ間のファイルシステム統合アーキテクチャ（Hatari WebAssembly実装、Web APIドキュメント参照）*

レトロコンピューティングのソフトウェア保存と文化的価値継承のフロー図。オリジナルハードウェアの劣化リスクから始まり、エミュレーション技術による保存、デジタルアーカイブへの格納を経て、教育・研究、ゲーム・エンタメ史の保全、誰でもアクセス可能な環境という3つの文化的価値へ分岐し、最終的に知識と文化の保全に至るプロセスを示しています。

  • 図11：エミュレーションによるソフトウェア保存と文化的価値の継承フロー*