В этой статье я расскажу о микроконтроллерах Sunplus с ядром 6502 которые использовались в популярных в 90-е «тетрисах» Apollo, а также об их эмуляции. Отдельно опишу способ запуска своего кода на этих играх и в частности проигрыватель «Bad Apple!!», крупнопиксельный кадр из которого показан на КПДВ.
В общем-то и целом, мой предыдущий эмулятор ZX Spectrum, написанный на go, работал. Показывал нужное (или очень близко к нужному) и давал чувство приближенности к программистам. Однако у него были очень фундаментальные проблемы, связанные исключительно с языком разработки. Ну по крайней мере я сейчас так думаю.
Другим движущим фактором все-таки была бесплатность БЯМок от cloud.ru (не реклама, да и бесплатности больше нет). Ну где еще можно на халяву пожечь сотни миллионов токенов и получить хоть что-то работающее?
В общем, я принял волевое решение переписать все на С++. Под катом дневник "переписчика", в котором я последовательно описываю все боли и страдания начинающего писателя эмуляторов. Желающим сразу посмотреть на конечный результат можно сходить на https://github.com/kiltum/zxcpp
Помните статью про самую дешёвую консоль с Ozon — Sup GameBox? Тогда я рассказал вам о том, что у этого чуда инженерной мысли находится «под капотом» и почему эта консоль не так проста, как кажется на первый взгляд.
После статьи я решил написать письмо производителю процессора этой консоли. И что самое интересно — мне ответили! Даже Спустя 40 лет после релиза оригинальной NES, тайваньская компания V.R.T продолжает развивать архитектуру оригинальной NES. Мне больше ничего не оставалось, кроме как включить фен, достать программатор и хакнуть этот девайс...
Когда в 19-летнем возрасте я покупал свой первый компьютер, то я очень сильно хотел купить БК-0010-01. Однако обстоятельства сложились так, что к моменту, когда у меня появилась необходимая сумма, в магазинах БК‑шек не осталось, и вообще ничего не осталось. На полке в «Электронике» лежало только невзрачное нечто с нарисованной клавиатурой и названием «ЛИК».
Давным-давно, когда с ездовым котом приключилась "записка шестая", а знания об аллокаторах и опыт их применения ограничивался линейным и системным, перебросили мою команду в помощь другой команде, которая занималась системами навигации больших судов. Ездовые коты, особенно нестарые - это такие создания, которые редко изучают документацию детально, а чаще бегло читают там про интерфейсы систем в проекте, malloc, new, системные аллокаторы и думают, что теперь-то точно понятно, как всё устроено. А потом приходит работа и такая: “Забудь всё, что ты знал. Ты не дочитал до страницы восемьсот что-то там РД, тут есть свой аллокатор - и он реально плохой”.
Примерно так началось мое погружение в мир ненормального распределения памяти. Это сейчас я знаю с десяток разных аллокаторов, и специфику их работы, специфика правда больше игровая, но думаю многим будет интересно - зачем нужны все эти "танцы с аллокаторами". В той статье все аллокаторы еще более менее нормальные, но есть еще ненормальные и они оказывается тоже нужны, и в определенных сферах разработки очень даже важны и применяются.
А вот почему нужны и важны ненормальные - объяснений почти нет, как и самих реализаций в открытом доступе. В этой статье я расскажу, какие повстречал ненормальные алгоритмы распределения памяти, чем они живут, кого едят, и почему иногда malloc делает вид, что он не при делах и таки да, malloc может возвращать null и ту проверку мы убрали зря.
Тридцать лет назад, в 1995 году, мы провели первую в России и бывшем СССР demo party (или, говоря более понятным языком, компьютерный фестиваль) - ENLiGHT. С тех пор мы делали это почти ежегодно, с 1999 года по нынешнее время - под именем "Chaos Constructions". В этой статье я хочу немного рассказать о Chaos Constructions'2025, прошедшем 23 и 24 августа этого года.
Когда отлаживаешь программу, речь идет про использование отладчика в студии или другой IDE, то почти всегда имеешь дело с точками останова (breakpoint, бряками) — механизмом, когда выполнение программы приостанавливается, чтобы можно было заглянуть внутрь и понять, что происходит. Точек останова есть всего два основных типа, программные и аппаратные, а остальные все сделаны на их основе. Эти два базовых типа могут вести себя похоже, но устроены по-разному.
Программные точки останова — это то, с чем сталкивается каждый разработчик, когда вы ставите красную точку в среде разработки (в основном я использую большую студию) или используете команду bp под WinDbg. В этом случае отладчик просто подменяет один байт машинного кода в нужной инструкции на команду int 3. Это специальная инструкция для вызова прерывания отладки (Debug Interrupt), имеет машинный код 0xCC и говорит процессору: “Остановись, я хочу передать управление отладчику”, соответственно когда выполнение доходит до этой инструкции, срабатывает прерывание, и управление передаётся в отладчик. Отладчик "просыпается" и видит, что программа остановилась из-за исключения EXCEPTION_BREAKPOINT , возникшего по конкретному адресу, проверяет свой внутренний список точек останова и находит ту, которая была установлена по этому адресу.
Все вокруг стараются сделать мир лучше, пишут редакторы, используют нейросети. Скука! Я решил пойти другим путём и создал "Лабораторию Абсурда" — которая намеренно и с особым цинизмом превращает любой осмысленный текст в лингвистический бред.
Не спорю, существуют и другие генераторы бреда, но я дарю вам 50 (или что-то около того) разных способов издевательства над текстом и здравым смыслом! Никаких рекламных баннеров, только ванильный JS и словари на тысячи слов, только хардкор!
Как следует отображать на экране результат деления 3.0 на 10.0 ? Сколько цифр следует вывести, если пользователь не указал точность?
Скорее всего, вы даже не знали, что вывод на экран чисел с плавающей запятой — это сложная проблема, настолько сложная, что по ней написаны десятки научных статей, причём последний прорыв был относительно недавно, в 2016 году. На самом деле, это одна из самых сложных частей поддержки чисел с плавающей запятой в среде выполнения языка.
Давайте продолжим разговор о самой неоптимизированной в мире библиотеке эмуляции плавающей точки при помощи целочисленной арифметики.
Это вторая статья из цикла «Санпросвет о плавающей точке»:
2. Вывод чисел с плавающей точкой на экран <- вы тут
Недавно мне понадобилось сэмулировать работу с плавающей точкой только при помощи целочисленной арифметики, поскольку флоаты были недоступны. Полез я было в интернет за готовой библиотекой, и чуть не утонул. Мало того, что я не нашёл того, что искал, это бог с ним. Я обнаружил, что в интернете кто-то неправ. :)
Оказалось, что форумы кишат людьми, которые не до конца понимают, как компьютеры манипулируют числами. Например, мемасик с КПДВ я стянул с реддита (перечеркнул его я). Кто-то настолько был напуган страшными ошибками округления чисел с плавающей точкой, что даже смешную картинку смастерил. Только вот проблема в том, что 0.5 + 0.5 в точности равно 1.0.
Таким образом, я решил засучить рукава, и изобрести велосипед. То есть, написать самую неоптимизированную C++ библиотеку для эмуляции IEEE754 32-битных чисел с плавающей точкой при помощи исключительно 32-битной целочисленной арифметики. Библиотека уложится в несколько сотен строк кода, и в ней не будет никакого битхакинга. Задача написать понятный код, а не быстрый. А заодно хорошенько его документировать серией статей.
Итак, этим полукреслом мастер Гамбс начинает новую партию мебели, или статья первая: поговорим о числах и компьютерах.
Хочу поделиться своим опытом разработки крупных игровых проектов на C++, где производительность и стабильность — это не просто приятные бонусы, а абсолютно естественные требования к разработке. За годы работы над движками и играми я понял, что подход к управлению памятью очень сильно влияет на весь проект. В отличие от многих приложений - игры, особенно большие, часто работают часами без прерываний и должны поддерживать стабильный фреймрейт и отзывчивость. Когда проседание fps или фриз происходит на глазах у сотен тысяч игроков, вам уже никто не поможет — ущерб уже нанесен, а в steam полетели отзывы о кривизне рук разработчиков.
Однажды моя команда закончила работу над довольно интересным проектом, который портировали больше двух лет на плойку. Движок старый, большой и мощный, но работа с памятью была ориентирована на ПК времен конца 2000-х, и что меня поразило, так это насколько сильно большая часть кодовой базы зависела от динамической памяти во время выполнения. На ограниченном железе (далеко не у всех есть PS5 pro) и в условиях жёстких требований к сертификации на консолях такие решения быстро превращаются в проблему.
В разработке для консолей (про мобильные устройства я молчу, потому что игра не влезает по памяти даже в восемь гигов) с ограниченными ресурсами, архитектура с частыми аллокациями не просто неэффективна — она становится реальной угрозой для стабильности проекта. Каждое выделение памяти в куче влечёт за собой накладные расходы: это дополнительные !миллисекунды! (в целом на кадре) задержки, риск большой фрагментации памяти, и непредсказуемое поведение в долгой игровой сессии. После двух часов игры постоянные операции с кучей буквально «сжигают» половину бюджета кадра.
Недавно я набрёл на шедевр Патрика — клон DOOM, основанный на DuckDB-WASM и работающий в браузере. Прочитав о нём, я решил довести эту великолепную идею до логического завершения: написать многопользовательский DOOM-подобный шутер целиком на SQL. При этом всю тяжёлую работу хотел сделать через базу данных CedarDB. Отлучившись с работы в месячный отпуск по уходу за ребёнком (бессонных ночей хватало), я попытался сделать именно это.
Вот вам тизер DOOMQL:
Как повернуть время вспять и выиграть Assembly с DOS-демкой в 2025-м году.
Разбираем олдскульные эффекты на примере демки "Demoded".
Секреты, хитрости и откровенное жульничество российского демомэйкинга.
История в картинках.
Доброго времени суток, господа и дамы! Иногда у некоторых людей возникает желание заняться откровенным непотребством в программировании — то, что не несет практической пользы напрямую, но помогает развлечься. В этой статье я хочу рассказать вам о лайфхаках, трюках (магических и не очень), алгоритмах на языке C!
Идея написать эту статью зародилась из моего поста. В нем я рассказал о том, что через последовательность Фибоначчи можно конвертировать мили в километры с небольшой погрешностью. Увидев, что многим понравилась, я задумался: почему бы не изучить еще какие-нибудь трюки, заодно практикуясь в программировании на C?
Всех, кто заинтересовался — прошу под кат.
Недавно работал в команде, занимавшейся разработкой встроенного ПО. Это ПО в значительной степени основывалось на конечных автоматах, которые десятками были разбросаны по множеству функций. И хотя такая архитектура весьма распространена в разработке встраиваемых систем, в особенности систем без ОС, я задался вопросом: неужели нет способа выразить поток управления более чисто?
Конечные автоматы в нашем коде работают прекрасно, но их понимание и обслуживание зачастую вызывало головную боль. В их работе отсутствовал линейный поток, плюс они требовали мысленного жонглирования флагами, состояниями и переходами, происходящими в функциях опроса.
Меня не покидала мысль: «А не будет ли проще написать логику в виде последовательной программы, ожидающей события и возобновляющей выполнение с места остановки?»
Естественно, в проекте не допускалось использование RTOS, посему традиционный подход применения потоков или систем блокирования для управления конкурентностью не рассматривался. Но я знал, что должна быть некая золотая середина.
...которая работает на первых Android-смартфонах в мире, компьютерах из 90-х и даже Mac'ах! Часть 2.
Иногда у меня лежит душа просто взять и написать какую-нибудь небольшую игрушку с нуля, без использования готовых движков. В процессе разработки я ставлю перед собой интересные задачки: игра должна весить как можно меньше, работать на как можно большем числе платформ и использовать нетипичный для меня архитектурный паттерн. Недавно я начал писать ремейк классических «танчиков» и в рамках серии статей готов рассказать о всех деталях разработки трёхмерной игры с нуля в 2025 году. Если вам интересно узнать, как работают небольшие 3D-демки «под капотом» от написания фреймворка до разработки геймплея и тестов на экзотических устройствах — жду вас под катом!
Осторожно: в данной серии статей я рассказываю о реверс-инжиниринге и хакинге простых кнопочных звонилок. Цель простая: расширить скудный функционал телефонов ценой до 1 000 рублей и сделать их привлекательной платформой для самых разных гиков. Если вам интересно узнать, как происходит процесс взлома и изучения прошивок, а также написания новых программ для кнопочников — жду вас под катом!
