Май 2019
ПнВтСрЧтПтСбВс
  12345
6789101112
13141516171819
20212223242526
2728293031  

Календарь Календарь

Последние темы
» Эмулятор ИРИШИ для тех, кто не имеет её реальной
автор barsik Пт Май 24 2019, 08:24

» Эмулятор радио 86рк
автор parsec Ср Май 22 2019, 18:44

» Новинки. Книги. Часть 1.
автор Viktor2312 Вт Май 21 2019, 16:21

» Программирование для ИРИШИ
автор barsik Пн Май 20 2019, 21:14

» Новинки. Книги. Часть 3.
автор Viktor2312 Пн Май 20 2019, 16:38

» Модуль контроллера графического дисплея (МКГД).
автор barsik Вс Май 19 2019, 13:40

» ATM Turbo 2+ v7.10
автор alemorf Сб Май 18 2019, 20:03

» Схемы и документация на отечественные ЭВМ и ПЭВМ и комплектующие
автор Viktor2312 Сб Май 18 2019, 18:10

» Куплю микросхемы КР1818ВГ93 и КМ1810ВТ3.
автор Savoj Чт Май 16 2019, 07:51

» Радио-86РК: Расширение ОЗУ
автор barsik Чт Май 16 2019, 01:26

» Клавиатура ИРИШИ
автор barsik Ср Май 15 2019, 16:57

» ИРИША и магнитофон
автор barsik Пн Май 13 2019, 04:23

» Новости криптовалют: статьи, заметки, разное...
автор Viktor2312 Сб Май 11 2019, 03:01

» Жалобы/пожелания по работе форума
автор Viktor2312 Сб Май 11 2019, 00:50

» Альтернативные КНГМД для ИРИШИ
автор barsik Пт Май 10 2019, 01:12

» Видеокарты (GPU). Статьи, заметки, очерки, разное...
автор Viktor2312 Чт Май 09 2019, 19:55

» Алгоритм SHA-256 и др., хеш (hash), хеширование, майнинг.
автор Viktor2312 Чт Май 09 2019, 01:30

» Обсуждение желаемых новодельных плат расширения и мелких усовершенствований базовых плат
автор barsik Ср Май 08 2019, 16:06

» Разное
автор Viktor2312 Вт Май 07 2019, 19:19

» Для новичков (криптовалюта).
автор Viktor2312 Вт Май 07 2019, 17:32

» Ассемблер для современных CPU Intel.
автор Viktor2312 Вт Май 07 2019, 17:12

» МКНГМД Вариант-3. Версия на К1818ВГ93
автор barsik Вт Май 07 2019, 15:15

» Обзор крипто проектов.
автор Viktor2312 Вт Май 07 2019, 12:57

» 7 Мая. День Радио!
автор Viktor2312 Вт Май 07 2019, 12:00

» "Радио-86РК". Статьи, заметки, очерки, разное...
автор barsik Сб Май 04 2019, 20:20

Самые активные пользователи за месяц
Viktor2312
Программирование для РК86 Vote_lcapПрограммирование для РК86 Voting_barПрограммирование для РК86 Vote_rcap 
barsik
Программирование для РК86 Vote_lcapПрограммирование для РК86 Voting_barПрограммирование для РК86 Vote_rcap 
alemorf
Программирование для РК86 Vote_lcapПрограммирование для РК86 Voting_barПрограммирование для РК86 Vote_rcap 
demetrius2003
Программирование для РК86 Vote_lcapПрограммирование для РК86 Voting_barПрограммирование для РК86 Vote_rcap 
a.oleg.a
Программирование для РК86 Vote_lcapПрограммирование для РК86 Voting_barПрограммирование для РК86 Vote_rcap 
parsec
Программирование для РК86 Vote_lcapПрограммирование для РК86 Voting_barПрограммирование для РК86 Vote_rcap 
Savoj
Программирование для РК86 Vote_lcapПрограммирование для РК86 Voting_barПрограммирование для РК86 Vote_rcap 
VladimirS
Программирование для РК86 Vote_lcapПрограммирование для РК86 Voting_barПрограммирование для РК86 Vote_rcap 

Поиск
 
 

Результаты :
 


Rechercher Расширенный поиск


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

Перейти вниз

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

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

1
В общем-то програмирование для РК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.

_________________
***
barsik
barsik
Мастер+

Сообщения : 460
Дата регистрации : 2016-11-10
Откуда : С-Петербург

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

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

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

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

2
Считается, что КР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.


Последний раз редактировалось: barsik (Пн Апр 22 2019, 03:16), всего редактировалось 4 раз(а)
barsik
barsik
Мастер+

Сообщения : 460
Дата регистрации : 2016-11-10
Откуда : С-Петербург

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

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

Программирование для РК86 Empty стандартный графический режим

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

3
В базовом РК базовый фонт имеет 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 раз(а)
barsik
barsik
Мастер+

Сообщения : 460
Дата регистрации : 2016-11-10
Откуда : С-Петербург

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

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

Программирование для РК86 Empty новые графические режимы высокого разрешения

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

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

_________________
***
barsik
barsik
Мастер+

Сообщения : 460
Дата регистрации : 2016-11-10
Откуда : С-Петербург

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

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

Программирование для РК86 Empty как увеличить число печатаемых символов РК86

Сообщение  barsik в Пн Апр 22 2019, 08:41

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

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

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

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

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

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

_________________
***
barsik
barsik
Мастер+

Сообщения : 460
Дата регистрации : 2016-11-10
Откуда : С-Петербург

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

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

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

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

6

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


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

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


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