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

[barsik]

А чем не устраивает отладчик самого эмулятора? Всё равно разработку проще в эмуляторе делать

Без сомнения в эмуляторе делать отладку намного удобнее, чем в реале. Наверно отладчик в эмуляторе B2M хороший. Но у меня в эмуляторе РК на PC встроена загрузка отладчика ИРИШИ, т.к резидентный отладчик в кодах Z80, а не КР580 (хотя эмуляция КР580). Почему не иметь, если это не стоит никаких затрат труда? В моих эмуляторах тоже есть отладчики (даже в эмуляторе РК на ОРИОНЕ), хотя и не экранные. А т.к РК-ДОС в эмуляторе B2M нет, а ПЗУ для её установки есть, то что-же иное, кроме отладчика, разумно запихать в это ПЗУ?

Кстати, в отладчике эмулятора B2M нет встроенного миниассемблера, а мнемоники соответствуют процессору заданному конфигом. К тому же иногда иметь миниассемблер удобно. А если надо отлаживать что-то на КР580, тому кто ненавидит мнемоники Z80 (такие странные люди существуют)? А вообще, вероятно, для РК86 ничего лучше экранного отладчика 'DBG' С.В.Дрогайвера нет. Я попозже перетранслирую его для области 8400...BFFF. В моих эмуляторах РК он не работает, т.к меняет режимы ВГ75, а в эмуляторе B2M он работает.

Кстати, так и не разобрался пока как сделать в эмуляторе 2 фонта, переключаемых битом D7 доп.ППА. В конфиге АПОГЕЯ нашёл строки про переключения фонта (по-видимому выходом INTE).

fntmap : MemMap {
map[0][000-3FF]=font[2000]
map[1][000-3FF]=font[2400]
page=cpu.int
}

Но не понял, что за цифры (якобы смещения где-то) 2000 и 2400. И в случае, если это ПЗУ знаконенератора типа РФ2, то смещения д.быть 0000 и 0400? И не понятно что писать после символа '=' в строчке 'page='. И ведь как-то надо задать адрес регистра (порт с доп.ППА) и номер бита.

Однако сделать в окне 8400...BFFF две страницы ОЗУ из верхней памяти 565РУ5 (то что выше 8000) удалось без проблем. Для этого в конфиг-файле для РК86 надо сделать следующее:

В секции 'CPU' надо вставить строки

mem8400 : Memory {
size=8000
frame[0].size=3C00
frame[0].page=D14.portC[0]
}

D14 : K580ww55 {
}

А в секции 'mm'

map[0][8400-BFFF]=mem8400.frame[0]
map[1][C400-FFFF]=mem8400.frame[1]
map[0][F100-F1FF]=D14.data
map[0][F200-F2FF]=tim.data

Здесь порт доп.ППА перенесён на F100 (т.к размещение доп.устройств в области 8000...83FF считаю неудачным, - так можно делать для себя, но это пагубно для тех, у кого базовая архитектура, т.к у них будет попадание в ППА клавиатуры). Как видите таймер ВИ53 размещается на F200 (а в том конфиге, что на сайте B2M он был на A000, что может быть правильным для АПОГЕЯ или других, но неверно для РК86). С таким конфигом ОЗУ в окне 8400 коммутируется, но смущает то, что у всех других областей в секции 'mm' после слова 'map' стоит индекс 0. Не значит ли это, что при карте памяти 1, эти области станут вообще недоступны? Не надо ли строки относящиеся к другим областям продублировать с индекстом 1?

Непонятна строка

frame[0].page=D14.portC[0]

Точнее не ясны цифры в квадратных скобках. Насчет 'frame[0]' - это вообще полный мрак, а вот про 'portC[0]' предположительно это бит, который управляет конфигурацией (в данном случае тем, какое ОЗУ включается в окно заданного размера с заданного адреса). Но непонятно как быть если управляется не одним битом, а 4-мя битами, позволяя включать в окне любой кусок из 256 Кб. Чтобы отлаживать РК-ДОС или любую другую ДОС для РК86 в эмуляторе нужно иметь, как минимум, столько ОЗУ.

Но само удобство организации в эмуляторе доп.памяти впечатляет. В моих эмуляторах, чтобы добавить что-то в архитектуре, надо несколько дней усердно модифицировать ассемблерный исходник и затем долго отлаживать. Эмулятор B2M очень удобен для того, чтобы опробовать в нём разные варианты архитектуры, с целью выбрать оптимальный вариант. В частности, вариант РУ5 + две 62256, где РУ5-тые используются как две пол-банки, а на 62256 организовано "верхнее" ОЗУ 8400. Есть и второй вариант расширения ОЗУ - это на 565РУ7.

Собираюсь "организовать" таким образом в эмуляторе B2M поддержку динамических ОЗУ РУ7, с целью иметь в самом РК86 электронный диск, т.к в моём реальном РК86 нет дисковода или других устройств массовой внешней памяти. И тем самым пользоваться РК могу только закачивая в него по линии из IBM PC по одному файлу. А так как обмен (без ВВ51 или другой аппаратуры, с расходом деталей лишь в провода) программный и оттого медленный (всего 100 байт в секунду), то оперативная закачка программ не годится. Наличие подключенного по стандартному програмному интерфейсу эл.диска позволит отлаживать ДОС и программы в эмуляторе для любого типа железа.

Однако при окне доступа в 15К, из каждых 16К впустую теряется 1К, т.е недоступно 14 Кб полезного объёма РУ7-мых. Таким образом максимальный эл.диск будет (256-32-16):16*15= 195 кб. Т.е для программ имеем 32 кб основного ОЗУ и 15 Кб верхнего ОЗУ, а дополнительно имеем 195 Кб электронного диска.

С целью экономии полезнее иметь окно доступа в 8 Кб, что избавляет от потерь. Однако для программ выгодно иметь как можно больше сплошного ОЗУ, т.е важно иметь окно максимального размера в 15К. Поэтому напрашивается более извращенная архитектура, когда есть ОЗУ 8400...BFFF, но коммутируемое окно (окно прокачки) ограничено областью в 8К. Тогда в области 8400...9FFF расположено некоммутируемое ОЗУ, а в окне прокачки A000...BFFF можно включить любой кусок в 8К из 256К. Увы, это требует 5-ти разрядного регистра и для переключения требуется уже две КП11, что приводит к громоздкости схемы и делает её неприемлемой для доработки на базовом РК86 (т.е проводками).

Вариант расширения ОЗУ не играет роли, т.к важно лишь, чтобы в окне 8400...BFFF было 15 кб верхнего ОЗУ. А всё остальное ОЗУ - факультативное (необязательное) и доступ к нему должен происходить только стандартными подпрограммами ПЗУ F800, также как это сделано в ОРИОНЕ. Тогда схема и тип носителя доп.ОЗУ не играет роли. Это может быть как любой тип памяти в самом компьютере, так и внешняя плата эл.диска (256К...1 Мб). Тогда любая ДОС может иметь эл.диск и будет совместима с любым РК86 имеющим количество ОЗУ достаточное для организации эл.диска, внешнюю карту флэш-памяти или внешнюю плату эл.диска (на статических ОЗУ или на РУ7).

Поэтому введя в эмулятор любым способом доп.ОЗУ размером достаточным для эл.диска, можно перетранслировать для РК86 кучу разных ДОС и получить доступ к новым программам. Причём, эти ДОС будут заведомо работать на любом железе РК86 (т.к, как указано выше ДОС работают с эл.диском только подпрограммами F836/39). Всё, что требуется от пользователя это ввести эти две подпрограммы в свои ПЗУ F800, которые работают с конкретным железом пользователя.

А почему в эмуляторе для КР580 не происходит останова, если встретилась команда Z80?

Отсюда и следующий вопрос. Как Вы обрабатываете недокумментированные команды КР580?

Обслуживается ли матричная клавиатура в смысле обнаружения РК-программой одновременного нажатия двух клавиш (не в плане спец.клавиша + символьная клавиша, а две символьных клавиши нажатые одновременно)?

В моих эмуляторах программа Z80 может использовать функции эмулятора, которые вызываются командой INIR (в рег.А номер функции). В частности Z80-программа может читать/писать файлы с винчестера, считывать каталог, переименовывать и т.п. (может даже низкоуровнево работать с секторами на винчестре, вплоть до формата, печатать на принтере и даже читать с линии через порт принтера).

Это позволяло написать в кодах Z80 оболочку, что делает обмен файлами между ДОС в эмуляторе и винчестером PC. В моём эмуляторе РК86 на PC есть 2 подпрограммы для организации ДОС - читать/писать сектор 512 байт с внешнего устройства (это или VDISK 512K из ОЗУ IBM PC или дисковый файл на винчестере). Благодаря этому, код эмулятора при использовании разных ДОС и разного железа менять не требуется. Поэтому можно иметь любую ДОС, и эмуляция "железа" при этом не требуется. Поэтому мне не требовалось эмулировать ни ВГ93, ни РК-КНГМД.

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

[Advertiser]

[b2m]

Но не понял, что за цифры (якобы смещения где-то) 2000 и 2400.

Это смещения шрифтов в файле symgen.bin (я его взял из эмулятора Пыхонина). В этом файле несколько шрифтов, в том числе и для Партнёра и др. компьютеров.

map[1][C400-FFFF]=mem8400.frame[1]

Эта строчка явно лишняя. Во-первых, карту памяти номер 1 (т.е. map[1]) ты явно не задумывал. Да и второй вариант доступа через окно тоже (mem8400.frame[1]). frame[1] имеет смысл, если нужно адресоваться к памяти через окно другого размера, или этих окон несколько, т.е. номер текущей страницы задаётся для каждого окна.

Непонятна строка

frame[0].page=D14.portC[0]

Ну что тут непонятного: номер текущей страницы окна 0 будет равен значению бита 0 порта С устройства D14 (описанного в когфиге как ВВ55).

Насчет 'frame[0]' - это вообще полный мрак

Внутри эмулятора это объект, который предоставляет доступ к памяти через окно. Таких объектов может быть несколько, поэтому есть индекс. У этого объекта есть размер окна size и номер текущей страницы page. А само имя frame[0] предоставляет интерфейс к памяти, т.е. содержимому памяти в окне. Такой объект есть только у устройства, описанного в конфиге как Memory.

Но непонятно как быть если управляется не одним битом, а 4-мя битами

Тогда я бы написал frame[0].page=D14.portC[0-3]

так и не разобрался пока как сделать в эмуляторе 2 фонта, переключаемых битом D7 доп.ППА

Рассмотрим, как задан фонт в Радио-86РК сейчас:

font : Memory {
  rom="symgen.bin"
}

crt : K580wg75 {
  dma=dma[2]
  font=font[0C00]
  hilight=crt.ggh
}

Здесь устройство crt это ВГ75, у него есть свойство font, которое связано с неким устройством font, при этом указано ещё и смещение 0C00. Устройство font описано как память (Memory), а свойством rom мы указываем, что это ПЗУ и содержимое нужно грузить из файла symgen.bin

Теперь мы хотим добавить свой переключаемый фонт. Допустим он будет в файле Radio/myfont.bin (пусть будет в подкаталоге Radio). Мы соеденим его через мультиплексор fntmap, и у нас есть ещё дополнительная ВВ55, которая в конфиге называется D14.

font : Memory {
  rom="Radio/myfont.bin"
}

fntmap : MemMap {
  map[0][000-3FF]=font[0000]
  map[1][000-3FF]=font[0400]
  page=D14.portC[7]
}

crt : K580wg75 {
  dma=dma[2]
  font=fntmap
  hilight=crt.ggh
}

D14 : K580ww55 {
}

Свойство page у fntmap указывает, откуда брать номер текущей карты памяти. В каждой карте область 000-3FF связана со шрифтом с нужным смещением в файле. То есть, когда меняется значение бита 7 порта С микросхемы D14, то изменится и содержимое области памяти 000-3FF. А ВГ75 в данном случае именно из этой области и будет считывать данные шрифта.

Однако это устаревший способ. С момента появления объекта frame у Memory от мультиплексора MemMap можно отказаться:

font : Memory {
  rom="Radio/myfont.bin"
  frame[0].size=400
  frame[0].page=D14.portC[7]
}

crt : K580wg75 {
  dma=dma[2]
  font=font.frame[0]
  hilight=crt.ggh
}

D14 : K580ww55 {
}

Кстати, левая часть равенства, которое находится внутри секции (обозначенной фигурными скобками) всегда дополняется слева именем секции. То есть следующие две записи эквивалентны:

crt : K580wg75 {
  font=font.frame[0]
}

crt : K580wg75 {
}
crt.font=font.frame[0]