Чисто теоретически Амур по вычислительной производительности примерно как 60 MSX’ов в кэше, или как 7 MSX’ов при постоянных кэш-промахах. Но это на 8-битных операциях, на 32-битных он в пару раз быстрее. И он должен мочь лучше, чем у меня получилось на данный момент. Надо только суметь его заставить.
Интересно, это что за консоль с 18650? У меня пока в коллекции (больше ста портативок) таких нет, но мне теперь надо! По опыту, в консолях начала 2000-х ставили аккумулятор от GBA вместе с его проприетарным разъёмом зарядки, а сейчас очень часто встречается BL-5C от Нокии. Ну и просто несъёмные пакеты, как в этой Сеге.
Тут есть важный момент, что подавляющее большинство портативок не имеет слота картриджа, а из подмножества, поддерживающего картриджи, очень малая часть работает именно с классическими полноразмерными картиджами от старых консолей. И на удивление было не так уж мало оригинальных, ни с чем не совместимых картриджей.
В общем да, места там в обрез. Но думаю, вполне можно было сделать крепление хотя бы не на сам экран, а на какую-то подложку. С другой стороны, в бюджетных планшетах тоже нередко крепят аккумуляторы прямо на экран, но там у него вроде как задник из металлической пластинки, а не из бумажки.
Пока не проверял. А откуда цифры 100/400 кГц? Что-то я их упустил, видел эти значения только для i2c контроллера. Если это реально его скорость, это будет крайне медленно. Что, кстати, может объяснить, почему настолько медленно работает бутлоадер, он же находится в EEPROM.
Да, это очень печально, потому что не получается пока полноценного самодостаточного решения. Чисто технически можно обойтись без внешней флешки, если весь код влезает в EEPROM, но его всего 8 килобайт. Было бы там ну хотя бы 32 килобайта, ещё куда ни шло, хоть какая-то альтернатива 32-ой Меге.
Микроконтроллеры - не компьютеры и не приставки. Сами по себе они не обладают никакой графикой и звуком. Они предназначены для других задач: опрашивать датчики, обрабатывать и передавать данные, обеспечивать простенькие пользовательские интерфейсы. Ради забавы динамическую графику и звук можно реализовать на них программными средствами, но эффективность этого сильно ниже, чем у аппаратных реализаций 80-х годов.
Показанное в статье - не предел возможного, а то, чего удалось добиться на данный момент. Чип относительно свежий и малоизученный, поддержка сырая. Не всё сразу.
Что особенно интересно — растровая картинка на осциллографе. Уже делали векторные версии на осциллографе и на Vectrex, векторизацией исходной анимации, и для XY осциллографа это вроде как натуральный подход. А тут вроде всё тот же растр, как у всех на обычных растровых дисплеях, но для такого устройства вывода это нетипично.
Для работы алгоритма DLSS5. Который не дорисовывает в том смысле, как дорисовывает img2img. Это принципиально иная технология, чем просто прогон финального кадра через подобие StyleGAN, как почему-то решили почти все критики.
Можно конечно сделать и трекерный вариант на сэмплах, но это будет ещё один вариант около-чиптюнового звучания. Имеет смысл, если есть много вычислительной мощи, но маловато памяти.
Есть ещё вариант пожать звук в вариацию ADPCM, это сразу в 2-4 раза меньше (4 или 2 бита на сэмпл). Распаковывается не очень долго, но напрямую из Flash гнать по DMA поток в ЦАП уже не выйдет. Будет нужна система распаковки в буфер небольшими фрагментами, а из буфера уже DMA.
Эти превью - не демонстрация DLSS5. Это просто случайные картинки, созданные разными способами, в том числе обычными img2img сетями, просто для прикола. Прикол заключается в надписи DLSS5 Off/On.
Почему все вдруг решили, что лица будут разными? Это же не какой-то генератор картинок типа img2img. DLSS5 делает ровно то же, что и предыдущие: апскейл, заполнение лакун на основе статистических данных, собранных для конкретной игры. Существенное изменение — добавили полный попиксельный пересчёт освещения, работающий аналогичным образом. Но внизу всегда есть конкретные, созданные вручную ассеты, и они никак не меняются (в показанных демках похоже, что модели персонажей не родные, а доработанные под технологию).
В данном случае в логе загрузки показывается процесс: сначала стираются все страницы размером в загружаемый скетч, потом идёт сама загрузка. Стирание тоже не очень быстрое, но сильно быстрее, чем последующая загрузка. Судя по этому, похоже, что дело не в стирании.
Да, в текущей реализации поддержки в среде Arduino сделано именно так, скетч загружается полностью. В принципе, для ESP32 с аналогичной архитектурой реализовали файловую систему (SPIFFS/LittleFS) в отдельной области Flash'а, в которую из IDE плагином можно загружать данные, и скетч их не затирает — вероятно и для Амура можно сделать что-то подобное. Тогда хотя бы можно будет один раз подождать загрузки данных, и дальше отлаживать код.
В данном проекте у меня не эмулятор AY, а нечто подобное CB2 на PET, оно сильно попроще (один канал). Но да, немало времени тратится на синтез звука.
Чисто теоретически Амур по вычислительной производительности примерно как 60 MSX’ов в кэше, или как 7 MSX’ов при постоянных кэш-промахах. Но это на 8-битных операциях, на 32-битных он в пару раз быстрее. И он должен мочь лучше, чем у меня получилось на данный момент. Надо только суметь его заставить.
Лайк хотя бы за Ивана. Немногие и нечасто вспоминают эту игру.
Ха, значит такие в коллекции у меня уже есть. Есть именно DF2000. Я и забыл, что там стоит 18650. На вид даже не скажешь, очень хорошо вписали.
Интересно, это что за консоль с 18650? У меня пока в коллекции (больше ста портативок) таких нет, но мне теперь надо! По опыту, в консолях начала 2000-х ставили аккумулятор от GBA вместе с его проприетарным разъёмом зарядки, а сейчас очень часто встречается BL-5C от Нокии. Ну и просто несъёмные пакеты, как в этой Сеге.
Тут есть важный момент, что подавляющее большинство портативок не имеет слота картриджа, а из подмножества, поддерживающего картриджи, очень малая часть работает именно с классическими полноразмерными картиджами от старых консолей. И на удивление было не так уж мало оригинальных, ни с чем не совместимых картриджей.
В общем да, места там в обрез. Но думаю, вполне можно было сделать крепление хотя бы не на сам экран, а на какую-то подложку. С другой стороны, в бюджетных планшетах тоже нередко крепят аккумуляторы прямо на экран, но там у него вроде как задник из металлической пластинки, а не из бумажки.
Да, я тоже особенно впечатлился этим моментом. Тем веселее ковыряться в таких железках, можно подивиться изобретениям сумрачных гениев.
Судя по документации, там как раз отдельный контроллер, аналогичный SPIFI, и подключаемый так же. Но деталей реализации там нет.
Пока не проверял. А откуда цифры 100/400 кГц? Что-то я их упустил, видел эти значения только для i2c контроллера. Если это реально его скорость, это будет крайне медленно. Что, кстати, может объяснить, почему настолько медленно работает бутлоадер, он же находится в EEPROM.
Да, это очень печально, потому что не получается пока полноценного самодостаточного решения. Чисто технически можно обойтись без внешней флешки, если весь код влезает в EEPROM, но его всего 8 килобайт. Было бы там ну хотя бы 32 килобайта, ещё куда ни шло, хоть какая-то альтернатива 32-ой Меге.
Похоже, пока есть только такое: https://docs.mikron.ru/wiki/development/MIkboy/MikBoy.html#_описание
Микроконтроллеры - не компьютеры и не приставки. Сами по себе они не обладают никакой графикой и звуком. Они предназначены для других задач: опрашивать датчики, обрабатывать и передавать данные, обеспечивать простенькие пользовательские интерфейсы. Ради забавы динамическую графику и звук можно реализовать на них программными средствами, но эффективность этого сильно ниже, чем у аппаратных реализаций 80-х годов.
Показанное в статье - не предел возможного, а то, чего удалось добиться на данный момент. Чип относительно свежий и малоизученный, поддержка сырая. Не всё сразу.
Что особенно интересно — растровая картинка на осциллографе. Уже делали векторные версии на осциллографе и на Vectrex, векторизацией исходной анимации, и для XY осциллографа это вроде как натуральный подход. А тут вроде всё тот же растр, как у всех на обычных растровых дисплеях, но для такого устройства вывода это нетипично.
Для работы алгоритма DLSS5. Который не дорисовывает в том смысле, как дорисовывает img2img. Это принципиально иная технология, чем просто прогон финального кадра через подобие StyleGAN, как почему-то решили почти все критики.
Можно конечно сделать и трекерный вариант на сэмплах, но это будет ещё один вариант около-чиптюнового звучания. Имеет смысл, если есть много вычислительной мощи, но маловато памяти.
Есть ещё вариант пожать звук в вариацию ADPCM, это сразу в 2-4 раза меньше (4 или 2 бита на сэмпл). Распаковывается не очень долго, но напрямую из Flash гнать по DMA поток в ЦАП уже не выйдет. Будет нужна система распаковки в буфер небольшими фрагментами, а из буфера уже DMA.
Нет такого в показанных демках. Там нет дорисовки вообще как таковой.
Эти превью - не демонстрация DLSS5. Это просто случайные картинки, созданные разными способами, в том числе обычными img2img сетями, просто для прикола. Прикол заключается в надписи DLSS5 Off/On.
Почему все вдруг решили, что лица будут разными? Это же не какой-то генератор картинок типа img2img. DLSS5 делает ровно то же, что и предыдущие: апскейл, заполнение лакун на основе статистических данных, собранных для конкретной игры. Существенное изменение — добавили полный попиксельный пересчёт освещения, работающий аналогичным образом. Но внизу всегда есть конкретные, созданные вручную ассеты, и они никак не меняются (в показанных демках похоже, что модели персонажей не родные, а доработанные под технологию).
В данном случае в логе загрузки показывается процесс: сначала стираются все страницы размером в загружаемый скетч, потом идёт сама загрузка. Стирание тоже не очень быстрое, но сильно быстрее, чем последующая загрузка. Судя по этому, похоже, что дело не в стирании.
Да, в текущей реализации поддержки в среде Arduino сделано именно так, скетч загружается полностью. В принципе, для ESP32 с аналогичной архитектурой реализовали файловую систему (SPIFFS/LittleFS) в отдельной области Flash'а, в которую из IDE плагином можно загружать данные, и скетч их не затирает — вероятно и для Амура можно сделать что-то подобное. Тогда хотя бы можно будет один раз подождать загрузки данных, и дальше отлаживать код.