Улучшение видео возможностей РК86

barsik пишет:
Чем не нравится более простая и не грузящая шину схема, когда доп.ППА формирует сигналы нужные для записи в ОЗУ фонта? имер 565РУ2), то и буфер развязки от шины не нужен.

Я просто хотел взять проверенный рабочий вариант. На ППА схем не видел, разве что интересная схема КР 04. Посмотреть схему можно. Но опять же... ППА на диск, ППА на фонты, ППА на выборку периферии... Где их брать то? )) Я увидев вашу последнюю доработку на тм9 вместо ППА прям обрадовался, что можно так легко и непринужденно.


По поводу ПЗУ - не торопимся все по порядку. ПЗУ однозначно 8 КБ, у меня будут вопросы с ОЗУ, я хочу ставить статику а оно немного не вяжется в мозгах ))

ведущий_специалист пишет:Vinxru... Но увы, связаться с этим товарищем крайне проблематично. На этом форуме он вроде появлялся в 2019-м году.

Сейчас vinxru активно пишет на http://hype.retroscene.org/profile/alemorf/created/topics/page1/. На этом сайте есть все его текущие контакты (см. пользователя alemorf) и доступ к ним есть и для незарегистрированных. Вас может заинтересовать его новый компилятор ассемблера Z80 доработанный элементами из Си.

ведущий_специалист пишет:хочу ставить статику, а оно немного не вяжется в мозгах

Я тоже хотел этого в начале 1990-тых, когда поимел 62256. Хотел сделать всё ОЗУ на статике, чтобы не сбоило при всех типах 4164 и 565 РУ5. Но резко обломился, т.к ума не хватило это сделать. Буду благодарен, если, наоборот, это Вы подскажете мне как заменить ОЗУ в РК86 на статику (по идее это должно стать не только надёжнее, но и позволить больший клок CPU).

Вопрос к Freddy, (он вроде знаток по вг75). Обдумывая расширение графических возможностей ВГ75 подумал следующее. Можно ли завести аппаратный счетчик на окончание символьной строки экрана (например стандартного 64 символьного режима). В идеале на 2 символьные строки. Тут подумалось, что можно реализовать полноценный графический режим 512х384 точки. Смысл в следующем. Еще в лохматых годах был придуман способ переключения пзу знакогенератора в адресное пространство ОЗУ. Данный режим по мне так просто великолепен, и позволяет по сути обграфичить кусок экрана 128ю символами. Я долго думал, как устранить проблему 128 символов и тут вот чего пришло в голову. Ставим 12 запараллеленных 2 кб ОЗУ, и переключаем их выборку каждые 2 символьные строки. Переключая эти банки (а получится это непросто) для записи данных, мы можем свободно размещать уникальную графическую информацию линейно по каждые 2 кб (каждые 2 строки). Переключив обратно на вывод информации мы наблюдаем полноценный графический экран 512х384 точки.
Если подумать глобальнее, можно 12 корпусов заменить на 1 32кб микросхему статики.
Делали такое с вг75? Наверняка же было?

ведущий_специалист пишет:Ставим 12 запараллеленных 2 кб ОЗУ, и переключаем их выборку каждые 2 символьные строки. ... Делали такое с вг75? Наверняка же было?

Наводит на мысль о Электронике КР-04. Похожую идею обсуждали тут.

barsik пишет:..... обсуждали тут

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

ведущий_специалист пишет:дальше читать не стал

Перечитайте ещё раз, и если понадобится в третий... Там о том же и речь. О принципе, как использовать ВГ75 для графического экрана. Суть в том, что каждые две строки переключается фонт (и это можно делать как аппаратно-программно атрибутами, что дешевле, так и чисто аппаратно счётчиком на ССИ), что даёт аж до 16*2= 32 знакорядов, где в каждых двух знакорядах записан инкрементный код 0...127, и т.о ВГ75 выполняет просто роль счётчика видеогенератора, а экранный буфер образован 16-ю (как бы) фонтами доступными напрямую процессору.

ведущий_специалист пишет:вопрос был лишь в том чтобы поиметь с платы РК сигнал конца символьной строки.

Чем Вас ССИ (или в случае программного бордюра, - HRTC из ВГ75) не устроил?

---

И возникает вопрос, зачем столько трахаться, чтобы получить обычную графику Специалиста или ОРИОНА. Специалист, кстати, даст то же самое при меньшем числе деталей (причём с экраном 512*256). И к тому же, зачем это делать на компьютере с эффективной скоростью в ~1 МГЦ !!! [скорость РК86 падает до ~1 МГЦ при 39-ти полных строках, хотя при базовом режиме в 31 полную строку она достигает аж 1.3 МГЦ, что для текстовой машины вполне достаточно).

Такая конструкция полностью лишает машину текстовости, по железу ничего не упрощает относительно полноценных графических машин, а в программировании это ничуть не проще, чем их (т.к текстовости дающей тайловую графику при этом уже нет, а скорость упала). Если графика 192*128 (получаемая за счёт умного фонта) ещё кое-как пойдёт при скорости CPU ~1 МГЦ, то на вчетверо большем экране нехватка скорости уже фатально скажется.

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

barsik пишет:
И возникает вопрос, зачем столько трахаться, чтобы получить обычную графику Специалиста или ОРИОНА. Специалист, кстати, даст то же самое при меньшем числе деталей (причём с экраном 512*256). И к тому же, зачем это делать на компьютере с эффективной скоростью в ~1 МГЦ !!! [скорость РК86 падает до ~1 МГЦ при 39-ти полных строках, хотя при базовом режиме в 31 полную строку она достигает аж 1.3 МГЦ, что для текстовой машины вполне достаточно).

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

Не хотел бы спорить, но как раз таки, даже при видеообласти в 24 кБ в отличии 16 специалиста , так вот даже при этом объеме рк будет шустрее.
1. Вся графика так же будет выводиться тайлово.
2. Работа дма разгрузит процессор.
3. Вся задержка будет уходить лишь на закачку "фонтами" и тайлами соответствующей видеообласти.
4. Процессор будет также как и раньше заниматься передвижением на экране СИМВОЛОВ, то есть графических элементов (тайлов, спрайтов) 8х16 точек.
Повторюсь, то что в специалисте нужно вывести на экран процессором в рк думать об этом не надо, а думать куда вывести... Вот и вся разница
Да и кто мешает переключиться обратно на работу ПЗУ , чтобы остаться в текстовом режиме

ведущий_специалист пишет:даже при видеообласти в 24 кБ в отличии 16 Специалиста

В базовом Специалисте - экран 12 Кб. На обычном советском телевизоре экран 24 Кб в такой концепции от freddy - не получить. Но это возможно на VGA.

Максимальный размер экрана при работе на телевизор достигается за счёт режима в 80 знакомест в знакоряду и 32-х знакорядах (хотя в базовом РК из-за нестандартного КСИ вместо 32-х строк в режиме с фонтом высотой в 8 линий видны лишь 30 знакорядов, а не 32). В каждом знакоряду 80*8=640 байт (8 - это высота знакоместа в линиях растра). Итого общий размер в байтах: 640*32= 20.480 байт. Т.е 24К используя телевизор не получить. Но зачем столько? Для игр достаточно экрана 5...8 Кб.

Т.к VGA дисплей визуализирует аж 350/400/480 линий развёртки (а телевизор и CGA-монитор только ~260), а ВГ75 умеет выдавать аж до 64 знакорядов, то при работе на VGA при 480 линиях на этой идее можно поиметь экран объёмом до 37.5 Кб.

ведущий_специалист пишет:при видеообласти в 24 кБ...  даже при этом объёме РК будет шустрее.
1. Вся графика так же будет выводиться тайлово.
....
4. Процессор будет также как и раньше заниматься передвижением на экране СИМВОЛОВ, то есть графических элементов (тайлов, спрайтов) 8х16 точек.

ВГ75 в исходной идее freddy занят выводом адресов экранных позиций в фонте. А весь вывод на экран делается сами процессором изменением фонта. И чем экранное ОЗУ больше, тем будет тормознее. Вы же предполагаете использовать идею freddy, в качестве аппаратного спрайт-движка (типа как в Амиге и др).

Так возможно. Если спрайт должен двигаться везде, то нужно, чтобы в каждом из 16-ти фонтов (каждый из которых хранит графику для двухстрочного ряда) содержались 32 байта спрайта 16*16. Иначе при вертикальных перемещениях спрайта придётся переносить эти 32 байта в другой фонт, а не только переписать 4 байта.

Программировать это конечно сложнее и ощутится ограничение на количество спрайтов. Зато можно получить более плавное движение спрайта и по горизонтали спрайты могут двигаться почти мгновенно, мало нагружая процессор. Основная проблема в том, что если спрайт 16*16, т.е занимает 32 байта, то возможны всего 4 фазы его движения с быстрой скоростью, а ведь ещё д.быть пейзаж и другие спрайты. В итоге это тормознёт (возможно почти до скорости обычной графической машины), а сложность будет выше, чем при программировании традиционной графики.

Для начала достаточно и обычного РК86 с большим числом фонтов в ПЗУ. Т.к это проще и легче в программировании новичку.

Недавно я с интересом посмотрел на видео самодельного любительского GUI с мышью на антикварной Атари-800, т.е 8-ми разрядке из 1978-го года. И подумал, а почему же на крутой советской 8-ми разрядке РК86 из 1986 года нельзя сделать GUI?

Основная трудность заключается в том, как выводить указатель типа "стрелка" по чисто текстовому экрану. И тогда у меня возникла идея, как эту аппаратную проблему преодолеть. Т.о если найдётся нужный пассионарий, то обладая этой ценной идеей, он вполне сможет сделать графический интерфейс с пиктограммами, окнами, меню и мышью (т.е GUI) даже для ущербного текстового компьютера РК86.

А аппаратно достаточно лишь заменить ПЗУ фонта, чтобы поиметь большое число фонтов, добавить ЛП5 для инверсии знакомест и как-то подключить мышь. Естественно будет лишь моно, т.к один атрибут уйдёт на инверсию, а три остальных придётся отдать на коммутацию фонтов, ибо в GUI очень много графики.

Итак, вот решение проблемы наложения изображений символов в РК86.

Идее через-кадровой развёртки в бытовой ЭВМ более 25 лет. Но если эта идея через-кадрового повышения разрешения снижает яркость картинки на дисплее ЭЛТ и даёт мерцания на современных TFT и LCD экранах, то для одного единственного знакоместа (или нескольких) идея должна сработать вполне приемлемо.

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

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

С учётом текущей реальности сейчас оптимальной мне видится следующая целевая платформа РК86 для разработки программ. Она требует совсем минимальных доработок железа и даже часть из них опциональны (т.е по желанию).

Целевая платформа для игр - это обычный базовый РК86 с 32К ОЗУ к которому добавлены доп.фонты и цвет (или хотя бы Reverse Video - расход деталей 1/4 155 ЛП5 и 2 диода). Опционально турбирование до 1.76...2.2 МГЦ реального такта (по варианту ж.Радио 01.1992, где отдельный генератор для ВГ75 и повышенный кварц у ГФ24). Увы, фонты эмуляторы не поддерживают, это пока проблема.

Фонты, Турбо и RVV - это три минимальные базовые опции доработок (и это очень простые доработки, они все делаются за полчаса). Цвет из ж.Радиолюбитель 04.1992 чуть посложнее, но он существенно улучшает игры (и ценно, что эмуляторы это поддерживают). Z80 в целевой платформе не присутствует. Ибо платформа это то, что у всех, а не у одного!

Фонты дают тайловую графику в графических играх, а также графический видеорежим 192*104 (при статике и АГ3 для аппаратного КСИ возможен и режим 192*128, но это не надо, т.к у большинства 565 РУ5). Доп.фонт в минимуме обходится в кусок проволоки и допрошивку ПЗУ РФ2. Аппаратно самое сложное это цвет, т.к для него затрачивается аж несколько доп.микросхем. Но для начала хватит и RVV.

При кварце 20 МГЦ реальное быстродействие РК в режиме 25 строк увеличивается с 1.31 МГЦ до 1.76 МГЦ реального такта. Если из периферии есть всего одно устройство (например контроллер винта/флопа/microSD), то спокойно можно применить кварц для 580 ГФ24 в 24 МГЦ. Это даёт эффективную скорость такого РК86 в 2.21 МГЦ, что соответствует ускорению в ~1.7 раза (относительно базового варианта). Ускорение ценно при написании РК-игр на ЯВУ. 2.21 МГЦ для текстовой 8-ми разрядки это как 22.1 МГЦ для графической.

Такова целевая платформа ! Вот для такой целевой платформы нужно делать РК-игры (в графике 192*104 или текстовые с тайловой графикой) используя компиляторы ЯВУ. -- Возможно лишь пока. Если объёма ОЗУ в 28К для игр на ЯВУ будет не хватать, то ещё возможны варианты и на счёт доп.ОЗУ (тогда выбор - или 2 полубанки по 32К на 565 РУ5 или открытие ОЗУ 8000...BFFF, что даёт 48 Кб).

Как видите, этот пост по сути резюмэ, или просто обобщение того, что я написал раньше.

---

А вот для себя можно иметь РК86 и получше. Но и тут критерии разумного минимализма играют роль. На моей плате будут следующие отличия от целевой платформы - ОЗУ 48 Кб, ПЗУ 8 Кб (E000...FFFF), RVV и пока без цвета. 48К надо для DOS. 27256 для фонтов. А цвет пока не нужен (т.к для него две доп.микросхемы уже некуда монтировать). Инверсии знакомест пока достаточно.

Критерий - минимальность доработок на моей журнальной плате РК. Уже добавка (открытие) ОЗУ в 16К в окне 8000...BFFF сжирает весь мой лимит доп.микросхем на плате, что я могу смонтировать вторым этажом.

А с Z80 это был бы уже и не РК86 (к тому же имея Z80 никто не сможет удержаться от использования Турбо-Паскаля). Да и лампово получить лучшие параметры железа на тех же деталях. Я уже нашёл несколько вполне пригодных компиляторов под КР580, потому Z80 (если не учитывать его бОльших скоростей) уже не актуален.

У меня есть и моно-CGA и телевизоры со скартом (один даже 14"), так что на VGA-видеовыход я не падкий. Хотя ненужных ЭЛТ VGA-моников у меня хватает (есть даже один относительно маленький). Но, если сделать вывод на VGA будет не особо сложно, то можно сделать.

Динамические ОЗУ 565РУ5 смогут работать при переделке РК86 на выдео-вывод на VGA-дисплей. Т.к не обязательно клок CPU также синхронно поднимать, а можно оставить клок CPU тем же (1.77 МГЦ или 2.22 МГЦ). Для чего достаточно лишь сделать для питания ВГ75 отдельный генератор на 24 МГЦ.

Длительность /CAS в РК зависит от частоты клока CPU - чем он больше, тем период доступа к ОЗУ короче. Есть надежда, что с одним тактом WAIT процессор КР580 даже при ОЗУ без буферов сможет позволить получить Турбо-200% (относительного базового варианта РК).

barsik пишет:

Фонты дают тайловую графику в графических играх, а также графический видеорежим 192*104 (при статике и АГ3 для аппаратного КСИ возможен и режим 192*128, но это не надо, т.к у большинства 565 РУ5). Доп.фонт в минимуме обходится в кусок проволоки и допрошивку ПЗУ РФ2. Аппаратно самое сложное это цвет, т.к для него затрачивается аж несколько доп.микросхем. Но для начала хватит и RVV.

Предлагаю в темах, которые выпросил у Виктора, пообсуждать именно это. Все ваши желаемые доработки раскиданы в разных ветках форума и собрать все эти идеи становится проблематичным.
1. Мое мнение, что при условии создания динамичных игр нужно как минимум 2 переключаемых экрана (в идеале 4, чтобы не отвлекать процессор на перерисовку просто двигать экран аппаратно по области памяти, тем самым создавая скролл). Поэтому памяти нужно 32КБ +8КБ. Это минимум.
2. Опять про память. Так как ни одно программное обеспечение в современном мире не обходится без ОС, то нужно задуматься об операционной системе. Лично в моем понимании это должны работать резиденты, которые постоянно будут обеспечивать подгрузку - выгрузку данных на внешний носитель. Для моих скромных подсчетов, эти самые подпрограммы должны занимать не более 4 кб оперативки.Поэтому 32+8+4. Если будет хоть какая нибудь страничная организация памяти или какие либо переключаемые фонты и прочие режимы то сюда нужно еще 128Б - 1КБ под резервные ячейки ОС стек и прочие запоминалки текущих режимов.
3. Я с Вами почти согласен заделать огромную ПЗУ фонтов. Но почему то у меня абсолютно не вяжется, где и каким образом взять эти фонты, кто и как их будет делать и что самое главное..... как эти фонты получит и внедрит тот ...другой... пользователь рк, который захочет сделать также и поиграть в новые творения на рк86. Стандартизация фонтов для новых игр это еще тот геморой, и врятли приживется. Гораздо удобнее (по моему скромному мнению) подгружать эти самые фонты с диска в озу в процессе игры и эта самая игра будет работать на всех платформах, доработанной ремапом пзу знакогенератора в общее адресное пространство (в озу).
4. Про АГ3 предлагаю обсудить в ветке аппаратных доработок, так как считаю это обязательной доработкой.

Я пока что нахожусь на стадии отладки аппаратных модулей, и как обещал, собираюсь закончить это к весне. Параллельно ведется работа в программной поддержке, пишутся драйверы новинок. Но ничто не мешает мне предусмотреть Ваши НЕОБХОДИМЫЕ минимальные внесения. Думаю можно найти компромисс. Я пока что против динамического ОЗУ в новоделе также как и против использования там CP/M.
В связи с выше описаным хочу попросить конкретики, если ставим АГ3 - то схему и небольшое описание (или хотя бы вместо схемы) как это работает.
Если ставим ПЗУ с фонтами - то сколько банок переключать, и как, либо это тм9 либо дешифратор с чем то там...
Если лепим вместо пзу с фонтами просто кп11 то нужно проработать программно аппаратно как это вообще все устроить и облагородить. Я бы напряг мозг и подумал как этот режим сделать переключаемым.

Вопрос freddy, если он тут обитает еще. Занимаюсь сейчас изучением работы ВГ75. В частности возникли следующие вопросы.
1. - Знаю с детства что вг75 можно настроить так, что получается вывод данных без межстрочных интервалов. Я до сих пор не понимаю (не знаю) почему уходят эти интервалы и символы слипаются? Может кто объяснить на 2х пальцах? Или где почитать про это? Ибо мне не нравится, что включая данный "необходимый" режим я сбиваю синхру на мониторе, а очень бы хотелось этим пользоваться ибо машинка делается для создания "игр" а игры будут смотреться красивее без межстрочных интервалов.
2. - Тупой вопрос, но все же. Сейчас у меня схема с VGA выходом на монитор, но так же схемотехнически предусмотрен видеовыход. Я так и не смог получить сигнал на тв, менял кварц с 24 мгц на штатные 16, и ставил "родную" прошивку монитора. Нужно ли менять пзу с штатным ЗГ? потому как телек нифига не может поймать нужную частоту синхры. Кто такое встречал и можно ли это обойти?
3. - Никак не пойму что у меня с курсором, он как то программно управляется? может все дело в прошивке?
4. - Странная хрень с цветами, вместо красного синий и тп... Тоже не пойму, схему всю перепроверил все верно вроде.
С удовольствием пообсуждал бы данные вопросы ибо одному катастрофически не хватает времени думать над этим всем.

Отвечу на свой же пост выше (фредди видимо появляется здесь пару раз в год а как оказалось Барсик вообще покинул форум).
Про межстрочные интервалы вобщем то нашел в этой же теме в самом начале. У меня есть подозрения что если применить фонт не на 14 точек как сейчас, а на 16 точек, то все станет на свои места.... но когда я применил код reverse video то увидел все те же интервалы. Конечно не хотелось бы применять доп лл1, еще немного попытаюсь разобраться и если что - внедрю ее в схему.
С цветами похоже все тривиально. Я после ле1 поставил транзисторы, но не поставил инвертора. Скорее всего из за этого. Дождусь прихода ле6 , коротну транзисторы - посмотрю... должно все стать на свои места.

С курсором - тут писал Барсик - там программно его можно крутить вертеть как угодно, выберу время проверю первым делом.

Я после ле1 поставил транзисторы, но не поставил инвертора.

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

Хочу упомянуть ещё одно небольшое и сразу совсем неочевидное улучшение видеовозможностей РК86 возникающее при самой традиционной (описанной в журналах и многократно опробованной) доработке. Речь о добавке к РК внешней платки цветного адаптера (по схеме из ж.Радиолюбитель 04.1992) и введении хотя-бы нескольких альтернативных фонтов в ПЗУ (удобнее всего на ПЗУ 2732 в 4 Кб, что даёт аж 4 фонта без всякого труда) управляемых незадействованными битами PC1, PC2 ППА клавиатуры (или битами запасного ППА D14).

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

Из-за семибитовости символов выводимых ВГ75 при блочно-текстовой псевдографике в знакоместе можно иметь в лучшем случае лишь 6 пикселей и, таким образом знакоместо можно разбить или в матрицу 3*2 или в матрицу 2*3. Для первого варианта самым выгодным является выбор высоты знакоместа в 4 линии и режим недавно изобретённый vinxru с 51-й видимой строкой (и частотой кадров в 60 Гц), что даёт качественный графический экран в 192*102 пикселя на ЭЛТ-телевизоре. А на плоском телевизоре число видимых строк может быть 52 и более.

При разложении знакоместа на три по вертикали годится только высота знакомест в 9 или 6 линий (т.к остальные числа в диапазоне 4...10 не делятся на три). 9 для целей совмещения фонтов не годится, т.к не делится на два. Т.к на экране обычного ЭЛТ телевизора видно не более 260 линий (хотя у плоских телевизоров бывает видно до 280 линий), то при высоте знакомест в 6 линий в его видимой части растра уместятся лишь 260:6= 43 строки. Что даст пиксельное разрешение 128*129. Зато, если сразу рассчитывать не на ЭЛТ телевизор, а на плоский TFT или LCD, то можно выводить и на 45 строк, т.е иметь по вертикали аж 45*3= 135 линий.

Ранее рассматривалась графика или с фонтом 3*2 или 2*3. Но недавно я, наконец, сообразил что, если использовать знакоместа высотой в 6 линий растра, то или тут не обязательно, - можно объединить в одном экране оба граф.фонта. Каждый из этих шестипиксельных графических фонтов занимает 64 символа. И ранее предполагалось задействовать под графику только 64 кода, а в остальных 64-х символах (из возможных в фонте 128-ми) иметь или тайлы для рисования пейзажа или буквенно-цифровые символы, что также полезны в играх (для вывода инструкций к игре).

Но, если мы все 128 символов займём двумя данными шестипиксельными блочно-графическими фонтами, то без всякого рукоприкладства получим в РК86 графику 192*135. Таким образом графика 192*135 реализуется всего-лишь прошивкой в знакогенератор из 128 символов в первые 64 кода - графики для матрицы 3*2, а во вторые 64 кода - для матрицы 2*3.

Разрешение 192*135 - это уже почти приличная графика, не уступающая графике даже некоторых высоко динамичных игр ZX-Spectrum-а (в которых с целью выигрыша скорости сознательно уменьшали динамично меняемую часть экрана, где собственно развертывается основное игровое действо) и примерно равная по разрешению лучшим американским игровым консолям конца 1970-х годов (некоторые из которых имели тираж в 40 и даже 70 млн экземпляров). Для сравнения в Commodore 64 игры работают на экран 160*200 при 4-х цветах (правда там есть ещё аппаратные спрайты, так что такое разрешение по сути лишь для фона).

Т.о с помощью всего лишь особого фонта мы как бы объединяем на одном экране в режиме с 45 строками видео разрешения 192*90 и 128*135 и (пусть и с некоторыми ограничениями) получаем возможность видеть на экране как бы графику с разрешением 192*135. Хотя на самом деле это и не такая мощная графика - мы лишь в одних участках экрана можем иметь в 1.5 раза лучшее разрешение по горизонтали, в других - по вертикали.

Разумеется, даже такая графика остаётся сравнительно убогой и на ней более менее прилично будут выглядеть лишь абстрактные игры (типа тетриса или ксоникса), где не требуется человекоподобие объектов.

Существенно увеличить качество РК-игры можно лишь используя на экране и шестипиксельную цветную графику с разрешением 192*135 (или 192*128) и одновременно цветную символьную тайловую графику. Но для этого нам нужен хотя бы один атрибут. Тогда, например, пейзаж или лабиринт мы рисуем графикой 192*135, а бегающие по лабиринту спрайты делаем красивыми за счёт изображения их в символьном виде. Один истраченный на коммутацию фонта атрибут позволяет в одних участках экрана иметь рисунок графикой 192*135, а в других участках экрана символами выводить красивые спрайты (по идеологии Денди, для чего второй фонт должен содержать символы представляющие графические изображения фрагментов спрайтов в разных фазах).

К сожалению, атрибутов в ВГ75 всего 4 штуки и все они задействованы в базовой схеме цвета из ж.Радиолюбитель 04.1992. Минимум три атрибута для цвета необходимы потому что у ЭЛТ-телевизора три цветовые пушки и в кабеле для подключения дисплея - три сигнала (называемые R, G, B). А вот четвёртый бит-атрибут служит в качестве как бы цветового реверса - он переназначает управление цветом с цвета символов на цвет фона. Т.е при атрибуте RVV=1 раскрашивается фон, а символы становятся чёрными.

Разумеется, (чтобы освободить один атрибут) простым и логичным выходом было бы применение кодопреобразователя на 155 РЕ3. Тогда 3 атрибутных бита кодировали бы не сразу физический цвет на экране (по сути включение лучей эл.лучевых пушек в ЭЛТ телевизоре), а служили бы логическими цветами. Тогда логические цвета подаются на кодопреобразователь на скоростном ПЗУ, с выхода которого снимаются уже физические цвета. 8 входных кодов позволяют иметь 8 выходных сочетаний цветов (что как раз и делает ненужным в цветовой схеме РК86 4-тый атрибут).

Например, можно прошить 155 РЕ3 так, что логическому цвету 5 соответствуют жёлтые буквы на синем фоне, а цвету 7 - красные символы на чёрном фоне. При этом схема остаётся совместимой с журнальным историческим цветом РК86 (но мне, например, это даже не надо, 155 ЛА3 из схемы ниже выгоднее с'экономить). Кодопреобразователь при затрате на цвет трёх битов даёт лучшие цветовые возможности, чем 4-х битовый цвет без него.

К сожалению, прошивка 155 РЕ3 доступна только тем, кто имеет соответствующий прожигатель ПЗУ с проволочными перемычками и электропечь с температурой в 150'C для их термозакаливания. По этим причинам скоростные прожигаемые ПЗУ не приветствуются в радиолюбительских конструкциях, хотя часто они позволяют в 3-4 раза сократить число микросхем определённых схемных решений. У меня пока нет прожигателя 155 РЕ3, но хотелось бы впоследствии его поиметь.

Как видите, истратив всего лишь кусочек проволоки, можно улучшить графические возможности РК86 с базовых 128*60 до почти 192*135. Учитывая это, можно задуматься о том, так ли уж необходимо добавлять в РК86 специализированный видеопроцессор типа EF9345 (который широко применялся игровых ЭВМ в начале 1980-тых годов, например, в Tandy MC10/Alice/Alice 32/VG 5000), что хотели бы сделать некоторые разработчики новодельных вариантов РК86.

Как видите, РК86 при обдуманном подходе - это компьютер ещё пригодный для разработки игр уровня игровых консолей из начала 80-тых годов. И если бы не внезапное появление графических компьютеров и вследствие этого быстрый отток на них огромной массы любителей РК-подобных, то несомненно в конце 1980-тых годов программисты любители додумались бы о возможностях РК86 возникающих всего лишь за счёт альтернативного фонта.

В том, что этого не случилось виноваты в первую очередь авторы РК86, не применившие не только второй фонт (что ничего бы не стоило им по деталям), но даже не задавшие стандарт на управление фонтом. Увы, программистов для РК86 привлекли графические машины, потому хотя и более скоростные по экранному выводу текстовые машины быстро сошли на нет.

Спойлер:

- - - Добавлено - - -

Некоторые эстетствующие любители РК86, т.е ценители прекрасного, которым базовый эр-ка-шный фонт 6*8 показался слишком некрасивым (по сравнению с фонтом Корвета 8*16) ещё в конце 1980-тых годов заменяли 155 ИЕ4 на ИЕ5 (что одновременно требует замены кварца с 16 до 20 МГЦ), что не только давало более красивый фонт 8*8, но и поднимало быстродействие РК86 почти на 30%, что было очень существенно для использования игры шахматы (эта примитивная РК-программа в 1988 году нагло обыграла меня в шахматы, хотя я в 6-м классе школы даже посещал шахматный кружок в доме пионеров).

Также некоторые современные любители РК86 делая перестройку РК86 под вывод на VGA-дисплей не сумели найти достаточно скоростного сдвигового регистра с параллельной записью имеющего выходы с шестого разряда (в  терминах шины данных это разряд D5) и вынуждены были применять ИМС 1533 ИР10 у которых есть только выход с последнего 8-го разряда. Из-за чего им также одновременно пришлось менять фонт на более широкий шириной в 8 пикселей.

Сведения о граф.видео режимах с шириной экрана в 192 пикселя у владельцев РК86 с 8-ми пиксельными фонтами создало сложное чувство, т.к возникло впечатление, что раз 8 не делится нацело на три, то и 64*3= 192 пикселя по горизонтали им не видать. Однако, оказывается, можно пренебречь этим. Вот ниже посмотрите на графический фонт из компьютера Philips VG 5000 (это сравнительно малоуспешный компьютер с тиражом менее 400 тысяч из 1984 года, продавшийся в основном во Франции, а также как VG 8000 под маркой Radiola и Schneider и в Германии).

Хотя в этом компьютере применён видеопроцессор EF9345, который выводит и полноценную графику 320*250, в нём (видимо из расчёта, что текст быстрее графики) имеется такой же псевдографический режим, как тут обсуждается (с разрешением 160*75), т.е чисто текстовый режим с псевдографикой за счёт граф.символов с пиксельной матрицей 2*3. Хотя, если посмотреть на скриншоты, похоже, что псевдографику в играх они не использовали, все игры VG 5000 графические. Но не в этом суть.

Приглядевшись внимательно к этому фонту, Вы обнаружите, что знакоместо там имеет размер 8*10. А число 10 также хреново делится на три. Тем не менее такое неделимое знакоместо всё-равно разбили на матрицу 2*3. Верхний и нижний пиксельный ряды имеют высоту в 3 линии растра, а средний пиксельный ряд имеет высоту в 4 линии растра.

Если это сгодилось для промышленного компьютера известной фирмы, то почему бы и нам не делить 8 на три, пусть и неравных по ширине пикселя, а именно 3, 3 и 2. Что позволит и на VGA экране отобразить 192 пикселя по горизонтали. Уже наверно в следующем году я нарисую такой фонт и в эмуляторе сразу же увижу по крайней мере как выглядит текст в экране 32*11 (символы размером 6*8 в экране 192*88).

Если, ещё чуть подняв частоту кварца до 22 МГЦ и добавив 155 ТМ2 (чтобы коэфф-т деления счётчика стал 9), можно получить фонт шириной в 9 пикселей. Число 9 прекрасно делится на 3, но тогда оно не будет делиться на 2. Так что это тоже не вариант.





- - - Добавлено - - -

Т.к в РК86 видеочасть на ВГ75 выводит на экран сама по себе, в смысле никак не связано с процессорной частью, то частота пиксель-клока и частота знакомест-клока никак не отражается на быстродействии машины. А вот клок ПДП ВТ57 существенно влияет на быстродействие РК86 и чем этот клок выше, тем на меньший процент времени процессор КР580 останавливается. Потому при выводе на VGA-дисплей, если кварц у ГФ24 остался тем же 16 МГЦ, то быстродействие РК86 не меняется (хотя теперь можно ставить произвольный кварц, стандарт телевидения по пиксель клоку теперь соблюдать не надо).

Разрешение в 192 точки, не особо вредя совместимости со старым ПО, можно немного увеличить до более приятной цифры в 200 точек, если заменить кварц 16 МГЦ на 16.5 МГЦ (я об этом думаю как раз потому, что такой кварц у меня есть). Разумеется несложно увеличить число символов в строке аж до 80, что дало бы аж 240 точек по горизонтали. Но хочется сохранить совместимость и лишь сделать круги квадратными. Для этого соотношение сторон экрана должно быть как в Специалисте - 1.5.

Увы, мой импортный калькулятор в железе сдох. Однако, с помощью программного калькулятора встроенного в Windows XP, мне всё же удалось выяснить, что если 135 точек по вертикали умножить на 1.5, то получается, что по горизонтали следует иметь 202 точки. При замене кварца 16 МГЦ на 16.5 МГЦ, визуально картинка немного уплющится и в неё даже на обычном ЭЛТ-телевизоре станут влезать уже не только 64 символа в строке, но и 67 символов в строке. А 67*3= 201, что и требовалось. Экран в 200 точек выглядит стандартнее и солиднее.

Даже без изменения одной константы (задающей длину HRTC) синхронизация телевизора не нарушится, т.к частоты строк и кадров не выйдут из полосы захвата, а совместимость не изменится, т.к по прежнему строчный шаг во всех режимах остаётся 78. А для режима в 200 точек достаточно задавать длину HRTC не в 6 знакоместных периодов, а в 10.

При этом частоты ССИ и КСИ вернутся к стандарту, HRTC слегка удлинится, а видимая часть экрана увеличится так, что видны станут 67 символов, что и требуется. На плоских телевизорах (а уж тем более на VGA дисплеях) это не надо, т.к там 67 символов видны и без подгонки частот. По некоторым сведениям при перестройке видео частот РК86 под VGA-дисплей, на экране становятся видны аж 76 символов в строке, что позволяет иметь полноценный экран 150*135.

Но надеюсь, что даже экран шириной в 200 пикселей и высотой от 86 до 135 пикселей позволит абстрактным играм РК86 выглядеть чуть получше. Хотя, мало кто сомневается, что без тайловой графики это будет всё равно достаточно погано.

- - - Добавлено - - -

Как выше упоминалось, если ОЗУ статическое, то можно кадровый бордюр сделать аппаратно и за счёт этого получить число видимых строк в 64 и разрешение экрана в 200*128 (или при VGA аж 225*128). При этом ещё появляется возможность резко увеличить и цветовые возможности. Ведь при этом используются только 64 граф.символа, что позволяет 7-й бит из экранного истратить на цвет фона.

Тогда вместе с 4-мя атрибутами имеем 5 битов для цвета. Из них 3 бита достаточно для цвета символов (8 цветов) и 2 оставшихся бита остаются на цвет фона (4 цвета). 4 цвета для фона это намного лучше, чем всегда чёрный цвет. Но к сожалению, с динамическим ОЗУ мы можем иметь только программный бордюр, т.к при DRAM нельзя выключить регенерацию на время большее, чем на время вывода двух знакорядов.

Конечно, эта идея (4 полноценных цвета для фона) годится и при программном бордюре, но размер растра при этом возможен не более 200*104 (или 225*104 при VGA). В принципе, разумно подумать о программной регенерации во время бордюра. Программная регенерации ОЗУ во время кадрового бордюра не сложна - требуются только частые прерывания - тогда также как это в IBM PC, каждые 2 мс по прерыванию CPU должен прогонять 64 команды POP. А ещё более грамотно это было бы сделать используя другой канал ПДП.

PS. Исходя из вышеизложенного, сам я пока в раздумьях про VGA. С одной стороны качество картинки на VGA дисплее выше, но и доработок уже становится слишком много, в то время как допрошивка ПЗУ знакогенератора (чтобы увеличить число фонтов) и добавка цветного адаптера не так обременительна для неумеек. Удачно, что цветной адаптер может быть конструктивно выполнен в виде внешней платки, что очень ценно для эстетов и неумеек.

Но с другой стороны стандарт это всё-же РК86 с выводом на CGA, т.к тогда программы доступны для всех и платформа не разрушается. Пока у меня не сдох CGA-монитор, VGA по полезности не перевешивает для меня возможность иметь на РК86 хотя бы 128 Кб ОЗУ. В виде двухэтажных банок 565РУ5. Но если удастся поиметь VGA видеовывод без замены ОЗУ на статику, то почему бы не сделать вывод на VGA?

Без наличия альтернативного фонта базовые возможности РК86 по выводу графики более, чем скромны и равны 128*60. Воспользовавшись онлайн перемножителем чисел легко узнать общее число пикселей в экране. А если воспользовавшись онлайн калькулятором процентов, сравнить графику РК86 с графикой ZX-Spectrum по числу пикселей, то легко убедиться, что объём графики РК в пикселях составляет всего лишь 15% от графики ZX (которая, как все знают 256*192).

Однако по цветовому разрешению даже РК86 в режиме 64*30 лучше, чем ZX-Spectrum в 2.5 раза (т.к цветовое разрешение ZX всего лишь 32*24). Так что сэру Клайву Синклеру не стоило так уж сильно гордиться цветовыми возможностями ZX-Spectrum, ибо они у него весьма убогие.

Недавно один из пользователей этого форума перестроил свой компьютер РК86 под видео вывод на VGA. Причём не в режиме 10H (640*350), а в режиме 11H (640*480). Благодаря чему стали известны некоторые дополнительные возможности, что даёт вывод на VGA. Кстати, режим 11H лучше тем, что в нём частота кадров ниже (60 ГЦ вместо 70 ГЦ в режиме 10H), а чем ниже частота кадров, тем быстрее работает РК86. Если наплевать на совместимость новых игр для владельцев стандартного журнального РК86 с выводом на телевизор, то возникают следующие соображения на этот счёт и следует решить делать ли новые РК-игры универсальными или работающими только под новую платформу РК86 с выводом на VGA.

Легко посчитать, что у VGA мониторов существенно меньший процент времени кадрового периода тратится на обратный ход луча, чем в телевидении. Так при выводе на телевизор из 312 линий растра в видимую часть экрана умещают обычно лишь 256 линий. При этом на обр.ход луча или кадровый бордюр тратится (312-256):312= 18% времени кадра. А в VGA мониторе в режиме 11H из 525 полных линий растра видны аж 480 линий, что составляет всего лишь (525-480):525= 8.5%. Кроме того (вероятно, чтобы выровнять пропорции сторон растра) для VGA ставится бОльшая длительность HRTC (18 вместо 8 знакомест), что приводит к тому, что в экран по горизонтали влезает уже не 64, а ~75 символов.

Что нам это знание даёт?

Во-первых, уже даже в базовом (сбросовом) режиме РК86 64*25 в экран влезут (т.е станут видимыми) уже не 25, а аж 27 текстовых строк. Это нам совсем не важно (скорее вредно, т.к плющит экран), зато в режиме без межстрочных разрывов (что часто используется в играх) на экране мы увидим не 30 строк, а уже 38 строк высотой в 12 линий. Глупо использовать лишь 30 из них. Т.к с тем же базовым эр-кашным граф.фонтом (2*2 пикселя в знакоместе) вообще без хлопот мы получаем графику 150*76 (а с альтернативным фонтом аж 225*76).

А с альтернативным вдвое более низким фонтом (аналогично режиму 64*51 для телевизора открытому vinxru) и бОльшим числом символов в строке, мы можем получить лучшую графику, чем 192*102, что достигается на телевизоре. На VGA будет видно больше строк, чем 51, что видны на телевизоре при вдвое низком фонте. Максимальное число строк, на что можно запрограммировать ВГ75 это 64. Размер VRTC 2 строки, итого полное число строк 66. Делим полное число линий на полное число строк и получаем 525:66= 7.96. Потому нет никаких препятствий, чтобы при высоте знакоряда в 8 линий видимыми были аж 480:8= 60 строк.

Таким образом используя вывод на VGA в режиме 11H с помощью альтернативного фонта содержащего 64 граф.символа блочно-символьной графики (с разложением знакоместа на 3*2 пикселя) вообще без всяких хлопот мы получаем графику 225*120 (при этом текстовый формат экрана 75*60).

Это уже существенный прогресс по сравнению с 192*102, что мы имеем на обычном телевизоре. Если Вы умеете пользоваться онлайн калькулятором процентов, то легко сможете узнать, что это на 38% бОльшее число экранных пикселей. Что касается тайловой графики, то фигурки составленные из знакомест нарисованные специальными тайлами в таком режиме получаются выполненными в графике экрана 600*480, что по числу пикселей превосходит графику ZX-Spectrum почти в 6 раз (точнее 5.86).

Таким образом лишь перевод РК86 на видеовывод на VGA-дисплей улучшает его графические возможности аж на 38%. Число пикселей такой графики составляет уже 55% от числа пикселей графики ZX-Spectrum и в многих ZX-играх динамичная часть игры происходит в почти таком же окне, как 225*120. Причём цветовое разрешение такой РК-графики равно 75*60, что относительно цветового разрешения ZX-Spectrum 32*24 также в 5.86 раза выше.

Цветовое разрешение в 6 раз лучшее даже важнее, чем немного худшее графическое разрешение. А учитывая возможности выводить красивые спрайты тайлами (для чего есть 64 тайла, т.к из 128 кодов 64 уже отнимают символы блочно-символьной псевдографики с матрицей 3*2 пикселя), что к тому же намного быстрее, чем вывод графики, а также с учётом грамотного использования ВИ53 для звуков, можно надеяться, что опытный программист сможет сделать игру для РК86 по качеству не хуже, чем некоторые из игр ZX-Spectrum из сезона 1982/1983 года для машин с ОЗУ в 16К.

Единственное, чего может не хватить для написания игры приличного качества - это ресурса скорости процессора. Потому, что при запрограммированном выводе на 64 строки при том же клоке CPU в 1.77 МГЦ реальное быстродействие РК предположительно составит всего ~750 КГЦ (а может и менее, т.к чем выше частота кадров, тем скорость ниже). При КР580 путём повышения частоты кварца вероятно удастся где-то раза в полтора поднять быстродействие. Большее турбирование потребует применения скоростного украинского процессора КР580 ВМ1.

По игровому аспекту, ZX-игры, разумеется, превзойти невозможно, так как некоторые из ZX-игр писались оплачиваемыми профессионалами несколько лет. Сейчас для РК86 конечно никто не станет писать игру три года, да и превзойти уровень даже лучших из имеющихся РК-игр не так уж сложно. Реальный срок на написание чего-то более-менее похожего на РК-игру используя компилятор ЯВУ это не более трёх недель, хотя простейшие РК-игры на ЯВУ пишутся за день.

Понятно, что на исходно чисто текстовой машине не имеющей даже отдельного ОЗУ для цвета, все попытки получить хоть какую-то графику и цвет дают довольно убогий результат и возможно кому-то даже смешны.

В предыдущем посте  показано, что перестройка видео РК86 под частоты VGA в режиме 11H (строчная 31.5, кадровая 60)  позволяет выводить графику на 38% более качественную, чем базовый РК86. При этом за счёт использования графического фонта достигается фантастическое (для РК86) графическое разрешение 225*120 или 150*180 при цветовом разрешении 75*60.

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

Базовый вариант цвета в РК86 состоит в том, что 3 атрибута напрямую управляют цветовыми пушками кинескопа (R G B), а 4-й атрибут используется, как цветовой реверс (коммутирующий цвет на фон символа), а бит D6 из символа не используется вообще.

Если при отображении букв и цифр цветовой реверс имеет смысл (для маркировки текста), то для графики он просто бессмысленен, ибо пикселями (неважно 3*2 или 2*3) в матрице знакоместа мы можем изобразить любую фигуру из пикселей, которая отображается так: биты в экранном байте, что установлены - цветные, а биты, что сброшены - чёрные. Реверс RVV=1 просто переключает цвет на нулевые биты экранного байта (а единичные биты - чёрные). Но т.к эти биты экранного байта мы можем сделать любыми, то нет смысла реверсить, если мы можем то же самое получить сменой графики. Таким образом один атрибут в графике при базовом цвете мы просто тратим впустую.

С учётом этого для улучшения графического режима у нас есть два бита - один атрибут и один бит D6 из кода символа. Как показано в позапредыдущем посте, бит D6 разумно использовать по прямому назначению - коммутировать им полутаблицы фонтов - первая половина фонта содержит графику с матрицей 3*2, а вторая - с матрицей 2*3.

Можно обдумать вариант повышения цветового разрешения до 75*120 при тех же 8-ми цветах, используя 4 атрибута ВГ75 иначе, плюс излишний при графике 7-й бит кода символа. В блочно-символьной псевдографике  биты D5...D0 задают графику двух стоящих один над другим рядов пикселей 3*1, а бит D6 для графики не используется. Т.о для управления цветом (или яркостью) имеем 5 битов на знакоместо (увы, не 6). Для использования этих 5 битов для задания цвета можно придумать несколько вариантов (хотя и все, что я до сих пор обдумал достаточно поганые).

Если атрибуты использовать в виде двух цветовых групп, каждая из которых задаёт цвет для ряда пикселей 3*1, т.е два атрибута задают цвет верхнего ряда пикселей, а два других атрибута задают цвет нижнего ряда пикселей. Вместе с битом D6 из кода символа получается 3 цветовых бита для каждой из групп пикселей 3*1. Что и даёт 8 цветов. Но с существенными ограничениями. Бит D6 из кода символа можно сделать лишь задающим палитру, что действует на всё знакоместо, т.е на оба ряда пикселей 3*1 стоящих один над другим. Или можно битом D6 менять цвет фона (например с чёрного на белый или синий).

Если использовать бит D6 для задания палитры знакоместа, то чтобы можно было рисовать сплошные объекты разумно сделать два цвета из 4-х одинаковыми в обоих палитрах, что сокращает число цветов до 6, но зато позволяет в пределах знакоместа иметь не только чёрный плюс один цвет, а чёрный плюс два цвета, т.е три цвета на знакоместо.

Такое устройство цвета дающее 2 цвета на знакоместо с удвоенным цветовым разрешением конечно лучше, чем единственный цвет на знакоместо из 6 пикселей, что дают существующие схемы цвета. Но за это мы платим невозможностью коммутировать граф.фонт в пределах экрана (т.е всегда пиксельная матрица знакоместа 3*2 или 2*3).

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

Бит D6 в коде символа при выводе на VGA позволяет выбирать графику участка между 225*120 или 150*180, что как бы даёт графику 225*180 !!! А атрибут RVV оперативно (т.е прямо в экране) переключает фонт с псевдо-графического на символьно-тайловый. Что позволяет в одном экране отобразить и псевдографику 225*180 и красивые спрайты (составленные из заранее подготовленных тайлов) и буквы и цифры.

С другой стороны, возможно, что для игр с тайловой графикой режим с 60-ю строками содержит слишком много строк (что ограничивает знакоместо в 8*8 и значит для большого спрайта надо много тайлов, число которых невелико). Если для тайловых игр выгоднее знакоместа 8*12 или даже 8*16, то графика и тайлы не сочетаются и тогда для графики выгоднее увеличить цветовое разрешение.

Узнав о высоких частотах кадров в VGA я подумал вот о чём.

В телевидении используют чересстрочную развёртку, и т.о реальная частота кадров на ЭЛТ-телевизоре не 50 ГЦ, а только 25 ГЦ. Используя покадровую коммутацию экранной области мне удавалось на ОРИОНЕ видеть 16-ти цветную картинку в 4-х цветном режиме. Для этого (используя то, что в ОРИОНЕ есть порт для апаратного переключения экранной области) с помощью простейшего триггера, чётный кадр считывался из одной области ОЗУ, а нечётный с другой. Никаких мерцаний при этом не было (т.к время послесвечения в телевизоре и рассчитано на 25 ГЦ), но визуально яркость картинки заметно упала.

Когда я поделился этой идеей на ZX-PK.ru, то завсегдатаи форума меня сразу затоптали, утверждая, что они настолько крутые, что им и при 100 ГЦ мерцание заметно, так что при 25 ГЦ будет сильное мерцание. А ведь первые 30 лет существования (до середины 1920-тых) частота кадров в кинематографе была лишь 16 ГЦ и на мерцания вроде никто не жаловался посмотрите сами.

Ведь как всем известно из Википедии, в 1765 году Шевалье д’Арси... установил, что длительность персистенции сетчатки человеческого глаза длится тринадцать сотых секунды [ 1 ]. Т.о граница заметности мерцаний составляет 7.69 Гц. У разных народов и рас это слегка индивидуально, но считается, что если число кадров в секунду больше 10, то мерцания уже никто не заметит. Потому в немом кино частота смены кадров была всегда лишь 16 Гц. И только с появление звукового кино зачем-то подняли частоту кадров аж до 24 кадров в секунду (видимо под нажимом производителей киноплёнки, чтобы больше был её расход).

На плоских телевизорах чересстрочная развёртка конвертируется в настоящую построчную 50/60-ти герцовую (чересстрочные полукадры запоминается и складываются и затем эти сложенные два полукадра выводятся дважды). Хорошие плоские телевизоры выводят такой сводный кадр четырежды и потому имеют частоту кадров 100/120 ГЦ при частоте обновления картинки в те же 25/30 ГЦ. Производители в рекламах утверждают, что при бОльшей частоте кадров меньше устают глаза. Но реально 120 ГЦ необходимы лишь для высокоскоростных кабельных, интернетных и DVD-шных передач в HDMI, где в сигнале настоящие 120 ГЦ (а не 30*4).

Если при перенастройке в РК86 видеовыхода на VGA использовать режим 10H, в котором частота кадров 70 ГЦ и использовать тот же принцип черескадрового переключения экранов, то частота кадров будет 35 ГЦ. Это уже намного больше, чем 25 ГЦ. Я очень сомневаюсь, что мерцания 35 ГЦ будут заметны.

Даст такая идея что-либо полезное для улучшения видео возможностей РК86 ?

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

На первый взгляд кажется, что на РК с его текстовой породой это позволит лишь увеличить число цветов на знакоместо. Во первых, можно увеличить число цветов символов с 8 до 16. Но это нам совсем не интересно, т.к 8-ми цветов при низком цветовом разрешении вполне достаточно. Но можно во втором экране атрибутами раскрашивать фон. Тогда это даст нам 8 цветов для раскраски букв и 8 цветов для раскраски фона (в базовом цвете раскрашиваются только буквы, фон остаётся чёрным, хотя можно реверсить имея цветной фон, но с чёрными буквами).

Но, как неоднократно упомянуто в предыдущих постах, у РК86 есть и графические режимы и при некоторых простых доработках, они даже не такие уж плохие. Используя переключаемые с перидом частоты 35 ГЦ два экрана мы можем выводить монохром с разрешением ~200*100 с двумя градациями яркости на каждую точку. А если знакоместо раскрашено, то мы получаем уже 2 цвета в пределах знакоместа вместо одного. Визуально такая картинка очевидно должна выглядеть существенно лучше, - цветовое разрешение поднято вдвое (ценой снижения общей яркости).

Если в псевдографическом фонте знакоместо разложено на 3*2 пикселя и в чётном кадре мы будем выводить чётные линий развёртки, а в нечётном кадре нечётные линии развертки, то бы получим обычную чересстрочную развёртку как в телевидении, причём с частотой аж в 35 ГЦ (при цветовом разрешении 67*120). Только в каждом полукадре при экране 200*120 не 312.5 линий, а лишь 128 (64*4:2) линий. С чего вдруг, если в телевидении в точно таком же режиме видеовывода экран даже при всего 25 Гц нисколько не мерцает, здесь аж при 35 Гц он вдруг будет мерцать?

В общем, такая идея при повышенной частоте кадров это тоже очень перспективное поле для экспериментов.

В свое время я учился в киновидеотехническом колледже, что на правды, далее в университете кино и телевидения что через дорогу от колледжа ))). Так вот, 23кпк (кинопроектор) с частотой кадров 24Гц существовали во всех кинотеатрах страны вплоть до 2010г. О чем Вы говорите? Вы в кино видели мерцание? Насчет мерцания на экране нам вдолбили так, что я готов даже найти теорию как видит человеческий глаз. А видит он сплошное изображение начиная с 15ти герц. Простейший пример, собрать генератор на 555 подключить к нему светодиод и регулировать переменным резистором частоту до тех пор , пока глаз не увидит сплошное свечение. А потом замерить частоту осциллографом или частотомером. Диванных умников полно (с яйцефорума), они даже не понимая о чем речь будут спорить. По поводу яйцефорума, да простят меня те тысячи пользователей , умных инженеров и программистов там можно посчитать на пальцах рук, остальные.....
Я кстати уже придумал, как применять в играх так называемый "гигаскрин". Если честно я не понимаю почему его так обозвали.
Так вот, быстрая смена кадров и контроль их смены можно применить в следующих игровых сценариях:
1 - Финальный экран, когда игра пройдена и игрок зашел на последний экран, то можно поздравить его порадовав глаз красивой картинкой доселе невиданных на рк цветов.
2 - скрытые комнаты , если в них попал - то можешь увидеть какую нибудь супер херь, которую добыл, вырисованную в других неестественных цветах
3 - конец игры... ну например что то рвануло да так, что все цвета поменялись... это будет круто.
4 - конечно же заставка. Чем красивее заставка, тем больше интрига в содержимом игры.
Я почему загорелся кодить именно под рк86 - так это его ну реально страшные характеристики. Если хочешь цвет - напряги мозг, хочешь сдвинуть экран?? хаха, это можно но сперва пойди застрелись или побейся лбом об стену... Хочешь динамики в играх? Можно...но процессор работает с частотой 700 кГц нет системного таймера и прерываний, все в ваших руках - программист. Хочешь поэкспериментировать с видеоадаптером? Запасись спиртным очками и валидолом, ибо ты сперва испортишь скорее зрение сбившейся разверткой от своей программы, нежели разберешься почему такое происходит . Но увы, оно того стоит, ибо не перевелись еще владельцы рк жаждущие новых игр. Писать под PC? кому твои игры будут нужны, писать под андроид? твою игру никто даже не посмотрит, писать под стм32? твоя игра будет в единственном экземпляре.....Эх, что то меня понесло.. Простите за оффтоп.