Программирование для компьютера РК86

В общем-то програмирование для бытового компьютера РК86 в том, что касается микропроцессора и машинных команд не отличается от программирования других компьютеров с тем же микропроцессором. Но есть и нюансы из-за своеобразия его железа. Например БИС CRT 580 ВГ75 можно запрограммировать десятком способов, получив разные режимы и адреса экрана. Также на РК86 используется своеобразная дискетная RK-DOS (разработанная Е.Седовым), программы для которой имеют много особенностей.

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

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

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

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

Однако некоторые недостатки РК86 можно рассматривать как достоинство. Например, наличие в области выше адреса $8000 более 32 тысяч адресов, куда программы РК86 никогда не обращаются, позволяет каждому пользователю РК86 использовать их по своему усмотрению не теряя совместимости. Так нельзя поступить ни в "Орионе", ни в "Векторе", где всё адресное пространство уже занято ОЗУ.

Значительно улучшить приятность пользования РК86 позволяет фонт 8*10 вместо родного фонта 6*8. Это даёт красивый фонт при высокой скорости вывода, что не может обеспечить даже ОРИОН с его графикой и тормознутостью вывода. Фонт 8*8 делается за счёт замены кварца и счетчика ИЕ4 на ИЕ5. Но это необязательно, и реально необходимо лишь тем, кто дорожит своим зрением.

Но перед тем как обсуждать особенности в разработке программ для РК86 надо упомянуть об отладчике. При разработке программ для РК86 для программиста желательно иметь резидентный отладчик, причём не загружаемый в основное ОЗУ, а работающий из памяти выше 8000, что позволяет отлаживать программы для всех адресов.

Проще всего (т.е без апп.доработок) получить отладчик, если есть плата РК-КНГМД. Тогда вместо ПЗУ с RK-DOS в панельку на плате РК-КНГМД ставится ПЗУ с отладчиком. Это даёт в системе отладчик без всякого вторжения в основной плате РК86 (а если на плате РК-КНГМД стоит ПЗУ 8 кб, то одновременно можно пользоваться и RK-DOS). Можно иметь отладчик и в других адресах, например если используется доп.ПЗУ в области C400...FFFF.

Для останова в нужных местах программы достаточно поставить в исходнике RST и программа по достижении данной точки вылетает в отладчик. Благодаря этому отладка в реале становится такой же удобной, как и в эмуляторе.

Некоторым неприятно лишь то, что в данном отладчике (полученном из DDT) используется уже ныне малопопулярная мнемоника КР580, тогда как эмулятор EMU80 позволяет выбрать мнемонику. В будущем планирую сделать отладчик с использованием мнемоники Z80 (мини дизассемблер Z80 уже есть, осталось написать мини ассемблер). Такой отладчик уже не уместится в 4 кб и его придется размещать в доп.ПЗУ C400...EFFF.

Считается, что КР580 ввиду отсутствия у него JR-команд не позволяет писать позиционно независимые программы. Если программа КР580 должна работать в другой области (не в той для которой она странслирована), то если программа не имеет обращений в область своей загрузки (т.е нет данных в области кода), то перемещение программы тривиально. Находим коды команд с абсолютной адресацией и корректируем адреса на величину оффсета. Я встречал такие программы.

Но в большинстве случаев такое невозможно, т.к есть данные в самой перемещаемой области. Тогда для перемещения составляется таблица коррекции и программа перемещения кода ей пользуется для настройки программы на конкретные адреса. Так делают отладчики CP/M ZSID3, DDT, ZBUG и другие программы работающие под вершиной BDOS.

Однако оказалось, что есть метод писать адресно-независимые программы для КР580 и без всяких автонастроек на адреса загрузки. Этот метод ещё в начале 90-тых изобрёл Е.Седов.

Поясняю его метод. Достаточно в ПЗУ (или в ОЗУ по фиксированному адресу) разместить крошечную подпрограмму в 2 команды, которая возвращает в HL адрес возврата. Узнав таким образом адрес, куда сейчас загружен код программы, вычисляется адрес перехода. Можно использовать самомодифицируемый код, но это сложнее, потому Е.Седов в качестве команд переходов использует условные RET-ы.

Такие программы неприятно дизассемблировать, их приходится анализировать вручную считая адреса, что очень утомляет, но зато код работает в любых адресах.

Вот как по методу Е.Седова делается одна позиционно независимая команда JP Z,TARGET:

Е.Седов в 1992 году пишет:
        LD      BC,TARGET-M1
        CALL    GETADR
M1:
        ADD     HL,BC
        PUSH    HL      ; в стеке адрес TARGET
        RET     Z
        POP     HL
        . . . . .
TARGET:
        . . . . .
GETADR: POP     HL      ; п/п-мма по фиксированному адресу
        JP      (HL)

Если в данном фрагменте нужно сохранять содержимое регистров, то дополнительно понадобятся два PUSH-POP-а для HL и BC. Учтите, что команда ADD HL,RR портит флаг CY (т.е нужно сохранять AF, если переход по флагу CY). Указанный метод позволяет позиционно независимо реализовать все переходы. Т.е - безусловный JMP и условные переходы по флагам Zero, Sign, Carry и Parity.

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

Так происходит из-за того, что из-за ложной экономии фонт сдуру сделали в 1 кб (в то время как с помощью одного лишнего проводника) надо было сделать фонт в 2 кб, - достаточно было завести LC3 на A10 ПЗУ знакогенератора.

Ложная экономия потому, что 573 РФ1 и РФ2 стоили одинаково, к  тому же РФ1 сразу дохнет, если вовремя не подать -5 или +12 вольт. А РФ2 всё-равно нужен под ROM-BIOS. Так зачем же было увеличивать номенклатуру комплектующих - применять и РФ1 и РФ2. И терять при этом возможность чертить сплошные вертикальные линии, в частности рамки. Заметим, что в промышленных клонах РК для фонта всегда применяли РФ2, т.к 573 РФ1 в 80-тых была уже редкой экзотикой.

Потому матрично-графические символы для псевдографики рассчитаны на режим с высотой знакоместа в 8 линий. В базовом режиме ВГ75 выдаёт 30 отображаемых строк плюс строка на обратный ход (25 строк видимы, остальные вертикальный программно формируемый бордюр). В итоге общее число строк в кадре 31. Число отображаемых линий 31*10=310, что довольно близко к TV-стандарту, где используется 312.5 линий развёртки в кадре.

Для того, чтобы при высоте знакоместа в 8 линий, был соблюдён телевизионный стандарт, надо выводить в кадре 312.5 : 8 = 39 строк. За вычетом одной строки на обратный ход, ВГ75 должен программироваться на 38 строк. Для чего второй параметр в команде RESET для ВГ75 должен быть 37 ($25). Если курсор не нужен, то третий параметр д.быть $97, а если нужен, то $77.

В таком режиме всего в кадре 39 строк. Отображаются 38 строк по 8 линий в каждой. Но видимыми являются только 30, в лучшем случае (на хорошем телевизоре) 31 строка, что даёт разрешение экрана в псевдографике в 128*60 (или 128*62). Такой режим с отображением 38-ми строк используют все оригинальные графические игры РК86. Но в новодельные времена кое-кто делал игры  с режимом в 36 строк, что приводит к частоте кадров в 60 Герц. Для старых советстких телевизоров это недопустимо, но вряд-ли кто-то их ещё использует.

Замечу, что такой графический режим настолько стандартный, что его стоит включить в виде стандартной подпрограммы в ПЗУ РК86. Естественно сохранив п/п-мму F82D. Путём удаления ненужного и оптимизации, я освободил в ПЗУ РК86 285 байт, так что место есть. На такое расширение уйдёт всего десяток байт. Разумно ввести подпрограмму, которая получает в регистрах DE второй и третий параметры команды RESET ВГ75, а в регистрах BC - адрес экрана. Тогда такая подпрограмма будет пригодна для программирования ВГ75 для разных режимов.

Ввиду того, что 38 строк занимают намного больше места, чем 30 строк, то стандартной области отведённой для экрана 76D0...7FFF уже не хватает. Из этого есть 2 выхода. Во-первых, экран можно перенести ниже рабочих ячеек и стека, например на 6000. При этом рабочие ячейки ПЗУ уцелеют и можно будет по-прежнему пользоваться стандартными подпрограммами ПЗУ. Но при этом резко сокращается сплошная область свободного ОЗУ, а старая экранная область 76D0...7FFF пропадает впустую.

Потому гораздо выгоднее, экран сдвинуть вниз, впритык к вершине ОЗУ (8000), что обеспечит максимально большую сплошную область ОЗУ, но экраном будут затёрты все рабочие ячейки ПЗУ и делать некоторые вызовы ПЗУ F800 будет невозможно. Так выводить тексты по F809, F818, F815 и вводить с клавиатуры по F803 будет невозможно. Это не проблема, т.к с экраном можно работать напрямую, записывая коды символов в экранное ОЗУ, а для игр это даже удобнее. По счастью подпрограмма для "чтения на лету" F81B не использует служебные ячейки, потому переписывать опрос клавиатуры не потребуется.

Т.к при выводе символа выводятся сразу 4 пикселя псевдографики, то работать с пикселями на уровне символов очень неудобно. Чтобы можно было зажигать/гасить пиксели по одному разумно написать две подпрограммы PSET и PRESET, которые соответственно зажигают и гасят пиксели в экране 128*60. Естественно, для разработки программ для графического режима нужен графический редактор (такой редактор у меня есть, но пока он для Микроши, т.к лезет на D00x и F80x), а для разработки игр полезен также редактор спрайтов.

Здесь поговорим о нескольких малоизвестных псевдографических режимах РК86, которые возможны при наличии альтернативного фонта (или схемы с загрузкой фонта).

На сайте ZX-PK.ru описаны уже две конструкции, позволяющие загружать свой фонт. Они содержат всего по 7-8 микросхем. Но для меня и это слишком сложно, тем более, что практически то же самое получается, если в качестве ПЗУ знакогенератора использовать 27256, что даёт 32 фонта, что ничуть не хуже загрузки, а делается за несколько минут труда с расходом (кроме 27256) в несколько кусочков проволоки. Панельку на 28 ног для большого фонта можно впаять вместо панельки на 24 ноги или смонтировать с краю платы (где уже сть отверстия для этого).

Псевдо графический режим определяется прошивкой фонта. Т.к в базовом РК86 всего один фонт, то и графический режим всего один 128*60. Все графические игры РК и графический редактор работают только в этом режиме.

А вот разработчики РК-клонов оказались поумнее, они предусмотрели коммутацию фонтов и альтернативные более грамотные фонты для вывода графики. Так в Апогее есть фонт с высотой знакоместа в 4 линии растра с разложением знакоместа на 3*2 пикселя (что при 51 строке даёт режим 192*102), а для Партнёра есть фонт высотой в 6 линий с разложением знакоместа на 2*3 пикселя, что даёт графический режим 128*129.

Правда, т.к программное обеспечение клонов на 90% состоит из программ адаптированных от РК86 и Микроши, то и для клонов, - игр для таких режимов практически нет. Только уже в новодельные времена vinxru использовал режим Апогея 192*62, сделав для него несколько цветных графических игр. А для режима Апогея 192*102 вообще есть только демо.

Разрешение стандартного графического режима 128*60 почти соответствует разрешению первых игровых автоматов и игровых консолей середины 70-тых годов. Но всё-же хотелось бы чего-то получше.

Любому инженеру ясно, что, если не пожалеть одного кусочка проволоки и допрошить альтернативный фонт в ПЗУ знакогенератора, то в режиме со знакоместом высотой в 6 линий и пикселем размером 3*2 точки при 43 (45) видимых строках, - РК86 обеспечивает графику 128*129 (и даже 128*135). Что в сочетании с цветом, позволяет делать вполне визуально привлекательные игры. Такой режим есть в Партнёре, т.к там предусмотрели альтернативный фонт под знакоместо высотой в 6 линий.

Возможен и ещё один видео режим, который получается разбиением знакоместа на 3 пикселя по горизонтали и 2 по вертикали. Что даёт 64*3= 192 пикселя по горизонтали и при 45 строках - 45*2= 90 пикселей по вертикали. 45 строк при высоте знакоместа в 6 линий дают в растре по вертикали 45*6=270 линий растра. На LCD телевизорах это отображается нормально. На кинескопных телевизорах это требует точной центровки растра по вертикали. Это можно сделать формированием КСИ на одновибраторе 555 АГ3 запуская её сигналом КСИ из РК86. Можно ограничиться и 43 строками, что даст разрешение 192*86.

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

К сожалению, прогрессивный режим 192*90 возможен только для фонта шириной в 6 точек. Сам я использую более качественный фонт шириной в 8 точек, а 8 точек на 3 не делится. Выкусывать ИЕ5 и снова запаивать ИЕ4, чтобы снова вернуть некрасивый фонт РК не собираюсь, да и печать моей платы из 1987 года это уже не выдержит. Потому я ориентируюсь на более ущербный режим 128*129. Но если кто-то разработает эмулятор с режимом 192*90, то можно делать версии программ и для такого режима.

Более того, оба эти режима занимают только один фонт с знакоместом высотой в 6 линий, если ширина знакоместа как в оригинале всего 6 точек, то можно применить одновременно два графических фонта (т.к каждый из них занимает 64 символа, а всего есть 128 символов). Один фонт использует матрицу 3*2 (по горизонтали 3), а другой фонт 2*3 (по вертикали 3). Первый фонт даёт разрешение 64*3=192 по горизонтали, хотя всего 45*2=90 по вертикали. Такой фонт позволяет в одних участках экрана иметь лучшее разрешение по вертикали (129) , в других по горизонтали (192), что визуально почти эквивалентно режиму 192*129.

В Апогее есть нестандартный режим 192*102 применённый vinxru в играх Гонки и Сокобан. Он не соответствует стандарту телевидения. Там частота кадров 61 Гц, но даже советские телевизоры синхронизировались. Этот режим не изобретён vinxru, а изначально присутствует в Апогее. Я не знал о такой возможности в начале 90-тых, когда экспериментировал с РК86, потому считал максимальным режим 192*86.

Ещё один удобный, хотя и не лучший по граф.разрешению, режим получается при задании высоты знакоместа в 9 линий. Тогда задаём общее число знакорядов в 35 (что даёт 35*9=315 линий растра в кадре, что всё ещё в полосе захвата) при числе видимых знакорядов в 29.

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

Тогда в псевдографике получается разрешение 64*2=128 по горизонтали и 29*3=87 по вертикали. Фонт для 6-ти пиксельного знакоместа занимает 2 в 6-той степени символов, т.е тратится лишь 64 символа из имеющихся 128-ми. Остальные 64 символа остаются для ASCII-символов. Это значит, что на одном экране, причём без оперативной коммутации фонта с помощью атрибутов (все 4 атрибута остаются для 8-ми цветов для INK и PAPER) можно выводить и более качественную псевдографику и надписи обычным текстом. Конечно, разрешение 128*87 не кардинально лучше, чем 128*60, но всё же заметный прогресс.

К сожалению, при этом придётся делать небольшую доработку. Т.к надо получить отсутствие междустрочной линии, что возникает из-за того, что фонт имеет высоту 8 линий, а не 9. Идея, как в текстовом режиме VGA и адаптере Hercules, где матрица знакоместа 9*14, но последняя 9-тая вертикальная колонка повторяет 8-ю колонку, что и обеспечивает сплошную по горизонтали псевдографику, хотя ПЗУ фонта лишь 8-ми битовое. Здесь то же самое только по вертикали.

Ставится КП11, на её вход SEL заводится LC3 (старший адрес для адресации фонта из ВГ75). Тогда пока идут линии знакоместа 0...7 на адреса ПЗУ фонта проходят адреса LC0,LC1 и LC2, а когда пошла 9-тая линия при LC3=1, то КП11 выдаёт на адреса ПЗУ фонта 3 единицы, и из ПЗУ снова читается содержимое 8-мой нижней линии фонта. Т.е 8-я и 9-тая линии знакоместа одинаковы. Если бы авторы РК86 додумались до этого, то можно было бы рисовать сплошные вертикальные рамки и в стандартном режиме (по сбросу).

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

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

Точнее отсутствие такой личности, что вовремя смогла бы понять ценность альтернативного фонта и опубликовать в 1987-89 схему или хотя бы стандарт на порт управления и бит для коммутации фонта, а также рассказать программистам о том, как используя альтернативный фонт можно поиметь более качественный графический режим.

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

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

Таким образом на сегодняшний день прогрессивные видео режимы, т.к для них требуется допрошивка фонта, являются абсолютно "новым словом" в РК-программировании и соответственно для них ещё нет никаких программ. Это для РК86. Да и для клонов почти тоже. Для Партнёра (на форуме ZX-PK.ru упоминалось) есть, по крайней мере одна игра с графикой 128*129. Для Апогея есть игры в режиме 192*62, а для режима 192*102 программ вообще нет (есть только демо режима).

Таким образом для РК86 открыт простор для написания, как игр с красивой тайловой графикой, так и чисто графических игр для псевдо графических режимов 128*87, 128*129, 192*90 или 192*102.

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

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

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

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

ROM-BIOS РК86 (дилетантами обычно называемый монитором), обслуживает единственный из ~30 искейп-кодов промышленных терминалов (это конечно искейп-код позиционирования ESC,59). Т.к пару лет назад я отковырял от ПЗУ РК86, т.е выкинув ненужное и уплотнив, освободил там около 280 свободных для использования ячеек, то появляется возможность добавить хотя-бы какие-то дополнительные управляющие коды в подпрограмму CONOUT (это F809, если кто забыл, хотя как такое можно забыть даже спустя 35 лет).

В такой объём можно упихать обслугу для нескольких дополнительных искейп-кодов или, например, даже целый музыкальный язык, чтобы кодами выбрасываемыми на CONOUT (а ЯВУ ничего другого делать и не умеют, что и заставило придумать искейп-коды, которые служат для передачи команд консоли) можно было бы выводить мелодию через гуделку ВИ53.

Но это всё-равно не спасёт при использовании CP/M, т.е не позволит F809 использовать в качестве входа CP/M-BIOS, что делалось в первых примитивных адаптациях CP/M для РК86 и ОРИОНА, из-за чего экранные программы CP/M не работали, и от CP/M можно было использовать только ассемблер и файловую систему. Потому что для того, чтобы работали все программы надо эмулировать намного большее число упр.кодов, необслуживаемых в ПЗУ РК и потому нет никакой пользы, если в CP/M-BIOS надо будет эмулировать на пару кодов меньше (тем более, что такой код уже написан сто лет назад и сложнее его менять, чем оставлять неизменным). К тому же при использовании DOS, - RAM-монитор не нужен и из ПЗУ РК можно выкинуть более 1 кб, куда как раз удобно и влезают все нужные коды VT52 и даже остаётся место для загручика.

Но всё-же есть один код, причём он не CP/M-овский, а иришин, который ПЗУ РК полезно поддерживать. Для начала вспомним, вывод каких символов поддерживает BIOS РК86.

В фонте РК есть символы для некоторых кодов в диапазоне 0...$1F. Но т.к почти все символы с такими кодами являются управляющими, то разработчики РК86 прошили символы только в те позиции, которые не используются конкретно в РК (но всё-равно остаются управляющими). Потому из 32-х кодов с пользой используется чуть больше половины. А в остальных позициях прошита пустота.

Это сделано потому, что авторы РК не предполагали, что найдутся люди, которые при наличии ROM-BIOS будут лезть в экран внаглую, т.е будут заносить символы прямо в экранный буфер командами процессора. А стандартно, т.е подпрограммой CONOUT половину символов с кодами меньше $20 не вывести, т.к ROM-BIOS интерпретирует их как управляющие коды, а не печатаемые символы. Но разработчики ИРИШИ, а до них разработчики других компьютеров, догадались как обойти эту неприятность.

Они придумали выводить символы с кодами меньше $20 в виде двухбайтовой последовательности первый байт которой равен $01, а следующий байт соответствует подлежащему печати на экране коду в интервале 0...$1F. Таким образом ROM-BIOS ИРИШИ, когда встречает выведенный на CONOUT код $01, то он по нему узнаёт, что следующий байт выброшенный на консоль не надо проверять на управляющий код, а надо просто положить его в экранный буфер в текущую позицию курсора.

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

Без изменения ROM-BIOS нестандартные символы можно помещать на экран только внаглую. Но, если при этом в ROM-BIOS ввести упр.код $01, то вывод всех 32 символов с кодами меньше $20 можно будет делать из ЯВУ и стандартно. Впрочем, для фанатов графики РК останется возможность рисовать кошмарные убогие РК-шные рамки стандартными символами РК86.

Введение обслуживания такого упр.кода в ПЗУ РК86 занимает в нём всего ~20 байтов и доступно любому, знающему хотя бы несколько основных команд ассемблера. Попутно возникает удобство в том, что программа написанная для ИРИШИ тоже использует код $01, а т.к фонт в ИРИШЕ может загружаться в ОЗУ, а экран "не виден" программе на ЯВУ (т.к экран в другой карте и писать в него внаглую она просто не может), то чисто текстовая программа с графикой по принципу текстовой машины написанная для ИРИШИ может работать и на РК86.

В частности, я когда-нибудь собираюсь написать иришин нортон для CP/M, в котором можно рисовать таблицу отдельной подпрограммой на ассемблере, (как это приходилось делать на ОРИОНЕ), которая сама включает карту памяти, содержащую экран и прямым наглым доступом процессора в него рисует на экране линии и рамки. А можно это делать корректно, рисуя на экране выводом символов на CONOUT (кстати ИРИША позволяет рисовать рамки и ещё более уникальным способом, за счёт использования встроенного в ROM-BIOS графического языка).

Если рамка рисуемая таким стандартным способом будет не очень тормозить, то, т.к вначале разумно сделать лишь монохромную версию (не знаю просто пока как работать с цветом ИРИШИ, да и нет у меня цветного монитора), то смогу сделать версию нортона полностью корректную для CP/M, которую можно будет использовать и на Специалисте и на РК (CP/M для РК с ОЗУ в 1 мб я нацарапал для эмулятора ещё года 1.5 назад, в реале не проверял, но вряд-ли на реале возникнут проблемы, т.к эмулятор EMU вполне аккуратный, аналогичную версию CP/M сделал и для Специалиста с расширенным до 256/512К ОЗУ, конфиг для которого предоставил Pyk).

Собственно потратил несколько часов но написал, думаю люди оценят.
https://cloud.mail.ru/public/5pfU/4HZ4HxgYiэто пример кода
https://cloud.mail.ru/public/3Ka6/27A3VsALu это описание как и что.
Для написания простых вещей компилятор подходит более чем. Оптимизации по коду....ну скажем ее нет совсем. Так что пользуйтесь ))).

ведущий_специалист пишет:написал, думаю люди оценят.

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

Конечно что-то можно понять посмотрев предложенный пример, но обидно сделать разработку, а в итоге понять, что возможностей не хватит. Кстати, насколько я понял скомпилированный код возврат в DOS делает по RET, оттого на выходе курсор стоит не там (по крайней мере в эмуляторе так), - если это так, то надо написать свою функцию выхода с JMP F86C. Из примера ясно, что кусок на ассемблере встраивается оператором ASM (кстати в ряде компиляторов встречал конструкцию #ASM ... #ENDASM, а символ # как раз признак макроса). И из примера не понять и информации нет ни слова о интерфейсе между Си и ассемблером (а как раз в этом левизна, читал, что в этом аспекте химия), в стандарте ли глобальные имена и др.

Также многим людям будет огорчительно, что мнемоника ассемблера КР580, хотя изменить под Z80 в лоб похоже не так уж просто (надо проверить все файлы в каталоге INCLUDE и подставить табличный файл для Z80). А под другой компилятор ассемблера не изменишь. Возможности TASM и его моторолловские соглашения меня не устраивают, я привык к интелловским, т.к пользуюсь исключительно М80. Лучше М80 макро-ассемблеров нет, может и есть приличные Windows самоделки любителей, но в основном они неприемлемы (и по соглашениям и по возможностям).

Кстати, смотреть пришлось в резидентном блокноте, т.к кодировка UTF. Я пользуюсь нормальным программистским редактором UltraEdit 9.1 из середины 90-тых (ничего лучше за 25 лет не попалось, более новые версии UltraEdit не устраивают) с кодировками Windows и MSDOS, а для UTF все редакторы убогие. И к тому же ретро компиляторы CP/M, которыми я пользуюсь для ретро-программирования UTF не любят.

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

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

Я собираюсь сравнить в плане эффективности этот Си с BDS Си (в моём архиве есть ещё десяток других, но этот вроде лучший для КР580 ). Я с Си ~20 лет дел не имел, но вряд-ли забыл до нуля. У меня Win XP потому мне пригодны и CP/M-компиляторы, так что кроссовость компилятора (т.е компиляция из Windows) для меня не довод и честно говоря, я сомневаюсь, что бесплатный самодельный компилятор может быть лучше фирменных (которые как раз продавались задорого и доводились несколько лет), хотя отдельные операторы, что важны именно для игр, вполне могут быть скоростнее.

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

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

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

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

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

Однако позднее я поимел дисковод с RK-DOS и заимствовав её подпрограммы странслировал CP/M для РК86 с расширенным до 60 Кб ОЗУ и с аппаратной ASCII-клавиатурой. Это делалось ради текстовости, чтобы получить инструментальную машину с быстрой работой с текстом (т.к оказалось, что графические 8-ми разрядки, особенно те, у которых экран уже 512 пикселей, неприемлемо медленны в выводе текста из-за необходимости использовать небайтовый шрифт).

В CP/M нет корректного нортона (видимо потому, что все нортоны для конкретных 8-ми разрядок писали по железу, т.к корректный, но некрасивый, т.е без графики и цвета, нортон был пользователям неинтересен). Без нортона пользоваться дискетной DOS не особо удобно и к тому же фирменные CP/M-программы нуждались в инверсии знакомест.

Потому, чтобы написать хотя бы нортон для CP/M я сделал в своём РК86 схему введения инверсии знакомест из ж.Радиолюбитель (естественно заменив имитацию XOR-элемента на вентилях ЛА3, на нормальный XOR-вентиль из 155 ЛП5), - закрепление на плате 155 ЛП5 и монтаж трёх проводков не отнял много времени. Но при программировании обнаружились проблемы. Оказалось, что при обрамлении подлежащих инверсии символов атрибутами включения и выключения инверсии приходилось не только раздвигать весь экран, но и сдвигалась адресация последующих экранных позиций и курсор мигал не в том месте.

Вся доступная мне тогда информация о ВГ75, была лишь в книге В.Г.Маоров "Практический курс программирования микропроцессорных систем". Там была довольно подробная информация о работе с ВГ75, но не было информации про служебные коды ВГ75. А не зная данных секретов и методик программирования атрибутов ВГ75, немного поэкспериментировав и убедившись, что так инверсию программировать сложно, я в итоге сделал инверсию другим способом (за счёт фонта с инверсными буквами), который программировался простым традиционным способом (когда инверсия задаётся взводом одного бита в коде символа).

Естественно, при сдвигаемых в ходе работы адресах начала экранных строк можно хранить таблицу этих адресов и при позиционировании считывать их оттуда. Однако это глупо, т.к это всё-равно не спасает от необходимости сдвигать весь экран при вставке атрибутов. Но оказывается разработчики ВГ75 (точнее его прототипа 8275) не были настолько глупы, учли наличие такой проблемы и специально ввели атрибут "конец строки", который позволяет принудительно ограничить размер занимаемый строкой в ОЗУ при вставке в неё атрибутов.

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

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

Такой трюк позволяет в базовом режиме с отображаемой частью экрана шириной в 64 буквы вставить в строку две группы атрибутов, т.е всего 4 байта. Это потому, что в правом бордюре всего 6 байтов (78-8-64). Однако никто не мешает нам делать вывод на экран меньшей ширины и иметь в строке большее число групп цветовых атрибутов. Например, если в игре будет формат текстового экрана не 64*30, а 60*30, то мы сможем задать цвет уже на 4 объекта в строке, чего вполне достаточно для РК-игры. Сама БИС ВГ75 имеет ограничение на не более 16 атрибутов в строке. Т.е задаёт ограничение на не более 8 цветных объектов в строке.

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

Есть ещё один способ сохранить неизменными адреса начал всех строк экрана. Для этого надо заранее в конце всех строк вставить группу фальшивых (т.е ничего не делающих) атрибутов. Атрибуты не идут в зачёт, в смысле не защитываются CRT ВГ75 в счёт 78-ми символов строки, но строчный шаг естественно изменяют.

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

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

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

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

А затем с 1993 года и позднее резкому падению популярности РК-подобных сильно поспособствовало вытеснение 8-ми разрядок используемых в стране, завозимыми в страну (целыми контейнерами на вес) очень дешёвых б/у IBM PC устаревших моделей (так называемого IBM-хлама, который до того уже успел завалить весь остальной мир). Т.е тех IBM-железок, что морально устарели на Западе, потому были дёшевы и их можно было закупать по цене лома. Дешевизна устаревшей для других стран б/у IBM-техники сделало в середине 90-тых годов покупку вплоть до 486-той PC доступной практически каждой российской семье.

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

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

Это разумеется объясняется тем, что программисты любители обитали в основном в городах и привлечённые лучшими апп.возможностями других 8-ми разрядок к 1991 году покинули РК-платформу. Появление для РК86 в начале 1992 года крутого атрибутного цвета (по идеям из Апогея-06Ц) и в начале 1993 года дисковода для РК86 - сильно опоздало и уже не могло изменить ситуацию (потому цветных или дисковых программ РК86 практически нет).

Отрицательную роль в популярности РК86 сыграла публикация совершенно несеръёзного (т.к бессмысленно громоздкого и без печ.плат) варианта аппаратной доработки РК86 в 1995 году (так называемый вариант РК-Макси), тогда как значительно бОльшую пользу для популярности РК принесла бы реклама доработки до цвета (о которой многие российские владельцы РК86 ничего не знали, не имея доступа к статьям в иностранном журнале "Радиолюбитель"), а появлению новых программ для РК помогла бы публикация дискового компилятора Си или Паскаля для RK-DOS.

И лишь в XXI-веке после того, как Интернет сделал доступным контакты между любителями, выяснилось, что всё ещё осталось небольшое число любителей РК86 и клонов. К тому же промышленность изготовила в начале 90-тых такой запас РК-подобных, что ещё несколько лет назад желающие могли закупать "Апогей" выпуска 1992 года десятками в нераспечатанных заводских коробках. Позднее были выпущены даже новодельные платы как самого РК86, так и основных промышленных РК-подобных, так что интересующаяся ретро техникой молодёшь имела возможность самостоятельно собрать РК86 или клоны.

К сожалению, для программирования программ для РК86 вплоть до сегодня не были доступны компиляторы ЯВУ. В историческую эпоху (т.е в 1986...1993 годах) они были недоступны из-за отсутствия дисковых накопителей или эмуляторов РК86 на PC XT, а в XXI-веке - уже из-за отсутствия знаний по CP/M у ныне живущих любителей РК86.

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

Потому энтузиастам программирования для РК86 даже в XXI-веке был доступен лишь ассемблер, причём даже не в виде отличных CP/M макро-ассемблеров, а в виде простых самопальных ассемблеров для КР580, сделанных любителями для Windows (ибо микропроцессор 8080 уже лет 40, как непопулярен в мире империализма). Из-за этого в новодельное время было написано всего лишь порядка десятка РК-игр на ассемблере и лишь одна РК-игра была написана на ЯВУ (а точнее на PL/M - речь о этой игре).

Недавно я опробовал методику позволяющую создавать программы для РК86 используя компилятор ЯВУ из CP/M. К сожалению, для процессора КР580 выбор компиляторов даже в среде CP/M не особо большой, а именно - доступны лишь компиляторы Паскаля (один компилятор), Си (два), Ады (один), Фортрана (один), Алгола (один), PL/I (один), PLMX (один), бейсика (два) и ещё нескольких совсем экзотических ЯВУ.

По утверждению Гарри Килдэлла (его фирма написала ряд известных компиляторов для КР580, потому его мнение самое компетентное) для среды CP/M самым эффективным является компилятор PL/I. К сожалению, хотя этот ЯВУ был основным ЯВУ на советских клонах IBM-370 (т.е на машинах серии ЕС ЭВМ), сейчас этот ЯВУ давно вышел из моды (его сейчас помнят вероятно лишь программисты в возрасте 70-ти лет и более).

По времени выпуска вероятно самый свежий компилятор это Ада, которая в середине 80-тых разрабатывалась, чтоб вытеснить господствовавший тогда Паскаль. Аду стоит попробовать позднее, но в первую очередь сейчас актуальны компиляторы Паскаля и Си. Так как Паскалю учат в школе, а Си знают все профессионалы в области IT-технологий и документации больше всего именно к этим ЯВУ.

Однако при этом имеется одна, хотя и преодолимая проблема. Почему-то компиляторы из CP/M компилируют программы предназначенные для запуска в ОС CP/M, т.е они делают ввод/вывод используя функции BDOS CP/M и нагло вызывают п/п-ммы CP/M-BIOS, а также коварным образом определяют RAMTOP ОЗУ (чтобы узнать куда им поставить стек) считывая два байта из ячееек с адресом 0006/0007. Эта наглость программ скомпилированных CP/M-компилятором не позволяет их в лоб использовать на РК86, даже, если не делать дисковых вызовов и ввод/вывод делать собственными ассемблерными процедурами (переадресующими вызовы к стандартным входам в ПЗУ F800 или лезущим прямо в экранный буфер).

Некоторые компиляторы позволяют транслировать не для среды CP/M (и даже для ROM). Но, например, для Паскаля МТ+ это требует существенных изменений, т.е замены некоторых базовых функций буферизованного ввода/вывода на свои (а там исходника RUN-тайм библиотеки нет и разобраться, что и как менять, довольно сложно).

С BDS Си немного проще, т.к там в дистрибутив прилагается исходник RUN-тайм модуля, содержащего процедуры инициализации и подпрограммы ввода/вывода. Их несложно переделать. Но я только вчера, под влиянием Виктора-2312, решил посмотреть на BDS C и с этим ещё даже не пытался разбираться. Однако есть и более тривиальные, лобовые варианты. Проще всего программы из под CP/M компиляторов модифицировать так, чтобы при своём запуске они как-то сами создавали себе CP/M-совместимую среду.

Это делается просто добавлением в конец кода программы или в её начало специального блочка кода, который стартует и прогоняется до передачи управления собственно коду программы из под компилятора ЯВУ и создаёт имитацию CP/M-среды. Если программа не лезет в дисковые накопители CP/M, то этого достаточно для работы CP/M-программы, которая только читает с клавиатуры и что-то выводит на TTY-терминал.

Как все знают, исходно в CP/M как раз был именно TTY-терминал (пример такого терминала это АЦПУ) при котором символы выводятся лишь в текущую позицию (на экране или на рулонной бумаге в АЦПУ). Т.е курсор не может быть позиционирован в любую точку экрана и для последующего вывода заданы атрибуты вывода (в частности включена инверсия знакомест).

Однако в 1978 году какие-то люди, которых почему-то (как всех остальных пользователей CP/M) не удовлетворил убогий построчный си-пи-эмовский командный редактор ED.COM, написали текстовый экранный редактор (точнее якобы даже текстовый процессор: Word Master). Это конечно сделало текстообработку намного более удобной, но одновременно лишило возможности пользователей использовать для вывода АЦПУ, а в случае РК86 - использовать для вывода на экран п/п-мму F809 из ПЗУ РК86.

Ибо такие слегка наглые программы (называемые экранными) применяют какие-то странные управляющие коды, обычно называемые искейп-кодами (вероятно потому, что в них первый байт это $1B, который на CP/M-машинах выдаёт клавиша <ESC>). По этой причине, имитатор CP/M для РК86, чтобы работали экранные программы не может быть настолько примитивно простым, как это предложил изобретатель РК86 С.Н.Попов в журнале МПСС в 1986 году.

Простой имитатор CP/M-функций лишь обеспечивает вывод на TTY-экран, т.к не эмулирует ни один из десятков стандартных CP/M терминалов (наиболее популярными были терминалы самых массовых CP/M машин, например Heathkit H89, менее популярны - терминалы DEC VT52 и VT100, которые, напротив, были очень популярны в СССР из-за бОльшей популярности у нас DEC-овских ЭВМ). Это приводит к тому, что с простейшим имитатором CP/M работают лишь неэкранные CP/M-программы (например, отладчик DDT). Кстати, без экранного терминала (например VT52) на РК86 вполне могли бы работать CP/M-компиляторы, но для них нужен дисковый привод и к тому же им в базовом РК86 не хватит ОЗУ в 29 Кб.

Однако отсутствие обслуги искейп-кодов в ПЗУ РК это не проблема для программирования игр на CP/M-компиляторах ЯВУ. Для игр, что вероятно позволяет немного выиграть скорость, можно работать прямо по экранному буферу. Ибо в РК86, в отличие от крутых развитых западных 8-ми разрядных машин, экранный буфер находится в адресном пространстве для программ, что как раз удобно для ЯВУ. Т.к компиляторы ЯВУ генерят монофайловые программы (т.е программы из под ЯВУ не могут раскидывать свой код по разным банкам, что могут делать программы написанные на ассемблере).

Да и даже без наглоты (т.е не используя наглую прямую запись и прямое считывание из экранного буфера), наличие в ПЗУ РК86 возможности позиционировать курсор по ESC,Y и наличие подпрограммы ПЗУ для корректного к конкретному железу считывания кода из экрана, вполне позволяет делать на ЯВУ динамичные РК-игры без наглоты.

Если заняться штамповкой игр на ЯВУ, то не очень выгодно вставлять в каждую программу из под ЯВУ (т.е написанную на BDS-C, Паскале МТ+ или PLMX) блок имитации среды CP/M (кстати, другие компиляторы под КР580 пока не опробованы, хотя может они и намного лучше). Удобнее было бы просто транслировать программы для среды CP/M не заморачиваясь несовместимостью.

Для этого достаточно прошить имитатор CP/M прямо в эр-кашное ПЗУ F800. Т.к кому-то год назад удалось путём оптимизации освободить в стандартном РК-ПЗУ аж 285 байтов (а при переделке под Z80 будёт еще на более, чем 50 свободных байтов больше) - этого хватит на встраивание в РК-ПЗУ режима имитации CP/M.

Управление теоретически можно сделать автоматическим, т.е по сбросу. Но это невыгодно, т.к после каждого аппаратного или программного сброса будет затираться код с адреса 0, а большинство РК-программ как раз грузятся на 0 (и это сделает после сброса программу в ОЗУ - повторно нестартуемой). Потому надо ввести п/п-мму F842 (F836, F839, F83F это п/п-ммы для банкового ОЗУ и программного звука). При вызове F842 имитатор CP/M будет инициализироваться, после чего на адрес 100 можно загрузить и запустить недисковую CP/M-программу, которой хватает 29 Кб TPA.

Ценность имитатора CP/M работающего из ПЗУ в том, что он не отнимает основное ОЗУ, т.е уровень TPA не понижается, плюс удобство не трахаться с каждой скопилированной на ЯВУ программой. Если всё-же затратить 285 байтов в РК-ПЗУ жалко, то можно истратить в нём лишь ~60 байтов и получить почти то же самое, сделав загрузку имитатора CP/M из ROM-диска. Но это будет не совсем то же самое, а лишь почти то же самое. Т.к тогда уровень TPA будет немного ниже (ибо имитатор будет грузиться из ROM-диска под вершину ОЗУ, снижая RAMTOP).