А вот об эту платформу я пообломал немало зубов, и так никуда и не продвинулся. У неё большой потенциал для homebrew — как раз выросло и ударилось ностальгию поколение её обладателей, но homebrew до сих пор нет: рынок со спросом и совершенно без конкуренции.
Проблемы с homebrew две, не считая большей ресурсоёмкости разработки под такую платформу вообще. Первая — чип региональной защиты, её уже решили, сделали клон. Вторая — микрокод. Лицензия на него у крупных и очень живых компаний, поэтому просто взять упомянутые в статье варианты нельзя. Исходников от них нет, инструментария толком нет, без микрокода мощность железа просто недоступна — надо написать свой микрокод, хотя бы как-то сопоставимый по возможностям. Любители грызут этот гранит уже не первый год, только недавно дело начало сдвигаться, но по причине очень высокого порога вхождения в это дело тему двигает полтора энтузиаста, регулярно теряющие энтузиазм.
Ещё можно слить немного инсайдерской инфы и сказать, что были надежды получить лицензию на микрокод Factor 5, который даже лучше официального. Но уже не первый год воз и ныне там. Также есть проблема, как вообще что-то писать, даже если старый код будет получен — документации толком нет, всё заточено под древние SDK (дикая помесь gcc и Visual Studio), которые непонятно даже как просто установить, чтобы просто собрать написанные в них же исходники игр.
Про лицензионную политику же надо было досказать. С одной стороны, консоль лицензировалась сторонним производителям, и потому стоила дорого. Но с другой стороны, выход на платформу производителям софта обходился значительно дешевле других консолей, всего $3 за копию. Правда в итоге это привело к тому, что на не самой сильной платформе вышла куча треша от не самых сильных производителей.
Я пробовал писать под этот аппарат, ничего серьёзного. У меня сложилось впечатление, что делался он ещё до того, как возникло понимание перспективности 3D, больше под 'мультимедиа'. SDK там не предполагает работу с низким уровнем, но сам он создаёт впечатление очень проработанной системы, по крайней мере в сравнении с другими консолями контраст значительный (что несложно, у большей части предшественников вообще никакого SDK и документации, у последующих PS1 и N64 с этим также не фонтан). Железо, конечно, медленнное. Там даже два растеризатора (которые corner engine), но один по умолчанию почему-то выключен. Если включить, рендер в теории может ускориться до двух раз. Ещё запомнился трюк с ускорением доступа к данным на CD — они там могут дублироваться несколько раз в разных местах диска, время экономится за счёт позиционирования головки на ближайшую копию.
Интересный момент про PS1 в том, что платформодержатель официально поддерживал homebrew. То есть уже в 1996-97 году обычному человеку с лишними деньгами можно было купить сцепконсоль со спец-SDK, и с помощью обычного 486 писать любительские программы для PS1. Некоторые удачные разработки потом публиковались на демо-дисках, прилагавшихся к журналу Official Playstation.
На SNES и Genesis обычное DMA очень полезно. Там отдельное видео-ОЗУ ограниченного объёма, с последовательным доступом к видеопамяти через порт обмена, и доступ возможен только во время VBlank. Большая часть игр подкачивает часть графики в видео-ОЗУ 'на лету', в частности, анимацию героя (некоторые и врагов тоже), чтобы оставить побольше места для графики фона. Процессор через последовательный порт пишет в видеопамять очень медленно, DMA в разы быстрее, значит можно передать больше за кадр — около 5 КБ на SNES и 6 КБ на Genesis. И всё равно приходится изворачиваться, передавать половинками через кадр и.т.д.
На SNES побочных эффектов от DMA нет, просто замедляется выполнение кода, но это не проблема, т.к. наличие HDMA позволяет избежать игр с точными таймингами выполнения. На Genesis на время передачи тормозится Z80, а на нём любят играть сэмплы, поэтому звук очень сильно портится (выпадения с частотой 50/60 гц), характерные искажения голосов возникают во многих играх по этой причине. Не так давно придумали обход этой проблемы: буферизировать звук из ПЗУ в ОЗУ Z80 во время прохода луча по видимой части кадра, а во время VBlank играть буфер из ОЗУ. При отсутствии обращений к ПЗУ во время VBlank Z80 продолжает работать (остановка активируется только в момент обращения к ПЗУ). К сожалению, во времена расцвета платформы до этого не додумались.
Собственно 8 каналов DMA там именно для этого, для обычного DMA в видеопамять в начале кадра достаточно одного канала. И надо уточнить, что там именно списки, а не просто однократное DMA. У списка есть адрес, куда ему надо будет писать значения, формат записи (1-4 байт в разных схемах, типа два соседних адреса или два раза один и тот же), и далее в самом списке пары — сколько строк ждать и какое значение записать, следующая пара, и так до конца кадра. Таким образом всего одним списком можно сделать, например, цветовой градиент на экране, или, скажем, эффект copper bars, или искажение слоя фона по синусоиде (типа горячий воздух).
Надо отметить, что на SNES не практикуется перехват HBlank в том виде, как это делается на всех остальных консолях (по прерыванию или задержкой в коде), хотя он и возможен. Вместо этого там сделана специальная система HDMA, которая, я бы сказал, является самой главной и мощной железной фишкой платформы, и которой очень активно пользуется каждая игра — она позволяет менять значения регистров, заданных посредством восьми списков, строго в начале нужных строк. И это даже не 8 регистров за строку, в одном списке может быть до 4 записей. Поменять таким образом можно практически что угодно, хоть ABCD Mode7, хоть параметры смещения, хоть видеорежим. Списки заполняются в любой удобный момент и назначаются в начале кадра, дальше железо работает само, а процессор может спокойно заниматься другими вещами.
Насколько я помню, идея с последовательными сдвиговыми регистрами пришла с первых компьютерных видеотерминалов, у них изначально был такой дизайн, и потом уже перешли на нормальное ОЗУ (где и раскрылась сущность названия RAM — random access memory).
Я сам больше склоняюсь к объединению, чем разделению ретро-платформ, именно по соображениям необходимости ограничивать число конкурсов. Иначе будет как с музыкой, где уже давно беда, и это реально напрягает людей (сто сортов одного и того же для неискушённого слушателя, да ещё в диком разбросе жанров).
Согласен, цена тоже так себе фактор, как и год. Вероятно в итоге мы всё же придём к конкретным спискам платформ, с консультацией организаторов в непонятных случаях (прецеденты будут пополнять правила).
Непонятно, откуда такой страх перед процессором в картридже NES. Ну нет их пока, и не предвидится. Это реально сложная инженерная задача. В теории возможно, на практике никто не сделал и не пытается. И это точно не пойдёт на эмуляторе или Flash-картридже, это уже будет чистый Wild, работающий только в единственном экземпляре у автора, при удачном стечении обстоятельств.
Это несколько относится к вопросу GS/WS. GS у нас уже исторически сложившийся стандарт, 20-летней выдержки, с широкой поддержкой эмуляторами и доступностью в железе. А WS пока ещё оправдывает свое название, Wild — пока малодоступен в железе и недоступен в эмуляторах.
В теории можно что угодно прикрутить к чему угодно, например, самый быстрый процессор к любой ретро-системе. Но это вряд ли можно считать принципиальным критерием при сортировке платформ. А действительно принципиальные надо ещё как-то выработать.
Касательно объединения компо NES/ZX128. С точки зрения программиста и под ZX и под NES я могу сказать, что мне это кажется вполне себе честным. У этих двух платформ есть слабые и сильные стороны (каждая может лучше одно, но проигрывает в другом), но в целом они из одной весовой категории. В ту же категорию я бы добавил и C64, и Atari, и БК, и прочие советские 8-битные компы — там ситуация аналогична, кое-что лучше, кое-что хуже, но в целом близко. А вот Sega Genesis или SNES уже явно из следующей весовой категории, ближе к ранней Amiga и ST. Опять же, концептуально эти платформы разные, но баланс сильных и слабых сторон их вполне себе уравнивают. Я считаю, что платформы одно исторического периода вообще в целом равны, потому что им надо было конкурировать по цене, цена была близка, а за одинаковые деньги можно было получить примерно одинаковое количество технологии (скажем, коэффициента общей вычислительной мощности).
Замок укладывается в лимит спрайтов, неспроста он такой формы, с дыркой и разной ширины на разных уровнях. Подобный визуальный трюк (чтобы казалось больше, чем на самом деле) встречается и в других играх, в том числе в заставках. Помню, меня спрашивали про аналогичный случай, забыл в какой игре, возможно в другой части NG.
Вообще 64 пикселя спрайтов — это четверть ширины экрана, не так уж мало.
Robus, критика становится гораздо ценнее, когда выдвигаются альтернативные предложения. Я затрудняюсь понять, в чём твоё предложение — выбрать другие критерии деления на категории? Сделать каждой платформе и модификациям платформ по отдельному компо для максимальной честности?
Мне кажется, о конкурсе платформ речи вообще не шло. Соревнуются работы, голосуют за понравившиеся работы, а не за платформу. Можно взять X, впаять Y, и так далее, но работа будет плохая — значит проиграет. Или получится очень крутая, значит выиграет. Заслуженно.
Всё же в NES дополнительный процессор до сих пор никто ещё не впихивал. Хотя в начале 90-х Color Dreams и планировала впихнуть Z80, но это так и осталось планами.
Надо отметить, что процессор SNES работает на частоте не ровно, а до 3.58 МГц. И это одна из крупных проблем платформы (другая — страшная система спрайтов, у Genesis намного лучше). Частота автоматически переключается между 1.79, 2.58 и 3.58 МГц в зависимости от того, к чему обращается процессор (на самом деле меняется количество тактов шины для доступа, 6-8-12, мастер-клок 21 МГц). Для полной скорости в ПЗУ нужна память соответствующей скорости, и вручную включить режим 3.58 МГц. ОЗУ всегда работает только на 2.68 МГц (хотя можно замаппить его через слот картриджа в пространство ПЗУ, и оно таки заработает на 3.58 МГц, но это неприменимо в обычных картриджных играх). Все устройства в диапазоне адресов $4000-43ff (там регистры DMA, джойстика, математики) работают только на 1.78 МГц, регистры остальных устройств на 2.58 МГц.
Из всех чипов расширения я сам работал только с DSP1. Штука конечно интересная, но строго для определённого типа игр. Делался он, по всей видимости, для Pilotwings. Там есть 3D-проекция пола (типа трассы в Mario Kart), объектов, некоторая математика. Результатов вычисления надо ждать, и они не такие уж быстрые, хотя и быстрее, чем считать вручную. И неприятный момент, с DSP1 в режиме LoROM можно поставить только 1 МБ ПЗУ.
И так тоже делается, например, в Battletoads. Как правило для этого нужно ОЗУ графики тайлов. Хотя есть варианты и с ПЗУ (там лежат сдвинутые копии фона), например, Castle Master. А иногда бывает и то и другое сразу, и прокрутка графики тайлов, и перезапись смещения карты тайлов несколько раз за кадр.
Лицензированный ли? Ходит легенда, что в 2A03 BCD режим отключили (обрезанием соединения) для обхода патентов, типа чтобы можно было скопировать ядро 6502 без последствий (по японским законам).
HuC6280 — вот реально прикольный клон, в PC Engine. Маппер памяти, интересный 6-канальный звук и 7 МГц.
По мапперам я давеча начал объёмную статью, в продолжение тематических постов здесь, но она так и лежит в ожидании своего часа.
Забавно еще то как именно был реализован этот счётчик отрисованных сканлайнов — видеочип не проектировался для такого и пришлось найти изощрённый обходной путь.
К слову, у этого пути есть побочные эффекты — если расположить спрайты и тайлы в одном окне PPU (т.е. настроить PPU, чтобы он брал и тайлы и спрайты из одной страницы), прерывания перестанут работать. Ну и если выключить рендер, прерывания тоже перестанут приходить, а значит, скрывать артефакты доступа к видеопамяти во время хода луча по кадру становится сильно сложнее — гасить экран обычно хочется на неопределённое время, но для нормальной работы прерываний ниже по кадру можно гасить только на фиксированное время.
К вопросу ограничений CNROM и UNROM. Большинство дискретных мапперов (на обычной мелкой логике), включая эти два, позже подвергались расширению китайцами и фанатами. Поэтому есть варианты CNROM на 128К, UNROM на 512К и 4096К, есть подобный UROM по сути маппер на 64M (защёлкиваются биты ША, а не ШД).
Именно так, все чипы с дополнительным звуком выводили его на специальный контакт слота картриджа, и в приставке он смешивался с основным. Но это только в Famicom, в NES он не подключен, в клонах — как повезёт. Плюс ещё есть традиционная проблема баланса громкости встроенного и внешних чипов (аналогично MSX).
Речь идёт про трансляцию кода на уровне исходников с ручной доработкой, не про полностью автоматическое портирование. Такое делали и в начале 90-х любители у нас, перенося с MSX на Вектор, и в 2000-х не у нас, перенося с NES на Sega Genesis.
Проблемы с homebrew две, не считая большей ресурсоёмкости разработки под такую платформу вообще. Первая — чип региональной защиты, её уже решили, сделали клон. Вторая — микрокод. Лицензия на него у крупных и очень живых компаний, поэтому просто взять упомянутые в статье варианты нельзя. Исходников от них нет, инструментария толком нет, без микрокода мощность железа просто недоступна — надо написать свой микрокод, хотя бы как-то сопоставимый по возможностям. Любители грызут этот гранит уже не первый год, только недавно дело начало сдвигаться, но по причине очень высокого порога вхождения в это дело тему двигает полтора энтузиаста, регулярно теряющие энтузиазм.
Ещё можно слить немного инсайдерской инфы и сказать, что были надежды получить лицензию на микрокод Factor 5, который даже лучше официального. Но уже не первый год воз и ныне там. Также есть проблема, как вообще что-то писать, даже если старый код будет получен — документации толком нет, всё заточено под древние SDK (дикая помесь gcc и Visual Studio), которые непонятно даже как просто установить, чтобы просто собрать написанные в них же исходники игр.
Я пробовал писать под этот аппарат, ничего серьёзного. У меня сложилось впечатление, что делался он ещё до того, как возникло понимание перспективности 3D, больше под 'мультимедиа'. SDK там не предполагает работу с низким уровнем, но сам он создаёт впечатление очень проработанной системы, по крайней мере в сравнении с другими консолями контраст значительный (что несложно, у большей части предшественников вообще никакого SDK и документации, у последующих PS1 и N64 с этим также не фонтан). Железо, конечно, медленнное. Там даже два растеризатора (которые corner engine), но один по умолчанию почему-то выключен. Если включить, рендер в теории может ускориться до двух раз. Ещё запомнился трюк с ускорением доступа к данным на CD — они там могут дублироваться несколько раз в разных местах диска, время экономится за счёт позиционирования головки на ближайшую копию.
На SNES побочных эффектов от DMA нет, просто замедляется выполнение кода, но это не проблема, т.к. наличие HDMA позволяет избежать игр с точными таймингами выполнения. На Genesis на время передачи тормозится Z80, а на нём любят играть сэмплы, поэтому звук очень сильно портится (выпадения с частотой 50/60 гц), характерные искажения голосов возникают во многих играх по этой причине. Не так давно придумали обход этой проблемы: буферизировать звук из ПЗУ в ОЗУ Z80 во время прохода луча по видимой части кадра, а во время VBlank играть буфер из ОЗУ. При отсутствии обращений к ПЗУ во время VBlank Z80 продолжает работать (остановка активируется только в момент обращения к ПЗУ). К сожалению, во времена расцвета платформы до этого не додумались.
Согласен, цена тоже так себе фактор, как и год. Вероятно в итоге мы всё же придём к конкретным спискам платформ, с консультацией организаторов в непонятных случаях (прецеденты будут пополнять правила).
Это несколько относится к вопросу GS/WS. GS у нас уже исторически сложившийся стандарт, 20-летней выдержки, с широкой поддержкой эмуляторами и доступностью в железе. А WS пока ещё оправдывает свое название, Wild — пока малодоступен в железе и недоступен в эмуляторах.
В теории можно что угодно прикрутить к чему угодно, например, самый быстрый процессор к любой ретро-системе. Но это вряд ли можно считать принципиальным критерием при сортировке платформ. А действительно принципиальные надо ещё как-то выработать.
Касательно объединения компо NES/ZX128. С точки зрения программиста и под ZX и под NES я могу сказать, что мне это кажется вполне себе честным. У этих двух платформ есть слабые и сильные стороны (каждая может лучше одно, но проигрывает в другом), но в целом они из одной весовой категории. В ту же категорию я бы добавил и C64, и Atari, и БК, и прочие советские 8-битные компы — там ситуация аналогична, кое-что лучше, кое-что хуже, но в целом близко. А вот Sega Genesis или SNES уже явно из следующей весовой категории, ближе к ранней Amiga и ST. Опять же, концептуально эти платформы разные, но баланс сильных и слабых сторон их вполне себе уравнивают. Я считаю, что платформы одно исторического периода вообще в целом равны, потому что им надо было конкурировать по цене, цена была близка, а за одинаковые деньги можно было получить примерно одинаковое количество технологии (скажем, коэффициента общей вычислительной мощности).
Вообще 64 пикселя спрайтов — это четверть ширины экрана, не так уж мало.
Расширения можно ограничить тем же 1991 годом.
Из всех чипов расширения я сам работал только с DSP1. Штука конечно интересная, но строго для определённого типа игр. Делался он, по всей видимости, для Pilotwings. Там есть 3D-проекция пола (типа трассы в Mario Kart), объектов, некоторая математика. Результатов вычисления надо ждать, и они не такие уж быстрые, хотя и быстрее, чем считать вручную. И неприятный момент, с DSP1 в режиме LoROM можно поставить только 1 МБ ПЗУ.
HuC6280 — вот реально прикольный клон, в PC Engine. Маппер памяти, интересный 6-канальный звук и 7 МГц.
К слову, у этого пути есть побочные эффекты — если расположить спрайты и тайлы в одном окне PPU (т.е. настроить PPU, чтобы он брал и тайлы и спрайты из одной страницы), прерывания перестанут работать. Ну и если выключить рендер, прерывания тоже перестанут приходить, а значит, скрывать артефакты доступа к видеопамяти во время хода луча по кадру становится сильно сложнее — гасить экран обычно хочется на неопределённое время, но для нормальной работы прерываний ниже по кадру можно гасить только на фиксированное время.
К вопросу ограничений CNROM и UNROM. Большинство дискретных мапперов (на обычной мелкой логике), включая эти два, позже подвергались расширению китайцами и фанатами. Поэтому есть варианты CNROM на 128К, UNROM на 512К и 4096К, есть подобный UROM по сути маппер на 64M (защёлкиваются биты ША, а не ШД).