- =A=L=X=
- Постоялец
0iStalker
Мда, в России практически неизвестно то дикое количество аддонов и приблуд которые в Японии выпускались для фамикома.
Собственно на этом же канале он много такого дерьма странного обозревает.
8-bit guy выпустил небольшое видео про то как работали старые контроллеры:
Если в большинстве случаев всё было очень просто - прямой завод контактов на порт ввода, отчего в проводе до джойстика/геймпада было столько проводов сколько кнопок/направлений + 1 на землю.
То у Famicom/NES/Денди случай более сложный (на видео с 5:20) - проводов в шнуре было меньше 8 кнопок (всего 7), но еще и два из них использовались для светового пистолета, так что геймпаду нужно было только 5 проводов.
Из них два были земля и +5В, а вот три были latch, clock и data.
Что происходило - в геймпаде стоял 8-битный сдвиговый регистр марки 4021.
Кнопки были заведены на 8 входных бит этого регистра. При подаче перепада на контакт latch их состояние копировалось в триггеры 4021 и застывало там.
Далее консоль подавала периодически сигналы на контакт clock и при этом биты в микросхеме сдвигались и последний из них выводился в контакт data который и попадал в порт ввода.
То есть чтобы считать 8 кнопок надо было сперва зафиксировать их состояние в регистре встроенном в геймпад, а потом 8 раз дёрнуть ему цикл сдвига. На видео всё наглядно изображено, но на английском.
В SNES использовался тот же принцип, но кнопок было больше и потому сдвиговый регистр тоже был больше по битам.
=A=L=X=
> 8-bit guy выпустил небольшое видео про то как работали старые контроллеры:
Кластер про это 3 года назад видео делал
0iStalker
> Кластер про это 3 года назад видео делал
У 8-bit guy всё же лучше расписано что именно происходит в денди. Кластер даже не упоминает что там используется сдвиговый регистр, что половина объяснения тому что происходит.
=A=L=X=
> Кластер даже не упоминает что там используется сдвиговый регистр
На 2й минуте, доступным языком
0iStalker
> На 2й минуте, доступным языком
Ну так я её и посмотрел - там просто "для этого стоит простенькая микросхема" - но что за микросхема - ни слова. Про latch, например, говорит, что это "просто обозначает начало и конец передачи", но latch это "защёлка" и суть происходящего в том, что биты кнопок "защёлкиваются" в триггеры сдвигового регистра и в дальнейшем по clock по нему собственно сдвигаются, а не потому что "начало передачи".
=A=L=X=
> биты кнопок "защёлкиваются" в триггеры сдвигового регистра и в дальнейшем по
> clock по нему собственно сдвигаются
я так когда то динамическую индикацию делал, на синхронный СОМ порт вешал последовательно два сдвиговых регистра, один регистр переключал стробы, а второй данные на линейку 7-ми сегментных индикаторов.
Tonal
Если я правильно понимаю у тебя были регистры обратного толка - в однобитовый вход записываешь последовательно байт, а потом с параллельных выходов снимаешь его. А тут наоборот с параллельного входа берется байт и сериализуется в поток бит.
=A=L=X=
Есть универсальные регистры в которые можно записать или считать как парралельно так и последовательно.
Tonal
> Есть универсальные регистры
Ну да. В фамикоме просто использовались видимо самые дешевые для своей цели. И там на выход подавалось только 3 последних бита из восьми, судя по всему они просто влезли в форм-фактор микросхемы, а вывести их ничего не стоило. Денди использовала только последний контакт.
Эх. Ностальгия.
Если -A-L-X- не против.
То запощу видео для тех кто не застал крутых времен :)
Commodore 64 не был распространён в наших широтах, но в Северной Америке он сыграл наверное такую же роль, как ZX Spectrum в Европе. Вот только он был примерно в два раза дороже и наверное примерно в два раза лучше по усреднённому количеству возможностей своих компонент. Так, например, его видеочип (VIC-II) умел несколько разных видеорежимов, причём как текстовых так и графических, поддерживал аппаратные спрайты и в целом был гораздо более заточен под игровые применения, нежели спектрум.
Вчера я наткнулся на забавную особенность видеочипа Commodore 64 в англоязычной статье про реализацию на этом ПК плавного скроллинга: http://1amstudios.com/2014/12/07/c64-smooth-scrolling/.
Дело в том, что в портах ввода–вывода видеочипа были регистры позволяющие использовать аппаратный плавный скроллинг, но общая реализация системы делала его реализацию довольно нетривиальной вещью.
В играх как правило использовался текстовый видеорежим, т.к. графический был совсем неподьёмен для плавной графики.
Фактически текстовый видеорежим является попросту тайловым, как в денди, и главным образом задаётся тремя зонами видеопамяти:
1. массив 256 изображений символов (тайлов) 8x8 (2048 байт)
2. таблица 40x25 кодов символов — содержимое квадратно–текстовой сетки текста/тайлов экрана (1000 байт)
3. таблица 40x25 цветов символов — нижние 4 бита выбирали один цвет символа из фиксированной палитры на 16 цветов (тоже, как понятно, 1000 байт)
Кроме того существовало два варианта цветовых режимов — детальный и многоцветный.
В детальном режиме изображения символов были монохромные. При этом один (зачастую чёрный) цвет был общим для всего экрана, а второй выбирался из таблицы цветов и таким образом мог варьироваться по экрану от символа/тайла к символу/тайлу.
(Демонстрация цветных символов с одним общим чёрным цветом фона)
В многоцветном режиме на пиксель символа выделялось два бита, при этом массив изображений описывал тайлы 4x8, которые однако вытягивались в два раза на экране таким образом всё равно формируя тайл 8x8 — изображение теряло в горизонтальном разрешении с 320 до 160 пикселей. С цветами было так же хитро — три из них задавались на глобальном уровне и только один, третий, выбирался из цветовой таблицы. В играх это был предпочтительный режим из–за цветности, но как понятно, подбирать палитру на Коммодоре было тем еще творческим занятием, т.к. варьировался по тайлам только один цвет из четырёх.
Например посмотрим на скриншот игры Turrican II:
Так сразу и не скажешь, что три цвета на этой картинке общие между всеми тайлами, хотя какая то ограниченность цветовой палитры несомненно чувствуется.
И вот возвращаемся к вопросу плавного скроллинга — в видеочипе было два 3–битных регистра задающих скроллинг всего текстового экрана по вертикали или горизонтали на от 0 до 7 пикселей.
Техника для, например, горизонтального скроллинга предполагалась следующая:
— в видеочипе включается подавление вывода двух крайних колонок текста для бесшовности
— далее 7 раз экран скроллится попиксельно только лишь записью в регистр горизонтального скроллинга
— а вот на 8–ой раз, когда он уже проворачивается через ноль таблицы символов и их цветов надо было физически сместить на 1 байт левее и дописать в освободившуюся колонку новые номера тайлов и их цветов
Казалось бы ничего сложного, но на последнем шаге и возникала мощная проблема — процессор C64 (MOS 6502) просто не успевал переписать два килобайта массивов тайлов и их цветов за относительно короткий период VBlank (когда видеочип «отдыхает» после вывода очередного кадра на электронно–лучевую трубку монитора, подробнее о чём я писал тут) и проваливаясь в период VDraw (когда видеочип собственно выдаёт построчно на монитор сигнал о картинке на экране) создавал ужасные и неприемлемые вертикальные разрывы и дёргания изображения. Тут надо заметить, что обновление картинки шло с частотой 50 или 60 герц и поэтому временное окно было действительно маленьким.
Чтобы побороть эту проблему и еще оставить пространство для обработки игровой логики, звука и манипуляций со спрайтами приходилось писать довольно изощрённый код.
Во первых — в C64 местонахождение адреса таблицы кодов символов в памяти была настраиваемой величиной, что позволяло делать двойную буферизацию — таким образом обновление этой таблицы можно было разбросать по семи остальным VBlank, чтобы разгрузить наш критический до приемлемых величин. Содержимое активного буфера тайлов кусками переписывается со смещением в теневой буфер, после чего на восьмой такт буфера переключаются. Автор статьи по ссылке разбрасывает его на два других VBlank — их становится достаточно.
Но вот с таблицей цветов такой номер не проходит — она жёстко прошита по фиксированному адресу и даже обновление только её опять не пролазит в нужный VBlank, т.к. нужно еще успевать обрабатывать звук и прочее. Тогда автор приходит к следующему решению — он еще на предыдущем кадре отлавливает момент на фазе VDraw когда видеочип уже выдал информацию о первой строке символов на монитор и начинает переписывать первую половину цветовой таблицы отставая от хода луча ЭЛТ и потому не подрывая процесс, остаток же цветовой таблицы он обновляет уже на наступающем VDraw, половина таблицы уже успешно обновляется за его время.
Таким образом размазывая все эти обновления и скроллинги по разным фазам VDraw и VBlank на Commodore 64 всё–таки становится возможным получить идеальный плавный скроллинг. Возможно автор статьи несколько перемудрил с процессом, у меня закрадывается такое подозрение, но в целом принцип крутится вокруг этого.
В качестве бонуса занимательное видео любительского «порта» игры Limbo на Commodore 64, где используется еще немало других трюков:
А, никто не знакомился с инструментом разработки игр под SMD на Бейсико подобном языке
Basiegaxorz? (внутри есть примеры, но проект не развивается с 2010г.)
P.S. Пара даже игрушек встретилась сделанная или перенесённых под него (Barbarian, CrazyCars)
Проверил, компилируются и работают под симулятором.
Сейчас интересно освоится с системой команд Motorolla 68000 (описана в разных книгах с разной степенью понимаемости). Есть и симуляторы её (Easy68K).
т.к. 68000 использовался много где, то тема может быть интересна для изучения и реверсинга.
Можно замутить какой нибудь вариант Форта под него (из существующих разработок)
KPG
> Motorolla 68000
Эта платформа была довольно популярна, например использовалась в определенном поколении компов Apple, поэтому под неё существуют довольно продвинутые компиляторы в целом.
Она мне по первому ознакомлению вообще понравилась даже больше, чем i386 - регистров больше и деление их на данные/адреса по идее должно быть довольно естественной штукой даже в асме.
> Basiegaxorz
На gbx есть чувак пишущий игры http://gbx.ru/?showtopic=127428 на SMD под SecondBasic https://gcup.ru/load/engines/secondbasic/3-1-0-2487 базированный как раз на нём.
Да, система команд M68K достаточно мощная и чем то напоминает в целом команды PDP-11.
И этот процессор есть и в частности у таких девайсах Sinclair QL, TI-86/92, Canon Cat, Palm ...
(калькулятор TI89/92 содержит алгебраическую систему символьного вычисления Derive, и даже для этого калькулятор пользователи наделали разного софта и игр на сайте https://www.ticalc.org)