semu-c64 - Commodore C-64でLinuxを実行

• Commodore C-64でLinuxを実行するために、最小限のRISC-V32エミュレーター semu をC-64向けに移植したプロジェクト
• 64KiBのメモリだけでは全体構成を収められないため、RAM Expansion Unit(REU) が必要で、実行速度は “extremely slowly” と表現されるほど非常に遅い
• 生成される semu 実行ファイルは汎用 RISCV32 エミュレーター であり、REUが 0x00000000 から 0x01000000 までのアドレス範囲にマップされていると仮定する
• Linux実行には仮想メモリエミュレーションとMMUが使われ、エミュレートされたUARTはPETSCIIとASCIIの大文字・小文字変換を処理する
• ビルドは make で行い、mos-c64-clang が必要
• VICEで実行する際は、コンパイル済み semu 実行ファイルを含む .d64 ファイルと reufile.linux を使い、RAM Expansion Moduleを有効化したうえでサイズを 16MiB に設定する必要がある
• C-64側での実行は LOAD "SEMU",8,1 の後に run を入力する方式で、READMEによれば起動には長い待ち時間が必要
• PC向け semu バイナリは -k オプションで reufile.linux を読み込め、最初のキー入力前まで決定的なブートシーケンスを得る用途に使える
• 永続化機能はエミュレーター状態を保存し、すでに起動済みのLinuxをより速く読み込む方式で、RISC-V CPUレジスターとUART、割り込みコントローラーの状態をREUアドレス 0xfff000 から読み込む
• リリースは “highly experimental” と見なされており、本番用途には適さないと明記されている

[GN⁺]

Hacker News のコメント

• Onno Kortman は、最小構成の RISC-V エミュレーター semu を、MOS 6502 向けの LLVM ポートである llvm-mos でクロスコンパイルし、Commodore 64 上で Linux を動かせるようにした。
  Kortman は「スクリーンショットを作るのに、VICE の『warp mode』でも数時間かかった。今の状態なら、実機の C64 でも 1週間ほどあれば Linux をブートできるだろう」と書いている。

  • 6502 は C のコンパイルターゲットとしては悪名高いほど不向きで、特に 6502 の制約を考慮していない C ならなおさらだ。
    ネイティブ 6502 で RISC-V エミュレーターを書けば、実機で Linux をブートするのに 1週間ではなく 1日以内で済むかもしれない。そうなればどれだけ多くの命を救えることか、と思う。
    https://www.folklore.org/StoryView.py?story=Saving_Lives.txt
  • このブートストラップ方式は、別の 8ビットマイクロコントローラー上で Linux を動かすプロジェクトを思い出させる。
    https://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bi... は 8ビット AVR で ARMv5 エミュレーターを使っていたが、今回は ギーク的な格好よさ では一段上だ。
  • 実ハードウェアで動いているところを見たいし、誰かが成功させてくれるといい。

• すごいとは思うが、最初に思ったのは「64KB RAM に収まるわけがない！」で、実際にも収まらない。
  16MB REU が必要だ。当時の C64 用 REU は 256KB と 512KB で、回路図が公開されていたため、クローンも主にそちらが作られている。
  90年代後半には、元の CPU とコード互換の新 CPU である SuperCPU（65816）を載せた C64 用の「拡張」もあり、おそらくこの装置は最大 16MB まで対応できたはずだ。
  その後、FPGA ベースの再実装が登場し、16MB REU も出てきた。元の SuperCPU の回路図は失われており、FPGA ベースの拡張ボードはいま数百ユーロで買えるとはいうが、実際に買った人は知らない。
  だから、きれいな技術的成果ではあるものの、「C64 で動く」という言い方は、「386 で Doom 3 を動かした。ただしその 386 は現代 PC の PCI カードだ」と言っているのに近く感じる。
  当時入手できたハードウェア、あるいは当時現実的に作れたハードウェアで自分の C64 上で実行できないなら、「C64 で動く」と呼ぶのは微妙だ。
  REU の話に戻ると、なぜいまだに公開回路図がないのかも気になる。eBay には安い SRAM チップがたくさんあるので簡単に作れそうに思えるが、実際には SuperCPU と DMA コントローラーという 2つの構成要素をかなり大きな FPGA でエミュレートする必要があり、単純ではない。
  もっと安価な FPGA や、FPGA に似た機能を持つマイクロコントローラーが出てくれば、誰かがオープンソースの SuperCPU を作るかもしれない。これまで聞いた利用者はみなエミュレーションを使っているようだ。開発にはエミュレーションが非常に有用だが、自分のレトロ趣味の楽しさは、オリジナルのハードウェアで動かすときが一番大きい。

  • 「当時入手できたハードウェアや、当時現実的に作れたハードウェアでなければ C64 で動くとは言いにくい」という基準なら、16MB REU は 80年代にも作ること自体はできた。
    価格が天文学的だっただけで、技術的に不可能な理由はない。SuperCPU と通常の REU を混同しているように思う。
    REU は RAM の塊と、C64 と通信して RAM バンクを保存したり取り戻したりさせる ASIC にすぎず、CPU はない。6502 は 64KB を超える範囲を直接アドレス指定できないので、システム RAM を入れ替えるよう指示する仕組みだ。
    SuperCPU（65816）は実際に 16MB を直接アドレス指定できるが、別物だ。元記事のプロジェクトは標準の C64 と標準の C64 CPU で動作し、ただし当時なら家一軒分の値段がしたであろう 途方もない量の RAM が必要なだけだ。
  • FPGA の代わりに、たとえば RPi Pico/Nano のようなボード内蔵の汎用 ARM SoC にソフトウェアで同じことをさせることはできないのだろうか。
    それとも、その程度でもエミュレーション純粋主義の限界に引っかかるのだろうか。
  • 「自分の 386 は実は現代 PC の PCI カード」だなんて、今ではそういうものが欲しくなってきた。
    今なら 386、486、Pentium とさらに別の SoC 群を PCIe カード 1枚に載せて、パッシブ冷却もできそうだ。
  • 16MB のメモリ追加が必要なら、「Commodore 64 で」と言うにはかなり境界線上だ。

• Linux の話ではないが、最近 C64 のアクセサリーをいろいろ試している。
  Kung Fu Flash を使ってみた。STM32 ひとつで作られた安価なソフトウェア定義カートリッジで、ほぼ何でもできる。「8-bit show and tell」で見ていた開発者体験を再現してみたくて買ったもので、「Super Snapshot」はエミュレートできるが REU はできない。多くの C64 ソフトウェアやゲームを素早く試すにはとても良い。
  https://8bithardware.wixsite.com/website/post/kung-fu-flash
  https://github.com/KimJorgensen/KungFuFlash
  SD2IEC も持っているが、追加の DIN ソケットがあるバリエーションを買えばよかったと学んだ。悪くはないが、もともと C64 の DOS は好きではなく、この装置はその印象を強めた。D64 ディスクイメージをマウントするには OPEN1,8,15,"CD:MYIMAGE.D64":CLOSE1 と打たなければならず、いまひとつだ。
  C64 用の交換 ROM である JiffyDOS はこれを改善してくれて、より高速で、常駐 DOS ウェッジも含んでいる。ひとつ注文してあり、実機の 1541 ドライブと組み合わせて試すのが楽しみだ。
  最近こういうものを始めるきっかけになったのは、VIC-20 用の「Penultimate +2」カートリッジだった。
  https://www.youtube.com/watch?v=eNGyneXHKJQ
  実のところ、このカートリッジを試したくて VIC-20 を買ったようなものだ。

• チューリング等価性の実演。時間が問題にならないなら、どんなチューリング完全なコンピューターでも、別のチューリング完全なコンピューターがすることを実行できる

  • 時間とメモリも必要
  • ラムダ計算で Linux をどうやって実行するんだろう？

• こうなると気になる。最新の Linuxを起動でき、なおかつ日常用途にも使える最も古いハードウェアは何だろう？

  • 日常用途での主な制約は、おそらく現代のウェブサイトの大半にアクセスするために必要な暗号演算だろう
    最も軽く高速なシステムを作って遅いマシンでもうまく動くようにはできるが、今のインターネットは容赦ない場所だ
  • 「日常用途」が最新のウェブブラウザと最新のウェブ生産性アプリを動かすことを意味するなら、下限はCore 2 Duo と 4GB メモリあたりだと思う
    ものすごく速くはないだろうが、少しの忍耐があればハードウェアが原因で行き詰まることはなさそうだ。ハードウェア動画デコード対応の GPU まで入れれば、YouTube もジャガイモ画質よりはましなレベルで見られるかもしれない
  • 議論のために、Debian 12 をインストールしてウィンドウマネージャーとブラウザを実行でき、苦痛なほど遅くはないコンピューターだとしよう
    Pentium 4 / Athlon XP時代あたりを目標にしたい。ドキュメント上、初代 Pentium はサポートされていないので、本当に苦痛を受け入れるなら Pentium II までさかのぼれるかもしれない
  • おそらく Core 2 Duo 搭載機のどれかだろう。もちろん 230MHz CPU でも、デスクトップ付きの Linux を「実行」することはできるはずだ
  • 最新 Linux ではまったくないが、1995年夏に Slackware 2.0 を入手したときは、Pentium 75MHz、8MB RAM、1024x768 が可能な Trident カード（X では 800x600 だけ可能）、IDE CD-ROM と HDD を使っていた

• これは LUnix と違うのか？
  https://en.wikipedia.org/wiki/LUnix

  • LUnixは C64 ネイティブのオペレーティングシステムなので、アプリを書いて C64 ハードウェア上で直接実行できる
    これは C64 上で RISC-V エミュレーターを実行し、そのエミュレーター上で Linux の起動をエミュレートするものだ

• 厳密に言えば、C64 上で Linux が直接動いているわけではない
  C64 がRISC-V 環境をエミュレートし、その上で Linux が実行されている。もちろんそれでも印象的だが、意味の区別は重要だ

• REU ではなく、フロッピーディスク数十枚をRAM のように使って動かせるのか気になる
  必要になるたびにユーザーにディスクを入れ替えさせるのはどうだろう。誰かが数か月か数年ほど余暇を持て余しているなら、実機でそれをタイムラプスで見てみたい

• Commodore 64 に RAM を追加したら、それはまだ Commodore 64 なのだろうか？

  • REUを使うなら、そうだと思う。C64 と同時代に合ったメモリアップグレードだからだ
  • 近くの johnwbyrd の説明を広げると、Commodore は C64 を 256KB RAM に増やす「1764」という RAM Expansion Unit を販売しており、C128 用の REU である「1750」を使って C64 を 512KB RAM に増やすこともできた
    さらに C64 用に 2MB REU まで拡張することも可能だ。https://www.neperos.com/article/rlut8ce90fbb7701 を参照
    C64 で2MBはかなり「正当に」持てる
  • いや、それは Commodore 16384 だ
    C64 REU でアドレス指定可能な最大メモリは16MBだ

• 最近、完全に動作するTRS-80 Model 4を手に入れ、そこにぼんやり Unix っぽい何かを載せる想像をよくしている
  その想像は続いている

  • 128KB までは増設できるはずだ。そこまで行けば、Fuzixを動かせる可能性はかなり出てくる
    その地点から始めれば、ほどよく深いウサギ穴を見つけることになるだろう