FT812. Вступление и лирика



Как в своё время было принято начинать научные труды цитатами из вождей, так и данную статью стоит начать чем-то вроде: сценообразующий режим 6912 неисчерпаем, как андронный коллайдер и все такое.

Но данная статья будет ровно о противоположном — она будет не о 6912, а наоборот.

Среди направлений научно-хозяйственной мысли по прикручиванию к ZX расширенной графики, если речь идёт об аппаратных доработках, можно перечислить следующие:
— модификации плат на дискретной логике путём допаивания корпусов,
— создание новых режимов в клонах на FPGA,
— создание спрайтовых процессоров в клонах на FPGA,
— использование готовых ASIC-ов видеопроцессоров.

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

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

Блиттер. Вторая стадия болезни. Изобретатель уже осознает, что сил Z80 на новый режим не хватит. Предлагается концепт «видеокарты» на бюджетной FPGA с максимальным количеством SRAM (потому что работать с дешевой и большой SDRAM автор не умеет). «Видеокарта» должна аппаратно двигать тонны пикселей по командам Z80. На этом мысль автора обычно тоже обрывается.

Спрайтовый процессор. До этой стадии видеопроцессорного дизайна доходят немногие и намного меньше, чем почти лишь каждый.
Я пока знаю двоих =)

В отличие от блиттера, который:
1) читает фоновые данные из видеопамяти,
2) читает данные для блиттинга,
3) пишет результат блиттинга в видеопамять,
4) после чего видеоконтроллер читает видеопамять для отображения на экране,

спрайтовый процессор делает не четыре операции, а одну:
1) читает видеопамять для отображения.

Главная идея в том, что спрайтовый процессор строит экран на лету. При этом в памяти нигде не хранится в виде битмапа то изображение, которое мы видим на экране. Оно состоит из описаний разрозненных элементов, а видеопроцессор собирает их в общую картинку.

Попытки использовать на спектрумах готовый чип в качестве внешнего спрайтового процессора, насколько мне известно, закончились на существующей в одном экземпляре видеокарте на V9990. О том, насколько тёпл и лампов сей микросхем можно почитать здесь. Кроме его неиллюзорной теплоты он имеет и другие особенности:
— непонятно в каком музее его брать и по цене какого самолёта, как и его особенную двупортовую память,
— он поддерживает работу только в ТВ развертке, VGA соответственно в сторонке.

И однажды попался этот проект. Видео очень понравилось. И заверте…

В проекте Gameduino 2 использован видеопроцессор FT800 фирмы FTDI, известной народу по USB RS-232 адаптерам FT232.
О возможностях судите сами (спискота неполная):
— выход цвета 24 бита,
— бортовое ОЗУ (не требуется внешнего),
— дисплей лист, который представляет собой набор команд для рисования,
— во всех экранных операциях учитывается альфа 8 бит,
— битмапы (читай: спрайты) каких угодно цветовых форматов: палитровый, грейскейл, труколор, с альфой, без альфы и прочая,
— афинные преобразования (читай: зумротатор), в том числе и с линейной фильтрацией,
— графические примитивы: круги, прямоугольники, линии,
— БЛИТТИНГ, ичсх на лету,
— сопроцессор для распаковки JPEG, PNG, ZIP и рисования всякой всячины,
— подключение по SPI,
— смешная цена 8 долларов (на самом деле — 12 с пересылкой).

Как водится, я стал искать недостатки в этом чипе, и нашёл только один: максимальное разрешение — 512х512 пикселей, что не дает возможности развернуть изображение в формате VGA.

Через некоторое время фирма FTDI выпустила новую линейку FT81x, в которой можно было развернуть VGA в разрешении 800х600 и более того — 1024х768 пикселей.

Чип FT812 стал основой девайса под названием VDAC2.
Девайс продан в количестве несколько десятков штук (я думаю, уже около сотни).
О нём и пойдет речь в дальнейших статьях.

И немного рассуждений.
На данный момент имеются следующие опасения и контраргументы, услышанные мной в сообществе спектрумистов по девайсу.

«Недостаточная 8-битность».
Всё очень гладко, всё в очень высоком разрешении, какойто андроид и прочее.
Уверяю вас, уважаемые юзернеймы: на данном девайсе можно нарисовать более, чем 8-битный контент (об этом тоже речь дальше).
Никто же не парится от того, что на стриме и кикстартере лежат игрухи, которые работают как на РС, так и на андроиде.

«Непроцессор не будет успевать».
У FT812 дисплей лист имеет размер 8192 байта и состоит из 4-байтных команд, с битовыми полями разной размерности. AVR8, например неплохо успевает его рассчитывать, но у Z80 действительно нет шансов.
Однако, можно модифицировать дисплей лист и не «в лоб», и непроцессор будет успевать. Об этом я тоже расскажу позже.

«Непонятная сложность».
Новый концепт всегда вызывает страх непонимания и нежелание напрягаться и разбираться.
Тут могу сказать следующее: FT812 проще чем все, с чем мне приходилось иметь дело в графических системах. А кроме того, я работаю над созданием SDK, чтоб уменьшить порог входа до минимума.

А пока, можно порассматривать картинки (вытащенные с ардуины через SPI-USB переходник). В скриншотах присутствует альфа-канал, так что рассматривать стоит в фотошопе, например.




  • avatar
  • +34

14 комментариев

avatar
Продолжай…
avatar
Очень интересно, давай ещё
  • VBI
  • +2
avatar
Надеюсь, это всерьёз и надолго =)
avatar
Блиттер. Вторая стадия болезни. Изобретатель уже осознает, что сил Z80 на новый режим не хватит. Предлагается концепт «видеокарты» на бюджетной FPGA с максимальным количеством SRAM (потому что работать с дешевой и большой SDRAM автор не умеет). «Видеокарта» должна аппаратно двигать тонны пикселей по командам Z80. На этом мысль автора обычно тоже обрывается.


Kek. На этом обычно обрывается (если вообще не проходит мимо) мысль религиозно верующих во спрайты. Основное преимущество блиттера как раз в том, что развивать его намного удобнее. И еще, если уж для спрайтера всё свалено в одну кучу, то и список операций для блиттера также можно сократить до двух пунктов «чтение и запись видеопамяти» (кстати, первые два вида чтений необязательны).

Дальше будет больше матчасти и меньше богословия, я надеюсь. Железяка интересна, хоть и неспектрум :p
avatar
Основное преимущество блиттера как раз в том, что развивать его намного удобнее.
Обоснуй.
Если речь о таком развитии, как у «быстрой видеокарты метеора», то конечно ))
кстати, первые два вида чтений необязательны
Чтение бэкграунда обязательно.

Дальше будет больше матчасти и меньше богословия, я надеюсь.
Б-г-словия много, ибо смотри название статьи )
Дальше будет немного философии, потому что сабж для людей незнакомый, непонятный и пугающий.
Однако статьи будут относительно четко разделены на философские и технические.
avatar
Обоснуй.
Если речь о таком развитии, как у «быстрой видеокарты метеора», то конечно ))
Нет, вообще. Чхать на тайминги развёртки и разрешение, на локальные заторы на шине данных. Не поломаешь совместимость с прошлыми фичами. Узлы разных стадий работы с блоком можно заменять и дорабатывать независимо. Добавлять новые форматы блоков, дисплей-листа. Вся система в целом «свободнее»

Чтение бэкграунда обязательно.
При наложении — необязательно, если гранулярность доступа равна пикселю. При восстановлении — фон может оказаться сплошным/градиентом/закэшированным «тайлом» или текстурой. Схему кэша, кстати, тоже проще пилить отдельно и без особенной оглядки на старый софт. Впрочем, это отдалённая перспектива.
avatar
Ну вот тсконфа, я ее пилил 2 года, дорабатывал, вроде ниче катастрофически не ломалось.
Не вижу связи между развитием архитектуры и типом графпроца — блиттер или пиксельбуфер.
Опять же, тот же формат дисплей листа из фт812 можно запросто реализовать в блиттере. С т.з. программной модели не будет никакой разницы.

Чтение бэкграунда обязательно.
Вот ситуация: ты рисуешь 3 спрайта 32х32, один по координатам 0,0, второй по 200,200, третий по 16,16. Допустим тебе хватит кеша чтоб не читать фон для 3го спрайта. Усложни задачу — добавь еще 25 промежуточных спрайтов, которые гарантированно вытолкнут кеш.

Относительно блиттера мое мнение таково: он позволяет нарисовать больше объектов за фрейм при большем использовании памяти. Применим в системах, где памяти много и она быстрая.
Пиксельбуфер — более изящное решение.
Я позже покажу пример для фт812, в котором бы лучше справился блиттер — большое кол-во объектов дисплей листа на экране.
avatar
Что, вот прям ни разу такого не было, что начинали глючить старые демки после добавления новых фич, если что-нибудь по таймингам не сошлось? Надо быть ну очень уж осторожным. С блиттером вообще об этом можно не думать. Как однопоточность против многопоточности.

А зачем мне фон читать при выводе спрайтов (если нет каких-нибудь эффектов полупрозрачности)? Фон я буду восстанавливать одним махом в начале цикла отрисовки нового кадра. Кэш тогда сработает эффективно.

Память блиттеру действительно желательна побыстрее, но вот размер не обязательно нужен больше. Можно ведь и распаковывать на лету (а скорость распаковки непостоянна, что для блиттера значения не имеет). Да и просто собирать из кусочков, особо спрайты, часть которых в разных фазах анимации совпадает.

По решениям имею твёрдое мнение, что сперва удобство, потом изящество. В современной обстановке, само собой, и при проектировании нового (втиснуться в старое железо — особый случай).
avatar
Многие мне говорят, что я хам, и я согласен с их мнением.
Чо добавить?.. Да, ты прав во всём.
avatar
Какое-то ощущение «бесконечных мощностей» от твоих слов
avatar
Не бесконечные, но более чем приличные.
avatar
А сорри, не на то ответил =)
avatar
и так неплохо получилось))
avatar
TSL, Крассава) Ждем, продолжения… IDE-это нужная весчь!) В массы, в продакшн…
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.