2026-04-22 — 在 1960 年代 UNIVAC 跑 Minecraft、Theseus 靜態 Windows 模擬器、Arduino 2KB 跑 Unix Shell

Running a Minecraft Server on a 1960s UNIVAC 1219B Computer (250kHz, 90KB RAM)

farlow.dev · 2026-04-17

有人在 1960 年代的 UNIVAC 1219B 電腦上成功跑起了 Minecraft 登入伺服器，這台機器只有 90KB 記憶體和 250kHz 處理器，採用奇特的 18 位元字和補數算術。

工程難題：架構不相容

UNIVAC 1219B 使用非標準的 18 位元字長和補數（one's complement）算術，市面上沒有任何現代編譯器支援直接輸出 UNIVAC 彙編。暴力移植幾乎不可能。

創意解法：RISC-V 模擬器

工程師選擇了一條迂迴路線：

• 用 UNIVAC 彙編編寫一個 RISC-V 軟核模擬器
• 所有現代應用程式用 GCC 工具鏈編譯成 RISC-V 二進制
• 在 UNIVAC 上運行 RISC-V 模擬器來執行現代代碼

優化過程

原始模擬器極慢，工程師透過以下手段實現約 30 倍加速：

• 指令預處理：將 RISC-V 指令預解碼為查找表，避免每次執行重複解碼
• 跳轉表：替換頻繁的條件分支
• 熱路徑分析：識別並優化最常執行的指令序列

最終成就

在這台 60 年前的機器上成功運行了：

• Minecraft 登入伺服器（驗證玩家身份）
• 靜態網頁伺服器
• SHA-256 雜湊運算

這個項目的工程哲學是：當直接路線不可行時，建立一個適配層往往比硬移植更可行。這也是 WebAssembly、JVM 等虛擬機設計的本質。

Theseus: A Static Binary Translator for Running Windows Apps on Linux Without JIT

neugierig.org · 2026-04-19

Theseus 是一個挑戰模擬器設計傳統智慧的專案：用靜態二進制翻譯取代 JIT 編譯，在 Linux 上執行 Windows 應用程式。

靜態翻譯 vs JIT 翻譯

靜態翻譯的意外優勢

• 原生偵錯器可用：翻譯後的代碼是標準 ELF，gdb 可直接附加，棧追蹤引用原始函數名
• 編譯器優化：mov eax, 3; add eax, 4 可被編譯器直接優化為 mov eax, 7，消除冗餘計算
• 模擬層邊界清晰：模擬代碼與原生代碼的界限清楚，易於系統化測試

實作進展

作者宣稱幾週內完成了 DirectX、FPU 和 MMX 指令支援。這個進度速度令人印象深刻，驗證了「靜態翻譯在複雜度可控的架構上是可行的」這一假設。

這個專案有趣的地方不只是技術成就，而是它示範了「換一個框架思考」的工程哲學——當大家都在說 JIT 是唯一可行方案時，靜態翻譯提供了一條完全不同的路。

KernelUNO: A Unix-like OS Shell Running on Arduino UNO with Only 2KB RAM

GitHub · 2026-04-20

KernelUNO 在 Arduino UNO 僅有的 2KB SRAM 限制下，實現了功能完整的類 Unix shell，包含虛擬文件系統、硬體控制和 22 個內建指令。

極端約束下的設計決策

Arduino UNO 的資源清單讓人望而卻步：

• SRAM：2KB（用完即死）
• Flash：32KB（代碼存儲）
• CPU：16MHz AVR ATmega328P（8 位元！）
• 無 MMU：沒有虛擬記憶體保護

實現的功能

儘管如此，KernelUNO 實現了：

• 基於 RAM 的文件系統模擬（虛擬 inode 結構）
• ls、cat、mkdir、rm 等 22 個內建指令
• GPIO 控制（可透過 shell 直接操作硬體腳位）
• Kernel 訊息日誌系統
• LED 迪斯科模式彩蛋（工程師的幽默感不可缺少）

資源使用率

• RAM 佔用：85%（1700 bytes，剩 300 bytes 給堆疊和變數）
• Flash 佔用：38%（約 12KB）

工程啟示

這個專案最有教育意義的地方是：它迫使你理解 Unix 系統中每個抽象層的本質——文件系統不過是有名字的記憶體區塊，shell 不過是 read-eval-print loop，進程管理不過是上下文切換。去掉所有 overhead，你看到的就是計算的本質。

HiNet DNS 168.95.192.1 的區域性 ICMP 封鎖事件——DNS 服務仍正常但 Ping 全滅

blog.gslin.org · 2026-04-21

一個關於 DNS 基礎設施的有趣觀察：台灣 HiNet 的公開 DNS 伺服器 168.95.192.1 出現了奇怪的區域性 ICMP 封鎖現象。

現象描述

從大埤地區發出的 ping 168.95.192.1 顯示 100% packet loss，持續相當長的時間。然而，DNS 查詢（TCP 和 UDP 的 53 埠）完全正常運作——這代表 IP 層是通的，只是 ICMP 協定被選擇性封鎖。

作者從新竹住所測試同一 IP 則完全正常，ICMP 沒有任何問題。

問題的有趣之處

按理說，大型 ISP 的 DNS 服務通常採用 anycast 架構，同一個 IP 背後有多個節點，理論上應提供統一的用戶體驗。但這個案例顯示：

• 某個特定地理路由路徑上的節點（或中間路由器）選擇性過濾了 ICMP
• UDP/TCP 53 不受影響，說明這是協定層面的選擇性過濾，而非 IP 封鎖
• 區域性差異揭示了 ISP 內部網路管理政策的不一致性

可能原因

這種選擇性 ICMP 封鎖在 ISP 中並不罕見：

• DDoS 防禦：某些 ISP 在高流量期間選擇性丟棄 ICMP 以保護 DNS 服務頻寬
• 速率限制：對 ICMP 應用嚴格速率限制（遠比 DNS 查詢嚴格）
• 路由政策差異：不同機房有不同的防火牆規則

這個小故事提醒我們：「Ping 不通」≠「服務掛了」。在診斷網路問題時，協定層面的區分至關重要。