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

[Lethargeek]

Размышляя на тему реализации "внутренних" ldir-ов, я подумал: что, собственно, происходит
в разных ситуациях при таких пересылках? Например, ldi из ОЗУ в видеопамять - сначала байт
читается из обычной страницы ОЗУ, потом записывается в перехватываемую страницу - и
одновременно в видеопамять через логическую операцию с регистрами-защелками. И наоборот,
для ldi из видеопамяти в ОЗУ сначала в защелки читаются байты, потом они суммируются
какой-то логической операцией и полученный байт через процессор отправляется в ОЗУ.

А при "внутреннем" ldi (то есть когда обращение к обоим адресам источник/приемник
перехватывается видеокартой) что произойдет? То и другое - читаются байты, суммируются,
полученный байт процессором отправляется в ОЗУ - и одновременно обратно в видеопамять.
То есть во все слои попадают одинаковые байты, что очень плохо. Очевидно, что от проца
требуются только адреса приемника и источника, а данные не нужны - и если байт данных при
записи проигнорировать, то в адрес-приемник в видеопамяти попадет содержимое защелок,
полученное перед эти при чтении, то есть произойдет параллельная пересылка, чего мы и
добивались!

Спрашивается, как понять, когда игнорировать данные при записи, а когда нет? Не делать
же анализатор кода на видеокарте с отловом нужных команд... Можно поступить так:
если сразу после попытки чтения происходит попытка записи (то есть между ними не было
выборки новой команды - сигнал M1 не появлялся), тогда игнорируем. А если после выборки
сразу идет запись, тогда безусловно пишем, что на шине.

Понятно, что такой ldi годится только для параллельного копирования данных в видеопамяти,
то есть прежде всего для "побайтных" прокруток изображения. Вот если бы можно было делать
такие пересылки с учетом логических операций! А для этого нужно просто ввести "второй
комплект" регистров-защелок (то есть теперь имеем отдельные для чтения и для записи) и
распараллелить схему выполнения логических операций. А заодно дать возможность отдельно
выбирать базовые 16K страницы видеопамяти для чтения и записи. То есть запись происходит
так: байт, поступивший от проца, распределяется по Ч-защелкам, одновременно заполняются
данными из видеопамяти З-защелки, выполняются логические операции и результат из З-защелок
записывается обратно в видеопамять. А вот при выполнении "внутреннего" ldi прочитанные из
видеопамяти байты сначала попадут в Ч-защелки, суммируются "на выход" (результат отдается
процу) и остаются в Ч-защелках. Теперь, когда придет запрос на запись, Ч-защелки
байтом, поступившим по шине, не заполняются, а сразу производятся логические
операции с заполненными из адреса записи З-защелками и собственно запись в видеопамять.
Добавить к этому возможность записи "со сдвигом" и "зеркальной" записи, как раньше.

[Lethargeek]

Какой отсюда вывод? А такой, что спрайты можно теперь хранить прямо в видеопамяти,
и выводить на любой фон со скоростью, сопоставимой со скоростью работы обычной спековской
графики - и это все в 64 цветах! Причем маску можно (нужно!) хранить в обычном ОЗУ, что
сэкономит место в видеопамяти под сами спрайты. Даже если в APA-режиме используются все
четыре базовых страницы (два переключаемых задних и два передних плана), все равно в
каждой странице остается 6*4K, что с учетом масок в обычном ОЗУ составит эквивалент 16-32К
обычной спековской графики. Да еще и в неотображаемых (отсекаемых бордюром) областях
можно чего-нибудь хранить. Плюс менее важные спрайты/тайлы можно по-прежнему печатать из
ОЗУ за несколько проходов.

Процедура вывода "спрайта" в APA-режиме будет выглядеть примерно так:

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

Можно попытаться еще "упихать" все это в один цикл (с некоторыми аппаратными
доработками), но не уверен, что получим существенное ускорение.

[Lethargeek]

Следующая мысль: если APA-графика сможет работать с той же скоростью, что и спековская,
нафиг нужен отдельный SCF-режим с собственной логикой на видеокарте - если можно настроить
обычный APA-режим на совместимость со стандартным спековским. Короче, "я тебя породил,
я тебя и убью" - (c) Тарас Бульба. Вместо SCF реализуем "атрибутный" APA.

Основное отличие от обычного "двухпланового" APA - читаемый по строке второй байт считается
не графикой "переднего плана", а атрибутом (есс-но, счетчик ходит уже по другим адресам).
Причем атрибут применяется только к двум дегко опознаваемым цветам - белому и черному
(111111 и 000000). То есть в каждом знакоместе имеем два "атрибутнозависимых" цвета плюс
свободно используем остальные 62.

Очевидно, что при движении по строке на каждые восемь 64-цветных пикселов читается сразу
шесть "атрибутов". Эту "избыточность" можно использовать так - каждый "атрибут" будет
состоять из двух байт, причем второй для совместимости используется только при несовпадении
их битов BRIGHT - он определяет дополнительные три бита цветов INK и PAPER, то есть
уже будет тоже по 64 цвета для INK/PAPER. И FLASH-и отдельные можно сделать. И отдельно
включаемый BRIGHT2, и даже, наверно FLASH-color, хотя незачем, по-моему - где они были?
Ну, можно еще гигаскрин аппаратный добавить - просто автоматически переключать базовые
страницы видеопамяти на каждой новой строке.

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

Итого истрачено четыре байта из шести. Оставшиеся два можно использовать как этакий
"флажок", определяющий, надо ли гасить остальные (неатрибутнозависимые) цвета в случае,
когда INK=PAPER. И тоже для двух вертикальных половинок.

В "режиме совместимости" постоянно включены запись "с заменой" во все плоскости, то есть
все абсолютно прозрачно для старого спековского софта. Чтение при этом можно либо вообще
запретить (в ОЗУ есть копия экрана), либо суммировать плоскости по AND (тогда пикселы
остальных цветов получатся нулевыми - PAPER) или по OR (тогда единицами - INK). Плюс
режим "игнорирования данных" надо сделать отключаемым, потому что кроме ldir-ов еще
всякие rr/rl [hl], set/res [hl] и rrd/rld производят и чтение, и запись в память.

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

[Lethargeek]

Уже некорректно говорить о разных "видеорежимах", фактически это режимы работы второго
счетчика адресов и различные способы интерпретации второго прочитанного байта (*6 слоев).
Фактически видеокарта будет теперь работать в одном и том же режиме без всяких явных
переключений по следующей общей схеме (опуская бордюр и смену-кадров/строк):

1. Читаются шесть пар байт из всех плоскостей
2. Определяются INK и PAPER для атрибута
3. Для каждого пиксела (первый байт) определяется его код (цвет)
4. Если это 111111 или 000000, меняем их на INK и PAPER соотв-но
5. Для каждого пиксела (второй байт) определяется его код (цвет)
6. Если он не "прозрачный", заменяем им код пиксела, полученного из первого байта
7. Из формата GRBgrb код преобразуется в формат GRB000grb000 для ЦАП
8. Эти нули заполняются кодом второго байта для получения 4096 цветов

Весь фокус в том, что в "атрибутном APA" на этапе 5 ВК всегда подсовывается "прозрачный"
цвет, а на этапе 8 - нули вместо кода второго байта. В обычном "двухплановом" APA на
этапе 2 INK всегда равен 111111, а PAPER - 000000, на этапе 8 - снова всегда нули. И
наконец, в 4096-цветном режиме те же INK и PAPER подсовываются на 2 этапе, "прозрачный"
цвет на 5 этапе, а на 8 этапе цвет правильно расширяется в формат GRBGRBgrbgrb

Итого субъективно имеем следующие "режимы" (не считая бессмысленных вариантов):

- стандартный режим - частный случай "атрибутного" APA-mode, обрезан бордюром
- полный "атрибутный" APA - 64 цвета, раздельный FLASH, на весь экран (или его часть)
- он же с вертикальными половинками/горизонтальными половинками/четвертушками
- он же с hardware multicolor (второй счетчик бегает по тем же адресам в другой странице)
- этот же multicolor еще и с вертикальными половинками (то есть "атрибут" 1x4)
- "двухслойный" APA-mode - 64 цвета, передний и задний план
- "сдвоенный" APA-mode - 4096 цветов, пикселы разных планов "сцепляются"

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

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

[ASDT]

"пока самый простой (но глючный)вариант расширения до цвета на точку у AlCo из ZX.SPECTRUM"
А можно подробнее ... или где ...

[CHRV]

"пока самый простой (но глючный)вариант расширения до цвета на точку у AlCo из ZX.SPECTRUM"
А можно подробнее ... или где ...

В основном это предназначено для Пентагона.
Это читать в Алко-ньюс на Виртуал ТрДос.

[Konstantin Denisov (2:5095/1.104)]

FromNet: Podolsk_Russia (Podolsk_Net)

Hello, Дмитрий!

Octomber, 14, 2005 22:52 Дмитрий Малычев Wrote to All :

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

Кстати, как насчет переделки в такую видеокарту старых 48К Спектрумов,
пылящихся на антресолях, и тому подобного барахла?

Это весьма было бы интеpесно для некотоpых опpеделенных задач.
И таким обpазом мы пpиблизились к pазpаботке пpинципиально но-
вого компьютеpа на Z80 !!! Spectrum 1982 ,Enterprize 1984,
???? - 2005.

P.S. CHRV, а что, последнее предложение недостаточно конкретно...
Или только и можем, что чайников "сизым дымком" пугать?

... ,но фpизеpаааа!!! БОЛЬШЕ ФРИЗЕРОВ,БОЛЬШЕ ФРИЗЕРОВ,БОЛЬШЕ ФРИЗЕРОООООВ!!!

[jtn]

... ,но фpизеpаааа!!! БОЛЬШЕ ФРИЗЕРОВ,БОЛЬШЕ ФРИЗЕРОВ,БОЛЬШЕ ФРИЗЕРОООООВ!!!

...однако
не точная цитата =]]

[ASDT]

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

[madcore]

2 Lethargeek:
Ну так чем всё закончилось?