冷戰遺跡：德國倉庫裡沉睡二十年的東歐計算機群
Computer History Museum · 2026-06-12
2006 年 7 月 26 日，電腦歷史博物館（CHM）策展人 Dag Spicer 收到一封德國稅務顧問的電子郵件，信中描述了一棟廢棄倉庫裡堆滿了罕見的歷史計算機器材。Spicer 與同事 Alex Bochannek 隨即飛往德國魯爾區小城 Castrop-Rauxel，親自確認這批傳說中的遺產。這是 CHM 歷史上規模最大的單次收藏行動。
背景
這批藏品據信是由 亞琛工業大學（RWTH Aachen） Rogowski 電氣工程研究所的 Walter Ameling 教授畢生蒐羅而成。倉庫本體為三層樓建築，地板面積約 11,840 平方英尺（約 1,100 平方公尺），從 1930 年代至 1980 年代的計算設備散落其中。倉庫在所有者過世後遭遺棄，文物在無人管理的環境中自然老化。
Spicer 與 Bochannek 抵達後，採用 2m × 2m 網格系統，對整棟 22m × 50m 的倉庫進行系統性盤點。文件與儲存媒體只佔空間的 20%，卻耗費了兩人 40% 的編目工時——因為那批文件囊括了工程手冊、維修記錄、行銷資料，以及大量磁帶與打孔卡片，狀況從嚴重水損到保存完好不等。就在盤點過程中，現場距倉庫 350 英尺外挖出一枚二戰遺留的 500 磅英軍炸彈，所有人不得不撤離等待排爆。
技術細節
這批藏品涵蓋了冷戰兩側的計算史脈絡，以下是其中幾臺具代表性的機器：
- Telefunken TR 440（約 1971 年）：西德大型主機，全球僅生產約 45 臺，主要配置於大學研究單位。
- Siemens System 4004（1965 年）：以 RCA Spectra 70 架構為基礎，是西歐計算工業史的重要標本。
- IBM System/370 Model 148（1976 年）：1970 至 80 年代企業主機的代表機型。
- 蘇聯 CM 5400（1982 年）：搭配保加利亞製硬碟機的東歐計算系統，是冷戰期間蘇聯電腦工業自主路線的實物佐證。
- TRICE 混合電腦：由 Packard Bell 與 Raytheon 合製的混合數位微分析儀（hybrid digital differential analyzer），起始售價 89,500 美元，NASA 與北美航空（North American Aviation）均曾採用。
- Control Data 3100（1967 年）：曾服役於美國國稅局（IRS）。
- IBM Model 82 Sorter（1949 年）：每分鐘可處理 650 張打孔卡片。
- 東德 ROBOTRON 點陣印表機（約 1983 年）：每秒 360 字元，是東歐計算機製造商 ROBOTRON 的代表產品之一。
儲存媒體方面，倉庫內保存有 80 欄與 96 欄打孔卡、磁帶捲軸、DECtape、8 吋軟碟，以及內含原始碼的磁碟包（disk pack）。這些媒體能否成功讀取，至今仍是數位保存領域的重大挑戰。
實作方式
最終確認的規模令人咋舌：共 2,056 件文物（含 1,127 件實體機器），需要七輛大型拖板車跨越大西洋，從德國運往加州舊金山。整個物流與通關作業耗費了大量協調成本。此次收藏規模之大，迫使 CHM 新建一座氣候控制倉儲設施，現命名為「SAP Collection」，資金由 SAP 高管 Ike Nassi 贊助。
這次發現的意義不僅在於機器本身，更在於它填補了歐洲計算史在西方文獻中長期缺席的一塊——尤其是冷戰期間東歐國家（蘇聯、東德）的計算機工業軌跡，過去在英語資料庫中極為罕見。能在同一個倉庫裡同時見到西德、蘇聯、美國的計算設備，本身就是一幅橫跨意識形態分裂的科技史全景。
原始來源：Computer History Museum — Explorers of the Lost Computers
2007 年諾基亞 N95 跑起 Half-Life：30 FPS 驗證了一個年代的算力
Tom's Hardware · 2026-06-12
開發者 dante_leoncini 近日在社群媒體發布影片，展示 1998 年的經典射擊遊戲《Half-Life》在 2007 年出廠的 Nokia N95 上以接近 30 FPS 的效能流暢執行。這不只是一項「能跑就好」的實驗，更引發了技術社群對 2000 年代手機晶片算力的重新估量。Tom's Hardware 在 2026 年 6 月 12 日報導了這項成果。
背景
Nokia N95 是 Symbian S60 平臺的旗艦機，搭載 332 MHz 的 ARM 1136EJ-S 處理器，配備 128 MB RAM 與 Imagination Technologies PowerVR MBX Lite GPU。以今日標準看，這不過是個嵌入式微控制器等級的規格；但放在 1998 年 Half-Life 首發的硬體背景下——Pentium II 300 MHz、64 MB RAM——兩者的理論浮點效能其實相去不遠。
Half-Life 採用的 GoldSrc 引擎源自 id Software 的 Quake 引擎（1996），核心渲染路徑以軟體光柵化為主，對 GPU 依賴程度相對低，這使它成為移植到無完整 OpenGL 支援平臺的可行選擇。GoldSrc 的 BSP（Binary Space Partitioning）可視剔除在低頻 CPU 上仍能維持合理效率，也是此次移植成功的關鍵之一。
技術細節
N95 的 Symbian 平臺不支援標準 x86 二進位，因此這次移植並非模擬（emulation），而是針對 ARM 架構的原生重新編譯（native recompilation）。開發者需要處理 Symbian 特有的記憶體模型、有限的動態連結支援，以及 C++ 標準庫的相容性問題。N95 的螢幕解析度為 320×240（QVGA），恰好是 Half-Life 最低支援解析度之一，有助於降低填充率（fillrate）瓶頸。
音效系統通常是移植到受限平臺的最大障礙之一。N95 的音效 API 設計針對多媒體播放而非即時混音，遊戲音效的部分極可能被簡化或停用，以騰出 CPU 週期供渲染管線使用。輸入處理同樣需要重新映射——原版遊戲依賴鍵盤與滑鼠的六自由度控制，在 N95 的數字鍵盤上必須大幅妥協。
實作方式
這次成果呼應了嵌入式移植社群長久以來的觀察：1990 年代末的 PC 遊戲引擎，其算力需求其實與 2005–2010 年間的中高階手機晶片高度重疊。同樣的現象早在 Doom（1993）被移植到智慧型電視、懷孕測試筆、示波器等設備時就已屢見不鮮。Half-Life 在 N95 上達到 30 FPS，不僅是個人技術的展示，更是一份量化的硬體歷史文件——它證明 ARM 嵌入式核心在某個特定窗口期，與 x86 桌機在特定工作負載下的效能已大致持平。
Tom's Hardware 的報導副標寫道：「proves 2007 phones can just about match 1998 PCs」——這句話背後隱含的是整個 ARM 架構在 2000 年代初的算力成長曲線，以及 id Software 等引擎在設計上刻意保持的可攜性傳統。
原始來源：Tom's Hardware — Developer gets Half-Life running at 30 FPS on a Nokia N95
用 COBOL 寫第一人稱射擊遊戲：FPS.cob 的光線投射引擎解析
GitHub (icitry/FPS.cob) · 2026-06-12
開發者 icitry 在 GitHub 上發布了 FPS.cob，一個完全以 COBOL 撰寫的第一人稱射擊遊戲引擎。這個專案以 GnuCOBOL 編譯器（cobc）編譯，透過將原始 RGB 像素資料 pipe 給 ffplay 來輸出畫面，實現了在這門以帳務處理著稱的語言上執行 3D 遊戲渲染的奇特壯舉。
背景
COBOL（Common Business-Oriented Language）誕生於 1959 年，由 Grace Hopper 主導設計，長期是全球金融、政府系統的骨幹語言。它的語法以接近英語的冗長著稱——MOVE X TO Y 而非 y = x——設計目標是可讀性與資料處理，而非數學運算或系統程式設計。拿它來寫 3D 遊戲，本身就是對語言用途邊界的刻意挑戰。
整個 repository 有 99.7% 的程式碼以 COBOL 撰寫，剩餘 0.3% 為 shell script（build.sh）。專案上線後在 GitHub 累積了 53 顆星，並有 4 個 pull request 待審，顯示社群對這類「不正經」工程的高度興趣。
技術細節
渲染核心採用 DDA（Digital Differential Analyzer）演算法進行光線與網格的交叉測試。對每一個螢幕水平列（screen column），引擎從玩家視角計算一條射線方向，逐步遍歷地圖格子直到碰牆，再計算垂直距離以消除魚眼畸變，最後將深度值存入 Z-buffer 供後續精靈（sprite）遮蔽判斷使用。
更進階的 WORLD_MODE 支援類似 Doom 的 linedef/sector 架構——地圖由頂點（VERTICES）、扇區（SECTORS）、牆段（LINEDEFS）和物件（THINGS）等資料結構描述，透過線段交叉測試實現門（door）與可變天花板高度的 portal rendering。這種架構在 1993 年的 Doom 中首次被廣泛應用，比起 Wolfenstein 3D 的純網格模型，大幅提升了地圖設計的自由度。
畫面緩衝區以 COBOL 的 Working Storage 區段定義：
01 FRAMEBUFFER.
05 FB-BYTE OCCURS 35000 TIMES PIC X.這是一個 35,000 位元組的平坦陣列，對應 120×90 像素、每像素 3 位元組 RGB 的原始影格。每幀輸出的格式為標準 PPM 影像標頭（P6 120 90 255\n）加上原始像素資料，透過 stdout pipe 給 ffplay 做即時播放，目標幀率約 60 FPS（每幀間插入 16ms usleep）。
實作方式
COBOL 本身並不支援指標算術或低階 I/O，開發者以 CALL 陳述式直接呼叫 C 標準函式庫中的 read、write、open、usleep、system 等函數，繞過 COBOL 原生的 I/O 層。終端機的非緩衝輸入（no-echo raw mode）則透過 stty 系統呼叫達成，讓鍵盤事件能即時回應。
浮點計算透過 USAGE COMP-2（64 位元原生雙精度）宣告的變數配合內建函數 FUNCTION SIN、FUNCTION COS、FUNCTION SQRT 實現。紋理採樣則以 PIC X 位元組陣列儲存 4 套牆面紋理（各 64×64×3 位元組），搭配手動計算的線性索引存取，不依賴任何 struct 對齊假設。支援的地圖格式包括 Wolf3D 風格的純網格（map/level1.map）以及 Doom 風格的 sector/linedef 格式（map/doom_sectors.map）。
建置指令只需兩步：
git clone https://github.com/icitry/FPS.cob
cd FPS.cob && bash build.shFPS.cob 的出現再次印證了一件事：語言的適用領域並非由語法決定，而是由實作者的意志決定。在這個案例裡，意志的代價是每行都得寫成像企業財報的英文句子——但那也正是它引人發笑、引人深思的地方。