Pull to refresh

Comments 30

Я знал, что там всё надо было по тактам синхронизировать — но сейчас передо мной разверзлась бездна ада :-D Я даже не представлял, что именно и с чем именно при этом надо было синхронизировать по тактам.

Интересно, можно ли было в картридже сделать ОЗУ вместе с ПЗУ и каким-нибудь грязным хаком (переходом на волшебный адрес?) менять его содержимое.

Или переключать страницы ПЗУ, выходя за пределы адресного пространства. Хотя бы в теории.

Нет того ада, который нельзя дополнительно подогреть.

Да, и дополнительное ПЗУ, и ОЗУ на картридже сделать можно, и это было сделано в ряде поздних игр. Переключались именно подобным хаком.

На поздних - потому что позже ОЗУ подешевело.

UFO just landed and posted this here

А если не только сделать на картридже ОЗУ, но и программу написать такую, которая будет некоторую его часть в качестве видео-ОЗУ на полный кадр использовать? И иногда эту программу очень кратковременно прерывать для внесения туда изменений.

Вас случайно не 10 задачка этого года Advent of Code на статью вдохновила? :)

Просто нашли хороший материал. На AoC посмотрим, спасибо за наводку! :)

пользовательский чип - скорее специализированный (custom)

Сейчас существует такое кросс-средство:

https://github.com/batari-Basic/batari-Basic

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

Есть ещё https://8bitworkshop.com/, очень удобная браузерная среда для первых шагов в ассемблере, batariBasic, и не только, для 2600 и для других платформ.

Интересно, а существовали ли подобные кросс-средства, когда Atati 2600 был современным?

Подобных конечно не было, но разработка для приставок всегда была кросс. По свидетельству Джеда Марголина, который работал в компании в те годы, в самом начале софт для систем Atari разрабатывали на бумаге и на PDP-11/20: программа писалась на бумаге, специальные люди её набирали, компилировали, и выдавали список ошибок или перфоленту с результатом. Джед сохранил внутреннюю электронную переписку компании за 1982-1992 годы, там можно узнать много чего интересного.

А те кросс-средства помогали в той или иной степени автоматизировать "гонку за лучом" и прочее?

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

"Тонкое управление горизонтальным положением включает запись в регистр TIA под названием HMOVE, и его использование приводит к одному из самых печально известных графических недостатков Atari 2600: неравномерным чёрным линиям в левой части экрана, которые закрывают часть игрового поля. Часто этот эффект называют гребёнкой HMOVE"

Это ещё что, в первой модели Game Boy определённые манипуляции с регистрами или ещё чем-то подобным приводили в физическому повреждению одной из микросхем, возможно, сквозным током через транзисторы КМОП-элемента. Компания Nintendo даже инструкцию рассылала программистам о том, что именно нельзя делать. В Atati 2600 такого, надеюсь, не было?

Во всех 8-битных ч/б моделях Game Boy (оригинал, Pocket, Super GB) нельзя использовать инкремент регистровых пар, если в них содержится значение $fe00..$feff - это запарывает содержимое памяти спрайтов.

А физическое повреждение - стало быть, миф?

Про GB я не знаю, но на MSX есть подобный момент, если включить порты ввода-вывода AY (звукового чипа) на выход вместо входа - они будут бороться с входными сигналами, и теоретически это может повредить чип. Практических случаев вроде не известно. Аналогично, простые мапперы для NES, типа UNROM, из-за упрощённой дешифрации требуют, чтобы в локации ПЗУ было уже записано значение, которое пытаются в неё записать (для управления маппером), иначе возникает конфликт выходных сигналов ПЗУ и регистра маппера, и потенциально это тоже опасно - на практике просто ничего не работает, но не ломается.

Про Game Boy нашёл, где о таком читал:

https://gbdev.io/pandocs/LCDC.html#lcdc7---lcd-enable

"Stopping LCD operation (Bit 7 from 1 to 0) may be performed during VBlank ONLY, disabling the display outside of the VBlank period may damage the hardware by burning in a black horizontal line similar to that which appears when the GB is turned off. This appears to be a serious issue. Nintendo is reported to reject any games not following this rule"

Похоже, начинает гнать через дисплей постоянный ток, что чревато электролизом.

А, действительно, вспомнил такое, оно повторяется из описания в описание. Да, при этом должны остановиться и счётчики, и вообще тактирование контроллера дисплея, и вероятно будет идти постоянный ток на строку, которая была активна в момент останова. Пробовать на практике, что именно будет, желания как-то не возникло.

Интересно, зачем именно в Game Boy вообще нужна функция отключения дисплея при включённом питании всего остального? Дежурный режим там вроде как не предусмотрен, выключатель питания физический.

Это по сути сброс контроллера, вроде как в некоторых играх он применяется для растровых эффектов, выключением-включением контроллера в нужный момент. Дежурного режима нет, однако, в гайдах есть рекомендации по экономии энергии, т.к. система неплохо жрёт батарейки, и в частности расход энергии можно сократить, останавливая процессор на неиспользуемое время кадра (посчитал кадр, время ещё осталось - halt, кадровое прерывание выводит из останова).

Так во время отключения контроллера дисплея изображение на Game Boy пропадает, и только на Super Game Boy - "замораживается".

UFO just landed and posted this here

Да, есть такой цвет, 0x0d. Но про опасность выхода из строя - это скорее всего миф, т.к. цвет реально встречается в паре десятков коммерческих игр. Развёртка может срываться у некоторых телевизоров - это факт. Больше информации тут.

UFO just landed and posted this here

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

Значит, популярный миф - не такой уж миф? Когда оксидный катод нагрет, но не испускает электроны, это для него тоже не самый оптимальный режим. Правда, в этом случае "Радио-86РК" и подобные платформы портили бы кинескопы ещё сильнее, чем "Денди", а таких жалоб на них не было.

Sign up to leave a comment.