Emu80 v.4

[Pyk]

ZEman, "Лик" будет, уже готов. "Спектром" пока не занимался, наверное уже после НГ.

barsik, насчет процедуры настройки посмотрю еще.
А байт E6 просто всегда выдается сразу после открытия файла.
Также не понял, зачем нужен критерий выхода из п/п LDBYTE/SVBYTE?

[zx_]

нашел вот в описании ленинградского монитора 3.0 -3.3 по ссылке barsik,

я же помню -)
""

НОВИНКА! ПЗУ D000 содержит полный (!) эмулятор барнаульского монитора, что
позволяет выполнять барнаульские программы без изменений в них!

Для этого в самом компьютере необходимо установить дешифратор (555ИД7),
разбивающий адресное пространство F800-FFFF на 8 участков по 256 байт (для
тех у кого это еще не сделано) и обеспечить выборку ПЗУ C800 при обращении
к ПЗУ F800 - включить два диода анодами к входу /CS ПЗУ C800, катоды к вы-
ходам дешифраторов C800 и F800. После этого все программы барнаульского
кооператива не обращающиеся непосредственно к порту по адресу F000 (это 90%
программ) будут вашими. А для получения 100% совместимости с помощью еще
двух диодов (или одной ИМС 155ЛИ1) обеспечьте выборку порта, как по адресу
FF00 так и по адресу F000.

это я все про свое -РК КНГМД

[barsik]

не понял, зачем нужен критерий выхода из п/п LDBYTE/SVBYTE ?

Адрес LDBYTE в ПЗУ это адрес входа в подпрограмму. Но Вы эту п/п-мму реально не прогоняете, а химичите, заменяя прогон этой подпрограммы лезущей в МГ-порт 8-ми разрядки, считывающей фронты и компонующей из считанных битов целый байт, на примитивное чтение очередного байта из открытого файла. Т.е в тот момент когда в регистре PC эмулируемого КР580 вдруг оказался адрес LDBYTE=C377, что было задано строчкой в Вашем конфиге, Вы неожидано прекращаете эмуляцию, считываете очередной байт из открытого файла и заносите его в эмулируемый регистр A (т.к эта подпрограмма возвращает результат в A). И вот что Вы делаете дальше это Ваш большой секрет.

Эмулятор EMU от b2m в этом месте, зная точку выхода из LDBYTE, просто переустанавливает регистр PC на адрес точки выхода и продолжает эмуляцию прогона программы с этой точки. Просто и эффектно. И весь код, что исполняет подпрограмму LDBYTE в ПЗУ можно забить нулями или матерными фразами, это не повредит.

Ну а вот, что делаете Вы, т.к Вам неизвестна точка выхода, это большой и тщательно скрываемый Вами секрет. Могу предположить, что Вы пошли мазохистским путём, а именно продолжаете с этой точки уже не прогон, а трассировку программы. Т.е просто отслеживаете только регистр PC, трассируете и ищете команды которые меняют стек, т.е PUSH, POP, LD SP,nnnn, LD SP,HL и др. И ждёте когда стек станет ровно на 2 адреса выше того, что был в момент входа в точку LDBYTE, что означает, что прошла команда RET и произошел возврат, т.е была целиком прогнана подпрограмма LDBYTE.

Какие другие варианты узнать момент возврата из CALL LDBYTE могут быть ещё ?

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

это я все про свое - РК-КНГМД

Почему Вас волнует, что КООП SP580, чтобы освовободить адреса F800...FFFF для ПЗУ совместимого с РК86 решил перенести ППА клавиатуры с FF00 на F000. Они совершенно справедливо решили, что совместимость с РК86 важнее, чем совместимость с базовым вариантом, т.к для СПЕЦИАЛИСТА тогда вообше не было программ, а для РК86 были.

Только они ещё не знали о мониторе Орлова на C800 и потому не догадались, что для совместимости достаточно совместить только входы в подпрограммы, т.е F803, F806, F809... и т.д. Остальные адреса F839...FFFF совмещать не требуется. Потому и возможно с помощью 2-х дидов получить и совместимость с РК86 и сохранить адрес порта на FF00. И тогда все системные программы РК86 (кроме программ извращенцев, что лезут внутрь ПЗУ РК86 на нестандартные входы) будут работать на СПЕЦИАЛИСТЕ.

Идеи и схемы КООП SP580 не имеют никакого отношения к РК-КНГМД, хотя если РК-КНГМД ставить на вариант железа SP580, то да, возникнет конфликт, т.к по F000 у них стоит клавиатура, а РК-КНГМД как раз использует адрес F000. Но какая проблема? Если у Вас СПЕЦИАЛИСТ по варианту SP580, так перетранслируйте РК-КНГМД на какой-нибудь другой адрес. А вообще какой смысл в варианте SP580. Для него программ гораздо меньше, его использовали единицы, да и то, только до момента пока не понимали, что совместимость с остальными пользователями важнее.

[b2m]

Ну а вот, что делаете Вы, т.к Вам неизвестна точка выхода, это большой и тщательно скрываемый Вами секрет.

Ничего он не скрывает, внимательнее надо читать посты. Он уже писал, что вместо выполнения процедуры эмулируется команда RET. К сожалению, этого не всегда достаточно, вызывающая программа иногда рассчитывает на определённое значение флагов и других регистров. Очень часто анализируется флаг переноса, и если он был установлен до входа в процедуру (и является флагом ошибки) то чтение прерывается. У меня в конфигах не всегда адрес выхода из процедуры в точности соответствует реальному концу процедуры, приходится искать подходящий код в ПЗУ (типа ORA A / RET).

[barsik]

внимательнее надо читать посты. Он уже писал, что вместо выполнения процедуры эмулируется команда RET

Ссылку на пост, где об этом сказано.

Это Вам откуда-то известно, но я об этом узнаю впервые. Действительно, если с'имитировать команду RET сразу на входе LDBYTE, то не надо знать адрес выхода из п/п-ммы LDBYTE. Это имеет недостатком то, что подгрузив на вектор LDBYTE свою исполнительную часть, например процедуру выводящую полосы по бордюру, как в Синклере, в эмуляторе этого не будет.

И понятно, что многоблочные программы в которых своя процедура загрузки, этим алгоритмом не вводятся. Т.е только самые-самые простейшие многоблочные программы, что не используют своих подпрограмм чтения с ленты можно грузить в эмулятор. А практически все чуть более грамотные многоблочные программы уже в первом блоке имеют процедуру автонастройки на скорость (т.к нельзя рассчитывать, что у всех монитор с автонастройкой) и соответственно уже первый блок зависнет тщетно ожидая фронты на МГ-входе.

И подпрограмма ввода в многоблочных программах своя, даже когда используется та же двухфазная кодировка. Например, в отличие от базовой подпрограммы в ПЗУ подпрограмма контроллирует сигнал на тайм-аут, достаточно сигналу прерваться на длительность более чем период выдачи одного бита, как это будет обнаружено и замигает надпись "TAPE LOADING ERROR".

b2m а почему в Вашем эмуляторе монитор с автонастройкой на скорость записи не зависает, как эмулятор EMU80 ? В чём секрет ?

Предполагаю, что Вы отлавливаете и чтения МГ-порта и инвертируете бит читаемый с PB0 по каждому 20-му обращению туда (число можно подобрать, чтобы определялась стандартная константа).

Что советую сделать и Pyk-у в эмуляторе EMU80. Тогда автонастройка на скорость ввода будет работать, а какая константа определится и будет подставлена в CLD (8FFF) не важно, т.к п/п-мма LDBYTE всё-равно не прогоняется, а от зависа на чтении МГ-порта это избавляет.

[CodeMaster]

Ссылку на пост, где об этом сказано.

barsik, как так-то? Я читаю эту тему по диагонали, чисто из исторического интереса и то видел, что на прошлой странице Pyk тебе лично повторил где он об этом писАл:

Вместо них выполняется перенаправление в файл и имитируется команда RET

[barsik]

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

[Pyk]

вызывающая программа иногда рассчитывает на определённое значение флагов и других регистров. Очень часто анализируется флаг переноса, и если он был установлен до входа в процедуру (и является флагом ошибки) то чтение прерывается.

Это конкретно к процедурам ввода/вывода байта на РК и клонах относится? Что-то я не припомню, чтобы подобное где-то использовалось...

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

Но вот, что совершенно непонятно, так это почему у эмулятора EMU от b2m не было никаких проблем с ленинградским монитором из-за процедуры настройки на скорость

Попробовал - что мой эмулятор, что emu одинаково зацикливаются с непатченым Монитором на процедуре автонастройки...
В вот в эмуляторе uart судя по всему должно все без проблем работать

[barsik]

А вот в эмуляторе uart судя по всему должно все без проблем работать

Но этот эмулятор конечно же недоступен, т.к не для IBM PC.

Попробовал - что мой эмулятор, что emu одинаково зацикливаются с непатченым Монитором на процедуре автонастройки...

А у меня EMU от b2m не зацикливается на автонастройке с любыми мониторами. Видимо Вы использовали в нём конфиг для орловского монитора, а он не подходит для других мониторов. Конфиги, чтобы грузили в формате RKS (точнее в обоих RKS-ах) надо настраивать индивидуально. Я не пользуюсь теперь эмулятором EMU более полугода, но впечатление от его работы с МГ было хорошее, т.к особых проблем не было. Хотя со зверковским загрузчиком я его не использовал.

Я использую вот такой файл с именем "Specialist Mon 3.3.cfg" и по директиве I файлы RKS с именем грузятся. Но вот сделать записи в WAV-файл у меня с EMU не получается. Поэтому я и переключился на Ваш эмулятор. Надеюсь, что у Вас всё получится. Этот конфиг обычный, только в самом конце в нём возможно я изменил две строки в разделе "cas: tape-recorder". Точно не помню, это было ещё в апреле.

Мой конфиг для EMU

main.CPUClock=2500000Hz
main.Caption="Специалист КР580 базовый"

CPU : K580wm80a {
debug=cas
mem=mm
pc=C000
port.maptomem=1
}

mem1 : Memory {
size=10000
}

bios : Memory {
rom="Specialist\BIOS_33.DAT"
}

sys : K580ww55 {
portA=kbd.row
portB[0]=cas.playback
portB[1]=kbd.shift
portB[2-7]=kbd.col
portC[0-3]=kbd.row2
portC[7]=cas.record
}

mm : MemMap {
map[0][0000-8FFF]=mem1[0000]
map[0][9000-BFFF]=vid.mem
map[0][C000-F7FF].ro=bios[0000]
map[0][F800-FFFF]=sys.data
}

kbd : Specialist-Keyboard {
layout="Specialist\layout.kbd"
}

vid : Specialist-Video {
}

beep : beep {
input=sys.portC[5]
}

cas : tape-recorder {
biproc[C37D-C4CF]=rk
boproc[C3CB-C3F8]=sp
}

[свернуть]

А вот когда я соберусь переделать свой эмулятор ОРИОНА для MSDOS в эмулятор СПЕЦИАЛИСТА для MSDOS (возможно в НГ-праздники), то я быть может тоже попробую встроить работу с магнитофоном (раньше не эмулировал, было не надо, зачем если есть CP/M), но применю не Ваши алгоритмы c перехватом LDBYTE, а "химию" более высокого уровня, буду перехватывать другие точки

.
C3F9 - ввод блока с  поиском синхробайта, адреса 
       начала  и конца  блока  указаны  на ленте

C422 - ввод блока с поиском синхробайта, адреса 
       начала и конца блока  заданы  в HL  и DE

C414 - то же  самое,  но без поиска синхробайта, 
       позволяет иметь синхробайт не равный E6

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

Флаги эти подпрограммы не возвращают, а весь МГ-ввод основан только на этих подпрограммах. И напрасно Вы не включили в формат RKS синхробайт. Это значит, что просто подменив синхробайт E6 на E7 все эмуляторы блокируются.

[Pyk]

barsik, не работает с этим конфигом.
Как и следовало ожидать, зацикливается на тех же адресах, что и emu80...