ZXNet эхоконференция «hardware.zx»

Hello, 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-а тоже.