Идея простого расширения стандартного видорежима

[SMT]

(для Lethargeek)можно на клешинг между спрайтами закрыть глаза, всё равно он меньше, чем был в обычных играх с цветным фоном. или делать спрайты одноцветные. а насчёт печати, боюсь ускорения не будет. если рисовать спрайты, то уж рисовать все по новой идеологии (на отдельных спрайтовом и вентильном экранах). раз вывод дублируется можно было экономить только на том, что вывод идёт без чтения с экрана (для сложения с маской). но так не получится, если в одном месте вдруг надо нарисовать 2 спрайта. тогда надо на спрайтовом экране подготовить общие пиксели в знакоместе, а на вентильном - сложить маски по OR. то есть замедление вместо ускорения. нужно пересматривать спецификации

[Advertiser]

[Lethargeek]

Vladimir Kladov> маркеры продаются в канцтоварах Кстати, ручкой удобнее на бумаге
' помечать. Нотепад еще есть, тоже хорошая штука такая...

Ага, в Notepad еще лазить... Кроме шуток, речь же о том, что в Sprite Finder-е не видно
общей картины, приходится все время настройку ширины дергать. А то бы раз нашел спрайт
- и потом его всегда видно.

Vladimir Kladov> В паузе листать надо (однако).

А если надо посмотреть, как программа над своими спрайтами в ОЗУ издевается? Это не
такое уж редкое явление (паузой такие моменты замаешься ловить). Или теневой видеобуфер
можно отслеживать. Вообще неплохо бы Sprite Finder в динамике сделать (если конкретный
пЦ потянет).

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

[Lethargeek]

madcore> Возможность копирования точек через регистры-защелки будет? В отличии от ЕГА,
' хочется, чтобы в этом режиме работали логические операции (включая сдвиг)

Уже загрузил человека подобным вопросом - чтобы хотя бы ldir-ы всякие внутри видеопамяти
работали параллельно для всех разрешенных плоскостей. А насчет остального - почему
"включая" сдвиг? На z80 вроде как нет команд типа "xor [hl],reg", только одноместные
"rlc/rrc/rl/rr/sla/sra/sli/srl/bit/set/res [hl]" - почти все из которых сдвиги.
Для большинства параллельная работа (по крайней мере частично) бессмысленна. Ладно еще
set/res, а вот по команде "rr [hl]" в видеопамять при нескольких разрешенных плоскостях что
должно во флаг переноса попасть? Для подобных команд (а ведь есть еще rrd/rld!) надо изучить
последовательность состояний шины, тогда и станет ясно, что возможно. Хорошо еще, если их
удастся заставить работать при одной выбранной плоскости, а нет - и фиг с ним, это не
фатально (в APA-графике обойдемся, а при адаптации в SCF-mode копия экрана есть в ОЗУ).
Гораздо важнее сделать режим записи байта "со сдвигом" в два "соседних" (на экране) адреса
(причем тоже с учетом OR/AND/XOR), пусть даже с лишним циклом записи (иначе в APA памяти
не напасешься на заранее рассчитанные горизонтальные фазы сдвига многослойных спрайтов).
А остальное тогда пусть глючит, как захочет.

madcore> Дак запрещенные они для того и запрещенные, чтобы в них ничего не писалось.
' А надо, чтобы устанавливались все битовые плоскости в соответствии с выбраным цветом.

Зачем лишний регистр, если битовый список разрешенных и запрещенных плоскостей фактически
и есть цвет. Я тут подумал - ну можно спецрежим записи ввести, причем даже с вариациями
OR/AND/XOR (то есть по OR просто печатается цвет, по AND оставляется только этот цвет
в совпадающих с единицами в байте пикселах (остальные - черным), по XOR все совпадающие
- в черный, а несовпадающие - в этот цвет красить). Ну или что-то типа этого. Вопрос в
том, насколько это схему усложнит. Может, не стоит и огород городить, особенно учитывая,
что того же можно добиться обычным способом за два прохода (пусть и медленнее).

madcore> О количестве режимов говорить еще рано.
' ЕГА, конечно, копировать один-в-один не стОит.

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

madcore> Область атрибутов я предлагал использовать для выбора палитры для знакоместа...
' ... Цветность мы урезаем только при эмуляции (путем настройки палитры) задних планов.
' Зато этих планов можно иметь, сколько захотим, и любой глубины цвета, лишь бы плоскостей
' хватало. А если нам не нужно, используем все плоскости для одного полноцветного экрана,
' и никакие лишние фоновые экраны не будут висет мертвым грузом. В моем варианте новое
' расширение не является чем-то инородным для спека, цепляемым где-то сбоку. ZX-экран
' является частным случаем нового режима, т.е. никаких отдельных режимов для совместимости
' нет. Возможно, мои объяснения несколько сбивчивы и сумбурны, постараюсь позже оформить
' мою идею более последовательно...

Вот-вот, постарайся, а то впечатление совершенно бредовое. Что значит "планов можно иметь,
сколько захотим, и любой глубины цвета, лишь бы плоскостей хватало"? Глубина цвета - это
количество бит на точку, а вовсе не общий размер палитры! Тут слои как ни распределяй,
все равнов итоге урезание цветности. И что такое "лишние" фоновые экраны? Я, кстати,
подумываю об объединении двух 64-цветных экранов в один 4096-цветный, причем это решение
логически обоснованное и кучи новых железок в моей схеме не потребует. Правда, и годятся
такие "полноцветные экраны без фона" только для просмотра картинок. И ZX-экран, кстати,
является частным случаем SCF-mode, не такой уж он "отдельный".

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

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

[Lethargeek]

SMT> можно на клэшинг между спрайтами закрыть глаза, всё равно он меньше, чем был
' в обычных играх с цветным фоном. или делать спрайты одноцветные. а насчёт печати,
' боюсь, ускорения не будет. если рисовать спрайты, то уж рисовать все по новой идеологии
' (на отдельных спрайтовом и вентильном экранах). раз вывод дублируется можно было
' экономить только на том, что вывод идёт без чтения с экрана (для сложения с маской).
' но так не получится, если в одном месте вдруг надо нарисовать 2 спрайта. тогда надо
' на спрайтовом экране подготовить общие пиксели в знакоместе, а на вентильном - сложить
' маски по OR. то есть замедление вместо ускорения. нужно пересматривать спецификации

Ну смотри. Вот что часто встречается в игрушках для вывода спрайта на заполненный чем
угодно (в том числе другими спрайтами) фон (чтобы пример был менее громоздким, ЦИКЛ
означает "цикл по всему спрайту", с изменением экранного адреса в bc как по горизонтали,
так и по вертикали):

ld bc,^экран
ld hl,^маска
ld de,^спрайт
ЦИКЛ
- ld a,[bc]
- and a,[hl]
- ex de,hl
- or a,[hl]
- ex de,hl
- ld [bc],a
- inc de, hl
- (изменение bc)
ПОВТОРИТЬ

А для SCF-mode будет:

out... ; (вывод по AND в вентильный и спрайтовый экраны)
ld bc,^экран
ld hl,^маска
ЦИКЛ
- ld a,[hl]
- ld [bc],a ; равносильно "and [вентиль],a" + "and [спрайты],a"
- inc hl ; то есть напечатали маску и заодно стерли попавшиеся куски спрайтов
- (изменение bc)
ПОВТОРИТЬ
out... ; (вывод по OR в спрайтовый экран)
ld bc,^экран
ld de,^спрайт
ЦИКЛ
- ld a,[de]
- ld [bc],a ; равносильно "or [спрайты],a"
- inc de
- (изменение bc)
ПОВТОРИТЬ

Для одноцветных спрайтов нужен только первый цикл, так как маска и спрайт совпадают
(только используется цвет PAPER спрайтового экрана, а не INK).

Для двухцветных на первый взгляд SCF-mode несколько медленнее (если в оригинале спрайт
и маска печатались за один проход). НО! Мы забыли одну "мелочь", а именно: запоминание
и восстановление фона. То есть для стандартного экрана нужно сначала стереть старые
спрайты (и не просто "стереть", а забить картинкой), потом запомнить фон в новом месте
и уже после этого вывести туда спрайт. А в SCF спрайты "стираются" элементарно
и фон запоминать не надо. То есть весь "рабочий цикл" в SCF выполняется быстрее.

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

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

(Опять упрощенно):

out... ; (временно отключили автопересчет адреса)
out... ; (вывод по AND в вентильный и спрайтовый экраны)
ld de,^экран
call "пересчет адреса в родной формат" ; быстро, с таблицей
ld bc,de
ld hl,^маска
ЦИКЛ
- ld a,e
- call "цепочка ldi"
- ld e,a
- inc d
ПОВТОРИТЬ
ld de,bc
ld hl,^спрайт
out... ; (вывод по OR в спрайтовый экран)
ЦИКЛ
- ld a,e
- call "цепочка ldi"
- ld e,a
- inc d
ПОВТОРИТЬ
out... ; (включили обратно автопересчет адреса)

Понятно, что могут быть нюансы, и все это можно сделать немного по-другому, но идея ясна?
Цепочки ldi могут быть любого размера вплоть до 256 с ret в конце, и call адресуется в
произвольное место цепочки. Для прямой адресации видеокарты это лучший способ вывода
графики в обоих режимах - и SCF, и APA (просто по вертикали в "среднем" куске экрана
байтов гораздо больше, чем по горизонтали). Это я еще молчу про извращенные варианты
со стеком...

Примечание: не путать ldi из ОЗУ компа в отображаемую видеопамять с ldi исключительно
внутри самой видеопамяти! (Связанные с ним вопросы пока выясняются.)

[Lethargeek]

Очередной вариант спецификаций.

Добавлена схема автопересчета адреса и сравнительные размеры экранов (файл "_mapadr.xls")

03-11-2005 кое-чего поправлено...

Все, этот вариант похоронен 25-11-2005.

[madcore]

Lethargeek>Уже загрузил человека подобным вопросом - чтобы хотя бы ldir-ы всякие внутри видеопамяти работали параллельно для всех разрешенных плоскостей.

А без этого от режима и толку ноль..


Lethargeek>А насчет остального - почему
"включая" сдвиг? На z80 вроде как нет команд типа "xor [hl],reg", только одноместные
"rlc/rrc/rl/rr/sla/sra/sli/srl/bit/set/res [hl]" - почти все из которых сдвиги.
Для большинства параллельная работа (по крайней мере частично)

Дык я говорил про сдвиг адаптером, а не цпу


Lethargeek>Гораздо важнее сделать режим записи байта "со сдвигом" в два "соседних" (на экране) адреса
(причем тоже с учетом OR/AND/XOR), пусть даже с лишним циклом записи (иначе в APA памяти не напасешься на заранее рассчитанные горизонтальные фазы сдвига многослойных спрайтов).

Так я про то и говорю! Нужен сдвиг как на ЕГА, только _нециклический_, а чтобы байт мог записаться в соседние 2.


madcore> Дак запрещенные они для того и запрещенные, чтобы в них ничего не писалось.
' А надо, чтобы устанавливались все битовые плоскости в соответствии с выбраным цветом.
Lethargeek>Зачем лишний регистр, если битовый список разрешенных и >запрещенных плоскостей фактически и есть цвет.

Нет не фактически, ибо в запрещенных плоскостях может уже быть записан "1", а внашем цвете там "0".

Ладно, об остальном пока не буду, еще подумаю.


Lethargeek>Я, кстати,
подумываю об объединении двух 64-цветных экранов в один 4096-цветный, причем это решение логически обоснованное и кучи новых железок в моей схеме не потребует.

Т.е., фактически у тебя получится экран 12 плоскостей, так? Так вот я это и мею ввиду, что его разделить на 2 можно просто установкой палитры! Ничего специально для этого городить не надо. И распределить количество бит(плоскостей) на точку между планами мы можем как захотим. И вообще, можем сделать хоть 6 планов по 2 бита на точку. И экраны можно сделать полупрозрачные. А рисовать в каждый в отдельности просто запрещая чужие битовые плоскости.
Вот, чтоб была яснее идея, набрасал щас прогу(для ПЦ;(), которая разбивает 256-экран на два 16-цветных. Правда, адресация там не плановая, а линейная, потому условно первая половинка байта - пердний план, вторая - задний. Пикрепил к сообщению.


Lethargeek>Ты лучше напиши наподобие того, как я объяснял идею вентильного экрана:
что в каждой плоскости записано, и что мы увидим на экране в результате.

Постараюсь, просто я сейчас пытаюсь состыковать свою и твою версию.

[Lethargeek]

madcore> Так я про то и говорю! Нужен сдвиг как на ЕГА, только _нециклический_,
' а чтобы байт мог записаться в соседние 2.

Не в соседние, а в нужные два. Соседние они только на экране, а на самом деле смещение
по горизонтали 256 байт - в спецификациях приведена раскладка видеопамяти.


Lethargeek> Зачем лишний регистр, если битовый список разрешенных и
' запрещенных плоскостей фактически и есть цвет.

madcore> Нет, не фактически, ибо в запрещенных плоскостях может уже быть
' записан "1", а в нашем цвете там "0".

НЕТ, ФАКТИЧЕСКИ, - мало ли что где записано, мы ж говорим про ВЫБРАННЫЙ цвет.

Что касается записи - условно назовем варианты "моим" и "твоим".
Плюс для простоты рассмотрим всего три битовых слоя (красный, синий, зеленый).

ЗАДАЧА ПЕРВАЯ: на произвольном фоне напечатать символ/нарисовать отрезок и т.п.

"твой" вариант - без проблем, выбрали цвет и за один проход отправляем байты во все слои.

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

ЗАДАЧА ВТОРАЯ: на произвольном фоне напечатать восьмицветный спрайт.

"мой" вариант - сначала печатаем маску спрайта по AND во все слои, как и полагается.
После чего печатаем туда же три цветовых слоя спрайта - R,G,B. Всего четыре прохода.

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

Вопрос на засыпку: какой из двух вариантов следут выбрать? Правильно, ОБА!
Но здесь все опять упрется в сложность схемы. Можно придумать универсальный режим записи,
например, действительно переназвать регистр разрешения слоев в регистр выбора цвета
(или, что точнее, регистр различия слоев), и для обоих "типов" слоев - теперь не
разрешенных и запрещенных, а просто "единичных" и "нулевых", устанавливать свой режим
записи (и чтения), то есть по одному биту на разрешение чтения/записи, по одному биту
на NOT, и по два на OR/AND/XOR (см. поправленные последние спецификации). Такая схема
справится с любыми осмысленными режимами записи и чтения (хочешь - проверь ).
Соблазнительно. Но вот делать это в железе... ладно, об этом ниже. Пока же, если
придется от чего-то отказаться, лучше оставить "мой" вариант, как более универсальный
и ориентированный на спрайты (это важнее векторной графики, которую по-прежнему можно
будет делать в одном цвете с той же скоростью).


madcore> Т.е., фактически у тебя получится экран 12 плоскостей, так? Так вот я это и
' имею ввиду, что его разделить на 2 можно просто установкой палитры! Ничего специально
' для этого городить не надо. И распределить количество бит(плоскостей) на точку между
' планами мы можем как захотим. И вообще, можем сделать хоть 6 планов по 2 бита на точку.
' И экраны можно сделать полупрозрачные. А рисовать в каждый в отдельности, просто
' запрещая чужие битовые плоскости.

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

Пусть сначала хотя бы предварительный (неоптимальный) вариант схемы появится. Пока только
еще отдельные вопросы выясняем. И спецификации, которые я вложением кидаю, тоже не на
пустом месте взялись. Так, идея 4096-цветного экрана основана на том, что в любом режиме
контроллер на каждые восемь пикселов читает из слоя по два байта - в SCF это пикселы и
атрибут, в APA пикселы заднего и переднего планов. И если два плана не нужны, почему бы
не объединить полученные значения пикселов, увеличив разрядность. И "плоскостей" (то есть
физически, как отдельных линеек памяти) у меня 6, а не 12, и писать одновременно даже
в 4096-цветном режиме можно по-прежнему только в 6, то есть вывод в два раза медленнее.
Но просто для картинок пойдет. Причем заметь, что в любом режиме схема чтения контроллером
из видеопамяти практически не меняется. А 6 плоскостей тоже не случайно - это позволит
в крайнем случае обойтись без палитры, а спековские IGRB легко перевести в удобную для
ЦАП форму GRBgrb, аналогично и 64 цвета масштабируются в 4096. А еще это даст возможность
легко менять яркость планов относительно друг друга (обычно лучше, чтобы спрайты были ярче).

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

Не стоит забывать, что видеокарта планируется для СПЕКТРУМА. 16-битной консоли из него
все равно не получится (а если какой-то суперчип прикрутить, еще неизвестно, что к чему
прикручивается, и что получится в результате - навороченный Спек или нерационально
используемый видеочип ). Главная задача - обеспечить неплохие возможности при
сохранении легкости программирования именно для спектрумистов, то есть важен баланс
возможностей/ограничений с одной стороны и сложности реализации с другой. А не просто
"голые" характеристики, как бы завлекательно они ни выглядели.

[CHRV]

Не стоит забывать, что видеокарта планируется для СПЕКТРУМА. 16-битной консоли из него
все равно не получится (а если какой-то суперчип прикрутить, еще неизвестно, что к чему
прикручивается, и что получится в результате - навороченный Спек или нерационально
используемый видеочип ). Главная задача - обеспечить неплохие возможности при
сохранении легкости программирования именно для спектрумистов, то есть важен баланс
возможностей/ограничений с одной стороны и сложности реализации с другой. А не просто
"голые" характеристики, как бы завлекательно они ни выглядели.

MSX не шестнадцати-битная консоль, а v9990 специально создан для 8битного процессора (я бы даже сказал специально под архитектуру Z80). Если вы этого не знаете, то не надо пудрить другим мозги. Я за трейдом слежу и не желаю чтобы изза своей неосведомленности дизориентировали других. Будьте внимательны!

[Lethargeek]

CHRV> MSX не шестнадцати-битная консоль, а v9990 специально создан для 8битного процессора (я бы даже сказал специально под архитектуру Z80). Если вы этого не знаете, то не надо пудрить другим мозги. Я за трейдом слежу и не желаю чтобы изза своей неосведомленности дизориентировали других. Будьте внимательны!

Упоминался "какой-то суперчип", а не конкретно v9990. Причем в контексте именно завышенных (на мой взгляд) аппетитов madcore в вопросах разработки оригинального девайса. Чего ему хочется, было скорее для 16-биток, ИМХО.

[Lethargeek]

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

А это открывает уже такие возможности...

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