Valen
Вообще, я, конечно, согласен - видеопороцесор необходим в большинстве случаев. Речь не идет о 3D - и без этого мы имеем очень затратные операции свёрток при масштабировании изображения, сглаживании... Можно составить минимальный набор операций видеопроцессора (в моём понимании, в отличие от видеоконтроллера видеопроцессор способен выполнять самостоятельные операции над содержимым видеопамяти):
1) Копирование растр-растр с масштабированием и альфа-прозрачностью.
2) Сглаживание растра.
3) Поддержка оверлеев (спрайтов) - минимум одного оверлея (для мышиного курсора).
Под растром понимается прямоугольная часть экрана либо буфера видеоозу.
Сделать приемлимый видео-проц на ПЛИС (то, что вы задумали) дело не
тривиальное.
Согласен, обладающий минимальными 2D возможностями видеопроцессор на логике реализовать проблематично: тут и проблемы с DMA, и контролем ресурсов, проблемы с реализацией свёртки, форматом поверхностей (растров)...
Но я собираюсь делать лишь видеоконтроллер, а вовсе не видеопроцессор. То есть никаких самостоятельных операций в видеосистеме, кроме вывода на экран.

Я, для себя, пришёл к выводу, что нужно отталкиваться именно от
графич. возможностей (т.е. VDP со своей личной быстрой памятью),
разрядность и скорость ЦПУ дело второе.
Это зависит от ТЗ на вычислительную систему. В моём случае ТЗ не содержит требований к графики - кроме возможности эту графику воспроизводить с любыми разрешениями на любых устройствах. Так что я это и реализовываю.
А моё ТЗ получилось прежде всего из необходимости минимизации стоимости, из стоящих перед платформой задач (это НЕ ИГРОВАЯ платформа), а также из опыта программирования ПК. Могу сказать, что до 640х480 у P-200 под Windows+DirectX вполне хватает производительности, чтобы любой вышеперечисленный эффект много-много раз реализовать в реал-тайме. У меня есть работающие игры, использующие такой режим и возможности программного альфа-канала и сглаживания/масштабирования. Тут всё зависит от программиста, и только.

И пару слов по дизайну видеосистемы. специально для Valen.
Видеоозу разделено на два банка по 8Мб. Физически это две разные 16-ти разрядные микросхемы PC-133. Процессор обращается всегда только к неактивному банку, эффективная скорость обмена равна скорости обмена процессора с основным ОЗУ. Т.е. никаких задержек нет. Банки переключаются моментально, одной командой.

Видеоконтроллер способен посылать прерывания процессору по сигналу обратного вертикального хода луча и по требованию переключать банки видеопамяти.

Видеорежимы поддерживаются только беспалитровые. Опять же, ещё во времена программирования графических движков под ДОС я экспериментировал с различными вариантами палитр, VESA 2.0 режимов, "нереального" режима i386 CPU и т.п. В результате пришёл к выводу (палитровую анимацию в расчёт не берём), что для практических задач (игры и т.п.) достаточно 8-битного цвета с фиксированной палитрой, отображающей цвета форматом 2-3-3 (RGB; градации красного цвета наименее различимы глазом). Видеоконтроллер будет поддерживать 2-3-3, 5-6-5 и 8-8-8 видеорежимы. Причём последний вариант как 24, так и 32 бит на точку (во многих случаях 32 бита работают быстрее 24-х из-за отсутствия дополнительных операций).

Оверлеи поддерживаться не будут, т.к. это усложняет конструкцию (у меня используется внешний DAC, подключенный напрямую к выводам м/с памяти).

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

Жду комментариев, Valen