Идея по введению лучшей графики в РК86

[fifan]

Мы смотрели схемы в журнале Радио и делали похоже. Я рисую в Altiume Designer'е и там библиотек по ГОСТу почти нет - рисую свои. А так если схема нарисована по буржуйски, я не злорадствую, принимаю как есть.

[Advertiser]

[barsik]

Попробую ответить по порядку...

Кое что прояснилось, но вопросы остались.

у меня четыре пробела (коды $00, $10, $20 и $7F), но старшие биты во всех рядах этих пробелов равны 00B, 01B, 10B и 11B соответственно. При отображении такого пробела происходит "переключение" на другой набор символов путём изменения старших адресов знакогенератора

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

Из этого понял, что вывод символа с таким кодом, приводит к тому, что по концу вывода такого пробела в триггеры LS74 защелкиваются два бита (которые подаются на A11, A12 псевдо-ПЗУ фонта), что приводит к тому, что следующий символ берётся из фонта, чей номер защелкнулся в этих триггерах.

Также понятно, что раз все биты D6, D7 во всех символах каждого из 4-х фонтов выставлены в соответствие с номером фонта, то до очередного "управляющего" пробела или конца строки, последующие символы будут браться из того же фонта, т.к каждый символ задавая битами D6,D7 фонт следующего символа, сохраняет текущий фонт.

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

Но не понял зачем понадобилась сама идея самоподдержки текущего фонта, т.е зачем графикой каждого выводимого символа с помощью битов D6, D7 задавать номер фонта следующего по горизонтали символа. После включения соответствующим пробелом триггеров выбора нужного фонта, их состояние не меняется, а гашение экрана удобно делать запретом /CS "ПЗУ" фонта и привязкой его выходов на +5В (т.к фонт инверсный).

Зачем нужен буфер D6 на выходе ОЗУ фонта ?

Для коммутации фонта кодом самого символа я предлагал стандартные для этого коды 0E и 0F. Как это и делается в фирменных терминалах. А вообще на идее коммутации фонта кодом самого символа можно поиметь 32 фонта, переключаемых кодами 00...1F. Недостаток - для переключения фонта выводится пустое знакоместо, что для работы с текстом не особо вредит, а вот для графики фатально.

По принципу, как Вы вывели спрайты, freddy реализовал полноценную графику на базе ВГ75. Там для вывода поля в 2 знакоряда, т.е символьного куска экрана 64*2, со знакоместами 8*8, что из двух знакорядов даёт графическое поле (64*8)x(2*8)= 512x16, в соответствующие экранные позиции заносятся числа 0, 1, 2, 3... 127. Благодаря чему графика каждого из 128-ми символов фонта становится графикой одного экранного квадратика 8*8. ОЗУ фонта становится ОЗУ экрана, а старое текстовое ОЗУ экрана при этом играет роль счётчиков видеогенератора.

Четыре атрибута позволяют последовательно включать по экрану 16 таких полей 512*16 следующих один под другим, что и даёт полноценный графический экран 512*256 с удобным экраном в виде последовательно лежащих в "экранном ОЗУ" квадратиков 8*8. Но выгоднее с'экономить атрибуты для цвета, а для адресации по рядам использовать счётчик 561 ИЕ10 инкрементируемый по ССИ.

Кто-нибудь знает передаётся ли код (точнее его 7 битов) аппаратного графического символа (для рисования рамок) на выходы CC0...CC6 ВГ75 ?

[SegaBoy]

Кое что прояснилось, но вопросы остались.

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

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

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

Зачем нужен буфер D6 на выходе ОЗУ фонта ?

Буфер D6 разделяет шины данных статического ОЗУ и системного знакогенератора. По умолчанию у нас подключён системный знакогенератор и с его выходов мы получаем байт для следующего отображаемого символа. Во время записи в программируемый знакогенератор откроется буфер D5 и на шину данных статического ОЗУ поступит новый байт. Если не будет буфера D6, то возможен конфликт на шине.

Возможно я где-то и ошибаюсь, поправьте если не так.

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

Попробую прояснить некоторые моменты. Изначально данное изделие планировалось использовать именно с Апогеем. Одно из (главных для меня) условий - минимум изменений на печатной плате компьютера. В этом варианте единственная обязательная доработка это удаление перемычки 78-79, заботливо предусмотренной разработчиками. Остальное это подключение проводами платы устройства к обозначенным на схеме выводам.
Применение символа шириной 8 точек потребовало бы переделку (или установку нового) счётчика. Биты 7 и 8 у регистра сдвига намертво посажены на +5 вольт и даже перерезать дорожку там невозможно (только откусывать и отгибать ножки микросхемы). Вывод по умолчанию осуществляется через шестой бит, а не восьмой - тоже потребовались бы переделки на печатной плате.
Так что в данном случае это самое простое (и я надеюсь что элегантное) решение, продиктованное имеющимися ограничениями = ))

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

Кто-нибудь знает передаётся ли код (точнее его 7 битов) аппаратного графического символа (для рисования рамок) на выходы CC0...CC6 ВГ75 ?

Да, передаётся. Это легко проверить на реальном РК или клоне. Если занести такой символ в экранную память, то отобразится символ соответствующий младшим семи битам.
Попробую сделать скриншот...
В самой верхней строке 12 спецсимволов с кодами от 0000 до 1011

[barsik]

Использование битов D6, D7 в самой графике фонтов для формирования номера фонта хуже, чем любое другое решение, т.к для удобного использования ZX-графики лучше иметь переделку на полноценный фонт шириной в 8 точек.

Вам пришлось конвертировать байтовую графику от ZX в графику по 6 битов на экранный байт ? И даже при 6-ти битовом фонте лучше эти два бита D6, D7 истратить под что-то полезное, например, цвет с бОльшим разрешением (свой цвет на каждую линию знакоместа, вместо общего цвета на все 8 линий знакоместа).

Не лучше ли перенести область загрузки фонта в область 8400...BFFF ? Это позволит постепенные дальнейшие доработки, в частности позволит провести макетирование полноценной графики.

Тогда, истратив всего несколько проводков, чтобы ввести коммутацию ОЗУ-шных знакогенераторов атрибутами ВГ75, получится полноценная графика. Отмакетировав с атрибутами, далее можно освободить атрибуты для цвета и добавив счётчик 561 ИЕ10, инкрементируемый по ССИ, получить уже цветную графику с объёмом экранного ОЗУ в 8...12 кб.

В данном случае у нас программируемый знакогенератор и эти коды "заняты" не навсегда, а только для одной конкретной программы.

Да, использование в играх пробела 7F не повредит, если по сбросу грузить фонт, в котором все биты D6, D7 =1.

Не понял почему "родной" фонт прошитый в ПЗУ РФ2 остался и для борьбы с ним пришлось вводить буфер D6. Для макетирования достаточно его деактивировать подачей "1" на его /CS. А в окончательной конструкции этого ПЗУ вообще не должно быть, - по сбросу из ПЗУ (или ROM-диска) в ОЗУ фонта грузится базовый фонт РК86.

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

Я так и думал, т.к это упрощает микросхему. Это можно использовать, чтобы из выходов LA0, LA1 управляемых графическими символами получить больше, чем один атрибут.

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

[SegaBoy]

Использование битов D6, D7 в самой графике фонтов для формирования номера фонта хуже, чем любое другое решение, т.к для удобного использования ZX-графики лучше иметь переделку на полноценный фонт шириной в 8 точек.

Не лучше ли перенести область загрузки фонта в область 8400...BFFF ? Это позволит постепенные дальнейшие доработки, в частности позволит провести макетирование полноценной графики.

Не понял почему "родной" фонт прошитый в ПЗУ РФ2 остался и для борьбы с ним пришлось вводить буфер D6. Для макетирования достаточно его деактивировать подачей "1" на его /CS. А в окончательной конструкции этого ПЗУ вообще не должно быть, - по сбросу из ПЗУ (или ROM-диска) в ОЗУ фонта грузится базовый фонт РК86.

Основная цель была разработать программируемый знакогенератор для Апогея, а не переделать Апогей.
У Апогея жёстко прибито знакоместо на 6 точек - ничего с этим уже не поделать (не кромсая компьютер). Единственная доступная область памяти куда можно "безболезненно" подсунуть знакогенератор это $F800-$FFFF - все необходимые сигналы генерируются на плате, а ПДП не мешает, так как "висит" по адресам $F000-F7FF. Родной фонт не планировалось удалять или изымать - он неотъемлемая часть компьютера, а плата знакогенератора всего-лишь довесок. По (моей) логике работы родной фонт постоянно включён, когда выключен "новый" знакогенератор.

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

Наверное в каком-то другом решении использовать биты D6 и D7 это неправильно. Но насколько я могу видеть - в "классических" решениях они вообще никак не используются. И в первой версии знакогенератора я их тоже не использовал. Из доступных 8 килобайт в микросхеме ОЗУ бесполезно пропадали 6 килобайт. Поэтому были попытки найти решение для использования этой памяти под дополнительные наборы символов, а так же найти решение для переключения этих наборов. Использовать LA0 и LA1 для переключения я не стал, так как не совсем разобрался как они работают и не был уверен в конечном результате. Использовать "ранее никому не нужные биты" показалось самым оптимальным решением. Они и так никому не нужны - пусть послужат делу.

П.С. Возможно мне стоило изначально создать тему "Программируемый знакогенератор для Апогея", чтобы не вводить в заблуждение владельцев и пользователей классического РК или других клонов.

[Titus]

Раз уж тут собрались знатоки ВГ75, то может быть кто знает, отличается ли она от i8275 или же является ее полным клоном? Равно как и ВТ57 против i8257.

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

Заодно, может быть кто знает что-то о следующих вещах (в инструкции к 8275 описаны, но не поняты):

1. Что такое 'Spaced Rows'? Этот флаг может быть установлен в команде Reset.
2. Что означает вот эта сноска:

3. Что делает Preset Counter Command?
4. Как в режиме Character Attribute Codes контроллер вычисляет, где находится середина знакоместа? (позиция Underline). Просто делит параметр 'число линий на строку' пополам?

[IgorR76]

П 2. Всё просто. uuuu - номер строки подчёркивания. Если больше 7 - то верхняя и нижняя строки растра в символах бланкируются, если меньше- то нет. Этот номер строки и определяет п4.

[SegaBoy]

1. Что такое 'Spaced Rows'? Этот флаг может быть установлен в команде Reset.

На первой картинке экран "здорового человека" - стандартный экран РК86 - три пустые строки сверху, 25 видимых строк и две пустые снизу, ну и плюс одна строка на кадровый синхроимпульс (30+1). Занимает в памяти 78*30=2340 байт.
На второй - экран "курильщика" - режим с включённым атрибутом Spaced Row - две пустые строки, 12 отображаемых и одна снизу пустая, так же плюс одна строка на кадровый импульс (15+1). Занимает в памяти ровно в два раза меньше 78*15=1170 байт. В этом режиме после каждой строки символов ВГ75 генерирует ещё одну, но полностью пустую строку - получается такой "через-строчный" режим.

[freddy]

freddy реализовал полноценную графику на базе ВГ75.

что и даёт полноценный графический экран 512*256 с удобным экраном в виде последовательно лежащих в "экранном ОЗУ" квадратиков 8*8. Но выгоднее с'экономить атрибуты для цвета, а для адресации по рядам использовать счётчик 561 ИЕ10 инкрементируемый по ССИ.

Немного уточню. У меня разрешение 640x400@70Гц, самый, что ни есть, VGA-шный VGA. Pixelclock стандартный 25Мгц. Видеопамять 32к с одновременным доступом процессора и видеоконтроллера. Они даже не знают о существовании друг друга При этом подразумевается, что процессор и видеоконтроллер работают асинхронно, доступ к видеопамяти осуществляется с помощью специального сиквенсора, переключающего шины управления, адреса и данных видеопамяти в определенной последовательности. Fillrate получается 1,6Мб/c, что дает возможность прокачать 50 раз в секунду 32-х Кб экран. В случае с 8080 50FPS- запредельный праметр с большим запасом на разгон/апгрейд процессора.
На настоящий момент - эта технология признана бесперспективной, мой компьютер с 80-м процессором на 3,6Мгц ворочал такой графикой со скрипом. Если двигать фигурки персонажей 128х32 пикселя то нормуль, а если перерисовывать экран, то начинается драма. Видно как прорисовывается. Был сделан вывод, что видеокарта не для этой машины, а также нужен другой подход.

Вот теперь пора и по РК-шке вставить свои 5 копеек. Постараюсь высказаться кратко и сильно не тролить кривость авторов РК-шки.
В общем то, если говорить о классике, на оригинальной печатной плате с 32к на борту, то графика ей и не нужна. Она сильно тормознее 3,6Мгц, поэтому там совсем будет слайд шоу, даже в телевизионном разрешении. Она то и текст скролит с тормозами. Поэтому ее нужно в первую очередь хоть как то ускорить, а графику ей лепить уже потом. Как разогнать процессор, можно посмотреть у меня. Избавиться от тормозов на время DMA циклов, можно многочисленными способами. Мой способ - изолированная шина видеокарты, на которой лабает DMA, с доступом со стороны процессора через спец буфер, используя механизм приостановки DMA с захватом у нее захваченной шины ))) На стандартной плате это делать бесполезно, уйдут километры МГТФа. Проще слепить новодельную РК, ну тогда уже с исправлением остальных косяков. Будет ли такая РК-шка той РК-шкой, что раньше? Вот в чем вопрос!
Наверное не будет... Нужна ли она в таком виде кому то?
Эх.. ну и немного технического троля на счет вышеупомянутого "другого подхода". Спасти РК-шку сможет только чудо в виде 2D-акселя. Для этого нужно даблбуферинг. С одного буфера ВГ-шка будет разворачивать кадр, прикидываясь счетчиком адресов и генератором синхросигналов. А в другом видеобуфере будет рендериться картинка с помощью самодельного GPU. Его задача сканировать координаты спрайтов, сравнивая с текущими координатами в видеобуфере и, при совпадении, из спрайтовой памяти быстро перелить данные в видеобуфер. Потом по сигналу VRTC буферы меняются местами. Хватит 2-3 плоскости спрайтов. Тайлы можно делать спрайтами Все это можно осилить 3-мя способами: на логике, на FPGA, на STM32
сорри за офтоп, просто увидел тему, решил заглянуть

[barsik]

что дает возможность прокачать 50 раз в секунду экран в 32 кб...

Не существует 8-ми разрядки способной обновить экран в 32 кб за 1/50 секунды. РК за 1/50 секунды не может обновить даже чисто текстовый экран, хотя он имеет размер в 20 раз меньший.

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

Делать игры в полной графике задача не стоИт.

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

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

При наличии загрузки фонтов полная графика для игр не особо нужна. И для текстообработки это тоже не надо. Это интересно лишь мне, чтобы сделать для РК86 GUI. Так при фонте 8*8 (что даёт экран 512*256) и турбировании до 2.5 МГЦ реального такта, получается ЭВМ более удобная для GUI, чем Специалист, где и скорость ниже и экранчик маленький.

оригинальной печатной плате с 32К на борту графика не нужна. РК сильно тормознее 3,6 Мгц, поэтому [в режиме полной графики] там будет слайд-шоу. Потому РК нужно в первую очередь хоть как то ускорить, а графику лепить уже потом

РК уже турбировали простой заменой кварца в ж.РАДИО 01.1991. При кварце 27 МГЦ, такт КР580 составляет 3 МГЦ (а эффективный такт ~2.5 МГЦ), хотя на практике из-за слабости шины используют кварц 22.5 МГЦ, что даёт реальный такт ~2 МГЦ.

Спасти РК-шку сможет только чудо в виде 2D-акселя

Вы ведёте речь о ужасно сложной и громоздкой конструкции. Я сторонник только простых доработок. Платка для загрузки фонтов - это уже и-так сложнее, чем хотелось бы.

Акселератор действительно нужен, но только не акселератор видео, а акселератор шины. Это делается путем подключения через розетку CPU внешней платки с Z80B на такте 10 МГЦ со своим скоростным ОЗУ. При этом экранный буфер 7700...7FFF остаётся в РУ5-тых, для доступа к экрану и В/У вводятся такты WAIT. Попутно такая плата будет улучшать архитектуру, давая сплошные 48К ОЗУ плюс 15К ПЗУ. Реальное быстродействие такого РК будет ~8.5 МГЦ.