Re: Нестандартные режимы отображения
Вполне. Не удивлюсь что еще и цветное.
Кажется точно для чего-то внешнего, ведь агатовский ДК не смог бы потянуть 512х512 даже в монохроме?
- garnizon
- Участник
- Неактивен
Re: Нестандартные режимы отображения
ДК пришлось бы переделывать.
Чтобы показать 512 строк при чересстрочной развертке нужно, чтобы ДК формировал правильные полукадры - по 312,5 строк. В Агате строк ровно 312, поэтому при попытке выводить разные полукадры строчки второго налепятся поверх строчек первого, вместо того чтобы рисоваться между ними.
- Voldemar0
- Участник
- Неактивен
Re: Нестандартные режимы отображения
Ставим два телека, заводим на них одинаковую синхру, а видеосигнал делим на два + два бита. Первые два на один телек, вторые два - на другой.
Получаем удвоение площади или разрешения и 4 оттенка серого (или 4 возможных цвета) на каждый телек.
Только кинескопы прижать друг к другу.
- AlexBel
- Участник
- Неактивен
Re: Нестандартные режимы отображения
А можно два "Агата" поставить рядом - будет не только удвоение площади картинки, но и два честных процессора, два дисковода и два пользователя. Или один, но шустрый :)
Не удержался :)
- garnizon
- Участник
- Неактивен
Re: Нестандартные режимы отображения
Voldemar0 пишет:
Получаем удвоение площади или разрешения и 4 оттенка серого (или 4 возможных цвета) на каждый телек.
.
Это как?
31 18-03-2021 11:10 Отредактировано Voldemar0 (18-03-2021 11:12)
- Voldemar0
- Участник
- Неактивен
Re: Нестандартные режимы отображения
> А можно два "Агата" поставить рядом - будет не только удвоение площади картинки, но и два честных процессора, два дисковода и два пользователя. Или один, но шустрый :)
В этом случае их надо как-то синхронизовать по операциям, чтобы картинки менялись совместно.
> Это как?
Ну если ты два моника одновеменно подключишь к компу- у тебя будет одинаковое изображение на двух.
А теперь представь, что, например, синие точки показывает только правый моник, а зелёные - левый.
А если вывести голубую точку, то она будет видна на обеих мониках - на одном как синяя, на другом - как зелёная.
Ну или пусть моники будут ч/б : вывел синюю - она на левом как белая видна, вывел зелёную - она на правом видна как белая. Вывел голубую - на обеих мониках белые точки в этой позиции.
Получается, что у тебя два монитора, каждый, например, 256x256. Но их два - получается 512x256.
Цветов меньше, но разрешение больше.
Также как текст 32x32 - цветной, но только 32 символа в строке и 64x32 - ч/б, зато символов больше.
32 16-05-2021 00:15 Отредактировано garnizon (16-05-2021 00:16)
- garnizon
- Участник
- Неактивен
Re: Нестандартные режимы отображения
LeoN пишет:
avivanov76 пишет:и порядок строк такой же, как в ЦГВР: нечетные строки из первых 8 кб, четные - из вторых.
Вероятно, наоборот.
Но PAR получится 8:3, что очень, ИМХО, коряво...
А можете сформулировать какой порядок строк и т.д. (т.е. вот максимально подробно) должен быть у возможных режимов:
512x256 4 цвета
256х256 16 цветов
Т64 цветной
- garnizon
- Участник
- Неактивен
Re: Нестандартные режимы отображения
Все вымерли :)
Re: Нестандартные режимы отображения
Не вымерли, просто на этот вопрос нельзя дать точный ответ. Потому что нет возможности влезть в мозг разработчикам девятки и узнать, как они планировали расширение возможностей.
С режимом 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 не требуют выдумывать какие-то сложности с адресами ради экономии вентилей. Для новых режимов удобнее всего было бы последовательное расположение адресов.
- garnizon
- Участник
- Неактивен
Re: Нестандартные режимы отображения
Просто подумал что есть какие-то мысли или четкие предположения, когда это прочитал:
avivanov76 пишет:
Вот если бы в Агат поставить К565РУ5Б, у которой время обращения 230 нс, и вдвое увеличить частоту чтения памяти, то тогда можно было бы сделать еще пару режимов:
1) 128 байт/строку
2) эппловый 80 байт/строкуТогда реально было бы сделать вот эти режимы:
- 512х256 4 цвета
- 256х256 16 цветов
- Т64 цветной
Voldemar0 пишет:
Рано или поздно я доберусь и до этой темы ;) Но не в этом году.
- Voldemar0
- Участник
- Неактивен
Re: Нестандартные режимы отображения
> Рано или поздно я доберусь и до этой темы ;) Но не в этом году.
?? Я вроде такого в этой теме не писал.
Re: Нестандартные режимы отображения
garnizon пишет:
Просто подумал что есть какие-то мысли или четкие предположения, когда это прочитал:
Ну сначала-то вопрос звучал так:
garnizon пишет:
В некоторых темах на форуме упоминалось что для отображения более крупных режимов агату не хватает быстродействия.
А вот как реально разгон агата может это изменить?
Разгон действительно нужен для поддержки режимов с 128 байт на строку. Иначе ДК не сможет получать данные в нужном темпе. Без разгона нет смысла даже и пытаться делать такие режимы (на самом деле про варианты без разгона я думал, и они есть, но в схеме придется изменять вообще все, и совместимость с обычным Агатом будет еще хуже).
Но разгон - это только половина дела, сам ДК в девятке тоже не готов к режимам с 128 байт на строку.
Voldemar0 пишет:
?? Я вроде такого в этой теме не писал.
А тут писал, правда про DMA :) Мне, кстати, тоже не очень нравится, что обсуждение режимов "разъехалось" по двум темам.
- Voldemar0
- Участник
- Неактивен
Re: Нестандартные режимы отображения
> А тут писал, правда про DMA :) Мне, кстати, тоже не очень нравится, что обсуждение режимов "разъехалось" по двум темам.
Не, там речь у меня совсем о другом: не о разрешении вывода, а о том, чтобы именно ускорить операции с памятью в разных местах. Скорость скроллинга видео, скорость копирования кусков памяти ....
-
А в этой теме я не пойму, что обсуждается: если то, как разработчики агата хотели сделать больше, выше и лучше - то гадать я не любитель и DMA тут явно ни при чём. Если же речь о том, как сейчас можно сделать внешний модуль ДК с HD-Video шахматами, барышнями и displayport, то тут вариантов много и я даже не соглашусь, что это непременно требует более высокой скорости шины: можно просто перехватывать запись в базовое ОЗУ и иметь хоть мегабайт озу на внешнем ДК и пусть даже оно обновляется ЦП медленно, но отображать -то его можно будет в реальном времени. Или работать с мелким объёмом озу (хоть набортном агата, хоть на своём, но сделать какую-то дикую механнику компрессии - типа, яркость отдельно, цвета - отдельно (a'la SECAM).
39 22-06-2021 18:17 Отредактировано Voldemar0 (22-06-2021 18:29)
- Voldemar0
- Участник
- Неактивен
Re: Нестандартные режимы отображения
Насчёт компрессии текстового режима, вдруг вспомнил, мож кому пригодится:
Игрался я когда-то с микрухой stv9425.
Это OSD-контроллер. Как бы дисплейный контроллер, но только у него синхро не выходит наружу, а - наоборот - входит из внешнего источника. Т.е. картинку OSD можно наложить на другой видеосигнал.
Интерфейс у него был i2c и ниакого другого. И 1 Кб ОЗУ.
Но этот 1 Кб использовался очень занятно: он был насквозь векторный.
Т.е. сперва идёт вроде вектор на таблицу строк. В таблице строк вектора, указывающие на буфер строки (т.е. они сопоставляют физическую строку на экране строке в видеопамяти). Где-то там ещё вектора на матрицы загружаемых символов (т.е. бОльшая часть прошита в ПЗУ, но есть несколько символов, которые можно самому задавать). Где-то там ещё были настройки расстояния между строк, размера символов и ещё много разного. Т.е. получалось, что как бы строго, например 32x32 цветных символа не выведешь, но гибкость и скорость модификации картинки может быть очень высокой и изобразить что-то вроде экрана с как бы 32x32 (а может и больше даже) можно легко.
Например, не надо тебе в конце конкретной строки символы, сойдут и пробелы: просто выделяешь под эту строку память не 32 байта, а меньше. Последний символ ставишь EOL - и контроллер дальше пробелы рисует, а ты несколько байт озу сэкономил. Или надо тебе несколько одинаковых строк ('--------' например): просто делаешь одну такую строку в видеоозу, а векторами указываешь на неё несколько раз для разных физических строк.
У этой микры даже никак и не декларировалось разрешение ни в символах ни в пикселях, поскольку можно было что угодно накрутить в одном месте, пожертвовав другим местом. А полная полоса pixrate у неё вроде бы 50 МГц, что ли ... 15 лет назад это было.