Ретрогейминг: PAL vs NTSC. Или почему PAL не нужен

Многие из вас знают про форматы видео как PAL, NTSC и, конечно же, SECAM. Скорее всего эти аббривеатуры вы слышали, когда речь шла о видеотехнике. Толком никто не знал в чем была между ними разница и почему они отличались. Что касательно видеоигровой индустрии, то тут уж точно все в курсе про региональные различия. PAL — это прежде всего про страны Европы и СНГ. И именно в этом формате скрывалась главная проблема — игры для данного региона были намного медленнее, чем для NTSC. И это были еще далеко не все проблемы.


В этой статье я собираюсь расказать о том, что выбор ретро-игр европейского региона не самый лучший вариант, ну и почему так произошло.


Для начала немного исторического экскурса, что бы вы поняли, почему вообще появились региональные различия и как это влияло на видеоигры тех времен.


image

Когда в конце 19-го начале 20-го веков разрабатывались первые коммерческие системы электроснабжения, использовалось много разных рабочих частот, и в конечном итоге некоторые части мира, такие как Европа и Австралия, установили стандартом частоту тока 50Гц с напряжением 220-240 В, в то время как как Америка и некоторые страны Азии, использовали 60Гц с напряжением 100-127 В. Выбор данных частот был обусловлен работой обычной лампочки с нитью накаливания. Потому что, начиная с частоты в 50Гц, человеческим глазом не ощущались мерцания и освещение становилось комфортным.


image

И тут мы подбираемся к самому важному моменту, потому что в первые дни существования телевизионных технологий частота обновления экрана должна была быть привязана к частоте источника питания, чтобы избежать помех. Так в Америке и Японии частота обновления экрана стала 60Гц, а система вещания NTSC, а в Европе и Австралии соответственно 50Гц с системой вещания PAL. SECAM, который был принят во Франции и СССР, так же работал с 50Гц, но рассматривать мы его не будем.


В формате PAL видео могло работать только с частотою 25 и 50 кадров в секунду, а в NTSC 30 и 60 кадров в секунду. Что касательно цветопередачи, PAL имел куда более сочные и натуральные цвета на экране, когда NTSC формат был в этом плане плоховат.


image

В основном все консоли и игры разрабатывались с учетом частоты обновления 60 Гц, потому что самыми доминантными рынками тогда были Япония и Америка. Европа на тот момент не рассматривалась как что-то очень серьезное. Поэтому оптимизация в игропроме не являлась чем-то необходимым и важным, а разработчики практически не уделяли этому внимания… Именно поэтому подавляющее большинство игр для PAL региона, примерно на 17% медленнее чем было задумано изначально:


(1 — (50/60))*100% ≈ 16.6(6)% ≈ 17%


Ну и в совсем редких случаях, разработчики следуя принципу “хотелось как лучше, а получилось, что получилось” увеличивали тайминг геймплея так сильно, что даже эти 17% замедления не спасали и выходило все ну слишком быстро.


С современными консолями и телевизорами частота обновления больше не является какой-то преградой, но мы тут все же говорим про ретрогейминг, так что частота с которой работает ваш телевизор с электронно-лучевой трубкой была очень важна. Сейчас это гораздо проще, потому что более поздние модели старых теликов могут работать как с 50/60Гц, так и с форматами PAL и NTSC.


Любителям же карманных ретро-консолей париться вообще не стоит, потому что вышеописанных проблем по понятным причинам для них попросту не существует и региональные различия весьма условны. Именно поэтому на вашем геймбое будут одинаково хорошо идти игры японского и европейского регионов.


image

К слову, разница варьируется между консолями, с которыми вы имеете или будете иметь дело. По большому счету, с PAL форматом все похуже, а большее разрешение скорее является даже минусом, потому что для компенсации всегда добавляют толстые черные бордюры сверху и снизу изображения. Этот метод известен также под названием letterboxing, эффект которого вы можете наблюдать на картинке ниже. А разность частот означает падение частоты кадров.



Вообще Европа тех времен — это совокупность множества стран с разными законодательствами, а разработчики тогда часто относились к ней как к одной большой массе с кучей различных правил и законов собранных в одну кучу. Ну так, для удобства… Например, если нужно было что-то сделать для Польши и Испании, то все запреты для каждой страны объединялись в одно целое. Что означало, что некоторые из наиболее экстремальных случаев цензуры происходили именно в этом регионе (и чаще всего, по понятным причинам, это случалось из-за Германии, хотя далеко и не всегда из-за нее), с другой стороны, некоторые факты цензуры довольно сильно варьировались, а там, где были под запретом насилие либо религиозные и сексуальные темы, то для для Северной Америки и Японии это практически не имело никаких границ и рамок. В настоящее время Европа рассматривается как нормальное единое целое с каким никаким, но относительно общим законодательством.


Есть еще такая интересная особенность, которая состоит в том, что для европейского региона консоли и игры выходили в самую последнюю очередь. Это и не плохо и не хорошо. Почему? Потому что в некоторых случаях вышедшая намного позже игра получала исправленные баги и была более стабильная в работе, а так же туда мог быть добавлен дополнительный контент, что согласитесь — весьма приятно. Но так же, могло быть много чего и вырезано из-за цензуры, либо просто заменено, что делало конечный продукт весьма отличным от оригинала. Например, взять игру для Super Nintendo как Contra III: The Alien Wars, в которой из-за цензуры все человеческие персонажи были заменены на роботов, а называться она стала Super Probotector: Alien Rebels.



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


Еще отдельно стоит сказать про формат PAL60, который как вы поняли, выдавал изображение с такой же частотой как и NTSC формат, но к большому сожалению он появился к концу эры консолей 5го поколения. Но если уж говорить об играх, то Metroid Prime 2 отличный тому пример.


Если говорить о консолях, то, например, Sega Mega Drive европейского региона, сравнительно довольно ужасна в этом плане, если учитывать, что игры для этой платформы были очень динамичные и быстрые. Практически все они получают леттербоксинг, и, понятное дело, работают с частотой 50 Гц, что делает их весьма неуклюжими.



Худший пример, который я могу назвать, это Sonic 1. В более поздних играх этой серии музыка была оптимизирована для работы с 50 Гц, поэтому там она уже на слух не такая отвратительная, но в Sonic 1 все реально ужасно, когда ты понимаешь как все должно быть на самом деле.


Собственно, для остальных ретро-консолей, как вы понимаете, все то же не так и радужно.



Есть еще отдельный вид спорта как модификация консолей, благодаря чему можно выдаваемые 50Гц увеличить до 60Гц, тем самым насильно заставляя их работать в режиме "типа NTSC" позволяя играть в игры данного региона, но это не всегда является панацеей, потому что некоторые игры все равно будут работать некорректно или совсем никак, да и это веселое занятие потребует от вас скилла работы с паяльником. Забавный факт еще будет заключаться в том, что после моддинга — 60гц не будут настоящими. Почему? Потому что итоговая рабочая частота будет составлять примерно 59.3Гц, хотя на глаз вы это даже и не заметите. А все из-за кварцевого резонатора, несущая частота которого рассчитана для PAL региона.


На самом деле это правило относится вообще ко всем ретро-консолям любого региона если вы захотите их сделать монстрами Франкенштейна, которые бы выдавали чистые 50Гц и 60Гц. Возни с резонатором вам просто не избежать, потому что тут умения работы с паяльником будет мало, и придется мало-мальски шарить в схемотехнике и в других мелочах.


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


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


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


Поделиться публикацией

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 86

    +1
    «PAL — это прежде всего про страны Европы и СНГ» странно, почему я всегда считал что на просторах необъятной вещание шло в формате SECAM?
      +1
      Тоже удивило, потом понял, что речь про времена консолей. Секама на них уже не было в принципе
        0
        Почему же не было, было, но редко, в основном на самых ранних приставках в версии для Франции. Их делали по самому остаточному принципу, это как PAL, но с совершенно кривой палитрой. И была даже версия Dendy Classic SECAM, самые первые поставки. Потом пошли PAL.
          0
          У меня, кстати, есть Классик СЕКАМ — взял для RGB-мода, да руки не дошли, так вот, изображение с него ужасное — бледные цвета и дикое «мыло». Все же в связке UM6558-UM6559 декодер SECAM предельно упрощенный.
            0
            У меня тоже был такой, правда не в 90-х. Так и есть, у всех нечастых приставок-компьютеров с SECAM-кодером (всякие местные Спектрумо-клоны) изображение просто ужасное, потому что нормальный кодер сильно сложно-дорого сделать.
        +1
        Так и было до недавнего времени. У SECAM лучше приём в условиях помех, насколько я помню, поэтому для нашей необъятной она довольно удобна. Но у каждой системы есть свои специфические искажения и недостатки.
          +1
          Все правильно был SECAM, но у ретро-консолей был только PAL для данного региона. И подавляющее число жителей СНГ тех времен ставили в телеки декодеры «SECAM в PAL», на чем, в свое время, очень сильно наварились теле-мастера.
            +3
            Не «SECAM в PAL» а наоборот, «PAL в SECAM», ставили из-за кино на видеокассетах в PAL.
            Ну и «cильно наварились» это преувеличение, я помню те времена.
              0

              Ну, если быть совсем точным, то ЕМНИП у декодера PAL на выходе были цветоразностные сигналы, а иногда и своя матрица RGB. То есть речь не идёт о перекодировке, в ней и смысла то нету.

                0
                Да, верно, так и было.
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              Яркостную составляющую все системы передают одинаково, т.к. совместимость с черно-белыми телевизорами не имеющими никаких декодеров было одно из условий при их разработке.
              • НЛО прилетело и опубликовало эту надпись здесь
            0
            Именно поэтому подавляющее большинство игр для PAL региона, примерно на 17% медленнее чем было задумано изначально:


            Вот этот момент нифига не очевиден. Развёртка там черезстрочная, но, обычно, консоли/микрокомпьютеры не страдали выдачей разных полукадров и дублировали один и тот же полукадр два раза. Привязываться к началу обновления экрана консолям было не нужно, но можно. В таком случае, действительно, частота обновления задаёт скорость работы программы. Но можно ведь и не привязываться — это дело видеоконтроллера не допускать сбоев картинки при изменении видеопамяти.
              +7

              Игры на консолях того времени состояли из хаков чуть менее, чем полностью, поскольку аппаратная часть в них просто-напросто не поддерживала такой уровень графики. Всякие хитрые приёмы требовали активной работы процессора во время отрисовки кадра (всякой буферизации ведь тоже не было — память была жутко дорогая), соответственно все геймплейные расчёты приходилось успевать выполнять во время обратного хода луча. Программная часть была выверена до последнего такта. Вот пример из Legend of Zelda.

                +1
                Я тут подумал, и решил, что всё гораздо проще было. Был один кварц на всё, а частота экрана получалась его делением. И вот это кварц просто был разный для PAL и NTSC. Вот и всё.
                  0

                  Само собой, что тактовая частота отличалась. Например, у NES в NTSC-варианте частота процессора была 1,79 МГц, а у PAL-версии — 1,66 МГц. Однако, если бы железо позволяло, то программистам не нужно было привязываться к тактам. Просто считали бы анимации по таймерам и ренедерили в secondary-буфер, как это делается в современных играх, которые работают с одинаковой скоростью игрового мира на самых разных процессорах.

                    0
                    Однако, если бы железо позволяло, то программистам не нужно было привязываться к тактам.


                    Они привязывались не к тактам, они привязывались к прерыванию. А вот это уже прерывание привязывалось к основному кварцу.
                      +1
                      Привязываются к тактам всюду и ещё как. Без точнейшей привязки к тактам нельзя написать ни одной игры на 2600, и едва ли получится сделать что-то на NES.
                        0
                        Интересно, как вы это делаете, если инструкции процессора имеют разное время выполнение и там масса переходов? Что же, программа во всех подпрограммах выровнена nop до одинакового числа тактов при любых ветвлениях? ;) Кто вам рассказал про это? Никогда никто по тактам программы не выравнивал, всегда используют что-то типа halt и ждут прерывания.
                          +3
                          Знаете — это даже не смешно. Напоминает изумление моей малолетней племянницы эпизодом из трёх мушкетёров, где они отбирают разрешение для отплытия из Франции у Миледи: «но как так может быть — на документе разве фотки не было?».

                          Никогда никто по тактам программы не выравнивал, всегда используют что-то типа halt и ждут прерывания.
                          И как вы это предлагаете сделать на 6507, где для удешевления #IRQ и #NMI из корпуса не выведены?

                          Да и в Apple IIGS у 65C816 есть режим, когда переход через границу страницы генерирует лишний такт — думаете его ввели, потому что у них транзисторный бюджет слишком большой был?

                          Да, считают такты по всем веткам, вставляют задержки если нужно. Никакой программы без набора команд 6502 с растактовкой вы для 2600 не сделаете — ну никак. Такое железо. Почему, как вы думаете, Pitfall! считается таким прорывом? Да потому что никто и представить себе не мог, что на платформе без видеопамяти и прерываний можно сделать такое!
                            0
                            Это я просто не обратил внимание на 2600. Число и число. Ну так и написали бы atari 2600. Да, в столь ранних приставках выравнивали, это действительно так, поскольку видеопамяти фактически нет. Но в консолях 80-х такого уже не было.
                              +3
                              Но в консолях 80-х такого уже не было.
                              Было-было, ещё как было. Не во всей программе, как под 2600, но в отдельных процедурах. На Хабре даже есть перевод серии статей, где объяснялось как именно эти игры издевались над железом.

                              Многие эффекты там невозможны без подгонки всех операций по тактам — просто скорости железа не хватает всё на прерываниям делать.
                                –1
                                но в отдельных процедурах.


                                Тут, вообще говоря, речь-то не об отдельных процедурах. В отдельных процедурах и milticolor делали на ZX. Но это не стандартный режим работы аппаратуры (потому и не работает на любом клоне zx).
                                  +3

                                  Топовые игры на NES все поголовно работают в нестандартном режиме аппаратуры. Например, все эффекты параллакса (https://habr.com/ru/post/354774/) фактически требуют, чтобы процессор успевал переключать координаты в PPU в процессе отрисовки кадра. Само собой, что луч идёт по каждой строке буквально микросекунды, а потому в коде расчёта смещения обязательно следует заложить точное потактовое время выполнения, чтобы успеть к отрисовке строки. Выровнять тайминги ветвлений — отдельное искусство, в крайнем случае, это можно сделать с помощью NOP.

                                    0
                                    Обратите внимание, о чём, собственно, разговор.
                                    Дано: Частота работы игры определяется стандартом PAL или NTSC.
                                    Появилось утверждение, что цикл игры просто выровнен по тактам под видеосигнал. На это утверждение я ответил, что никто так не делает и есть прерывание задающее начало игрового цикла и, скорее всего, получающееся делением основного генератора (которые разные в PAL и NTSC версиях). И вот по этому прерыванию уже выровнена игра. Замечу, что этот ответ никоим образом нет отменяет выравнивание по тактам внутри игрового цикла отдельных процедур, в том числе, задающих операции с графическим процессором. Но сама игра работает с привязкой к частоте кадров не потому, что за один игровой цикл выполняет одинаковое количество тактов.
                              0
                              кстати о миледи… а пол в документе отражен не был?
                                0
                                Там даже не было написано сколько человек с ней ехало. Дикие времена, дикие нравы…

                                В те времена границ, похожих на сегодняшние, в общем-то не было. Так что запрет касался кораблей. И разрешение его обойти тоже было на корабль. А если вы на корабле в эпоху парусников, путь даже и всего лишь через Ла-Манш, в одиночку поплывёте… можете ведь и не доплыть…
                                  0
                                  ну видимо да.
                                  учитывая как была написана «бумага кардинала» — ничего удивительного что тут так же универсально.
                            +1
                            Ну 2600 это отдельная статья: как вы без привязки к тактам вообще хоть что-то изобразите на железке без прерываний (на 6507 для удешевления отсутствуют входы #IRQ и #NMI) и без видеобуффера (там памяти только под одну экранную строку)?

                            Гораздо веселее привязка к тактам на PlayStation 2: там скорость такая, что это всё не так-то просто воспроизвести даже на современном железе, процессоров много (не SMP, они все разные), а синхронизации в большинстве игр нету, всё выверено по тактам…
                              0
                              а синхронизации в большинстве игр нету, всё выверено по тактам…


                              На PS2? Где такое написано? Вы это сами видели или просто кто-то где-то сказал?
                                0
                                Можете с разработчиками PCSX2 поговорить. Там у них куча настроек на эту тему. Вплоть до того, что у них есть отдельный «специально для Final Fantasy X» без которого в ней текстуры «рассыпаются».
                                  0
                                  Так это опять про отдельные процедуры, или «а синхронизации в большинстве игр нету, всё выверено по тактам…»?
                                    +2
                                    Тут я боюсь мы будем долго спорить на тему что такое «всё».

                                    Все процедуры, которые что-то делают на нескольких процессорах — просчитаны по тактам, никакой синхронизации внутри них нету в большинстве игр. Но, конечно вся игра в целом — нет. Там обычно довольно много кода, работающего только на основном процессоре. Его уже незачем в тактах считать… всё-таки почти 300MHz…
                                      0
                                      Все процедуры, которые что-то делают на нескольких процессорах — просчитаны по тактам,


                                      Разве её процессор Emotion Engine не использует параллельное выполнение инструкций? Он же суперскалярный. Сдаётся мне, что такого не может быть в конце XX века, а это значит, что есть возможность создания барьера, пусть даже на уровне процессора.
                                        0
                                        Он же суперскалярный.
                                        Суперскаляр — да, но спекуляций там нет.

                                        есть возможность создания барьера, пусть даже на уровне процессора.
                                        Инструкции там есть, но ими не пользуются. Так как если вы не просчитаете всё в тактах, то синхронизация приведёт к тормозам, а если просчитаете — то нафиг она нужна?
                                          0
                                          Суперскаляр — да, но спекуляций там нет.


                                          Так речь и не про спекулятивное выполнение. Просто если процессор выполняет несколько инструкций одновременно, то в чём тогда выравнивание по тактам (тоже синхронизация) процессоров, если на них запущен разный код? А если запущен одинаковый код, тогда это простое распараллеливание однотипных действий и совсем не интересно с точки зрения растактовки игры, так как синхронизацией по тактам процессоров не является.
                                            +1
                                            А если запущен одинаковый код
                                            Как вы собрались запускать там одинаковый код если это процессоры разную архитектуру имеют?

                                            У вас просто в голове, похоже, немножко смешалось. Русская Wiki, как обычно, всё «опускает для ясности», но в Английской — всё чётко: The Emotion Engine consists of eight separate «units», each performing a specific task, integrated onto the same die. These units are: a CPU core, two Vector Processing Units (VPU), a 10-channel DMA unit, a memory controller, and an Image Processing Unit (IPU).

                                            Как я сказал — это ни разу не SMP. CPU, VPU0 и VPU1 — это три разных процессора. Ну примерно как 8086 и 8087. И чтобы они не «разъезжались» есть способы их синхронизовать (что-то типа fwait в 8086).

                                            Только вот игры этим почти не пользовались — просто рассчитывалось всё так, чтобы VPU выдавали результат ровно тогда, когда он нужен в CPU.

                                            И писать это и эмулировать это всё — жуткий гемор…
                                              0
                                              Только вот игры этим почти не пользовались — просто рассчитывалось всё так, чтобы VPU выдавали результат ровно тогда, когда он нужен в CPU.


                                              Так вот в этом варианте как раз хрень и получается. Если процессоры умеют выполнять несколько инструкций одновременно, как синхронизировать по тактам? Вы же не знаете, сколько тактов займёт выполнение программы — суммированием тактов на команду это число не получится. Нет, это можно выяснить для конкретной ревизии чипа, но, боюсь, очень трудоёмко. Вот что более реально, так это создать барьер и на этом закончить извращения.
                                                0
                                                Вот что более реально, так это создать барьер и на этом закончить извращения.
                                                И, тем не менее, во многих играх барьера нет…

                                                Нет, это можно выяснить для конкретной ревизии чипа, но, боюсь, очень трудоёмко.
                                                Не так сложно, как кажется. Для процессоров класса Pentium или R5900 всё вполне считается: там может исполняться либо одна комнда за такт, либо две, причём ограничения это всё фиксированны.

                                                А если чуток промахнулись — можно всегда пару Nop'ов добавить. Железка то — вот она…

                                                Барьеры же — гораздо медленее, они и сейчас дорогие, а на «старых» процессорах они чуть не весь pipeline с нуля перезапускали…
                        0
                        В PAL/NTSC версиях приставок часто помимо кварца отличается много чего ещё. В той же NES делители другие, и в итоге на такт пиксельклока в NTSC приходится нецелое количество тактов процессора (ужасно усложняет жизнь, озвереть можно как), а в PAL целое. В PAL также сделали период обратного хода луча аж втрое дольше, что конечно очень хорошо, но если это применить, адаптация такой игры PAL>NTSC сильно усложняется.
                          0
                          ужасно усложняет жизнь, озвереть можно как


                          Чем? У вас PPU в NES живёт своей жизнью и сам выдаёт спрайты и всю остальную муру.
                            0
                            Усложняет сплит скролл, например. Он даже в первом SMB есть. Железо NES проектировалось ориентировочно в 1981 году и не предполагало никаких сложных игр. То, для чего оно делалось — простые одноэкранные аркады типа Donkey Kong. Все более сложные игры, пошедшие с 1985 года, результат выжимания всех соков и использования множество трюков, и всё это завязано на точное знание устройства CPU/PPU и их точной потактовой синхронизации.
                              0
                              Все более сложные игры, пошедшие с 1985 года, результат выжимания всех соков и использования множество трюков, и всё это завязано на точное знание устройства CPU/PPU и их точной потактовой синхронизации.


                              Пример такой точной потактовой синхронизации у вас есть?
                                0
                                К вопросу об усложнении жизни, написано на днях. У вас было столько приставок и компьютеров, я думаю, вы разберётесь, что это такое, зачем оно нужно, и как работает без подсказок.

                                Заголовок спойлера
                                ;------------------------------------------------------------------------------

                                irq_line_sy_init:

                                lda #<_split_list
                                sta <IRQ_SPLIT_LIST+0
                                lda #>_split_list
                                sta <IRQ_SPLIT_LIST+1

                                rts



                                irq_line_sy_m:
                                ;6 for jsr

                                lda #39 ;2
                                jsr timing_delay ;25+39

                                ldx #0 ;2
                                lda (IRQ_SPLIT_LIST),y ;5+
                                iny ;2
                                stx PPU_ADDR ;4
                                sta PPU_SCROLL ;4
                                stx PPU_SCROLL ;4
                                and #$f8 ;2
                                asl a ;2
                                asl a ;2
                                sta PPU_ADDR ;4 this write should be done on the hblank
                                rts ;6=109 including jsr



                                irq_line_sy:

                                sta MMC3_IRQ_DISABLE

                                pha
                                txa
                                pha
                                tya
                                pha

                                lda #69 ;2
                                jsr timing_delay ;25+69

                                ldy #0

                                _irq_loff_0:

                                ;NTSC 113.6 CPU clocks per line
                                ;to make up the .6 to an integer, lines needs to have slightly shifted timings in groups of ten
                                ;five lines is 568 cycles exactly, but there is still a slight shift

                                jsr irq_line_sy_m ;109 0
                                nop ;2
                                lda <0 ;3
                                jsr irq_line_sy_m ;109 114
                                nop ;2
                                nop ;2
                                jsr irq_line_sy_m ;109 227
                                nop ;2
                                lda <0 ;3
                                jsr irq_line_sy_m ;109 341
                                nop ;2
                                nop ;3
                                jsr irq_line_sy_m ;109 454
                                nop ;2
                                lda <0 ;3

                                jsr irq_line_sy_m ;109 0
                                nop ;2
                                lda <0 ;3
                                jsr irq_line_sy_m ;109 114
                                nop ;2
                                nop ;2
                                jsr irq_line_sy_m ;109 227
                                nop ;2
                                lda <0 ;3
                                jsr irq_line_sy_m ;109 341
                                nop ;2
                                nop ;3
                                jsr irq_line_sy_m ;109 454

                                cpy #220 ;2 height of the raster
                                bcc _irq_loff_0 ;2/3

                                lda #0
                                sta PPU_MASK

                                pla
                                tay
                                pla
                                tax
                                pla


                                rti

                                  +1
                                  Может мне тоже кинуть кусок какого-нибудь дампа хрен знает чего и посоветовать «как-то так. разбирайтесь»? Идея-то в чём?
                                    +2
                                    Идея в том, что вы просили пример точной потактовой синхронизации CPU/PPU, и вы его получили. Объяснить на пальцах, как работает? Услуга платная.
                                      0
                                      Золотые слова! Занесу в копилку. ;)
                                    +1
                                    > nop ;2
                                    > nop ;3

                                    Хм, не опечатка? Я после школы 6502 не мучал, но трёхтактного nopʼа не помню :/
                                      0
                                      Спасибо за внимание! Да, конечно, опечатка, довольно частая у меня в подобных местах. Как раз подгонялись тайминги 'на живую', заменялись lda zp на nop и обратно, что поиграть ± такт, а комментарии после этого не поправил. К слову, в итоге этот код был переделан до неузнаваемости, теперь там табличка тактовой задержки для каждой отдельной строки.
                                    0

                                    Точная потактовая могла быть. Но вот вышеозвученный сплит-скролл делался довольно просто и без потактовой синхронизации — в NES есть регистр-счетчик, декрементирующийся каждую строку растра, и генерирующий прерывание при обнулении.

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

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

                                      В любом случае после срабатывания флага или прерывания надо очень точным таймингом загнать нужную запись обновления регистров скролла в hblank, иначе будут артефакты. Регистры скролла только кажутся простыми (адрес и X/Y смещение), на самом деле там очень хитроумная логика, требующая планирования порядка записей — какая запись перезапишет какой внутренний счётчик, какие биты проигнорируются. И она была известна разработчикам ещё в 1985, используется в SMB, если эту логику не эмулировать, скролл не будет работать.

                                      Прерывание по строке есть только в некоторых жирных мапперах, в частности MMC3. Но оно реализовано через аппаратный хак, с кучей ограничений. Нужно, чтобы был включён рендер. Нужно, чтобы тайлы спрайтов и фона были в разных банках PPU (включая режим 8x16). Нужно, что в конфигурации не было CHR RAM. Разные версии маппера имеют свои особенности, типа диапазона возможных строк. Прерывание приходит ближе к началу строки, когда записи уже делать поздно, и нужно программной задержкой ждать следующую строку — таким образом нельзя сделать обновление по прерыванию каждую строку, только через одну. Ну и другие приятные мелочи.

                                      И не стоит забывать про джиттер. Во-первых, всегда есть джиттер на 4 такта, а процессор не отличается быстротой — легко промахнуться мимо hblank. Но есть хитрые способы отсинхронизироваться и удерживать стабильное смещение тактов от начала кадра. Также DPCM — если он используется в игре, каждый раз, когда происходит выборка байта, процессор тормозится, и вся синхронизация кадра уплывает. Типичное проявление — графические артефакты в такт ударным.
                          0
                          Не все так просто, если вспомнить эпоху VHS, то там на 4% скорость отличались. И было очень заметно на слух, что тональность голоса немного другая. Ну и вообще в телевидении это было впринципе, когда пытались сигнал показать через иную систему вещания.
                            0
                            Честно говоря, не вижу связи консоли и скорости вращения барабана в видеомагнитофоне, которая соответствовала частоте кадров.
                              0
                              Мои пардоны, DVD и тому подобное.
                            0
                            Развёртка там черезстрочная, но, обычно, консоли/микрокомпьютеры не страдали выдачей разных полукадров и дублировали один и тот же полукадр два раза.
                            Попробуйте включить в любом эмуляторе frameskip=1 и «насладиться» игрой на 30 к/с.
                            Думаете, зря на ютубе при выкладывании геймплея cо старых консолей особо указывают — «60 fps»?
                              0
                              А зачем мне это пробовать?
                                0
                                Чтобы наглядно увидеть, что вы заблуждаетесь.
                                  0
                                  В чём я заблуждаюсь? В черезстрочной развёртке? Ну извините, так телевизор устроен. Что там в SNES не знаю, но NES, Spectrum, Amiga фигачат два одинаковых полукадра.
                                    0
                                    На этих приставках в основных режимах черезстрочная развёртка не используется, каждый полукадр идёт как самостоятельный кадр половинного разрешения. Содержание каждого полукадра отличается, оно не одинаковое. Т.е. приставки показывают 50/60 разных картинок в секунду.

                                    То, что не используется сдвиг полукадра (т.е. честная черезстрочность, полукадр не на том же месте геометрически) — отчасти правда. Т.е. если пытаться взять и вывести картинку полного разрешения, выводя её в соседних полукадрах, она на многих подобных системах будет смотреться неправильно, как простое мерцание — если, конечно, не используется режим высокого разрешения (при наличии).
                                      +2
                                      На консолях и ПК, подключаемых к телевизору, не используется сдвиг полукадров. Фактически, полукадрами это называть вообще некорректно — телевизор просто работает, как монитор с разрешением 256×224(240).
                                        –2
                                        каждый полукадр идёт как самостоятельный кадр половинного разрешения.


                                        Нет. Там обычное дублирование. Полукадры совершенно одинаковы.

                                        Т.е. приставки показывают 50/60 разных картинок в секунду.


                                        25/30 и не более.
                                          0
                                          Это такой IT троллинг, я понял. Спасибо, прекращаю тратить время.
                                            0
                                            Странно, но я так же решил про вас. Уж больно не совпадает с тем, что я вижу на реальном железе (у меня есть и денди, и спектрум, и амига и я в своё время возился с их видеокадрами).
                                            Может быть, вы только с эмуляторами знакомы? Там может быть как угодно, не спорю. Но реальные системы просто дублируют поля и всё.
                                          0
                                          >>каждый полукадр идёт как самостоятельный кадр половинного разрешения.

                                          Кстати, Amiga 500 даже не утруждает себя формированием указания на чётный полукадр. Я был очень удивлён, как телевизор Витязь воспринял такой сигнал — он его выводил строго как верхнюю половину экрана, так как решил что это режим без интерлейсинга и ожидал продолжения картинки, а Amiga забила хоть на какие-то различия полукадров. Впрочем, там можно настроить в workbench нужный видеорежим.

                                          Выглядит вот так:
                                          image
                                            0
                                            Amiga по многим характеристикам куда ближе к тому железу, которое вы можете купить в магазинах сегодня, чем к 2600 или NES, вы уж извините.
                                              0
                                              А год-то разработки какой? ;)
                                              На скринах в статье нифига не atari 2600 и даже не NES, кстати.
                                                0
                                                А год-то разработки какой? ;)
                                                Какая разница какой там год разработки? Многие вещи, которые есть уже в самой первой версии Amiga в приставки и PC пришли ближе к XXI веку. Она очень сильно опережала своё время. Так что Amiga — это не очень показатель. Хотя подобрать для неё «правильный» Dell 2001FP было той ещё задачей…
                                                  0
                                                  Она, конечно, вся на ускорителях, но PC её догнали не к XXI веку точно. Скорее, к середине 90-х (за исключением режима переменной плотности пикселей в части экрана). Тем не менее, даже она со своими ускорителями выводит картинку изначально ровно как два одинаковых полукадра. Хотя, конечно, у неё широкие возможности программирования видеорежимов.
                                                    0
                                                    за исключением режима переменной плотности пикселей в части экрана
                                                    Это как раз одна из редких вещей, выдающих её возраст. Такие вещи как раз в 80е были распространены. Apple IIGS тоже так умеет (отсюда, кстати, шестицветное Apple лого: вот как раз его в меню Apple IIGS изобразить было можно… а если бы цвета не были именно горизонтальными полосками — то ничего бы не получилось).
                                  0
                                  Все консоли и почти все домашние компьютеры тех лет выдают только полукадры (отсюда разрешение 240/224 по высоте), и никакие кадры не дублируются. Все игры на консолях тех лет и большая часть игр на компьютерах типа ZX Spectrum привязываются к началу кадра. Почти на всех консолях до 32-битной эры доступ к видеопамяти возможен только во время обратного хода луча или принудительного гашения экрана (иначе либо сбои картинки при изменении видеопамяти, или — редко — задержка обращения до конца кадра), а попасть в обратный ход без привязки к началу экрана никак нельзя. Как правило в начале кадра всюду генерируется прерывание. А других таймеров в тех системах как правило нет, поэтому все действия привязаны именно к частоте кадров, и как правило с самых первых приставок до 32-битного поколения старались обеспечить полную полукадровую частоту обновления, 50/60 герц. Игры с медленной перерисовкой в основном встречались на компьютерах, где не было железа, чтобы обеспечить такую скорость, зато был более свободный доступ к видеопамяти (ZX-подобные).
                                    +1
                                    Насколько я помню, в спектрумах доступ к видеопамяти возможен всегда. Скорость работы памяти вполне себе позволяла разносить такты запросов от видео-контроллера и процессора. Причем, запросы видео-контроллера еще и служили в качестве циклов необходимой регенерации DRAM (так как все равно проходили весь необходимый диапазон строк).
                                      0
                                      Про это я упомянул в конце сообщения. Да, у ZX доступ к видеопамяти возможен всегда, что позволяет делать более детализированную, хотя и существенно медленную графику. Т.е. можно выводить сколько угодно спрайтов, делать 3D рендер, и так далее.

                                      Но там своя интересная специфика: ОЗУ делится на два поля, 16 и 32 килобайта, физически находящиеся в двух разных банках DRAM (т.е. там аж 16 микросхем памяти). Первое общее с видеобуфером, процессор при выборке байта видеоконтроллером тормозится (причём непосредственно через тактовый вход, не WAIT), поэтому в нижней памяти возникает очень сложный паттерн тактов. Также есть аппаратный баг, это торможение не срабатывает при некоторых условиях, в частности при размещении таблицы векторов прерывания в нижней памяти — тогда на экране возникает так называемый 'снег'. Второе поле памяти без торможения, весь критичный к таймингам код (биперная музыка, бордюрные эффекты, мультиколор) может работать только там. В ZX Spectrum 16K второго поля просто нет (не установлены микросхемы ОЗУ), соответственно все перечисленные эффекты там невозможны.

                                      В поздних советских клонах схемотехника и элементная база сильно отличаются от оригинала, конфликт доступа к ОЗУ решён иначе, и в них уже одно общее поле памяти без тормозов.
                                    0
                                    Можно не привязываться. Но тогда у Марио ноги будут впереди головы бежать. Что бы кадры получались цельными, нужно все изменения проводить только между кдрами.
                                    0
                                    старые аналоговые pal, ntsc, secam (во Франции негативный)…
                                    50 герц, 60 герц…
                                    про особенности тактирования и вывода сигнала сказали…

                                    Кстати, а почему в играх ntsc где сигнал на тв должен идти в формате (приблизительно, тк формат аналоговый) 480i, размер кадра по высоте больше, чем в pal с размером кадра 576i ?

                                    А всё статью, ИМХО, можно свести к тому что: игры европейского региона калеченые от рождения, если играть, а не коллекционировать — берите американку.
                                      0
                                      Кстати, а почему в играх ntsc где сигнал на тв должен идти в формате (приблизительно, тк формат аналоговый) 480i, размер кадра по высоте больше, чем в pal с размером кадра 576i ?
                                      Не понял вопроса. Если вы на телевизоре, где физически 576 строк отрисуете их только 480 — то как раз и получите чёрные поля сверху и снизу…
                                      0
                                      Самая большая проблема с поддержкой PAL/NTSC в том, что это в принципе не решаемо без значительных компромиссов. Допустим, мы задизайнили игру, где персонажи бегают с кратными частоте развёртке пиксельными скоростями — в простейшем случае каждое обновление герой или экран смещается на один пиксель (или раз в два кадра, или в три). Всё выглядит довольно плавно и красиво. Не важно, для какой из систем это было сделано изначально.

                                      Теперь нам нужна поддержка другой системы, и нужно сохранить те же скорости движения, то есть откорректировать их на 17%. Мало того, что для одного варианта было достаточно целых чисел, а теперь нужна fixed point арифметика, что сильно медленнее (на старых приставках даже сдвиги дорогие), но мы никак не сможем сохранить плавность — появятся либо пропущенные перемещения за обновления, либо двойные, идущие определённым паттерном. И неважно, делать ли такую коррекцию на уровне отдельных объектов, или на уровне обновления всего экрана (т.е. дублировать каждый 6-ой кадр изначально-PAL игры на NTSC, или наоборот, делать два обновления каждый 5-ый кадр изначально-NTSC игры на PAL), плавность при прежних таймингах уже никак не получить.

                                      По совокупности этих причин — сложно сделать, результат всегда плохой — в большей части случаев разработчики забивали на сохранение абсолютных таймингов, сохраняя относительные, т.е. не делали ничего, и игра просто шла на 17% медленнее/быстрее, но так же плавно и с точно таким же геймплеем.
                                        +2
                                        Думаю для многих бывших игроков Dendy ещё будет интересно узнать что Dendy не была по таймингам ни PAL приставкой ни NTSC.
                                        ru.wikipedia.org/wiki/Dendy#Технические_характеристики
                                          +1
                                          PAL нужен — в нем разрешение больше (768*576 против 640*480). И если игра действительно PAL, а не NTSC втиснутый в PAL, то в ней нет никаких черных бордюрчиков.
                                            0
                                            К сожаленю, таких игр очень мало.
                                            0
                                            Могу добавить, что проблемы с PAL/NTSC сохранялись вплоть до времен Playstation 2. Во-первых, в PAL большее количество строк, но откуда их брать? Далеко не все разработчики заморачивались «честным» повышением разрешения, и просто ставили бордюры — черные полосы сверху и снизу экрана. Есть и в той же Final Fantasy X, и ещё в просто куче игр.
                                            Во-вторых, скорость игры. Не знаю как, но косячили разработчики и в этом. Есть хорошо известные игры, в PAL-версии которых играть просто невозможно из-за «тормознутости». Например, Devil May Cry.
                                            В-третьих, цензура, да. Причём этот пункт сохраняется и для PS3 и для PS4 и думаю будет актуален всегда. Как правило, PAL-версии сильнее зацензурены, но есть очень-очень редкие исключения.
                                            Playstaion 1 тоже имела все те же проблемы, к которым добавлялась ещё одна, важная для определенного «круга пользователей»: только PAL-версии игр имели хитрые защиты от пиратства, так называемые анти-модчипы. Иногда они просто не давали запускать игру, иногда включались после первого уровня, а иногда действовали совсем подло и создавали какой-то специфический баг, не позволяющий дойти игру до конца, нередко активировавшийся после десятка часов игры и заставлявший игрока бесцельно переигрывать по несколько раз (хорошо известный пример — одна из частей Spyro). Причём некоторые защиты были настолько лютыми, что баги, создаваемые ими, затрагивали и честных, лицензионных пользователей, так что в отдельных случаях игры потом переиздавали уже без защит (опять ту же Spyro). В NTSC версиях ничего подобного не существовало.

                                            Из преимуществ PAL можно отметить, что так как европейские версии почти всегда выпускались позже американских, то PAL-релиз (если он был) зачастую содержал исправление некоторых багов и даже иногда получал дополнительный контент. Американские версии получали это позже только с перевыпуском или допечаткой игры. Но, в принципе, консольные игры тогда и так были хорошо отлаженными (ещё бы, диски-то не пропатчишь), так что особо критичные баги встречались не так часто.

                                            И ещё забавный факт: PAL-версии фильмов на DVD были короче NTSC на 1/24.
                                              0
                                              В формате PAL видео могло работать только с частотою 25 и 50 кадров в секунду

                                              Способ кодирования цветового сигнала не зависит от частоты кадров. Например в Бразилии частота сетевого напряжения 60Гц и соответственно число полей в секунду 60, но система цветного телевидения — PAL.
                                                0
                                                Cкорее PAL60. Но к частоте тока привязка была везде. Да и вообще в Бразилии своя атмосфера до сих пор.
                                                –3
                                                Я бы не стал доверить мнению по теме «РЕТРО ГЕЙМИНГ», чуваку с татухой рукава, серьгами во всяких местах и разговочиком в стиле «пацик со двора». Блин откуда эти эксперты берутся?

                                                Все равно что искать огрехи между «свежим» и «грушевым», для всего свои цели.
                                                Если человек изначально говорит, что ему не нужен PAL то о какой экспертности может идти речь? Это никак не относится к слову «Ретро», мы играли, как могли, на чем могли и всегда получали от этого удовольствие.

                                                Это все равно что, доказывать, что в былые времена играть в баскетбол волейбольным мечем было плохо!
                                                  0

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

                                                    0
                                                    А у меня была NTSC'шная 3DO и советский телик, поэтому помимо декодера PAL (установленного еще во времена Денди) требовалась дополнительная коробочка-конвертор, купленная вместе с приставкой. А еще адаптер для конвертора (на вилку), т.к. у него вилка была с плоскими штырьками :)

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                  Самое читаемое