РАДИО-86РК на 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, я их разместил в теме ИРИШИ.

[Advertiser]

[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 файла (типа включили магнитофон). Всё как на реальном РК.

[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, кстати...