[umup 0]

Хватит ли для создания такого контроллера (с управлением от любого микроконтроллера через параллельную/последовательную шину) PLD типа EPM3064/3128 и 256/512К 70ns 8-битной FPM/EDO памяти (осталась куча от старых видеоплат). Разрешение не очень существенно (от 512х512 до 1024х1024, 4,8 или 16 бит). Понятно, что нужны 2 10-11 битных счетчика для перебора строк/столбцов, немного логики для обнаружения перехода на следующую строку и формирования сигналов синхронизации. Еще нужно обеспечивать доступ от контроллера (по скорости памяти одновременная запись и чтение невозможны), наверно придется сделать 2 банка памяти - 1й текущий отображаемый буфер, 2й - для фоновой записи из контроллера, контроллер заполняет фоновый и во время кадрового импульса переключает страницы. Пока непонятно как делать регенерацию памяти фоновой страницы. С выдачей изображения понятно - в начале строки выставить ее адрес и подать ~RAS, далее выставлять адрес пикселя в строке и подавать ~CAS.

[Artem-1.6E-19 0]

Хватит ли для создания такого контроллера (с управлением от любого микроконтроллера через параллельную/последовательную шину) PLD типа EPM3064/3128 и 256/512К 70ns 8-битной FPM/EDO

Нет.

[umup 0]

Почему ? Уже пробовали ?

[Artem-1.6E-19 0]

Почему ? Уже пробовали ?

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

[Postoroniy_V 0]

Хватит ли для создания такого контроллера (с управлением от любого микроконтроллера через параллельную/последовательную шину) PLD типа EPM3064/3128 и 256/512К 70ns 8-битной FPM/EDO памяти (осталась куча от старых видеоплат). Разрешение не очень существенно (от 512х512 до 1024х1024, 4,8 или 16 бит). Понятно, что нужны 2 10-11 битных счетчика для перебора строк/столбцов, немного логики для обнаружения перехода на следующую строку и формирования сигналов синхронизации. Еще нужно обеспечивать доступ от контроллера (по скорости памяти одновременная запись и чтение невозможны), наверно придется сделать 2 банка памяти - 1й текущий отображаемый буфер, 2й - для фоновой записи из контроллера, контроллер заполняет фоновый и во время кадрового импульса переключает страницы. Пока непонятно как делать регенерацию памяти фоновой страницы. С выдачей изображения понятно - в начале строки выставить ее адрес и подать ~RAS, далее выставлять адрес пикселя в строке и подавать ~CAS.

если взять sram вместо dram и вычитывать спрайты из ROM(тоесть экран будет состоять из спрайтов)

то сделать можно но PLD 3128 нужно 2-3 штуки

[Flanker 0]

Сделать аналоговый VGA контроллер на таком железе в принципе невозможно.

Допустим даже если делать монохромный VGA, то имеем исходные данные: разрешение 640х480, 8 бит на градации серого, 60 Гц кадровая.

Даже если не учитывать неактивные точки в кадре, необходимые на обратные строчные и кадровые ходы, то получим, что необходимо в памяти хранить 640*480=307200 байт. Значит неоходимо имеет память объемом 512*8 Кбит. Шина адреса будет иметь ширину 19 бит. Предполагается организовать 2-х страничную память. В итоге в PLD необходим как минимум один 19р регистр (если ША общая) и два 8р регистра (раздельные ШД). Итого получим уже занятых 35 триггеров, а еще необходима логика для генерации строчных и кадровых синхроимпульсов (дополнительные счетчики, разрядность в зависимости от используемого Clk), контроллер регенерации памяти и т.д.

Хоть с данными PLD не работал, но судя по маркировке в них либо 64, либо 128 триггеров. Так что одного 3128 может и хватит (сомнительно), но хватит ли пользовательских ног, да и гибкости при трассировке у PLD никакой, итоге проект может и не влезть.

Память тоже придется заменить. Время доступа в 70нс явно велико. Период одного кадра (при частоте 60 Гц) составляет примерно 16,7 мс. Мы имеем как минимум 307200 активных точек. В итоге, чтобы за кадр выдать все точки, необходимо выдавать каждую за 16,7/307200=54,3нс, а еще время на регенерацию. Значит необходимо ОЗУ с временем доступа не меньше 50 нс, а лучше обойтись асинхронной SRAM, благо кристалы SRAM 512х8 Кбит найти можно.

 

Удачи

[rezident 0]

Память тоже придется заменить. Время доступа в 70нс явно велико. Период одного кадра (при частоте 60 Гц) составляет примерно 16,7 мс. Мы имеем как минимум 307200 активных точек. В итоге, чтобы за кадр выдать все точки, необходимо выдавать каждую за 16,7/307200=54,3нс, а еще время на регенерацию. Значит необходимо ОЗУ с временем доступа не меньше 50 нс, а лучше обойтись асинхронной SRAM, благо кристалы SRAM 512х8 Кбит найти можно.

Как сейчас помню (визуально) видеокарту для шины ISA на чипе Trident 9000A (или C?) на которой стоят м/с DRAM 70 нс. 512кБ памяти было на нем. И ведь как-то работал аж 800*600 гаденыш! :) Правда с частотой рефреша всего 56Гц.

[umup 0]

Но ведь это и есть память со старых видеоплат ! Intel P21014, Mosel V53C104F, Siemens HY8514256A - 4 бита, 256К. Есть и более жирные 1M EDO 16бит, но в SOJ копусах. В режиме FPM при чтении строки время доступа по ~CAS 55ns даже для памяти на 80ns.

Кстати, FPM или EDO память еще производят, или все на SDRAM ? У нее вроде протокол доступа сложнее.

[Flanker 0]

В принципе, если использовать черезстрочную разверку, то скорости работы памяти 70 нс будет достаточно. но для построчной (прогрессивной) нет. Я считал именно для построчной развертки.

[otrog 0]

Вот чего нашел:

General purpose display controller

Так что на CPLD сделать VGA-контроллер вполне реально.

Но на FPGA ИМХО получится лучше:

Verilog Assignment 1: VGA Controller

[umup 0]

Ясно, это я уже видел. Наверно для упрощения действительно лучше взять SRAM (есть на 64К от кэша мат.плат, на 320х200 точек хватит для эксперимента, можно также купить недорогую 512К от Alliance).

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

Изменено 6 декабря, 2006 пользователем umup

[EXeGLuMATOR 0]

Вот только поднимал подобную тему. И была в той теме ссылочка на очень интересный сайт по подобного рода вещам. :)

Ну, дабы не теоретизировать на эту тему - вот практическая помощь. :)

В аттаче файлик с той самой странички, на которую я давал ссылку. Генератор адреса и синхры для VGA 640х480х60Гц от 25 МГц. Можно легко переделать на другие параметры. Только адрес и синхра и сигнал разрешения на чтение из памяти. Входы клоков для цветов - лучше на высокий уровень и на выходе будет нормальный сигнал разрешения - проверено, все ОТЛИЧНО работает. На циклоне, вместе с PLL и памятью на паттерн - весь проект занял 98 элементов.

Сам генератор влезет в 3128, но вот по ногам... Может быть проблема. :) Плюс для формирования ВГА в аналоге надо выводить по 8 ног каждого цвета, например на R-2R матрицу. Качество отличное. Все очень четко вписывается в экран и монитор подстраивается на автомате прям очень хорошо.

Проект делался в квартусе 5.1

vga_sync.zip

[moonrock 0]

Давненько я делал подобную штуку. Состояла из Меги128, ЕПМ3128А и статической памяти 256кБ.

Девайс врезал тексты и картинки в ТВ сигнал(перекрестье + текст по краям), правда в черно-белый, но все равно я один байт на пиксель уводил, 1 на коммутатор и 7 на цвет, т.е. 128 градаций серого.

Разрешение было в два раза меньше телевизионного - 384х288. Память подключалась к меге через плисину, причем плисина могла влезать в память так, что контроллер ничего не подозревал. И без всяких wait state. Плисина тактировалась 28 МГц, память на 14МГц, а контроллер на 7 МГц. Тяжело вспомнить, в плисине кажется было занято всего 90 МЯ, но там были узлы которые вам не понадобятся. Так что если идею разогнать немного модифицировать и применить, то VGA получить можно.

 

PS. Если найду остатки старого бука, то поищу файлы.

[EXeGLuMATOR 0]

Да там ничего сложного и нету. Особо. :) На плисе удобно делать сам генератор сигнала и интерфейс на видеопамять. Единственное - если делать в цвете - то в зависимости от количества цветов - придется и разрядность и объем памяти менять. А заполнение памяти и вывод - на контроллере каком-либо. если и плисина жирная - то можно и на встроенном проце (типа НИОСа) делать. Хотя гибкости меньше - чуть изменил код - и может не влезть... :(

Впрочем, судя по отсутствию активности автора темы - разобрался он уже с этим. :)

[umup 0]

Впрочем, судя по отсутствию активности автора темы - разобрался он уже с этим

Говорить пока не о чем. Заказал EPM3032,3064,3128, SRAM 256K - еще не пришли. Пробую в MAX+plus разные варианты, нужно сделать как можно дешевле. Кроме варианта с VGA хочу проработать вывод на TV и контроллер LCD на разные разрешения. Под вопросом - связь с контроллером (3 варианта - полная шина адреса/данных (как у http://elm-chan.org/works/crtc/report.html), 8-битная управляющая шина команд/адреса/данных (у многих LCD, http://www.schemov.com/), или последовательная шина, например SPI). Последний вариант лучше в плане экономии выводов контроллера, но хуже в плане скорости. Хотя для отображения окон/текста/графика процессов думаю хватит и этого. Производители так называемых промышленных компьютеров/дисплеев вообще оборзели с ценами. А хочется сделать замену семисегментной индикации - LCD или ЭЛТ экранчик с тач-скрином, контроллер типа ATMega/AT91SAM7S/LPC21xx, набор универсальных подпрограмм для отображения текста/графики - и проблема индикации решена.

Еще один вопрос - формирование пиксельной частоты. Для этого можно будет использовать саму ПЛИС - сделать внутри программируемый счетчик-делитель, внешний ГУН - должно получиться. Кто-нибудь делал такое ?

Изменено 26 декабря, 2006 пользователем umup