Игрался я когда-то с микрухой stv9425.
Это OSD-контроллер. Как бы дисплейный контроллер, но только у него синхро не выходит наружу, а - наоборот - входит из внешнего источника. Т.е. картинку OSD можно наложить на другой видеосигнал.
Интерфейс у него был i2c и ниакого другого. И 1 Кб ОЗУ.

Но этот 1 Кб использовался очень занятно: он был насквозь векторный.
Т.е. сперва идёт вроде вектор на таблицу строк. В таблице строк вектора, указывающие на буфер строки (т.е. они сопоставляют физическую строку на экране строке в видеопамяти).  Где-то там ещё вектора на матрицы загружаемых символов (т.е. бОльшая часть прошита в ПЗУ, но есть несколько символов, которые можно самому задавать). Где-то там ещё были настройки расстояния между строк, размера символов и ещё много разного. Т.е. получалось, что как бы строго, например 32x32 цветных символа не выведешь, но гибкость и скорость модификации картинки может быть очень высокой и изобразить что-то вроде экрана с как бы 32x32 (а может и больше даже) можно легко.
Например, не надо тебе в конце конкретной строки символы, сойдут и пробелы: просто выделяешь под эту строку память не 32 байта, а меньше. Последний символ ставишь EOL - и контроллер дальше пробелы рисует, а ты несколько байт озу сэкономил. Или надо тебе несколько одинаковых строк ('--------' например): просто делаешь одну такую строку в видеоозу, а векторами указываешь на неё несколько раз для разных физических строк.

У этой микры даже никак и не декларировалось разрешение ни в символах ни в пикселях, поскольку можно было что угодно накрутить в одном месте, пожертвовав другим местом. А полная полоса pixrate у неё вроде бы 50 МГц, что ли ... 15 лет назад это было.

Не, там речь у меня совсем о другом: не о разрешении вывода, а о том, чтобы именно ускорить операции с памятью в разных местах. Скорость скроллинга видео, скорость копирования кусков памяти ....

-

А в этой теме я не пойму, что обсуждается: если то, как разработчики агата хотели сделать больше, выше и лучше - то гадать я не любитель и DMA тут явно ни при чём. Если же речь о том, как сейчас можно сделать внешний модуль ДК с HD-Video шахматами, барышнями и displayport, то тут вариантов много и я даже не соглашусь, что это непременно требует более высокой скорости шины: можно просто перехватывать запись в базовое ОЗУ и иметь хоть мегабайт озу на внешнем ДК и пусть даже оно обновляется ЦП медленно, но отображать -то его можно будет в реальном времени. Или работать с мелким объёмом озу (хоть набортном агата, хоть на своём, но сделать какую-то дикую механнику компрессии - типа, яркость отдельно, цвета - отдельно (a'la SECAM).

Просто подумал что есть какие-то мысли или четкие предположения, когда это прочитал:

Ну сначала-то вопрос звучал так:

Разгон действительно нужен для поддержки режимов с 128 байт на строку. Иначе ДК не сможет получать данные в нужном темпе. Без разгона нет смысла даже и пытаться делать такие режимы (на самом деле про варианты без разгона я думал, и они есть, но в схеме придется изменять вообще все, и совместимость с обычным Агатом будет еще хуже).

Но разгон - это только половина дела, сам ДК в девятке тоже не готов к режимам с 128 байт на строку.

А тут писал, правда про DMA :) Мне, кстати, тоже не очень нравится, что  обсуждение режимов "разъехалось" по двум темам.

?? Я вроде такого в этой теме не писал.

С режимом 128x256 все проще. Он хорошо ложится на существующее железо, и все, что надо изменить - это увеличить размер страницы до 16 Кбайт. Как это сделать - тоже понятно, режимы с таким размером страницы есть (МГДП, ЦГВР). И порядок строк просто берется такой же, как у них.

А вот режимы 512x256 4 цвета, 256х256 16 цветов, Т64 цветной - совершенно новые. Они требуют от ДК темп чтения из памяти 128 байт на строку и 2 новых размера страницы - 32 Кбайт для графических режимов и 4 Кбайт для текстового. Схема ДК девятки под это не рассчитана.

Например, горизонтальный счетчик ДК содержит всего 6 разрядов. 5 используются для формирования адреса, 6-й разряд нужен для формирования гасящего и синхронизирующего импульсов. При чтении со скоростью 128 байт на строку понадобится еще один разряд. Его негде взять - у ПЗУ D61 все выходы заняты.

Но основная головная боль с добавлением режимов в ДК девятки - это их переключение. В каждом режиме адреса формируются по разному. В переключении режимов участвует множество микросхем. Я тут взял кусочек таблицы 14 из описания девятки и прикинул, кто за что отвечает при переключении.

+--------+--------+--------+--------+--------+--------+--------+------------------------+
| Разряд |  Т32/  |  ЦГСР  |  МГВР  |  ЦГВР/ |   Т40  |   HGR  | Режимы каких м/сх      |
| адреса |  Т64   |        |        |  МГДП  |        |        | меняются               |
+--------+--------+--------+--------+--------+--------+--------+------------------------+
|   A1   |   H1   |   H1   |   H1   |   H1   |   H1   |   H1   |  D61                   |
|   A2   |   H2   |   H2   |   H2   |   H2   |   H2   |   H2   |  D61                   |
|   A3   |   H3   |   H3   |   H3   |   H3   |   S0   |   S0   |  D61 + D62 + D73       |
|   A4   |   H4   |   H4   |   H4   |   H4   |   S1   |   S1   |  D61 + D62 + D73       |
|   A5   |   H5   |   H5   |   V0   |   H5   |   S2   |   S2   |  D61 + D62 + D73       |
|   A6   |   V3   |   V1   |   V1   |   V1   |   S3   |   S3   |  D62 + D75 + D28 + D29 |
|   A7   |   V4   |   V2   |   V2   |   V2   |   V3   |   V3   |  D63                   |
|   A8   |   V5   |   V3   |   V3   |   V3   |   V4   |   V4   |  D62                   |
|   A9   |   V6   |   V4   |   V4   |   V4   |   V5   |   V5   |  D62                   |
|   A10  |   V7   |   V5   |   V5   |   V5   |    1   |   V0   |  D62 + D63 + D75       |
|   A11  | ЭПС0   |   V6   |   V6   |   V6   |    0   |   V1   |  D63 + D75             |
|   A12  | ЭПС1   |   V7   |   V7   |   V7   |    0   |   V2   |  D63 + D75             |
|   A13  |  ЭС0   |  ЭС0   |  ЭС0   |   V0   |    0   |    1   |  D88                   |
|   A14  |  ЭС1   |  ЭС1   |  ЭС1   |  ЭС1   |    0   |    0   |  D28 + D29             |
|   A15  |  ЭС2   |  ЭС2   |  ЭС2   |  ЭС2   |    0   |    0   |  D28 + D29             |
|   A16  |  ЭС3   |  ЭС3   |  ЭС3   |  ЭС3   |    0   |    0   |  D28 + D29             |
+--------+--------+--------+--------+--------+--------+--------+------------------------+

Hx - выходы горизонтального счетчика адреса, Vx - выходы вертикального счетчика адреса, Sx - выходы эпплового сумматора адресов, ЭС, ЭПС - выходы регистра управления ДК.

Режимы переключаются выбором нужной части прошивки ПЗУ либо переключением мультиплексора. И если прошивки ПЗУ можно менять и добавлять туда режимы (хотя не во всех ПЗУ для этого есть место), то у мультиплексоров все входы и выходы заняты.

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

Разработчики девятки старались максимально сократить число микросхем. Кроме того, не все типы микросхем им были доступны. В результате режимы МГДП и ЦГВР они добавили каким-то обходным путем, сделав чересстрочность, хотя было бы намного удобнее, если бы адреса шли последовательно. А если бы они тогда, в 90-е, стали делать видеостраницы на 32 Кбайт, то наверняка раскидали бы адреса еще хитрее.

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

С другой стороны, поскольку режимы совсем новые, можно махнуть рукой и не думать про правильность. Современные CPLD/FPGA не требуют выдумывать какие-то сложности с адресами ради экономии вентилей. Для новых режимов удобнее всего было бы последовательное расположение адресов.

avivanov76 пишет:

и порядок строк такой же, как в ЦГВР: нечетные строки из первых 8 кб, четные - из вторых.

Вероятно, наоборот.
Но PAR получится 8:3, что очень, ИМХО, коряво...

А можете сформулировать какой порядок строк и т.д. (т.е. вот максимально подробно)  должен быть у возможных режимов:

512x256 4 цвета

256х256 16 цветов

Т64 цветной

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

> Это как?

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

Получается, что у тебя два монитора, каждый, например, 256x256. Но их два - получается 512x256.
Цветов меньше, но разрешение больше.

Также как текст 32x32 - цветной, но только 32 символа в строке и 64x32 - ч/б, зато символов больше.

Получаем удвоение площади или разрешения и 4 оттенка серого (или 4 возможных цвета) на каждый телек.
.

Это как?

Кажется точно для чего-то внешнего, ведь агатовский ДК не смог бы потянуть 512х512 даже в монохроме?