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

Интересно, что РК86 из-за своей схемотехники позволяет огромное количество вариантов улучшения, в том числе и видео-возможностей. Некоторые варианты улучшения видео РК86 уже опубликованы и обсуждены на других сайтах (некоторые варианты даже опробованы в реале). Недавно я придумал ещё один способ позволяющий ввести цвет, причём без использования атрибутов ВГ75. Этот способ позволяет ввести цвет только в графический режим 128*60, а при наличии доп.фонта (соответственно для высоты знакомест в 6 и 4 линии) и в режимы 128*86 и 128*102.

Первое, что приходит в голову, когда речь заходит об улучшениях видео возможностей РК86, это использовать хотя-бы те возможности, что изначально заложены в БИС ВГ75. В частности атрибут ReVerseVideo (RVV), который позволяет инвертировать знакоместо. Схема проста: VIDEO с  выхода ИР13 пропускают через вентиль из 555 ЛП5 на второй вход которого заводят управляющий атрибут. Расход деталей один корпус, зря авторы РК это не использовали.

ВГ75 может ещё аппаратно выводить 11 символов для рисования рамок (расход деталей диоды и резисторы) и может обеспечивать подчёркивание символов. Ну и естественно гораздо лучше было бы применить для фонта матрицу 8*8, что не только выглядит намного красивее, чем изначальный фонт 6*8, но и намного разборчивее на телевизоре (при вертикальных линиях шириной в 2-3 точки).

Схема для улучшения фонта одновременно повышает и быстродействие. При кварце 20 МГЦ ускорение составляет 34% (ускорение не пропорционально соотношению частот кварцев, т.к быстрее начинает работать и ПДП отчего короче становится период захвата ПДП). Но если у пользователя хреновая реакция и ему трудно играть в игры на повышенной скорости, то можно для тактирования ВГ75 собрать отдельный генератор на 20 МГЦ, оставив такт ГФ24 равным исходным 16 МГЦ. Кроме замены такта на входе счётчика надо выкусить 155 ИЕ4, впаять 155 ИЕ5 и поставить диоды по схеме.

Схема ReVerseVideo - типовая, хотя кажется, это не та же схема использования RVV из журнала "Радиолюбитель" 04.1992 (кажется добавлен триггер, чтобы сдвинуть позицию). Обратите внимание, что в схеме Reverse Video красными крестиками обозначены переделки, что делаются при фонте 8*8. Если Вы делаете Reverse Video до переделки на фонт 8*8, т.е со старым фонтом 6*8, то делать разрезы указанные красными крестами не надо.

Насчёт инверсии знакомест за счёт атрибута Reverse Video. Нет программ которые используют аппаратную инверсию в программах (если такие и были, то не сохранилось). В начале 90-тых, после прочтения статьи в ж.Радиолюбитель я сделал себе Reverse Video, т.к для Нортона нужна была инверсия знакомест. Оказалось, что инверсия атрибутом RVV неудобна, из-за того, что ROM-BIOS РК это не поддерживает, все последующие экранные позиции сдвигаются, вывод происходит не там и курсор мигает в другом месте.

Поэтому я ввёл инверсию знакомест намного более удобным способом. Я использовал альтернативный фонт, в котором вместо русских букв прошиты латинские, но с инверсией знакоместа, а вместо символов "якобы точечной" графики (коды 0...1F) прошиты символы для рисования рамок из настоящей псевдографики (причём в фонте есть как инверсные так и неинверсные рамки). К сожалению, из-за свойств ВГ75 общее число символов на экране без задействования атрибутов не может превышать 128, из-за чего при инверсии общее число отображаемых символов падает вдвое. А атрибуты, заняли на цвет. Вот и приходится решать трудную задачу, как поиметь и инверсию знакомест и КОИ-8 и цвет и графические режимы повышенного разрешения.

Конечно, если речь о улучшении видео возможностей, надо думать и о цвете. Для РК86 известна всего одна реализация цвета, описанная в той же статье "Цветные РК86" в журнале "Радиолюбитель" 04.1992.  В этой конструкции на цвет истрачены все 4 атрибута - инверсия, яркость и оба GPA (General Purpose Attributes).

Что печально, т.к использование хотя бы одного атрибута для целей коммутации фонта позволяет обойти ограничение в семибитовости выводимых символов, т.е иметь на экране одновременно более 128 разных букв. Т.к атрибут может менять управляющий сигнал прямо в строке, то уже один атрибут позволяет одновременно отображать на экране 256 символов, т.е даёт латинские буквы большие и маленькие, КОИ-8 вместо КОИ-7 и символы для рисования рамок.

А 4 атрибута позволяют иметь 16*128=2048 разных символов, например тайлов спрайтов фигурок в разных фазах. Если использовать спрайты размером 2*2 знакоместа, т.е когда каждый спрайт состоит из 4-х тайлов и хранить для каждой фигурки 16 фаз (чего достаточно для мультипликации), то один спрайт занимает 16*4=64 кода в фонте. Что теоретически позволяет иметь 2048:64=32 спрайта. Т.к один символ занимает в ПЗУ фонта 8 байт, то весь фонт в 2048 символов занимает 2048*8= 16 кб, т.е половинку ПЗУ 27256.

Таким образом, получается, что мы можем иметь или цвет и старый фонт в 128 символов или множество символов, в том числе КОИ-8 и спрайты для игр, но без цвета. На мой взгляд монохромные игры с красивой графикой лучше, чем цветные, но с фигурками состоящими из букв.

Можно попробовать использовать лишь 3 атрибута на цвет, а 1 атрибут отдать на коммутацию фонта. Тогда 2 бита кодируют цвет, 1 бит определяет  задаётся цвет для символа или для фона, и последний бит выбирает текущую половину знакогенератора. Для системных программ это вполне удобно, т.к там число цветов не особо важно, т.к цвет в системном ПО служит лишь для выделения участков экрана. А как для игр?  Общее число цветов - 5 (т.к в зависимости от RVV, или фон или символ - всегда чёрный). Всего 256 символов. Используя спрайты 2*2 знакоместа и всего 8 фаз для каждого спрайта, на спрайт тратится 8*4=32 знакоместа. Итого в фонте умещается всего 8 спрайтов. Если использовать 7 спрайтов, оставив 32 символа для формирования пейзажа, то этого достаточно для многих игр.

Есть ещё одна возможность улучшить видео возможности РК для игр. Вспомним, что в первой микро ЭВМ Apple-II для первых игр использовался цветной режим с разрешением 40*48. Разрешение низкое, зато каждый из 40*48= 1920-ти квадратиков на экране мог быть любого из 16-ти цветов. В 1977 году этого всем хватало, пользователи визжали от восторга, играя в цветной тенис. Да и первые игровые автоматы имели графику не намного лучше. Т.о ясно, что для антикварных игр пригоден даже режим очень низкого разрешения экрана, особенно если при этом число цветов 16 или более.

Собственно говоря, РК86 изначально имеет псевдографический режим 128*60. Это получается перепрограммированием ВГ75 на высоту знакоместа в 8 линий растра вместо 10-ти, отчего видимыми становятся уже 30 строк вместо 25-ти, и использованием имеющейся "якобы псевдографики" с кодами 0...1F. Называть графический режим РК86 псевдографикой неправильно. Псевдографика - в текстовом адаптере IBM PC, а это не псевдографика. Правильно такой называть не псевдографикой, а матрично-символьной графикой, а по сути это эмуляция поточечной графики текстовым режимом.

Распределение матрично-составленной псевдографики в фонте РК сделано так, чтобы коды графических символов не попадали на упр.коды терминала, благодаря чему эти символы можно выводить через консольный вывод, т.е 16 графических символов хитро распределены в интервале кодов 0...31.

Если 16 матричных символов прошить в альтернативный фонт подряд, т.е в местах для кодов 00...0F, и повторить ещё 7 раз в областях 10...1F, 20...2F.... 70...7F, то получится цветной режим 128*60 с 8 цветами, хотя и не на пиксель а на знакоместо, т.е сразу на 4 пикселя. При этом цвет задается кодом символа, точнее битами D6, D5, D4 кода символа (эти биты могут соответствовать цветам R G B), а вид выводимой графики задаётся битами D3...D0. Такой режим цветной блочной графики по разрешению в 6-8 раз лучше цветных режимов низкого разрешения в Apple-II.

Расход деталей на введение такого режима - защёлка цветов, это трёхбитовый регистр (например на 155 ТМ5 или ТМ7) и мультиплексор 555 КП11, который при включении цвета выдаёт RGB с выхода трёхбитового регистра цвета, а при включении монохрома выдаёт на RGB единицу (когда в видеосигнале идёт 1).

ВГ75 позволяет программно менять как размер знакоместа, так и формат экрана. К сожалению, ради экономии одного TTL-корпуса (ценой в 40 копеек), в РК86 сигналы ССИ и горизонтальный бордюр формируются программно. Замечу, что насчёт того, что вертикальный бордюр - программный, возражать трудно. Т.к это сделано авторами сознательно из-за 565 РУ3. Ведь если бы использовали ВГ75 по РТМ, когда гашение по кадрам аппаратное, то между кадрами регенерация 565 РУ5 прерывалась бы на время более, чем 2 МСЕК и динамическое ОЗУ не могло бы хранить данные. Поэтому отображение строк идёт без перерывов, а бордюр и гашение луча формируются программно за счёт вывода чёрных знакомест. Но вот формирование горизонтального бордюра также программно, как и вертикального, это ошибка разработчиков ради пустяшной экономии.

Из-за этого в РК86 никак не изменить число знакомест на строке, оно всегда 78 (но видимы только 64). Можно менять только высоту знакоместа, а тем самым число строк (т.к общее число видимых линий растра при частоте кадров 50 ГЦ неизменно, порядка 260 из общих 312). К сожалению, базовый фонт РК86 позволяет использование для вывода графики только знакоместа высотой в 8 или 4 точки. Что даёт базовый графический режим 128*62 и теоретически для современных телевизоров возможен режим 128*51, который имеет частоту строк в 60 ГЦ (51 видимая строка высотой 4 линии). Первый режим широко используется в играх, а режим 128*51 не был доступен в 80-тые (т.к советские телевизоры не синхронизировались на 60 ГЦ), но стал доступен сейчас. Используя эту возможность современных телевизоров, режим в 51 видимую строку высотой в 4 линии растра и разложение знакоместа в матрицу 2*2 vinxru изобрёл графический режим с разрешением аж 128*102.

Улучшить графические возможности для игр позволяет альтернативный фонт. Не важно программно включаемый или тумблером. Наилучшим по разрешению можно считать нестандартный по частоте кадров режим 192*102 с высотой знакоместа в 4 линии. Этот режим получается из режима с 51 строкой за счёт деления знакоместа 6*4 по вертикали вдвое и по горизонтали втрое.

Но я предпочитаю (т.к у меня фонт шириной в 8 точек) режим получаемый за счёт альтернативного фонта высотой в 6 линий. Это 43 видимых строки высотой в 6 линий растра при стандартной частоте кадров. Такой режим при матричной графике с матрицей 2*3 пикселя в знакоместе обеспечивает разрешение 128*129. Такой режим есть в Партнёре. Псевдографика занимает 64 символа в ПЗУ знакогенератора. Остальные 64 символа позволяют иметь 32 буквы в матрице 8*12. Каждая буква состоит из двух поставленных одно над другим знакомест. Для этого режима у меня есть текстовый драйвер дающий 21 символ в строке.

Ещё один удобный режим можно получить при использовании знакоместа высотой в 9 линий и матричной графики также 2*3 пикселя, что требует наличия в фонте 64 граф.символов. Тогда 29 отображемых строк дают экранное разрешение в 128*87. В этом режиме пиксель более квадратный и остаётся возможность вывода 64 символов высотой в 9 линий. Вспомним, что в Apple-II, тоже было всего 64 символа, но это не помешало его выпуску тиражом в 6 млн. Для использования такого режима нужно обеспечить неразрывность знакомест по вертикали (см. следующий пост).

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

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

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

С помощью всего одной 555 ЛЛ1 (или КП11) и перезашивки фонта от межстрочных разрывов легко избавиться. Для этого достаточно, когда выводятся 9-я и 10-я линии знакоместа, т.е когда сигнал LC3=1, с помощью этого же сигнала LC3 сделать сигналы LC0, LC1, LC2 на входах ПЗУ равными единице, что приведёт к повторной выборке из фонта графики 8-й линии графики символа.

Идея заимствована из VGA-адаптера. Там встроенный фонт имеет матрицу 8*14 (или 8*16), но можно включить режим когда фонт выводится в матрице 9*14 (или 9*16), что достигается тем, что девятый горизонтальный пиксель знакоместа всегда повторяет 8-мой. Это приводит к тому, что горизонтальные линии начерченные псевдографикой выводятся без разрывов.

Здесь тоже самое, только по вертикали. Изменив фонт так, чтобы во всех буквенно-цифровых символах фонта 8-я линия была пустой, 9-тая и 10-тая линии повторяющие 8-ю - также будут пустыми. Благодаря этому в символах псевдографики вертикальные линии получатся сплошными без разрывов.




Вообще я собираюсь когда-нибудь странслировать альтернативный ROM-BIOS для РК86 для текста в режиме 30-ти строк. Это удобнее всего, если ПЗУ F800 двухстраничное в окне 2 кб (т.е две напаянных друг на друга РФ2). Тогда, например, по записи любого числа в FC00 включится альтернативное ПЗУ РК86 (по записи в F800 и сбросу - стандартное ПЗУ F800). Альтернативное ПЗУ будет идентичным стандартному, только экранный буфер будет размером в 38*78= 2964 байтов. Начало экрана вероятно будет на 7400, рабочие ячейки - на 7FA0...7FFF.

Можно также странслировать такое ПЗУ с драйвером на 30 строк и на E000 или 9000, тогда можно большую часть кода использовать из стандартного ПЗУ (добавляется векторизация входов для работы с экраном и клавиатурой).

Описанная в предыдущем посте идея по расширению графики в знакоместе по вертикали может быть с успехом применена и по горизонтали.

В базовом РК знакоместо имеет размер 6*10 (а фонт 6*8 ). В моём личном РК путём замены счётчика ИЕ4 на ИЕ5 знакоместо увеличено до размера 8*8 и фонт значительно более красивый. Но для альтернативных граф.режимов 192*102 (60 ГЦ) или 192*90 (50 ГЦ), где знакоместо по горизонтали разбивается на три пикселя, ширина знакоместа в 8 точек не подходит, т.к 8 хреново делится на 3. Потому при моём красивом фонте 8*8 знакоместо по горизонтали можно разбить только на 2 пикселя, отчего максимальное разрешение по горизонтали ограничено всего в 128 точек.

А для более качественной графики выгоднее высокое разрешение именно по горизонтали (в частности, это даёт бОльшее число символов в строке и более разборчивый шрифт). Чтобы при знакогенераторе с фонтом 8*8 расширить знакоместо до 9 точек можно использовать биты из 8-го столбца знакоместа, т.е выводить колонку 9 в знакоместе такой же как 8-ю колонку. Это сохранит возможность сплошных горизонтальных линий, т.е полноценную псевдографику. Такой трюк применялся и в промышленных текстовых адаптерах.

При этом также несколько увеличивается междубуквенный интервал, т.е фонт занимает поле 7*8 и две точки разделяют символы (что кстати, делает фонт более разборчивым). Реализуется это увеличением частоты кварца до 20:8*9= 22.5 МГЦ, что при использовании такого кварца для ГФ24 увеличивает такт КР580 до 2.5 МГЦ. И требуется добавить ТМ2 и ЛА3, чтобы сделать равным 9 коэфф-т деления счётчика в формирователе такта знакомест (и защёлкивать 9-тый бит). Как известно, быстродействие РК при повышении такта растёт больше, чем простое соотношение частот, т.к при большем такте ПДП быстрее закачивает строку в ВГ75, отнимая у CPU уже не 26% времени, а меньше.

Так соотношение частот 2.5 МГЦ и 1.77 МГЦ равно ~1.41. Это значит, что ПДП будет занимать шину не 26% времени, а в 1.41 раза меньше, т.е всего 18.4% времени. Тогда процессор 81.6% времени будет прогонять программу на такте 2.5 МГЦ, что в итоге даст эффектифный (реальный) такт 2.5*0.814= 2.035 МГЦ и чуть превысит быстродействие Специалиста (у которого такт ровно 2 МГЦ). Что означает ускорение в 1.55 раза относительно реальной скорости базового РК в 1.31 МГЦ.

Естественно, цель расширения знакоместа до 9 пикселей - не ускорение CPU, а получение режима графики 192*90, основное применение которого это игры, где скорость д.быть равна базовой. Потому разумно ввести отдельный генератор на 22.5 МГЦ на отдельной 531 ЛН1 для ВГ75, оставив такт для ВТ57 и КР580 равным как и в базовом РК 1.77 МГЦ, т.е оставив стандартную скорость прогона программ (что необходимо для использования РК-игр тем, у кого пониженная реакция).

При этом разумно ввести кнопку ТУРБО, для чего придётся добавить мультиплексор и однобитовый стробирующий регистр, чтобы переключение Турбо--Нетурбо происходило без сбоев. Таким образом общее число дополнительных ИМС достигает четырёх (КП11, две ТМ2 и ЛА3).

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

Конечно лучше всего переключать фонты атрибутами ВГ75. Но они уже заняты на цвет. Не думаю, что стОит губить цвет. Можно, конечно, попробовать как-то совместить коммутацию фонтов с цветом, для чего придётся "нагромоздить", но проще ввести доп.фонты просто кусочками проволоки.

В РК-МАКСИ для управления фонтом использовался бит PC3 клавиатуры. Это бит для светодиода РУС/ЛАТ. У них этот бит не только зажигает светодиод, но и включает мелкие русские буквы вместо латиницы. Это вполне грамотно, т.к и индикация РУС-ЛАТ остаётся и биты не тратятся.

При стандартной РК матрице два бита PC1 и PC2 не используются. Два бита позволяют выбрать 4 фонта. Таким образом, если фонтов всего 4 (прошитых в две РФ2), можно сохранить светодиод РУС/ЛАТ подключенный на PC3.

Меня светодиод РУС/ЛАТ не волнует, т.к удобнее индицировать регистр клавиатуры формой курсора и высотой тона подзвучки нажатий. Кроме того, в РК есть возможность при включённом русском регистре выводить рамку по краю экрана (как бы бордюр, в MSDOS-русификаторах индикация русского регистра цветом бордюра была очень удобна). На светодиод расположенный на клавиатуре при наборе текста никто не смотрит, потому у меня не было вообще никогда светодиода РУС/ЛАТ.

В 90-тые годы я не догадался использовать PC1...PC2 и использовал для переключения фонтов биты с запасного ППА D14. Тогда я использовал биты порта A (и так сделано в моём эмуляторе РК на ОРИОНЕ), но теперь считаю, что разумнее использовать свободные биты порта C клавиатуры, т.к это не конфликтует с ROM-диском.

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

В принципе, не важно как конкретно коммутируется фонт, т.к можно ввести дополнительную стандартную подпрограмму ROM-BIOS (F842), которой в регистре А будет передаваться номер фонта. А уж подпрограмма ПЗУ сама знает как в данном конкретном компьютере переключается фонт. Например,  не получится переключать фонт с помощью битов порта C клавиатуры, если на РК используется клавиатура с иной матрицей (например 6*12 или 8*16), отчего биты PC1...PC3 заняты.

Но для тех, кто использует базовую РК-клавиатуру с матрицей 8*8 + 3 спец.клавиши невозможно придумать более простой и разумный способ коммутации фонтов, чем PC1, PC2 и, при отказе от светодиода РУС/ЛАТ, и PC3, что даёт с затратой всего в три кусочка проволоки 8 фонтов.

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

Быстродействие РК86 в базовом режиме (для текста 64*25), что устанавливается по сбросу известно. Опытным путём измерено, что в этом режиме реальный (иногда говорят эффективный) такт РК86 соответствует нетормозимому циклами ПДП или WAIT-ами компьютеру с тактом 1.31 МГЦ. Потери возникают из-за того, что не всё время процессор прогоняет программу, а в какие-то моменты останавливается захватом шины на 4*8=32 маш.такта (в ПДП-пачке 8 байт, 4 такта на байт).

Посчитаем сколько процентов скорости теряется впустую. Делим 1.31 МГЦ на 1.78 МГЦ, что даёт 0.7369. Это означает, что процессор работает на программу лишь 73% времени, а почти 27% сжирает видеовывод. Это происходит в стандартном режиме, когда 30 строк прогоняются с ПДП и лишь одна строка (когда идёт обратный ход по кадрам и ВГ75 не запрашивает байты у ПДП) прогоняется на максимальной скорости (1.777 МГЦ).

Теперь посчитаем, какой выигрыш в быстродействии даёт замена фонта 6*8 на более красивый фонт 8*8. При такой доработке схемы РК выполняется замена счётчика 155 ИЕ4 на ИЕ5, что меняет коэффициент деления с 6 на 8, а кварц у ГФ24 заменяется с 16 МГЦ на 20 МГЦ. На первый взгляд кажется, что увеличив такт CPU в 20:16= 1.25 раза во столько же, т.е на 25% увеличится и быстродействие машины. Однако это не так, т.к на те же 25% увеличивается и такт ПДП. Что приводит к тому, что требуемые для каждой строки 78 байтов быстрее перекачиваются в режиме DMA в ВГ75. То есть бесполезная потеря времени составит уже не 27%, а в 1.25 раза меньше.

Считаем какую часть времени будет сжирать ПДП при клоке 20 МГЦ. Это будет (1-0,7369):1.25= 0,2104. Т.е при кварце 20 МГЦ ПДП отнимает у процессора уже не 27% времени, а лишь 21%. И таким образом общее быстродействие получается: (20:9)*0.79= 1.755 МГЦ, а общее ускорение относительно базовой модели составит 1.755:1.31= 1,34 раза. Т.е при повышении частоты кварца на 25% скорость прогона возросла на 34%. При этом играть в Ксоникс становится намного труднее и на это способны лишь люди с хорошей реакцией. Можно установить отдельный генератор на 531ЛН1 для тактирования видеосхемы, оставив такт CPU и ПДП прежним получаемым из кварца 16 МГЦ, т.е 16:9= 1.777 МГЦ (на 9 делит входной такт ГФ24). При этом и качественный шрифт есть и быстродействие не изменится.

Теперь посмотрим, что происходит в стандартном графическом режиме 128*62. В этом режиме ВГ75 в кадре 39 строк высотой в 8 линий растра (39*8=312). На ЭЛТ-телевизорах видимы обычно около 250 линий из 312, (хотя у современных LCD-телевизоров можно увидеть и 280 линий), 31 строка высотой в 8 линий ещё нормально отображается на большинстве телевизоров, т.к умещается в 31*8= 248 линий.

Измерений в реале быстродействия в разных режимах никто не делал. И не особо ясно прямая ли зависимость между числом строк и временем CPU, что отнимает обслуживание ВГ75. Вероятно, если общее число строк увеливается с 32 до 40, то во столько же раз увеличивается время работы ПДП. Тогда (1-0,737)*(40:32)= 0,33 часть общего времени приходится на работу ПДП. И соответственно быстродействие в стандартном граф.режиме падает до (1-0,33)*1.777= 1,189 МГЦ, т.е по сравнению с текстовым режимом скорость падает ещё на почти 10%.

Теперь посмотрим на сколько падает скорость в режиме 52 строк. (1-0,737)*(52:31)= 0,441 это такую часть времени отнимает ПДП при графике 128*86 и строках высотой в 6 линий. Таким образом реальный такт в этом режиме (1-0,441)*1.777= 0,993 МГЦ. Т.е реальная скорость упала уже до 990 КГЦ.

А в последнем, самом крутом 60-ти герцовом граф.режиме, изобретённом vinxru (с разрешением 192*102) ПДП отнимает (1-0,737)*(65:31)= 0,552 такую часть общего времени, а быстродействие CPU составляет (1-0,552)*1.777= 797 КГЦ. За максимальное повышение графического разрешения приходится платить потерей быстродействия до 800 КГЦ.

Из этого ясно, что крайне желательно турбирование до максимально возможного. Скорее всего даже с неизбежной буферизацией ОЗУ (на двух 589АП16) при 565РУ5 не удастся получить надёжную работу РК при такте КР580 более, чем 3 МГЦ (хотя сам КР580 у меня вполне надёжно работал на такте 3.55 МГЦ). Работа на частотах выше 3 МГЦ требует хорошего охлаждения процессора - вентилятор плюс массивный медный радиатор. При такте 3 МГЦ наклеив на корпус КР580 медный радиатор ещё можно обойтись без вентилятора.

Потому делать такт более 3 МГЦ имеет смысл только при Z80. Кстати,  КР580 на такте 3 МГЦ вполне надёжно работает в Векторе. Это удобно и потому, что подбор кварцев удобен именно при такте 3 МГЦ, т.к кварцы на 27-28 МГЦ широко распространены, это любительский диапазон и здесь же работают радиоуправляемые игрушки (у меня, например, десяток таких кварцев).

При такте CPU в 3 МГЦ получаем реальное быстродействие в базовом режиме 2,534 МГЦ, хотя в самом крутом граф.режиме 192*102 оно падает до 3*(1-0,552)= 1.344 МГЦ.

Недавно я узнал, что в малоизвестном, но весьма грамотном компьютере "Юниор-ФВ" построенном на базе CRT-контроллера 580 ВГ75 разработчикам за счёт хитроумной идеи удалось впихнуть вывод символов в КОИ-8 несмотря на фатальное ограничение ВГ75 по 7-ми битовости символов. Это ещё один веский довод в пользу того насколько сильно улучшают возможности РК86 дополнительные фонты. Дополнительные альтернативные фонты по деталям не стоят почти ничего, а превращают РК86 в минимально приемлемый текстовый компьютер (особенно если добавить в него хотя бы 8 или 12 кб доп.ОЗУ нужного для введения CP/M) дают лучшую псевдографику, рамки, инверсию символов, а при необходимости, даже набор графических тайлов для написания красивых игр по принципу Денди.

В постах выше сказано много слов о том насколько сильно улучшает возможности РК86 простейшая доработка по увеличению числа фонтов, давая более качественную псевдографику 192*102, рамки и инверсию знакомест. Оптимальнее всего, конечно, коммутировать фонты так как и положено, - атрибутами ВГ75. К сожалению, любители цвета уже заняли все 4 атрибута ВГ75 под цвет.

Хотя цветных РК-игр вовсе не 40, как написано в ж.Радиолюбитель 04.1992, а едва-ли их наберётся десяток (а может их даже всего пяток). Даже для Апогея БК-01Ц, где цвет врождённый, - цветных игр единицы. Причина этого в том, что радиолюбители в то время не могли позволить себе выделить для хобби цветной телевизор. Цветные телевизоры до 1990 в магазинах свободно не продавались. Они продавались только по записи (ждать около полугода) и в первую очередь льготникам и ветеранам. Например, я поимел "Рекорд ВЦ-381" (за 650 рублей) в 1988 только благодаря тому, что одному ветерану ВОВ (отцу моего знакомого) купившему его, буквально тут же представилась возможность купить другой телевизор с бОльшим экраном. До того в моей семье был только чёрно-белый лампово-транзисторный телевизор. Даже в 90-тые годы я мог использовать для хобби только монохромный монитор.

Но даже использование фиксированного фонта (т.е непереключаемого между буквами) очень полезно и полностью окупает расход в кусок дорогостоящей проволоки МГТФ-0.03. В частности, хитроумный фонт от "Юниора-ФВ" добавленный как альтернативный фонт реально полезен для текстообработки. Такой фонт за счёт расхода в небольшой кусок проволоки даёт полноценную 8-ми битовую кодировку КОИ-8 несмотря на врождённую ущербность по 8-ми битовости символов БИС ВГ75 и невозможности из-за цвета использовать атрибуты ВГ75.



Этот фонт не только даёт все символы КОИ7-Н2, но и русские буквы из КОИ-8 и полноценную кодировку ASCII нужную для CP/M, несмотря на то, что ВГ75 выводит только 128 символов. Это достигнуто за счёт оригинальной идеи заключающейся в использования похожих латинских букв в качестве русских букв. Такой фонт сохраняет совместимость для чисто текстовых программ без псевдографики. Правда, разработчикам "Юниора-ФВ" пришлось занять под отображаемые буквы код 0 и 7F. Из-за этого такой фонт может быть только альтернативным и программно включаемым, - с таким фонтом не будут работать стандартный ROM-BIOS и игры, т.к монитор в ПЗУ и игры используют код 0 в качестве пустого знакоместа, а код 7F некоторые РК-игры (по крайней мере XONIX) используют как маркированное пустое знакоместо. Любопытно, что в качестве заглавной русской буквы "З" используется цифра 3.

Потому с базовым ROM-BIOS такой фонт должен программно включать только текстов редактор. Чтобы фирменные текстовые редакторы рассчитанные на КОИ-8 работали, надо переделывать ROM-BIOS. Это теперь не проблема, т.к даже для КР580 я освободил в коде РК-ПЗУ более 250 байтов (а при Z80 свободно ~300 байт). Разумно ввести в ПЗУ управление флагом включающим режим вывода КОИ-8.

При нужде можно и при стандартном ПЗУ F800 использовать вывод символов в КОИ-8 в отдельных специально написанных программах. У меня как раз сохранился исходник текстового редактора для РК86 (не ахти какой мощный, но не хуже Микрона-2, с блоками и, т.к есть исходник, то можно его дополнить работой с любой ДОС). Сделать так, чтобы в редакторе был вывод КОИ-8 - не проблема (достаточно табличной перекодировки перед выводом символов) и вывод на экран требуется делать не стандартной функцией F809, а своей процедурой вывода с прямой записью в экран. Это превратит РК86 в полноценный инструмент для текстообработки.

Хотя EMU80 пока ни хрена не поддерживает коммутацию фонтов, но для фонта от "Юниора" хотя бы можно отлаживать ПО, т.к английские буквы совпадают и не надо (как для графического фонта) грузить программы вслепую. А вот программы в графике не отладишь, т.к подставив вместо стандартного фонта графику, на экране не видно символов и требуется загружать отлаживаемую псевдографическую программу вслепую.

Правда, недавно мне пришла в голову победительная мысль, что для отладки в эмуляторе программ работающих с графическим фонтом с матрицей знакоместа 3*2 можно выкручиваться так. Достаточно переделать ПЗУ F800, чтобы по сбросу оно грузило и запускало из ROM-диска первый расположенный там с адреса 0 ORD-файл. Такая модификация ПЗУ F800 одновременно полезна для автостарта DOS (или её холодного загрузчика) по сбросу из ROM-диска. Недавно я узнал, что эмулятор EMU от b2m поддерживает программное включение альтернативного фонта. Попозже я разберусь как это делается и сделаю для РК86 текстов редактов в КОИ-8 используя данный фонт "Юниора".

Кроме вышеприведённого фонта для вывода КОИ-8 ещё два фонта очевидны. Первый, - это фонт дающий графику 192*102 (там 64 символа с разложением знакоместа на матрицу 3*2). Второй фонт - это фонт дающий инверсию знакомест и настоящие (тонкие) рамки. Т.о набегает минимум в 4 фонта, что при программном управлении требует двух управляющих битов. К сожалению, ни у кого за 35 лет не хватило ума и смелости задать стандарт на программное переключение фонта. Журнал "Радио" предлагал это делать тумблером (а в эмуляторах их авторы даже тумблер для переключения фонта проэмулировать поленились). Хороший кандидат на биты для программного управления это биты PC1 и PC2 порта клавиатуры (т.к это экономично, расход на управление только в два куска проволоки).

В первом посте этой темы я предложил прогрессивный и удобный для программиста вариант введения цвета в РК86 для типовой псевдографики 128*62. Его удобство в том, что не используются атрибуты (которые при программировании цвета неудобны), а недостаток в том, что это годится только для матрично-символьной псевдографики с всего 16-ю граф.символами (т.е с разбиением знакоместа на 2*2 пикселя).

barsik пишет:Распределение матрично-составленной псевдографики в фонте РК сделано так, чтобы коды графических символов не попадали на упр.коды терминала, благодаря чему эти символы можно выводить через консольный вывод, т.е 16 графических символов хитро распределены в интервале кодов 0...31.

Если 16 матричных символов прошить в альтернативный фонт подряд, т.е в местах для кодов 00...0F, и повторить ещё 7 раз в областях 10...1F, 20...2F.... 70...7F, то получится цветной режим 128*62 с 8-ю цветами, хотя и не на пиксель а на знакоместо, т.е сразу на 4 пикселя. При этом цвет задается кодом символа, точнее битами D6, D5, D4 кода символа (эти биты могут соответствовать цветам R G B), а вид выводимой графики задаётся битами D3...D0. Такой режим цветной блочной графики по разрешению (т.е по общему числу доступных пикселей) в 6-7 раз лучше цветных режимов низкого разрешения в Apple-II.

Расход деталей на введение такого режима - защёлка цветов, это трёхбитовый регистр (например на 155 ТМ5 или ТМ7) и мультиплексор 555 КП11, который при включении цвета выдаёт RGB с выхода трёхбитового регистра цвета, а при включении монохрома выдаёт на RGB единицу (когда в видеосигнале идёт 1).

В очередной раз оказалось, что моя идея уже не нова. Таким образом сделана цветная псевдографика в Tandy MC-10 (и в его европейском клоне Matra Alice). Tandy MC-10 это один из многих провальных компьютеров начала 80-тых. Как писали в обзорах, у него изначально не было ни единого шанса. Какой шанс мог быть в 1984 году у машины с ОЗУ в 4 кб и без графики (т.е с параметрами 5-ти летней давности), когда на рынке бытовых машин уже господствовали бытовые компьютеры с ОЗУ от 32 кб, с графикой и цветом.

В Tandy MC-10, кстати, в качестве процессора применён микроконтроллер 6803 с системой команд 6800 (правда с тактом всего в 0.89 МГЦ, что был повышен только в Alice 90). В знакогенераторе Tandy MC-10 в коды символов 128...255 прошито 8 блоков из 16-ти повторяющихся граф.символов (матрица 2*2 пикселя). И в соответствии с вышеизложенной идеей цвет задаётся битами D6, D5, D4 кода символа (эти биты соответствуют кодам R G B).

К сожалению, в РК86 фонт содержит всего 128 символов, а не 256. Но зато в ВГ75 есть атрибуты. Один из атрибутов RVV выгодно использовать по прямому назначению для инверсии (освободив для этого один вентиль из ЛП5), а другой атрибут используем для включения цветного графического фонта. Этот атрибут одновременно переключает и фонт и режим работы видеовыхода. Переключая фонт и режим вывода этим атрибутом мы имеем в одном экране и монохромный текст 64*25/30 (причём в отличие от базового варианта РК с инверсией) и цветную псевдографику с разрешением 128*62. На мой взгляд это самый оптимальный вариант доработки РК86 до цвета.

PS. Как уже упоминал, неправильно называть графику в РК86 псевдографикой. Так сдуру обозвали это авторы РК86 и эта дурь закрепилась. Псевдографика - в текстовом режиме IBM PC. А это символьно-матричная графика. В иностранной литературе встречал название такой графики как "block graphic (2x2 sub-matrix)", хотя это тоже не отображает суть.

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

Идея использования для цвета битов в самом коде символа позволяет иметь цветной фон у графики. А традиционный журнальный цвет (РЛ 04.1992) этого не позволяет - там цвет фона всегда чёрный, а при реверсе цветов буквы становятся чёрными на цветном фоне, что выглядит некрасиво. Затрачивая три бита из кода символа на цвет погашенных пикселей (в знакоместе 2*2 пикселя) и три атрибута ВГ75 - на цвет зажжённых пикселей мы получаем в граф.режиме 128*102 почти полноценные 8 цветов и ещё один атрибут ВГ75 остаётся для переключения фонтов, что и позволяет в одном экране иметь и цветной текст на чёрном фоне и полноценно цветную псевдографику.

РК86 отвращает от себя людей отнюдь не расточительным распределением портов по адресному пространству, недостаточностью объёма ОЗУ или скоростью работы. Для сравнения, BBC micro и его бюджетный клон Acorn Electron имея те же 32 кб (причём из которых половину отжирает граф.экран) вызывал восхищение пользователей качеством графики в играх. А кстати, РК скорости хватает, а вот эффективный такт Acorn Electron в графических High-видео режимах падал до скоростей РК86 (что сократило его сбыт, т.к таких скоростей достаточно лишь для текстовой машины, а для графической машины мало).

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

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

Хотя в качестве ПЗУ знакогенератора практически во всех произведённых платах РК86 и клонов применяется ПЗУ 573 РФ2 (т.к РФ1 найти было проблематично, их выпустили мало и прекратили их производство ещё до публикации РК86). А РФ2 позволяет иметь два фонта добавив на печ.плату РК лишь один печ.проводник (или на готовой плате истратив лишь небольшой кусочек проволоки МГТФ).

Другие советские инженеры, в отличие от разработчиков РК86, не зацикленые на примитивизме догадались, что возможность смены или загрузки фонта кардинально меняет свойства текстовой машины. В компьютерах Арго, Юниор-ФВ и Электроника-КР-04 они использовали эту идею и получили видео возможности на порядки лучшие, чем РК86 при почти той же схемотехнике и деталях. Среди радиолюбителей спаявших себе РК86 многие тоже догадались, что изобразительные возможности РК86 возрастут, если добавить в него возможность загружать фонты. В принципе то же самое достигается проще - просто введением в РК86 16-ти фонтов переключаемых атрибутами ВГ75.

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

Но в XXI веке (точнее в 2012 и 2018 годах) были опубликованы два разных варианта доработки РК86 позволяющих загрузку фонтов. Если пошариться по форуму ZX-PK.ru (ориентируясь на эти даты), то там в разделе про РК86 можно найти подробности про эти конструкции. Которые на мой взгляд не имели смысла, т.к на самом деле есть намного более простой и дешёвый вариант загрузки фонтов через ППА D14. Который не только в 20 раз проще в реализации, но и не требует вторжения в плату компьютера. А эти конструкции требуют существенного вторжения в основную плату (т.е они не в виде внешнего прибамбаса, который легко подключается и снимается). И естественно, такие значительные доработки не могут рассчитывать на популярность, т.к современные владельцы РК86 не любят делать даже простые доработки на готовых печ.платах, а платы новоделы РК с модификациями архитектуры никто вообще не делает.

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

Такая конструкция проста и доступна для изготовления. Требуется заменить ПЗУ РФ2 знакогенератора на крошечную внешнюю платку с ОЗУ (и узлами развязки его от ВГ75) подключаемую через косу с разъёмом конструктива DIP-24. На этой платке стоит ОЗУ на 1 кб и для загрузки в него фонта надо управлять адресами, сигналом /WR ОЗУ и подавать на вход ОЗУ данные. Для формирования этих сигналов вполне хватает 24 линий ППА D14.

Т.к адреса РФ2 подключены к ВГ75 и мне пока не известен способ перевести выходы ВГ75 в Z-состояние, то это значит, что для развязки адресов на ОЗУ от ВГ75 нужен двух канальный адресный мультиплексор на 9 входов-выходов. Что в лоб реализуется тремя мультиплексорами 555 КП11. Но с учётом того, что выходы ППА можно перевести в Z-состояние (запрограммировав порты на ввод), достаточно двух 155 ЛП10 включённых как буфер на выходы ВГ75 (тогда при переводе выходов буферов ЛП10 в Z-состояние выходы ВГ75 и ППА не конфликтуют).

А если вспомнить, что в ZX80 мультиплексоры заменили просто резисторами, то даже две ЛП10 не требуются и вся схема для загрузки фонта сокращается лишь до самого ОЗУ объёмом в 1 кб (например две 541РУ2/6514 или половинка 537РУ10). Т.е подача сигналов с ВГ75 через резисторы в 300 Ом заменяет мультиплексоры. Благодаря этому вся крутая схема загрузчика фонтов вырождается всего в одну микросхему 537РУ10 (аналог 6216). Это на порядок проще и удобнее, чем курочить печ.плату РК86 сложной переделкой с вторжением в шины. При работе в режиме отображения выходы ППА программируются на ввод и потому никак не мешают работе видео адаптера на ВГ75.

Эту идею по загрузке фонта я знаю более 30 лет и писал о ней ещё три года назад в форумах. Тогда же я упоминал, что адресный мультиплексор могут заменить резисторы, что почти до нуля упрощает схему обрамления. Но даже при такой предельно простой реализации узла для загрузки фонтов мне лично проще в качестве ПЗУ знакогенератора применять электрически перезаписываемое ПЗУ (Electrically Erasable and Programmable CMOS ROM), у которых интерфейс как у обычного ОЗУ, но по отключению питания данные не пропадают. Которые у меня как раз есть (хотя лишь на 8 кб, чего достаточно на 8 фонтов). Применение альтернативных фонтов по сути вообще не требует никаких доработок (расход в панельку на 28 ног и 4 проволоки), а графику позволяет иметь ту же самую.

Никто из аппаратчиков среди фанатов РК86 так и не ответил мне ни на одном форуме на вопрос: "Каким образом в схеме РК86 в режиме с высотой знакомест в 10 линий (т.е 25 видимых строк) гасятся 9-я и 10-я линии знакоместа?". Похоже никто ещё не знает как эти линии в схеме РК гасятся, но они гасятся.

Теоретически 9-ю и 10-ю линии знакоместа следует гасить сигналом LC3 (который как раз и становится равным единице при выводе линий знакоместа от 9-й до 16-той). Если подать LC3 на /OE ПЗУ фонта (можно и на неиспользуемый адрес А10 этого ПЗУ), то это обеспечило бы гашение (но в схеме этого нет).

По схеме, насколько я сумел разобраться (поскольку вес на LC0...LC2 при 9-й и 10-той линии знакоместа равен 000 и 001), получается, что в 9-ю и 10-ю линию знакоместа на экран должны выдаваться первая и вторая линии фонта, т.к не смог найти в схеме РК механизма которым ПЗУ знакогенератора переключалось бы в Z-состояние на время 9-й и 10-й линий знакоместа. Вообще в ВГ75 есть специальный сигнал гашения VSP, который задействуется при выдаче встроенной псевдографики, HRTC, VRTC и миганиях знакоместа и курсора.

Кстати, у РК86 (если забыть про подчёркивание, с которым у меня ещё нет ясности) всё же работает, как минимум, один встроенный атрибут - мигание (BLINKING), т.к он в ВГ75 реализован сигналом VSP, который в схеме РК86 заведён на чип-селект ПЗУ знакогенератора на выходах которого в схеме РК стоят резисторы привязки на +5В. Что приводит к тому, что во время гашения, когда VSP=1, выходы ПЗУ знакогенератора - в Z-состоянии и резисторы привязки выдают на эти цепи единицы (что и делает гашение знакоместа, т.к в РК86 фонт инвертированный). Благодаря этому после записи в экранную позицию атрибутной команды на включение мигания, - все последующие символы будут мигать с частотой 1.5625 ГЦ (это 50 ГЦ разделить на 32) до тех пор пока в экранном ОЗУ не встретится атрибут выключающий мигание. Причём режим мигания обязательно должен быть выключен до начала строчного бордюра и ССИ. Иначе сорвётся синхронизация на экране.

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

Я упомянул, что "про подчёркивание у меня пока нет ясности", т.к ничего не знаю про подчёркивание. Т.е есть оно в РК86 аппаратно или его аппаратно нет. Вроде бы подчёркивание формируется сигналом LTEN выдаваемым =1 в той линии подчёркивания, которая задана программно при задании режима ВГ75. А она как раз в базовом режиме РК задана на 10-ю линию знакоместа, т.к одновременно этот же параметр в команде 00 задаёт и среднюю линию встроенной псевдографики и линию подчёркивания и линию курсора, когда он задан тонким штришком. Кстати, курсор тонким штришком - это программная ошибка от разработчиков ПЗУ РК86, т.к курсор целым мигающим знакоместом приятнее и именно такой курсор был в большинстве терминалов (потому я сразу же и заменил себе форму курсора в прошивке ПЗУ).

Смущает, что вроде бы в схеме какого-то из РК-клонов я встречал доп.элементы для формирования режима подчёркивания. Так что пока я не 100% уверен в наличии подчёркивания в РК86. Хотя по логике, если курсор LTEN-ом формируется и мигает по VSP, то и подчёркивание должно работать. Если подчёркивание в РК есть, то получается, что и об этом разработчики РК86 опять таки "забыли написать" в его описании, а разобраться по даташиту любители программирования сами не могли, т.к не имели даташита на БИС Intel 8275. Даташит стал доступен людям лишь с появлением у них Интернета (что для большинства из жителей СНГ произошло лишь в XXI веке), но к этому времени, естественно, исчезли уже и сами программисты для РК86.

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

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

А при попытке прогуглить Интернет по ключу "подчёркивание в РК86" наткнулся на одно лишь туманное упоминание об этом вот здесь. Выше в той теме упоминается, что подчёркивание имеется в РК-клоне по имени "Спектр", а в оригинальном РК86 оно почему-то выводится не на каждом знакоместе. Кстати в этой же теме того же форума нашёл любопытную фразу о том, что опубликованная в ж.Радио муз.система для РК86 не авторская разработка, а портирована с Sol20.

Кстати, пока проверял все Интернет-статьи с упоминанием подчёркивания, узнал, что оказывается промышленно выпускался такой крутой РК-производный компьютер называемый "Партнёр-01", в котором есть не только инверсия знакомест и альтернативный фонт, но даже и подчёркивание. Полезно достать его схему и уточнить как ввести в машинку на ВГ75 работу атрибута подчёркивания.

А вообще странно, что за более, чем 30 лет никому из любителей РК86 не пришло в голову использовать подчёркивание в программах. Оно то, по-видимому, как раз не требует аппаратных доработок (или, возможно, совсем минимальные). Ещё более глупо, что выпускатели новодельных печатных плат РК86 не озадачились заимствованием в РК86 узла поддержки атрибутов из схем более развитых промышленных РК-подобных (тут доработки очень минимальны и даже в основном без расхода доп.микросхем). Кстати, атрибут яркости тоже можно поиметь за счёт расхода всего лишь в обратный германиевый транзистор (типа МП36...МП38) и резистор.

PS. Кстати инверсию знакомест атрибутом RVV в РК86 можно получить даже без дополнительного расхода микросхем, т.е добавки в схему РК одного вентиля из дополнительно припаянной где-то вторым этажом микросхемы 155 ЛП5. Достаточно прошить во вторую половину знакогенератора (неважно на РФ2 или 27256) тот же фонт, но инвертированный и соединить куском проволоки выход RVV ВГ75 с старшим адресом ПЗУ знакогенератора. Хотя атрибутная инверсия знакомест программисту намного менее удобна, чем инверсия задаваемая самим кодом символа (как это сделано в моём альтернативном фонте).

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

Если подумать о том как освободить вентиль ЛП5 на плате РК86, чтобы поиметь инверсию знакомест атрибутом RVV без припайки второэтажной 155 ЛП5, то можно прийти к выводу, что и сами разработчики РК86 могли бы поиметь инверсию знакомест не увеличивая число микросхем. Т.к если посмотреть на схему РК86, то видно, что вентиль из ЛП5 D5.4 выполняет функцию повторителя, работая в качестве буфера входов /WE ОЗУ. Буфер нужен, это правильно, т.к без этого выход /WR процессора буфера был бы перегружен 16-ю входами ОЗУ. Но вентиль для повторителя можно было выиграть заменив вентиль ЛИ1 D4.3 на два диода и резистор по варианту "диодное И".

И даже, если разработчикам РК так уж непременно хотелось истратить именно этот ЛП5 на буфер-повторитель, то можно было ввести инверсию ещё одним способом не тратя доп.деталей. Что кстати, можно сделать и сейчас. Достаточно прошить во вторую половину знакогенератора (неважно на РФ2 или 27256) тот же фонт, но инвертированный и соединить куском проволоки выход RVV ВГ75 с старшим адресом ПЗУ знакогенератора. Хотя атрибутная инверсия знакомест программисту намного менее удобна, чем инверсия задаваемая самим кодом символа (как это сделано в моём альтернативном фонте).

Всем добра, мое первое сообщение. Начитан очень много про ваши с Виктором переписки а также длинные монологи. Не скрою, приведено много полезной информации, я собираюсь ее даже использовать в будущих конструкциях. По делу. А почему бы не применить видеопроцессор от денди в качестве доп опции для РК? 3 дополнительных корпуса и один выбор кристала от рк и имеем полноценный PAL/NTSC видеовыход с очень простым программированием и совместимостью с кучей игр от денди. Из минусов - да, труднодоставаемый кварц на 26 мег с бородой, относительно небольшое разрешение экрана в виде 256х240 точек что в тексте 32х30 символов. Из плюсов, минимум корпусов микросхем, отличная документация и ПО, поддержка спрайтов и тд.
Я даже решился это дело все скрестить, у меня имеется рк86 на статике и уже вытравленная платка. Думаю конечно проверить все на связке микроконтроллер + видеопроцессор, а затем крепить к рк.
От форума прошу помощи в схемотехнике дешифратора адреса. Да, видел тему рк, 2 или 3 года переписки, очень неплохие наброски дешифратора и доп опций для рк. Меня бы носом ткнуть в рабочие моменты....
Вобщем принимайте в общество, думаю толк от меня будет.

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

Если можете это сделать и Вам это интересно, то почему нет? Сделайте внешний граф.адаптер для РК86 на более современной видео БИС, чем ВГ75. Чем смогу, я Вам охотно помогу, хотя себя аппаратчиком не считаю и мне даже низкоинтегральное железо не интересно (программировать хоть на ретро ассемблере, хоть на ретро ЯВУ - намного интереснее).

А вообще именно эту идею уже выдвигали вот здесь. Встраивать в новодел РК86 видеопроцессор - нелампово, т.к не было в 1986 году в СССР видеопроцессоров от Денди. При этом получается другое синтетическое, а не ретро хобби.

Почему обязательно видеопроцессор Денди? На настоящем видеопроцессоре NEC 7220 (если МНИП отеч.аналог - 1809ВГ6) будет немного сложнее, т.к в нём ОЗУ 16-ти разрядное (всего будет десяток корпусов), зато по параметрам лучше (экран м.быть любым до 2048*1024). Он использует своё ОЗУ, потому стыковать с МП-ядром легко. У меня уже 20 лет лежит NEC 7220, есть полный комплект документации (на бумаге) и схема есть и даже коды текстового драйвера (экран 640*200 на двух 6264), но всё лень сделать.

Или, например, видеоконтроллеры MC6847 или EF9345P, что разработаны для игровых консолей. Или видеоконтроллеры от MSX 9918 или 9938. Кстати, именно 6847 стал самым массовым в бытовых компьютерах и игровых консолях с конца 70-тых (он стоит в т.ч. в самых популярных машинах начала 80-тых, таких как Dragon 32, Matra Alice, Acorn Atom и др), затем его сменил 9345 (например он применён в Alice 32/90). 9345 даёт и аппаратный текст 40/80*25 и графику до 320*250*моно, а для игр даёт самый оптимальный для игровых консолей цветной видео режим 160*125.

Лампово подключить к РК86 простой граф.адаптер на всего 30-ти низкоинтегральных корпусах (это при экранном ОЗУ на 565 РУ6, на статике будет на ~8 корпусов меньше). И, как упомянуто в вышеприведённой ссылке, я так и сделал и потому узнал, что скорость РК86 для работы с графикой (по крайней мере при экране в 12 кб) недостаточна.

Но зачем видеопроцессору ущербное микропроцессорное ядро из платы РК86? Оно дико тормозное, имеет нелепую архитектуру, имеет перегруженную шину (т.е труднорасширяемо) и в нём не лучший микропроцессор (не Z80), который не турбируется. В качестве МП-ядра для применения с видеопроцессором гораздо выгоднее и удобнее обычное простейшее ядро на Z80 на 5 микросхемах (Z80, его задающий генератор, ОЗУ и ПЗУ), которое даже на широко распространённом Z80B разгоняется до 8...9 МГЦ.

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

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

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

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

ведущий_специалист пишет:и совместимостью с кучей игр от Денди

Это вряд-ли, т.к в Денди процессор не КР580. И даже, если бы был процессор тот-же, то пришлось бы повторять всю архитектуру и нюансы схемотехники Денди.

Кстати, Вы похоже разбираетесь в железе. Было бы выгоднее, если бы Вы поставили сначала в РК86 процессор 6502 (процессор 6802 тогда можно было бы поставить по той же схеме, т.к у него интерфейс тот же). Тогда в стране появился бы другой кроме Агата компьютер на процессоре 6502. После чего возможно и любители других отечественных самоделок и промышленных бытовушек бросились бы ставить в них процессор 6502 (читал, что 6502 якобы хороший и удобен как раз для игр, т.к быстрее делает пересылки). Вроде бы эмулятор EMU от b2m эмулирует ЭВМ Агат, тогда в нём есть эмуляция процессора 6502. Возможно можно без хлопот поиметь эмулятор РК86 с процессором 6502, лишь заменив строчку про процессор в его файле конфигурации.

ведущий_специалист пишет:Из минусов... труднодоставаемый кварц на 26 мег

Кварц не проблема.

ведущий_специалист пишет:Из минусов... относительно небольшое разрешение экрана в виде 256х240 точек

Разрешение экрана 256*240 даже излишне большое для игр (на ZX-Spectrum многие динамичные игры используют лишь часть его крошечного экрана ради ускорения, а на тормозном РК86 такой большой экран будет тормозить).

ведущий_специалист пишет:Из минусов... в тексте 32х30 символов.

Если есть прямой доступ к граф.экрану, то при ширине в 256 пикселей можно выводить 42 символа в строке вполне читабельным шрифтом 6*8, но если речь о РК86, то у него ведь есть и свои возможности выводить 64 символа в строке. Впрочем и 42 символов в строке достаточно, чтобы из нортоноподобной оболочки запустить игру. Текстообработка на РК86 для печати на принтере сейчас никому не нужна (да и в 1987 году была не нужна, т.к принтеры в СССР/СНГ были недоступны частным лицам до 1992 г).

ведущий_специалист пишет:Из плюсов, минимум корпусов микросхем, отличная документация и ПО, поддержка спрайтов и т.д.

Простота схемы и документация это конечно плюс. Сомневаюсь, что программирование аппаратных спрайтов простое, - работа с экраном в Специалисте всё-равно на порядок проще.

ведущий_специалист пишет:Я даже решился это дело всё скрестить, - у меня имеется РК86 на статике и уже вытравленная платка. Думаю конечно проверить все на связке микроконтроллер + видеопроцессор, а затем крепить к РК.

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

ведущий_специалист пишет:От форума прошу помощи в схемотехнике дешифратора адреса

Дешифратор в МП-системах это самое простое. Это первое, что начинающие изучают в начале освоения МП-систем, читая Библию любителей 8-ми разрядок "Д.Коффрон. Технические средства МП-систем. Изд-во «Мир», 1983". Это была моя настольная книга в 1987 году. Эту полезную книжку можно скачать здесь, - её должен иметь на столе каждый, кто интересуется ретро МП-схемами.

А двухрежимный дешифратор памяти для машины с двумя конфигурациями (позволяющий иметь сразу две архитектуры - базовую и расширенную) намного сложнее - посмотрите насколько громоздкий РК-Макси из журнала "Радио" (если МНИП это журнал из 1994 года). Ранее я придумал как расширить ОЗУ до 56К не за счёт двухрежимного дешифратора, а за счёт аппаратного блокирования чип-селектов двух портов ППА (занимающих два участка памяти по 8 Кб каждый) и открытия в освободившемся окне памяти 8000...BFFF ОЗУ физически имеющегося в 565 РУ5, но в базовой схеме закрытого портами 8000 и A000. Это позволяет иметь больше ОЗУ при существенно менее простой доработке базовой схемы РК.

Это возможно, потому, что порт A000 вообще не нужен программам (т.к это запасной ППА), а порт 8000 это клавиатура, доступ к которой нужен лишь в моменты её опроса. Потому эти два порта и можно отключать надолго, включая лишь когда идёт опрос клавиш. К сожалению авторы РК не оставили ни одного чип-селекта под расширения, потому, чтобы ввести доп.системный регистр конфигурации и понадобилось вводить ещё один дешифратор (вторую половинку ИД14). Сократить схему переключателя 32/56 кб можно было бы с помощью 556РТ4.

Если видеопроцессор требует участка памяти в процессорном ядре, то как раз удобно занять участок A000...BFFF, где стоит запасной ППА D14 (его просто извлекаем из панельки). Если же видеопроцессор под экранное ОЗУ использует свое ОЗУ вне шины процессора, то и таких проблем нет.

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

Сначала опишите, что надо, тогда хоть будет ясно о чём речь и можно начать думать.

ведущий_специалист пишет:В общем, принимайте в общество

Добро пожаловать! Тут общество небольшое, т.к любителей отечественных 8-ми разрядок осталось мало и сейчас все они обитают не в этом форуме, а вот здесь. Остальные подобные тематические форумы просто опоздали и потому малопопулярны. Зато на этом форуме пока нет троллей.

Ну очевидно он знает про zx-pk и пришёл сюда из-за этого:

Начитан очень много про ваши с Виктором переписки а также длинные монологи

Тут скорее вопрос откуда он "начитан много про ваши переписки" и как узнал про это форум двух фанатов

Дык форум вроде открыт, информация на нем легко читаема и интересна. Так как я долгое время (с детства) знаю рк86 и с юных лет дорабатывал его с братом как программно так и аппаратно, то немного понимаю его проблему и нюансы. zx pk тоже долгое время почитывал. И вот например, то , что придумали в 12 году по теме загружаемого знакогенератора, я испытывал в деле еще в 96 году (брат мой был в этом плане гениален и собрал на мультиплексорах и ру 10 схему еще в то время), а я тренировался, рисовал графику на символах в бейсике )))). Времена прошли, все позабылось но вот рк у меня в этом году появился... Отсюда и мысли.... И очень обидно, что на текущий 20 год народ до сих пор не сделал такие очевидные доработки этого компьютера. Считаю что вариант с SRAM памятью пока самый удачный. Так же как и прорыв Алексея с SD загрузчиком и СИ компилятором к вм80.

ведущий_специалист пишет:... то , что придумали в 12 году по теме загружаемого знакогенератора, я испытывал в деле ещё в 96 году (брат мой был в этом плане гениален и собрал на мультиплексорах и РУ10 схему ещё в то время)

Читал где-то, что был опубликован вариант того же, но для Микроши в ж.Радиолюбитель в середине 90-тых. Застолбите свой приоритет, опубликуйте на ZX-PK.ru свою схему и программы для неё (если сохранились).

ведущий_специалист пишет:очень обидно, что на текущий 20 год народ до сих пор не сделал такие очевидные доработки этого компьютера.

Если Вы не сделаете и не сделают.

Это вероятно из-за специфичного контингента владельцев РК86 и отношения людей к нему. Из-за его ущербности по видео возможностям к РК86 все относятся неуважительно (если не сказать презрительно). Как и 35 лет назад, так и сейчас его рассматривают лишь как пробу сил, а затем переходят на ретро-компьютер с графикой. А основной фактор в том, что и для всех 8-ми разрядок число практикующих программистов любителей стало малым, а для отчественных машин так вообще мизерным. А для РК86 уже вообще ноль программистов пишут игры (а больше ничего для РК и не напишешь). Писать игры для РК не привлекает, потому-что, как ни напрягайся, а всё-равно визуально получится погано, хуже даже, чем для Атари 2600 из 1977 года с разрешением экрана 160*192.

Как ситация с этим стала ясна, то уже никто и не пытается "пробивать стену", т.е пытаться разработать и произвести печ.платы новодельного РК с доработками. Все обсуждения и попытки организовать выпуск таких плат в прошедшие годы кончались ничем. Молодёжь предпочитает для тренировки и практики в сборке ретро-железа собрать именно оригинал РК, а затем положить его под стекло или выбросить.

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

ведущий_специалист пишет:Считаю что вариант с SRAM памятью пока самый удачный.

565 РУ2 из 1978 года тоже статическая (т.к всё, что не динамическое, то статическое). Сейчас почему-то пишут статическая память, а имеют ввиду статическая КМОП память. И можно сделать намного удачнее, т.е в многие разы проще, если встраивать ОЗУ фонта не в шину, а грузить через ППА D14 как упомянуто чуть выше в этой же теме.

ведущий_специалист пишет:СИ компилятором к ВМ80

Вам удалось получить его в виде работающей программы (а не в виде бесполезного неспециалисту исходника на Github)? Удалось разобраться в программировании на нём (т.к там не стандарт Си)?

Да, удалось. Вот результат вечера работы набросков на си, скомпилированных этим компилятором. https://vk.com/video-131665221_456239079

ведущий_специалист пишет:удалось [поиметь компилятор vinxru и разобраться в его использовании]

Не поделитесь ли с народом кросс-компилятором Си под КР580 от vinxru?

Спойлер:

ведущий_специалист пишет:Вот результат вечера работы

Здорово. Похоже на первые тестирования движка при написании игры Manic-Miner для РК86. Если для графических машин код из под ЯВУ тормозит и чтобы было приемлемо надо заботиться о скорости (делать критичные процедуры на ассемблере), то для текстовой машины проблема быстродействия кода из под ЯВУ существенно менее актуальна (хотя проблема чрезмерно быстрого роста объёма кода в ходе усложнения программы всё-равно остаётся). Интересно vinxru предусмотрел в своём кросс-компиляторе вставки на ассемблере? Без этого ценность компилятора падает, делая его менее пригодным для разработки игр.

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

Зачем Вам возня с железом, если Вы можете программировать для РК на Си? Начните с Manic-Miner-а для базового РК с несколькими программно переключаемыми фонтами. В минимуме можно допрошить РФ2 с базовым знакогенератором и поиметь альтернативный фонт, куда можно прошить тайлы нужных в игре спрайтов. А серьёзному пользователю РК желательно заменить для фонта 24-х нОгую панельку на 28-ми нОгую и поиметь аж 8 или даже 16 фонтов на 27256 или 27512.

Малая трудоёмкость работы по расширению числа фонтов в сочетании с кучей новых РК игр с продвинутой графикой (если Вы их быстро сделаете) может показать пользователям, что доработка РК до загрузки фонта кардинально меняет его видео возможности. Тогда владельцы РК сами захотят сделать доработку до загрузки фонта (это можно сделать или даже совсем без деталей или затратив кроме 537 РУ10 всего две 155 ЛП10 или три 555 КП11).

Есть ли у Вас граф.редактор с выводом результата в файл не в формате BMP (или в других PC-шных форматах), а выдающие в выходной файл монохромную графику в простом формате (который пригоден для использования в 8-ми разрядке), когда байты впритык (неважно формат с компоновкой по горизонтали или вертикали)? Например, разумен формат в котором должны быть спрайты предназначенные для вывода на экран подпрограммой из ROM-BIOS ИРИШИ (там простой формат упакованный по горизонтали, т.е горизонтальными линиями, что соответствует формату экрана ИРИШИ и CGA).

Если такого редактора нет, то может выручить конвертор графики из монохромного BMP в простой формат (например в формат линейного по вертикали экрана как в Специалисте/Орионе/Векторе).

Да, попытки создания супер марио закончились тем, что я понял :
1 Не хватит скорости для всего остального.
2 Нужен аппаратный скролл.
3 По сути скорости хватает на передвижение главного персонала и мельтешения пары спрайтов.
4 Очень нужен системный таймер, он позволит вывести игру на другой уровень в плане динамичности и играбельности.
5 Нужна микросхема звука.
6 Нужно больше ОЗУ
7 Крайне желательно загружать шрифты в замен основного ЗГ.
Собственно эти 7 пунктов сподвигли меня на создание свежей, учитывающей данные недостатки платформы. Апогей БК01ц в принципе решил бы эту проблему под корень, если его доработать загружаемым ЗГ и поставить более мощный процессор.
Насмотревшись постов Vinxru, я понял, что на рк подобных аппаратный скролл это не проблема и он делал эти вещи достаточно просто. Но увы, связаться с этим товарищем крайне проблематично. На этом форуме он вроде появлялся в 19 году.
По поводу компилятора СИ я готов выложить рабочую папку с рабочими примерами и описанием. Но думаю, может ли мне потом предъявить автор, по сути это его не законченное творение и кто его знает какие планы у него на авторские права.
Графику рисую по старинке в тетрадке в клеточку. Но использовал паинт с сеткой. Очень удобно, загружаешь картинку спрайта, удаляешь цвет, анализируешь то, что осталось от картинки и перерисовываешь все это в коды рк. Все просто ))). На PC я не программист, так бы написал пару удобных скриптов переводящих графику в псевдографику РК. Я очень силен в СИ под стм32, стм8.
И да, компилятор для вм80 позволяет делать вставки ассемблера. Как я понял, это больше набор макросов, так как до полноценного си там далековато, но что то можно уже изобрести )))).

ведущий_специалист пишет:Не хватит скорости

Эффективная скорость РК в режиме без вертикальных разрывов, т.е при задании общего числа строк 39 (из коих 30 видимы, 1 - КСИ, 8 - бордюр): ~1.05 МГЦ.

Спойлер:

ведущий_специалист пишет:Нужен аппаратный скролл

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

ведущий_специалист пишет:Очень нужен системный таймер

На РК аппаратно проще всего завести меандр 5 ГЦ на вход магнитофона, что позволит программно отмерять временные отрезки в 0.1 секунды. Введение прерываний аппаратно намного сложнее. Ещё можно применить ВИ53, т.к в нём есть возможность "читать на лету" и узнавать текущее время.

ведущий_специалист пишет:Нужно больше ОЗУ

Видимо потому что ЯВУ даёт как минимум в 4 раза более объёмный код, чем ассемблер. И потому, что если графика спрайтов и пейзажа располагается в теле программы, то она отнимает много места (в ZX-играх графика обычно занимает даже больше места, чем исполняемый код). Но если графика не в теле программы, а уже заранее прошита в виде тайлов в знакогенератор в большом ПЗУ 27256, то игра не содержит самой графики, лишь закодированное представление лабиринтов.

ведущий_специалист пишет:Апогей БК01ц в принципе решил бы эту проблему под корень, если его доработать загружаемым ЗГ и поставить более мощный процессор.

РК86 доработанный за счет 555 ЛЛ1, ТМ2, ИД7 даёт тот же объём сплошного ОЗУ 56К. А если важен цвет, то схема цвета из ж.Радиолюбитель 04.92 проста (несколько доп.корпусов - каждый может при желании спаять МГТФ-ом). Но к атрибутному цвету ВГ75 я отношусь плохо, т.к его сложнее программировать, чем любой другой.

ведущий_специалист пишет:Насмотревшись постов Vinxru, я понял, что на РК подобных аппаратный скролл это не проблема

ВГ75 позволяет мгновенно переставлять начало экранного буфера, что почти то же самое, что наличие двух аппаратно переключаемых экранов. Нет смысла у vinxru что-то спрашивать, т.к для 8-ми разрядок не очень трудоёмко дизассемблировать и посмотреть.

ведущий_специалист пишет:По поводу компилятора СИ я готов выложить рабочую папку с рабочими примерами и описанием. Но думаю, может ли мне потом предъявить автор

Честно говоря, я сомневаюсь, что самодельный кросс-компилятор сможет даже сравниться с фирменными, а люди пытаются использовать кросс-компилятор даже, если он слабый, лишь из-за того, что под современные Windows нет эмуляторов CP/M (отчего компиляторы ЯВУ из CP/M использовать удобно лишь в Win XP). Какой-то компилятор Си от vinxru в виде файла C8080.EXE у всех уже есть отсюда. Там же есть и другая версия от vinxru, но она лишь в виде исходника. Т.о для первой версии не хватает как раз описания и простейших примеров, а для второй отсутствует и сама программа компилятора.

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

В принципе, т.к есть много фирменных Си-компиляторов для КР580 (а для Z80 их ещё больше), нет смысла тратить время на что-то недоделанное и совсем без документации. Подумать о том, чтобы начать разбираться можно было бы, если имелся хотя бы список реализованных операторов, стандартных функций, информация про нюансы и примеры программ. Интересно взять один и тот же исходный код дающий не менее 10 кб кода, странслировать в BDS, Aztec и компиляторе vinxru и сравнить. Хотя сравнить что-то реальное вряд-ли получится, т.к читал, что компилятор от vinxru упрощённый и недоделанный. Я программировал на Си в CP/M. Но сейчас по эстетическим соображениям предпочитаю Паскаль.

ведущий_специалист пишет:Графику рисую по старинке в тетрадке в клеточку. Но использовал Пайнт с сеткой. Очень удобно, загружаешь картинку спрайта, удаляешь цвет и... [вручную переписываешь]... в коды

Не далеко шагнула технология разработки графики за 30 лет. Я подумывал о том, чтобы написать редактор спрайтов на Паскале (30 лет назад я уже делал такое на ассемблере для Специалиста). Написал пока лишь редактор фонта 8*8, собираясь переделать его на 16*16 и добавить визуализатор (это вывод в одно место подряд с интервалом в 0.2 секунды до 16 разных спрайтов, что позволяет оценить эффект мультипликации). Жаль, что на реальной 8-ми разрядке и соответственно в их эмуляторах нет мыши. Потому использование PC-шного редактора в котором есть мышь для создания спрайтов удобнее.

У меня Paint в Windows XP, а там нет сетки. Но Paint действительно может упростить ручную конверсию графики от ZX-Spectrum. Думаю, что можно научиться заимствовать спрайты из ZX-игр, используя эмуляторы позволяющие скриншоты (а далее спрайт вырезаем из скриншота Paint-ом и вручную оцифровываем). Обойтись без ручной оцифровки позволила бы программа конверсии из моно-BMP в простой экранный формат. Я бы написал, но не хватает ума разобраться в форматах BMP или PSX. Наверняка у синклеристов есть средства для конверсии графики в формате BMP в формат ZX-экрана.

У меня Paint в Windows XP, а там нет сетки.

Есть.

Viktor2312 пишет:

У меня Paint в Windows XP, а там нет сетки.

Есть.

Нашёл. Возможность включить сетку появляется только, если включить масштаб увеличения в 400 % и более, а я всегда рисую в нормальном масштабе, потому и не знал.

Попробовал брать графику из ZX-игр. Попробовал и скидывать в скриншот и брать прямо с экрана (это возможно в эмуляторах для Windows, в грамотных эмуляторах для MSDOS невозможно, т.к подменён INT 9). С экрана копировать быстрее, т.к получаешь не весь экран, а сразу нужный фрагмент. Проблема в сложности отловить все фазы (для этого удобен эмулятор, в котором скорость эмуляции можно замедлить).

Попробовал и мне стало ясно, что оказывается даже не имея редактора спрайтов и конвертора спрайтов в тайлы, лишь используя PAINT и последующую ручную конверсию в байты, (хотя и очень неудобно) можно уже рисовать графику тайлов для прошивки в фонт РК86 предназначенный для игры Manic-Miner, а затем пытаться написать движок для РК-игр на Паскале или Си. Кстати, на РК можно получить графику намного лучшую, чем в ZX, т.к ширина экрана РК в пикселях 384*256, а если фонт 8*8, то аж 512*256.

Т.к экран PC в игре Принц Персии для CGA - 320*200, то графику из этой игры можно брать без переделки (можно брать и из игры для Apple-II, там экран 280*192). Но естественно плавность движений можно было бы получить, если бы было много символов в фонте (а есть всего 128), так что даже движение с кратностью в ползнакоместа затруднительно (т.к тогда число тайлов возрастает в 4 раза). Так, что для начала сделать хотя бы движение рывками по целому знакоместу, но уже не буковок, а нарисованных спрайтов.

Кстати, возвращаясь к теме этой темы (о улучшении видео-возможностей РК86). Наилучший цвет в РК86 получился бы, если бы для него использовать параллельно включённую ВГ75 (как сделал freddy и как в МЦПГ Партнёра) - тогда будет аж 7 битов для цвета на знакоместо (что столько же битов на цвет, как и в ZX-Spectrum). Вот с такой доработкой игры РК могли бы выглядеть внешне очень похоже на игры ZX, но в динамике хуже - спрайты двигались бы более заметными рывками.

Я тут прикинул член к носу и вроде получается, что всего 128 кодов - это маловато для приличной мультипликации в графической тайловой игре для РК86 с доп.фонтами (впрочем в Денди вроде тоже не особо много, всего 256 кодов на тайлы). Кто-нибудь возможно сразу нагло заявит, что используя 4 атрибута ВГ75 можно поиметь на РК-экране одновременно аж 16*128= 2048 разных символов. Но ведь атрибуты как бы официально истрачены на цвет (и это даже программно поддержано несколькими цветными играми). А мне вообще не нравится использовать атрибуты, кроме как на выбор фонта сразу на весь экран, т.к атрибуты программировать сложно. Конечно имея 2048 кодов за счёт атрибутов можно сделать графическую тайловую РК-игру неотличимой визуально от монохромной игры полноценно графической машины, но сложность будет в 5 раз выше.

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

Чтобы игра хотя бы визуально выглядела похожей на графическую нужна примитивная мультипликация. Для этого надо иметь несколько фаз спрайта и выводить их подряд с интервалом ~0.1 секунды. Это позволяет отобразить на экране, как фигурка при ходьбе шагает и махает ручками, а например, взрыв эффектно "расцветает". Если двигать неизменный спрайт, то получится не намного лучше, чем в оригинальных играх РК86, где по лабиринтам построенным из букв и цифр бегают другие буковки и циферки.

Т.к, кодов в фонте всего 128, а даже в игре имеющей всего один пейзаж (лабиринт) спрайтов должно быть как минимум 5-6 и ещё надо оставить, как минимум 20-30 кодов под тайлы для рисования пейзажа, для тайловой графической РК-игры не получится выделить для каждого спрайта много кодов фонта. Некоторые маленькие и неизменные спрайты, например пуля или граната, умещаются в один тайл, т.е занимают на экране всего одно знакоместо. Гранате хватит и одного тайла (если только не надо, чтобы она летела более плавно). Зато пуле желательно лететь с более мелкими рывками (в ползнакоместа) , потому для неё лучше отдать 4 тайла (слева-вверху,  справа-вверху,  слева-внизу, справа внизу). А вот спрайт человечка лучше составить из 4-х тайлов, т.к в квадратике 8*8 (а уж тем при 6*8 при убогом базовом фонте 6*8, можно нарисовать очень уж убогий чересчур стилизовааный спрайт, что не намного лучше бегающих по экрану буковок.

Итак, одна фаза фигурки человека будет занимать 4 кода в игровом фонте. Если у спрайта человечка будет 8 фаз, то это займёт 32 кода в фонте. Если 30 кодов отдать на пейзаж (или например лабиринт), то оставшихся 128-30= 98 кодов хватит всего на три более-менее приличных спрайта. Если ~3 основных спрайта ограничить всего лишь 5-ю фазами (расход 20 кодов на спрайт), то останется 98-3*20= 38 кодов, в которые придётся уместить все остальные второстепенные спрайты. Например жориков в пэкмане достаточно изображать всего двумя фазами с открытой пастью и закрытой пастью (отчего тратится всего 4*2= 8 кодов).

128 кодов полностью хватает лишь на статические игры (например шахматы, головоломки типа игры 15, пазлы или игральные карты). Наример, в шахматах всего 6 фигур, так что на их красивые изображения уйдет всего 4*6= 24 кода из фонта для шахмат.

Тут подумав о выводе текстов в графических играх вспомнил, как эту проблему решил Стив Возняк при разработке Apple-II. Там есть Low Resolution video mode, который предназначен для игр. Так вот, чтобы можно было выводить в играх тексты, Стив Возняк ввёл в граф.режиме возможность выводить тексты в нескольких нижних строках экрана, благодаря чему в играх можно выводить счёт игры и другую информацию

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

Вышеизложенное лишь подвод к основной мысли поста. Основная цель этого поста в другом. В том, что даже имея удобный граф.редактор (удобно использовать граф.редактор Е.Якубовского для Специалиста, там есть лупа на фрагмент экрана и он естественно редактирует в формате экрана Специалиста, потому отпадает проблема конверсии из PC-шных форматов) для разработки правильно мультиплицируемых спрайтов нужен ещё и визуализатор, который работает точно как движок спрайтов из РК-игры. Визуализатор циклически выводит в нужном порядке подготовленные спрайты с интервалом между спрайтами заданными в движке конкретной игры (обычно в 0.1...0.3 секунды) и требуемым горизонтальным (или вертикальным) сдвигом. Что создаёт эффект того, что, например, фигурка человечка шагает по дороге перебирая ножками и отмахивая шаги ручками. Это и позволяет отредактировать спрайты фаз так, чтобы движение фигурок было естественным. С обычным редактором получается создать спрайты лишь с порывистым и неестественным движением.

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

Paint несмотря на наличие в нём мыши, значительно менее удобен, чем редактор спрайтов даже без мыши. Я в этом убедился. Мышь в Painte не очень помогает, т.к там есть два режима - режим включения пикселей и режим выключения пикселей. А надо чтобы, как сделано в редакторе спрайтов и в редакторе фонтов, - чтобы нажатие на кнопку мыши работало триггерно - если пиксель зажжён, то гасит его и наоборот. В своё время я написал свой примитивный редактор спрайтов для Специалиста и с его помощью создал несколько динамических 8-ми фазных спрайтов - бегущая лошадь, бегущий человек и взрыв с огнём и дымом. В итоге убедился, что не обладаю художественными способностями к рисованию компьютерной графики. А вчера попробовал рисовать в граф.редакторе - получилось на порядок хуже. Без визуализатора или "эмулятора спрайт-движка" хоррошо не сделать.

Сейчас уже доступны компиляторы ЯВУ пригодные для разработки игр под РК86, чего не было у любителей программирования для РК86 в 1986...1991 годах (последние игры, что есть для РК имеют дату 1992, затем программисты для РК куда-то подевались и соответственно новых игр уже не появлялось). Потому программистам был доступен только ассемблер, да и то не макро, хотя для Микроши завод ЛЭМЗ выпустил дистрибутивную кассету с макро-ассемблером, который даже годился для РК86 почти без адаптации (достаточно заменить текстов редактор Микроши на тектов редактор РК), но увы, в среде владельцев РК этот макроассемблер не распространился, да и в бездисководной среде ценность макроассемблера фатально падает. В те годы поиметь дискетную DOS владельцы бытовых ЭВМ даже не мечтали.

Кстати, привинтить к РК86 электронный диск и на его базе поиметь DOS было просто. Но любители РК это сделать не смогли, т.к когда стали доступны 565 РУ7, любители РК86 первой волны (те кто собрал Микро-80 и РК в 1983-1987), среди которых как раз было много инженеров, обладающих нужными знаниями и доступом к нужным программам (и потому могущих сделать разработку ЭД и DOS для него), из-за неудовлетворительных видео возможностей уже давно покинули РК86 и перешли на графические 8-ми разрядки или на клоны PC XT.

А сейчас уже не только самый крутой макроассемблер М80 от Microsoft доступен на PC (в эмуляторе CP/M под MSDOS), но и любые ЯВУ из 70-тых и 80-тых годов. А для богатеньких буратин сейчас доступны даже IDE кросс среды и для ассемблера и для ЯВУ (встречаются бесплатные полуфабрикаты, но все реально пригодные - платные, причём для них нужен РК86 c Z80). Хотя реально сейчас из ЯВУ для любительского написания РК-игр стоит использовать лишь PLMX, Паскаль или Си, с экзотическими ЯВУ нет смысла связываться (мало доков и учебников).

Писать РК-игру на ассемблере сложнее. ЯВУ упрощает трудозатраты в разы. Мне видится, что критичные к скорости процедуры всё-равное разумно написать на ассемблере, в частности спрайт-движок. А вот всё остальное, в т.ч. и логику игры можно писать на ЯВУ до тех пор пока хватит объёма ОЗУ в РК86.

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

Понятно, что текстовые РК-игры сейчас в любительских целях разрабатывать неинтересно. А ввести в РК86 хотя бы два фонта (а лучше 32 фонта на 27256) по силу любому, т.к это труд всего на 8 секунд (припайка куска проволоки между выводом ППА D14 и адресом А10 ПЗУ РФ2 знакогенератора). Ну, а если любителю программирующему для РК86 хватает ума даже на цветные игры, то ему достаточно открыть ж.Радиолюбитель 04.92, разогреть паяльник и - флаг ему в руки.

Рисую схему РК86 со следующими доработками:
1. Символы 8 точек по горизонтали.
2. Формирование выхода VGA.
3. Схема цвета от апогея.
4. Мультиплексированная ОЗУ знакогенератора (переключаемая вместо ПЗУ) в область памяти.
Пока что решил руководствоваться готовыми схемами (зачем придумывать велосипед, если и без того существует куча готовых примеров), но словил ряд схемотехнических вопросов, решить в лоб которые если честно не хватает времени. Разобраться можно и самому, но наверняка на форуме эти вопросы решатся быстрее.
1 - схема VGA вывода рк86
2 - схема цвета от апогея
Так вот, прошу помощи, куда подключить выводы С1 D1.
Смысл прост. Хочется использовать монитор в роли отображения информации ну и соответственно использовать цвет (ну а толку повторять новоделы которых и так валом).
В принципе я даже готов повторить полностью схему видеочасти апогея, использовав 6 битный ЗГ, но хочется уйти от старинной ир13 и .... хз где брать телевизор с ржб входом, а мониторов пруд пруди. Надеюсь на понимание.

продолжая разбираться со схемой апогея, понял, что 8 нога D1 из схемы формирования цвета, это не что иное как вход тактовой частоты, идущей от гф24. Она же заходит и на 14 ногу ие5.
Правильно ли я понимаю, что в случае со схемой VGA, на 8 ногу ир1 нужно подать частоту с генератора, я так понимаю это 24 МГц? Или там нужна другая частота?

ведущий_специалист пишет:Рисую схему РК86 со следующими доработками:
1. Символы 8 точек по горизонтали.

А иначе, т.е с фонтом 6*8 и не получится, потому, что у 555 ИР10 нет выхода 6-го разряда, а есть лишь выход 8-го разряда.

ведущий_специалист пишет:3. Схема цвета от Апогея.

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

ведущий_специалист пишет:4. Мультиплексированная ОЗУ знакогенератора (переключаемая вместо ПЗУ) в область памяти.

Чем не нравится более простая и не грузящая шину схема, когда доп.ППА формирует сигналы нужные для записи в ОЗУ фонта? А именно, - с выходов доп.ППА берутся или
1. и адреса и данные для записи в фонт ОЗУ или
2. только адреса (а данные поступают с шины процессора в цикле записи).

Расход деталей - 12 выходов (PB и PCL) из ППА для выдачи 11 адресов, буфер 555 АП6 на развязку данных от шины и два буфера с Z-выходом отрубающие входы ОЗУ фонта от ВГ75 (можно две 555 АП6, ИР22 или три 555 КП11). Или 3 порта ППА, чтобы данные тоже шли из ППА и тогда буфер развязки на ШД не нужен, что экономичнее. Адресов на ОЗУ фонта 537 РУ10 (аналог 6216) всего 11. Так что из 16 выводов из двух портов ППА хватает и на адреса ОЗУ фонта и если надо, то и на формирование сигналов записи в ОЗУ фонта (PCH). Но быстрее использовать отдельный чип-селект на запись. Т.е входы (они же выходы) данных ОЗУ фонта можно как подключить к ШД процессора через буфер, так и подавать из 3-го порта ППА, что чуть медленнее, но экономичнее. А если в схеме с загрузкой из шины применять ОЗУ с раздельными входами и выходами (например 565РУ2), то и буфер развязки от шины не нужен.

При подаче данных на ОЗУ фонта прямо с ШД алгоритм загрузки простейший: выкидываем в порт PB и PCL ППА адрес в ОЗУ фонта и пишем подлежащие записи данные по адресу этого чип-селекта на запись. Это м.быть адрес F800, если он развязан от ПДП дешифратором, как делалось в схеме включения РК-КНГМД, или любой дополнительно введённый чип-селект (т.к в РК не предусмотрено запасных чип-селектов). Кстати, можно освободить один из портов доп.ППА если для загрузки фонта задействовать один порт ППА-клавиатуры (т.к одновременно с загрузкой фонта в клавиатуру не лезут).

ведущий_специалист пишет:я так понимаю это 24 МГц? Или там нужна другая частота?

Если 24 МГЦ, то получается стробирование атрибутов ВГ75 на регистре ИР1 с частотой пиксель клока. Ответить может только тот, кто это делал или понимает, как цветовой адаптер Апогея работает. По мне так в регистр ИР1 надо защёлкивать не по пиксель-клоку, а по знакомест-клоку. Тогда хотя бы это можно объяснить тем, что действие атрибутов сдвигается на соседнее знакоместо.

---

А почему не хотите расширить ПЗУ на всё окно 8 кб (E000...FFFF)? Кто не имеет 2764, тот сможет ставить и РФ2, если предусмотреть перемычку конфигуратор на адрес A12, как в ИРИШЕ. В приличном компьютере д.быть много резидентного ПЗУ.

В такое большое ПЗУ 8 Кб как раз идеально встаёт или эмулятор CP/M-овских BDOS+BIOS или реальные BDOS-BIOS CP/M (это если есть внешний привод для хранения файлов). А входы в BDOS и BIOS нужны для того, чтобы можно было без извращений использовать программы странслированные компиляторами ЯВУ для CP/M, которым для работы нужны эти входы.