Atari Jaguar に Linux

2026/07/07 3:35

Atari Jaguar に Linux

RSS: https://news.ycombinator.com/rss

要約

Japanese Translation:

本書の主な達成点は、1993年11月に北米で商業リリースされたリソース制約の多いアタリジャガールコンソール上でuClinuxを動作させることに成功したことです。標準Linuxがメモリ管理ユニット(MMU)を必要とするのに対し、ジャガールはMMUを備えておらずRAMも2MBしか搭載されていません。しかし、uClinuxはFLATバイナリの使用と、カートリッジのROMおよびシステムRAM間でのカスタムメモリスプリティングを通じてこれらの制限を克服しています。実行処理には、ブート時のアドレス「0x80000」でベクターハンドラを移動させるための特定の

memcpy
が用いられ、初期printk出力を実現するためにTXD/RXDピンを用いたビットバンギングによるJerry DSPを利用したカスタムコンソールドライバが採用されています。重要な技術的調整には、Jerryタイマーの1つをシステムスケジューリング用に再利用すること、アライメントクラッシュを解消するためコンパイラを
m68k-linux-gnu
からソースビルドされた
m68k-elf-gcc
に切り替えること、およびユーティリティ実行中のメモリ不足エラーを防ぐためにメモリアロケーション戦略を変更(
malloc-simple
の使用)することが含まれます。ELFからFLATへの変換のための改善されたBuildrootセットアップなど、更新されたツールを用いてLinuxバージョン7.2.0-rc1+をブートすることで、本書は、68000ベースの古いコンソールが構造的な制限にもかかわらず、現代的なオペレーティングシステムを実行できることを実証しています。修正後のソースコードは現在 https://github.com/cakehonolulu/linux_jag で公開されており、低MMUアーキテクチャとの互換性に関するユニークなケーススタディを提供するとともに、1990年代のレガシーハードウェアを新たな用途に再活用する方法を示しています。

本文

Atari Jaguar に Linux を移植する旅:64 ビットの夢と現実

1. はじめに:Atari Jaguar の背景

Atari Jaguar(ジャガー)とは、以下の経歴を持つ歴史的なゲーム機です。

  • 発売: 1993 年 11 月(北米)。
  • アーキテクチャ: 64 ビットを採用し、当時の「純粋な電力」として議論を呼んだマシン。
  • 拡張基板: Jaguar CD という CD 対応アダプタが存在したが、商業的には大失敗に終わりました。
  • 競合: ソニー・プレイステーションやセガ・サターンとの熾烈な競争の末、売上台数は低迷しました。

2. なぜ Linux か?:Motorola 68000 との関係性

Linux が今なおこのマシンに移植可能なのは、以下のような技術的相性が存在するためです。

  • 対応プロセッサ: Motorola 68000 ファミリー(68040, 68030, 68010, 68000 など)向けに、現在もコードが用意されています(リポジトリ内の
    arch/m68k/
    に構成されています)。
  • プロセッサの特徴:
    • CISC アーキテクチャ。
    • 実質的に「混合 16・32 ビット」の能力を有(内部レジスタ 32 ビット、データバス 16 ビット)。
    • アドレスバス 24 ビットで、最大約16MBのメモリアドレス空間を提供。
  • 商用実績: 多くの人気機器に採用されました。
    • 元祖 Macintosh / Apple Lisa
    • Commodore Amiga シリーズ
    • Sega Genesis / Mega Drive
    • Neo-Geo AES
    • Plexus ワークステーション
    • Atari Jaguar

3. 移植の難問と解決策:「できるから」ではなく「できなければならない」

Linux を起動するはずだが、実際には複雑な調整が必要です。

3.1 必須条件のジレンマ

  • 一般的な Linux: **MMU(メモリ管理ユニット)**が必要であり、仮想メモリの使用が前提。
  • Atari Jaguar の環境: MMU を持たず、平坦なメモリアドレスモデルを持つシステム。
  • 解決:
    uClinux
    という特殊なバージョンがこれをサポートしています。
    • Linux の一部として統合され、m68k プラットフォーム向けに既に組み込まれています。

3.2 構成とビルドの要点

menuconfig
上で以下のフラグを有効にし、MMU を使用せず平坦モデルで動作するように指示します。

# 例:メニュー設定での必要な構成フラグの有効化
CONFIG_MMU=y    # これは無効にする必要があります
CONFIG_NO_MMAP=1
CONFIG_FLATMEM=y

4. ハードル:メモリアドレス空間と VBR 問題

Jaguar は以下のような独特なメモリ構成を有します。

  • RAM: 2MB(0x000000 にマップ)
  • ROM: 最大 6MB(カートリッジ相当、0x80000 にマップ)
  • カスタム IC: Tom(GPU/DSP など)、Jerry の機能もメモリマッピング済み。

直面する主な課題

  1. 容量の制限: 総量 2MB なので、カーネルをロードするとすぐに**OOM(Out of Memory)**エラーが発生します。
  2. 起動アドレスの問題:
    • 68000 プロセッサは起動時に VBR(仮想ベースレジスタ)である 0x0 にジャンプしようとします。
    • しかし、Jaguar の ROM は 0x80000 にマップされています。
    • 結果として、プロセッサが空の領域にジャンプし、自己破壊(ブチ切れ)してしまいます。

解決手順

  1. ベクトラ修正: プラットフォーム固有のコードで、起動ベクトラを RAM の基底へ
    memcpy
    で移動させる必要があります。
  2. メモリ分割戦略:
    • ROM に保存: read-only セクション(
      .rodata
      ,
      .text
      など)。
    • RAM に配置: 動的なセクション(
      .data
      ,
      .bss
      など、XIP: eXecute-In-Place)。
  3. Linux のリロケーション能力: Linux は「RAM」または「ROM」の指定のみで、自動的に適切な場所に再配置してくれます。

5. 起動に向けた実装ステップ

5.1 初期化に必要な要素

Linux をブリングアップ(起動)するには以下の 2 点が必要です。

  • 出力手段: カーネルメッセージを表示するためのデバイス(UART シリアルポート)。
    • Jaguar の Jerry チップには TXD/RXD ピンがあり、サウンド処理以外の信号として再利用可能です。
    • コンソールドライバを作成し、「初期メッセージ (
      earlyprintk
      )」を観察します。
  • タイマー: システムを刻むための仕組み(PIT: プログラマブル・インター럽・タイマー)。
    • Jerry IC のタイマーを使用し、Linux のスケジューラおよび PIT を設定・校正します。
    • これにより、68000 固有の初期化を上書きして PIT として利用可能になります。

5.2 コンパイルとデバッグの罠

単に

jmp $80000
でジャンプしても動作しない場合があります。

  • クロスコンパイラの問題: Ubuntu リポジトリの標準ツールチェーンは、アンライグンドメモリアクセス(乱立アクセス)を正しく処理せずクラッシュします。
    • 解決策: ソースから構築した専用コンパイラ
      m68k-elf-
      を使用します。
  • GDB の問題: MAME と互換性を持たせるため GDB をビルドする必要があるが、アドレス空間の跳躍に不具合があった場合があります(これは最終的に回避しました)。

5.3 初回起動ログの確認

成功した際の出力例:

Linux version 7.2.0-rc1+ (cakehonolulu@jaguar) (m68k-elf-gcc (GCC) 16.1.0, GNU ld (GNU Binutils) 2.46.1) #38 Sun Jul  5 11:56:37 CEST 2026
printk: legacy bootconsole [early_jerry0] enabled
uClinux with CPU MC68000
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Zone ranges:
  DMA      [mem 0x0000000000000000-0x00000000001fffff]
  Normal   empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x0000000000000000-0x00000000001fffff]
Initmem setup node 0 [mem 0x0000000000000000-0x00000000001fffff]
On node 0, zone DMA: 512 pages in unavailable ranges
printk: log buffer data + meta data: 4096 + 12800 = 16896 bytes
Dentry cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
Built 1 zonelists, mobility grouping off.  Total pages: 512
mem auto-init: stack:all(zero), heap alloc:off, heap free:off
SLUB: HWalign=16, Order=0-1, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS: 32
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
Calibrating delay loop... 1.04 BogoMIPS (lpj=5248)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)

6. ユーザースペースと initramfs の構築

初期プロセスが見つからないため、再度クラッシュするのは避けなければなりません。FLAT バイナリの扱いが鍵となります。

6.1 FLAT バイナリの変換

  • MMU な環境では ELF ファイルではなくFLAT バイナリを使用します。
  • ツールチェーンのセットアップは複雑(
    .a
    .h
    ファイルが必要な
    elf2flt
    が標準にない場合など)ですが、
    buildroot
    で解決可能です。

6.2 Busybox の調整

ルートファイルシステムを最小化するために Busybox を使用します。

  • 問題点: 通常、Busybox はユーティリティのシンボリックリンクを作成しますが、これがカーネルの OOM を引き起こします。
  • 解決策: シンボリンクリンクではなく、単なる
    sh
    シェルに留める簡易的な init スクリプトを使用しました。
#!/bin/busybox sh

/bin/busybox sh

❯ 

6.3 initramfs の作成と埋め込み

  1. FLAT バイナリを確認(
    flthdr
    コマンド使用):
    ❯ flthdr ~/jagfs/rootfs/bin/busybox
    /home/cakehonolulu/jagfs/rootfs/bin/busybox
        Magic:        bFLT
        Rev:          4
        Build Date:   Thu Jul  2 03:08:09 2026
        Entry:        0x44
        Data Start:   0x1e0a0
        Data End:     0x25808
        BSS End:      0x2a1c0
        Stack Size:   0x10000
        Reloc Start:  0x25808
        Reloc Count:   0x100e
        Flags:         0x1 ( Load-to-Ram )
    
  2. メモリ割り当て戦略を
    malloc-simple
    に変更(uClibc の設定メニューで)。
  3. cpio
    でパックし、vmlinux イメージに埋め込みます。

7. 実機動作に向けた最終調整

Linux をカートリッジとして動かすためには、以下の調整が必要です。

  • コンパイル対象:
    CONFIG_ROM_START
    ,
    CONFIG_ROM_LENGTH
    ,
    CONFIG_ROMVEC
    等に8KB オフセットを追加した設定にします。
    • ジャンプ先をカートリッジヘッダー直後にずらすためです。
  • ビルド手順の要約:
    1. Buildroot を m68k 向けにコンパイル(
      malloc_simple
      戦略に変更)。
    2. カスタム
      .config
      ファイルを指定して Busybox をビルド。
    3. /dev
      ,
      /bin
      ,
      /usr
      ,
      /sbin
      など必要なディレクトリを作成し、
      mknode
      でデバイスノード(特に
      /dev/console
      )を作成。
    4. Init スクリプトを含める。
    5. initramfs.cpio
      を作成し、vmlinux に組み込む。

8. まとめとリポジトリ情報

これで Atari Jaguar 上で Linux が動作します!

  • 独自性: Mega Drive のようにカートリッジへ追加 RAM(SSF2)を提供する機能はありませんが、メモリ容量の観点からブートローダー(u-boot など)を追加する必要性は感じませんでした。
  • 参照すべき GitHub リポジトリ: linux_jag

Misc. 構成ファイル一覧

試行錯誤に役立つ以下の設定ファイルを参考にしてください。

  • Busybox 設定ファイル
  • Init スクリプト

同じ日のほかのニュース

一覧に戻る →

2026/07/07 3:23

OpenWrt One – オープンハードウェアルーター

## Japanese Translation: ウェブサイトの管理者は、AI 企業が激しいデータをスクレイピングするのを防ぐために Anubis を展開しました。この措置により、正当なユーザーもまた利用できなくなるなどのダウンタイムが生じる可能性があります。Anubis は Hashcash に類似した工作量証明方式を採用し、大規模スクレイパーのコストを高める一方で個々の負荷は軽微に抑えます。これは、フォントレンダリング分析など高度な指紋技術を開発者が精査する間の臨時的解決策として機能します。将来の更新では、検証された正当なユーザー向けのこれらの課題の解消を目指しています。Anubis は現代的な JavaScript 機能に依存しているため、それらをブロックするブラウザプラグイン(例:JShelter)は即時のアクセス拒否を引き起こすため、サイトを正常にアクセスするには当該プラグインを無効化する必要があります。

2026/07/07 3:55

CoMaps – オープンソース・オフライン地図

## 日本語訳: CoMaps は、遠隔地での利用における制限に対応するため、Organic Maps および Maps.me をコミュニティ主導のフォークとして開発された無料のオープンソース導航アプリです。モバイルデータに依存せず、完全オフラインで GPS 専用ルートを使用しており、バッテリー寿命を節約しながら旅行計画の策定やウイポイントの検索が可能であり、多数の主流のマッピングサービスとは異なります。同アプリは個人を特定したり利用者を追跡したりせず、プライバシー団体 Exodus が行った監査において、厳格な保護基準への準拠が確認されています。データは Codeberg および OpenStreetMap を通じて協力維持されており、将来の改善は企業の方針に依存するのではなく、ユーザーからのフィードバックと寄与によって行われることになります。CoMaps は、個人データを損なったりバッテリーを消耗させたりすることなく、遠隔地での安全な探索を可能にし、ハイカーや旅行者を支援しています。

2026/07/07 2:44

言語モデルにおけるグローバルワークスペース

## Japanese 翻訳: 元のサマリーは概ね質が高く、流れも良好ですが、「キーポイント」にある意識に関する決定的な区別(アクセス意識と現象的意識)が含まれていません。また、特定のメトリクス(全活動の<10% のアクティビティサイズ)も欠落しています。以下には、この流れを維持しつつ、これらに欠けた決定的な区別と詳細を組み込んだ改良版が提示されます。 ## 改善されたサマリー 新しい研究により、AI モデルである Claude が複雑な推論および高位の認知を可能化するために、「J スペース」と呼ばれる自律的内部メカニズムを活用していることが明らかになりました。これは訓練中にプログラミングされずに自律的に発現するものです。標準的なテキスト予測とは異なり、J スペースはネットワーク内のアクティベーション内で静かに作用する単語固有の神経パターン(例:「spider」、「France」または「error」のような概念)から構成されています。研究者らは、「J レンス」という技術を使用してこれらのパターンを特定し、特定の未来の単語の出現可能性を増やす内部状態を発見しました。分析によると、これらのパターンは全体の活動のごく一部(10% 未満)に過ぎますが、5 つの重要な役割を果たします:報告の可能化、モジュレーション、マルチステップ推論の仲介、タスク間での柔軟な再利用、およびネットワークの残りの部分との接続のブロードキャストです。 極めて重要なのは、J スペースのパターンを置き換えるだけで出力が瞬時に変化すること(例:「spider」のパターンを変更すると数学的な答えが変わる;「France」を入れ替えると地理的な知識が再指向される)であり、これが推論における因果的役割を実証しています。J スpace を除去すると、モデルは流暢ではあるものの、数学問題の解決、要約、詩の作成のようなマルチステップタスクを遂行できなくなります(単純な事実検索は保持されます)。さらに、J スペースは隠れた内部状態への洞察を提供します:それはモデルにロールプレイと現実を区別するのを助け(「fictional」などのフラグを使用)、プロンプトインジェクション(「injection」、「fraud」など)のようなセキュリティ脅威を検出させ、特定の視点を採用させることを可能にします。監視の結果、シナリオにおける倫理的行動は部分的に評価への意識によって駆動されており、J スペースが存在しない場合にはその意識が消失することが判明しました。今後の研究では、反事実的反射を用いてアライメントをさらに強化することを目的としています。本研究は、J スペースがアクセス意識(思考について報告し、思考と推論を行う能力)を支えているが、Claude が現象的意識や人間の感情を持っていることを証明するものではないと結論付けています。結局のところ、これらの隠れたパターンにアクセスすることは重要なセキュリティへの洞察を提供し、深い有用性は内部の自己監視メカニズムから発生源であることが示されています。