ТЕМА: Делаем видеоадаптер на ПЛИС со всеми "плюшками"

В видеопроцессоре компьютера Yamaha MSX, который мы ковыряли в 1987 году, в одной строке растра экрана можно было расположить не более четырех спрайтов. При большем их числе спрайты начинали мерцать. Еще в данном видеопроцессоре интенсивно использовалась псевдографика с символами, у которых были многоцветные символы с определенными ограничениями. У более позднего ZX Spectrum была более примитивная псевдографика с двухцветными символами.
Я разработал в 1988 году компьютер на КР580ИК80А с 2 мегагерц тактовой частотой и 500 тыс оп/с с графическим и псевдографическим экраном 256х384 пиксела с 16 цветами на каждый пиксел. Затем на ассемблере написал игру, которая по кадровому прерыванию за один полукадр рисовала в теневом буфере новый кадр с цветными спрайтами, выдавала команды самодельному 4-голосому музыкальному синтезатору и осуществляла всю логику игры. т.е. за 20 мс делала все. Никаких мерцаний и перехлестов изображения не допускалось, которые я с удивлением наблюдал позже в играх на компьютерах, совместимых с IBM PC.
Думаю, что такое посильно и FPGA.

Patison пишет: В видеопроцессоре компьютера Yamaha MSX, который мы ковыряли в 1987 году, в одной строке растра экрана можно было расположить не более четырех спрайтов. При большем их числе спрайты начинали мерцать. Еще в данном видеопроцессоре интенсивно использовалась псевдографика с символами, у которых были многоцветные символы с определенными ограничениями. У более позднего ZX Spectrum была более примитивная псевдографика с двухцветными символами.
Я разработал в 1988 году компьютер на КР580ИК80А с 2 мегагерц тактовой частотой и 500 тыс оп/с с графическим и псевдографическим экраном 256х384 пиксела с 16 цветами на каждый пиксел. Затем на ассемблере написал игру, которая по кадровому прерыванию за один полукадр рисовала в теневом буфере новый кадр с цветными спрайтами, выдавала команды самодельному 4-голосому музыкальному синтезатору и осуществляла всю логику игры. т.е. за 20 мс делала все. Никаких мерцаний и перехлестов изображения не допускалось, которые я с удивлением наблюдал позже в играх на компьютерах, совместимых с IBM PC.
Думаю, что такое посильно и FPGA.

Теневой буфер, наверное, похож по смыслу на double buffering метод? Т.е. получается, что Вы не строили картинку именно в той области памяти, которая в тот момент выводилась на экран? Если памяти не хватит на теневой буфер, то надо будет во избежание мерцаний построить картинку не за время полукадра, а именно за вертикальный гасящий импульс, который меньше 20мс - 1,6мс, кажется, у аналогового телевидения. Такие игры были, но тут вроде как люди хотят подняться к разрешениям выше 800x600 - наверное там гасящий еще короче, а точек построить надо еще больше. Если у них дизайн интерфейса таков, что есть много перекрывающиеся элементы с прозрачностью, то не успеют.

На два буфера памяти хватает. Я имею ввиду "железную реализацию". У LPDDR2, которая стоит на плате, одна шина данных 32бита. Как я понимаю в один момент времени, только 1 процесс может ей воспользоваться, а значит, что когда идет трансляция в HDMI - шина занята. Как только хочу отрендерить второй экран - мне нужна эта же шина.
Плата будет только в среду, поэтому с памятью не успел "поиграться", но читал про заморочки доступа, то ли в два такта данные прилетают, то ли в один можно уложиться?
Вот и вопрос, какие кейсы есть для диспетчеризации запросов "в один такт"?

У DRAM бывают режимы, когда при установке на вход адреса можно читать каждым следующим тактом последовательно несколько ячеек памяти.
Можно еще изучить возможность применения более дорогой однопортовой или двухпортовой SRAM чтобы не мешалась регенерация.

Patison пишет: У DRAM бывают режимы, когда при установке на вход адреса можно читать каждым следующим тактом последовательно несколько ячеек памяти.
Можно еще изучить возможность применения более дорогой однопортовой или двухпортовой SRAM чтобы не мешалась регенерация.

Боюсь это "полумеры", а если захотим третий процесс, который тоже захочет получить доступ в память?

xakez пишет:

Patison пишет: У DRAM бывают режимы, когда при установке на вход адреса можно читать каждым следующим тактом последовательно несколько ячеек памяти.
Можно еще изучить возможность применения более дорогой однопортовой или двухпортовой SRAM чтобы не мешалась регенерация.

Боюсь это "полумеры", а если захотим третий процесс, который тоже захочет получить доступ в память?

У Вас есть один процесс, которому никак нельзя мешать - вывод изображение по HDMI. Есть этот один процесс и все остальные. Если порт один, то придется мультиплексировать доступ к нему во времени между HDMI и всем остальным. Если портов два - один только на вывод, второй на все остальное. Хоть их 10 процессов пусть будет - пусть конкурируют между собой, как на обычной шине данных (правда в ПЛИС это все равно мультиплексорами делается из-за, как правило, отсутствия высокоимпедансного состояния у выходов)

xakez пишет: Боюсь это "полумеры", а если захотим третий процесс, который тоже захочет получить доступ в память?

Вы посчитайте, какой процент от общего времени доступа будет занимать регенерация и сами решите, нужна вам DRAM или SRAM.
В советское время я изголялся над схемой так, чтобы процесс вывода на экран одновременно и регенерировал память. Поэтому отдельного времени и аппаратуры регенерации не требовалось.
Если в FPGA нужно будет использовать доп. оборудование для этой регенерации, то в случае SOFT решения оно отнимет от общего пула некоторое кол. ячеек.

Решил почитать ИНет по теме. Почему-то в основном нахожу результаты, связанные с Xilinx.
Для Altera нашел вот это www.altera.com/content/dam/altera-www/gl...donga-pusanu-web.pdf
Правильно ли я понимаю, что из этого документа нельзя сразу понять для FPGA какого размера оно подходит?

P.S.
вот, что Вы хотите сделать ?

Chaosorg пишет: Решил почитать ИНет по теме. Почему-то в основном нахожу результаты, связанные с Xilinx.
Для Altera нашел вот это www.altera.com/content/dam/altera-www/gl...donga-pusanu-web.pdf
Правильно ли я понимаю, что из этого документа нельзя сразу понять для FPGA какого размера оно подходит?

P.S.
вот, что Вы хотите сделать ?

Да) Именно это) Го в команду?) Плата приехала.

Посмотрел я плату, которая к Вам приехала :) Вроде вот эта www.altera.com/products/boards_and_kits/...ne-v-gx-starter.html
Ну что ж - это следующая ступень в плане потенциальных возможностей относительно Marsohod 3 и тем более 2
Понимание Ваших целей снизилось:( Зачем для такой FPGA "помощник" в лице STM32? Хочется понять, какого типа софт Вы "крутите" на STM32 - это просто "микроконтроллерный" C/C++ без ОС или RTOS или что? Т.е. согласитесь, что одно дело сделать что-то типа технодемо, совместимое только само с собой, а другое дело сделать способную на подмножество OpenGL видеокарту с драйвером под какую-то ось, ну или хотя бы под какую-то библиотеку, вернее какое-то где-то еще используемое API
И еще. Вы планируете один экземпляр устройства или тираж с BGA корпусом?