SMT> ещё неясно, как суммируются фоновый/спрайтовый/вентильный экраны

madcore> А эту идею я вообще не понял...

Значит, так: представим, что на каждой битовой плоскости (линейке памяти) "сидит" некоторое
подобие ULA, точнее, ее кусок. Точно так же, как в стандартном видеорежиме, в цикле по
отображению строки читается по два байта - пикселы и атрибут - ПАРАЛЛЕЛЬНО ДЛЯ ТРЕХ
"ЭКРАНОВ" (плоскостей). (Я здесь скролл пока не учитываю, чтоб понятней было.)

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

Ну и теперь аналогичный ULA цикл по 8 битам, только сначала анализируем соответствующий
вентильный бит, и если он равен нулю, то в определении цвета используется одна пара
байт "пикселы-атрибут", а если единице - другая. Полученный номер цвета отправляется
в ЦАП и пиксел выводится на экран. То есть две "юлы" стараются, работают, каждая выдает
готовый пиксел, и вот тут вмешивается вентиль и решает, какой из них отправить
на экран в текущую позицию луча.

Пример: какое-то знакоместо, из "фона" (экран-1) прочитаны байт графики 01111100
и атрибут 00-000-111 (серый INK, черный PAPER), то есть в стандартном режиме видим
07777700. Из "спрайтовой" плоскости (экран-0) прочитаны байт графики 00001110 и
атрибут 00-010-110 (желтый INK, красный PAPER), то есть в стандартном режиме 22226662.
Из вентильной плоскости прочитан байт "пикселов" 11100011 и "атрибут" 11111111
при отключенной "инверсии вентиля", следовательно итоговый вентиль 11100011.
Что получим в SCF-mode в соответствующих восьми точках?

экран-0 - 22226662 - ---266--
вентиль - 11100011
экран-1 - 07777700 - 077---00

в результате имеем - 07726600

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

Ну если и ЭТО непонятно, придется мне скриншоты драть и раскрашивать...


А в APA-mode все еще проще, там точно так же из каждого слоя читаются по два байта,
только второй не из области атрибутов, а по тому же адресу с другой страницы линейки
(например, если первый из адреса #4013, то второй из адреса #8013 - это именно внутренние
адреса видеопамяти). Дальше прогоняем аналогичный ULA цикл по восьми битам, получаем
два номера цвета и сравниваем один из них с "прозрачным" (с точки зрения железа проще,
если "прозрачными" цветами могут быть только 000000 и 111111 - проще проверять). Если
он непрозрачный, его и выводим, иначе другой (фоновый) берем.

Пример:
(Без палитры, по два бита на цветосоставляющую, то есть Gg, Rr, Bb. Специально взял
простые цвета, чтобы обозначать одной буквой, как на Спеке, а черный - прочерком)

страница> - 1-фон - 2-спрайты
слои
0 - b -- 00000000 - 01000000
1 - r '-- 00000000 - 01000000
2 - g -- 01000000 - 00000000
3 - B -- 00000000 - 00001000
4 - R -- 10000100 - 00001000
5 - G -- 10000000 - 00001000

цвета ` Yg---R-- ` -m--W---

допустим, прозрачный черный, тогда
---это будет фон `` Yg---R--
-----а это спрайт ` -m--W---
на экране увидим ` Ym--WR--