Стандартизация принципов развития видеопроцессора

[Black_Cat]

Стандартизация принципов развития видеопроцессора.

Спектрум на 90% – это видеопроцессор. И не удивительно, что основные критерии, определяющие компьютер как «Спектрум» – это параметры видеопроцессора.

Основными параметрами видеопроцессора являются:
- структура построения экрана и разрешение экранной области;
- структура отображения цветов и количество цветов;
- частота кадров и строк;

1.0 Структура построения экрана и разрешение экранной области.

Структура экранной области ZX Spectrum - довольно своеобразна. Можно выделить два критерия оценки структуры экранной области ZX Spectrum - оценка по внешней форме и оценка по внутреннему содержанию. Оценка по внешней форме предполагает критерием - подобность внешних размеров и взаимных соотношений. Оценка по внутреннему содержанию предполагает критерием - подобность внутренней структуры.
Оценка развития ZX экрана по критерию подобности внешних размеров и взаимных соотношений предполагает соблюдение кратности размера объёма памяти экранных областей и их начальных адресов, а так-же соблюдения пропорциональности относительного размещения их частей (растровой и атрибутной областей) в адресном пространстве, а кроме того предполагает соблюдение кратности визуальных параметров изображения - вертикального и горизонтального раразрешения и соотношения сторон.
Оценка развития ZX экрана по критерию подобности внутренней структуры предполагает деление его на три области, внутри каждой из которых используется одинаковый цикл формирования изображения. Отсюда можно сделать вывод, что минимальным неделимым дискретом в структуре экрана является его треть. Следовательно, при масштабируемом изменении пропорций экранной области, одним из условий совместимости должна быть кратность третям ZX экрана. Это условие автоматически формирует сетку допустимых разрешений при использовании эволюционного масштабирования:
- вертикальных: 192, 256, 320, 384, 448, 512, 576, 640, 704, 768 и т.д.
- горизонтальных: 256, 512, 768, 1024 и т.д.

1.1 Ограничение на пропорциональность масштабироания.

Если полученную сетку допустимых разрешений оценить с точки зрения кратности масштабирования по объёму ОЗУ экранной области (но не более объёма страницы памяти принятой в ZX Spectrum, т.е.16k), то получим следующую сетку экранных разрешений:
- 256х192(6k), 384х256(12k);
Ежели же полученную сетку допустимых разрешений оценить с точки зрения пропорциональности масштабирования по обеим координатам, то получим следующую сетку экранных разрешений:
- 256х192, 512х384, 768х576, 1024х768 и т.д.
Правомерно ли наложение условия пропорциональности масштабирования?
И да, и нет - в зависимости от преследуемых целей. Например, работа с такой неотъемлемой частью ZX, как встроенный BASIC предполагает пропорциональное масштабирование, без которого невозможно использование его стандартных графических функций. Работа с текстом накладывают совсем другие требования, здесь общепринятым стандартом является 40/80 символов в строке, при этом матрица знакоместа символов может быть любой удовлетворяющей этому условию (например 6х8). Таким образом, исходя из назначения, полученную сетку разрешений можно условно разделить на «графические» (пропорциональные) и «текстовые» (40/80 символьные) режимы*.

* Внимание!! Деление на «графические» и «текстовые» режимы - условно, т.к. по способу формирования изображения видеопроцессором ZX Spectrum, все режимы - графические.

1.2 Ограничение по стандартам видеоразвёрток.

Ещё одним ограничением, накладываемым телевизионным стандартом видеоразвёртки, является 312 строк в кадре при прогрессивной развёртке (телевизионный стандарт - 312,5 при чересстрочной). Наложение этого условия ограничивает сетку разрешений по вертикали при воспроизведении на телевизоре и CGA мониторе следующими режимами:
- графические: 256х192, 384x256;
- текстовые: 256х192, 384x256, 512х192, 512х256;

1.3 Есть ли жизнь за 312 строками? Ограничение по частоте кадров.

С точки зрения технической реализации – это возможно, хотя и имеются определённые ограничения. Рассмотрим их.

1) Миф №8: «Священная корова Nemo».

«Spectrum - это телевизор и только телевизор как устройство отображения» 26.11.98 © Nemo
«Spectrum изначально (т.е. как концепция, идеология) проектировался под TV. Это основа. Подключение дисплея к Spectrum'у абсурдно. Это противоречит всей логике архитектуры. Это не спектрумовский Spectrum. Это тупиковый путь. Он ведет в никуда. От TV-экрана нельзя отказываться. Это и есть Spectrum.» 21.05.99 © Nemo

Cпектрум действительно разрабатывался исключительно под телевизор, но... четверть века назад. А в 2012 году на территории России вещание для телевизионных приёмников, на работу с которыми был рассчитан ZX – будет полностью прекращено. С 2006 года ввоз импортных аналоговых телеприёмников в Россию запрещён. Расчётное проектное время эксплуатации бытовой техники ~6 лет. Уже давно ремонт 6 летнего телевизора дороже покупки б/у, то же и с CGA, EGA и VGA ЭЛТ мониторами - их не ремонтируют, их выбрасывают. Это не значит конечно, что тысяча «реальщиков» не смогут найти себе телевизор, это значит другое - что простой обыватель никогда впредь не купит ZX, т.к. у него в квартире его не к чему будет подключить, а курочить для этого новенький цифровик, сейчас даже в ателье не возьмутся.
Выводы:
- любые исторически сопряжённые во времени постулаты имеют смысл только в историческом контексте;
- аналоговое телевидение – это уже прошедшая история;
- ZX, только с аналоговым телевизором в качестве монитора – мёртвая конструкция без будущего.

2) Ограничение по частоте кадров.

Есть ли доступная замена аналоговому телевизору? Да, сейчас можно с уверенностью сказать – есть – TFT компьютерный монитор.
Почему только «сейчас»?
Т.к. ZX проектировался под телевизионную развёртку, то его кадровая частота =50Гц, а TFT мониторы изначально проектировались под VGA стандарт, для которого минимальная частота кадров =60Гц. До сих пор это было преградой на пути подключения ZX к VGA мониторам (хотя и преодолимой с определённым геморроем и потерей качества изображения). Но со временем электронику под многие мониторы начали выпускать унифицированную двойного применения VGA/TV и соответственно такие мониторы научились синхронизироваться по кадрам* на 50Гц.

*Внимание!! Не следует путать частоту кадровой синхронизации с частотой обновления изображения на TFT мониторе – это взаимно независимые характеристики.

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

1.4 VGA совместимые режимы ZX.

В чём суть преобразования сигналов ZX->VGA? Очень упрощённо - если длительность строки изображения ZX=Tzx, то длительность строки изображения VGA(640x480@60Hz)~Tzx/2, SVGA(800x600@72Hz)~Tzx/3, XGA(1024x768@75Hz)~Tzx/4. Т.е. сжав ZX строку соответственно в 2, 3 или 4 раза – получим строку VGA, SVGA или XGA. Соответственно, для синхронизации длительности кадров, каждую укороченную строку воспроизводим 2, 3 или 4 раза подряд. Единственная, существенная нестыковка в этом методе – это частота кадров, она останется неизменной – 50Гц, но как раз это и исправляется TFT монитором. Дело в том, что истинное разрешение TFT монитора определяется разрешением его матрицы, а все разрешения не совпадающие с истинным формируются с помощью пересчёта. Фактически, аналоговый сигнал на входе такого монитора построчно преобразуется в цифру с помощью АЦП, а потом отображается на TFT матрице уже с той частотой обновления, которая удобна для матрицы. Поэтому для такого монитора кадровая частота входного сигнала не имеет значения, лишь бы его схема оцифровки смогла с ней засинхронизироваться.
Таким образом, можем иметь следующие возможные разрешения для вывода ZX сигнала:
1) VGA(640x480)=[256x2]x[192x2]с бордюром,
2) VGA(640x480)=384x256 с бордюром,
3) VGA(640x480)=512x[192x2]с бордюром,
4) VGA(640x480)=512x256 с бордюром,
5) VGA(640x480)=512x384 с бордюром,
6) SVGA(800x600)=[256x3]x[192x3]с бордюром,
7) SVGA(800x600)=[512x1,5]x[192x3]с бордюром,
8) SVGA(800x600)=[384x2]x[256x2]с бордюром,
9) SVGA(800x600)=[512x1,5]x[256x2]с бордюром,
10) SVGA(800x600)=512x384 с бордюром,
11) SVGA(800x600)=768х576 с бордюром,
12) XGA(1024x768)=[384x2]x[256x2]с бордюром,
13) XGA(1024x768)=[256x4]x[192x4]без бордюра,
14) XGA(1024x768)=[512x2]x[192x4]без бордюра,
15) XGA(1024x768)=[512x2]x[256x3]без бордюра,
16) XGA(1024x768)=[512x2]x[384x2]без бордюра,
17) XGA(1024x768)=1024х768 без бордюра.

1.5 Ограничение по соотношению сторон.

Важным условием является повторяемость соотношения сторон при формировании области изображения на разных мониторных разрешениях. Проанализировав полученные варианты можно сказать, что предложенное ZX разрешение 512х256 при воспроизведении в каждом из рассматриваемых мониторных разрешений имеет разные соотношения сторон, а значит не удовлетворяет критерию проверки и исключается из дальнейшего рассмотрения (варианты 3), 7), 12)).

[Black_Cat]

1.6 Архитектурные ограничения.

Одной из стандартных возможностей архитектуры видеопроцессоров является конвертация видеорежимов по критерию «разрешение<–>глубина цвета» в рамках выделенного объёма памяти. В этом отношении принципиальное значение имеет кратность масштабирования видеоразрешений. В рассматриваемых вариантах нетрудно заметить, что для режимов VGA и XGA масшабирование видеоразрешений кратно степени основания 2, а для режима SVGA - соответственно степени основания 2 и 3. Т.е. для режимов VGA и XGA имеем: 1024x768х1bit=1024x384х2bit=512x384х4bit=512x19 2х8bit=256х192x16bit. Для режима SVGA: 768х576x1bit=512x384х2bit*=512x192х4bit*=256х1 92x9bit (* - в этих режимах видеопамять используется не полностью).
Ещё одной стандартной возможностью архитектуры видеопроцессоров является разделение видеопамяти на битовые плоскости переднего и заднего плана. В отношении режимов VGA и XGA очень легко произвести единообразное для всех режимов деление на 2 битовые плоскости переднего и заднего плана, чего не скажешь в отношении режима SVGA, где используются режимы кратные степеням разных оснований. В режиме SVGA произвести такое единообразное для всех режимов деление возможно только приведением режимов к общему кратному множителю путём увеличения битности в 2 или 3 раза, что позволит иметь деление соответственно на 2 или 3 битплана.
Выводы:
- учитывая полноту использования выделенного объёма памяти, меньшую требовательность к объёму памяти, а также то, что выпускаемые ЦАПы для формирования видеосигнала имеют разрядность кратную основанию 2 – наиболее оптимальными вариантами является использование режимов VGA и XGA;
- режим SVGA, как неоптимальный с точки зрения требований к ресурсам, из дальнейшего рассмотрения исключить.

1.7 Выводы: рекомендуемые разрешения и видеорежимы при развитии видеопроцессора ZX Spectrum.

Графические режимы:

1) TV=256х192х16bit (стандартный TV);
2) VGA(640x480)=[256x2]x[192x2]x16bit (стандартный с бордюром, в режиме VGA);
3) VGA(640x480)=512x384x4bit (1 повышенное разрешение с бордюром, в режиме VGA);
4) XGA(1024x768)=[256x4]x[192x4]x16bit (стандартный без бордюра, в режиме XGA);
5) XGA(1024x768)=[512x2]x[384x2]x4bit (1 повышенное разрешение без бордюра, режим XGA);
6) XGA(1024x768)=1024х768x1bit (2 повышенное разрешение без бордюра, режим XGA);

Текстовые режимы:

1) TV=(6х8)512х192х8bit (1 повышенное разрешение TV);
2) VGA(640x480)=(6х8)512x[192x2]x8bit (1 повышенное разрешение с бордюром, в режиме VGA);
3) XGA(1024x768)=(6х8)[512x2]x[192x4]x8bit (1 повышенное разрешение без бордюра, в режиме XGA);
4) XGA(1024x768)=(12x16)1024x[384x2]x2bit (2 повышенное разрешение без бордюра, в режиме XGA);

Такое разбиение на режимы позволяет перекрыть весь диапазон применений компьютера. При этом TV и VGA режимы ориентированы на старый софт с бордюрными эффектами, а XGA режим на перспективный софт, в котором бордюр не несёт информационной нагрузки.

P.S. Вы просматриваете тему составленную из материалов новой рубрики "ZX Концепции". Продолжение обсуждения тем рубрики вы можете найти на:
Soviet Union ZX Spectrum Community (http://zx.clan.su/forum/7)

[Black_Cat]

Стандартизация принципов развития видеопроцессора (продолжение).

2.0 Идеология развития ZX экрана.

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

В вопросе идеологии (см. определение: http://www.zx.pk.ru/showpost.php?p=61049&postcount=113 ) важным моментом является понимание того, куда мы хотим в итоге придти и где мы находимся сейчас. По этим двум точкам и строится вектор идеологии развития. Определим эти точки применительно к видеопроцессору ZX Spectrum.

На момент продажи прав на ZX Амстраду, ZX-видеопроцессор имел следующие особенности:

1.0 Отправная точка.
1.1 Экранная область в ОЗУ начиналась с адреса кратного 16k и состояла из 6k пиксельного экрана и следующих за ними 768 байт области атрибутов;
1.2 Экранных областей существовало две – активная и теневая;
1.3 Разрешение экранной области 256х192, разбитое на 32х24 знакоместа 8х8 пикселов;
1.4 Видеовывод осуществлялся третями экрана с периодом 8 строк;
1.5 8 цветов на бордюр.
1.6 15 цветов на знакоместо и режим мигания;

1.0 Точка назначения.
1.1 Дополнительные (т.е. к имеющимся) экранные области в ОЗУ со стандартной раскладкой адресов начинающиеся с адреса кратного 8k (для экономии места);
1.2 Разбивка всех экранных областей на две равные части – активную и теневую;
1.3 Расширенные экраны кратные разрешению 256х192 или объёму памяти экранных областей (см. рекомендации: http://www.zx.pk.ru/showpost.php?p=62984&postcount=119
http://www.zx.pk.ru/showpost.php?p=62985&postcount=120 );
1.4 Видеовывод осуществляется третями экрана с периодом 8 строк, и познакоместно (т.е. байт на строку знакоместа при развитии по критерию подобности внутренней структуры);
1.5 Для старых программ – возможность использовать бордюр, для новых – возможность не использовать (ввиду отсутствия такового);
1.6.1 Битплановая организация экрана с возможностью конвертации количества битплановых плоскостей в разрешение экрана;
1.6.2 Возможность деления битпланов на две равные части: передний (спрайтовый) и задний (тайловый) план;
1.6.3 Возможность отказа от атрибутов как носителей информации о цвете или их модификации;
1.6.4 Видеоускоритель с функциями скролла, зеркалирования, загрузки спрайтов;

Примечание: для облегчения сравнения номерам пунктов отправной точки соответствуют номера пунктов точки назначения.

Вывод: таким образом можно определить идеологию развития видеопроцессора ZX Spectrum как вектор отображения текущего множества параметров видеопроцессора на перспективное множество параметров.

P.S. Вы просматриваете тему составленную из материалов новой рубрики "ZX Концепции". Продолжение обсуждения тем рубрики вы можете найти на:
Soviet Union ZX Spectrum Community (http://zx.clan.su/forum/7)

[Lethargeek]

Спектрум на 90% – это видеопроцессор
Видеоконтроллер. Это на восьмибитных атари видеопроцессор. :)
А в принципе данное утверждение справедливо для большинства буржуйских "домашних" компов.


Из каких соображений проецирование экранной области на видеопамять было сделано именно так, сейчас - трудно сказать
И нифига не трудно (любому мало-мальски кодившему должно быть понятно).
Во-первых: минимальный размер затрачиваемой памяти в графическом режиме.
Во-вторых: максимальная скорость вывода цветного текста (путем "подгонки" железа под z80) в этом самом графическом режиме, раз уж отдельный текстовый режим не предусматривался из соображений дешевизны. Реализовано настолько, насколько не противоречило пункту "во-первых".

Пресловутые "трети" (или любые другие участки) тут совершенно ни при чем. Просто "так получилось". И что теперь, ориентироваться на случайность? Обычным кодерам эти "особенности" только осложняют жизнь. Вот если бы разработчики поменяли приоритет вышеуказанных пунктов, в том же разрешении пришлось бы отдать под экран уже 8 Кб (правда, сюда влезли бы и системные переменные), зато графика (а не только текст) была бы значительно быстрее, плюс можно сделать раздельный FLASH и BRIGHT. ИМХО так было бы гораздо лучше, но в начале 80-х у разработчиков (и особенно командовавших ими коммерсантов) были весьма специфические тараканы в голове.

Если уж говорить о неотъемлемых особенностях Спека с прицелом на дальнейшее обобщение:
1.Низкая нагрузка видеоконтроллера на систему (торможение процессора в нашем случае)
2.Атрибуты = различная палитра для фиксированных частей экрана (мин.два цвета, мин.область 8x8)
3.Прямой доступ ко всей видеопамяти (никак не ограниченный и именно как к памяти)
4.Упомянутая "подгонка под 8-битный процессор", облегчающая программирование
Из пп.3-4 вытекает необходимость битплановой организации памяти (на Спеке это минимум - одна плоскость), то есть адресация одного пиксела одним битом. Снизить нагрузку на память тоже может помочь.

Ну и дальше это дело можно экстенсивно наращивать, причем оставаясь в указанных рамках "совместимости" (битпланов там добавить, с атрибутами похимичить, если понадобится). Что лично я и пытаюсь в меру своих сил развивать, пока на уровне идей.

P.S. Про частоты я умолчал, ибо не только собс-но к Спеку относится, а и ко всем аналогичного класса компам. Но телевизор - это все-таки хорошо. Особенно ЖК. :)

[Black_Cat]

Из каких соображений проецирование экранной области на видеопамять было сделано именно так, сейчас - трудно сказать.Имелись ввиду трети экрана и каждая восьмая строка.
Видеоконтроллер. Это на восьмибитных атари видеопроцессор.У меня терминология другая:
Видеопроцессор - автомат формирования изображения, являющийся частью устройства.
Видеоконтроллер - автомат формирования изображения, являющийся отдельным, законченным устройством.
зато графика (а не только текст) была бы значительно быстрееЭто за счёт чего? За счёт "подгонка под 8-битный процессор"? Вчём это выражается?

плюс можно сделать раздельный FLASH и BRIGHTЧто имеется ввиду, и что это даёт?
1.Низкая нагрузка видеоконтроллера на системуПодразумевается режим
прозрачности, т.е. разномоментности обращения к памяти?
2.Атрибуты = различная палитра для фиксированных частей экрана (мин.два цвета, мин.область 8x8)Т.е. стандартные атрибуты?
3.Прямой доступ ко всей видеопамяти (никак не ограниченный и именно как к памяти)Для CPU имеется ввиду? Т.е. как в ZX48 без перетасовки 16к сегментов, или как?
адресация одного пиксела одним битомТ.е. каждому N-битному пикселу - физический адрес?

[Lethargeek]

Имелись ввиду трети экрана и каждая восьмая строка.
Я заметил. :) Ну и что же там "трудного" для понимания?


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


Это за счёт чего? За счёт "подгонка под 8-битный процессор"? Вчём это выражается?
Ну вот на Спеке (один раз вычислив начальный адрес) можно быстро перемещаться по всему экрану с шагом в одно знакоместо и в пределах символьной строки с шагом в один пиксел, используя в основном только inc/dec/rot. "Лишние" проверки нужны при пересечении границы символьной строки. А вот если бы видеопамять была организована не строками, а столбцами, можно было бы по всему экрану с шагом в пиксел быстро перемещаться (и по атрибутам тоже). И начальный адрес вычисляется в разы быстрее без всяких там таблиц. Вывод спрайтов/блоков тоже быстрее, потому что (помимо отстутствия лишних проверок) лучше иметь несколько длинных циклов по вертикали, чем кучу коротких по горизонтали (а циклы-то побайтовые, не попиксельные!).

Вкратце одна из возможных схем могла быть такая: каждый столбец - 256 байт, из них 192 байта графика и 48 байт атрибуты (по два на знакоместо), в каждом атрибуте раздельный BRIGHT для INK и PAPER, а FLASH получается, если эти два атрибута не совпадают (то есть опять же можно мигать раздельно инком и папером). 16 байт в каждом столбце (всего 512) свободны, и их можно еще как-то поюзать (под те же системные переменные, например) - итого с ними восемь килобайт на весь экран. Но разрабы когда-то решили иначе - килобайтик пожалели, блин! А в результате для скорости все равно почти всегда используются таблицы, которые память жрут... :(


Подразумевается режим прозрачности, т.е. разномоментности обращения к памяти?
Необязательно. Или "редкости" обращений. Или вообще внешней видеопамяти. Или еще чего.
Главное, чтобы хост не простаивал зря.


Т.е. стандартные атрибуты?
Как минимум "не хуже". Хотя и шибко наворачивать особого смысла не вижу.


Для CPU имеется ввиду? Т.е. как в ZX48 без перетасовки 16к сегментов, или как?
Не переключая страницы при рисовании по всему (выбранному) экрану, как в оригинале. Чтобы не было уродств типа банкирования на пц (с переключением посреди строки!). Да и вообще - банки фтопку. :mad:


Т.е. каждому N-битному пикселу - физический адрес?
Адресация одним битом, все как на Спеке. То есть адрес на группу из восьми пикселов.

[Black_Cat]

Вкратце одна из возможных схем могла быть такая: каждый столбец - 256 байт, из них 192 байта графика и 48 байт атрибутыТ.е. если не отвлекаться на дополнительный байт атрибутов, то всё дело в структуре организации адресного пространства видеопамяти. Т.е. как расположение ячеек памяти будет видеться со стороны процессора, и если эту организацию изменить, то ты считаешь это существенно повысит производительность обработки изображения процессором (программой)? Вобщем, для каких-то пока не существующих расширенных режимов, такую организацию памяти можно сделать - здесь особых проблем нет, при этом для видеопроцессора организация памяти останется прежней.
Чтобы не было уродств типа банкирования на пц (с переключением посреди строки!).Помоему для этого достаточно иметь 2 экрана. На одном изображение готовится, а со второго выводится, а потом они меняются местами. Или как по твоему можно обойти 16к банкирование в ZX, если весь экран допустим в каком-то новом расширенном режиме будет больше 16к?
В принципе чем юла не законченное устройство?Законченное устройство - это типа VGA адаптера для примера, а та его часть что занимается построением изображения - это собссно и есть видеопроцессор, но кроме этого у законченного устройства есть ещё как минимум интерфейс связи с компом. Изъяв видеоконтроллер - компьютер остаётся работоспособным, а изъяв ULA - выводится полностью из строя, т.к. ULA - это его неотъемлемая часть.

[captain cobalt]

итого с ними восемь килобайт на весь экран Круто.
Это обязательно нужно донести до железнячников.

Но разрабы когда-то решили иначе - килобайтик пожалели, блин! Вероятно, просто не догадались.

это существенно повысит производительность обработки изображения процессором (программой)? Определённо повысит.
Можно сравнить накладные расходы для двух случаев:

1. Перемещение по вертикали.
У Speccy - процедура, которая будучи заинлайнена занимает более 25 тактов, не будучи заинлайнена - более 40 тактов.
В восьмикилобайтной модели - одна команда INC L (или DEC L), 4 такта.
Дополнительный бонус - свободный аккумулятор и флаг переноса.

2. Преобразование вертикальной пиксельной координаты в адрес видеопамяти.
В восьмикилобайтной модели - 0 байт, 0 тактов. Координата в младшем байте является частью адреса.
У Speccy обычно делают таблицу адресов всех 192 линий -- 384 (или 512) байт таблица и пара десятков тактов на каждое преобразование.

[Lethargeek]

Законченное устройство - это типа VGA адаптера для примера, а та его часть что занимается построением изображения - это собссно и есть видеопроцессор, но кроме этого у законченного устройства есть ещё как минимум интерфейс связи с компом. Изъяв видеоконтроллер - компьютер остаётся работоспособным, а изъяв ULA - выводится полностью из строя, т.к. ULA - это его неотъемлемая часть.
Я имел в виду, что видеоконтроллер полностью влазит в юлу (помимо прочего).
Ну и у клонов там всяких конечно нет никакой юлы - все отдельно.


Помоему для этого достаточно иметь 2 экрана. На одном изображение готовится, а со второго выводится, а потом они меняются местами. Или как по твоему можно обойти 16к банкирование в ZX, если весь экран допустим в каком-то новом расширенном режиме будет больше 16к?
Я про переключение "внутри" экрана. Самый "ходовой" режим, предназначенный для быстрой графики (дем, игрушек...) не должен банкироваться ни в коем случае. В адресном пространстве 16К при использовании битплановой организации памяти можно получить разрешение порядка 400x300 (примерно соответствует телевизору). В больших разрешених - да, надо экран разбивать, но там о скорости и так уже речь не идет. ИМХО Спеку вообще особо большие разрешения не нужны, когда песюков навалом (и уж точно не нужны для всяких "казуальных" применений). Главное - чтобы кодить было легко и приятно. :v2_cool:


Это обязательно нужно донести до железнячников.
Я и пытаюсь - в закрытом разделе. Причем в куда более навороченном виде. :)
А то, что я тут описал (столбцовая организация как таковая) - у меня сильное подозрение, что так и было сделано в некоторых советских компах (Вектор, Орион?), только без атрибутов, конечно.

[Black_Cat]

Самый "ходовой" режим, предназначенный для быстрой графики (дем, игрушек...) не должен банкироваться ни в коем случае.Тогда самый ходовой режим - это будет два ZX экрана (отбросим экзотические разрешения), которые можно расположить либо удвоив разрешение, либо количество цветов на пиксель. А если битпланов не 2, а 4, 8, 16? Тут разве что только с аппаратными ухищрениями можно остаться в адресном пространстве одного банка.

[Lethargeek]

А если битпланов не 2, а 4, 8, 16?
Да хоть 250.
Суть в том, что в такой модели (в отличие от VGA-подобных режимов) разделяются задачи "где", "что" и "как". То есть предварительно устанавливаем, "что" обрабатывается и "как" - а уже потом "где" находится каждый интересующий кусок экрана определяется быстро и без заморочек.

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

А без "аппаратных ухищрений" не обойтись ни в одной модели. На самом деле, если покопаться в истории вопроса, все эти затруднения тем или иным способом давно разрешены в принципе, задача - взять самые удачные решения, объединить их и адаптировать к особенностям ZX.

[Lethargeek]

1.0 Точка назначения. ...
Ладно, вот сравнение с моим прожектом (мож кому интересно)...
1.1 VideoRAM - внешний (и потому быстрый), используется и для хранения (по желанию), и для отображения графики. Стандартная раскладка - только по желанию и только как способ адресации (а не действительного хранения графики).
1.2 Разбивка на несколько базовых страниц, переключаемых как угодно.
1.3 256x192 не катит. Полное разрешение фирменного спека с бордюром что-то вроде 368x288, Пентагона - 384x304. (также см. п.1.5).
1.4 Сохранять "трети" и "восьмистроки" - маразм, это не достоинство Спека, а его беда. Только как часть старого способа адресации. Атрибуты можно слегка навернуть...
1.5 Экран расширен почти на всю площадь бордюра, но его можно "сжимать" обратно, просто снова закрывая бордюром произвольного размера (не опасаясь при этом за перекос адресации).
1.6.1 Есть. И почему некоторым по чисто "религиозным" причинам битпланы не нравятся? :(
1.6.2 Есть. Только термины "тайловый" и "спрайтовый" здесь ваще не в тему - надо "передний слой" и "задний слой". Их еще можно на подслои делить простой настройкой палитры, благо битпланы.
1.6.3 Само получается. :)
1.6.4 Блиттер сегодня справится с чем угодно. Аппаратные спрайты фтопку. Даже аппаратный (в смысле не в памяти, а только на экране) скролл не нужен.


Вывод: таким образом можно определить идеологию развития видеопроцессора ZX Spectrum как вектор отображения текущего множества параметров видеопроцессора на перспективное множество параметров.
Вот только не надо отталкиваться от чисто внешних признаков. Главное - внутреннее содержание!! Попробуй описать "в двух словах" процесс рисования на стандартном экране... Даже не с точки зрения кодера (хотя там то же самое), а для простого юзера Art Studio например?

[Black_Cat]

Даже аппаратный (в смысле не в памяти, а только на экране) скролл не нужен.Скролл вообще-то в памяти и именно для спрайтов, а экранный скролл имеет смысл делать для заднего плана.
Аппаратные спрайты фтопку.Что ты подразумеваешь под "аппаратные"?
Их еще можно на подслои делить простой настройкой палитры, благо битпланы.Дальнейшее деление считаю излишним. Два слоя, да со скролируемыми, зеркалируемыми и подгружаемыми автоматом спрайтами должно хватить на дальнюю перспективу.
Сохранять "трети" и "восьмистроки" - маразм, это не достоинство Спека, а его беда.Какой уж есть, не я его делал. :) Хотелось бы иметь возможность модернизировать с минимальными затратами старые игрушки под новые возможности, поэтому экран по максимуму родной.
Полное разрешение фирменного спека с бордюром что-то вроде 368x288, Пентагона - 384x304Зачем изголяться на ни с чем не совместимые разрешения, если повышенное разрешение можно получить целочисленным масштабированием стандартного экрана?
VideoRAM - внешний(и потому быстрый)Ну быстота и внешнесть не связаны. Как понимаю это твой второй вариант развития идей - контроллерного типа. Первый мне больше нравится. А на счёт внешнего контроллера именно для перспективной видеосистемы, т.е. имеющей большое видео ОЗУ я бы не горячился. Всёж хочется развивать Спек сбалансированно, т.е. не закрывать путь к отложенной многозадачности. Для маленького видео ОЗУ внешний контроллер ещё куда не шло, но при объёмах ~128-256к с учётом, что к каждой отложенной задаче прилагается отложенный экран перекачка туда-сюда при каждом переключении с задачи на задачу будет долговасто. А в случае когда видео ОЗУ и основное = одно целое - просто надо щёлкнуть банками.

[Lethargeek]

Скролл вообще-то в памяти и именно для спрайтов, а экранный скролл имеет смысл делать для заднего плана.
Блиттер переносит что угодно куда угодно и как угодно. Если он все успевает - зачем какие-то лишние сущности? Это дополнительная головная боль при дальнейших доработках. Чем меньше отдельных узлов - тем лучше.


Что ты подразумеваешь под "аппаратные"?
Как на комодури или том же тридевятом. Что в момент прохода луча по растру накладывается динамически. То, что на Спеке - не спрайты, одно название.


Дальнейшее деление считаю излишним. Два слоя, да со скролируемыми, зеркалируемыми и подгружаемыми автоматом спрайтами должно хватить на дальнюю перспективу.
"Дальнейшее деление" там автоматически получается, ничего специально для этого добавлять не надо. :v2_laugh: Головой подумай. А также над тем, зачем оно может пригодиться.


Какой уж есть, не я его делал. :) Хотелось бы иметь возможность модернизировать с минимальными затратами старые игрушки под новые возможности, поэтому экран по максимуму родной.
Ну так для этого достаточно старого способа адресации. Хранить точно так же растр в памяти нет никакого смысла. Тем более что с увеличенной площадью экрана (хоть кратной, хоть некратной) все равно не получится.


Зачем изголяться на ни с чем не совместимые разрешения, если повышенное разрешение можно получить целочисленным масштабированием стандартного экрана?
Как выяснилось, уже "512x384 два слоя" многовато - в итоге дисбаланс скорости и площади, и адресация неудобная. Насчет "ни с чем не совместимые разрешения" - так это фактически PAL low resolution 352x288 (видимая область). Или что-то близкое подобрать. Для текста - "сплющенный" однослойный режим с удвоением разрешения по горизонтали.

Хватит уже судить по отдельным внешним признакам, нужен комплексный подход.

[Lethargeek]

Ну быстота и внешнесть не связаны.
:v2_laugh: Зато быстрота с тактовой частотой видеопамяти очень даже связана.

что к каждой отложенной задаче прилагается отложенный экран
И че, несколько дем планируется запускать в качестве таких задач? Сохранением экранов вообще ось должна заниматься. И тормозов пока что не избежать. Видеопамяти должно хватать на одно "тяжелое" (в смысле экрана) приложение. Если вообще планируется возможность запуска оного в многозадачном режиме с последующими частыми переключениями задач!!

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

[Black_Cat]

уже "512x384 два слоя" многовато - в итоге дисбаланс скорости и площадиВообще-то проектируется с перспективой на будущие машины 21-28MHz. Но может работать и на Спеке 3,5MHz, но из набора режимов естественно разумно использовать максимально облегчённые, но к такому Спеку врятли кто будет прикручивать такой видеопроцессор. Сейчас актуальный комп - это ПЛИС+CPU+RAM+ROM, а там на этапе проектирования всё решается.
это фактически PAL low resolution 352x288Знаешь, я уже забыл что такое аналоговый телевизор, и многие мои знакомые тоже. И чем дальше - тем больше. Электричество дорожает, метры жилплощади дорожают и электронно-лучевые гробы отправляются на ближайшую помойку и VGA кстати за ними следом. TFT - это уже не роскошь, а просто необходимость.
И скажи зачем кому этот PAL упал? :) Никому до него уже нет дела. Аналоговое телевидение - умерло морально, а через несколько лет умрёт физически. Всё, крест. Разработки под TV сейчас способны только отпугнуть пользователя. Для его привлечения надо делать под VGA.
Тем более что с увеличенной площадью экрана (хоть кратной, хоть некратной) все равно не получится.Не вижу тут проблем, все битпланы читаются параллельно, просто разрядность видеопроцессора возрастает - это нормально.
зачем оно может пригодиться.Неоправданное усложнение автомата работающего со спрайтами. Так туда eZ80 придётся ставить. Подумать можно, но лучше ещё лет через 20.:)
Блиттер переносит что угодно куда угодно и как угодно.Как управляется блиттер?

[scl^mc]

Стандартизация принципов развития видеопроцессора (продолжение).
1.2 Экранных областей существовало две – активная и теневая;
...
1.3 Расширенные экраны с разрешением кратным 256х192
...
по порядку:
1. с чего вы решили, что всегда существовали две экранные области? второй экран появлися только в 128х спеках.
2. почему за основу берутся расширенные экраны с разрешением, кратным 256 на 192, а не кратным 2м?

[Lethargeek]

Но может работать и на Спеке 3,5MHz, но из набора режимов естественно разумно использовать максимально облегчённые, но к такому Спеку врятли кто будет прикручивать такой видеопроцессор.
Именно "к такому Спеку" как раз и должно прикручиваться, иначе не выживет. Причем в первой версии наворотов и лишних функциональных узлов должно быть поменьше, чтоб потом не мучиться, как их все сохранить при модернизации девайса, чтоб они не мешались и ресурсы не жрали зря. Пусть пока кодеры осваивают что есть и пишут софт. Тем более что никаких "облегченных режимов" не надо, скорость Спека на данном этапе некритична.


И скажи зачем кому этот PAL упал? :) Никому до него уже нет дела.
Зато многим есть дело до one-frame.


Аналоговое телевидение - умерло морально, а через несколько лет умрёт физически. Всё, крест. Разработки под TV сейчас способны только отпугнуть пользователя. Для его привлечения надо делать под VGA.
Есть портативные ЖК-телевизоры. Есть близкий стандартный X-режим VGA 360x240. Есть стандартный режим 800x600, легко конвертируемый в интерлейс 400x300. Вот с частотой кадров возникнут траблы, тут надо что-то решать :(
Когда аналоговое ТВ "умрет физически" окончательно, можно будет "дать народу" нормальный ЖК-монитор специально для Спека, в конце концов (цены-то падают на детальки). Если к тому времени развитие Спека будет еще кому-нибудь интересно.


Не вижу тут проблем, все битпланы читаются параллельно, просто разрядность видеопроцессора возрастает - это нормально.
ПРОСТО "разрядность видеопроцессора возрастает"... :v2_lol:


Неоправданное усложнение автомата работающего со спрайтами. Так туда eZ80 придётся ставить. Подумать можно, но лучше ещё лет через 20.
Бред какой-то. Я там русским языком написал, что в битпланах оно получается "даром", ничего "усложнять" не надо. И еще какой-то "спрайтовый автомат" ни к селу ни к городу... :v2_wacko:


Как управляется блиттер?
Засылаешь в регистры режим работы (прозрачный цвет, формат данных, сколько битпланов участвует итд), размеры, откуда, куда. Параметры запоминаются, каждый раз повторять их все необязательно (изменил только нужные) - блиттер автоматически запускается при получении нового адреса "куда". Формат хранения графики может не совпадать (топологически) для источника и приемника. В итоге для тормозного Z80 возни будет меньше, чем скажем с перемещением аппаратных спрайтов фиксированного размера, а возможностей (в отличие от спрайтайловых движков) куда больше. В коде скорее всего будут просто вызываться типовые процедуры для типовых объектов... Еще неплохо бы для блиттера очередь команд задавать (но можно и отложить на следующую версию для того самого "продвинутого Спека").

[Black_Cat]

с чего вы решили, что всегда существовали две экранные области? второй экран появлися только в 128х спеках.А посмотреть самому на 3 строчки выше слабо было?
На момент продажи прав на ZX Амстраду, ZX-видеопроцессор имел следующие особенности:
почему за основу берутся расширенные экраны с разрешением, кратным 256 на 192А по ссылкам не сходить чтоли, там и написано почему, притом именно и только ответ на твой вопрос и больше ничего: http://www.zx.pk.ru/showpost.php?p=62984&postcount=119
http://www.zx.pk.ru/showpost.php?p=62985&postcount=120

[Black_Cat]

Пусть пока кодеры осваивают что есть и пишут софт.Это вообще дело эмуляторов. Врядли есть смысл в выпуске промежуточного железа. При реализации в ПЛИС особой разницы нет все режимы или половина. ПЛИС сразу выбирается под конечную конфигурацию, а на сколько её запишут на 50% или 100% это на сложность железа не влияет.
многим есть дело до one-frame.У тебя весь экран с множеством битпланов в одной странице ОЗУ помещается? У меня ОЗУ для 8 битпланов это грубо 64к, что в 4 раза больше страницы ОЗУ. И какой тут one-frame может быть?
Есть портативные ЖК-телевизоры.Опять же - пока есть.
можно будет "дать народу" нормальный ЖК-монитор специально для СпекаЗачем это радиолюбительство? Массовое советское радиолюбительство умерло вместе со смертью дефицита. Стократно доказано - серийный TFT дешевле и надёжней радиолюбительской поделки.
ПРОСТО "разрядность видеопроцессора возрастает"Поверь, в этом нет абсолютно ничего сложого.
И еще какой-то "спрайтовый автомат"Это автомат двигающий спрайты произвольного размера кратные знакоместу, зеркалирующий их, и подгружающий их. Его архитектура привязана к количеству плоскостей передних и задних планов, а конкретно - предполагается только одна плоскость переднего плана.
Засылаешь в регистры режим работы (прозрачный цвет, формат данных, сколько битпланов участвует итд), размеры, откуда, куда.Т.е. фактически тот же автомат, но на основе доп CPU. Это можно подумать.

[SfS]

Это вообще дело эмуляторов. Врядли есть смысл в выпуске промежуточного железа.

Ты когданибудь более-менее сложное железо делал ? ИМХО - нет. Иначе знал бы, что промежуточное железо бывает практически всегда. ВСЁ ты никогда нигде ни на каком эмуляторе не учтешь.


При реализации в ПЛИС особой разницы нет все режимы или половина. ПЛИС сразу выбирается под конечную конфигурацию, а на сколько её запишут на 50% или 100% это на сложность железа не влияет.

Хорошо быть тИАретикам!


У тебя весь экран с множеством битпланов в одной странице ОЗУ помещается? У меня ОЗУ для 8 битпланов это грубо 64к, что в 4 раза больше страницы ОЗУ.

8 битпланов для процессора могут выглядеть как бит-на-точку. 256х192 это будет 6к адресного пространства проца. При разрешении 512х384 - 24К адресного пространства проца. Если бы ты программировал EGA видеокарточки - знал бы как это реализуется.


И какой тут one-frame может быть?Опять же - пока есть.Зачем это радиолюбительство? Массовое советское радиолюбительство умерло вместе со смертью дефицита. Стократно доказано - серийный TFT дешевле и надёжней радиолюбительской поделки.

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


Поверь, в этом нет абсолютно ничего сложого.
Любимая фраза людей, которые сами мало что делали.

[Lethargeek]

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


У тебя весь экран с множеством битпланов в одной странице ОЗУ помещается? У меня ОЗУ для 8 битпланов это грубо 64к, что в 4 раза больше страницы ОЗУ. И какой тут one-frame может быть?
Кури EGA. В том-то и дело, что "помещается" - и растр, и новые атрибуты. Максимум для 16К. С удобнейшей адресацией.


Опять же - пока есть.Зачем это радиолюбительство? Массовое советское радиолюбительство умерло вместе со смертью дефицита. Стократно доказано - серийный TFT дешевле и надёжней радиолюбительской поделки.
А не такой уж старый б/у пц с эмулятором дешевле и надежней... :)
Если будет выгодно слепить такой монитор и надолго забыть о проблемах сопряжения - почему нет? :v2_cool:


Поверь, в этом нет абсолютно ничего сложого.
Я никогда не "верю", я все обсчитываю. :)
"Узкое место" не в ПЛИС, а в ширине ШД видеопамяти. А это ноги. Количество свободных ног имеет тенденцию коррелировать с ценой упомянутых ПЛИС и сложностью пайки изделия по принципу положительной обратной связи (во загнул!). :v2_finge: Короче, дорого и геморройно.
Второй момент - большее разрешение в 16К как раз и не влезет. Уже надо банкировать до той поры единый растр. А это "идеологически плохо", лишние тормоза и ваще аццтой. :v2_sick:


Это автомат двигающий спрайты произвольного размера кратные знакоместу, зеркалирующий их, и подгружающий их. Его архитектура привязана к количеству плоскостей передних и задних планов, а конкретно - предполагается только одна плоскость переднего плана.
Было бы странно изобретать какие-то особые велосипеды для отдельных планов и отдельных типов объектов, когда давно всем известно универсальное решение. :)


Т.е. фактически тот же автомат, но на основе доп CPU. Это можно подумать.
Все в том же корпусе и очень просто устроено.

-------------------------------

Гы, еще и SfS о том же наотвечал параллельно...

[Black_Cat]

ВСЁ ты никогда нигде ни на каком эмуляторе не учтешь.Промежуточное железо делается на макетке, а вот промежуточные печатные платы могут быть только в результате ошибок. При грамотной подготовительной работе в серию идёт только отлаженная конструкция. Если у Вас в серию идут недоделки - значит ваш технологический процесс отладки не достаточно хорош, только и всего.
Если радиолюбительство понимать как..Предлагаю не отвлекаться на обсуждение отвлечённых тем, и тем более ударяться в такие глупости как: кто что делал и какие титулы имеет :). Ваши титулы - это Ваши ответы. Если они грамотные и чётко изложены - Ваш титул "профессионал", если же в них ничего кроме "смеху*чков" нет - Ваш титул "флудер" или "ламер". Каждое Ваше сообщение содержит Ваш титул, Вы его выбираете сами в зависимости от того как Вы относитесь к обсуждаемому вопросу. Поэтому если по делу Вам сказать нечего, то лучше воздержаться от флуда и демагогии типа:
Любимая фраза людей, которые сами мало что делали.Надеюсь на взаимное понимание и более плодотворное сотрудничество направленное на на результат, а не на раздувание щёк.

[Black_Cat]

почему нет?Потому, что TFT можно купить и в С.Пб и на Чукотке или Таймыре и всяко качественней и дешевле.
Полное разрешение фирменного спека с бордюром что-то вроде 368x288, Пентагона - 384x304.Тогда уж лучший вариант 384х288*. При этом соотношение сторон сохраняется 4:3. Обрати внимание - фактически 4:3 - это технологическое соотношение сторон ЭЛТ и оно сохранялось не только в TV, но и в VGA и в SVGA и в XGA, т.к. колбы трубок производились практически по одним и тем же технологиям, и только сейчас начали клепать 16:10 и то TFT и плазму.
Количество свободных ног имеет тенденцию коррелировать с ценой упомянутых ПЛИСНе обязательно переходить на супер многоножки, битпланы все одинаковые и действия над ними производятся одинаковые, а значит такие структуры хорошо масштабируются. Т.е. вместо одной дорогой ПЛИС можно поставить несколько одинаковых дешёвых. Естественно проводить стоимостную оценку вариантов решения надо. Но говорить об этом сейчас пока нет смысла - ещё и концепция не была формализована, и что при этом о схемотехнике спорить.
Поэтому, пока суд да дело, лучше прояснить мнения по другим вопросам:
1) Как понимаю в том варианте что ты предлагаешь архитектура будет закрыта для развития в сторону увеличения разрешения и по максимуму будет возможность расти в сторону глубины цвета? Или дальнейший рост не предусмотрен? Если предусмотрен, то до какого числа?
2) Спрайты переднего плана двигаешь блиттером, а весь задний план? В обеих измерениях?
3) Теневое ОЗУ используется для подготовки изображения, или может для чего ещё?
4) Как понимаю это будет доп контроллер, а что будет с видеопроцессором на мамке? Будет балластом или есть применение?
5) Переход в расширенный режим переключением в системном регистре, или режим вообще только один?
6) Что с обратной совместимостью нового софта? В начале стандартный экран, а потом переход в расширенный если он есть? Можно делать софт под оба экрана в рамках одного проекта (т.е. отличия не такие что легче другую прогу написать, чем адаптировать)?
7) Зеркалирование тоже с помощью блиттера? Ещё какие аппаратнореализованные эффекты будут?
8) Операции над видеоданными и управляющими регистрами, по механизму подобные EGA будут?
* - исправлено, под утро туго с арифметикой :) .

[Lethargeek]

Тогда уж лучший вариант 384х256. При этом соотношение сторон сохраняется 4:3 и цифры более-менее красивые. Обрати внимание - фактически 4:3 - это технологическое соотношение сторон ЭЛТ и оно сохранялось не только в TV, но и в VGA и в SVGA и в XGA, т.к. колбы трубок производились практически по одним и тем же технологиям, и только сейчас начали клепать 16:10 и то TFT и плазму.
Мне эти прописные истины прекрасно знакомы, и 384x256 планируется с самого начала. Другое дело, что на практике видимую область возможно придется ужать, вся проблема в частотах "близких" видеорежимов VGA.


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


Т.е. вместо одной дорогой ПЛИС можно поставить несколько одинаковых дешёвых. Естественно проводить стоимостную оценку вариантов решения надо.
Прогноз неблагоприятный.


1) Как понимаю в том варианте что ты предлагаешь архитектура будет закрыта для развития в сторону увеличения разрешения и по максимуму будет возможность расти в сторону глубины цвета? Или дальнейший рост не предусмотрен? Если предусмотрен, то до какого числа?
Сейчас задача стоит выжать максимум улучшений именно для совместимого со стандартным экрана, это и сделано, я считаю. По цвету - так есть еще "режим" с 12-битным цветом, когда оба слоя объединяются. А разрешение раздувать дальше бессмысленно - в конце маячит неизбежный отказ от совместимости. Действительно новый, несовместимый режим имеет смысл делать только для столь же нового Спека (на новой элементной базе И с несколько другими характеристиками). С поддержкой вот этого "старого" есс-но (к тому времени думаю не проблема будет в тогдашние ПЛИС все вместе запхнуть), чтобы возможность запускать за это время наработанный софт "вывозила" и новый режим как бесплатное приложение. А уж каким он будет, этот новый режим - "коллективный опыт" подскажет.


2) Спрайты переднего плана двигаешь блиттером, а весь задний план? В обеих измерениях?
Я ж ясно написал, что "все, всюду, и всяко-разно". "Спрайты" ничем особо от простых блоков не отличаются. Прозрачный цвет обрабатывается логическими операциями заодно со всем прочим.


3) Теневое ОЗУ используется для подготовки изображения, или может для чего ещё?
Для хранения чего угодно, хоть данных для хоста.
Можно даже разрешить оттуда код исполнять, но не думаю, что нужно. :)


4) Как понимаю это будет доп контроллер, а что будет с видеопроцессором на мамке? Будет балластом или есть применение?
Разве что в спецотладчиках второй экран (то есть телевизор) подключать и следить за пищеварением.


5) Переход в расширенный режим переключением в системном регистре, или режим вообще только один?
Один. Там "режимы" - не режимы, а просто "конфигурации", их можно переключать хоть посреди строки.


6) Что с обратной совместимостью нового софта? В начале стандартный экран, а потом переход в расширенный если он есть? Можно делать софт под оба экрана в рамках одного проекта (т.е. отличия не такие что легче другую прогу написать, чем адаптировать)?
Максимальное удобство для адаптации. Я уже как-то писал - теоретически можно написать прогу под новый режим, которая даже его наличие проверять не будет, причем на обычном Спеке тоже увидим вполне вменяемую картинку. Старый экран - просто одно из состояний нового.


7) Зеркалирование тоже с помощью блиттера? Ещё какие аппаратнореализованные эффекты будут?
Блиттер только последовательность стандартных операций организует, их все можно будет и с хоста выполнять. Еще печать "по цвету"/"под цветом", кисть/текстура, вся прочая логика. Возможно транспонирование со скалингом. Геометрия и векторные функции (собс-но это уже не блиттер) - отдельно и только если место останется. Подробно описывать не хочу и не буду, ибо все может измениться.


8) Операции над видеоданными и управляющими регистрами, по механизму подобные EGA будут?
На более "низком" уровне, но удобнее. :) EGA вообще несколько бредоватый.

[Black_Cat]

384x256 планируетсяПардон, я там ошибся с арифметикой :), правильно 384х288, при этом будет 4:3, правда цифры не очень красивые получаются.
именно для совместимого со стандартным экрана256х192 надеюсь имеется ввиду?
По цвету - так есть еще "режим" с 12-битным цветомТ.е. 12 битовых плоскостей - это предполагаемый максимум.
несовместимый режим имеет смысл делать только для столь же нового Спека (на новой элементной базе И с несколько другими характеристиками).Несовмес тимый режим вообще делать не надо, их и так хватает на некоторых клонах. Моё мнение об идеологии совместимости известно - это 4:3 и по возможности целочисленное масштабирование (в случае 384х288 коэффициент масштабирования 1,5). Текстовые экраны - отдельный компромисс.
2) Спрайты переднего плана двигаешь блиттером, а весь задний план? В обеих измерениях?Имелось ввиду что-то типа аппаратного скролла, когда на самом деле двигается экран относительно неподвижного заднего плана.

[Lethargeek]

Пардон, я там ошибся с арифметикой , правильно 384х288, при этом будет 4:3, правда цифры не очень красивые получаются.
Ну будет минимальный бордюр в виде полосок сверху и снизу, да и хрен с ним.


256х192 надеюсь имеется ввиду?
Имеется в виду способ программирования и минимальность патчей.
256x192 никуда из центра экрана не денется.


Т.е. 12 битовых плоскостей - это предполагаемый максимум.
В принципе можно частоту сканирования удвоить и получить труколор, но зачем? Помимо тормозов, память расширять надо будет (иначе бестолку), ЦАП расширять опять же... Ноги нужны либо лишни(е) корпус(а) на последовательные передачи. Фтопку. Пусть 12 хотя бы освоят.


Несовместимый режим вообще делать не надо, их и так хватает на некоторых клонах. Моё мнение об идеологии совместимости известно - это 4:3 и по возможности целочисленное масштабирование (в случае 384х288 коэффициент масштабирования 1,5). Текстовые экраны - отдельный компромисс.
Сейчас и не надо (а что там дальше получится - хрен его знает). А в случае 384x288 коэффициент масштабирования как раз единица. :D Потому что он (кфц) к размеру пиксела относится, а не к APA участку растра.


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

[Black_Cat]

Сейчас и не надо (а что там дальше получится - хрен его знает). А в случае 384x288 коэффициент масштабирования как раз единица. Потому что он (кфц) к размеру пиксела относится, а не к APA участку растра.По подробнее пожалуйста, чёт не вьехал. Я говорил о масштабировании разрешения.

[Lethargeek]

Разрешение - это плотность (количество минимальных базовых элементов (пикселов) на единицу площади).

Бордюр считается, ибо состоит из тех же пикселов.

[Black_Cat]

Разрешение - это плотность (количество) элементов (пикселов) на единицу площади.Тогда это называется удельным количеством пикселов на единицу площади, или плотностью пикселов и оно действительно может быть = const, но отнюдь не 1 (ни в СИ, ни в СГС, если экран конечно обычный). А вот относительная плотность пикселов действительно может быть равна 1.

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

Кстати тут Sonic идею двинул про монохромный режим: http://zx.pk.ru/showthread.php?p=68145#post68145 . Интересует мнение насколько это востребовано и где есть необходимость в применении монохромного вывода.

[Lethargeek]

Тогда это называется удельным количеством пикселов на единицу площади
Дык это И ЕСТЬ разрешение. В данном случае "единица площади" - безразмерная величина - "один экран". Другой пример - как указывается разрешение сканеров/принтеров? Типа "400 dpi", "точек на дюйм" (дюйм - конкретная единица). И одномерные "горизонтальное разрешение" и "вертикальное разрешение" - то же самое.


и оно действительно может быть = const, но отнюдь не 1
Проснись. Единице там был равен коэффициент масштабирования.


Разрешение само по себе - это двумерная абсолютная величина.
А вот и нет, смотри выше. :)
И 256x192 на Спеке - это разрешение не ЭКРАНА, а отображаемого на память УЧАСТКА растра, только и всего. И если я на одном телевизоре нарисую какой-нить спрайт, он и в 256x192, и в 384x256 будет одинакового размера. На песюке отображаемый растр занимает можно считать весь экран, так что здесь таких ошибок не делают.


Поэтому когда говорим "масштабирование разрешения", то имеем ввиду пропорциональное коэффициенту масштабирования увеличение значения размерности по обеим координатам, либо по одной из них.
Именно что плотности. То, что площадь представлена в виде произведения X*Y, роли не играет.
В общем случае коэффициента масштабирования действительно два, свой на каждую ось.

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


Кстати тут Sonic идею двинул про монохромный режим:
Смиялсо. :D

[ZEK]

Короче подучи термины
Aspect ratio зовется при квадртном пикселе (физически) он равен 1, завели его еще во времена CGA/MDA (на писюках, а так может и раньше), и нужен он то бы круг был круглым а не овальным


Типа "400 dpi", "точек на кв.дюйм" (дюйм - конкретная единица).
Точек на дюйм тока не квадратный а по горизонтали или вертикали :) Обычно горизонтальное разрешение посерьезней вертикального.

[Lethargeek]

Aspect ratio зовется при квадртном пикселе (физически) он равен 1, завели его еще во времена CGA/MDA (на писюках, а так может и раньше), и нужен он то бы круг был круглым а не овальным
Совсем не то, aspect ratio - это про соотношение сторон и коррекцию формы.
Хотя "масштабирование разрешения" и правда звучит несколько двусмысленно.


Точек на дюйм тока не квадратный а по горизонтали или вертикали :) Обычно горизонтальное разрешение посерьезней вертикального.
Ачепятка. Пальцы моск опережають.

[vicktech]

В любом случае всем нормальным людям требуется полноценный цвет (32бита на точку). Ну а почему бы не шокировать мир и не сделать разрешуху 16384x12288 точки 32 bit per pixel?
По крайней мере спектроюзерам хватит 512x384 на первое время.
Спрайтовый проц затрудняет работу мозга програмиста в смысле кросплатформенности, и значительно снижает возможные "навороты" в динамической графикой, т.е. получаем уровень денди.