Как сделать игру на nes
Создание инструментов для исследования NES-игр
Я решил продолжить серию публикаций про внутреннее устройство NES-игр, на этот раз я расскажу об используемых мной инструментах для исследований.
Большая часть того, что необходимо исследователю, уже есть в эмуляторе FCEUX, который хорошо подходит для отладки игр. В документации стоит досконально изучить раздел Debug, каждый инструмент оттуда полезен исследователю, причём умение использовать их совместно друг с другом усиливает возможности хакера.
Однако я не буду пересказывать документацию, а остановлюсь на случаях, когда возможностей эмулятора оказывается мало и необходимо добавить новые, либо же когда существуют необычные способы найти желаемое в ROM-файле напрямую, в обход длительного изучения кода игр.
Использование Lua-скриптов
Собственно, первый способ, пример которого приведён на картинке для привлечения внимания – создание вспомогательных инструментов с помощью встроенного в эмулятор интерпретатора Lua-скрипт.
На примере выше для исследования игры (и просто читерского прохождения, при желании) используется такая возможность скриптов, как вывод изображений на экран поверх отрисовываемой эмулятором картинки.
Таким образом исследователь может заметить то, что недоступно обычному игроку, например, на скриншоте выше из трёх скрытых бриллиантов игрок может допрыгнуть только до первых двух, и никаким образом не может взять третий или даже просто догадаться об его существовании. В «Утиных историях 2» встречаются даже такие драгоценности, которые вообще размещены за пределами игрового уровня.
Другой пример скрипта с выводом на экран дополнительных данных – компас до ближайшего драгоценного камня в «Книге Джунглей»:
Естественно, визуализация информации из оперативной памяти или ROM игры не единственная возможность скриптов.
Другая часто используемая возможность – логгирование происходящего в коде игры, например, шаблон скрипта для дампа разархивированных данных сразу после их распаковки (для SMD игр, но принцип применим и для NES).
Ну, и никто не запрещает создание на Lua-скриптах полноценных утилит, вроде уже включённого в эмулятор редактора нажатых клавиш TasEditor.
Также, на мой взгляд, недооцененной является идея частичного переписывания кода игры на скриптах, когда игровые данные патчатся скриптом на лету для модификации геймплея. Proof-of-concept такого скрипта, модифицирующего врагов в «New Ghostbusters 2»:
Однако, для сложной обработки конкретной игры или создания новых методов хака стоит задуматься об использовании следующего метода.
Модификация исходного кода эмулятора
Здесь есть где разгуляться фантазии на разные темы, не касающиеся исследования игр, вроде добавления в эмуляторы поддержки достижений, 3d-рендера или улучшенной графики, однако я попытаюсь удержаться в рамках темы статьи.
Одно из направлений расширения эмулятора с целью улучшения возможностей для реверс-инженерии – прокидывание как можно большего числа его внутренних возможностей в Lua-библиотеки. Во второй статье цикла я уже показывал, как с помощью прокидывания всего пары новых функций появилась возможность сделать универсальный (подходящий для исследования любой игры) инструмент для исследования.
Другой простой и полезный пример, который пока ещё отсутствует в последней версии эмулятора – возможность модификации из скрипта памяти PPU.
Модификация эмулятора может также использоваться для того, чтобы встроить в него редактор для конкретной игры с возможностью на лету запустить её и проверить внесённые изменения:
Скрипты для статического анализа кода игры
Предыдущие две категории модификаций касались динамического анализа игры в ходе её выполнения. Однако большая часть исследования – это статический анализ ROM-файла игры (или дампов каких-либо данных из него).
Основной программой для такого анализа кода является интерактивный дизассемблер IDA. Он поддерживает ассемблер 6502, однако требует как плагина для правильной загрузки файлов в формате nes, так и набора скриптов для автоматизации рутинных действий по преобразованию загруженного файла в причёсанный код. Набор скриптов, специфичных для исследования NES-игр собран тут.
Сами скрипты для IDA могут быть написаны на встроенном языке команд idc или python, в любом случае лучше всего открыть их текстовым редактором и изучить, в большинстве случаев это помогает лучше понять команды самого IDA, которые пригодятся в работе с ним и научиться писать такие скрипты самому. Это очень пригодится, когда понадобится провести несколько сотен однотипных действий, вроде объединения байт в поинтеры или выделения массивов по некоторым правилам.
Инструменты для статического анализа данных игры
IDA хороший инструмент для анализа кода, настолько хороший, что некоторые гуру исследования игр даже считают, что только его достаточно для исследования и изменения игр. Однако, даже имея на руках разобранную до компилируемых и прокомментированных исходников игру, сложно модифицировать игровые данные – уровни, графические карты, анимации персонажей. К сожалению, формат игровых данных часто сильно отличается от игры к игре, поэтому создать универсальные инструменты, подходящие для большинства игр, достаточно трудно.
Редакторы тайловых карт
Формат хранения графических банков (самый низкий уровень хранения графики) стандартный для всех игр NES, поэтому существует множество редакторов тайловых карт, однако, среди них я не нашёл ни одной библиотеки, которая позволяла бы рендерить эти тайлы в своём приложении.
Такими программами можно редактировать тайлы графики в играх с наличием CHR-ROM – целыми банками графики. В других играх используется CHR-RAM – видеопамять тайлов в них считывается частями из банка с данными и кодом и копируется в видеопамять (при этом иногда достаточно хитрыми способами, но о них скорее лучше рассказывать в статье о компрессии данных).
На более высоком уровне игры отличаются уже настолько, что общих программ для редактирования практически нет, максимум существуют редакторы, охватывающие несколько игр на одном движке. Про свои попытки сделать универсальный редактор уровней я напишу в конце статьи, пока же приведу ещё несколько общих идей, как находить данные в играх, и утилит, реализующих эти идеи.
В качестве языка реализации я использую python за то, что на нём можно быстро и просто проверить какую-либо догадку, иногда даже прямо в интерактивном режиме.
Коррапт ROM
Собственно, как раз про эту идею была вторая статья цикла – если перебрать все возможные варианты изменения одного байта в ROM и посмотреть, как это отразится на экране, то это может помочь прояснить внутреннюю структуру игры. После этого возможно даже составить простой вариант редактора игры – нужно заготовить набор картинок-блоков верхнего уровня, из которых строится экран, не вникая до конца, как строятся сами эти картинки из данных ROM и отобразить массив этих картинок, обнаруженный этим методом.
Поиск блоков
Можно также зайти с другой стороны.
Фон, который отображается на экране, задаётся массивом индексов тайлов видеопамяти по фиксированному адресу PPU – для NES существует 4 экранные страницы, которые в зависимости от настроек PPU могут разными способами выводится на экран. Не важно, что именно будет на экране, достаточно просто захватить какую-нибудь загруженную страницу для анализа.
Здесь же можно сделать дамп всей видеопамяти, который пригодится нам для анализа (File → Dump to File → PPU Memory).
Это просто массив из 960 индексов маленьких тайлов видеопамяти размером 8×8 пикселей. При этом, после реверса большого числа игр известно, что игровые экраны часто описываются блоками большего размера, например, 16×16 или 32×32 пикселей. Таким образом, если мы предположим некоторый размер блока (для начала попробуем самые стандартные – 2×2 тайла, выделены на скриншоте красной рамкой), то мы можем разбить данные из экранной страницы на участки, в каждом из которых окажется описание одного блока.
Так получается список из всех блоков, которые присутствуют на экране. Причём у нас «чистые» описания блоков, без информации о спрайтах персонажей (спрайты рисуются другим способом), и независимый от анимации (анимации фона практически всегда делаются с помощью изменений палитры либо самой видеопамяти, номера тайлов в Name Table остаются неизменными). Однако мы не знаем номера блоков.
У нас есть описание блоков на экране, но мы не знаем их порядок хранения в ROM. Тем не менее, мы можем с некоторой вероятностью предположить, где именно расположено описание блоков. Алгоритм для этого такой:
1. Проходим по всему ROM и размечаем все адреса, по которым обнаруживается какой-нибудь блок, при этом сохраняем его номер (настоящий номер может быть другой, нам важно отметить только отличия блоков друг от друга).
2. Находим область в ROM, в которой обнаружено наибольшее количество РАЗНЫХ блоков. С наибольшей вероятностью именно это и есть описание блоков.
Таким образом, мы можем найти блоки размером 2×2 в играх, в которых они хранятся последовательно.
Это уже неплохо, но есть способ кардинально улучшить результаты работы алгоритма. Дело в том, что существует ограниченное количество основных размеров блоков и способов их хранения в ROM, и мы можем перебрать их все.
Основные размеры блоков: 2×2, 4×2, 2×4 и 4×4, но в случае необходимости легко добавить и другие размеры.
Со способом хранения их в ROM немного хитрее, блоки могут храниться как линейно, так и разбитыми на части массивами (Structure of Arrays, сокращенно SoA ), т.е. сначала в ROM хранится массив только первых частей блоков, за ним — массивы со следующими частями. Чаще всего такие массивы хранятся друг за другом, при этом промежуток между началами массивов равен количеству блоков. Чтобы найти в ROM такие SoA-массивы, мы должны узнать их длину, что можно сделать перебором всех вариантов (частенько в играх используется по 256 блоков, так что начинать проверку стоит с этого числа и постепенно его уменьшать).
Всё это выглядит достаточно запутанно, ведь мы опираемся только на вероятность того, что игра использует определённый вид блоков, но на практике утилита находит блоки в 80-90% проверенных игр!
Вдобавок, она позволяет отсеять игры с необычной структурой (неблочной), чтобы пристальнее их изучить.
Сравнение CDL-файлов
Эмулятор FCEUX умеет в ходе эмуляции каждую инструкцию отмечать, какие байты были интерпретированы как код, а какие – как данные (меню Debug → Code/Data Logger. ). Эта фича полезна сама по себе и тесно интегрирована с другими отладочными возможностями эмулятора – попробуйте включить этот режим и посмотреть, как изменились другие отладочные окна. Однако, я хочу рассказать об её одном частном применении. Если сохранить два таких cdl-файла, один ДО совершения изучаемого действия, а другой сразу же ПОСЛЕ его окончания, то разница между двумя такими файлами покажет только те данные (или код), которые были использованы во время совершения действия. При грамотном отсечении можно найти нужные данные, всего лишь правильно выбрав два момента времени между измеряемыми событиями.
Формат файла достаточно прост, как и скрипт сравнения, но пользы он может принести очень много, на нём вообще можно построить отдельную методологию отладки.
Компрессоры/Декомпрессоры
Эту тему невозможно раскрыть в паре абзацев, да и она будет слишком упрощённой в контексте только NES-игр, поэтому она заслуживает отдельной статьи.
Универсальный редактор уровней CadEditor
Собственно, изначально эта программа создавалась для отображения уровней в игре «Chip & Dale» (Chip And Dale Editor), дальше по просьбам она была переделана в редактор и со временем обрастали поддержкой других игр Capcom («Darkwing Duck», «Duck Tales 1-2», «Tale Spin», «Little Mermaid»).
Позже выяснилось также, что принципы блочного построения уровней в этих играх очень похожи на способы организации уровней из многих других игр, однако дьявол кроется в деталях – мелкие отличия в каждой игре требуют описывать внутренние структуры редактора максимально гибко, чтобы с помощью комбинаций этих структур можно было описать формат уровней для игр, для которых он изначально не предназначался, без изменения ядра самого редактора.
Фича, с помощью которой обеспечивается универсальность редактора – так называемые конфиги игр. Это скриптовые файлы на языке C#, в которых описано, как именно загружать данные конкретной игры. Почему именно C#? Редактор уже был написан на этом языке и это позволило легко переносить код из ядра в конфиги, не меняя его, что пришлось бы делать, если бы использовался более классический скриптовый язык, вроде Lua.
Использование полноценного языка вместо простого файла настроек позволяет описывать в конфигах свои функции загрузки и сохранения данных любой требуемой сложности. Скрипты представляют собой обычные текстовые файлы, что позволяет пользователям в случае необходимости создавать свой конфиги без перекомпиляции редактора, используя уже существующие конфиги в качестве шаблонов. В комплекте с редактором идут около 500 конфигов для 60 разных игр, около 100 из них сделаны пользователями редактора без моего участия, для игр, в некоторые из которых я даже никогда не играл:
Однако в данный момент, несмотря на попытки сделать универсальный редактор, обнаруживаются игры, которые невозможно описать без модификации самого редактора (тем не менее, множество игр уже можно добавить и так). Чтобы собирать информацию о таких играх с необычной структурой, я пошёл ещё немного дальше и начал использовать сам редактор как библиотеку для Python, чтобы исследовать формат игр перед добавлением их в редактор и тестировать правильность понимания построения уровня конкретной игры. Я реализовал это в виде блокнотов Jupyter, из-за того, что в них удобно как писать код в интерактивном режиме, так документировать его.
Составление из базовых тайлов больших игровых структур и сборка в итоге целого уровня напоминает сборку пазла из тысяч кусочков, и доставляет такое же удовольствие, когда, наконец, каждый кусочек оказывается на своём месте.
В следующей статье не будет такого обилия технической информации и я приведу примеры сборки уровней игр с нестандартной структурой или использованием необычных модификаций стандартной блочной архитектуры. Также вы можете в комментариях назвать игру на NES, формат уровней которой интересен вам, возможно, я исследую и её тоже.
Как сделать игру на nes
Kaillera server:
gs.emu-land.net:27888
Mednafen server:
gs.emu-land.net:4046
Консоли > NES / Famicom / Dendy > История / Описание
Консоли > NES / Famicom / Dendy > История / Описание
Как сделать карманную денди
Глава Nintendo Хироши Ямочо хотел создать приставку, которая превзойдёт все имевшиеся на тот момент консоли. Эта задача была поручена Масаяки Уемура который был должен создать 16-битную машину с дисководом и при этом она должна была стоить не более 75$. К сожалению это осуществлено не было так как цена была бы тогда крайне дорога и поэтому консоль стала 8-битной, а дисковод был выпущен позже.
Famicom был выпущен в Японии в июле 1983 года по цене 100$. Первые игры вышедшие на Famicom были всем нам ныне известные: Donkey Kong, Donkey Kong Jr и Popeye. К концу 1993 года были выпущены улучшенные версии Donkey Kong Jr и Popeye с возможностью игры вдвоём. Также в это время выходит Baseball и главный хит от Nintendo, Mario Bros.
В первый год выпуска Nintendo столкнулась с рядом проблем такими как: невысокая надёжность приставки с многочисленными просчётами и дефектами. Ямочо не хотел чтобы у покупателей сложилось плохое мнение о приставке и поэтому дефектные приставки были отозваны и продажи новых прекращены до устранения неполадок. Позже Famicom был перевыпущен с обновлённой материнской платой.
В 1984 году Nintendo решила завоёвывать рынок в США. Nintendo попросила заняться продвижением на американском рынке своей консоли фирму ATARI, но был получен отказ в связи с тем что ATARI продвигала свою систему. И тогда Nintendo наняла фирму Worlds of Wonder для дистрибьюции своей консоли в США.
Приставка была выпущена на рынок США в июне 1985 в самый неудачный за весь период истории видеоигр момент. В момент краха индустрии видеоигр. Приставка позиционировалась как система развлечений от Nintendo. Продавцы относились к новой приставке с крайним скептицизмом, Nintendo пришлось гарантировать, что они выкупят все непроданные экземпляры приставок и картриджей в случае плохой продажи в магазинах и только на таких условиях она появилась в американских магазинах.
Сама консоль для США также была переделана чтобы как можно меньше походить на игрушку и поэтому она обладает таким внушительным дизайном.
Первая партия консолей появилась в Нью-Йорке и была распродана на удивление быстро, а этого было ни много ни мало 100.000 консолей.
Будучи одной из немногих консолей выживших после краха 1985 года с успешными играми, немудрено что она перешила и более технически совершенные приставки вышедшие позднее такие как: Sega Master System и ATARI 7800. Famicom и NES позже были перепроектированы как AV Famicom и New NES c целью хоть ещё немного выжать из уже устаревающей консоли перед выходом Super Nintendo.
Поскольку NES жила на протяжении огромного количества времени игры под неё постоянно совершенствовались и улучшались, поэтому игры раз от раза становились всё лучше. В итоге за всё время существования консоли было продано порядка 50 миллионов экземпляров самой приставки и 350 миллионов картриджей к ней.
Безусловно что NES одна из самых успешных консолей когда либо появлявшихся в мире.
Техничекие характеристики NES/Famicom
На самом деле как ПЕРЕДЕЛАТЬ фамикомовский картридж, ну да пофиг. Да-да, название специально такое залупил, чтобы все желающие ввязаться в эту срань знали хотя бы как происходит сам процесс. Все претензии пишите в комментарии, а то я эту тягомотину второй раз пересматривать не вынесу просто, лол. P.S. Если кому-то интересно, в следующий раз могу рассказать про то как я делал Гиммика, хех.
Edyard Filippov: Он такой же дешёвый как и твоя ж**а
Unusual Studio: Зачем «Nintendo» изменила распиновку?
как делали игры на dendy
Что бы было сложнее подделать. «Nintendo» активней всех других компаний боролась с пиратством.
Vadim Massachusetts: красава
John Batista: шикарно разбираешься в микросхемах, красавчик)
Alekse Ma: перемычки лучше кидать волоском от многожильного провода под корпусом микрухи до массовой запайки контактов. ТТЛьщик)
Zloi: Очень уважаю таких людей. Однако в данном случае искренне не понимаю зачем тратить столько времени и сил «ради антуража», когда можно накачать эмуляторов и играть во что угодно. Начиная с игр ZX Spectrum и заканчивая SonyPlaystation 2. Возможно, таким вот рукоблудием можно заняться, чтобы потом продавать картриджи по 100 баксов?)))
TheRomixERR: А что делать, если в оригинале есть Nintendo CIC чип? А я хочу слепить картридж с нуля?
ReedMy Flash: Всё прекрасно! А как другие игры заливать?
T O R G O W E E K: а мне нравится этот волшебный дымок, я кайфую ))
Василий Dan Star. Звезда восходящего солнца.: А можно ли мой картридж на денди переделать он у меня на микросхемах четырёх игровка.
Сергей Василич: Очень хорошо, когда есть увлечение. Особенно, когда оно требует мозгов. Во-первых, когда при деле, не забухаешь, к тому же подобное хобби всегда можно обратить в денежку.
format 13: Пояльничек,губочка,отверточка,температурка,фоточка…ты что,няшный пидорочек?
Руслан Рябуха: Добрый день.Очень хорошее видео.Я только начал постигать науку создания катриджей для Дэнди и Сеги.Честно скажу,я полный профан в программировании,пайке плат,микросхемах,но очень загорелся целью постигнуть эту науку.Очень помогло твой видео.Просмотрел раз пять)У меня назрел вопрос.Если есть возможность,помоги.Какие программаторы сейчас можно купить чтоб прошивать чипы для Дэнди и Сеги?.Да,я понимаю,что чипов огромное количесто,как и программаторов,но может есть универсальные,охватывающие большой спектр чипов?Может есть какой-то ресурс или статья в которой это рассказывается.Я сам пытался разобраться,но полностью утоп в этой огромной куче программаторов((И еще вопрос.На одном из сайтов,попал на группу по продаже кариков.Автор-nikita600.Случаем не ты?)
Алексей Радугов: Видео крутое, ничего не понял, ибо не умею паять, но молодец, для меня это магия
Алексей Радугов: На заказ смастеришь катридж? Прям от души будет и чё по ценам сразу, надо просто игрушек 10 на катридж запилить определенных, сам паять не умею, не возьмусь портить) покупать… 250 минимум руб 1 катридж, да не факт, что рабочий… Дорого если честно, хотя на крайняк придется рисковать. Ну а так подумай, может договоримся о катридже, если чё данные ВК дам
Kishvarsho Pallaev: Ты красавчик! Мне бы так научится. Куй с этой терминологией
Секреты Windows Обход вирусов: как праильно паять с канифолью? просто у нас не продают флюса… припаял как богг черепаху. Навыка в пайке 0.0 научите и подскажите. Чинил наушники. припаял ппц как стрёмно… паял в перый раз в жизни с помощью канифоли. Но починил. Но хочу научиться паять чисто
Александр Ровний: Эта робота плюс инструменты и детали стоят своих денег
Clever Fog: Сейчас есть специальная губка для впитывания излишков олова, если я не ошибаюсь. Приятно осознавать что кто-то всё ещё возится с Денди. 8)
Video on this topic
 |
 |
 |  |  |  |
| Основные положения Итак.. Вы решили создать игру вашей мечты. Вы собираетесь переплюнуть х3 и даже Элиту. Ну что ж.. Вы не знаете языков программирования. Вы не знакомы с gamedev`ом. Учтите — к вам никто не присоединиться, пока не будет хоть какого-то графического движка или финансирования. В общем случае выход таков — учите языки программирования и графические API, будь то OpenGL или DirectX. До первой игры вам предстоит довольно много пройти. Какой же выбрать язык программирования? Существуют мнения, что качественную программу (игру в частности) можно написать только на Си. Этот миф зародился еще в те времена, когда альтернативе Си не было… К сожалению, этого мнения придерживаются и работодатели – учтите это! На самом деле и Делфи и Бейсик (последних версий – где это уже самостоятельный язык программирования, а не интерпретатор) пригодны к написанию игр. Да, если написать тестовую, консольную программу, которая будет в цикле делать что-то математическое, то скорость будет самой большой у Си… Но, например, Делфи – самый быстрый в ООП программировании, причем, намного быстрее Си. Еще возможно быть лидером и организовать финансирование (скорее из своего кармана, т.к. издатели не пойдут на такой риск — давать деньги фирме без имени… ну или условия будут абсолютно неприемлемые). Вы знаете какой-либо язык программирования. Но не знакомы с особенностями создания игр и работы с графикой. Не важно, какой опыт у вас есть в программировании. Вы не знаете, как создавать игры – значит, вы не знаете основного. Т.е. если вы опытный программист не думайте, что сможете сразу написать игру. Как сделать картридж для Dendy?Я не могу вам объяснить, КАК написать игру – нет универсального способа. Программирование это творчество. Вот основные положения и советы: — Игра состоит из графического, физического, звукового движков (они могут быть слиты в одну целую структуру). И игровой движок, который использует эти движки, при чем они не знают об игре ничего. Т.е. игр может быть много – движок один. — Грубо говоря, движок это менеджер объектов такого плана – источник света, геометрия, система частиц, источник звука, материал и т.п. Он общаться с графическим API (DirectX, OpenGL) – будь то непосредственно с ним или через какой-либо интерфейс (если создается движок, который не зависит от графического API, например, с целью переделать его на игровые приставки). — Игра предоставляет игроку возможность влиять на объекты движка. Игра – менеджер объектов типа (это пример — ведь тут много чего может быть) корабль, планета, станция, ракета. Игровые объекты уже имеют связи с объектами в движке. На самом деле существует огромное количество вариантов архитектуры игр – я привел один из многих. Делайте движок как можно более универсальным, но не забывайте о его специализации – если он строго для космосимов, то не нужно добавлять в него поддержку чего-то абсолютно стороннего. Обязательно попробуйте написать свой движок – это даст вам огромный опыт. — Не делайте лишнюю работу. Например, если у вас есть поддержка конверта из графического пакета Mesh`ей, то не пишите расчетчик нормалей – ведь за вас это сделает графический пакет. Да, можно взять и готовые движки – но всё равно большинство пунктов, которые я перечислил выше, относятся и к готовым движкам. Ведь еще нужно написать игровой движок… Ах да, ну и на последок — не увлекайтесь сидением на профильных форумах (кроме ЕГи ессно) — там обитают одни флудеры — настоящие профессионалы просто работают и помогают новичкам, но никогда не будут обсуждать, например, на каком языке программирования писать. | |||
 |  |  | |
| Дизайн Elite Games V5 beta.18 EGM Elite Games Manager v5.17 02.05.2010 |
|
Famicon — под таким именем Dendy была известна в Японии. Появилась на рынке в 1983 году, а затем, переименованная в NES, вышла в США и Европе. Приставка сразу же стала хитом продаж и сумела завоевать неслыханную популярность на американском и японском рынках. Самыми популярными играми в то время для приставки были игры из серии Super Mario Bros (даже сейчас этот приставочный «сериал» пользуется огромным успехом). «Лицом» компании Nintendo стал Марио — главный герой. По официальным данным было продано более 60млн приставок и игр более чем 500 млн.
Выходу консоли многие критики приписывают возрождение рынка игровой индустрии в связи с компьютерным кризисом на рынке компьютерных игр. Все это связано конечно с тем что было выпущено огромное количество разнообразных игр, которые, конечно, вызвали неподдельный интерес как у инвесторов, так и у потребителей. В начале 90-х годов Денди начала сдавать позиции, отступая перед натиском шестнадцатибитных приставок. SegaMega Drive — основной конкурент Денди в то время. Следующим ударом для консоли стало появление такой мощной игровой системы как SuperNintendo (SNES/Super Famicom). Но, несмотря на это выпуск консоли продолжался и в 1992 году.
Нинтендо выпустила новую партию Денди.
Создание самодельных аксессуаров для Dendy
Это было связано с приходом в негодность более старых версий. С 1993-го года NES появилась и в России, причем это была нелегально произведенная система из Китая. Её распространением занималась фирма Steepler. Прекращение выпуска приставок официально было заявлено на 1995 год. Однако, благодаря компьютерным эмуляторам вся библиотека Денди доступна пользователям и сейчас.