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

[Vladimir_S]

А доп.ППА это общее устройство и оно может использоваться по любому.

Я когда в далеких восьмидесятых сделал программатор на РКшке, наверно с неделю по неопытности убил выискивая почему портится последняя программируемая ячейка. У меня программирующее напряжение включалось единицей.

[Advertiser]

[barsik]

Спасибо B2M. Отличный эмулятор. По предоставленной Вами информации удалось сделать в эмуляторе РК86 и два фонта и 256 кб ОЗУ, прокачиваемого в окне 8400...BFFF. Написал тест расширенного ОЗУ и это ОЗУ оказалось исправно. Интересно, какое это ОЗУ? Думаю, что это ОЗУ не из конвенциональной памяти (не ОЗУ XT, адресуемое до 640 кб), а ОЗУ защищённого режима, и поэтому можно без конца расширять это ОЗУ в эмуляторе РК86. Сейчас закончу писать и попробую сделать в эмуляторе РК86 512 кб, т.к чем больше ОЗУ, тем приятнее.

Однако "ложку дёгтя" добавил тот факт, что фонт всего-лишь 6*8, в то время, как на моём реальном РК86 фонт 8*10 и я привык, что никаких двух линий растра разделяющих строки нет. Ну, я понимаю, что для близости с реальным базовым РК86 надо было ввести эти две линии растра между строками. Но фонт-то зачем уродовать? Зрение-то у всех своё. С эстетической точки зрения лучше было бы применить более красивый фонт 8*8. Кроме того, реальный фонт от реального РК86 не годится, т.к реальный фонт инверсный, а у Вас в эмуляторе фонт неинверсный. Поэтому подставить реальный фонт нельзя, что создаёт лишние неудобства пользователю и к тому-же, "разлучает с реальностью". Поэтому не смог сразу использовать свой фонт с инверсией и псевдографикой. Придётся его вручную переделывать из матрицы 8*10 в матрицу 6*8.

Очень большое достижение, что Вы проэмулировали команды ВГ75. В своём эмуляторе, в своё время, я это делать не стал, т.к решил, что это слишком сложно. Однако, Вы не точно ВГ75 проэмулировали. Я использовал на РК86 монитор (ROM-BIOS), который отличался от базового двумя байтами в п/п-мме PUSK_VG, отчего курсор был не крошечной мигающей чёрточкой толщиной в 1 пиксель, а мигающим прямоугольником 6*8, что визуально намного приятнее. Если в моих исходниках поставить флаг ORIG=0, то будет такой курсор. Но на Вашем эмуляторе это не получается. Курсор получается не сплошной, а какой-то мусор.

Ну вот, теперь можно с удобством сделать для РК86 RK-DOS с поддержкой эл.диска и реального дисковода. Эл.диск - привод 'A:', а дисковод - привод 'B:'. Если ОЗУ для эл.диска нет, то дисковод становится приводом 'A:', а эл.диска нет. Хотя может быть и есть, но очень-очень маленький, размером в 15 кб из ОЗУ в области 8400...BFFF. В реале даже небольшой эл.диск ценен, т.к существенно облегчает копирование файлов на дискетах.

Однако, B2M не расслабляйтесь ещё. Ещё полно недоработок. Во-первых, в реальном РК86, то ОЗУ, что включается в окно 8400...BFFF при записи в порт управления F102 числа 0, это основное ОЗУ с адресов 400...3FFF. И соответственно, при числе 1 - будет отображён участок 4400...7FFF. А в эмуляторе отображается не основное ОЗУ, а какое-то другое ОЗУ, так, как будто мы для основного ОЗУ используем пол-банки РУ5-тых, а для верхнего ОЗУ имеем отдельную банку РУ7-мых. Реальный РК86 столько параллельных банок не потянет, т.к ОЗУ не имеет буферов, отчего возможна только одна банка динамических ОЗУ. Поэтому при числах 0 и 1 в окне 8400 отображается то же самое ОЗУ, что является в РК86 базовым ОЗУ 0...7FFF.

Не подскажете, как совместить основное ОЗУ и ОЗУ оконного диспетчера?

Кроме того, мне не удалось реализовать в архитектуре РК86 в эмуляторе цельно пол-банковую коммутацию ОЗУ. Это когда есть регистр F300 и занося в него порядковый номер пол-банки, во всём основном ОЗУ 0...7FFF включается ОЗУ нужной пол-банки. Это как в ОРИОНЕ, но коммутируется не 60К, а 32К и нет некоммутируемой области F000...F3FF (а зачем некоммутируемая область, если при нужде её легко про-имитировать, записав в обе пол-банки одинаковый код). Думаю, что для реализации такой полу-банковой архитектуры уже понадобится задействовать map[0,1,2,3...FF].

Прилагаю тот конфиг, с которым мне удалось получить два фонта в знакогенераторе и дополнительные 256К ОЗУ (кроме основных 32К) прокачиваемые в окне 8400...BFFF (управление портом С ППА по адресу F100). Здесь тип CPU стоит Z80, поэтому используйте совместимый с Z80 монитор (ROM-BIOS) или измените тип процессора в конфиге и соответственно имя ПЗУ F800 с ZBIOS.ROM на BIOS.ROM. Здесь вместо странного фонта знакогенератора SYMGEN.BIN используется файл 2KFONT.DAT, но вы можете подставить свой фонт от реального РК86 (даже всего 1 кб размером). Если Ваш фонт РК - оригинал, т.е инвертированный, то Вы увидите всё в инверсии (причём синхронизация не сорвётся, как в реальном РК86). Не забудьте убедиться, что в секции 'cas' адреса входов в подпрограммы RDBYTE, WRBYTE и адрес возврата из них (@BAK) соответствуют Вашему ПЗУ F800, иначе при директивах I и O будет завис. Чтобы не заботиться об этих адресах используйте тот монитор, что выложен в моём предыдущем посте (транслировать с ключом B2M=0 (тогда адрес выхода из TAPE-подпрограмм как раз и будет FC9D вместо базовых FCA4). Обратите внимание на первую строчку CPUclock=. Если Вам не хватает скорости 1.77 МГЦ, то можно сделать себе и побольше. А если игра работает слишком быстро (что как раз обычно и имеет место), то ставьте клок поменьше.

Скрытый текст

main.CPUClock=1777777Hz
main.Caption="Ðàäèî-86ÐÊ"

CPU : Z80 {
debug=cas
mem=mm
pc=F800
port.maptomem=1
}

mem1 : Memory {
size=8000
}

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


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

bios : Memory {
rom="Radio\ZBIOS.ROM"
}

memE000 : Memory {
rom="Radio\IRISHA.ROM"
}

D14 : K580ww55 {
}

sys : K580ww55 {
portA=kbd.~mask
portB=kbd.~data
portC[0]=cas.record
portC[4]=cas.playback
portC[5-7]=kbd.~data2
}

tim : K580wi53 {
clock[0].rate=1/1
clock[1].rate=1/1
clock[2]=tim.out[1]
~gate[0]=tim.out[2]
gate[1].value=1
gate[2].value=1
}

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

dma : K580wt57 {
mem=mem1
}

mm : MemMap {
map[0][0000-7FFF]=mem1[0000]
map[0][8000-83FF]=sys.data
map[0][C000-DFFF]=crt.data
map[0][E000-FFFF].wo=dma.data
map[0][E000-EFFF].ro=memE000[0000]
map[0][F100-F1FF]=D14.data
map[0][F200-F2FF]=tim.data
map[0][F800-FFFF].ro=bios[0000]
map[0][8400-BFFF]=mem8400.frame[0]
}

kbd : Keyboard {
layout="Radio\layout.kbd"
}

beep : beep {
input=cpu.int
input2=sys.portC[0]
input[0]=tim.out[0]
}

cas : tape-recorder {
biproc[FB98-FC9D]=rk
boproc[FC46-FC9D]=rk
}

[свернуть]

[b2m]

Думаю, что это ОЗУ не из конвенциональной памяти (не ОЗУ XT, адресуемое до 640 кб), а ОЗУ защищённого режима

Под виндой нет такой границы - 640кб, и конвенциональной памяти тоже нет. Начиная с 64-х битных версий у процессора нет даже виртуального V86 режима (это который для эмуляции старого ДОСа, изначально работающего в real mode).

С эстетической точки зрения лучше было бы применить более красивый фонт 8*8

Например в конфиге Роботрона фонт 8х12. Достигается указанием fontwidth и fontheight. По-умолчанию используется 6x8, так что достаточно указать fontwidth.

реальный фонт от реального РК86 не годится, т.к реальный фонт инверсный

Эмулятор может инвертировать загружаемый ROM, нужно только писать не rom="...", а ~rom="..."

Однако, Вы не точно ВГ75 проэмулировали.

Да, вроде с курсором я не угадал. Сейчас уже трудно всё вспомнить, надо в исходник опять вникать.

Не подскажете, как совместить основное ОЗУ и ОЗУ оконного диспетчера?

Отказаться от дополнительной памяти mem8400, увеличить размер основной памяти mem1 и перенести туда frame[0], размер окна сделать 4000, ссылку на окно сделать со смещением: map[0][8400-BFFF]=mem1.frame[0][0400]

Кроме того, мне не удалось реализовать в архитектуре РК86 в эмуляторе цельно пол-банковую коммутацию ОЗУ. Это когда есть регистр F300 и занося в него порядковый номер пол-банки, во всём основном ОЗУ 0...7FFF включается ОЗУ нужной пол-банки.

Вот тут пригодится ещё одно окно: map[0][0000-7FFF]=mem1.frame[1], соответственно нужно будет задать размер frame[1].size=8000 и frame[1].page=...
То есть примерно так (не проверял, так что работу не гарантирую):

mem1 : Memory {
  size=40000
  frame[0].size=4000
  frame[0].page=D14.portC[0-3]
  frame[1].size=8000
}

mm : MemMap {
  map[0][0000-7FFF]=mem1.frame[1]
  map[0][8000-83FF]=sys.data
  map[0][8400-BFFF]=mem1.frame[0][0400]
  map[0][C000-DFFF]=crt.data
  map[0][E000-EFFF].wo=dma.data
  map[0][E000-EFFF].ro=memE000[0000]
  map[0][F100-F1FF]=D14.data
  map[0][F200-F2FF]=tim.data
  map[0][F300-F3FF]=mem1.frame[1].page
  map[0][F800-FFFF].wo=dma.data
  map[0][F800-FFFF].ro=bios[0000]
}

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

port.maptomem=1

Забыл сказать, это фича только ВМ80, для процессора Z80 эту строчку можно удалить.

[barsik]

port.maptomem=1

Забыл сказать, это свойство только ВМ80, для процессора Z80 эту строчку можно удалить.

Удалил эту строчку в конфигах для Z80.

Правильно ли я понимаю, что эта строчка нужна для того, чтобы IN/OUT-команды попадали в ОЗУ по адресам, где старший и младший адреса равны адресу порта. А для Z80 такую строчку применить нельзя.

Хотя на реальном компьютере с Z80, если установлены две КП11 подменяющие адреса A8...A15 на адреса A0...A7 при работе команд IN/OUT (как сделано в схеме установки Z80 в ОРИОН от МП ОРИОН-СЕРВИС), то команды попадают в ОЗУ правильно, т.е аналогично процессору КР580.

Если при Z80 действительно нельзя задавать такую строчку, то тем самым, на Вашем эмуляторе не смогут работать программы с командами IN/OUT, рассчитанными на КР580 без дешифратора В/У. Тем самым эмулятор B2M пока не может эмулировать схему установки Z80 с двумя КП11-тыми.

Пользуясь информацией предоставленной B2M, без хлопот получил совмещение основного ОЗУ и ОЗУ в коммутируемом окне расширения памяти 8400...BFFF, т.е теперь эмулятор работает как реальный РК86 с одной банкой динамического ОЗУ. А также "поставил" в эмуляторе РК86 1 мб памяти, хотя мог бы "поставить" и 4 мб памяти (это максимум, чем можно управлять восемью битами при данном окне доступа). В реальном РК86 1 мб получается, если вместо 565 РУ3/РУ5/РУ7 поставить SIMMS 1 мб от 386-тых. У меня есть такие SIMMS от 386-той, поэтому их и думаю применить.

Эл.диск 1 Мб из ОЗУ на скоростях РК очень долго форматируется, что меня раздражает. Поэтому в моём эмуляторе специально для такого случая есть команда TURBO, по которой скорость эмуляции временно устанавливается максимально возможной, отчего форматирование VDISK-а происходит не на скорости 2.5 МГЦ ОРИОНА, а на скорости 100 МГЦ. А по команде НЕТУРБО скорость возвращается к той, что была в момент прогона команды ТУРБО.

Но с попыткой реализовать в архитектуре РК86 в эмуляторе цельно пол-банковую коммутацию ОЗУ в окне 0...7FFF потерпел неудачу.

Во-первых, не понял, как ввести обыкновенный регистр ИР22 по адресу F300, чтобы управлять переключениями полу-банок. Поэтому пришлось "ввести" третий ППА по адресу F300 и использовать его порт А, как регистр. Удобно, что в эмуляторе БИС ППА не надо инициализировать, они работают как порты ввода и вывода и без этого.

Написал тестовую программу для проверки цельно полу-банковой коммутации, которую загружаю в некоммутируемое ОЗУ в области 8400...BFFF. Банки похоже коммутируются, т.к по переключению полубанки изображение на экране исчезает (остается только мигающий курсор). В реальном РК86 изображение тоже будет исчезать при включении иной полубанки (не 0-вой), поэтому надо аппаратно обеспечить, чтобы DMA (сигналом HOLD) принудительно читал из полу-банки 0.

Впрочем, если переключать полу-банки кратковременно, что и имеет место при работе п/п-мм F836/39, то изображение целиком не погаснет, хотя яркость, думаю, упадёт и возможны мигания экрана. Или же надо ввести возможность читать кадровый бланк и переключать полу-банки только во время обратного хода строчной развёртки. Но увы, в РК86 кадрового бланка (т.е сигнала гашения на обратный ход луча) - просто нет, т.к он в РК организуется программно, а не аппаратно).

Видя, что картинка пропала, я перетранслировал ROM-BIOS так, чтобы экранная область оказалась в некоммутируемой области 8400...BFFF. И тут снова "облом"... Оказалось, что эмулятор никак не хочет работать с экраном выше 8000, хотя на рельном РК86 экран без проблем переносится путём перетрансляции ПЗУ (в начале 90-х я имел РК86 со сплошным ОЗУ в 60К для использования CP/M). Думаю, что надо как-то указать DMA, чтобы он читал из frame[0], что в моём конфиге это область 8400...BFFF.

А вообще-то при наличии памяти выше 8000 свойство переносить экран в верхнее ОЗУ очень полезно, т.к для программ освобождается ровно 32К, что позволяет загрузить больший исходный текст для редактора или ассемблера, которые сами загружены в верхнее ОЗУ. Не могди бы Вы указать способ как исправить мой конфиг, чтобы экранное ОЗУ в области 8400...BFFF тоже отображалось на экране.

Я не понял строки

map[0][F300-F3FF]=mem1.frame[1].page

в секции 'mm'. Ведь слева это адрес регистра управления (ИР22), который переключает полубанки. И значит справа должно стоять это устройство. По аналогии со строчкой

map[0][F100-F1FF]=D14.data

относящейся к управлению окном 8400...BFFF. Почему управление окном 0...7FFF иное, чем окном 8400...BFFF. Поэтому я понял, что это ошибка и исправил строчку так:

map[0][F300-F3FF]=XPPA.data

где XPPA - это ППА заменяющее ИР22 (т.к ИР22 вставить нельзя, пришлось использовать третий ППА).

Как сделать, чтобы при Z80 звук звучал по биту D0 порта С клавиатуры (это бит вывода на МГ-ленту)? В БК-010 тоже, кажется, звук объединён с выводом на МГ-ленту.

Вот результирующий конфиг-файл для РК86 на Z80 с 1 мб ОЗУ.

Скрытый текст

main.CPUClock=1777777Hz
main.Caption="╨рфшю-86╨╩"

CPU : Z80 {
debug=cas
mem=mm
pc=F800
}

mem1 : Memory {
size=100000
frame[0].size=4000
frame[0].page=DOPPPA.portC[0-5]
}

font : Memory {
~rom="Radio/2KFONT.DAT"
frame[0].size=400
frame[0].page=DOPPPA.portC[7]
}

bios : Memory {
rom="Radio\ZBIOS.ROM"
}

memE000 : Memory {
rom="Radio\IRISHA.ROM"
}

DOPPPA : K580ww55 {
}

KBDPPA : K580ww55 {
portA=kbd.~mask
portB=kbd.~data
portC[0]=cas.record
portC[4]=cas.playback
portC[5-7]=kbd.~data2
}

tim : K580wi53 {
clock[0].rate=1/1
clock[1].rate=1/1
clock[2]=tim.out[1]
~gate[0]=tim.out[2]
gate[1].value=1
gate[2].value=1
}

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

dma : K580wt57 {
mem=mem1
}

mm : MemMap {
map[0][0000-7FFF]=mem1[0000]
map[0][8000-83FF]=KBDPPA.data
map[0][8400-BFFF]=mem1.frame[0][0400]
map[0][C000-DFFF]=crt.data
map[0][E000-FFFF].wo=dma.data
map[0][E000-EFFF].ro=memE000[0000]
map[0][F100-F1FF]=DOPPPA.data
map[0][F200-F2FF]=tim.data
map[0][F800-FFFF].ro=bios[0000]
}

kbd : Keyboard {
layout="Radio\layout.kbd"
}

beep : beep {
input=cpu.int
input2=KBDPPA.portC[0]
input[0]=tim.out[0]
}

cas : tape-recorder {
biproc[FB98-FC9D]=rk
boproc[FC46-FC9D]=rk
}

[свернуть]

Есть ещё один вопрос. Причём актуальный, т.к на реальном РК86 я использую не матричную клавиатуру, а аппаратную. И мой контроллер для подключения к РК86 клавиатуры от IBM PC (на SU880) выдаёт на выходе сигналы именно такой клавиатуры (преобразуя последовательные коды в готовый ASCII-код). Т.к клавиатура IBM PC намного приятнее, чем самодельная матричная клавиатура (с низким качеством кнопок), то многим пользователям РК86 и ОРИОНА этот вопрос тоже важен.

Как сделать в конфиг-файле аппаратную клавиатуру для РК86?

Я её подключаю к реальному РК86 к порту клавиатуры вместо матрицы (листинг такого ПЗУ, если любопытно, можно посмотреть в моём каталоге исходников ROM F800 для РК86).

Вот кусок листинга, поясняющий подключение клавиатуры Apple-IIe, что имеет тот же интерфейс, что и клавиатура ИРИШИ (но без клавиши <фикс.рег>).

PORT_A: на ввод, D0-D6 - код клавиши, 
		 D7    - выход ТМ2 (готовность) 
		 
PORT_B: на ввод, бит D0 - сигнал /STB клавиатуры APPLE
                 бит D7 - клавиша <фикс.рег> (это не обязательно эмул-ть) 

PORT_C: на вывод, любой бит - вход R триггера (для сброса ТМ2)

На вход C триггера подводится инвертированный /STB клавиатуры, т.е ТМ2 взводится по нажатию (/STB =0 пока нажата клавиша клавиатуры). В конфиге ИРИШИ это реализовано так

port[04-05]=kbd.keycode - это ASCII-код от апп.клавиатуры

и так

portB[7]=kbd.pressed - это бит готовности кода клавиатуры

Как это сделать для РК86, чтобы вместо порта В/У код читался из порта A ППА клавиатуры РК86 по битам D0...D6? А готовность с того же порта А ППА, но по биту D7. Если из одного и того же порта нельзя читать готовность и данные, то я могу перенести бит готовности в порт B и даже сделать тот же бит D7, как в ИРИШЕ. Но перенести эти регистры в область В/У не могу.

Хотя в ИРИШЕ код клавиши защёлкивается, в ППА код не защёлкивается. Поэтому-то, я и ввёл триггер (он фиксирует, что было нажатие). По биту из триггера узнаём, что было нажатие, а по сигналу /STB узнаём, что код клавиши ещё подаётся (когда клавишу отпустят исчезнет не только 0 на /STB, но и сам код клавиши). Поэтому код клавиши действителен только когда есть /STB и взведён триггер готовности. Так, за счёт всего одного триггера, я подключил аппаратную клавиатуру к РК86 и ОРИОНУ, избавившись от необходимости защёлкивать данные клавиатуры в регистре ИР22.

Правда в ИРИШЕ бит готовности автоматически сбрасывается после считывания, а в РК86 мне приходится сбрасывать его программно делая 0-вой импульс в порт C клавиатуры.

Но для эмулятора сгодится предположение, что ППА защелкивает данные, как в ИРИШЕ и после считывания готовность сама сбрасывается.

У меня возникли вопросы про эмулятор B2M, не касающиеся РК86. Чтобы не злить модераторов и фанатов РК86, я их разместил в теме ИРИШИ.

[b2m]

Правильно ли я понимаю, что эта строчка нужна для того, чтобы IN/OUT-команды попадали в ОЗУ по адресам, где старший и младший адреса равны адресу порта. А для Z80 такую строчку применить нельзя.

Абсолютно верно. Кстати, если не заморачиваться аппаратно, то реальный Z80 тоже не будет обращаться к памяти командами IN/OUT.

Тем самым эмулятор B2M пока не может эмулировать схему установки Z80 с двумя КП11-тыми.

В принципе, если все порты соеденить через Decoder с памятью, и задать соответственно adrxlat (это собственно и есть перестановка битов адреса), то сможет.

Во-первых, не понял, как ввести обыкновенный регистр ИР22 по адресу F300, чтобы управлять переключениями полу-банок.

А что, вышеприведённый конфиг не заработал? Вводить дополнительный регистр не надо, можно напрямую соединять со свойством page. Я выделил красным цветом строчки, необходимые для "полу-банковой коммутации".

Банки похоже коммутируются, т.к по переключению полубанки изображение на экране исчезает (остается только мигающий курсор).

Странно. ВТ57 соединён непосредственно с mem1, ему банки должны быть по-барабану. В Апогее конфиг мало чем отличается в этой части, а там экран выше 8000.

Почему управление окном 0...7FFF иное, чем окном 8400...BFFF.

Потому-что оба варианта возможны. ВВ55 в данном случае не обязательна. Можешь считать, что page это и есть регистр.

Как это сделать для РК86, чтобы вместо порта В/У код читался из порта A ППА клавиатуры РК86 по битам D0...D6? А готовность с того же порта А ППА, но по биту D7.

В секции нужного ВВ55:
portA[0-6]=kbd.keycode
portA[7]=kbd.pressed
Не забудь настроить порт А на ввод.
Правда специфика реализации kbd.keycode такова, что после его чтения обнуляется kbd.pressed. Так что наверное лучше разнести их по разным портам. Иначе keycode может считаться раньше, чем pressed, и последний будет всегда нулевой.

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

Чтобы не злить модераторов и фанатов РК86, я их разместил в теме ИРИШИ.

Честно говоря, обсуждение эмулятора РК86 и в этой теме немного оффтопик.

[barsik]

Эмулятор B2M при эмуляции РК86 визуализирует экран выше 8000 только с таким конфигом, при котором область 8400...BFFF некоммутируемая и является частью mem1, расширенной с 32К до 64К.

mem1 : Memory {
size=10000
}

mm : MemMap {
map[0][0000-7FFF]=mem1[0000]
map[0][8000-83FF]=KBDPPA.data
map[0][8400-BFFF]=mem1[8400]

А вот при такой строке отображения экрана выше 8000 нет:

mm : MemMap {
map[0][0000-7FFF]=mem1[0000]
map[0][8000-83FF]=KBDPPA.data
map[0][8400-BFFF]=mem1.frame[0][0400]

Т.е при коммутируемой области 8400...BFFF экран выше 8000 делать нельзя, что несколько снижает ценность эмулятора.

Попробовал получить архитектуру с переключение ОЗУ полу-банками по 8000H байт и с предложенной (красным цветом) строкой

map[0][F300-F3FF]=mem1.frame[1].page

и со строкой

map[0][F300-F3FF]=XPPA.data

Результат одинаковый.

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

К сожалению, исходника отладчика для Z80 у меня нет, да и в 4К в области E000...EFFF отладчик Z80 не влезет. Поэтому пришлось перетранслировать тест на команды КР580 и использовать отладчик для КР580.

В результате удалось выяснить, что экран в эмуляторе гаснет не по команде записи в регистр переключающий банки, а по команде пишущей в ОЗУ 0...7FFF, т.е в уже переключённую полубанку. Но проблема не в отсутствии визуализации, а в том, что одновременно с гашением изображения происходит улёт самой программы, расположенной в области 8400, даже в шаговом режиме под отладчиком, отчего ничего выяснить нельзя.

Тогда странслировал тест для адреса E000, где в эмулируемом РК ПЗУ, т.е где код не должен разрушаться. Однако стек всё-равно пришлось ставить на C000, т.е в область 8400...BFFF. Результат был аналогичным.

Это меня достало. Я не могу тратить столько времени, на то, что особо и не требуется. Достаточно наличия "верхнего ОЗУ". А уж если оно банкированное (несколько страниц), то это предел мечтаний любого фаната РК86, измученного нехваткой ОЗУ.

Коммутацию полу-банок хотелось иметь в эмуляторе, чтобы не тратить 1/16 ОЗУ впустую (из-за некруглости окна в 15К). На реальном РК86 сделать одновременно и "верхнее ОЗУ" и диспетчер ОЗУ с коммутацией всего основного ОЗУ - нереально. Слишком много пайки и слишком много деталей. Я признаю только такие доработки, что можно без хлопот сделать за 1-2 часа. Наличие ОЗУ 8400...BFFF важнее, чем чуть больший размер эл.диска.

Однако и использование "верхнего ОЗУ" в эмуляторе B2M сейчас под вопросом.

Я обнаружил, что отладчик работающий в верхнем ОЗУ нельзя использовать. А именно, при попытке трассировать программу командой Gstart,stop (где START адрес старта, а STOP адрес стоп-точки), отладчик портит программу. Возврат в отладчик из стоп-точки происходит, но сама стоп-точка не восстанавливается. По адресу стоп точки остаётся байт с кодом RST 8. В этом легко убедиться дав команду X, или L. Тот же отладчик странслированный в основное ОЗУ работает как положено. Происходит так, как будто после прогона кода RST 8, и возврата тем самым в верхнее ОЗУ, программа не смогла записать байт в основное ОЗУ.

Опыт был повторён с тремя разными отладчиками, которые использовались в течение 25 лет и не имели нареканий. В файле TEST B2M.RAR прилагаю исходник отладчика, чтобы Вы могли повторить эксперимент. Руководство в файле _READ_ME.TXT.

В то же время в верхнем ОЗУ без проблем работали несколько игр, мой текстовый редактор и макроассемблер. Т.е проблемы с верхним ОЗУ возникают только при каких-то условиях (возможно при прогоне каких-то редких команд).

Как указано выше, тесты работающие из верхнего ОЗУ и вызывающие п/п-ммы F836/39 тоже по непонятным причинам улетают и трассировать их не удаётся. Я потерял много времени, пока это понял. Причём, как в варианте с двумя блоками памяти (mem1 и mem8400), так и с совмещённым ОЗУ из одного блока памяти.

Таким образом пока разрабатывать программы в эмуляторе B2M, по причине отстутствия отладчика, невозможно. Т.к не имея ни отладчика, ни команд эмулятора для управления прогоном, ничего делать нельзя. Команда HALT, если в ней программа находится более 2 секунд должна автоматически вылетать в отладчик.

Обнаружились глюки эмулятора B2M не зависящие от архитектуры. Если по директиве I ввести файл, а по окончании ввода сразу нажать клавишу I и <ВК>, например, загружая программу для отладки и затем отладчик, то второй файл вводится неверно. Старшим байтом введённого блока выводится FF. Т.е блок вводится в область ПЗУ, выходит за сегмент в 64К и концом блока затирает код самого эмулятора. Если затем снова ввести I и <ВК>, то произойдёт улёт эмулятора с авральным его завершением. Если же между первым вводом файла и вторым вводом файла выполнить любую директиву, например дамп, то последующий блок вводится нормально. Данное явление почему-то бывает не всегда. В половине случаев два подряд ввода по директиве I проходят прекрасно. Если такой глюк случился и старшим байтом введённого блока выведен FF, то необходимо сразу сделать сброс (кликнуть кнопку с красным кружком). После такого глюка в эмуляторе ничего делать нельзя, - будет улёт. Если сразу после сброса нажать I и <ВК> и затем в меню выбора файлов нажать <ESC>, то изображение на экране исчезает и прогон зависает. Это тоже глюк эмулятора B2M.

Эмулятор B2M с базовым ПЗУ F800, но без ПЗУ F000 улетает, если нажать <ВК> на пустой строке. Это ошибка не эмулятора, а авторов РК86, точнее их ПЗУ F800 (уход на несуществующее ПЗУ F000). Автор эмулятора B2M избавился от этой ошибки подставив код ПЗУ F800 также по адресу F000, отчего JMP F000 равноценен рестарту. Поэтому надо использовать исправленый мной ROM-BIOS, где вместо ухода на F000, в случае ввода ошибочной команды, сделан уход на ERROR.

Регистр управляющий содержимым окна 8400...BFFF надо инициализировать при старте компьютера, т.е по холодному старту ПЗУ F800. Для этого надо запрограммировать режим доп.ППА (по адресу F100) и вывести в порт C ППА число 2. Иначе в окне 8400 отображается содержимое основного ОЗУ с адресов 0400...3FFF. При числе в порту С равном 1 в окне 8400 тоже отображается основное ОЗУ (но уже 4400...7FFF). Поэтому приходится выводить в регистр число 2. При расширении ОЗУ выше 8000 за счёт статического ОЗУ, это ОЗУ не совмещено с ОЗУ из динамического ОЗУ и таких проблем нет.

Использование ОЗУ 8400...BFFF со стандартным базовым ПЗУ F800, т.е без инициализации регистра управления равнозначно использованию основного ОЗУ 0400...3FFF. И если, использовать текстовый редактор, работающий в верхнем ОЗУ, то при загрузке текста разрушается код редактора и происходит улёт. Таким образом инициализировать регистр управления окном надо как в версии ПЗУ для Z80, так и в версии для КР580.

Т.к регистр управления находится в ППА стоящем по адресу F100, то работать такие ROM-BIOS могут только, если область F000 выделена дешифратором. Если дешифратора нет, т.е РК86 абсолютно базовый, без РК-КНГМД, то запись в ППА F100 попадает в БИС ВТ57. И соответственно такое ПЗУ не годится для базового РК86.

Прилагаю версии ROM-BIOS для КР580 и Z80. В версии Z80 есть п/п-ммы для работы с расширенным ОЗУ, а также добавлены 2 новые директивы. Читайте READ_ME-файлы и смотрите исходники. Всё документировано.

Прилагаю для тестирования версии RK-DOS для Z80. Также читайте READ_ME- файлы и смотрите исходники. Всё документировано.

Прилагаю для теста "верхнего" ОЗУ несколько программ работающих в верхнем ОЗУ. Мой редактор и ассемблер - это последняя версия для КР580, что была адаптирована от СПЕЦИАЛИСТА к РК86. Последующие версии были для Z80 и только для ОРИОНА и их конверсия для РК требует труда и пока не сделана (не ясно как сделать маркировку текста без инверсии, нужна замена Z80-команд, замена координат POSX,POSY и переделка роликов вверх-вниз). В этой версии макроассемблера в макрокомандах нет некоторых расширенных свойств (но документация соответствует).

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

Здесь во вложении версия RKDOS с ошибкой (работает только в ОЗУ) исправленную версию можно взять в конце темы.

[b2m]

Эмулятор B2M при эмуляции РК86 визуализирует экран выше 8000 только с таким конфигом, при котором область 8400...BFFF некоммутируемая и является частью mem1, расширенной с 32К до 64К.

Всё правильно. ВГ75 читает из памяти через ВТ57, а её "память" подключена непосредственно к mem1. Можно это изменить, и, я думаю, ты получишь, что хочешь:

dma : K580wt57 {
  mem=mm
}

Просто с такой конфигурацией можно настроить экран на область портов, а это мне показалось лишним. Да и аппаратная реализация, как мне кажется, позволяет контроллеру ПДП читать только из памяти. Необходимость переключать экран при помощи "банок", на мой взгляд, не является такой уж насущной.

Результат одинаковый.

В смысле работает, или в смысле не работает?

встроенный в эмулятор отладчик оказался неудобным, неполноценным и потому непригодным (для меня) для практического использования

Как? Вы не любите кошек? Да вы просто не умеете их готовить!

одновременно с гашением изображения происходит улёт самой программы, расположенной в области 8400, даже в шаговом режиме под отладчиком, отчего ничего выяснить нельзя

Во встроенном отладчике такого не может быть. По клавише F8 всегда происходит выполнение одной команды. И всегда можно выяснить, что происходит. Единственный, может быть, недостаток, это то, что при этом (из соображений эффективности) не обновляется дамп. Но если это не команда перехода или вызова процедуры, то можно нажать Shift+F8 (то есть выполнить до следующей команды, при этом подпрограмма выполнится без трассировки), и дамп обновится. Кстати, точки останова (клавишой F9) можно ставить не только в окне дизассемблера, но и в окне дампа. При этом останов произойдёт при обращении к отмеченному байту памяти, даже если это порт. Таким образом можно отлавливать обращение к портам.

Однако и использование "верхнего ОЗУ" в эмуляторе B2M сейчас под вопросом.

Да нет в эмуляторе никакого "верхнего ОЗУ"! Эта "граница" всего лишь результат используемого конфига. Когда я делаю эмуляцию какого-либо компьютера, я чётко представляю себе его архитектуру, и делаю конфиг таким образом, чтобы программы работали также, как и на реальном компьютере. Да, это не всегда просто. Даже для меня, хотя я абсолютно точно представляю себе, как будет эмулироваться та или иная фича конфига.

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

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

Если по директиве I ввести файл, а по окончании ввода сразу нажать клавишу I и <ВК>

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

Если сразу после сброса нажать I и <ВК> и затем в меню выбора файлов нажать <ESC>, то изображение на экране исчезает и прогон зависает. Это тоже глюк эмулятора B2M.

Это не глюк, а непонимание работы эмулятора. Если отказаться от выбора файла при перехвате процедуры ввода, то перехвата не будет, и программа будет выполняться дальше. А дальше п/п ввода с магнитофона отключит ПДП, чтобы не мешать чтению (при этом экран гаснет) и читает из порта магнитофона. В этот момент можно кнопкой на тулбаре "включить" воспроизведение .wav файла (типа включили магнитофон). Всё как на реальном РК.

[Pyk]

barsik, а что именно не должно было работать в RK-DOS на Z80?
Попробовал в текущей разрабатываемой версии своего эмулятора эту комбинацию - на первый взгляд все ок...

[barsik]

Попробовал в текущей разрабатываемой версии своего эмулятора эту комбинацию и на первый взгляд - всё OK.

Вы имеете ввиду RK-DOS? Именно ту, перетранслированную для Z80 из файла "RKDOS_for_TEST.RAR", что я выложил для проверки в реале? У меня вообще-то нет особых причин думать, что они нерабочие, т.к я получил их, - одну "кромсанием" рабочего исходника RK-DOS для ОРИОНА, а вторую косметическими изменениями в оригинальной РК-ДОС для КР580. Но т.к обе версии не проверялись в реале и при переделках почти всегда возникают ошибки и с первой попытки обычно ничего не работает, то я и предложил их проверить в реале тому, у кого есть Z80 процессор в РК86 и стандартный РК-КНГМД по адресу F000. Так что конкретных ошибок я указать не могу. Если они есть, их надо определить при проверке в реале или хотя-бы в эмуляторе.

Из текста сообщения понял, что Вы проверили эти коды в эмуляторе, который эмулирует и РК-ДОС и процессор Z80. О существовании такого эмулятора ничего никому ещё не известно. Не сообщите ли подробности о новой версии своего эмулятора EMU80 для Z80? Если действительно сделана эмуляция железа РК-КНГМД, то это удобно, чтобы проверять ДОС на базе дисковода. А вот Z80 в РК86 это пока не актуально.

Следующая строка поможет иметь экран выше 8000

dma : K580wt57 {
  mem=mm
}

Эта строка не помогла, хотя появились отличия. Если при 'mem1' вообще ничего на экране не было, то теперь кое-что на экране есть. Но удивляет, что выводится только часть символов.

Теперь снова про глюк в работе отладчика из ОЗУ 8400...BFFF и тот же самый глюк при работе отладчика из ПЗУ E000. Этот глюк не связан со стеком, т.к одинаков при стеке - в основном ОЗУ и в ОЗУ выше 8000.

Как с конфигом, где основное ОЗУ совмещено с помощью 'frame' с ОЗУ окна 8400, так и с конфигом, где эти ОЗУ (mem1 и mem8400) - разные, отладчик ведёт себя так, как я и описывал, - не удаляет RST в основном ОЗУ.

Но если закомментировать одну строку так

// map[0][F100-F1FF]=DOPPPA.data

то отладчик в верхних адресах работает отлично, но естественно коммутации ОЗУ в окне 8400...BFFF - нет, хотя само ОЗУ в области 8400...BFFF - есть. Таким образом, всё портит коммутация кусков памяти в окне.

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

Открою секрет: файл, из которого происходит ввод, не закрывается сразу после возврата из перехвата, а только через 5 секунд.

Я не мог знать насчёт паузы в 5 секунд между вводами по I? Ведь документации нет. Это объяснило почему дефект возникал не всегда. И то, что выполнение какой-то промежуточной команды перед второй директивой I помогало избавиться от дефекта. И это явный глюк эмулятора, а не особенность. Если пользователь страдает, то это всегда глюк. Если произошёл "отлов" прогона входа RDBYTE, чётко указанного в конфиге, то уж сам Бог велел при этом закрыть все файлы. И ссылки на паузу в 5 секунд и ожидание продолжения ввода предыдущего блока, после входа в RDBYTE - неуместны.

Зачем ждать 5 секунд. Достаточно тайм-аута в пол секунды. И это не объясняет откуда берётся старший байт адреса следующего блока равный FF. Предположительно это байт КС предыдущего блока. FF потому, что для неокончательных файлов я не устанавливаю правильную КС, - это ни к чему, если файл ещё изменится 20 раз. Но не важно по каким причинам искажается адрес ввода. В любом случае эмулятор не должен вводить блок в адреса выше C000. Так что с тем, что это глюк спорить невозможно. Но это нормально, все программы содержат ошибки.

Синхронизация должна происходить по байту E6. Это лишний раз доказывает, что формат 'GAM' лучше, чем надуманный формат 'RK', т.к в нём есть байт синхронизации E6. Но эмулятор B2M правильно считывает и файлы с расширением RK. И даже вообще любые файлы с произвольным расширением. Он просто считает первые 4 байта как адреса ввода. А если первый байт E6, то его игнорирует. Вследствие этого, по директиве I файл в формате RK в эмулятор B2M нельзя ввести на адреса E600...E6FF. А вот в формате GAM - можно.

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

Лишние байты есть всегда. Файлы записанные в CP/M имеют кратность 128 байт. Поэтому после трансляции очень редко появляется GAM-файл у которого длина чётко равна длине блока плюс служебные байты в начале и конце блока. Точнее это может случиться только с вероятностью 1/128-мая, т.е на практике почти никогда.

И кстати, раз уж речь о вводе файлов. А что насчёт ввода других форматов? В частности ORD. Ведь как-то Вы вводите при эмуляции СПЕЦИАЛИСТА и ОРИОНА другие МГ-форматы, кроме формата МИКРО-80 и РК86. Точнее, - задача вводить файлы не с магнитофона, а с винчестера. Это же проще, чем эмулировать ввод с магнитофона.

Когда я делал эмулятор РК86, то сразу решил не "заморачиваться" с магнитофоном. Ввёл в сам эмулятор функцию загрузки файла. А уж какой он, в каком формате этот файл, это эмулятор не волнует. Эмулятор получает от КР580-программы имя файла, адрес загрузки и максимально допустимый размер файла и просто грузит файл с винчестера. Аналогично при записи. Но самое трагичное, что ориентация на магнитофон и низкоуровневую эмуляцию железа, а не на файлы на винчестере, лишает возможности тестировать в эмуляторе ДОС. А особенно, когда даже низкоуровневой эмуляции РК-КНГМД нет. Хоть какой-то выход из этого - это эмуляция большого ОЗУ, используемого в качестве эл.диска.

У меня файлы для всех БК (в том числе РК86) - в формате ORD и этот формат понимает мой эмулятор РК86. Очень неудобно транслировать все программы в двух видах - и в виде GAM и в виде ORD. Формат ORD удобен тем, что он годится и для МГ-ленты (или WAV-файла) и для дискового файла. Форматы RK и GAM при выгрузке на ленту теряют имена файлов.

Я не представляю, как загрузить в эмулятор B2M файл в формате ORD. Ещё большее неудобство возникает при вводе файлов в ИРИШУ. Потому-что там формат записи на МГ не содержит ни адреса загрузки, ни длины файла. Поэтому приходится помнить эти данные или хранить их на бумажке. Я с этим намучился ещё на реальной ИРИШЕ (потерял из-за этого кучу файлов). И был дико удивлён, когда обнаружил такую-же ерунду и в эмуляторе. Здесь задача ввода ORD-файлов, на порядок более актуальна.

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

Я пользовался экранными отладчиками 80x86. Отладчиком эмулятора B2M пользоваться неудобно. Почему пользователь экспериментальным путём должен устанавливать, что делают команды отладчика, приведённые в HELP-е? HELP должен быть исчерпывающе понятным.

В отладчиках должна быть команда PASS для прохождения подпрограмм без трассировки. В отладчике ИРИШИ из 1977 года нажимаешь P на команде CALL или RST и она прогоняется, как одна команда ассемблера. И кстати, о якобы ущербности командного режима относительно графического представления отладчика. Видя фрагмент кода и зная, где надо остановиться, на порядок быстрее ввести команду 'G,xxxx', чем подгонять курсор куда-то, ставить там стоп-точку и затем нажимать на <F5>. А если стоп точка вообще не на экране, то переход к ней отнимает ещё больше времени.

Видел отладчики которые показывают дамп ОЗУ, куда указывает текущий HL. Удобно если в отладчике работают символьные клавиши, а не только функциональные и мышь. Например, по P,S,A,B,D,H может выскакивать окно для HEX-ввода регистров. По нажатию I,C,Z,E... могут переключаться на обратный флаги. По нажатию только одной клавиши курсор должен перескакивать в нужное окно. В визуальном отладчике тоже удобно иметь команды.

У программирующих для 8080/Z80 не бывает листинга LST, это же не MASM или TASM для 80x86. У них бывает только файл с расширением PRN, где тоже есть таблица меток.

Почему запрашиваются HEX-числа с СИ-префиксом '0x'? По нажатию клавиши окно очищается, в том числе и префикс. Просто HEX-число, без префикса не вводится. Приходится вручную вводить ещё и префикс 0x, что раздражает. Если уж окно очищается, то префикс '0x' следовало оставить, чтобы пользователю не пришлось вводить его вручную. А если уж необходима подсказка, что ожидается HEX-число, то это можно сделать в заголовке окна.

Да и странно ожидать что-то другое кроме HEX-чисел, мы же в отладчике, не в бейсике. Всё должно быть для удобства пользователя.

[Pyk]

Ох, написано выше много, не готов пока обстоятельно ответить. Перечитаю сначала последние страницы темы и отпишусь дополнительно (а то я сам уже не уверен, какой именно вариант я проверял

Пока могу лишь сказать, что эмулятор в разработке, поддержка как РК-ДОС, так и Z80 в нем уже есть, но публиковать сырую версию я пока не планирую. Я не ставил перед собой цель поддержать как можно больше платформ, так что таких продвинутых конфигов, как у b2m, у меня, к сожалению, нет. Возможно, для полноценной поддержки вашей конфигурации придется минимально дополнять код.

Отладчик пока также не доделан, некоторые из пожеланий в нем учтены, некоторые нет. Что-то и у b2m на самом деле есть, например, Pass over по Shift-F8.

Что же касается остальных пожеланий, в том числе перехватов файловых операций, то уж не обессудьте - на что сил хватило, то и будет в эмуляторе. Мы ведь занимаемся этим в свободное время и для собственного удовольствия. Поэтому и собираюсь опубликовать исходники, чтобы желающие могли полноценно добавлять нужные фичи...