nedoPC.org

Electronics hobbyists community established in 2002
Atom Feed | View unanswered posts | View active topics It is currently 28 Mar 2024 05:14



Reply to topic  [ 59 posts ]  Go to page 1, 2, 3, 4  Next
Видеотерминал - немного мыслей 
Author Message
Doomed

Joined: 16 Mar 2002 17:00
Posts: 490
Reply with quote
Тема является продолжением темы микромашины Romanich'а, но решил выделить её в отдельную.

В процессе обдумывания различных идей, как-бы реализовать свой видеоконтроллер на кучке AVR'ов, я в итоге пришёл к нижеописанной идее. Т.к. я в теме генерации видеосигналов не особо разбираюсь, равно как и в построении схем на микроконтроллерах, я надеюсь, что мне объяснят, насколько идея разумна и реализуема.

Задача: реализовать тексто-подобный режим (байт в памяти отвечает за отображаемый символ 8x8 точек), с достаточно высоким разрешением (хотя-бы 256x192), с загружаемой графикой символов (но тут можно и ПЗУ использовать, конечно), и, так как придумывалось это для игровой системы, с кучей цветов - 256 на точку.

Понятно, что чисто программно AVR ни на 16, ни на 20 мгц, такое не потянет. Поэтому представляется такая схема (рисовать не стал, опишу на словах):

AVR типа Mega32 + внешняя SRAM (или ROM), в котором хранится графика символов. Минимум 16КБ (256 символов 8x8, байт на точку), можно и больше. Шина данных SRAM может вообще не подключаться к этому микроконтроллеру - через буфер идти к другому, который будет загружать туда графику, а может и подключаться - тогда загружать графику будет этот-же контроллер. Загрузка графики в процессе отображения невозможна. Карта символов хранится во внутренней памяти контроллера (32x24 - 768 байт). Шина данных SRAM также идёт сразу (ну или через буфер) на ЦАП - на сетке резисторов, RGB3-2-3 (а-ля Вектор 06Ц). Запрос данных из ОЗУ выполняется внешней схемой синхронизации (она-же генерирует кадровую и строчную синхру). Контроллер-же занимается чисто перебором адресов ОЗУ, выставляя в нужный момент времени нужный адрес. Правда, пока я не очень-то придумал, как засинхронизировать внешнюю синхру, и перебор адресов.

Шина адреса SRAM распределяется следующим образом:

NNNNNNNN NNYYYXXX

X - горизонтальная координата в символе; X - вертикальная; N - номер символа. Для ускорения выставления адресов можно YYYXXX завести на один порт, а NNNNNNNN (только 8 бит) - на второй.

Алгоритм перебора адресов:

В начале очередной строки выставляем биты YYY, на протяжении строки они не меняются. В начале строчки каждого символа выставляем его номер (т.е. одна строка в текстовом буфере проходится 8 раз для отображения строки символов). Дальше просто перебираются все значения XXX.

Если AVR работает на частоте 16мгц, мы имеем 16000000 тактов в секунду, 320000 в кадр. При разрешении 256x192 у нас 49152 точки, получаем 320000/49152 = 6 тактов на точку. Негусто. Но вроде можно уложиться. Выставление NNNNNNNN получается довольно долгое, я не уверен, что его можно уложить в 6 тактов, а вот перебор XXX уложится точно. Правда, я не учёл обратный ход луча, реально тактов ещё меньше. Но на 20мгц (вроде люди разгоняли?) можно получить 8t/точка, может поможет.

Да, при этой схеме можно также организовать попиксельный скролл в любую сторону, изменяя начальные значения для перебора. Данные в буфер текста можно подпихивать во время VBLANK.

Что скажете о такой идее?


28 Oct 2006 20:32
Profile
Doomed

Joined: 16 Mar 2002 17:00
Posts: 490
Reply with quote
Post 
Прикидки для Mega16 @16MHz (16-ая, т.к. она бывает в DIP40).

Подключение шины адреса SRAM: N (8 разрядов, 256 символов) - на PA0-7, YYY на PB0-2, XXX на PC0-2 (другие разряды порта C использовать будет нельзя)


Программа перебора адресов для строки будет выглядеть примерно так:

Code:
   ;начало строки
   
   ;r0 = номер строки пикселей в строке символов (0..7)
   ;r1 = номер пикселя в строчке пикселей символа (0..7)
   ;r2 = всегда равен 1
   ;r30:r31 = текущий адрес во внутренней RAM
   
   ;сначала надо модифицировать r30:31 нужным образом, чтобы установить на начало строки
   out PORTB,r0   ;1t - установили адрес текущей строки пикселей
   
   ;читаем код символа из буфера во внутренней RAM, и устанавливаем адрес символа
   ld r3,r30:r31+   ;2t
   out PORTA,r3   ;1t
   
   ;проход по символу (повторяется 32 раза за строку, если экран 256 точек в ширину)
   
   ;0 пиксель символа
   out PORTC,r1   ;1t
   ld r3,r30:r31+   ;2t
   ;1 пиксель символа
   out PORTC,r2   ;1t
   inc r1         ;1t
   inc r1         ;1t
   ;2..6 пиксель символа (повторить 5 раз)
   out PORTC,r1   ;1t
   inc r1         ;1t
   nop            ;1t
   ;7 пиксель символа
   out PORTC,r1   ;1t
   inc r1         ;1t
   out PORTA,r3   ;1t


Получаем минимум 3t на точку символа, при этом корректный адрес присутствует все 3t для первых 7 точек символа, и 2t для последней точки. По идее, на строку ТВ-растра у нас есть 1024 такта (320000/312.5), мы можем пройти за это время 340 точек, т.е. при 256 точках в ширину у нас остаётся ещё 256t. А если разогнать AVR до 20MHz, после прохода останется 512 тактов (1280t/строка). На HBLANK (где происходит коррекция r30:r31, и прочее для перехода на строку ниже) должно хватить. Вроде получается?


29 Oct 2006 07:25
Profile
Doomed

Joined: 16 Mar 2002 17:00
Posts: 490
Reply with quote
Post 
Есть буржуйский проект, аналогичный моей идее (но у них чисто растровая графика). Я знал о нём ещё до создания темы, но сама идея пришла ко мне всё-же до того, как я увидел их проект. Они там используют микросхему генератора синхросигналов ELM304 и кодер цвета AD724. Первая у нас вроде недоставаема, так что мне придётся ещё долго кумекать, чем её заменить. AD724 тоже не ширпотреб, но это мелочи, можно взять любую другую схему кодера цвета. Синхронизацию перебора адресов с синхросигналами видео они делают программо, видимо и в моей задумке это получится.

Выше описана только часть системы, создающая один слой фонового изображения. Реально таких блока может быть два, для реализации двух независимых слоёв фона. При этом перебиралка адресов по идее должна иметь возможность персонального назначения смещения фона для каждой строки растра (для реализации различных сканлайновых эффектов, типа параллакс-скролла). И ещё должен быть блок вывода спрайтов. С ним у меня проблемы, пока ничего лучшего, чем описанная в теме про Микромашину идея с двумя МК и двумя ОЗУ (с растровым буфером, один контроллер выводит - другой рисует/стирает спрайты), не придумалось. Слои в итоге должны накладываться схемой сравнения (это уже на рассыпухе) - если выставлен код, скажем, #FF - значит, этот пиксель этого слоя прозрачен. Также желателен ещё и блок палитры, хоть цветов и так много, но палитра позволяет делать кучу эффектов, которые без неё делать крайне сложно.

Остальная часть системы - главный МК, опять-же со своей RAM, управляющий всеми остальными, и выполняющий байт-код игровой программы; и отдельный МК синтезатора звука (вот он может быть и обойдётся без дополнительной памяти).

В целом система пока видится набором из 6 AVR'ов, 5 отдельных SRAM'ов (6, если будет палитра), и минимальным количеством рассыпухи. Вроде не так уж и монструозно для любительской конструкции - в том-же РК корпусов наверняка побольше будет;)

Только не говорите мне о том, каким гемороем будет синхронизация такой кучи МК и написание управляющих программ для них:)


29 Oct 2006 20:57
Profile
Banned

Joined: 12 Oct 2006 16:44
Posts: 608
Reply with quote
Post 
Это сделать можно, но через большие усилия!
Главная трудность в формировании ТОЧНОГО видеосигнала программой микроконтроллера(VSync,HSync,Color).

Можно поступить хитро - часть сигналов (VSync,HSync) реализовать на мелкой логике (генераторы+кварцы+делители). Тогда остается только цветовую составляющую гнать контроллером...


29 Oct 2006 21:21
Profile
Doomed

Joined: 16 Mar 2002 17:00
Posts: 490
Reply with quote
Post 
Romanich wrote:
Это сделать можно, но через большие усилия!

Не спорю, проект крайне гемморойный.

Romanich wrote:
Главная трудность в формировании ТОЧНОГО видеосигнала программой микроконтроллера(VSync,HSync,Color).

Можно поступить хитро - часть сигналов (VSync,HSync) реализовать на мелкой логике (генераторы+кварцы+делители). Тогда остается только цветовую составляющую гнать контроллером...

Видимо, ты не особо читал, что я написал:) Я не предлагаю генерировать на МК полный видеосигнал, как это делается в большинстве любительских проектов подобного типа. А предлагаю как раз именно то, что ты и описал - сихронизация формируется внешней схемой (можно, конечно, и эту часть на отдельном МК сделать, типа 2323, для уменьшения кол-ва элементов); а МК конкретно этого слоя фоновой графики только перебирает адреса ОЗУ с графикой, т.е. гонит цвета каждой точки, выставляя в нужные моменты времени соответствующий текущему положению луча адрес точки в ОЗУ.


29 Oct 2006 21:40
Profile
Banned

Joined: 12 Oct 2006 16:44
Posts: 608
Reply with quote
Post 
Shiru Otaku wrote:
...Но на 20мгц (вроде люди разгоняли?) можно получить 8t/точка,
может поможет....
Что скажете о такой идее?


По моему опыту ATmega128-16AI уверенно гонится на
24МГц, ATmega8535-16PI гонится до 21-22 МГц

Ма ло того, запускал ATmega128-16AI на частоте 49МГц - жутко тормозило... :(

Если не нравица разгон - есть ATtiny2313-20PI - он официально
работает на 20МГц. Хотя у него ножек меньше, чем у Меги, но для формирования сигналов думаю хватит...

Так что в принципе запас до 24МГц у тебя есть :wink:


29 Oct 2006 22:19
Profile
Banned

Joined: 12 Oct 2006 16:44
Posts: 608
Reply with quote
Post 
AVR'ы могут обращаться к внешней памяти через интерфейс XMEM минимум за три такта. Обращение ко внутренней - за два


29 Oct 2006 23:38
Profile
Doomed

Joined: 16 Mar 2002 17:00
Posts: 490
Reply with quote
Post 
Romanich wrote:
AVR'ы могут обращаться к внешней памяти через интерфейс XMEM минимум за три такта. Обращение ко внутренней - за два

Спасибо, я в курсе.

Попробуй внимательно прочесть то, что написано выше. Нет никаких обращений к внешней памяти.


30 Oct 2006 00:43
Profile
God
User avatar

Joined: 29 Dec 2003 01:00
Posts: 1101
Location: Москва
Reply with quote
Post 
Shiru Otaku wrote:
Romanich wrote:
AVR'ы могут обращаться к внешней памяти через интерфейс XMEM минимум за три такта. Обращение ко внутренней - за два

Спасибо, я в курсе.

Попробуй внимательно прочесть то, что написано выше. Нет никаких обращений к внешней памяти.

Ширу я так понял ты хочешь вформировать принцип заложенный в ZX-NEXT, где проц занимался формированием адресов памяти и построением сигналов синхронизации..?


30 Oct 2006 01:34
Profile ICQ WWW
Doomed

Joined: 16 Mar 2002 17:00
Posts: 490
Reply with quote
Post 
CHRV wrote:
Ширу я так понял ты хочешь вформировать принцип заложенный в ZX-NEXT, где проц занимался формированием адресов памяти и построением сигналов синхронизации..?

Ну, насколько я знаю (а знаю я совершенно неточно), в ZX-Next этот второй проц формировал только адреса знакомест или чего-то типа, вобщем не точек. Но что-то похожее, да.

Кто-бы мне объяснил подробно, как должны выглядеть эти самые сигналы синхронизации (я более-менее представляю, но уверенности в правильном понимании нет), и как они соотносятся со сменой информации на RGB-выходе видеоконтроллера..


30 Oct 2006 02:00
Profile
Doomed

Joined: 16 Mar 2002 17:00
Posts: 490
Reply with quote
Post 
Почитал ещё немного доки, поизучал схемы.. Новые прикидки.

На 16мгц у нас 1024t/строка, на 20мгц - 1280t/строка. На каждую точку мы тратим 3t.

Длительность строки 64мкс, длительность строчного синхроимпульса 4мкс, и ещё 4 мкс пустых, дальше до конца строки могут идти точки.

Для 16мгц:

64t синхроимпульс, 64t пустые. Дальше остаётся 1024-128=896t. 896/3 = можно отобразить максимум 298 точек в строке. Т.е. реально получить горизонтальное разрешение в 256 точек, и при этом можно заставить этот-же контроллер генерировать синхроимпульсы (времени останется достаточно для всех требуемых операций).

Для 20мгц:

80t синхроимпульс, 80 пустые. 1280-160=1120/3 = можно отобразить максимум 373 точки в строке. Т.е. реально получить горизонтальное разрешение в 320 точек.

Вроде всё верно?


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


30 Oct 2006 02:50
Profile
Doomed

Joined: 16 Mar 2002 17:00
Posts: 490
Reply with quote
Post 
Подумалось, что ATMega16 мне не хватит, из-за объёма внутренней памяти, так что переориентируюсь на Mega32.

Предположим, что работать оно будет на 20мгц, для получения разрешения 320x??? (скажем, 224). Минимальный объём 'текстового' буфера должен быть 40*28=1120 байт. А это уже больше, чем 1К (при 256x192 минимальный буфер влез-бы и в 1К). Для реализации скролла без видимого появления новых строк нужно буфер сделать чуть больше отображаемого. Пусть будет 42x30=1260 байт. Также, я хочу иметь возможность задавать каждой строке персональное смещение. Т.к. экран шире одного байта - надо 3 байта на строку, 224*3=672 байта. 1260+672=1932 байта, и остаётся немного для своих нужд программы МК.

Предполагается, что эти 1932 байта будут пересылаться в момент вертикального обратного хода луча и VBLANK, наверное, из-за нехватки выводов, по SPI (а хватит-ли её скорости?).

А можно использовать вместо Mega644 - она штатно поддерживает 20мгц, у неё 4кб памяти (что очень пригодится, если я захочу сделать набор символов >256), и тоже бывает в DIP (для меня актуально).


Last edited by Shiru Otaku on 30 Oct 2006 20:02, edited 1 time in total.



30 Oct 2006 09:59
Profile
Banned

Joined: 12 Oct 2006 16:44
Posts: 608
Reply with quote
Post 
Shiru Otaku wrote:
А можно использовать вместо ATMega32 Mega644 - она штатно поддерживает 20мгц, у неё 4кб памяти (что очень пригодится, если я захочу сделать набор символов >256), и тоже бывает в DIP (для меня актуально).


Хе-хе... А может вапще юзать AT91RM9200 на 180МГц и не парица с тактами? Иль взять норамльный VDP от Epson S1D13506 с 16bpp 800x600 и 2D-акселератором :wink:


30 Oct 2006 19:53
Profile
Banned

Joined: 12 Oct 2006 16:44
Posts: 608
Reply with quote
Shiru Otaku wrote:
Тема является продолжением темы микромашины Romanich'а, но решил выделить её в отдельную.


Продолжением это никак не может быть :cry:
Экран не графический...
Машина, сделанная мной не содержит "софтварных резинок",
её принципы держатся в основном на железе (это касаеца Графики и Звука)

Для ликбеза - "софтварная резинка" - это программная реализация чего-либо существующего в железе


30 Oct 2006 19:59
Profile
Doomed

Joined: 16 Mar 2002 17:00
Posts: 490
Reply with quote
Post 
Romanich wrote:
Хе-хе... А может вапще юзать AT91RM9200 на 180МГц и не парица с тактами? Иль взять норамльный VDP от Epson S1D13506 с 16bpp 800x600 и 2D-акселератором


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

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

А так - конечно, можно много чего взять...


30 Oct 2006 19:59
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 59 posts ]  Go to page 1, 2, 3, 4  Next

Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.