РК со сплошным ОЗУ в 60К цветом и альтернативным фонтом называется "Апогей БК-01ц". На него было перенесено достаточно много программ с РК.Сообщение от barsik
Ещё был Партнёр-01.01, с CP/M и восемью фонтами, а при подключении блока МЦПГ ещё и практически с графическим экраном. И точно также на нём работали слегка адаптированные программы с РК.
Последний раз редактировалось b2m; 01.03.2017 в 11:23.
так в том и идея чтобы не уходить, а сделать совместимо: расширить ОЗУ страницами по 64к (что не исключает дополнительных опциональных более мелких окон - например ими можно пользоваться для межстраничных пересылок), добавить порт страниц ОЗУ, где первую страницу (с адресом "0" по сбросу) пожертвовать под совместимость с ретро и адресным порно, при обращении к остальным страницам ничего такого странного не делать
- вся память процессору (почти по Ленину). Всего-то надо - чипселектами того, что лезет в середину адресного пространства, дополнительно управлять в зависимости от порта страниц по 64к.
Кто эти все? Убедились думаю в основном кто попробовал и бросил - ниасилил, те, кто продолжал пилить, до сих пор используют: вон даже игры на С вполне себе выпускают (в соседних темах по ZX), библиотеки есть на уровне "сред быстрой разработки" - куда там ассемблеру. А уж для псевдографических и системных утилит где графики мало, по скорости требования ниже, а математики будь здоров сколько, ЯВУ вполне себе инструмент.
А для "лоскутной" адресации таки-да, остается только ассемблер и демосцена (т.е. перевод электричества в тепловыделение), ибо никаких громадных проектов последнее время на асме что-то не видно: "настоящих буйных мало", профи ассемблера (которые писали под CP/M и фирмы-игроделы) ушли, а потенциал для портирования готового исходного кода с других платформ у ассемблера околонулевой (здесь с возможностями ЯВУ даже сравнивать бесполезно).
Оно все так, но в те времена было одно существенное ограничение: в СССР память ОЗУ была дорогая и дефицитная. Поэтому чтобы забороть "трудные детские болячки РК" опять же обошлись одной линейкой РУ5, унеся порты и экран, и потеряв железную совместимость. Сейчас с памятью проблемы нет - хочешь статикой выйти можно из положения, хочешь на РУ7 или на более емких DRAM-аналогах. Взять тот де Вектор (ЕМНИП): в нем же так и сделали - имеющуюся страничку с экранами не трогали, а добавили "квазидиск", в котором благодаря прямой адресации ЦПУ работала CP/M=Микродос и прочее что требовало больших страниц.
- - - Добавлено - - -
Кстати, компиляторы ЯВУ до сих пор делают, даже среди участников форума есть пример - Vinxru (к сожалению, свалил с форума) с его компилятором С и несколькими играми на этом самом С написанными - как раз таки для Апогея и Ориона (и может еще каких), кросплатформенность же
Последний раз редактировалось Error404; 01.03.2017 в 12:09.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Если взять, что де факто РК имеет ОЗУ 32Кб, то лучше наверное сделать окно 16Кб, чтобы при переключении банок хотя бы какое-то ОЗУ оставалось на месте, тем более что и экран нельзя переключать (а вдруг там мусор и ПДП подсунет ВГ-шке всякую ересь). Так что окно 16Кб с нулевого адреса - вполне адекватно с программной точки зрения, даже если первые 2 страницы будут отражать стандартное ОЗУ 32Кб. Другое дело, что с аппаратной точки зрения, чтобы сделать окно 16Кб и фиксированные 16Кб в области 4000-7FFF - одним проводочком не обойтись.
Окно в 16кб (или меньшие) никакого удобства при программировании не дает. Маленькие окна - это медленные и мучительно организовываемые оверлеи кода или данных для единственного приложения, которое придется еще и написать, потому что готовые приложения (если из приличных) - большие и не лезут в 32к из которых еще надо вычесть экран. "Удобство" диспетчера по 16к наглядно иллюстрирует соседняя тема про FUZIX для ZX-128, где уже наизнанку вывернулись, а ничего путного в эти 16к не лезет.
Другое дело, что это окно в 16к приобретает смысл как отключаемая "склеенная" область межстраничного обмена, но только если есть эти большие страницы.
- - - Добавлено - - -
В этом случае можно упростить: на время межстраничного обмена накрывать "большие страницы" 32к-шной ОЗУшкой нулевой (основной,начальной) страницы. Т.е. как аналог диспетчера с окном 32к где всегда включается только один сегмент. Это же даст возможность и в экранное ОЗУ писать. Фактически, это будет единственное что будет требоваться от основной страницы в расширенном режиме - экран да подпрограммы межстраничной пересылки.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Собственно, нет особой необходимости иметь порты по адресам выше 8000h в расширенных режимах. Можно сделать как в Специалисте-МХ - стандартный режим, совместимый с обычным Радио-86РК, и режим типа МХ, когда все порты сгруппированы по адресам, например, FF00-FFFF. По сбросу - стандартный режим, при записи в область FFFC-FFFF - меняем режим.
Теоретически так, но на практике нет. Не видел в сети исходников игр на СИ, а вот на ассемблере видел много. Только на прошлой неделе встретил на этом сайте ссылку на исходник TINY BASIC, адаптированный для CP/M (добавлены LOAD/SAVE), странслировал не меняя ни байта, а затем не напрягаясь нашёл в сети более 10 программ на TINY BASIC от антикварных ЭВМ (в том числе ассемблер и дизассемблер 6502). Понятно, что игры убогие (что иного ждать от игр из 1976-77), но важен факт, что работают. Хотелось бы перетранслировать бейсик от ZX80 (4 кб) и найти несколько сотен игр на этом бейсике.
Что за блок МЦПГ? Модуль Цвета Псевдо-Графический? Где увидеть схему и описание? Программировать псевдографику неудобно. Я написал текстовый драйвер 32*12 для режима 192*100, опыт имею.
Что касается АПОГЕЙ, ПАРТНЁР, КРИСТА, МИКРОША... и кто там ещё, всех не упомнишь. Понаделали несовместимых клонов. Если уж так хотелось несовместимости, могли бы сделать в них 2 режима - свой и РК86. Для чего было достаточно вместо ИД7 поставить РТ4 и второе ПЗУ F800. Несовместимых клонов много, а РК86 один. Лучше держаться за РК86, незачем менять компьютер и для РК больше программ.
Лучше бы вместо компиляторов СИ делали бы компиляторы PL/M, который даёт код, в 4 раза более меньший и быстрый. Чтобы понапрасну не "пудрили" людям мозги идеями, что на СИ можно написать что-то для РК86. BEST-C РК86 тому пример. Хотя от лучшего СИ, чем BDS и AZTEC, я бы не отказался.
Исхожу из того, что не встречал для отечественных 8-ми разрядок ни одной приличной программы написанной на ЯВУ (за исключением форта и PL/M). Сам я программирование на СИ и Паскале для CP/M и MSDOS осилил еще в начале 90-х. Видел с какой скоростью работает CHANGER для дисков MSDOS на Pascal МТ+ (объём 32К). Видел 2 Нортона написанных на СИ. Один А.Балдина (1993, с драйвером на 80 символов в экране 400) чисто на СИ, который разбух до 32 кб и был брошен по причине нехватки памяти. Другой мой, написанный на BDC С (или AZTEC не помню), с максимально большими вкраплениями ассемблера, что предположительно должно было помочь удержать объём кода. Но не особо помогло.Кто эти все? Убедились думаю, в основном, те, кто пробовал и бросил, не осилил. Те, кто продолжал пилить, до сих пор используют. Вон, даже игры на СИ выпускают (в темах по ZX), библиотеки есть на уровне IDE, - куда там ассемблеру?
Хотел скинуть исходники этих СИ и ПАСКАЛЬ программ, чтобы доказать вышесказанное, но подкаталоги всех версий всех программ на ЯВУ в архиве оказались пустыми. Так бывает когда копируешь каталог, который занят, остались только 200 пустых подкаталогов. На дискетах что-то осталось, но ранние версии, т.к дорабатывал уже в своём эмуляторе. Но нет исправного флопа. Среди TD0 нашёл раннюю версию нортона на СИ в 17 кб (объём последней версии был 30 кб). Если кого интересует могу выложить. Нашёл также текстовый редактор на Турбо-Паскале, аналог турбо паскалевского. Имеет тот же размер, что и SED.COM написанный на форте, причём редактор даже слабее, чем SED, т.к нет свопинга, отчего редактируется только файл, что умещается в ОЗУ, так же как и турбо паскалевский редактор. Если сделать для файлов любого размера, то объём кода увеличится на 30%. Полный аналог редактора на ассемблере в 3.5 раза меньше.
Но что касается СИ, применительно к разработке игр для РК86, то думаю, что здесь еще не сказано последнее слово. Для написания игр для текстовой ЭВМ скоростей СИ хватит, если критичные процедуры переписать на ассемблере и использовать ОЗУ 64К в виде двух полу-банок. Т.к во вторая полубанка может использоваться только для данных, то получается 28К для кода и 32К для графики. Этого вполне достаточно. Для РК86 ещё никто не писал на СИ, т.к в годы когда для РК создавалось ПО, - не было доступа к CP/M и соответственно СИ-компиляторам. Давайте исправим эту ошибку и сделаем для РК86 килограмм игр, используя BDC-СИ (т.к он почти единственный и возможно лучший для КР580).
Можно, и даже нужно. Этой фразой Вы натолкнули меня на две победительные идеи, которые я обязательно использую.
Надо сделать так, чтобы по сигналу HLDA автоматически включалась конфигурация с экранным буфером в адресном пространстве. Вот тогда в области экранного буфера можно включать любую банку ОЗУ.
Это хорошо, но интересная идея не в этом. А в том, как временно убирать экран и KBDPPA из адресного пространства программ пользователя, не нарушая совместимости в самой базовой схеме РК86 на РУ5. Что даёт сплошное ОЗУ 46 кб и позволяет в CP/M увеличить TPA c 28 кб до 37 кб, что для меня существенно. Например, в СПЕЦИАЛИСТЕ я имел TPA 35К и этого хватало (CPM на D000...EFFF, экран с 9000, ниже служ.ячейки и TPA).
При старте программы пользователя (программно) экран переносится на B6D0, для чего сигнал HLDA подаётся на два вентиля ЛП5, которые при HLDA=1 будут инвертировать адреса A14 и A15, поступающие от БИС ПДП (точнее от ИР12, т.к старшие адреса ПДП защелкиваются по ALE в ИР12). Оттого ПДП будет как всегда читая экран с адресов 76D0...7FFF, будет реально считывать экран находящийся на B6D0...BFFF (что как раз удобно попадает в окно расширения ОЗУ 8400...BFFF). Можно перенести экран и в область E6D0...EFFF, но тогда надо 3 вентиля ЛП5, хотя я предпочитаю на E000 иметь ПЗУ с отладчиком DDT (или же ОЗУ, чтобы его туда грузить).
Вторая идея заключается во временном отключении выборки ППА клавиатуры по адресам 8000...83FF. Делаем так. ППА клавиатуры адресуемое на 8000...83FF одновременно выбирается по другому адресу (например, F200). Тогда перед стартом CP/M выборка ППА по 8000...83FF программно отключается, экран для ПДП программно или аппаратно переносится на B6D0 и образуется сплошное ОЗУ 0...BFFF.
Естественно, т.к тот драйвер вывода, что в ПЗУ выводит в экран 76D0, то CP/M выводит на экран не п/п-мой F809, а имеет свой драйвер вывода на экран B6D0 (но выгоднее доработать ПЗУ F800, введя служ.ячейку адрес экрана).
Таким образом в полностью базовой "кривой" архитектуре, мы получаем то, что хотели - 100% совместимость и работу ДОС в сплошном ОЗУ 48К. Эта идея мне нравится.
Если в CP/M переносить экран не аппаратно, а программно, то расход деталей составит всего один корпус ЛА3. В качестве управления - один бит из доп.ППА D14 по адресу F100 или даже неиспользуемый бит PC1 ППА клавиатуры. Если переносить адрес экрана аппаратно, то расход будет уже 2 корпуса: ЛП5 и ЛИ1.
Только вот такие простейшие доработки с минимумом доп.корпусов приемлемы. Что толку от победительной архитектуры, если реализация сложна и её не повторить, даже имея электропаяльник?
Последний раз редактировалось barsik; 22.03.2017 в 12:07.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
BDS C и Aztec C - слабые компиляторы. Они для 8080 (который менее удобен для кодогенератора С чем Z80), они сами по себе генерируют не самый оптимальный код, они не совместимы с ANSII, ЕМНИП оба не умеют int32 (или через какие-то жуткие костыли). У BDS C есть правда один плюс - это писали классики (Borland inc), для MSDOS позже сделавшие лучшие реализации С/C++, и они не так давно официально отдали в PublicDоmain исходники этого своего компилятора (единственные кто так сделал).
Я в своих орионовских проектах (сотни килобайт исходного кода С) использую Hitech C - лучший нативный компилятор С для Z80: даже версии работающие на РС его только-только догнали по эффективности после десятков лет допиливания (я сейчас про smallC-переросток SDCC, других реальных конкурентов нету), а по удобству использования пока еще не догнали (и это при том, что работают на безразмерных ресурсах РС, тогда как Hitech C - в 64кб и на Z80). Hitech C версии для CPM официально бесплатен (его исходников правда нет, но есть исходники всех библиотек), совместим с ANSII, умеет int32 (ну и float для желающих странного) . Т.е. им можно странслировать код с Unix или с PC написанный классиками программирования, а BDS C или Aztec C - наврядли. В этом ключе PL/M бесмысленен - что им компилировать? В мире никто на нем не пишет.
Приложения у меня порой доходят до 40-50 кб размера бинарника, не вижу в этом никакой проблемы, тут опять же плата за удобство: хочешь добавить в свой труд технологичность разработки, пользоваться достижениями предшественников, подчас поумнее чем сам (всё есть в OpenSource), - добавь памяти (в данном случае размер TPA) и частоту проца. А у грамотного кода пера опытных программеров и размер будет меньше.
На С я делал 2 командера (один на BDS C чисто для прикола - с графической либой) и один на HI-TECH-C в качестве ГУЯ для копировщика с FAT32, код командера получался порядка 20кб (прикидочно по памяти), но я не делал рюшечки для полной похожести на НортонКомандер v3, чем так увлекся А.Балдин (я видел его нортоны) в ущерб функционалу да еще с привязкой по железу (нортон Балдина работал только в определенном окружении). Нортон от vinxru написанный на его же С (там весьма хакерский С, не совсем по букварю работающий), вообще маленький - несколько килобайт.
Вот кстати, FATfs (библиотека-копировщик с FAT32/FAT16/FAT12 на С со всеми функциями файловой системы, а не только копирования,) без гуя при всех наворотах и 32-битной математике (т.е. на порядок более сложная функционально) в бинаре произведеном HI-TECH-C дает только 20 кб. Вот и пример в сравнении с CHANGER для дисков MSDOS на Pascal МТ+ (объём 32К для только FAT12) - грамотно написанный код и скомпилированный нормальным компилером на порядок меньше.
Последний раз редактировалось Error404; 02.03.2017 в 01:06.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
А ни кто её не пытался переписать под православный z80 асм?
На порядок обозначает разницу в 10 раз, т.е. 3.2кб вместо 20кб. Но что интересно и тот и другой пример как бы намекает: нужны способы (оверлеи) поднять общий обьем кода\данных программы с обычных 50...60кБ до 128...4Мб для более-менее серьезных программ. А иначе писать все прийдется на ассемблере (который дает выиграш в 3...5 раз по обьему).
Данная тема, после того как выяснилось, что на новые платы РК86 нет интересантов, плавно преобразовалась в тему по обсуждению изменений архитектуры, что можно сделать на самой плате РК86 или в виде внешних плат расширения.
Сообщение B2M о том, что в одном из клонов РК86 есть целых 8 фонтов, навело меня на мысль, что если число фонтов сделать ещё большим и переключать их не целиком на весь экран, а с помощью GPA ВГ75 лишь для отрисовки конкретного спрайта (т.е переключать фонт в пределах строки), то получится делать красивые игры неотличимые от графических, но работающие гораздо быстрее (без мерцаний). Что доказывает, что возможности РК86 ещё далеко не исчерпаны.
При использовании ПЗУ 27256 или 62256 с подпаянной батарейкой, т.к каждый фонт занимает 1 кб, получаем 32 фонта. Рассмотрим портацию игры Manic Miner от ZX80. Будем использовать спрайты 2 на 2 символа. При матрице знакоместа в 8*8 отображается спрайт в матрице 16*16, а при фонте 6*8 будет 12*16.
Для имитации движения, в среднем вполне достаточно иметь 8 фаз каждого спрайта. Тогда на один спрайт уйдёт 2*2*8= 32 символа. Итого, в одном фонте в 128 символов мы сможем разместить всего 4 спрайта, а в 32 фонтах умещаются 128 спрайтов. В средней игре не более 12-ти спрайтов. При 4-х спрайтах в фонте и до 16 спрайтах в игре, для коммутации фонта надо всего 2 атрибута ВГ75. Это даёт 12 спрайтов и ещё 128 граф.символов для рисования пейзажа. Тогда ПЗУ 32К хватит для хранения графики для 8-16 игр. Некоторые спрайты можно делать 3*3 (благодаря текстовому режиму даже скоростей РК хватит, чтобы двигать большие спрайты), то будет еще красивее.
Аппаратно, - два атрибута ВГ75 коммутируют 4 фонта в конкретной игре (адреса А10,А11 27256), а портом БЭ ППА D14 выбираем игру (адреса A12...A14 27256).
Если добавить цвет, то практически получится реализация Денди, если я правильно понимаю, как он устроен. Если кто-нибудь даст мне спрайты из Manic Miner ОРИОНА, я написал бы демо (движение фигурки, это просто) и тогда можно было бы увидеть, что получается. Кто нибудь может предложить какой-нибудь редактор спрайтов на PC? Не хочется писать ещё и редактор спрайтов (с визуализацией фаз).
Для получения цвета уже не обойтись только заменой ПЗУ, как для получения спрайтов. Здесь придётся делать существенные доработки. К сожалению, в ВГ75 всего 4 выходных сигнала управляемых атрибутными командами. Если 2 атрибута занять на коммутацию фонта, т.е на выбор спрайта в играх, то на цвет остаётся всего 2 бита, т.е всего 4 цвета. Маловато.
Впрочем, для игр можно сделать 7 цветов, имея всего 2 бита. Смотри ниже.
Однако, в играх можно получать цвет из фонта. Для этого параллельно ПЗУ фонта со спрайтами, ставится второе ПЗУ содержащее цвет спрайта. При защелкивании видеобайта из ПЗУ фонта в ИР13, одновременно в добавленной вторым этажом ИР13 защелкиваем 8 битов из ПЗУ цвета. ПЗУ цвета может иметь размер в 8 раз меньше, чем ПЗУ с фонтом, задавая тем самым один цвет на все знакоместо. Как обычно 16 цветов фон и 16 цветов цвет символа. Для оцвечивания текста такой способ не годится (нам ведь не надо чтобы, например, все бувы А были красными на белом, а все буквы Б - зелёными на жёлтом. А вот для раскраски спрайтов это в самый раз. Увы, второе ПЗУ увеличивает сложность конструкции, хотя и даёт спрайтам цвет (не хуже, чем у Синклера).
Если фонт 6*8, то можно получить цвета для спрайтов и без второго ПЗУ с кодами цвета. Тогда цвет прошивается в два неиспользованных бита в каждом байте спрайта. При защелкивании байта из фонта в ИР13, два бита из фонта защелкиваем в D-триггерах и используем для формирования R.G.B. Два бита дают 4 цвета. Расход деталей для такого цвета в играх составит всего 2 TTL-корпуса.
4 цвета это мало, поэтому я придумал, как на 2-х цветовых битах сделать 7 цветов. Если 2 бита цвета равны 0, все нули байта из фонта выводятся белыми (в РК фонт инверсный), т.е всё как в базовом РК. Три другие сочетания битов задают 3 цвета для чётных битов и 3 другие цвета для нечётных битов. Т.е закраска светящейся точки зависит от позиции в байте. Поэтому если надо чтобы спрайт был одного цвета его рисуют только чётными или только нечётными точками. Спрайт получается прореженным, но зато есть 7 цветов. Сочетанием точек можно получить другие цвета. Такое оцвечивание годится только для раскраски спрайтов в играх. Текст так не раскрасить.
Это не моя идея, это идея цвета Apple-II, но об этом знают только те кто изучал Apple-II, т.е практически никто из фанатов РК86 и ОРИОНА. Кстати, количество цветов можно увеличить до 8, отказавшись от сочетаний цветов (в 2-х соседних точках. Тогда если четный и нечетный биты 01 или 10, то один из 6 цветов, а если 11, то это 8-мой цвет.
Если же хочется большее число цветов, то можно использовать 2 бита GPA ВГ75 и 2 бита из ПЗУ фонта. Тогда 2 атрибутных бита задают цвет фона, а 2 бита из ПЗУ фонта задают цвет символов (точнее спрайта). Получаем 4 цвета для фона и 7/8 цветов для символов. А два остальных атрибутных бита используются для выбора спрайта из ПЗУ фонта.
Из-за простоты реализации, цвет из ПЗУ фонта мне нравится больше. Преимущество такого цвета в том, что программисту не надо вообще заботиться о цвете. Спрайт раскрашивается сам, аппаратно. Из-за того, что правее 64-го символа всего 7 пустых знакомест, цвет Апогея допускает всего 3 смены цвета в пределах строки, даёт цвет только символов (не фона), а тут цвет меняет не атрибут, а фонт, потому в играх цвет может меняться хоть в каждом символе и есть цвет фона. Недостаток в том, что на моём РК86 фонт 8*8, и переделывать красивый фонт на уродский я не собираюсь.
Поэтому я придумал ещё один вариант введения аппаратного цвета спрайтов для игр. Он заключается в том, что спрайт делается с размером пикселя не в одну точку растра, а в две. Т.е вдвое снижаем разрешение спрайта по горизонтали (сам размер не меняется). Это достигается расходованием одной КП11. При включении цвета в игре, она в нечётных битах байта из ПЗУ фонта выдает чётные. Вот так: D6,D6, D4,D4, D2,D2, D0,D0. Тем самым биты D1,D3,D5,D7 не участвуют в формировании изображения, т.е свободны. В этих битах и кодируется цвет. КП11 включается в разрыв 4-х цепей идущих от ПЗУ фонта. 4 бита дают 8 цветов символа и 2 цвета фона. 2 цвета фона задаются портом A D14.
Если для цвета добавить вторую схему видео выхода, то можно иметь цвет по принципу CGA, когда 2 соседних бита из фонта задают цвет пикселя. Но тут всё-же больше деталей и меньше число цветов, хотя в спрайте каждый пиксель может быть своего цвета, а не 2 цвета на группу.
Если затратиться ещё на РЕ3 для перекодирования, то из 4-х битов можно было бы иметь 16 оптимальных сочетаний цветов, что ничуть не уже, чем традиционный цвет 16+16. Но это доработка вручную, тут приходится экономить корпуса.
При введении цвета есть один неприятный нюанс. А именно, в РК нет сигнала BORDER, т.к он формируется программно заполнением нулями части экранного буфера. В момент вывода бордюра сигналы R.G.B. или производный из них монохромный яркостный сигнал должны быть погашены. Поэтому если цвет фона нулей в экране не чёрный, то на выходах R.G.B. будет сигнал во время обратного хода развёрток, когда идёт ССИ и синхронизация сорвётся. Чтобы этого не было цвет символа 0 всегда д.быть чёрным.
Затратив один управляющий бит из ППА D14, можем ввести "цвет бордюра". Для этого требуется один вентиль (из ЛИ1 или ЛЕ1) и резистор. Обьединив наш сигнал BORDER с сигналом из ППА и подав его через резистор на вход красного R, мы сможем выводя 1 в бит в ППА окрашивать бордюр экрана (там где записан байт 0) в бледно красный цвет, как сигнал о включённом регистре клавиатуры. Цвет бордюра может быть только бледным (т.к при ярко-красном цвете на дисплее сорвётся синхронизация).
Итак, возможность прогона на РК86 монохромных, цветных и по настоящему графических игр обходится в замену ПЗУ на 27256 и монтаж на плате РК86 4-х корпусов 1533. Адаптация игр РК для такого цвета, намного проще, чем для схемы цвета за счёт атрибутов. Вся работа сводится к выбору символа и цвета из имеющегося набора цветных символов. Но главный сюжет в том, что новые игры РК могут быть полностью графическими и цветными и программировать их легко.
; ---------------------------------------------
В АПОГЕЕ или ПАРТНЁРЕ (или Бог знает где ещё) использовали атрибут RVV для инверсии символов (по схеме из Радиолюбитель за 04.1992). На моём РК тоже так сделано. Но счастья мне это не принесло, т.к оказалось неудобно в программировании.
Для использования атрибутов надо переписать ПЗУ F800, чтобы, при позиционировании по 1B,59 и другим кодам меняющим позицию (в РК эти коды равны кодам курсорных клавиш) учитывались коды атрибутов.
Например, сейчас в ПЗУ F800, при позиционировании по 1B,59 курсор ставится на начало строки и 'nn' раз вызывается п/п-мма "курсор вправо". А при использовании атрибутов надо при этом просматривать строку и если в позиции стоит код более 80H, то надо делать два сдвига позиции, чтобы пропустить неотображаемый атрибут. Вот тогда можно будет при включённой в строке инверсии пользоваться для вывода стандартными подпрограммами вывода и ввода.
А т.к нет желающих так доработать ПЗУ РК86, то для использования инверсии и цвета программист должен сам работать с экраном, а также, запретив аппаратный курсор, должен сам выводить его программно. В итоге от такого атрибута нет толка.
Потому я использую инверсию за счёт альтернативного фонта (что вводится за счёт затраты одного куска провода). Но при этом при инверсии число выводимых символов становится всего 64, как в Apple-II и ZX80 (нет русских букв, вместо них инверсные английские) и нет псевдографики РК (вместо неё инверсные и неинверсные рамочки). Однако, если пользователь РК имеет паяльник и может напаять на ПЗУ РФ2 панельку, куда устанавливается вторая РФ2 с ещё двумя фонтами, то там есть фонт для текстообработки. Точнее два фонта совместно дающие (с инверсией) русские заглавные и маленькие буквы и большие латинские (но рамок нет). Управление фонтом битом PC2 ППА клавиатуры.
Используя атрибут RVV (ReVerse Video) как атрибут выбора текущего фонта, мы получаем и удобную инверсию и все 128 символов. Причём и работе подпрограмм ПЗУ при таком использовании атрибутов вред не наносится, т.к используется режим отображения атрибутов пробелом, отчего экранные позиции никак не сдвигаются. Так можно менять фонт прямо в строке, хотя слова с одним фонтом от слов выводимых с другим фонтом должен разделять пробел. Проще всего задавать фонт сразу на всю строку, тогда атрибут RVV ставится до начала строки (в области левого бордюра из 8 знакомест, что в РК формируется программно), а на место последнего 78-го символа строки ставится атрибут выключения RVV.
Не вижу достойной альтернативы такому способу введения инверсии. Она не только проще стандартной инверсии (кусок проволоки вместо 2-х 155-х корпусов и диодов), но и гораздо удобнее в программировании. Хотя есть и минус, - если ПЗУ фонта всего 2 кб, то русские буквы всегда без инверсии и, соответственно, в открытых инверсных окнах с рамочками тексты могут быть только латинскими буквами.
Потому есть просьба к авторам эмуляторов сделать там поддержку атрибута RVV в качестве коммутатора фонта.
Только такие простейшие доработки, что реализуются лишь расходом проволоки или, в крайнем случае, не более 5-6 TTL корпусов, напаянных вторым этажом, допустимо делать в РК86.
Последний раз редактировалось barsik; 22.03.2017 в 17:05.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
