Секреты и трюки программирования (в том числе и игр) для РК-86

[barsik]

Как видно, экран остался таким же. Никакие строки короче не стали

Да, это было уже понятно из кодов и первой картинки. Но ведь Вы использовали бесполезный режим с отображением атрибутов пробелами. Вот Вы сделайте то же самое, но закрашивайте каждый символ, а не с интервалом в пробел. Из картинок понял, что цветовой атрибут в режиме отображаемых атрибутов начинает действовать не с текущего знакоместа, а со следующего. Режим с отображаемыми атрибутами бесполезен.

Неудобно, что в "Апогее" экран не с E6D0, отчего неудобно адаптировать экранно-лезущие программы с/на РК86, где экран 76D0.

А у кого-нибудь есть идеи, как сделать, чтобы и цвет был (8 штук) и знакогенератор атрибутом переключался? Не портом или еще каким сигналом (INTE как в Апогее), а сигналом от ВГ75, чтобы была возможность выводить символы двух знакогенераторов одновременно.

Вообще-то цветов, точнее сочетаний битов программно управляемых атрибутных сигналов на выходах ВГ75 - 16, не 8. Есть 8 цветов для фона плюс 8 цветов для символа. Но не одновременно в одном знакоместе. То есть, в одном знакоместе можем задать ИЛИ цвет для фона ИЛИ цвет для символа. Второй цвет знакоместа всегда чёрный. Сигнал ReVerseVideo как бы переводит окраску цвета в окраску фона.

Так что удовлетворить Вашему условию в 8 цветов совсем просто - тратим бит RVV на управление фонтом, отчего цветов по-прежнему остаётся 8. Но увы, тогда раскрашивать можно будет только цвет символов - имеем только цветные буквы, всегда на чёрном фоне.

Самый грамотный вариант, - это использовать атрибутные выходы не для прямого управления электронными пушками кинескопа R, G и B. а через кодо-преобразователь. Сейчас имеем 16 цветов, точнее 8 цветов для символа ИЛИ 8 цветов для фона (что определяет сигнал RVV). Это тратит 4 бита, а даёт всего 8 цветов и к тому с таким ограничениями - красим или INK или PAPER.

Если использовать всего 3 бита, но подавать их через кодо-преобразователь, то цветов также останется 8 и к тому же цвета будут одновременно и для INK и для PAPER. Причём будут иметься самые ходовые цвета, а не только производные из основных цветов с весами 1. На 8-ми битовом кодо-преобразователе 3 в 8 получаются 3 бита на веса R, 3 бита на веса G и всего 2 бита на веса B. Но доступных цветов становится 256. А бит RVV освобождается для коммутации фонтов.

Мне нравится этот вариант (хотя цвет из фонта даёт больше цветов, в любом сочетании и окрашивает каждую линию растра). Расход деталей - одно ПЗУ кодо-преобразователя. Совместимость сохраняется (2 режима, переключаемые программно битом из ППА D14). Это даст в игре 256 символов, что достаточно для 8-ми спрайтов 2*2, по 4-8 фаз на каждый спрайт и немного графики для пейзажа.

Кстати, в качестве кодо-преобразователя соверешенно необязательно ставить трудно-прошиваемые РЕ3 или РТ5. Оказывается в этой роли прекрасно работают даже обычные УФ-ПЗУ 573РФ5.

Ещё одну идею на эту тему я уже высказал - затратить коды общепринятых как раз для этого символов 0E и 0F на переключение фонта. Тогда на выходе ВГ75 эти коды отлавливаются и подаются на R и S входы триггера. Расход деталей 4 корпуса.

Распределим экран так, чтобы на строку отводилось не 78, а например, 120 байтов.

Я так понимаю, - это апофеоз бреда в этом топике

Опять хамите. Слово бред, что самое любимое? Если идея программного удлинения области в 78 байт для символов строки не дошла, то это не повод ругаться.

А возразить, Вы должны были следующее. Что шаг 120 символов на строку не пойдет, потому что в пачке ПДП - 8 байтов. Поэтому если в 78-ми байтах с начала строки не набирается 78 отображаемых символов, то ВГ75 заказывает ещё одну посылку от ВГ75. В которой тоже 8 байтов. Поэтому если мы выберем строчный шаг в 78+8=86, то получим в строках больше места для вставки атрибутов и шаг по строкам будет неизменным, так что начало каждой строки N в ОЗУ будет чётко соответствовать формуле SCREEN +N*86.

Хотя, при желании, можно извращаться и со строками переменной длины. Тогда составляем таблицу адресов начал строк. И при каждой записи в строку двух атрибутов (вкл.цвет,выкл цвет), будем корректировать не только экранный буфер, но и адреса начал строк. Причём придется учитывать, что первая вставка 2-х атрибутов удлиняет строку на 8, три последующие вставки не удлиняют строку, а 4-я вставка двух атрибутов снова удлиняет строку еще на 8 байтов. В общем, это "полный электротрах" для сумасшедшего программиста. Естественно, таким извратом никто заниматься не будет.

Цвет конечно забавный но в 86РК его нет же, значит он не нужен

Я бы назвал такой цвет не забавным, а неудобным для программиста (особенно для игр). И цвет в РК есть. Т.к стандарты задают публикации в журналах. Если что-то придумали, но не опубликовали, то этого нет (есть только у автора). А если опубликовали, и это стоящая вещь, то это есть у всех. А именно такой цвет опубликовали в журнале "Радиолюбитель" 04.1992, стр.10, статья "Цветные компьютеры РАДИО-86РК". Против силы печатного слова не попрёшь.

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

Практика показала, что введение в схему "Радио-86РК" цветообразующей схемы резко расширяет эстетическое восприятие "эркашных" картинок.