Исходить из традиционного экрана

[andrews]

Это понимание выработалось лично у меня еще в 1997 году.
Так как мэйнстрим это утяжеление экранов, удорожание и усложнение железа и софта(для разработчика), а также непрерывная "дойка" потребителя, то андеграунд должен зафиксить сложность экрана и, используя прогресс в технологиях, упрощать, удешевлять, делать все более доступным для потребителя. Полярная антитеза.

[stop-7]

Зафиксировать экран, или наращивать его наиболее прямым способом, в лоб, добавляя битовые плоскости?

[andrews]

По пикселям и цвета ограничить и тем самым уменьшить требования к пропускной способности шин и прочему за что сейчас надрывается мэйнстрим.

[stop-7]

>> по пикселям
я, Летаргик и BC тож так считали.

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

1) В одном случае "статичные картинки" - он будет использовать все битовые плоскости, которые в его распоряжении. И тем самым добиваться нужной ему фотографичности.
2) Если речь пойдет про анимацию - тут 1-4 битовые плоскости
3) Если речь о консервативной проге - пожалуйста, используй только один битплан (традиционный спековский битплан) - остальные не трогай.
4) добавить 1 порт - выбор битпланов, которые будут использоваться.
Скажем так:
0000 0001

Включить только 1 битплан. Запись в остальные битпланы не приводит к изменениям в изображении на дисплее.

Или же речь о действительно жесткой фиксации, отказа от наращивания видео - как принципиальной позиции?



кто не в курсе, по битпланам (битовым плоскостям)
http://zx.pk.ru/attachment.php?attachmentid=4935&d=1175483397

[Lethargeek]

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

[andrews]

Мне нужна программная модель(на С/С++ пжлста). Я скомпилю, загружу и скажу сколько это отгрызло ресурсов. ПЛИС у меня не предусмотрено.
Blackfin в ZX Yellow Spectrum это почти как SX Scenix в BASIC STAMP :cool:

[stop-7]

Если наглядно, то вот например так:



char vidram[32][192] [24];
char vidport;
void show( void ); /* функция перед "склейкой битпланов"
считывает "vidport".
Видеомассив "vidram" */


Если это похоже на то, что ты просишь, то можно и продолжить...

[PegasResearch]

andrews, действительно, почему бы не сделать конфигурируемое разрешение и глубину точек? Наподобие VGA, в котором программно можно любое разрешение выставить.
Т.е. дать пользователю возможность выбирать не из заданного набора видеорежимов, а дать способ конфигурирования видеорежима. Включая строчные/кадровые частоты.
stop-7, а почему стоит ограничиваться тьлько битовыми плоскостями? Посмотри на CGA/EGA - они все пришли к VGA, где вообще битовых плоскостей нет. Т.к. проблематично создать быстрый алгоритм разбиения растра на плоскости. Т.е. работать он будет медленнее, чем запись по одномоментно 8 бит, т.к. потребуется несколько логических операций, да и обращений к памяти будет тоже несколько, вместо гаратнированно единственного чтения и записи.

[stop-7]

PegasResearch
ну, почему стоит ограничиваться только битовыми плоскостями? Вопрос дизайна.
Из более веских аргументов - Масштабирование, и, как говорят в народе, желание подержаться одной рукой за письку и сиську. Т.е. нарастить глубину цвета, и при этом не терять совместимость со стандартным сп-экраном... Масштабирование, я понимаю его конечно на не очень-то крутом уровне... ну например так, если кто-то придет к выводу ставить проц на 14Мгц, то старый принцип программирования видеосистемы по прежднему будет работать на новой машине. Это стабильность, гут.

В третих, открывается интересная возможность "доработать" старые игры, работающими только со старым стандартным экраном (т.е. с одним битпланом). Как в свое время переработали старые проги под TRDOS и AY.

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

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

[andrews]

STOP-7 Да, именно это я и прошу, с учетом того, что видеоконтроллер будет реализован программно для процессора, у которого доступ к GPIO занимает несколько наносекунд.

[Lethargeek]

Посмотри на CGA/EGA - они все пришли к VGA, где вообще битовых плоскостей нет.
Конечно же есть - во всех доставшихся от EGA режимах. А в новых режимах - байтовые плоскости. Что сильно помогало на слабых процессорах, даже в существующем куцем варианте.


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


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


да и обращений к памяти будет тоже несколько, вместо гаратнированно единственного чтения и записи.
Зато для 8 точек сразу.



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

[Sonic]

По поводу увеличения глубины цвета...
http://aleste520.narod.ru/html/rainbow.html - интересный подход. Может на что сгодится?

[stop-7]

Графическая система была расширена оригинальным способом: теневая страница 16КБ памяти хранила информацию о цвете. На каждые 8 точек графического буфера был 1 байт цветовой памяти, определявший цвета фона и изображения из 16 цветов. На выходе двух портовая память палитры.
иными словами, атрибут INK/PAPER на полоску из 8 пикс.?

[Sonic]

Да. Только весь прикол не в этом, а в способе загрузки.

[Lethargeek]

Только весь прикол не в этом, а в способе загрузки.
Ничего принципиально нового. Кастрированный EGA.

[Sonic]

Да блин, я вот про это:
Возможность доступа к памяти цвета было обеспечено специальным регистром. Процессор устанавливал цвет в регистре и впоследствии данный цвет применялся ко всем байтам графики, которые изменял процессор. При чтении из видеопамяти информация о цвете автоматически прочитывалась в регистр цвета. Этот механизм позволял копировать участи графики вместе с цветом.
В результате вместо одной загрузки мы фактически выполняем две. Мы работаем с цветом, но скорость та же, как если бы мы работали с монохромом.
Приведу пример практического использования применительно к нам.
Представим себе, что в дополнение к нашему ZX-экрану (с атрибутами 8x8) мы имеем теневое ОЗУ атрибутов в формате "атрибут на линию", т. е. атрибутами 8x1. Представим себе, что логика работы видеоконтроллера такова, что при записи данных по относительному адресу X (относительно начала фреймбуфера) в область пикселов вызывает автоматическое копирование значения из области атрибутов ZX (которая 8x8), в теневую область атрибутов (которая 8x1) по тому же относительному адресу X. Что получаем в результате: а получаем мы возможность рисовать в хардварном мультиколоре хоть из бейсика, при 100%-ной совместимости с синклеровским экраном и всем существующим софтом.
Только пожалуйста не бейте ногами - это не законченная идея, это пример, придуманный на ходу за 10 секунд.

[PegasResearch]

Сообщение от Lethargeek
Конечно же есть - во всех доставшихся от EGA режимах. А в новых режимах - байтовые плоскости. Что сильно помогало на слабых процессорах, даже в существующем куцем варианте.
Я под VGA подразумевал 256-цветный 320х200 ;-) Режимы от EGA остались лишь для совместимости - "не сразу всё устроилось"...


Зато для 8 точек сразу.
Ага, 1-битных точек (!)


Если даже все чисто программно, то пользующемуся этим зетнику хватит.

Не все так просто. Например, программная реализация блендинга в битпланах (на нескольких логических операциях) может оказаться быстрее "лобового" решения в линейной модели (сложением), особенно если глубина цвета произвольна (хотя конечно и от железа зависит). Я уж не говорю про произвольное разбиение на слои и их независимую обработку (включая прокрутку)
Опять же - я имею в виду 90% всех случаев. Абсолютно согласен, что в 10% случаях битпланы могут оказаться не хуже, а может и чем-то лучше. Но разрабатывать девайс для 10% случаев, не обращая внимание на 90% - неправильно. И VGA это подтвердил - воспользованностью режима 320х200 и X-режимов.

Да, только одного на весь экран (писишный подход). А при фиксированных "базовых" частотах можно смешивать несколько "режимов" одновременно в кадре.
Про это вроде речи не шло... чем это принципиально отличается от нескольких видеоплоскостей с альфа-прозрачностью (либо просто с прозрачностью, как DirectX 2.0)?

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

Добавлено через 9 минут
Кстати, по поводу "базовых частот" и идее сложного видеоадаптера вообще. Вспоминается процессор Sigma SMP (Sequre Media Processor) - суть в том, что там для отображения используется несколько физических выходов (S-Video, component, composite, HDMI/DVI). Так вот, в самой распространённой версии проуцессора миксер (источник видео) только один, и на выходах установить отдельное разрешение можно только при совпадении "частоты сканирования" у этих разрешений. Помниться, мои эксперименты с попыткой это сделать ни к чему не привели... да и поставляемый набор семплов не смог с этим справится - один из выходов выдавал цветовой шум. И это на известном во всём мире процессоре, на разработку которого было потрачено немало усилий...
То есть это я к чему - не все идеи, хорошо описанные на бумаге, успешно реализуются в железе. Особенно идея совмещения видеорежимов ;-) Хотя, если все "видеорежимы" на самом деле - один режим более высокого разрешения, то почему бы нет?...

[Lethargeek]

Да блин, я вот про это:
И я про это. :D На EGA при чтении/записи то же самое (одновременная обработка всех относящихся к сгруппированным пикселям байт) и происходит. Как минимум.

Как все эти байты интерпретируются при отображении - дело другое. Но к "способу загрузки" уже никакого отношения не имеет.



Приведу пример практического использования применительно к нам. Представим себе...
Когда-то в начале 90-х (в век рассыпухи и пресловутого "кулибинства" даже на уровне производителей) подобные "дешевые и сердитые" решения имели какой-то смысл, сейчас даже начинать рассмотрение проблемы ВК для Спектрума надо с чего-то более сложного (и главное - универсального). С общего, а не с частного. Потому что если потом начать развивать девайс, сильно увеличивается количество необязательных наворотов (навешенных только потому что в базовом итд варианте чего-то не хватало). Вот например, походу в описанной реальной схеме даже ink и paper нельзя автоматически разделять, то есть с клэшингом надо все равно бороться программно (это помимо присущего даже аппаратному мультиколору остатков атрибутного клэшинга). То есть по каждой мелочи придется схему усложнять, усложнять...

Добавлено через 20 минут

Я под VGA подразумевал 256-цветный 320х200
VGA это видеоадаптер ваще-то (а не один видеорежим). :) Причем "в железе" именно что планарный (был изначально по крайней мере, как современные железяки устроены - не в курсе, мож там уже EGA эмулируется микрокодом или еще чего пострашнее).


Ага, 1-битных точек (!)
Нет, "сколькиугоднобитных" точек (в отличие!). Это детализация обращения такс-зать "однобитная".


Опять же - я имею в виду 90% всех случаев. Абсолютно согласен, что в 10% случаях битпланы могут оказаться не хуже, а может и чем-то лучше.
Распространенное заблуждение. Все ровно наоборот - для двухмерной графики битпланы в общем случае не хуже, а в подавляющем большинстве частных случаев - гораздо лучше. Для медленных восьмибитных процессоров - без всяких оговорок.


Но разрабатывать девайс для 10% случаев, не обращая внимание на 90% - неправильно. И VGA это подтвердил - воспользованностью режима 320х200 и X-режимов.
Вот именно. Причем X-режимы эффективно использовались как раз в силу своей планарности (эффективно, несмотря на общую кривость железа пц). Причем для медленных 16-битных процессоров до 286 (и первых 386) быстрее были именно X-режимы. Потом просто процы по скорости обогнали видеоадаптеры, и стало выгоднее всю графику через регистры и теневой-видеобуфер-в-обычном-ОЗУ ворочать. В настоящее время снова рулит обработка внутри видеоадаптера, причем в принципе уже пофиг, как именно "там внутри" организовано хранение растра (все равно напрямую программировать неэффективно). Но это сейчас и на пц. На Спеке (так исторически сложилось) положение несколько другое. ;)

Добавлено через 29 минут

Кстати, по поводу "базовых частот" и идее сложного видеоадаптера вообще. Вспоминается процессор Sigma SMP... Хотя, если все "видеорежимы" на самом деле - один режим более высокого разрешения, то почему бы нет?...
Необязательно именно "разрешения" (про SMP вообще что-то не в кассу).

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

[andrews]

Господа, товарищи...хорошо бы уже программные модели для иллюстрации начать приводить...на C или VHDL