Hacker News Digest

Программист Giles Goddard, отвечавший за «лицо Марио» на экране загрузки, рассказывает, что над Super Mario 64 работало всего около 15 человек — заметно меньше, чем над The Legend of Zelda: Ocarina of Time. Офис Nintendo был открытым, но разделённым на отсеки: художники и программисты сидели отдельно, а команда росла от центра, втягивая соседних специалистов. В японской студии царила тишина — стоило программистам собраться поболтать, как начальство одним взглядом заставляло их замолчать, совсем не как в британских или американских компаниях.

Проект стартовал задолго до появления железа — на эмуляторах SGI Onyx, где программист Нисида гонял первых марио по эмуляции графической библиотеки, а не самого N64. Миямото был полностью погружён в игру: садился за консоль, играл с демо и обожал эксперименты — именно так родилось интерактивное лицо Марио. Физику специально «подкручивали», чтобы герой мог нарушать законы реального мира ради азарта. Уровни казались огромными лишь за счёт узких извилистых карт и подмены секций, а эффект бесконечной лестницы — простым возвратом Марио в ту же точку, что происходило так быстро, что оставалось незаметным.

Создание Super Mario 64 требовало самостоятельного освоения сложной 3‐D математики: разработчики начала 90‐х разбирались с матрицами, перспективой и линейной алгеброй без доступа к интернету. Игра привнесла революционный аналоговый стики‐контроль, заменив «танковые» схемы управления и став ключевой инновацией. Чувство управления достигнуто за счёт многократного тонкого подгонения параметров скорости, ускорения, трения и импульса через длительное тестирование. Команда SM64 состояла из примерно 15 человек — значительно меньше, чем у Ocarina of Time (40‐50), что подчеркивает эффективность небольших групп Nintendo. Разработка велась в тихом японском офисе, где шум подавлялся по умолчанию, в отличие от современных студий. Большая часть усилий сосредоточилась на движении Марио и камере; Миямото тратил на это большую часть своего времени. Отделение художников и программистов способствовало фокусировке команд. Демонстрация 3‐D от Argonaut была выпущена для Game Boy, а не для NES, как иногда ошибочно указывают. Современные разборы Kaze Emanuar выявляют баги и неоптимальные места в SM64, подтверждая, что оригинальный код был далеко не идеален. SM64 ввёл современную схему управления от третьего лица с независимой камерой, отличающуюся от прежних «танковых» контролей.

Проект psp-web-recomp позволяет запускать игры для PSP в браузере без эмулятора, используя статическую рекомпиляцию машинного кода MIPS в C++, который затем компилируется в WebAssembly. Игра взаимодействует с высокоуровневой эмуляцией ядра PSP (HLE), реализованной в C++, которая обеспечивает работу потоков, файловой системы (с потоковой загрузкой данных диска через HTTP Range-запросы), контроллера, аудио и сохранений. Графический чип GE эмулируется на CPU, где обрабатываются дисплей-листы, а результаты рендеринга передаются в WebGL2 через OffscreenCanvas в отдельном рабочем потоке, что позволяет достичь 60 FPS даже при увеличенном разрешении (до четырёх раз нативного 480×272). Звук, включая музыку и речь, декодируется через портированный ATRAC3/ATRAC3+ декодер из PPSSPP. Для работы требуется кросс-ориентированная изоляция (COOP и COEP), обеспечиваемая локальным сервером с нужными заголовками. Пользователь предоставляет собственный образ диска игры, после чего скрипты генерируют локальную веб-страницу. На данный момент успешно запущены God of War: Chains of Olympus и God of War: Ghost of Sparta, работающие на ноутбуках и смартфонах с сенсорным управлением, хотя видеовставки пока пропускаются. Весь код проекта распространяется под MIT-лицензией, за исключением сторонних компонентов с их собственными лицензиями. Важно: полученный WebAssembly и C++ считаются производными от оригинальной игры и должны храниться только локально.

Статическая рекомпиляция PSP‐игр в WebAssembly воспринимается как прорыв в сохранении игрового наследия, особенно когда оригинальные разработчики не поддерживают проекты. Однако она вызывает споры: некоторые считают, что это стимулирует разрозненные «vibe‐coded» порты вместо совместной работы над единым decomp‐проектом, ослабляя качество и сотрудничество в открытом сообществе. Есть опасения, что такой подход может нарушать законы об интеллектуальной собственности, и крупные компании могут добиваться ужесточения законодательства. Участники отмечают, что AOT‐компиляция и статическая рекомпиляция технически воспроизводят поведение железа, но не считаются традиционной эмуляцией. Автор проекта подтверждает, что порты работают в браузере с приемлемой скоростью даже на старом железе, демонстрируя более 1 000 MIPS в Firefox. Для легального использования необходимо иметь собственный образ PSP‐диска, так как репозиторий не содержит игровых ресурсов. Другие разработчики уже применяют аналогичные методы, например порт Super Smash Bros. Melee для браузера, показывая масштабируемость подхода. Также упоминается, что AI использовался для взлома DRM‐систем, что может привести к судебным искам против разработчиков подобных инструментов.

Эмуляция x86-TSO на ARM — одна из самых сложных задач в совместимости архитектур, поскольку x86 требует строгой согласованности памяти (Total Store Ordering), тогда как ARMv8.0 использует слабую модель упорядочивания, позволяющую значительные аппаратные оптимизации. Это означает, что запись в память на x86 мгновенно видима всем ядрам, а загрузка гарантирует видимость всех предшествующих записей — поведение, ожидаемое программистами. На ARM же записи могут задерживаться в кеше и не быть сразу видимыми другим ядрам без явных барьеров, что нарушает семантику x86-кода, особенно в многопоточных приложениях и синхронных структурах данных.

Ключевые проблемы включают необходимость эмуляции атомарных инструкций (например, LOCK CMPXCHG), которые на ARM требуют дорогостоящих барьеров или циклических попыток с использованием LDXR/STXR; обязательную обработку split-lock операций (когда доступ пересекает границу кеш-линии), которые на ARM не поддерживаются аппаратно и требуют дорогостоящих программных обходов; и работу с некешируемой памятью (uncached), где доступы должны строго соблюдать порядок и не могут быть буферизованы — критично для устройств ввода-вывода и видеопамяти. На UMA-системах (например, Tegra, Snapdragon с Adreno 600+) проблема частично решается через принудительное использование кэшированных буферов в видеодрайверах, что исключает доступ к uncached памяти. Пользователи Asahi Linux с аппаратным битом TSO избегают проблемы естественным образом, но добавление дискретного PCIe GPU вновь вводит несовместимость. Несмотря на прогресс вендоров в решении отдельных аспектов, полное устранение накладных расходов остаётся вызовом, и эмуляция x86-TSO продолжает требовать значительных компромиссов между производительностью и корректностью.

Обсуждение дополняет статью, раскрывая практические аспекты эмуляции x86 на ARM: Apple внедрила TSO-режим в чипы, но не устранила все крайние случаи; FEX демонстрирует прогресс в эмуляции на Linux с поддержкой Steam и Crossover. Apple добавила TSO-режим в свои чипы для эмуляции x86 благодаря вертикальной интеграции и контролю над железом, но это не устраняет все крайние случаи. Спор: слабая модель памяти ARM не даёт значительных преимуществ в производительности, тогда как автор Rosetta 2 утверждает, что она улучшает производительность за счёт гибкой оптимизации. FEX — открытый фреймворк для эмуляции x86 на ARM, спонсируемый Valve, используется в Steam Deck и Crossover Beta, демонстрируя значительный прогресс в эмуляции x86 на Linux. Эмуляция одного ядра может обойти проблемы упорядочивания памяти, но с потерей производительности — приемлемо для устаревших рабочих нагрузок, где скорость не критична. При эмуляции x86 на ARM в пользовательском режиме (например, FEX на Linux) накладные расходы TSO на нативный ARM-код незначительны, так как нативного ARM-кода выполняется крайне мало. Разработка TSO-режима в Apple требовала координации множества команд, что стало возможным благодаря стратегическому приоритету продукта на высоком уровне. FEX на macOS позволяет запускать Wine на чипах M-series, но его использование ограничено из-за анти-ИИ политики, требующей форка. Вопрос о компиляции бинарников в байткод вместо эмуляции не решён, поскольку это требует переписывания всего экосистемного стека, а не только эмулятора.

Основная идея — полностью эмулированная графическая среда, работающая на реальном IBM PC XT с процессором 8088, где каждый запущенный элемент (окно, панель, мини‑приложение) представляет отдельный процесс, имеет собственный док‑тик и независимый буфер памяти. При этом ядро управляет прерывками, планированием и выделением сегментов так, что даже простые программы, как MINES (1,5 КБ) или HELLO, загружаются в собственные 2 КБ и 512‑байтные области без модификации кода.

Особенности, которые запоминаются: одновременная работа до пяти программ, включая «живой» About‑box, отображающий состояние планировщика, и плавный XOR‑трекинг курсора при перемещении окна; минимизация не останавливает фоновые задачи, а лишь скрывает их визуализацию; иконки файлов берутся непосредственно из первого сектора диска, а графические редакторы (Paint, Fractal) используют буферы и кольцевые истории, позволяющие выполнять фоновые операции, пока запущены ресурсоёмкие приложения. Всё это демонстрирует, как ограниченные ресурсы IBM PC XT могут поддерживать современный‑по‑удобству пользовательский интерфейс.

Тред обсуждает реализацию графической ОС Os8088 для IBM XT, 286, 386: участники анализируют код, производительность и опыт использования подобных систем, а также роль ИИ в разработке. Проект признаётся интересным примером графической ОС на старом железе, но некоторые скептически относятся к применению ИИ. Обсуждается уязвимость к перезаписи обработчиков прерываний и таймера — одни считают это значимой проблемой, другие — нет. Предлагаются улучшения: поддержка сети, улучшение интерфейса, портирование приложений вроде WordStar и VisiCalc. Отмечается потенциал ИИ в создании сложных систем, но подчёркивается необходимость человеческого участия в разработке и документировании.

Kazeta – Just Play
ОС, возвращающая консольный гейминг 90-х на современное железо: вставил картридж, нажал Power – и играешь.

---

Чистый гейминг

• Без настроек, обновлений, аккаунтов
• Максимальная производительность
• Полное погружение без отвлекающих факторов

---

Создай – коллекционируй – играй

• Делаем физические картриджи из DRM-free игр (SD-карты и др.)
• Игра без интернета и ограничений
• Коллекция навсегда остаётся playable

---

Спокойствие

Никаких: DRM, онлайна, серверов, обновлений, лаунчеров, подписок, микротранзакций.

---

Управление сохранениями

• Автосохранение прогресса
• Ретро-BIOS для просмотра, удаления, резервного копирования сейвов

---

Поддержка игр

• DRM-free AAA и инди
• GOG, itch.io, Linux, Windows
• Классика через эмуляторы

---

Для всех

Безопасно и просто: детям, родителям, бабушкам – всем, кто хочет «просто играть».

---

Скачать kazeta-2025.08.21-x86_64.iso

• Kazeta — это Linux-дистрибутив, который при включении ищет первый файл KZI на SD-карте и запускает описанную в нём игру, имитируя «вставил картридж — сразу играешь» консоль 90-х.
• Пользователей привлекает физическое владение играми, отсутствие онлайн-аккаунтов, патчей, микротранзакций и «анализа выбора».
• Критика: сайт мало что объясняет; SD-карты быстро изнашиваются, мелки и дороги; одна карта = одна игра — расточительно.
• Предложения: использовать карты как «ключи» к уже установленным играм, делать мультиигровые карты, обернуть SD в корпус размером с гейм-картридж.
• Проект ориентирован на ностальгирующих и на родителей, которым проще контролировать детский доступ к играм.