Программирование для РК86

Перейти вниз

Программирование для РК86

Сообщение  barsik в Вт Май 01 2018, 14:20

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

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

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

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

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

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

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

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

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

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

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

_________________
***
avatar
barsik
новичёк

Сообщения : 85
Дата регистрации : 2016-11-10
Откуда : 600 км от Москвы

Посмотреть профиль

Вернуться к началу Перейти вниз

позиционно независимый код для КР580

Сообщение  barsik в Вт Май 01 2018, 15:04

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

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

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

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

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

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

Код:
        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.
avatar
barsik
новичёк

Сообщения : 85
Дата регистрации : 2016-11-10
Откуда : 600 км от Москвы

Посмотреть профиль

Вернуться к началу Перейти вниз

стандартный графический режим

Сообщение  barsik в Вт Май 01 2018, 19:27

В базовом РК базовый фонт имеет 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 около 100 байт, так что место есть. На такое расширение уйдёт всего десяток байт. Разумно ввести подпрограмму, которая получает в регистрах 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), а для разработки игр полезен также редактор спрайтов.


Последний раз редактировалось: barsik (Ср Май 02 2018, 15:53), всего редактировалось 1 раз(а)
avatar
barsik
новичёк

Сообщения : 85
Дата регистрации : 2016-11-10
Откуда : 600 км от Москвы

Посмотреть профиль

Вернуться к началу Перейти вниз

новые графические режимы высокого разрешения

Сообщение  barsik в Ср Май 02 2018, 15:12

Здесь поговорим о нескольких малоизвестных псевдографических режимах РК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.

_________________
***
avatar
barsik
новичёк

Сообщения : 85
Дата регистрации : 2016-11-10
Откуда : 600 км от Москвы

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Программирование для РК86

Сообщение  Спонсируемый контент


Спонсируемый контент


Вернуться к началу Перейти вниз

Вернуться к началу


 
Права доступа к этому форуму:
Вы не можете отвечать на сообщения