Стандарты VESA: как сгенерировать изображение для монитора?

[Slabovik]

Это наверное одна из списка сложных частей, которые делают любители.
Вопрос стоит так: имея вычислительную микросистему, уметь генерировать при её помощи изображение, пригодное для подачи на типовой монитор.

Всё бы ничего, строки, кадры, гашение, синхроимпульсы. Это можно делать на микросхемах. Вызывают вопросы тайминги всего этого и как это можно соотнести с имеющимися ресурсами. Причём в последнем главный камень преткновения у меня вызывает "раскладка" всего хозяйства на частоты распространённых кварцевых резонаторов и генераторов. Ведь кварц на редкую частоту ещё и фиг достанешь, а городить цифровую PLL тоже как-то неохота.

Копаясь в стандартах и схемах генераторов, быстро выяснил, что подавляющее большинство бытовых компьютеров, использующих для вывода изображение телевизор, с таймингами обращаются достаточно вольно. Оно понятно - при их проектировании кроме телевизоров ничего доступно и не было, а обыкновенный аналоговый телевизор и "подкрутить" можно, чтобы изображение было там, где надо.

Современные цифровые LCD телевизоры по этой причине изображение показывают "как бы" неверно. Например, у Орион-128 оно поднято вверх настолько, что не видно первой строки. Смотришь схему, времянки, и понимаешь - так оно и есть на самом деле.



А как оно должно быть?

Нашёлся в сети документ VESA Coordinated Video Timings (CVT) Standard (пришпилен ниже), в котором разложены по полочкам принципы расчёта таймингов и ещё один документ, в котором описаны все общеупотребительные тайминги развёрток.

И что получается. VESA в общем-то декларирует весьма вольное обращение с количеством строк и пикселей на экране (документ CVT), но довольно жёстко привязывает их отношения и частоты кадров.

Там же нашёлся и файлик CVT Generator - довольно занятная табличка в excel для расчёта. Из него получается, что в принципе, для монитора стандарта VESA нет необходимости выдерживать высокие частоты горизонтальной развёртки с сумасшедшими (минимум мегагерц так 28~30) частотами пикселей. Конечно, при условии, что нам выводить нужно немного. Например, для получения изображения 480x270 нужно всего лишь 10 МГц "пиксельной" частоты, а это умеет мой лично собранный Орион

Так вот вопрос: кто-то ковырялся уже на предмет "а как оно там, у современных мониторов"?
Безусловно, я сам тоже буду пробовать с целью хотя бы получить представление, насколько мониторы способны показывать "нестандарт".
С другой стороны, в сети можно найти интересные проекты, в котором на AVR, STM, PIC генерируются вполне годные изображения, например вот http://wiki.pic24.ru/doku.php/osa/articles/vga_terminal и обязательно посмотрите другие варианты - ссылки на них внизу статьи.

И вот ещё ссылка на Video Timing Calculator: https://tomverbeure.github.io/video_timings_calculator
Ещё один терминал на AVR http://www.vga-avr.narod.ru/main_rus.html
И ещё примеры по ссылке к аналогичной статье https://habr.com/ru/post/495542/#comment_21460356

[Slabovik]

Не получается у меня отредактировать ссылку выше - оставлю здесь.
Нашлась ссылка на BOX с открытыми VESA стандартами
https://app.box.com/s/vcocw3z73ta09txiskj7cnk6289j356b/folder/11133487793

[Slabovik]

За прошедший год нарисовал аж два взможных варианта "видеоадаптеров" для бытового ностальжи-ПК. Один простой, на замену Орион-128, второй сложный, более универсальный под проц i8086. Но в силу стеснённости ресурсами не реализовал ни один. Второй получился интересным, настраиваемым по всем параметрам вплоть до посадки адресов видеопамяти и полностью прозрачный для основного ЦП. Но сложный... Первый же проще, но с жёсткой логикой работы. И я бы его уже сделал, но боюсь ошибиться с таймингами, из-за которых вся работа по схеме может превратиться в тыкву...

Нашёл интересный файлик уже цифрового стандарта.  Если с VESA калькуляторов всё просто, то со стандартами какая-то довольно толстенькая непонятка. Стандарты говорят, что произвольно никто ничего поддерживать не желает. Тем не менее, вот в этом файле из приложения, есть очень неплохой вариант - режим 24, пригодный для подачи на цифровой интерфейс, а если внимательно присмотреться, то разделив частоту (и количество горизонтальных пикселей) на три получим знакомый нам 480x288, который легко адаптируется в 480x256 путём отсекания. Однако что меня смущает? Смущает тактовая частота пикселей 9 МГц. Потому что в исходном варианте CVT-RB частота 10 МГц. При этом общая длина строки 640 пикселей при 480 активных. Здесь же 576 пикселей.

В общем, пока в замешательстве, какой режим брать за основу, если целью пока является подача сигнала через аналоговый VGA-разъём, но с целью сохранить совместимость с древним уполовиненным TV (312 строк), но в перспективе вдруг получится зацепить HDMI
Что выбрать?

[Shaman]

ИМХО стоит смотреть всё-таки в сторону цифрового интерфейса, с заделом на будуще, для VGA интерфейсов хватает, но вот что с ними делать? Мониторов конечно осталось ещё уйма (более 30 лет существования стандарта  сделали своё дело), но он уже отмирает и почти не поддерживается. А с захватом вообще труба.
Вот для примера интересное решение для захвата сигнала со старых ПК с нестандартными сигналами.

[Slabovik]

Да я бы и рад сразу на цифру перелезть, да не могу. Скилл надо прокачивать. Ибо, как я вычитал, в цифровых интерфейсах минимальная пиксельная частота 25 МГц. Это довольно много для рассыпных микросхем, с которыми обычно имеем дело. Обычно для таких частот хардверную логику перекладывают уже на ПЛМ, а вот с ними я не умею работать, несмотря на наличие желания.

[Slabovik]

К сожалению, мои потуги в ПЛИС оканчиваются пока ничем. Грешным делом хотел даже курсы, но... подходящих дистанционных не нашёл.

Но попалась ссылка на интересный с данной точки зрения девайс: Видеокарта VGA для микроконтроллера и вторая часть статьи. Пусть будут здесь.

[Slabovik]

Наткнулся на интересные штуки.
Дисплей 480x272 с параллельным интерфейсом

Winstar_WF43VTIAEDNN0_480x272_TFT.pdf

Пока вроде ничего интересного. Но посмотрим на контроллер

ST7282_480x272_RGB.pdf

Сразу скажу, что смотреть можно со страницы 54 - там самое интересное.
Для ленивых скажу, что фишка в том, что этот RGB - обычный 24-битный параллельный интерфейс для динамического обновления изображения панели. Ну т.е. работает практически как телевизор - подаёшь поток кадров, разбитых на строки - изображение есть. Пиксельная частота от 9 до 12 МГц, а это значит, что можно эти индикаторы использовать в простых конструкциях, выполненных на рассыпухе. Для этого надо соорудить схему хранения изображения и её интерфейсы с контроллером и, собственно, дисплеем.

480x272 - это 130560 пикселей. Если взять по байту на пиксель (режим 256 цветов), то объём необходимой памяти совсем невелик - всего 128 килобайт. Даже если взять старый Z80 с тактовой 5МГц, принять (очень приблизительно), что на запись одного пикселя ему нужно от 6 до 10 тактов (очень сильно зависит от организации процедур, но стековые операции - это 10 тактов на 2 байта), то на заполнение экрана требуется 130560*0,2мкс= 156172 до 261120 мкс, т.е. от 0,15 до 0,26 секунды. В принципе, для всяких контроллеров мне видится приемлемым...

Да, приаттачил pdf-ку, там данные на контроллер другой конторы. У него основное отличие в другом фронте тактирования и синхримпульс ему нужен длительностью 1, а не 4. Всё остальное, как и у первого, может варьироваться в довольно широких пределах. Надо попробовать совместить/сопоставить с сигналами от самодельных бытовых ПК.

ОЗУ выполняет двоякую роль. Во-первых, это ОЗУ центрального процессора. У него доступ к нему должен быть немедленным (приоритетным) - это необходимо, чтобы исключить ожидание при коллизиях (обращению к ОЗУ более чем одного устройства одновременно).
Процессоры 8080/Z80 а также 8086 имеют особенность. К ОЗУ они обращаются не более одного раза за цикл, а циклы состоят из трёх-четырёх тактов, иногда и более. Т.е. между тактами, когда они обращаются к памяти, есть такты, в которых память может взаимодействовать с другими устройствами (экраном, ДМА).

Таким образом, экран должен получать данные для отображения каждых 4 или 8 пикселов (обычно принято . Попиксельно таскать не выйдет - нужна чрезмерно большая скорость.

Ещё одно условие, если процессор главный при доступе к памяти. Организуемые циклы памяти синхронизированы с тактами процессора. Если видеоконтроллер синхронизирован с этими тактами, то длительность показа пикселей между выборками из памяти должна составлять не менее двух тактов ЦП. Если не синхронизирован - более трёх (нужно для гарантированного перекрытия свободного цикла памяти при любом положении фронтов во времени).

Получается, для синхронизированного. Примем пиксельную частоту 10 МГц (просто для ровного счёта). 4 пикселя отображаются 400 наносекунд. Сюда должно войти 2 (3-4-5...) такта ЦП. Проще считать так: пиксельную частоту делим на пиксели за выбоку и умножаем на такты ЦП.
2 такта - это 10.4*2=5МГц тактовой частоты = 1/2 пиксельной частоты. При этом такт, он же цикл памяти, длится 200нс, что вполне комфортно.
Три такта - 7,5 МГц, 133 нс. Z80 вполне работоспособен. Синхронизировать не очень удобно, но решаемо.
Четыре такта - 10 МГц, 100 нс. Есть варианты, но надо уже применять скоростную логику и память, и если ОЗУ выборка обычно 70 нс, то с ПЗУ похуже.

Для несинхронизированного при 10 МГц пиксельной и 4 пикселях на выборку получается минимальная граница тактовой 7,5 МГц.
И Z80 и 8086 нужно брать не хуже 8-мегагерцовых версий.

А вот при 8 пикселях на выборку
10/8 *3=3,75 - 8080 с трудом, но пойдёт (изначально это 3-х мегагерцовые процы, но практика показывает, что небольшой оверклокинг допустим). 10 МГц пиксельной ведь тоже не обязательно, можно 9 (минималка для экранчиков).

В общем, самая плотная загрузка памяти - у Z80 в процессе 3-тактовых циклов. Из трёх тактов цикла один занимает ЦП. Второй - видео. Третий - а кто угодно (ДМА). Таким образом, скорость передачи через ДМА в пике может быть 1/3 тактовой ЦП, при 7,5 МГц это 2,5 мегабайта в секунду. Вполне ничего И... никто никому не мешает! 

Нарисовал 8-пиксельную выборку совмещённую с 5МГц Z80.
Времянки ЦП от 6-магагерцовой версии.



Поскольку 8pix - это достаточно редко, запрос VREQ создаётся только после загрузки пикселей в регистр вывода видео. Для 4-пиксельного варианта необходимо запрос делать уже на выводе последнего пикселя, иначе следующая порция пикселей опоздает.

Да, почему 4 пикселя либо 8?
Если цвет один (монохром) - выбирать можно байт. Это и будут 8 пикселей.
Если цвета 4 - в байт можно засунуть 4 пикселя.
Если цветов 16 - в байте только два пикселя. Для минималки в 4 пикселя нужна выборка сразу двух смежных байт. Т.е. шина данных памяти становится 16-битной.
Если цветов 256, то в одном байте только один пиксель. Для выборки 4-х пикселей нужно выбрать сразу 4 байта, а это 32 бита ширины.
В общем, чем шире данные памяти, тем сложнее сделать арбитраж с шиной данных ЦП. Дело не в самой сложности, но в количестве микросхем.
Поэтому мне видится достаточно интересным при Z80 применение 128-килобайтных микросхем параллельно 4 штуки и выборки по 4 пикселя. Если 8086 - 8 штук микросхем и выборки по 8 пикселей (а чего терять? Всё-равно мегабайт насобирать надо)