Вид для печати
ZEman, "Лик" будет, уже готов. "Спектром" пока не занимался, наверное уже после НГ.
barsik, насчет процедуры настройки посмотрю еще.
А байт E6 просто всегда выдается сразу после открытия файла.
Также не понял, зачем нужен критерий выхода из п/п LDBYTE/SVBYTE?
нашел вот в описании ленинградского монитора 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.
это я все про свое -РК КНГМД
Адрес LDBYTE в ПЗУ это адрес входа в подпрограмму. Но Вы эту п/п-мму реально не прогоняете, а химичите, заменяя прогон этой подпрограммы лезущей в МГ-порт 8-ми разрядки, считывающей фронты и компонующей из считанных битов целый байт, на примитивное чтение очередного байта из открытого файла. Т.е в тот момент когда в регистре PC эмулируемого КР580 вдруг оказался адрес LDBYTE=C377, что было задано строчкой в Вашем конфиге, Вы неожидано прекращаете эмуляцию, считываете очередной байт из открытого файла и заносите его в эмулируемый регистр A (т.к эта подпрограмма возвращает результат в A). И вот что Вы делаете дальше это Ваш большой секрет.Цитата:
Сообщение от pYK
Эмулятор 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 были.Цитата:
Сообщение от zx_
Только они ещё не знали о мониторе Орлова на C800 и потому не догадались, что для совместимости достаточно совместить только входы в подпрограммы, т.е F803, F806, F809... и т.д. Остальные адреса F839...FFFF совмещать не требуется. Потому и возможно с помощью 2-х дидов получить и совместимость с РК86 и сохранить адрес порта на FF00. И тогда все системные программы РК86 (кроме программ извращенцев, что лезут внутрь ПЗУ РК86 на нестандартные входы) будут работать на СПЕЦИАЛИСТЕ.
Идеи и схемы КООП SP580 не имеют никакого отношения к РК-КНГМД, хотя если РК-КНГМД ставить на вариант железа SP580, то да, возникнет конфликт, т.к по F000 у них стоит клавиатура, а РК-КНГМД как раз использует адрес F000. Но какая проблема? Если у Вас СПЕЦИАЛИСТ по варианту SP580, так перетранслируйте РК-КНГМД на какой-нибудь другой адрес. А вообще какой смысл в варианте SP580. Для него программ гораздо меньше, его использовали единицы, да и то, только до момента пока не понимали, что совместимость с остальными пользователями важнее.
Ничего он не скрывает, внимательнее надо читать посты. Он уже писал, что вместо выполнения процедуры эмулируется команда RET. К сожалению, этого не всегда достаточно, вызывающая программа иногда рассчитывает на определённое значение флагов и других регистров. Очень часто анализируется флаг переноса, и если он был установлен до входа в процедуру (и является флагом ошибки) то чтение прерывается. У меня в конфигах не всегда адрес выхода из процедуры в точности соответствует реальному концу процедуры, приходится искать подходящий код в ПЗУ (типа ORA A / RET).Цитата:
Сообщение от barsik
Ссылку на пост, где об этом сказано.Цитата:
Сообщение от b2m
Это Вам откуда-то известно, но я об этом узнаю впервые. Действительно, если с'имитировать команду RET сразу на входе LDBYTE, то не надо знать адрес выхода из п/п-ммы LDBYTE. Это имеет недостатком то, что подгрузив на вектор LDBYTE свою исполнительную часть, например процедуру выводящую полосы по бордюру, как в Синклере, в эмуляторе этого не будет.
И понятно, что многоблочные программы в которых своя процедура загрузки, этим алгоритмом не вводятся. Т.е только самые-самые простейшие многоблочные программы, что не используют своих подпрограмм чтения с ленты можно грузить в эмулятор. А практически все чуть более грамотные многоблочные программы уже в первом блоке имеют процедуру автонастройки на скорость (т.к нельзя рассчитывать, что у всех монитор с автонастройкой) и соответственно уже первый блок зависнет тщетно ожидая фронты на МГ-входе.
И подпрограмма ввода в многоблочных программах своя, даже когда используется та же двухфазная кодировка. Например, в отличие от базовой подпрограммы в ПЗУ подпрограмма контроллирует сигнал на тайм-аут, достаточно сигналу прерваться на длительность более чем период выдачи одного бита, как это будет обнаружено и замигает надпись "TAPE LOADING ERROR".
b2m а почему в Вашем эмуляторе монитор с автонастройкой на скорость записи не зависает, как эмулятор EMU80 ? В чём секрет ?
Предполагаю, что Вы отлавливаете и чтения МГ-порта и инвертируете бит читаемый с PB0 по каждому 20-му обращению туда (число можно подобрать, чтобы определялась стандартная константа).
Что советую сделать и Pyk-у в эмуляторе EMU80. Тогда автонастройка на скорость ввода будет работать, а какая константа определится и будет подставлена в CLD (8FFF) не важно, т.к п/п-мма LDBYTE всё-равно не прогоняется, а от зависа на чтении МГ-порта это избавляет.
barsik, как так-то? Я читаю эту тему по диагонали, чисто из исторического интереса и то видел, что на прошлой странице Pyk тебе лично повторил где он об этом писАл:Цитата:
Сообщение от barsik
Вместо них выполняется перенаправление в файл и имитируется команда RET
Понятно, что команда RET когда-то должна быть исполнена, иначе как вернуться из LDBYTE. Поэтому эта фраза вообще ничего не говорит о теме. Из этой фразы ничуть не следует, что RET имитируется сразу же, а не по критерию выхода из подпрограммы LDBYTE. И вполне логично было думать, что в EMU80 алгоритм как у EMU.
Это конкретно к процедурам ввода/вывода байта на РК и клонах относится? Что-то я не припомню, чтобы подобное где-то использовалось...Цитата:
Сообщение от b2m
- - - Добавлено - - -
Попробовал - что мой эмулятор, что emu одинаково зацикливаются с непатченым Монитором на процедуре автонастройки...Цитата:
Сообщение от barsik
В вот в эмуляторе uart судя по всему должно все без проблем работать :)
Но этот эмулятор конечно же недоступен, т.к не для IBM PC.Цитата:
Сообщение от Pyk
А у меня EMU от b2m не зацикливается на автонастройке с любыми мониторами. Видимо Вы использовали в нём конфиг для орловского монитора, а он не подходит для других мониторов. Конфиги, чтобы грузили в формате RKS (точнее в обоих RKS-ах) надо настраивать индивидуально. Я не пользуюсь теперь эмулятором EMU более полугода, но впечатление от его работы с МГ было хорошее, т.к особых проблем не было. Хотя со зверковским загрузчиком я его не использовал.Цитата:
Сообщение от Pyk
Я использую вот такой файл с именем "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, а "химию" более высокого уровня, буду перехватывать другие точки
Флаги эти подпрограммы не возвращают, а весь МГ-ввод основан только на этих подпрограммах. И напрасно Вы не включили в формат RKS синхробайт. Это значит, что просто подменив синхробайт E6 на E7 все эмуляторы блокируются.Код:.
C3F9 - ввод блока с поиском синхробайта, адреса
начала и конца блока указаны на ленте
C422 - ввод блока с поиском синхробайта, адреса
начала и конца блока заданы в HL и DE
C414 - то же самое, но без поиска синхробайта,
позволяет иметь синхробайт не равный E6
C453 - ввод блока с поиском синхробайта и авто-
матическим запуском блока на исполнение
barsik, не работает с этим конфигом.
Как и следовало ожидать, зацикливается на тех же адресах, что и emu80...