На поиск и установку шрифтов в первый раз ушло совсем не много времени: очень помогла статья про русификацию старинных EGA адаптеров, в суть я особо не вчитывался, сразу в глаза бросилась табличка соответствия бинарных кодов буковкам и спец символам, вид примерно следующий:
{0x7E,0x81,0xA5,0x81,0xBD,0x99,0x81,0x7E},
Таким образом, описываются шрифты в системах, где каждый символ занимает 8 на 8 пикселей: так 0х7Е, это верхняя строчка значка или буковки, в бинарном представлении: 01111110, где 1ки означают что точка должна быть белая а 0 черный, ну и далее по строчкам
Русская буква "а" будет представлена в виде
{0x30,0x78,0xCC,0xCC,0xFC,0xCC,0xCC,0x00}
| 
{0xFC,0x66,0x66,0x7C,0x66,0x66,0xFC,0x00}
| 
{0x3C,0x66,0x6E,0x7E,0x76,0x66,0x66,0x00}
|
Ну а дальше мы можем отвести кусок внутренней памяти МК, достаточного размера и задать начальную точку, с которой начнем штамповать буковки, собственно это и есть процесс заполнения видеопамяти.
Бегающий текст.
На этом этапе уже есть возможность выводить статический текст на экран, начиная с нужной точки, теперь появилось желание этот текст как-нибудь закрутить по-хитрому. Очевидно, что нужно постепенно менять точку, с которой текст начинает печататься в видеопамять, и из этой новой точки заставить программу заново повторить операцию заполнения видеопамяти битами, из которых состоят шрифты.
Аналогичные процессы пересчета содержимого видеопамяти происходят и в обычном ПК, когда требуется поменять содержимое экрана, однако есть некоторые нюансы: дешевые микроконтроллеры неспособны просчитать всю видеопамять за короткое время, попытки реализовать такой алгоритм привели к довольно большим задержкам процесса обновления экрана. Из-за того что один и тот же процессор отвечает за пересчет видеопамяти и вывод ее построчно на сдвиговые регистры - страдают обе эти операции, а задержка вывода строчек приводит к увеличению времени показа каждой, и глаза начинают видеть неприятные мерцания всей матрицы. Если же времени не хватает совсем, то глаз видит не всю матрицу целиком, а только одну горящую строчку в каждый момент времени, пробегающую сверху вниз.
|
|
В ПК такой проблемы не может быть в принципе, т.к за просчет видеопамяти и ее свежее наполнение отвечает ЦП, а за вывод на экран монитора видеокарта. С одной стороны никто не мешает повторить эту же архитектуру и в "бегущей строке", однако это привело бы к удорожанию всей платы контроллера матрицы. Однако, ввиду того, что набор задач, решаемых МК табло довольно ограничен, и сводится к простому выводу текста, эта проблема как правило решается построчным просчетом видеопамяти.
Просчет изменений одной строчки занимает совсем небольшое время, которое как раз можно отвести под ее же вывод на матрицу (дать погореть немного), затем можно переключаться к следующей. Хотя данный алгоритм действий может серьезно варьироваться в зависимости от применяемого МК. Как уже сказал в начале, данная разработка несколько устарела, отчасти потому что в ней был применен КМ AVR mega128, в свое время довольно функциональный, но его вычислительная мощь в 16Мгц, не достаточна для применения других алгоритмов для этой задачки, хотя можно было бы решить и асинхронным просчетом видеопамяти и отображению по разным таймерам.
Наверное многие заметили, что в табличках бегущая строка, в процессе прокрутки текста появляется некоторый, ели заметный наклон букв (как-будто они написаны курсивом). Этот эффект как раз и появляется из-за того, что видеопамять и отображение это асинхронные процессы, и если видеопамять просчитывается сверху вниз, то верхняя часть уже сдвинулась по алгоритму прокрутки куда хотелось, а снизу отображаются еще данные предыдущего такта просчета.
|
|
В целом про эффекты движения текста писать особо нечего, это простенькая программисткая задачка.