monobogdan

Думаю, многие мои читатели встречались с таким неприятным явлением, как отвал чипа. Эта поломка свойственна многим топовым и околотоповым гаджетам из нулевых: ноутбуки с «отваливающимися» видеочипами и мостами, первые ревизии Xbox 360 (три красных огня) и PlayStation 3 (жёлтый огонёк и моментальное выключение), телефоны-«ударники» и другие девайсы с достаточно горячими чипами. Недавно я листал барахолки на предмет интересных девайсов «за копейки» и наткнулся на топовый игровой ноутбук 2007 года выпуска всего за 1.000 рублей (~10$) — Toshiba <модель>, с просто дичайшими характеристиками для тех лет: GeForce GTS 7900 Go, Core Duo Txxx, 1гб DDR2 ОЗУ и аудиоподготовкой от Harman-Kardon.

Сегодня мы с вами узнаем: почему отваливаются чипы и как продлить жизнь старому топовому железу, «дунем» на видеочип, «воскресим» его на некоторое время и посмотрим, что же крутого было в топовых ноутбуках тех лет. Интересно? Тогда добро пожаловать под кат!

❯ Почему чипы «отваливаются»?

В мире производства электроники и плат есть несколько различных видов монтажа чипов на платы. Все они зависят от корпусировки того или иного элемента. Обычно, сложные микросхемы выпускаются в нескольких различных корпусах, которые отличаются маркировкой и иногда функциональностью. В современном мире принято использовать несколько самых распространенных типов корпусов:

DIP— один из самых старых и тем не менее, до сих пор распространенных видов корпусов для чипов. Для таких микросхем сверлятся отверстия в плате, а затем чипы вставляются в отверстия и припаиваются, благодаря чему чип надежно держится на плате. Плюсов у такого способа довольно много: удобство пайки, возможность лёгкой установки чипа в сокет и быстрой его замены (привет Arduino и чипы памяти с BIOS на старых материнских платах), большая надежность соединения, и вероятно, простота производства. Минусов у такого способа тоже хватает: невозможность сделать микросхему с очень большим количеством пинов, громоздкость чипа, без фена чипы с большим количеством ножек выпаять проблематично. Известные примеры: сдвиговые регистры, МК AVR, Z80, MOS6502.

QFP/QFN/SOIC— современный способ монтажа чипов с большим количество пинов на плату. По принципу все они похожи: по разным сторонам микросхемы есть выводы, которыми можно припаять чип к плате. Однако у QFP ножки «торчат» наружу, что даёт возможность легко припаять их к плате, а у QFN контакты спрятаны под пузом самого чипа, из-за чего их можно припаять только феном (если чип достаточно мал — можно попробовать паяльником). Плюсы: надежность пайки, относительная простота монтажа и демонтажа (дунул и чип слетел). Минусы: для таких чипов практически нет сокетов (на самом деле есть, но особо никакой унификации нет — чаще всего сокеты можно встретить в материнских платах и программаторах у ремонтников).
SOIC немного другой тип монтажа, поскольку там ножки выводятся только по бокам чипа (как у DIP), но я не стал выносить его в отдельный типаж.

LGA/PGA/SMT— кристалл или кристаллы (пример — процессорное ядро и отдельно кэш-память на старых процессорах) распаяны на специальной небольшой плате, которая называютсяподложкой. Такие микросхемы обычно предназначаются для установки в сокет (процессоры), либо для пайки платы на плату (SIM800L). Даташит на SIM800C называет свою корпусировку какSMT, поэтому я отнесу его и различные системы на модуле («процессорные» платы с ОЗУ и ПЗУ) к LGA. Один раз я видел PGA-процессор AMD Geode, который запаивали напрямую штырями в плату — но может, меня обманывает память.

BGA— основной тип корпуса для сложных и компактных микросхем таких как SoC или видеочипы. Его суть проста: на плате и на нижней стороны чипа есть маленькие пятачки круглой формы (их размер отличается в зависимости от числа пинов, но стандартизирован), благодаря которым микросхема припаивается к плате. Такой корпус позволяет компактно вывести довольно большое количество пинов — например, SoC MediaTek MT6572 поставляется в корпусе аж с 428-шариками! С завода чипы приходят с уже накатанными шарами, в то время как работнику или машине остаётся их только припаять на плату. Несмотря на большое количество крошечных пинов, при наличии сноровки и должном оборудовании, пайка микросхем очень простая: физика всё сделает за вас и сама «притянет» чип к нужным пятачкам на плате. Это один из самых распространенных корпусов для микросхем и один из самых проблемных. Но почему? Давайте разбираться!

Отвал BGA-чипов далеко не всегда связан с термическим воздействием, как принято считать в широких кругах (от чего и идут советы по типу «погрей видяху в духовке»). Шарики достаточно сильно подвержены влиянию множества внешних факторов: попадание воды — в таком случае, шарики окисляются и со временем могут отгнить вместе с пятачками, падениям — такие устройства называются «ударниками» и шары могут дать микротрещину, что уже может сказаться на нестабильной работе устройства, и в немалой степени — термическому воздействию. Причём здесь мнение делится на два лагеря и сильно зависит от самого устройства.

Отвалы на смартфонах/планшетах в основном являются следствием неудачного падения и лечатся перекаткой уже установленного процессора, иногда — заменой на точно такой же «донорский» и с идентичной маркировкой (да, среди SoC бывают свои «подверсии»). Реже бывает срывает пятачки — тогда опытные мастера ковыряют плату и ставят перемычки вместо отвалившихся шаров (моё почтение вам!). В последнее время замена отдельных чипов на мобильных устройствах сильно затруднена: у девайсов есть жёсткая привязка между ID-процессора (прожжен на заводе в SoC), ID-процессора, записанного в флэш-памяти устройства (в специальном RPMB-разделе, доступный только для чтения, используется для Secure Boot, просчета ключей, шифрования и т. п.) и привязки к модему (насчет Android-устройств точно не могу сказать, но у iPhone такая привязка есть ещё с начала 10х годов: в один момент, после очередного апдейта iOS, многие девайсы с замененной NAND или процессором без замены всех трех чипов, висели на «сбое активации» — и в официальном сервисе такой аппарат не принимали), из-за чего при замене процессора или флэш памяти, придётся менять вообще всю пару на оный с донорского аппарата (а в случае iPhone — еще и не привязанный к iCloud).

Нормальные мастера обычно именно перекатывают чипы, т. е. снимают старые шары и накатывают с помощью трафарета новые, поскольку прогрев может поднять устройство, но это не ремонт, а лишь диагностика — такое устройство может в любой момент «отвалиться». Правда, есть и исключения.

Другой вопрос — отвалы чипов на ноутбуках и десктопах. На десктопных материнских платах отвал — не очень частое явление, поскольку отваливались обычно «горячие» северные мосты по типу nForce (которые славились довольно неплохими интегрированными GPU — тут уж попробуй не нагрейся при очень слабеньком пассивном охлаждении). Сейчас «северник» переместился в процессор, поэтому свежим десктопным материнкам это почти не грозит, однако другое дело — ноутбуки.

Система охлаждения на ноутбуках частенько подразумевает расположение ЦПУ и чипсета (а иногда и GPU) на одной теплотрубке, из-за чего тепло отводится заметно менее эффективно. А особенно ситуация плохая на тех девайсах, которые никто не чистит. И если процессор ещё может начать троттлить (занижать частоты) для того, чтобы понизить температуру ниже определенного порога — то что делать чипсету? После пары лет работы в таком режиме, девайсы внезапно начинают виснуть посередине работы, перезагружаться, выключаться или выдавать непонятные артефакты. Тем же самым когда-то страдала печально известная первая ревизия Xbox 360 — Xenon, которая выдавала три красных огня. Не обошла проблема и PS3 — вспоминаем желтые глазки и выключение устройства.

Даже если взять пример с Xbox 360, когда игрок нёс устройство в неофициальный СЦ, ему перекатывали горячий GPU от ATI (отваливался именно он) и снова припаивали к плате, включили — устройство работает и выдали обратно игроку. Игрок приходит довольный домой, играет день, месяц или даже год и… сталкивается с той же самой проблемой! Снова три красных огня, хотя девайс вроде бы чистый, шуба пыли из него не торчит, а при разборке оказывается, что система охлаждения визуально в норме и кулер работает… в чём же тогда дело?

Всё дело в том, как припаивается кристалл процессора или GPU к плате-подложке. По сути, подложка может быть любой, хоть LGA, хоть BGA: китайские умельцы как-то приноровились делать десктопные подложки для мобильных процессоров в BGA-корпусах. Но сам кристалл припаивается к подложке с помощью точно таких же BGA-шариков, как и подложка к плате, только гораздо меньших размеров. Перекатать такие шары доманевозможно, это можно сделать только в заводских условиях. Но поскольку сами кристаллы залиты компаундом (как раз таки с целью предотвратить внешнее влияние, в том числе и термическое — иначе кристаллы сдувались бы только так), а шарики достаточно маленькие — при прогреве устройства феном, в духовке (популярный когда-то метод), или даже перекатке шаровна подложке, из-за термического воздействия контакт между кристаллом и подложкой на время восстанавливался. Однако поскольку GPU Xbox 360, который я привожу в пример, очень и очень горячий сам по себе, вне зависимости от того, как хорошо от него отводится тепло, со временем контакт кристалла с подложкой снова нарушался и устройство переставало работать…

Происходило это по причине выбора неправильного типа припоя: в целях сохранения природы, использовался не совсем верный состав. Однако зная о проблеме, производители продолжали использовать его примерно до середины 2010-х годов: насколько мне известно, GeForce 1xxx серии и выше не страдают отвалами GPU вообще (но там своих болячек хватает — как минимум, те же банки памяти). Почему так происходило? Вероятнее всего, это изначально закладывание ресурса в технику. И если бюджетные ноутбуки со встроенной графикой и Celeron'ами от этого особо не страдали (их до сих пор очень много на юлито, живеньких и вполне рабочих), то топовые и дорогие устройства с горячими видеочипами отваливались только так…

Прогрев — это исключительно диагностический способ, им можно пользоваться либо в домашних условиях «для себя», либо для того, чтобы выявить неисправность одного из элементов устройства. Брать деньги за прогрев — прямой обман, но если делать просто «для себя», ради того, чтобы немного продлить жизнь крутому девайсу из прошлого — почему бы и нет? Предлагаю в практической части нашей статьи глянуть на топовый ноутбук 2007 года отToshiba, который я купил всего за 1.000 рублей (~10$). Девайс сам по себе очень крут, однако страдал отвалом GPU, который мы на время «вылечим»!

❯ Практическая часть статьи

Сегодняшнего подопытного продавала женщина на запчасти. Состояние было неизвестным: я не спрашивал её ни о симптомах поломки, ни о том, включается ли ноутбук вообще. Я списался с продавцом, договорился об условиях доставке и зарезервировал девайс себе. Через несколько дней ноутбук наконец-то приехал ко мне и я решив не медлить, сразу полез его диагностировать:

Внешне девайс очень симпатичный и сейчас — самое время его включить! Единственный нюанс: проприетарный трапецевидный разъем зарядки. Не беда: до этого я брал другой тошибовский ноутбук за… 300 рублей, который тоже оказался вполне живым, но у него были сломаны петли ( к буку за 3 доллара шёл и родной БП, который уже кто-то ремонтировал на скрутках, но он всё ещё оставался рабочим).

Включаем девайс, прощелкиваем нумпадом и видим, что реакция на него есть, однако изображения нет! Это значит, что ноутбук нормально проходит POST и висит на «CMOS Error, F1 to Continue», однако отсутствие картинки было для меня первым звоночком винить видеочип. Поскольку POST ноутбук проходил, то и реагировал на хоткей смены матрица/VGA: подключаем внешний монитор и видим…

Да, это самый классический отвал GPU. Ну а что вы хотели, GeForce 7900 это вам не шутки! Поскольку это ноутбук с дискреткой 7 серии, ни о каком UMA и речи не идет: отключить GPU и направить вывод на встроенный адаптер не получится. Вернее теоретическая возможность то есть, но линии LVDS/VGA идут с GPU, а не с хаба, как это происходит в современных ноутбуках. Девайс то может и включится, но никакой картинки вообще не будет — если устройство вообще пройдет POST.

Самое время разобрать красавца. Делается это не особо сложно: классическая разборка «с клавиатуры». Для обслуживания системы охлаждения придётся разбирать ноутбук полностью (в том числе снимать матрицу), но никаких особых проблем с этим не возникает: девайс хорошо продуман. При разборке выяснялась причина отсутствия изо на LVDS — матрицу банально отключили. Девайс явно обслуживали до меня и чистили, видимо в надежде что всё «оживет». А может и грели уже, кто его знает? :)

Да, «охлад» здесь и правда довольно серьезный: круче я видел только в ноутбуке с дискреткой ATI и… десктопным Pentium 4!

На ноутбуках тех лет частенько практиковались по настоящему съемные видеокарты. Помимо стандарта MXM (его сейчас вроде только Clevo как-то поддерживает), который предусматривает замену видеокарты в ноутбуке, некоторые вендоры придумывали свои коннекторы а-ля PCI-E. Наш девайс как раз из таких: видеокарту, при желании, можно было заменить на идентичную (возможно и какие-то другие от младших «тошиб» подходили, но мне это неизвестно).

Снимаем массивную систему охлаждения, которая отводит тепло и от GPU, и от чипов памяти и приступаем к прогреву. Для прогрева подойдет фен от паяльной станции, или даже регулируемый строительный фен (с ним осторожнее, есть шанс угреть чип). Для наглядности «дриставрации», я буду пользоваться именно строительным «интерсколом». Ставим температуру ~250 градусов (в случае строительных фенов — это погода на луне или попугаи, ну или средний режим) и осторожно греем кристалл по периметру. Для временного оживления чипа хватит дунуть секунд 15-30. Дольше не стоит — могут повылазить шары. Никаких утюгов и духовок — это кощунство!

Подсобираем ноутбук и включаем его. Ура, в биосе изображение есть и на первый взгляд всё нормально. Однако, после такой «дриставрации», проблемы могут вылезти где угодно: ошибка 43, артефакты в 3D-режиме, самопроизвольные ребуты и зависания системы. Самое время накатить систему и проверить это.

И таки да, они вылезли практически сразу, причём совершенно с неожиданной стороны. Девайс начал самопроизвольно отключаться в определенные моменты времени (обычно при старте Windows и игр), причём вне зависимости от подключения БП (отметаем версию, что АКБ не держит нагрузку) и заряда аккумулятора (отметаем, что не хватает мощности БП), а температуры судя по датчикам — в норме. Вероятнее всего, проблема в питальниках на GPU/CPU.

К сожалению, нормальные тесты при таких условиях сделать не получится — девайс нужно диагностировать дальше, но делать это с отвальным видеочипом такое себе. Но Proof of Concept есть: многие чипы вполне реагируют на прогрев и могут даже поработать какое-то время. Надолго ли?

❯ Заключение

Данный материал писался в эдаком «научпоп» стиле. Для опытных ремонтников, написанный текст отнюдь не станет каким-то откровением, но полагаю, было всё же интересно почитать о том, почему их любимые девайсы из нулевых «помирают».

Статья подготовлена при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, , чтобы не пропускать новые статьи каждую неделю!

Статьи про инди-разработку игр — это всегда интересно и занимательно. Но статьи про разработку игр с нуля, без каких-либо игровых движков — ещё интереснее! У меня есть небольшой фетиш, заключающийся в разработке минимально играбельных 3D-демок, которые нормально работали бы даже на железе 20-летней давности. Полтора года назад, в мае 2022 года, я написал демку гоночной игры с очень знакомым всем нам сеттингом — жигули, девятки, десятки, и всё это даже с тюнингом! В этой статье я расскажу вам о разработке 3D-игр практически с нуля: рендерер, менеджер ресурсов, загрузка уровней и граф сцены, 3D-звук, ввод и интеграция физического движка. Интересна подробнейшая статья формата "старого Пикабу" о разработке игры с нуля? Тогда добро пожаловать!

❯ Предыстория

На момент написания статьи, я всё ещё остаюсь достаточно юным — буквально 5 дней назад мне исполнилось 22 года. Но если откатиться на 4 года назад и вспомнить момент наступления моего совершеннолетия, то на ум приходят сразу два значимых события: отец приходит в один день и говорит «открывай юлито, будем смотреть авто за 40 тыщ рублей». Понятное дело, что за эту сумму (~700$ по тому курсу) особо не разгуляешься, поэтому мой выбор пал на карбюраторную «семерочку», свою ровесницу (2001 год) синего цвета. Приехали с батькой смотреть на машину, обкатали и приняли решение — надо брать!

С тех пор я ездил на своем «тазе» и горя не знал — машинка не ломалась, ни разу не подводила, вложений в себя не требовала, а я начал все больше увлекаться автомобилями и изучать тематический материал. Со временем я полюбил и другие российские модели автомобилей, но особенно мне нравился АвтоВАЗ. В один момент, вспомнив про популярный и провальный некогдаLada Racing Club, мне захотелось написать «гоночки на жигулях» самому, причём полностью с нуля. А поскольку нормального арта для города у меня не было, игру я решил назвать просто и понятно: «Ралли-кубок ТАЗов» :)

Поём всем Хабром!

Но с чего начинать писать такой объемный проект самому? Тут нам, конечно же, нужен план. У меня уже был готовый самопальный 3D-фреймворк для игрушек, который я использовал в одной из прошлых демок: арена-шутер от первого лица с модельками из модов для Quake. Фреймворк был вполне рабочим, но требовал некоторой доработки для использования в «кубке тазов».

На момент начала разработки гоночки у меня уже были готовы следующие фишки:

• Рендерер: Direct3D9, причём полностью FFP — для того, чтобы игра запускалась даже на встройках Intel, где нормальной поддержки шейдеров до HD-серии вообще не было. Практически все текстурные техники работали через комбайнеры — дальний предок пиксельных шейдеров, где программист оперировал целыми стадиями пиксельного конвейера, а не писал программу напрямую, что накладывало множество ограничений. Поддерживались: многослойные материалы, однопроходной сплат-маппинг для плавного текстурирования ландшафтов, отражения в кубмапах, плавный морфинг (вершинная анимация) с линейной интерполяцией между кадрами, MSAA (это заслуга GAPI), отсечение невидимой геометрии по пирамиде видимости и примитивный альфа-блендинг с ручной сортировкой.

• Звук: 3D-звук на DirectSound с позиционированием относительно источника звука, ускорением и т. п. Тут моей заслуги особо нет, кроме загрузчика wav-файлов я ничего не писал.

• Ввод: WinAPI + DirectInput. Клавиатура опрашивалась с помощью классического GetAsyncKeyState, в то время как геймпады с помощью DirectInput. Была и абстракция осей ввода — дабы не адаптировать управление под кучу разных контроллеров.

• Менеджер ресурсов: достаточно примитивен. К менеджеру ресурсов я отнесу и загрузчики — фреймворк поддерживал модели в форматах SMD (не анимированные меши, формат Half-life) и MD2 (анимированные меши, формат Quake 2, строго один материал на один меш), звуки — wav и простенький самопальный формат конфигов. Стандартный набор: трекинг ресурсов на слабых ссылках, пул ассетов для исключения дублирующейся загрузки и т. п.

Фреймворк выдавал не слишком крутую графику:

Зато был очень простым «под капотом», имел довольно неплохую расширяемую архитектуру и в целом, на нем можно было запилить что-то прикольное. Где-то за неделю я запилил вот такую демку шутера от первого лица:

Игрушка даже на VIA UniChrome работала — последователе всем известного S3 Savage/S3 Virge!

Минимальное приложение выглядело примерно так:

Приведённый выше код нарисует модельку с текстурой перед лицом игрока. Всё просто и понятно. Однако, как это всё работает «под капотом»? Давайте попробуем разобраться:

❯ Основа и рендерер

В своих играх я стараюсь придерживаться одной архитектуры: есть условный класс Engine, который управляет созданием платформозависимых окон, организацией главного цикла игры и инициализацией подсистем. Поскольку в одном процессе обычно запущен только один экземпляр игры (исключение — выделенные авторитарные серверы с комнатами, на манер Left 4 Dead), сам по себе Engine является синглтоном и содержит в себе ссылки на все необходимые подмодули.

Game.Initialize(new GameApp());

Game.Current.Run();

Как я уже говорил выше, сам по себе рендерер построен на базе графического API Direct3D9. Выбор DX9 обусловлен его распространенностью на железе прошлых лет, хорошей совместимостью (DX9 легко запускается на железе времен DX8 и даже DX7) и иногда лучшей производительностью на видеочипах от ATI. По сути, всё начинается с создания контекста или устройства в терминологии DirectX: в параметрах создания контекста указывается ширина и высота вторичного буфера, желаемый уровень сглаживания MSAA, видеорежим и частота желаемая частота обновления экрана.

https://pastebin.com/uba62bhu

При создании контекста есть свои нюансы, которые необходимо учитывать — например, большинство встроенных видеокарт не поддерживают аппаратную обработку вершин (D3DCREATE_HARDWARE_VERTEXPROCESSING), из-за чего создание контекста будет заканчиваться ошибкой без соответствующего флага, разные видеокарты поддерживают разные форматы буфера глубины и трафарета (сейчас видеокарты нативно даже 24х-битный RGB для рендертаргетов не умеют использовать, только выравненный XRGB), а видеокарты до GF5xxx-GF6xxx не поддерживали Pure режим D3D, который предполагает, что программист возлагает всю обработку ошибок на себя, при этом количество проверок в самом GAPI уменьшается, благодаря чему мы получаем небольшой выигрыш в производительности.

Важно так же отметить такой аспект, как управление ресурсами. К ресурсам видеокарты в терминологии старых GAPI относятся текстуры и буферы (как вершинные, так и индексные). В OpenGL особо нет такого понятия, как Device Lost. Если пользователь сворачивает ваше приложение из полноэкранного режима, или, например, видеодрайвер крашится — то GL сам должен позаботится о перезагрузке ресурсов обратно в видеопамять (исключение — Android и iOS, на мобилках контекст не уничтожится, но ресурсы будут выгружены и их хендлы станут некорректными). У D3D есть событие Lost, которое вызывается при потенциальной потере контекста — и его тоже нужно грамотно обрабатывать. Поэтому в D3D есть несколько пулов:

• Managed: D3D9 сам сохраняет копию текстуры или геометрии в ОЗУ, а затем при потере контекста пересоздаёт аппаратные буферы и перезагружает нужные данные сам.

• Default: данные загружаются напрямую в видеопамять (в терминологии D3D — AGP memory), или, если видеопамяти не хватает — в ОЗУ, если видеокарта, конечно, поддерживает Shared Memory Architecture.

• System: загрузка ресурсов только в ОЗУ. Этот пул обычно не используется в играх — слишком медленно.

И грузить данные желательно в пул Default. Иначе при относительно большом количестве ресурсов, игра начнет «жрать» ОЗУ не в себя (пример — Civilization 5). При потере контекста, ресурсы нужно перезагружать с диска «на горячую»!

Переходим к самому важному — отрисовке геометрии. Для задания внешнего вида объектов на экране, используются так называемые материалы, которые содержат в себе данные о том, какая текстура должна быть наложена на объект, насколько объект отражает свет, какая техника должна использоваться и т. п. В современных движках система материалов обычно гибкая, поскольку шейдеры могут принимать самые разные параметры. В нашем случае шейдеров нет вообще, набор параметров фиксирован и зависит от видеокарты: стандартные техники типа повершинного затенения по Фонгу/Гуро, цвет объекта, туман и т. п.

Формат материалов в фреймворке выглядит вот так:

Однако даже без шейдеров была возможность сделать относительно гибкую систему материалов — с помощью комбайнеров, как это делала Quake 3. Самые первые 3D-ускорители не поддерживали смешивание нескольких текстур за один вызов отрисовки, поэтому некоторые игры шли на ухищрение: к примеру Quake вручную сортировал геометрию по отдаленности без использования буфера глубины, он просто… накладывал альфа-блендингом ту же самую геометрию с затененной текстурой освещения (лайтмапа). Это называется многопроходной рендеринг. Комбайнеры, которые появились ближе к концу 90-х, позволяли смешивать несколько текстур с помощью различных операций (Add, Sub, Mul, Xor и т. п.), а также умножать финальный цвет на определенный коэффициент. Именно комбайнеры я использовал в своём фреймворке для реализации некоторых относительно сложных эффектов — например, плавное смешивание текстур на ландшафте:

https://pastebin.com/X6vA76CU

Основная проблема комбайнеров — каша из стейтов, поэтому код выглядит не особо презентабельно. Входная текстура-маска выглядит вот так:

Переходим к отрисовке. По сути, за рисование полигональной геометрии отвечает один метод — DrawMesh, с несколькими перегрузками (в идеале — основной должен принимать матрицу трансформации, а остальные принимать обычные World-space координаты, из которых будет построена матрица трансформации). В оригинале метод рисует геометрию с помощью DIPUP, поскольку практически вся геометрия в игре была анимирована (и анимация, само собой, обрабатывалась для каждой вершины софтварно, на ЦПУ, поэтому я не видел разницы между перезаливкой геометрии на GPU каждый кадр и DIPUP), однако в одном из бранчей фреймворка я переписал отрисовку статику на обычный DIP. Обратите внимание, что DIPUP для комплексной геометрии на старых GPU будет слишком медленным — когда-то этим страдал графический движок Irrlicht.

https://pastebin.com/L0GYCkmt

В более позднем бранче добавилось отсечение по дистанции от «глаз» игрока и по пирамиде видимости.

Переходим к анимации. Есть три основных метода анимации геометрии в играх:

• Скиннинг: анимация вершин относительно скелета модели. Очень хорошо подходит для различных персонажей. Весь скелет является иерархией, где каждый элемент трансформируется относительно позиции родителя, что позволяет легко интегрировать «скелетку» в граф-сцены самого движка (Unity — самый яркий пример). Иногда скелетку используют и для «неоживленных» предметов — например, анимация подвески авто.

• Морфинг: классический способ анимации суть которого заключается в «запекании» всех кадров в виде множества мешей. Затем игра интерполирует вершины между кадрами анимации, благодаря чему достигается эффект плавности.

• Object-Transform: классический метод иерархической анимации, очень похож на скиннинг, только трансформируются не сами вершины, а привязанные к ним объекты. Применялась, например, во многих играх на PS1 и в GTA III (замечали отсутствие плавности в местах сочленений персонажей — это и есть OT).

Я не умею нормально работать с скиннингом моделей в 3D-редакторах и обычно не юзаю скиннинг в своих игрушках — для небольших демок хватает обычного морфинга с интерполяцией. Если интерполяцию не использовать, то анимация будет выглядеть топорно (в Quake 1 при отключении CVar'а такая и была):

https://pastebin.com/Y5r9eDAk

Работа с анимациями выглядела вот так:

По сути, одна из самых комплексных частей — рендерер, готова. Однако в играх требуются и другие подсистемы, которые реализовать куда проще.

❯ Звук и ввод

Реализация звука в играх задача не шибко сложная, если дело не доходит до программной реализации микшера, 3D-позиционирования и различных эффектов. Большинству игр хватает обычного не-сжатого wav, звук в котором хранится в виде PCM-потока.

В качестве API для звука я выбрал DirectSound. Очень удобное API, хотя сейчас его фактически вытеснил XAudio. DirectSound поддерживает любые звуковые карты, сам занимается микшированием звука, а в некоторых старичках типа AC97 умеет даже аппаратное ускорение! На современных машинах обычно микширование реализовано полностью софтварно, дабы не упираться в количество каналов/память на борту звукового адаптера, но в прошлом это помогало снизить нагрузку на процессор.

В DirectSound есть два основных объекта: сам IDirectSound8, представляющий интерфейс к звуковой карте и управлению её ресурсами и буфер — который может быть подкреплен как собственными данными, так и данными из другого буфера. В играх, они делятся на три базовых понятия:

• Слушатель: описание позиции и иных параметров «слушателя» — позиции ушей в игровом мире. Обычно позиция слушателя совпадает с позицией игрока.

• Источник: описание источника звука в 3D-пространстве. Например, если мимо нас проносится машина, то звуковому API необходимо знать позицию, ускорение и дальность звука, дабы правильно скорректировать звук в пространстве.

• Поток: поток, который содержит в себе звук. Может быть как обычным буфером, куда звук уже предварительно загружен, так и потоковым буфером, куда загружается часть музыки или другого длинного трека.

Переходим к реализации примитивного звука:

https://pastebin.com/jrG2iaiT

Теперь мы можем воспроизводить звуки в нашей игре!

Однако, нам нужно чтобы пользователь мог взаимодействовать с нашей игрой. Для этого в разных системах есть различные API для взаимодействия с устройствами ввода. В случае Windows — это DirectInput для обычных USB-геймпадов и рулей, и XInput для геймпадов, совместимых с Xbox 360/Xbox One. Нажатия с клавиатуры можно обрабатывать двумя способами: с помощью событий WM_KEYDOWN и WM_KEYUP и функции WinAPI GetAsyncKeyState.

Пока что мне нужна только клавиатура и мышь:

В идеале обработку ввода лучше абстрагировать от физических устройств взаимодействия. Для этого вводятся понятия осей, кнопок действий и т. п. Желательно сразу продумать, как игра будет работать с геймпадом и уже затем назначать кнопкам на клавиатуре действия абстрактного геймпада.

Ну что ж, самый базовый фреймворк для игр у нас есть. Пора переходить к написанию самой игры!

❯ Редактор уровней

Поскольку у фреймворка нет какого-либо своего графа сцены, я реализовываю механизм загрузки уровней в каждой игре с нуля — под конкретные нужды. В какой-то игре нужен стриминг для открытого мира, в другой — быстрая загрузка уровней, где есть множество объектов с разными параметрами. Изначально я использовал Blender в качестве редактора уровней и экспортировал карты небольшим скриптом, который сохранял основные параметры в файл.

Однако блендер (особенно 2.79 и ниже) не очень удобный редактор для работы с достаточно большими картами. Поэтому в определенный момент встал вопрос с организацией графа сцены и собственного редактора карт.

Граф сцены и графом то не назовешь — это просто линейный список объектов, которые присутствуют на сцене. Каждый объект наследуется от базового абстрактного типа Entity, если это «невидимый» объект, или PhysicsEntity, если объект должен интегрироваться с физическим движком. У базового объекта есть только имя и флаг выборки в редакторе.

Вообще, для редактирования уровней можно хоть редактор Unity использовать, предварительно написав экспортер в самопальный формат. Однако я решил реализовать свой редактор: как обычное Windows Forms приложение + панель, в которую движок рендерит картинку. В его реализации нет ничего необычного: он точно также загружает уровень, как и основная игра, но при этом не создаёт игрока и ботов и имеет свободную камеру.

Формат уровней примитивный донельзя. В процессе разработки небольших игрушек я обычно следую принципу KISS и не люблю распыляться сложными сериализаторами/десериализаторами и прочими заморочками, реализовывая лишь самые необходимый функционал. Формат карт — текстовый, одна линия на один объект:

p ferns 0 0 10.8 0 0 0 1

Где p — «класс» объекта, в случае p — это Prop, «декорация».
ferns — модель пропа. При этом сами пропы описаны в отдельных текстовых файлах, где в виде key-value значений хранятся настройки коллизии, материала, текстуры и т. п.
XYZ — позиция в мире.
XYZ — поворот в мировых координатах, задаётся в углах Эйлера (это только для статики, которая не подвержена Gimbal Lock, под капотом вся работа идёт с кватернионами).

❯ Физика автомобилей

После того, как граф сцены был готов, я приступил к реализации физики автомобилей. Но как я уже говорил, физический движок я использовал готовый — т. е. вся работа по резолвингу столкновений, распаралелливанию вычислений и Joint'ам сводилась чисто к нему. Я лишь использовав физику колеса, реализовал поведение машинки, внеся в него некоторые изменения: в основном — вынес в публичные свойства параметры трения колеса.

Само колесо реализовано по классическому принципу рейкастинга — колесо пускает под себя лучи и определяет трение относительно поверхности, на котором стоит, при этом двигая остальное тело используя собственное ускорение. Сейчас в играх для более точной симуляции используется Pacejka Magic Formula — формула, позволяющая рассчитать физически корректное поведение покрышки с различными диаметрами.

Поскольку класс сущности машинки слишком большой и требует контроля самых разных аспектов (коробка передач, аспекты тюнинга, отрисовка и материалы), я вынес часть физики в отдельный класс CarPhysics:

https://pastebin.com/k9KXtreT

Как можно видеть из метода Move, наша машинка полноприводная и имеет две управляющие оси (передние, само собой). Конфигурацию привода легко можно модифицировать в будущем.
Коллизия кузова машинки — обычный OBB прямоугольник, ну или «коробка».

А вот как это работает на практике:

Пока что гонки на утюгах. Но ездит же. :))
Но с кем мы гоняемся?

❯ Боты

Я не стал называть этот раздел ИИ — боты в игре слишком примитивные. Здесь нет никакого поиска пути, боты просто ездят по заранее отмеченным точкам на карте, которые называются
вейпоинтами. Это стандартная практика во многих гонках, однако её реализация отличается от игры к игре. Вообще, для гонок есть несколько общеизвестных практик реализации навигации противников:

• Вейпоинты с поиском путей: довольно комплексный метод, который позволяет сделать, например, гонки в открытом городе, где боты сами смогут находить путь к чекпоинтам. Подобный способ используется для гонок в GTA, например. Строго говоря, сам по себе поиск путей — это тоже набор чекпоинтов и преград, поэтому для такого метода навигации необходимо довольно большое количество информации (пути для трафика, светофоры и т. п).

• Вручную раставленые вейпоинты: классика. Левелдизайнер вручную расставляет вейпоинты и задает им параметры: например, на этом повороте нужно притормозить, а на этой прямой можно поддать газку.

• Заранее записанные пути: способ с вейпоинтами, где разработчики сначала сами катаются по трассе, стараясь выбить лучшее время, а затем используют записанный набор вейпоинтов для противников.

При этом некоторые разработчики не стесняются красивых фейков: реализация реалистичного входа в поворот с крутой физикой может быть сложной, особенно когда боты «тупые», поэтому в некоторых играх ботам намеренно подкручивали управляемость или максимальную скорость. Помните, как быстро нагоняли соперники в NFS Underground? Вот то-то же. :)

Некоторые могут вообще записать фейковый трек, по которым машина будет просто скользить, без учета физики авто. Но «беспалевные» реализации этого способа я пока не видел.
По настоящему «трушный» способ — это когда противники используют всё те же способы, которые использует игрок — т. е. также «нажимают» на виртуальные кнопки и управляют осями автомобиля. Кроме того, частенько каждому сопернику подмешивают дополнительный фактор, куда он будет ехать — иначе машинки будут толпиться друг за другом и будет выглядеть не интересно.
Я использую классические вейпоинты с подсказками.

Сначала нам необходимо получить угол между машинкой игрока и вейпоинтом. Для этого нам нужно перевести координаты текущего вейпоинта в локальные координаты машинки с учетом её поворота (т. е. относительно неё и её Forward-вектора). Поскольку поворот автомобиля считается в кватернионах, нам нужно помножить матрицу поворота на матрицу позиции машинки в мире и умножить позицию вейпоинта используя полученную инвертированную матрицу. Звучит сложно, на деле легко:

private Vector3 WorldToLocalSpace(Vector3 worldPoint)

{

Matrix transform = Matrix.Invert(Matrix.RotationQuaternion(Rigidbody.Rotation) * Matrix.Translation(Rigidbody.Position));

Vector4 vector4 = Vector4.Transform(new Vector4(worldPoint, 1f), transform);

return new Vector3(vector4.X, vector4.Y, vector4.Z);

}

Если очень условно, то это выражение эквивалентно a — b с учетом поворота. Поскольку мы вычислили локальные координаты вейпоинта, нам остаётся только вычислить угол между ними с помощью классического atan2 и перевести радианы в градусы:

private float AngleBetween(Vector3 v1) {

return (float) Math.Atan2((double) v1.X, (double) v1.Z) * 57.29578f;

}

Полностью логика бота выглядит так:

Легко и просто, да?

❯ Гараж и гонки

Какой интерес в гонках без… гонок? Поскольку у меня не было особо ассетов для создания пригорода, я решил сделать пересеченную местность. А на пересеченной местности у нас есть как кольцевые гонки, так и спринт — от точки до точки.

Помимо этого, в игре должен быть гараж, где игрок мог бы купить новую машину или тюнинговать текущую. В начале игры выдавалась бы старая дедова копейка (модельки Оки не нашел), а то и Москвич, а потом игрок выигрывал бы в гонках и получал возможности про прокачке тачек и покупке новых. Эээх, лавры Lada Racing Club не дали покоя!

Начал я с реализации гаража. Сам по себе гараж — отдельный уровень, который обрабатывается своим контроллером, также в гараже применяется самый первый доступный UI в фреймворке — меню со списками. Сам гараж поделен на множество подменю: тюнинг, гонки и автосалон.

https://pastebin.com/dakm4AvbПараллельно с гаражом, была проработана система тюнячек — они тоже описывались в простых текстовых файлах и так или иначе влияли на ходовые качества машины. Правда, визуального тюнинга не было предусмотрена — некому моделлить апгрейды. :(

Сами гонки можно было начать, обратившись к RaceManager и передав структуру RaceParameters:

public struct RaceParameters {

public string Name;

public string Mode;

public int NumOpponents;

public int Difficulty;

public int Prize;

public int ProgressAffection;

}

После этого, игра загружала уровень, создавала ботов на месте spawnPoint (игрок оказывался, как обычно, последним) и запускала гонку.

https://pastebin.com/mgQJjyJL

А затем каждый кадр просчитывала позиции каждого участника гонки:

https://pastebin.com/0ExwDZaY'

Всё! Логикой движения и всем остальным заправляли уже боты. Хотя, там и был костыль на первых этапах, который помечает флаг конца гонки, в остальном — функционал гоночек рабочий. :)

Вот мы и дошли до этапа, когда простенькая, но рабочая демка игры у нас уже есть! Игра запускается на GF4, однако работает не совсем корректно — но оптимизировать её под видеокарты тех лет не составит труда (в основном — пережать текстуры, убрать некоторые техники на комбайнерах и запечь статические пропы в батчи).

❯ Заключение

Вот так я и написал гоночки за неделю. Время разработки демки с нуля до состояния, которое вы видите в статье — всего неделю. Да, за это время реально написать прототип гоночной игры. И я ведь знаю, что в комментариях игру будут сравнивать с Lada Racing Club и шутить о сроках её разработки — ведь в этом и суть! Слишком мало реально прикольных ламповых гоночек на жигулях. Вот что у меня получилось в итоге:

Исходниками игры я конечно же поделюсь: тык на GitHub.
А вот линки на загрузку демки:

Гоночки

Шутан

Ну а для меня это был своеобразный челлендж. И я его выполнил — у меня получилась рабочая демка на выходе! Я вижу что вам, моим читателям, интересна тематика самопальной разработки игр. Судя по комментариям, вам нравится тематика геймдева, программирования графики и разработки игр. Темой одной из следующих статей может стать описание архитектуры графических ускорителей конца 90х, история их API (без D3D) и написание 3D-игры для 3dfx Voodoo с нуля, на базе Glide!

Кроме того, я хотел бы рассказать о графическом API известного многим «3D декселератора» S3 Virge. Интересна ли вам такая рубрика? Пишите в комментариях!

Статья подготовлена при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, , чтобы не пропустить новые статьи каждую неделю!

В наше время большинство портативных устройств работает на базе достаточно мощных микроконтроллеров, которые способны запускать даже интерпретируемый код на Lua/Python. Чего уж там говорить — даже современная кофеварка или умный электрочайник может быть в разы мощнее оригинального IBM-PC, не говоря уже о автомобильных бортовых компьютерах, которые зачастую мощнее топовых ПК из начала нулевых. Но давайте вспомним конец 90-х и начало 2000-х, когда разработка собственной электроники была практически недоступна рядовому пользователю, а микроконтроллеры программировались в основном только на ассемблере. Недавно я нашёл некоторую информацию о том, какой процессор вероятно использовался в таких знакомых нам приставках Brick Game, которые мы называли «Тетрисами»! Более того, мне удалось найти полный даташит с описанием всех модулей этого процессора, который гордо можно назвать «система на кристалле». Какой была разработка микроэлектроники в 90-х? Читайте в статье!

❯ Немного о «Тетрисе»

Пожалуй, Тетрис или Brick Game был одной из самых популярных портативных игровых консолей в странах СНГ. Появившись где-то в конце 90-х, этот гаджет быстро стал бестселлером среди детишек благодаря наличию сразу нескольких игр, полноценного ЖК-экрана, звука и невероятной дешевизны. Не знаю, сколько Тетрис стоил в момент выхода, но в нулевых цена на него была крайне низкой — около 100-200 рублей в зависимости от корпуса. Типичный школяр мог накопить на собственный Тетрис за несколько недель, что делало его самым доступным игровым девайсом на рынке.

Конечно же, на рынке уже были различные консоли с гораздо более богатым функционалом — например GameBoy и даже GameBoy Color с цветным дисплеем, а люди, родившиеся в конце 90-х или начале 2000-х уже застали PlayStation Portable с реально крутой 3D-графикой и телефоны с хорошим игровым потенциалом — как, например, SE K500i. Однако цена на них была непозволительной роскошью для небогатых семей: PSP стоила 250$ (около 7-8 тысяч рублей по тому курсу), плюс каждый UMD-диск с игрой стоил около 1.000 рублей, GameBoy были относительно редкими в России, а телефоны — это всё же прерогатива более юных ребят, да и в нулевых далеко не всем перепадал крутой K500i — чаще всего покупали телефон попроще типа Siemens A55 (грузчика помним?) или Motorola C350 (а мотоциклиста?). Поэтому тетрисы оставались чуть ли не единственным средством развлечения у небогатых ребят.

Ощутимым плюсом было и то, что Тетрис работал от батареек: они были не слишком дорогими в то время, а если носить с собой в кармане парочку, то можно не бояться, что консоль сядет в долгой дороге и продолжать себя забавлять, да и сам Тетрис работал довольно долго, мне хватало на неделю игры (может и меньше). Несмотря на низкое разрешением всего в 10x20 пикселей, Тетрис обладал достаточно большим монохромным дисплеем без подсветки, на котором было комфортно играть.
Ещё одним немаловажным плюсом консоли была возможность «кооперативной» игры и эдакого азарта: будучи неискушенными детьми, многие из нас пытались поставить рекорды и выбить как можно больший счёт в каждой из доступных игр. Чем больше счёт, тем ты круче среди друзей!

Но что же у Тетриса «под капотом»? На чём он работал внутри? Недавно я нашёл информацию о том, что потенциально в Тетрисе могла использоваться 4х-битная система на чипеHoltek HT1130, которая использовалась в самой разной носимой электроники: от часов на батарейках, до полноценных игровых консолей. Причём я ничуть не преувеличиваю, это действительно SoC: уже в 90-х, тайваньская компания смогла объединить звуковой модуль, контроллер ЖК-дисплея, ввод/вывод и таймер в один чип! Однако тут важно понять, что 100% сказать, на чём работал Тетрис, нельзя — процессор спрятан под компаундом и у него нет корпуса с маркировкой, лишь «голый» кристалл. Тем не менее, мы можем предположить, что это был один из чипов Holtek и посмотреть, на чём же работала портативная электроника тех лет поближе!

Заранее прошу прощения за отсутствие нормальных фотографий. Под рукой у меня не оказалось «старого» Тетриса, а на новодельных показывать как-то не очень.

На данный чипсет есть «утёкший» в сеть даташит с полным описанием регистров микроконтроллера и его ТТХ. Чип был спроектирован так, чтобы не требовать практически никакой обвязки в виде конденсаторов/резисторов и других SMD-элементов — он работал фактически напрямую от пальчиковых батареек и его легко было развести на плате даже начинающему инженеру. Микроконтроллер стабильно оперировал при напряжении от 2.4в до 3.3в, что позволяло просто вставить две последовательно соединенные AA или AAA батарейки с напряжением 1.5-1.6в и получить необходимое питание для работы всей «приставки».

❯ Вычислительное ядро

Саму систему на кристалле можно разделить на несколько соединенных модулей в один чип. Основным, конечно же, является 4х-битное вычислительное ядро неизвестной архитектуры, которое компания Holtek разработала сама или лицензировала как IP-ядро у другой компании для использования в собственном чипе (как, например, MediaTek лицензирует у ARM ядра Cortex). Система команд, по крайней мере, описание мнемоник ассемблера в даташите наводят на мысли о некоторой схожести с микроконтроллером Intel 8051 (однако 8051 был 8-битным) и в целом, напоминают типичную интеловскую архитектуру из 80х. Однако только по мнемоникам точно определить архитектуру невозможно: здесь есть «проприетарные» команды типа SOUND и TIMER.

Чип работает на частоте 1мгц от встроенного тактового генератора, большинство команд выполняется за один такт, максимум — два. Если говорить совсем грубо, то даже ATMega328 в Arduino условно в 16-раз мощнее HT1130, хотя это совсем некорректное сравнение.

Длина машинного слова HT1130 — 4 бита, что отсылает нас в начало 70х годов, если мы говорим о компьютерах. Это означает, что процессор «аппаратно» мог выполнять операции только с числами от 0 до 16, хотя при программной реализации мог пересчитывать хоть 32х-битные числа. Ширина шины данных — 12 бит, что позволяло адресовать вплоть до 4Кб встроенной ROM-памяти. Кроме того, в МК было встроено 128 ячеек оперативной памяти (или 64 байта), где в00H..7FHхранились временные данные программы (например, позиция танчиков на экране) и сE0H..FFHхранился «буфер» кадра, который определял текущую на экране. Также у микроконтроллера были следующие регистры:

1. R0-R4 — регистры общего назначения. Пары из регистров используются для адресации памяти.

2. ACC — регистр-аккумулятор, который хранит результаты текущей операции.

3. PC — указатель на текущую инструкцию в ROM, которую выполняет процессор.

4. Стековый регистр — судя по всему, «невидимая» связка регистров, которую процессор использует для хранения PC при вызове функций. Ограничен максимум двумя адресами, что не даёт возможность писать программы с вложенностью более двух функций.

С стековым регистром всё интересно получается. В отличии от привычных нам архитектур, HT1130 не хранит в этом регистре указатель на память, он сам по себе как-бы является стеком. Пример допустимого и недопустимого кода:

Выбор 4х-битного процессора очевиден — они очень недорогие в производстве и достаточно простые. Примеры использования 4х-битных архитектур можно найти даже в советских играх: например, в игре «Волк и яйца» (клоне Nintendo Game & Watch) использовалась «микроЭВМ» КБ1013ВК1-2.
В встраиваемой и переносной электронике, 4х-битные вычислительные ядра продолжают использоваться и сейчас: в калькуляторах, в пультах для управления техникой, в часах. Связано это с простой и дешевизной подобных решений, да и если честно, реализация этих устройств была готова ещё в прошлом веке. Зачем дополнительно тратить деньги на R&D существующих решений? :)

❯ Графика

HT1130 специально разрабатывался для переносимых устройств с новомодными LCD-дисплеями. В те годы было нормой, когда на дисплейной матрице не было собственного контроллера с распространенным интерфейсом по типу 8080 или MIPI: частенько, драйвер дисплея либо выделялся в отдельный чип, либо реализовывался прямо в системе на кристалле. У Brick Game был дисплей разрешением в 10x20 пикселей, причём кастомизированный — с «захардкоженными» значками и сегментными индикаторами:

Работа с дисплеем была не особо сложной: один сегмент памяти был отведен специально под эдакий «фреймбуфер» — всё, что мы записывали туда, контроллер дисплея моментально отображал на нашу ЖК-матрицу. Поскольку дисплей был одноцветным, без градаций цвета, память была организована 1 бит — 1 пиксель. Работать со всем этим было как-то так:

MOV A, 0 ; Первая часть адреса (если я не напутал endianness)

MOV R1, A

MOV A, 0b0111 ; Вторая часть адреса. Не удивляйтесь, что по факту получается 224 при 128 байт ОЗУ - часть адресного пространства была как-бы зарезервирована

MOV R0, A

MOV A, 1 ; Закрасим первый пиксель в строке

MOV [R1R0], A ; И запишем это значение в ОЗУ

Частичным доказательством того, что этот чип мог использоваться в Brick Game — это то, что компания Holtek производила готовые «игры на кристалле» — вероятно, уже запрограммированные с завода HT1130 с определенными играми:

Примечательно, что даташит на готовые игры датируются ноябрём 1998 года, в то время как даташит на HT1130 — 1999. Если у вас появился Тетрис раньше этого времени — напишите пожалуйста в комментариях!

❯ Звук

Помимо этого, чипсет имел собственный генератор звука, или как вы вероятно подумаете — «пищалку». В чип (или SDK, если честно, не особо понятно из даташита) была уже встроена звуковая библиотека — причём половину из них как раз таки для игр, что ещё раз косвенно подтверждает догадки об использовании этого чипа в «Тетрисе». Всего поддерживалось до 16 «каналов», в которых было по 3 тональности. В звуковой библиотеке содержались следующие звуки:

• Шумы

• Мелодии

• Выстрелы

• Будильники

Управлять звуковым трактом было очень просто — буквально несколькими командами на ассемблере. Команда SOUND <номер канала> выбирала один из предопределенных звуков (причем не совсем ясно, где они хранились — возможно в ROM), а команда SOUND ONE/LOOP воспроизводила его в одном из режимов — один раз или повторяющийся. SOUND OFF же выключала звук совсем. Как-то так:

play:

SOUND A

SOUND ONE

SOUND OFF

CLC ; А если нет, то снова выполняем, пока не переполнится, эта операция очищает флаг переноса

loop:

INC A ; Увеличиваем значение в аккумуляторе

JC play ; Если флаг переноса установлен, то наш "таймер" как-бы переполнился и пора снова проиграть звук

JMP loop;

Совсем немудрено, согласитесь? :)

❯ Порты ввода/вывода и кнопки

Кроме этого, HT1130 имел несколько портов ввода-вывода, которые, однако, назвать GPIO нельзя — было 12 портов для вывода, которые могли читать логический уровень (для кнопок), и 4 пина, который мог задавать логический уровень (например, управлять вибромотором или светодиодом). Настройки портов задавались с помощью флагов: можно было настроить встроенные pull-up резисторы и они могли вызывать прерывания при переходе из высокого уровня в низкий.

Выходной порт мог быть сконфигурирован под тип выхода — CMOS или NMOS. Работа с портами шла с помощью команд IN и OUT — как в x86, а обрабатывать их можно было как-то так:

loop: IN A,0b00110010 ; Загрузить в аккумулятор значение порта PM

AND A,0b0001 ; Отсекаем биты состояний других кнопок и проверяем, нажата ли первая кнопка?

JNZ A, btn_pressed ; Если в аккумуляторе не 0 (а значит кнопка нажата) - то переходим на другую метку

JMP loop ; Если нет - то проверяем по новой

btn_pressed:

SOUND 0

SOUND ONE ; Воспроизвести звук при нажатии

❯ Таймер

В чипсете есть встроенный таймер — ну его ж не просто так для часов использовали. :) Основная суть работы аппаратных таймеров заключается в том, что его тактирует какой-либо внешний тактовый генератор с определенным делителем, в нашем случае — от 1 до 6 относительно системного генератора частоты (т.е 1мгц) и с определенной частотой он делает инкремент внутреннего регистра. Как только регистр переполняется — он очищается и вызывается соответствующее прерывание в основном процессоре.

Это позволяет регулировать скорость работы таймера, а посчитать количество тиков в таком случае не особо сложно. Однако учтите, что чем выше делитель таймера (а значит и обратно-пропорционально снижается точность таймера) — тем реже вызываются прерывания и меньше «кушают» наше процессорное время!

❯ Можно ли написать свою программу для Тетриса?

К сожалению, написать какую-нибудь свою игру для этой консоли в домашних условиях невозможно — таких удобных инструментов для прошивки, как у AVR ещё не было. Holtek предлагала собственный SDK, в которое входила IDE, ассемблер и симулятор отладки финальной программы. Однако дабы получить настоящее «хардварное» устройство, необходимо было заказывать у компании Holtek производство кастомизированного чипа с вашей программой на борту.

Чипсет использовал настоящую масочную Read-Only Memory, которая прожигалась один раз и навсегда на заводе. Производитель электроники отсылал скомпилированную программу Holtek, а они в свою очередь производили кастомный чип с прошитой программой. Несмотря на всю простоту ассемблера и устройства в целом, самому под него ничего написать не получится — внешних шин то у него нет. :(

Однако, в наше время можно разработать и собрать «Тетрис» самому: в том числе, с цветным дисплеем и на базе гораздо более мощного железа! Тут тебе и готовые мощные микроконтроллеры, и возможность собрать приставку на базе легендарного процессора Z80, да при желании можно симулировать почти настоящий HT1130 на FPGA!

❯ Заключение

Разработка вычислительной и при этом недорогой электроники в 90-х было весьма веселым занятием. Несмотря на то, что устройства были на первый взгляд достаточно примитивными, в них всё равно крылось много разных нюансов, которые ограничивали программистов во многом.

Однако embedded-разработка тех лет была весьма интересной: когда полноценные игры вмещали в ПЗУ размером пару килобайт, на ремейки Space Invaders на современных движках весом в под сотню мегабайт смотришь с некоторой улыбкой. :)

Спасибо за наводку ресурсу retroscene:
Пост Legnahar, который один из первых опубликовал предположения насчет HT1130 и комментарию =A=L=X= под тем же постом.