РАДИО-86РК на Z80

[b2m]

Таким образом, всё портит коммутация кусков памяти в окне.

Если программа хранит в коммутируемой области переменные или стек, то конечно же, после переключения ОЗУ в этой области будут совсем другие данные. Особенно критично это для стека, т.к. возврат произойдёт по случайному адресу. Про то, что стек у тебя в области 8400...BFFF ты писал:

Однако стек всё-равно пришлось ставить на C000, т.е в область 8400...BFFF.

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

Зачем ждать 5 секунд. Достаточно тайм-аута в пол секунды. И это не объясняет откуда берётся старший байт адреса следующего блока равный FF.

За полсекунды ты не успеешь запустить считанную программу, которая дочитывает данные. Хотя, дочитывают данные в основном программы с автозапуском.
И я смотрел .gam файлы, байтов FF после логического конца записи у тебя достаточно. И кстати, не все файлы содержат мусор после контрольной суммы. Некоторые из файлов вполне корректны.

Это лишний раз доказывает, что формат 'GAM' лучше, чем надуманный формат 'RK', т.к в нём есть байт синхронизации E6.

Мне как раз не нравится этот формат. Пропуск первого байта пришлось учесть в коде эмулятора.

В отладчиках должна быть команда PASS для прохождения подпрограмм без трассировки.

Shift+F8 выполнить команду без трассировки (т.е. точка останова временно будет на следующей команде, удобно для пропуска трассировки циклов с пост-условием и подпрограмм)
Ctrl+Shift+F8 выполнить без трассировки, пока не произойдёт RET при значении стека выше текущего положения, т.е. выполнить до выхода из подпрограммы (весьма полезная фича)

Видя фрагмент кода и зная, где надо остановиться, на порядок быстрее ввести команду 'G,xxxx', чем подгонять курсор куда-то

Для быстрого перемещения в окнах кода и дампа есть клавишная комбинация Ctrl+G.
Кстати, до недавнего времени не знал, что в диалоге по клавише F1, в котором выводится подсказка по клавишам эмулятора, текст сместился. На XP было нормально

[Vladimir_S]

А если последней была команда переключения банки, и стек был в переключаемой области, то считаются случайные данные.

Так может все таки уйти от этого дурацкого переключения банок, а поставить SRAM, где каждый байт имеет свой адрес.

[barsik]

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

Куда ставить static RAM? В адресном пространстве РК всё занято. А минимальное статическое ОЗУ - это 32 кб. Так что по любому каждый байт из этого ОЗУ не сможет получить свой адрес.Так что и при статическом ОЗУ выше 8000 имеет смысл диспетчеризация памяти. Если основное ОЗУ на РУ5/ РУ7, то выгоднее "открыть" ОЗУ в окне 8400...BFFF или C400...DFFF.

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

Cюжет заключается в возможности иметь эл.диск как в реале, так и в эмуляторе B2M. Для эмулятора это частично решает проблему проверки в эмуляторе ДОС и программ для них. А для реального РК86 эл.диск из лишнего ОЗУ даёт возможность закачать по линии из PC в эл.диск программы и удобно их использовать, не имея никакого внешнего массового накопителя.

К сожалению, для РК, в отличие от ОРИОНА невозможен программный интерфейс (где расход деталей составляет два куска проволоки), т.к ПДП рвёт программы реального времени. Поэтому обмен по линии с PC возможен лишь аппаратно, при установке в РК микросхемы ВВ51. Да и тогда ПДП на высокой скорости, скорее всего, придётся отключать, что погасит экран. Т.к при высокой скорости передачи, перерыв на 44 МКСЕК (цикл ПДП 78 маш.тактов) приведёт к потере принятых байтов. Хотя скорость передачи в 300 бод получится и без гашения экрана.

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

Речь не о коммутируемости ОЗУ, а о простейшей программе, которая работает в основном ОЗУ и никак ОЗУ в окне 8400...BFFF не коммутирует. Эта программа была с ошибкой, но трассировать её, чтобы понять в чём дело, не удалось. В итоге, мне всё-же удалось отладить эту программу с помощью отладчика КР580 (см.ниже), что и дало возможность получить проверенный код подпрограмм F836/39 для ПЗУ.

Удалось выяснить, что если отладчик КР580 работает в ОЗУ выше 8000, но стек стоит в основном ОЗУ (что сильно снижает ценность отладчика), то глюка с кодом RST не происходит. Глюка с кодом RST не происходит также, если ОЗУ 8400 - некоммутируемое. Т.е хотя коммутация ни в отладчике, ни в трассируемой программе не задействована, она влияет.

Вы настаиваете, что ошибка в отладчике. Это не так. Он успешно прошёл тестирование в течение 40 лет. Так что, на самом деле ошибка в эмуляторе.

В качестве примера, я привёл программу теста работы оконного диспетчера, точнее тех подпрограмм, что я хотел иметь в ПЗУ F800. Причём программу неотлаженную, т.к не на чем было отлаживать. Просто именно на этой программе, я столкнулся с неработоспособностью отладчика. Точку останова для проверки отладчика я задаю задолго до коммутации ОЗУ в окне. Поэтому в качестве подопытной программы, может использоваться любая программа в основном ОЗУ. По директиве отладчика Gstart,stop происходит искажение отлаживаемой программы в точке останова.

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

Пока перетранслировал отладчик для ПЗУ E000, сделав стек на 7000. C его помощью можно отлаживать программы, что ставят стек на 7600 или рядом. Когда ошибка эмулятора будет устранена, странслируйте себе нормальную версию.

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

Чтобы трассировать и найти точку улёта я пользовался встроенным отладчиком эмулятора. А как же иначе? Программным отладчиком это не сделать. Но и отладчиком эмулятора трассировать не удалось.

В итоге мне удалось отладить тест ОЗУ и теперь он работает. Т.е получены работающие подпрограммы F836/39, причём они такие же как в ОРИОНЕ. А по логике работы даже лучше, т.к в кажлой банке не 60К, а 64К. Однако объём кода этих подпрограмм (75 байтов) и, соответственно, скорость их работы удручают.

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

Однако такие затраты объёма ПЗУ и потеря скорости оправданы. Т.к это существенно упрощает адаптацию, ведь драйверы такого эл.диска давно имеются. Данные подпрограммы пока поддерживают только 4 банки ОЗУ. Но этого уже достаточно для работы любых ДОС.

Твой отладчик также пользуется стеком. И частично стеком программы. В частности, это происходит при срабатывании точки останова. С какого адреса продолжать трассировку, отладчик читает из стека трассируемой программы после выполнения RST. А если последней была команда переключения банки, и стек был в переключаемой области, то читаются случайные данные.

Это не мой отладчик. Это отладчик Гарри Килделла из 1977 года, называемый Dinamic Debugging Tool.

Отладчик в точке останова (точка VEC38) действительно читает из стека отлаживаемой программы POP-ом, чтобы получить адрес останова. Этот считанный из стека адрес отладчик уменьшает на 1 и восстанавливает по этому адресу старое содержимое этой ячейки (код программы в точке останова). Если бы это было случайное число, то оно отображалось бы как другой адрес текущей команды. И легко обнаружилось бы. Считанный из стека адрес верный. Просто не происходит физической записи по этому адресу. Ошибка не программная.

И кстати, не все файлы содержат мусор после контрольной суммы. Некоторые из файлов вполне корректны

Это уже готовые файлы, т.е те, что уже не меняются после очередной трансляции. В них я подставляю КС и удаляю ненужные байты (чтобы сократить RAR-архив). А в тех программах, что перетранслируются, в качестве КС стоят два байта FF. Т.к Microsoft ассемблер 1982 года не умеет считать контрольную сумму полученного объектного кода по F82A и подставлять результат в объектный код. А вот самодельный ассемблер это может.

Ctrl+Shift+F8 выполнить без трассировки, пока не произойдёт RET при значении стека выше текущего положения, т.е. выполнить до выхода из подпрограммы (весьма полезная фича)

Что делает Shift+F8 экспериментальным путём я установил, а про Ctrl+Shift+F8 решил, что это - то же самое. Полезное свойство. В программах иногда POP для сброса адреса возврата удобен. Но были извращенцы, что доводят эту идею до абсурда. И это плохой стиль программирования.

Но одной клавишей это делать привычнее. При трассировке ставишь пальцы на T и P и быстро-быстро жмёшь на них соответственно коду. А если с SHIFT-ом, то это менее удобно. И как в эмуляторе B2M Вы сделаете команду T200 или U200, чтобы прогнать ровно 200 команд с трассировкой или без? Кстати при большом числе, результаты трассировки выводятся только для 24 последних команд, так что долгой задержки нет.

Для быстрого перемещения в окнах кода и дампа есть клавишная комбинация Ctrl+G. Кстати, до недавнего времени не знал, что в диалоге по клавише F1, в котором выводится подсказка по клавишам эмулятора, текст сместился. На XP было нормально

У меня Win XP, но несмотря на это, HELP отладчика эмулятора выводится некрасиво, с переносами строк. Это происходит, если задан другой размер фонтов в меню настройки "Свойства:Экран/Оформление/Дополнительно/Дополнительное_оформление" . Что всегда и делается, ибо мизерными буковками при стандартной настройке легко испортить зрение. Сочетанием Control+G я, естественно, пользовался, т.к читать умею.

В отладчике эмулятора не хватает команды для пропуска текущей команды без её прогона. Так, понаставив команд HALT, мы останавливаемся в нужных точках, но чтобы пропустить команду HALT приходится вручную корректировать регистр PC. По HALT нужен автоматический вылет в отладчик, ведь в РК86 прерываний нет и не будет, иначе это просто завис. В моих эмуляторах есть команды STOP N. И при останове по STOP я вижу в какой точке произошёл останов, т.к отображется номер этой точки. А с голым HALT отлаживать программу гораздо тяжелее. Кстати почему при отображении окна отладчика клик на кнопке с красным кружком не работает? Это противоречит правилу - всё для удобства пользователя.

Почему при остановке по HALT содержимое PC показывает следующий адрес, а не адрес HALT. Подсветка жёлтым стоит на HALT, а в регистре PC другой адрес. По нажатию <F5> отладчик пытается выполнить именно команду HALT, а не следующую команду. Поэтому в стопе по HALT, в PC должен стоять адрес HALT, а не адрес следующей команды. Посмотрите другие отладчики.

Чтобы продолжить после HALT приходится набирать в PC тот же самый адрес, что уже и так стоит в PC. Это совсем нелогично. И дико раздражает необходимость вводить префикс '0x'. Это почти издевательство над пользователями. Когда голова забита мыслями о программе, то думать о префиксах '0x' некогда.

Как посмотреть дамп ОЗУ в окне дампа? В HELP-е ни слова не сказано как изменить адрес дампа. Поэтому дамп приходится смотреть как листинг, задавая его адрес по ^G. Или же полчаса ждать пока в ходе ролика дампа адрес дойдёт до 8400.

Как забить код HALT на NOP? Что это за отладчик, если модифицировать программу приходится в машинных кодах в окне дампа? И дампов должно быть два. Или же, - как только я кликну на регистр HL, то в окне дампа должен появиться дамп памяти куда указывает HL.

В ранее выложенной версии ПЗУ F800 для Z80 неотлаженные, т.е абсолютно дохлые подпрограммы F836/39. Поэтому выкладываю версию с уже исправленными подпрограммами. Отладчик от ИРИШИ также иной версии (в директиве L есть команды Z80).

Теперь надо решить проблему как две подпрограммы F836/39 с общим размером 75 байтов уместить в ПЗУ F800 для КР580, где с трудом удалось "уплющить" объём кода всего на десяток байтов. Если выкинуть директиву X, а директиву G упростить (убрав из неё зачатки отладчика, т.е возможность задания стоп-точки, что задаётся вторым параметром), то выигрыш составит ~70 байт. Надо выкинуть ещё какую-то директиву. Есть предложения? Видимо придётся выкинуть директиву R.

Сегодня вечером попробую сделать такое ПЗУ для КР580, а чуть позже выложу CP/M для РК86 из 1994, что работает в расширенном ОЗУ и имеет TPA почти 29К.

[Vladimir_S]

Куда ставить static RAM?

Динамическое ОЗУ убрать вообще нахрен.

[Pyk]

barsik, потестировал немного разные варианты Мониторов и РК-ДОС у себя в эмуляторе.

Что касается мониторов, то не заметил проблем ни с Z80-вариантом, ни с совместимым с Z80. На первый взгляд все работает. В то время как с оригинальным неадаптированным наблюдаются проблемы с выводом на экран.

РК-ДОС. Оригинальная версия, та, что была в журнале, никак не адаптированная, на первый взгляд работает нормально. Но это с включенной поддержкой обращения к памяти как к портам (там в коде повсюду IN/OUT, без этого даже пробовать бессмысленно). Что, кроме IN/OUT там такого использовалось, что делало ее несовместимой с Z80? Могу потестировать.
Скрин:


Версия без использования Ready. В принципе, работает, но почему-то при выводе списка файлов не происходит возврат каретки и перевод строки, причем так с любыми Мониторами:


С версией же с использованием Ready все еще хуже: при попытке вывода содержимого директории по DIR, похоже, в начало экранной области попадают байты из диапазона F0-FF, и изображение срывается:


До срыва изображения можно успеть заметить, что список файлов начинает выводиться так же, как и на предыдущем скриншоте - без переводов строки. Кстати, если DIR не делать, то запустить с дискеты что-то вполне можно.

P.S. Basic Plus не работает на Z80, кстати...

[barsik]

РК-ДОС. Оригинальная версия, та, что была в журнале

RK-DOS не было в журнале РАДИО, а там была только реклама МП "Лианозово", где можно было купить эту ДОС. В каком журнале и когда публиковали RK-DOS?

Что, кроме IN/OUT там такого использовалось, что делало ее несовместимой с Z80?

Чтобы увидеть, что изменено в исходниках RK-DOS сделайте в текстовом редакторе поиск '****' и слова 'W_INC'. Вообще все изменения помечены, как минимум так: '; *'. Т.е можно искать точку с запятой, пробел и звёздочку (астерикс).

Что касается мониторов, то не заметил проблем ни с Z80-вариантом, ни с совместимым с Z80

Вообще-то, если у Вас эмулируется базовая архитектура, то с этими ПЗУ должен быть какой-нибудь глюк.

Т.к в этих ПЗУ по WBOOT (а для РК86 WBOOT это и есть вход в CCP) делается инициализация доп.ППА F100 (все порты на вывод) и по адресу F102 (т.е в порт C) записывается число 2. Иначе в окне 8400...BFFF оказывается включённым основное ОЗУ и при попытке использовать ОЗУ 8400 портится программа в основном ОЗУ. Таким образом при записи на F100..F103 на базовом РК86 мы попадаем в ДМА ВТ57, что адресуется по адресам E000...FFFF. И ожидаю, что режим ПДП изменится и будет улёт.

Но проверить это реально не могу, т.к во-первых, у меня с 1993 стоит дешифратор на адрес F000, как делается при установке РК-КНГМД, а во-вторых, мой РК86 дохлый и заняться его ремонтом в ближайшее время не имею возможности и желания. Т.к жаль тратить время на РК86, - сейчас мне интереснее ИРИША, а РК86, сейчас я рассматриваю лишь как источник программ для ИРИШИ. Но через некоторое время я собираюсь поставить на РК86 процессор Z80 и подключить к нему дохлый винчестер (в смысле уже не пригодный для IBM PC).

Если в Вашем эмуляторе ещё нет "верхнего ОЗУ", просто забейте в исходнике ПЗУ F800 инициализацию доп.ППА, а ещё лучше просто верните адрес доп.ППА на стандартные A000. Тогда на реальном базовом РК86 без РК-КНГМД конфликта с ДМА ВТ57 не будет.

В эмуляторе переключение кусков в ОЗУ в окне 8400...BFFF сделать сложнее, но просто включить в этом окне некоммутируемое ОЗУ намного проще (именно так сделано в моём эмуляторе РК на PC, а в эмуляторе РК на ОРИОНЕ расширенного ОЗУ вообще нет, только 32К, т.к в ОРИОНЕ сам код эмулятора расположен в ОЗУ 8000...BFFF).

почему-то при выводе списка файлов не происходит возврат каретки и перевод строки

Вероятно, DIR дохлый из-за того, что я что-то нарушил при модификации. В версиях для ОРИОНА команда DIR была доработана, чтобы список файлов выдавался не в одну колонку (что идиотизм), а в 2 или 3 колонки (в зависимости от числа символов в строке), т.е чтобы можно было видеть все файлы, если их на диске больше, чем 24.

Я попозже странслирую те же версии с "родным" DIR-ом или посмотрю что там, подставив этот DIR в версию РК-ДОС для эмулятора РК86 на ОРИОНЕ (т.к моя версия эмулятора РК86 на PC не поддерживает РК-ДОС, точнее не было версии RK-DOS). В этом DIR должно было проверяться число символов в строке, т.к при разных драйверах RK-DOS м.быть 48/55/64 символов в строке, и в зависимости от этого в команде DIR менялось число колонок в которых выводится каталог.

Могу скинуть версию CP/M РК86 работающую с РК-КНГМД. Хотя она и для "верхнего ОЗУ". Так как для основного ОЗУ CP/M вообще не имеет смысла (т.к она сама занимает 10К, оставляя для программ всего ~17 кб). Но для эксперимента (в смысле проверки верности эмуляции РК-КНГМД в Вашем эмуляторе) её можно странслировать в основное ОЗУ.

Basic Plus не работает на Z80

Все бейсики производные от бэйсика МИКРО-80 на процессоре Z80 не работают. Хорошо бы, если бы кто-нибудь занялся этой проблемой. Что там надо менять знает только В.Пушков, который исправил бэйсик ОРИОНА для Z80. Меня бэйсик никогда не волновал, так что ничего не знаю на эту тему.

[Advertiser]

[Pyk]

barsik, итак, по-порядку:

1. Действительно, листинга РКДОС в журнале не было. Были лишь ссылки на нее и контроллер, предназначенный для работы с ней. Это моя неточность.

2. Смотрю, кроме обращений к портам там еще много где меняется INR M на LD A, (HL) \ INC A. Смысл последней замены от меня пока ускользает, видимо по каким-то причинам нужно, чтобы в памяти по адресу (HL) оставалось неизменное значение? За что вообще W_INC отвечает и при чем тут Z80, пока не понимаю; если поясните, буду благодарен. Как я уже писал, после разрешения обращения к устройствам как к портам я проблем в работе РКДОС не заметил, не вижу пока в чем может быть дело, и в исходнике - команд JP PE / JP PO там нет...

3. Тестировал, действительно, на базовой архитектуре. Глюков не заметил, так как в базовой архитектуре порт F102 попадает в порт канала 1 ПДП, который на РК не используется. Расширенную архитектуру готов сделать, можно только резюмировать, правильно ли я понял, что где находится?
- 8000-83FF - осн. ППА
- 8400-BFFF - доп./ основное ОЗУ, переключаемое битом D0 порта C дополительного ППА. если d0=0, то совпадает с основным ОЗУ по адресам 400-3FFF (не уверен, что правильно понял)
- C000-DFFF - вг75
- E000-EFFF - вт57 / РКДОС
- F100-F1FF - доп. ППА
- F200-F2FF - ПИТ
- F300-F3FF - порт переключения банок основного ОЗУ... тут не понял, совпадает ли вторая банка с тем, что отображается на 8400-BFFF когда D0=1 либо это самостоятельная область памяти?
- F800-FFFF - ПДП/ПЗУ
Не понял насчет переключения шрифтов битом d7. Вроде бы ранее было предложено менять шрифты атрибутом rvv? Альтернативный шрифт в бинарном виде пока недоступен? Да и основной, смотрю, тоже высотой 8 строк, а не 10...

4. От CP/M не откажусь, можно посмотреть. По возможности было бы неплохо еще готовые образы дисков для нее. Перекомпилировать для основного ОЗУ нет необходимости, добавить "верхнее" не проблема.

P.S. Кстати, формат .rk без синхробайта - как раз мой, а вот gam с ведущим синхробайтом был использован А. Деминым (aka begoon)...

[АлександрПП]

В каком журнале и когда публиковали RK-DOS?

Это не то?
https://yadi.sk/d/9_8GUIyQ3AXdQK

[uart]

Микроша круче. Она и с РК-ДОС совместима, и целиком область 8000-BFFF свободна. Шрифт опять же второй уже есть. Чего к РК-86 так привязались?

[barsik]

За что вообще W_INC отвечает и при чем тут Z80, пока не понимаю; если поясните, буду благодарен

W_INC (with INC) значит с командами INC (HL), когда HL адресуется в порт. INC (HL) делает считывание из порта и тут же запись в него. Это работает на РК86, но не всегда работает на ОРИОНЕ, даже с тактом всего в 2.5 МГЦ. А при Z80 в ОРИОНЕ такт всегда 5 МГЦ, неважно сделана схема ТУРБО с WAIT (142%) или ТУРБО-200%. ВВ55 не любит когда два обращения в порт происходят сразу друг за другом. Нужна пауза между обращениями. Поэтому была применена условная трансляция, чтобы иметь оба варианта. По этим же соображениям многие константы были увеличены вдвое.

8000...83FF - ППА клавиатуры
8400...BFFF - доп.ОЗУ, переключаемое битами D0...D5 порта C доп.ППА
C000...DFFF - ВГ75
E000...EFFF - ВТ57 / ПЗУ с RK-DOS или другим кодом
F000...F0FF - РК-КНГМД (факультативно)
F100...F1FF - доп.ППА (тот что называется D14)
F200...F2FF - ВИ53 (факультативно)
F800...FFFF - ПДП/ПЗУ с ROM-BIOS

То, какое ОЗУ прокачивается в окне 8400...BFFF, зависит от физической реализации. Может быть совмещённое ОЗУ и две разных банки ОЗУ (РУ5+62256). Самый дешевый вариант это РУ5 и прокачка в окне 4-х сегментов из неё размером по 16К (хотя доступно лишь 15К из 16-ти). При этом отображаемые в окне 8400 сегменты с номерами 0 и 1 оказываются из основного ОЗУ с адресов 0400...3FFF и 4400...7FFF. Можно сделать так, чтобы при РУ5-тых было только два сегмента, т.е управление только битом D0, тогда это получается как будто есть 2 банки ОЗУ, одна - основное ОЗУ, другое - оконное, хотя физически всё в одной банке РУ5-тых. Но при РУ7-мых такой трюк не проходит, т.к 32К не являются половиной от 256К.

Но если ОЗУ - несовмещённое, т.е состоит из двух разных банок ОЗУ, то в окне 8400...BFFF никак не включить основное ОЗУ из РУ5-тых, там всегда включается ОЗУ из 62256 или W24257. Это программно может определить программа и соответственно назначить начальный адрес эл.диска, так что эл.диск не конфликтует с основным ОЗУ при любой физической конструкции.

В эмуляторе надо реализовать большое ОЗУ. А значит, это совмещённое ОЗУ в 288К с прокачкой всех 288 Кб в окне 8400...BFFF. Т.е сегменты 0 и 1 в окне 8400 должны быть совмещены с основным ОЗУ 0...7FFF. 288К, а не 256К потому что, из-за недоступности в окне в каждом куске в 16К участка в 1 кб, чтобы логически иметь 256К, физически надо иметь 288К, т.е 4 банки по 64К + ещё пол-банки 32К. А на реальном РК на РУ7-мых подпрограммами F836/39 в последней 3-тьей банке доступно лишь 48К из 64К, т.е всего 32+30*7=242К, что чуть больше, чем 241К физически доступных в ОРИОНЕ на РУ7-мых..

На реальном РК86 с РУ7 при чтении сегмента с номером 16 будет читаться кусок основного ОЗУ 0400...3FFF, т.к физически банки 4...7, 8...11, 12...15 и т.д, это тоже самое, что банки 0...3, т.к управление выбором сегмента только 4-мя битами (в КП11 всего 4 разряда).

Регистр, для пробы установленный по адресу F300, в эмуляторе B2M должен был переключать целую полубанку в адресах 0...7FFF, по принципу цельнобанковой коммутации ОРИОНА. Т.о при РУ5-тых получалось две полубанки, а при РУ7 - 8 полубанок.

Никто такого реально никогда не имел. Хотя реализация при РУ5 самая простейшая из всех доработок. Если для коммутации использовать бит PC1 ППА клавиатуры, то расход деталей - кусок проволоки. На адрес A15 у мультиплексора КП11 просто заводится бит. Сюжет заключается в том, что тогда есть доступ ко всему ОЗУ без потерь. Минусом такой архитектуры является то, что только подпрограммой из ПЗУ F800 можно читать и писать в дополнительных полубанках.

Однако иметь ОЗУ выше 8000 важнее, чем потеря ОЗУ в 6% при окне не кратном 8 Кб. Делать и окно на 8400 и цельно полу-банковую коммутацию по 32К одновременно - слишком громоздко. Хотя при наличии 62256, что включена двумя страницами в окне 8400...BFFF, имеющуюся на плате банку РУ5 разумно использовать целиком как две полубанки (т.к куска проволоки никому не жалко). Что даёт в сумме 94 (32+32+30) кб.

Не понял насчёт переключения шрифтов битом D7. Вроде бы ранее было предложено менять шрифты атрибутом RVV?

Атрибут RVV это ReVerseVideo и его всегда применяют для инверсии знакомест. А атрибуты HGLT, GPA1, GPA2 (General Purpose Attribute) могут использоваться произвольно. Во-первых одного атрибута для фонтов - мало. Считайте сами. Как минимум, нужен фонт для режима графики 192*100, нужен фонт с инверсией, нужен фонт КОИ-8 и базовый фонт. Поэтому управлять фонтами атрибутами не надо. Пусть атрибуты идут на цвет.

Управление инверсией атрибутом неудобно, т.к не позволяет использовать встроенный в ПЗУ драйвер вывода символов. В то время как инверсия за счёт фонта на порядок удобнее и проще. И главное позволяет иметь инверсные окна с рамками, что даёт программам совсем другой вид. Я использовал в своё время атрибут RVV для инверсии, но отказался. Но сама переделка для RVV на моём РК сделана и она ничему не мешала. И её надо иметь, потому что инверсия фонтом неполноценная и пригодна только для системных программ. Т.к число символов сокращается вдвое с 128 до 64 и остаются только латинские буквы.

Альтернативный шрифт в бинарном виде пока недоступен? Да и основной, смотрю, тоже высотой 8 строк, а не 10

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

Фонт с инверсией у меня есть в ПЗУ реального РК, надо лишь перенести на PC, есть также где-то в виде листинга в исходнике эмулятора. Но пока нечего смотреть с фонтом с инверсией, т.к это использовано только в НОРТОН-ах, а они только для ДОС.

С трудом сделал ROM-BIOS для КР580 с подпрограммами F836/39. После выкидывания директивы X и стоп точки в директиве G, освободилось почти 90 байт. За счёт этого удалось уместить подпрограммы F836/39 и ввести 2 новые команды. Доп.информация в начале листинга. Используйте этот ROM-BIOS в эмуляторе B2M. Версию ROM-BIOS для Z80 тоже обновлю, т.к нашёл способ выиграть ещё несколько байт. Обращайте внимание на число просмотров и на дату упаковки архива, а также даты в исходниках. Если число просмотров для давно выложенного RAR-файла равно 0, значит этот архив был обновлён, т.к всё устаревшее или дохлое в выложенных ранее RAR-файлах я удаляю или заменяю.

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

Микроша круче

Никто с этим спорить не может. Но "ещё не вечер"... Может быть и РК86 с дополнительным ОЗУ будет не хуже. Кстати, скажите, фонт в МИКРОШЕ более красивый 8*8 или её изготовители не додумались и оставили фонт такой же как в базовом РК - 6*8?

Чего вы так к РК86 привязались?

Люди пользуются реальной РК86, потому что её имеют. А в эмуляторе, потому что про РК86 что-то знают, а про МИКРОШУ и ПАРТНЁР никто ничего не знает, т.к это малораспространённые среди самодельщиков машины. Готовые промышленные ЭВМ покупали "отцы семейств", а радиолюбители РК86 делали себе сами. А так как на этом сайте больше радиолюбителей, то отсюда и "привязка" к РК86.

Хорошо, что Вы напомнили о МИКРОШЕ, т.к это связано с темой ПЗУ.

У меня программ от МИКРОШИ никогда не было, но в дистрибутиве EMU80 в 1999 я нашёл кучу программ от МИКРОШИ и убедился, что они не работают в моём эмуляторе РК86 на ОРИОНЕ, т.к в эмуляторе совсем иной код ПЗУ F800. Дело в том, что в МИКРОШЕ несовместимое с РК86 ПЗУ, даже по стандартным точкам. В частности WBOOT там не F86C, а F89D. Ну а внутренние точки вообще несовместимы, и также для МИКРОШИ полно глупых авторов, что лезут в нестантартные точки ПЗУ глубоко внутри ПЗУ F800. Идиотизм, ради экономии трёх байтов терять совместимсоть.

Обнаружил, что программы МИКРОШИ по большей части вообще наглые и неграмотные. Вместо того чтобы считать стек в HL и проверить старший байт, чтобы узнать ОЗУ 16К или 32К, там сдуру лезут в ПЗУ в то место где стоит команда LD SP,STACK и смотрят старший байт. Это идиотизм (что, кто-то не согласен?). Причём, т.к в РК86 и в МИКРОШЕ эти байты - в разных адресах, то сначала идиотским способом выясняется тип машины - это РК86 или МИКРОША?. Для чего смотрится куда идёт JMP с адреса F800. Если там стоит адрес F836, то это РК86, иначе - МИКРОША. Т.е программы МИКРОШИ сделанные универсальными, - "привязаны" к коду ПЗУ РК86.

Поэтому если использовать 100% совместимое, но не базовое ПЗУ F800, то программы МИКРОШИ успешно глюкаются на РК86. Исправление такой глупости конечно несложно, но неприятно. Теоретически, можно даже написать программку, которая ищет в коде программ МИКРОШИ команды которые считывают несколько популярных точек внутри ПЗУ F800, чтобы сделать вывод о том, МИКРОША это или РК86. Но вообще-то руки надо отрывать авторам таких программ. Всякий, кто "привязывается" к конкретному коду ПЗУ, - это явный "враг народа". Чтобы определить МИКРОША или РК86 надо тестировать где стоят В/У. Например, ППА легко определить. Также идентифицировать другие БИС несложно.