Эмулятор ZX Spectrum на C++ довели до рабочего состояния за пару часов с помощью больших языковых моделей: архитектуру спроектировала Qwen, код процессора Z80 и обвязку написал DeepSeek, ULA и клавиатуру доработал Sol. Прирост скорости оказался заметным, но неравномерным. Дисковый контроллер WD1793 (КР1818ВГ93) модели не осилили без ручной проверки. Практический итог такой: LLM закрывают типовой код и рутину, а сложные низкоуровневые узлы по-прежнему требуют участия эксперта.
Год назад тот же автор написал эмулятор на Go, а затем критиковал Go как неподходящий язык для эмуляторов. Переписывание на C++ совпало с пересмотром рабочего процесса: к проекту подключили Qwen, GLM, Sol, DeepSeek и Claude, в том числе через Astra, плюс GPT для ревью. Роли распределились по сильным сторонам моделей.
Оценка автора за год: модели дотянулись до уровня джуниоров. Оговорка тоже конкретная: человек уступает машине в широте знаний, зато умеет творить. Дальше разберём, какие этапы удалось делегировать, а где модели выдали красивый, но нерабочий код.
Зачем вообще использовать LLM для эмулятора ZX Spectrum
Эмуляция ZX Spectrum требует точной работы с таймингами, шиной, портами и памятью. Такой код традиционно пишут вручную, потому что ошибка в один такт ломает загрузку или графику. В этом проекте LLM взяли на себя генерацию архитектуры, каркас компонентов и рутинные участки.
Основной выигрыш пришёлся на скорость прохождения этапов. Модель предлагает структуру, сразу пишет заготовки модулей и подсказывает, как связать компоненты между собой. Человек проверяет поведение на реальных образах и ищет расхождения там, где логика не сходится.
Первую версию автор написал на Go и позже объяснял, почему golang плохо подходит для эмуляторов. Переписывание на C++ стало отдельным этапом, и модели заметно его ускорили. Полный разбор опыта с деталями по компонентам приведён в статье «LLM против ZX Spectrum. Часть 3».
За год возможности моделей выросли, и автор формулирует это прямо: «Сегодня я смело могу утверждать, что по своему уровню они достигли джунов». Это субъективная оценка практика, а не результат независимого бенчмарка, поэтому принимать её стоит как ориентир, а не как измеренную характеристику.
Какие модели использовались и для каких задач
Набор моделей оказался шире одной. У автора был доступ к последним Qwen, GLM и Sol, а рядом лежали аккаунты к Claude через Astra, как описано в разборе опыта. GPT применялся для ревью, DeepSeek закрывал процессорное ядро. Разделение ролей работает: одна модель весь эмулятор не вытягивает, зато связка закрывает разные типы задач.
| Модель | Задача в проекте |
|---|---|
| Qwen | Архитектура новой версии, файл ARCHITECTURE.md |
| GPT | Ревью архитектуры |
| Sol | Ревью архитектуры, доработка ULA и клавиатуры |
| DeepSeek | Ревью архитектуры, Z80, обвязка по шине, портам и памяти |
| GLM, Claude (в том числе через Astra) | Участвовали в разработке, конкретные роли в источниках не детализированы |
Qwen: генерация архитектуры
Автор попросил Qwen нарисовать архитектуру новой версии эмулятора, и модель выдала здоровенный файл ARCHITECTURE.md. Этот файл затем ушёл на ревью к GPT, а следом его смотрели Sol и DeepSeek. Ключевой сдвиг, который предложили модели, состоял в переходе от машины состояний со спагетти-кодом к блочной эмуляции каждого компонента: процессор, видео, звук и периферия получают собственные модули и интерфейсы.
Блочная схема упрощает отладку. Сбой локализуется внутри одного компонента и не расползается по общему циклу, а значит, время на поиск регрессий сокращается. О том, как устроен запуск и поведение Qwen-моделей на одной видеокарте, мы разбирали в материале про Qwen 3.8 27B на одной RTX 5090.
DeepSeek и Sol: реализация Z80, ULA и клавиатуры
DeepSeek занялся Z80 и обвязкой по шине, портам и памяти. Sol доработал ULA и клавиатуру. Результат пришёл быстро: за пару часов появился эмулятор, который сохранял изображение с классической надписью Sinclair Research Ltd. Это проверяемый признак того, что ядро проходит начальную инициализацию и выводит картинку.
Поведение DeepSeek на генерации кода удобно оценивать отдельно, вне контекста эмулятора. Практический разбор его сильных и слабых мест на сложных сценариях собран в статье про DeepSeek-V4-Flash и его ограничения.
Как LLM справились с дисковым контроллером WD1793 (КР1818ВГ93)
Самым сложным местом стал дисковый контроллер WD1793, он же КР1818ВГ93. Здесь модели перестали помогать: они не смогли ни написать рабочую версию, ни найти ошибки в чужом коде. Этот момент отдельно подчёркнут в разборе проекта.
Даже с даташитами и примерами из других эмуляторов результат сначала выглядел красиво, но не работал. Продвинуться удалось лишь после ручной проверки через другие эмуляторы и добавления референсов. Причина в природе самого контроллера: WD1793 требует точной последовательности команд, корректной работы с регистрами и аккуратных таймингов, которые не выводятся из общего описания. Модель уверенно генерирует похожий на правду код, а проверка на реальных образах дисков выявляет расхождения.
Практический вывод: для контроллеров и других узлов с жёсткими таймингами нужна ручная верификация и сверка с уже работающим эмулятором. Без этого аккуратный на вид код остаётся нерабочим, а время на диалог с моделью тратится впустую.
Проблемы с fyne и переход на SDL3
Микрофризы, убивавшие геймплей в первой версии, возникали из-за тотального буферизирования. Причина оказалась на стороне библиотеки fyne для фронтенда: внутри неё слишком много буферизации, из-за которой появлялись лишние лаги. Детали этого этапа собраны в описании разработки.
После переноса фронтенда на SDL3 работа пошла быстрее. Задержки, которые портили управление, ушли, и эмулятор стало можно использовать для игр, а не только для отладочных запусков.
Случай с fyne показывает границу возможностей LLM. Проблему на уровне чужой библиотеки модель не видит, потому что не запускает графику и не измеряет задержки. Диагностика потребовала ручного анализа: нужно было отделить логику эмулятора от поведения фреймворка и найти источник лагов.
MCP-сервер: автоматизация тестирования и компиляции
Автор подключил MCP-сервер и фактически превратил ИИ в команду помощников: модели компилировали код, сравнивали результаты и исправляли ошибки. Автоматический цикл сборки и прогонов снял с человека часть рутины и ускорил итерации. По данным разбора проекта, такой контур дал заметный прирост продуктивности.
Функциональность эмулятора тоже выросла. Появились пошаговое исполнение, дизассемблер и OCR, а сам эмулятор дорос до чтения кассетных образов и проигрывания музыки. Это уже не демонстрация вывода картинки, а инструмент для отладки и повседневного использования.
Подводный камень нашёлся в интерфейсе: ИИ не всегда понимает разницу между обычным вводом с клавиатуры и токенизированным вводом в MCP. Из-за этого команды уходят не туда, куда задумано, и цикл приходится корректировать вручную. Плата за автоматизацию - дополнительные проверки на стыке инструментов.
Практические выводы: как работать с LLM над сложным проектом
Автор собрал выводы из своего опыта и сформулировал их в статье. Общая логика такая: модели дают скорость, а корректность обеспечивает человек.
Мультимодельность и агрегаторы
Использовать несколько моделей и агрегаторы: Qwen, GLM, Sol, DeepSeek, Claude. Разные модели сильнее в разных задачах. Qwen написала ARCHITECTURE.md, GPT и Sol с DeepSeek провели ревью, DeepSeek занялся Z80, Sol доработал ULA. Одна модель весь проект не закрывает. Проверить, как LLM справляется с генерацией кода на нестандартной механике, помогает внешняя валидация, например эксперимент с Minecraft-подобной игрой.
При выборе моделей полезно смотреть не только на свежесть релиза. Обзор того, как меняется расстановка сил между открытыми LLM и почему рейтинги бенчмарков не всегда совпадают с реальным качеством, есть в материале про отставание DeepSeek от Qwen и GLM.
Сброс контекста и работа с памятью
Контекст нужно регулярно сбрасывать, иначе модель теряет нить и начинает путать роли. На длинных проектах эффект заметнее: чем больше в окне устаревшего кода и диалога, тем ниже качество решений. Принцип простой - начинать новый этап с чистым контекстом и точной постановкой задачи, а не тянуть историю всего проекта до последнего сообщения.
Знание предмета важнее модели
Для правильных результатов нужно знать предмет глубже, чем модель. Пример с WD1793 это подтверждает: без ручной проверки через другие эмуляторы и добавления референсов модели не продвинулись. Человек задаёт критерии корректности и распознаёт правдоподобную ошибку, а модель ускоряет путь к этим критериям. Автор описывает разницу так: «Настоящий кожанный мешок не обладает такой широтой знаний. Но зато умеет творить».
Стоит ли повторять этот опыт: ограничения и риски
LLM ускоряют рутину, но экспертизу не заменяют. На сложных низкоуровневых задачах, таких как дисковые контроллеры и точные тайминги, модели ошибаются, и к ручной отладке нужно быть готовым заранее. Если в проекте критична каждая тактная задержка, рассчитывать на готовое решение от модели не стоит.
Часть выводов опирается на личный опыт автора и его субъективные оценки. В источниках нет данных о конкретных версиях моделей, точных метриках и сроках, поэтому сравнить ускорение в процентах не получится. Доступ к нескольким аккаунтам и агрегаторам тоже есть не у всех, а значит, часть сценариев придётся адаптировать под свои инструменты.
Разумный сценарий применения выглядит так: делегировать моделям прототипы, каркас, типовые модули и рутинные прогоны, а критичные компоненты проверять вручную, сверяя поведение с рабочими аналогами. Тогда LLM дают скорость без потери корректности, а глубокое знание предмета остаётся тем, что определяет итоговый результат.