Emu80 v.4

[Pyk]

В попытке проверить RAMDOS, RAMDOS-Commander, защищённые от копирования программы, их инсталляторы, МГ-компоновщик и SP-COPY, я столкнулся с проблемой загрузить программу с автостартом.

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

Т.к принцип эмуляции магнитофона здесь основан на перехвате единственной подпрограммы LDBYTE (C377, С806). Причём предполагается, что эта подпрограмма вызывается из подпрограммы ввода массива, в которой передаются адреса для ввода блока, а в конце массива следует контрольная сумма.

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

Пилотоны можно опустить, а вот все синхробайты E6, необходимы. Таким образом именно отсутствие в формате RKS байта E6 приводит к неприятностям. Именно по этой причине в формате GAM все байты E6 были сохранены.

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

имеющиеся возможности ленинградского монитора по чтению МГ-формата ZX-Spectrum и МГ-формата MSX не могут работать в эмуляторе EMU80

Эмулятор поддерживает формат CAS для формата MSX, интересно было бы попробовать перехватить также и эти вызовы. А для ZX остается загрузка wav.

лениградский монитор СПЕЦИАЛИСТА (в котором 100% совмещены все стандартные входные точки, но также и все нестандартные точки), не работает на ввод с магнитофона

Почему не работает Ленинградский Монитор я проверю и отдельно отпишусь.

я попробовал грузить те WAV-файлы, что без проблем грузились в эмулятор от b2m. Но почему-то получил сообщение, что формат файлов неправильный, хотя эти записи нормально грузятся и в реале.

Пожалуйста, пришлите примеры этих файлов, интересно будет посмотреть, что с ними не так.

[Advertiser]

[barsik]

Так что же насчёт МГ-формата орловского монитора. Как такой файл ввести в эмулятор?

принцип эмуляции магнитофона здесь основан на перехвате единственной подпрограммы LDBYTE (C377, С806). Причём предполагается, что эта подпрограмма вызывается из подпрограммы ввода массива

Нет, это не предполагается

Ну так расскажите о принципе эмуляции работы с магнитофоном в вашем эмуляторе. Всем это будет интересно узнать.

Ясно, что для перехвата используется попадание программы на адреса C377 и C806, т.е на стандартную подпрограмму ввода байта. Но не ясно по какому критерию Вы определяете, что прогон программы ввода байта закончился. b2m в своём эмуляторе делает это вполне понятным образом, он контроллирует точки выхода из п/п-рамм ввода байта и вывода байта. Поэтому его эмулятор не проблема настроить на любое ПЗУ конкретного компьютера. А вот как Ваш эмулятор настроить на конкретное ПЗУ нет никакой информации, а догадаться об этом изучая файлы EMU80.conf и Specialist.conf невозможно. Расскажите как Вы определяете, что ввод байта закончился.

для формата MSX, интересно было бы попробовать перехватить также и эти вызовы.

В этом нет проблемы. Т.к побайтовый обмен в любом МГ-формате имеет точку входа и точку выхода, то достаточно отлавливать вход в соответствующую исполнительную часть подпрограммы LDBYTE. Если перехватывать вход в подпрограмму LDBYTE и точку выхода из неё по RET, то Вас совершенно не волнует какой физически формат использует ПЗУ, это может быть даже и не МГ-формат, а например формат передачи по проводний линии со скоростью 8 кб в секунду.

А в ленинградском мониторе перехватывать ввод/вывод в любых форматах вообще не проблема. Так как в нём подпрограммы LDBYTE/SVBYTE векторизованы (идея заимствованая из монитора SP580), кстати, как и в ОРИОНЕ.

Итак, в ленинградском мониторе СПЕЦИАЛИСТА введены два вектора:

8FD3/D4 - ASAVE - адрес исполнительной части п/п-ммы записи байта на МГ
8FD5/D6 - ALOAD - адрес исполнительной части п/п-ммы чтения байта с МГ

а подпрограммы работы с МГ в ленинградском мониторе вот какие:

.
LDBYTE:	PUSH	HL
	LD	HL,(ALOAD)
	EX	(SP),HL
	RET

SVSB:	LD	A,0E6H		; вывод на МГ синхробайта
SVBYTE:	PUSH	HL
	LD	HL,(ASAVE)
	EX	(SP),HL
	RET

Так что, если Вы перехватили точки входа LDBYTE/SVBYTE, то Вы перехватили ввод/вывод байта во всех форматах, в том числе и когда загружен драйвер для обмена по проводной линии.

В ленинградском мониторе при включении частотной MSX-кодировки нажатием НР+F3 (включение обратно фазовой кодировки - НР+F4), то просто в ячейки ALOAD/ASAVE подставляются другие адреса. Однако в ленинградском мониторе в процедурах ввода/вывода используются не тупые программные паузы программной петлёй, а в паузе между фронтами процессор в правом верхнем углу экрана (по адресу из ACOUNT) выводит число - адрес ячейки куда (откуда) в данный момент происходит ввод (вывод) байта.

8FD7/D8 - ACOUNT (B00B) - экранный адрес куда выводится счётчик при вводе/выводе

А если Вы подменяете прогон реальных МГ-подпрограмм, то естественно и счётчика на экране не будет, если только Вы сами не захотите его выводить. Потому в эмуляторе от b2m счётчик при работе с магнитофоном бежит, а при Вашем алгоритме эмуляции магнитофона этого нет.

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

Оказывается эмулятор от b2m тоже не совершенен по работе с магнитофоном. Там тоже какая-то "химия". Т.к он не грузит коммерческие программы защищённые форматом записи (естественно, в WAV-виде). А грузит только программы, что используют стандартную п/п-мму ввода байта.

[Pyk]

Так что же насчёт МГ-формата орловского монитора. Как такой файл ввести в эмулятор?

Я не спец по Специалисту, "Орловский" Монитор - это какой?
(Насчет Ленинградского позже отвечу - не дошли руки пока до него)

[barsik]

Ороловский монитор это основной монитор, который используют все (в т.числе и Вы в эмуляторе) и на который сдуру в программах делают вызовы, тогда как есть ROM-BIOS, жаргонно называемый загрузчиком, т.к это не RAM-монитор, а просто набор 19-ти базовых подпрограмм. Делать вызовы на C800 неправильно, т.к не все применяют именно орловский монитор, мониторов может быть много разных, а ROM-BIOS один.

Но теперь эту неприятность уже не исправить, т.к слишком поздно. Потому что сначала адаптации системного ПО от РК86, а затем и авторские программы некоторых совсем малограмотных товарищей полезли на входы C800. Однако почти все игры работают через загрузчик. Так что теперь орловский монитор - просто стандарт, альтернативы нет. Загрузка по сбросу это свойство загрузчика, не монитора. Для себя я чуть изменил загрузчик, теперь он, по нажатию на НР после сброса стартует из ROM-диска в формате ОРИОНА файл с оффсетом 800.

Орловский монитор характерен тем, что он зачем-то имитирует все основные входы монитора РК86, но по адресу C800, а не F800, хотя схемы совмещения адресации не опубликовали (т.к тогда до этого ещё не додумались). Кстати, прилагательные даже образованные от имён собственных и фамилий людей пишутся с маленькой буквы. Монитор А.Волкова это понятно тот, который был опубликован с самим компьютером и который работает из ОЗУ (8D00), а не из ПЗУ и потому может грузиться с ленты.

В журнале был ещё новожировский монитор и ещё какой-то (увы, сейчас не имею под рукой журналов МК). Но они совершенно не в тему и программы их не используют. Никакого смысла в них нет, т.к любые доработки, в т.числе и содержимого ПЗУ должны оставаться совместимыми, а всё неудовлетворяющее этой аксиоме, это просто чушь. Несовместимость уже попробовал КООП SP580, но всё равно и после них "вылезали деятели", до которых это не дошло.

В волковском мониторе нет формата с именем, только формат пригодный для загрузки по сбросу. Формат с именем также можно загрузить по сбросу, если у пользователя скорость реакции превышает 3 секунды. Для этого надо дождаться когда пройдёт первый пилотон, блок имени и начнётся второй пилотон. Вот тогда и надо нажимать на сброс. Есть много ранних пост-доработок волковского монитора, которые тоже работают в ОЗУ, а дополнительно имеют встроенный дизассемблер КР580 и иногда используют МГ-формат РК86 и есть версии и с форматом ОРИОН CHANGER$, служащие для интерфейса с другими бытовыми ЛК.

Я уже в какой-то теме предложил маркировать формат с именем расширением .SPT (Specialist tape), чтобы не было путаницы с форматом .RKS, при котором в начале файла просто стоят 4 байта с адресами загрузки, а последними байтами вставлена КС (и что неприятно даже байта E6 в начале нет, что очень печально, т.к нарушает логику и делает файл непригодным для прямой конверсии в WAV).

Для автоматизации переименования можно сделать специальную программку на бейсике Quick Basic (или даже Power Basic, который получше, т.к даёт при компиляции меньший и более скоростной код). Эта программка будет проверять все файлы с расширением .RKS и если обнаружится файл у которого в дампе первым байтом стоит D9, то у такого файла расширение имени будет изменено на .SPT.

А то, что в эмуляторе EMU80 по сбросу выскакивает окно для выбора загружаемого файла, то это можно исправить не кастрацией загрузчика, а сделать так, что по нажатию одной красной кнопки сброс, всё как и сейчас - загрузка блока с автостартом уничтожена. Но если нажать кнопку сброс удерживая клавишу <Control> или <Shift>, то выводится окно запроса файла с расширением именно и только .RKS.

[Pyk]

Так что же насчёт МГ-формата орловского монитора. Как такой файл ввести в эмулятор?

Как обычно, с помощью директивы "R". Или я не понял вопрос?

[barsik]

с помощью директивы "R"

Да нет, по директиве R грузится файл в формате волковского монитора (который также может грузиться и по сбросу с автозапуском).

А МГ-файл в формате орловского монитора (т.е файл у которого первый байт E6 затем три байта D9, а затем имя из 16 символов и завершающий 0, далее пилотон любого размера) грузится по директиве I. Если такой файл грузить по директиве R, то он загрузится на D9E6 (или D9D9, если лидирующего E6 нет). Эмулятор от b2m требует, чтобы чтобы первого байта E6 не было, сразу D9 и второй пилотон, что идёт после имени, д.быть не короче 40 байтов.

Посмотрите дамп файлов. Чтобы такой файл конвертировать в WAV для вывода через AUDIO-выход PC на реал, достаточно лишь в начале добавить ракорд (т.е стартовый пилотон 256 нулевых байтов) и первый синхробайт E6. При желании, чтобы был стандарт, второй пилотон (что после имени и перед вторым синхробайтом) можно удлинить до 768 нулевых байтов (но это не обязательно). И затем специальной программой конвертировать коды в WAV-файл.

Длинный второй пилотон в этом формате потому, чтобы дать время тому, у кого только волковский монитор, успеть нажать на кнопку сброс пока звучит второй пилотон. Но если это не надо, то второй пилотон можно сократить до 40 байтов (это время нужное на вывод имени, максимальное время затрачиваемое на это будет при вводе команды I в последней строке, тогда при выводе имени происходит ролик всего экрана).

Во вложении файлы в формате орловского монитора. Все они грузятся как на реале, так и в эмуляторе от b2m по директиве I. Хотя не будет проблем и с орловским монитором, но т.к он неудобный, я использовал ленинградский монитор.

Для этого в каталоге "для эмулятора B2M" приложен дамп этого монитора и конфиг для эмулятора EMU от b2m. Файлы с расширением .cfg надо скопировать в каталог по имени config, а файл монитора BIOS_33.DAT надо поместить в каталог Specialist. При старте выбрать нужную конфигурацию. Каталог с файлами RKS можно скопировать целиком в папку Specialist а, если Вы используете в ней свою папку с именем "МГ-программы", то все файлы перемещаете туда, убрав оттуда предварительно другие файлы с расширением RKS, чтобы не возникло путаницы между RKS-файлами загружаемыми по командам I и R.

Для просмотра текстов описаний, после их загрузки надо стартануть встроенный редактор, для этого нажимаете E<ВК> (в редакторе HELP по F1). На вопрос NEW? ответить N. Т.к тексты в формате 48 символов в строке, лучше включить большой шрифт по НР+F2.

Для загрузки файлов по I в эмуляторе, после сброса нажимаете любую функц.клавишу, чтобы выйти из режима ввода по сбросу. Затем, удерживая SHIFT, нажимаете F2. Шрифт становится заметно разборчивее. Затем нажимаете I<ВК>, затем на вопрос о имени снова <ВК> и сами открываете окно выбора файла нажав на кнопку пуска магнитофона. Выбираете нужный МГ-файл и кликаете на "загрузить". При вводе должен бежать счётчик. Т.е процедура такая же, как и при загрузке WAV-файлов.

Собираюсь на днях нацарапать программку конвертирующую ORD-файлы (а у меня программы для всех 8-ми разрядок в формате ORD) в файлы в формате орловского монитора. Также нужна такая же программка конвертирующая из RKS-файлов в формате волковского монитора.

В итоге, Вы убедитесь, что эмулятор EMU грузит файлы в формате орловского монитора, а как это сделать в эмуляторе EMU80, пока не ясно. Загрузка по сбросу в EMU80, точнее автостарт после неё, тоже пока под вопросом.

[Pyk]

Кое-что успел посмотреть.

Ну так расскажите о принципе эмуляции работы с магнитофоном в вашем эмуляторе. Всем это будет интересно узнать.

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

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

Обнаружил у себя ошибку в загрузчике wav-файлов. После ее исправления загрузились все образцы wav-файлов как в формате по "I", так и по сбросу, кроме SP-COPY. Там какой-то свой формат записи - надо смотреть, почему не грузится.

А то, что в эмуляторе EMU80 по сбросу выскакивает окно для выбора загружаемого файла, то это можно исправить не кастрацией загрузчика, а сделать так, что по нажатию одной красной кнопки сброс, всё как и сейчас - загрузка блока с автостартом уничтожена. Но если нажать кнопку сброс удерживая клавишу <Control> или <Shift>, то выводится окно запроса файла с расширением именно и только .RKS.

Именно так наверное не получится, надо подумать на самом деле, как это лучше сделать. Могут быть разные варианты.

Я уже в какой-то теме предложил маркировать формат с именем расширением .SPT (Specialist tape), чтобы не было путаницы с форматом .RKS

Если народ поддержит, можно и переименовать. А я могу в эмуляторе просто сделать поддержку загрузки rks или spt-файлв с именем из ком. строки или по Alt-F3/L.

В итоге, Вы убедитесь, что эмулятор EMU грузит файлы в формате орловского монитора, а как это сделать в эмуляторе EMU80, пока не ясно.

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

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

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

[свернуть]

[barsik]

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

Это не требуется. В ленинградском мониторе используется не высокоуровневый протокол MSX, т.е все те же служебные байты, заголовки и т.п. что есть в компьютере MSX. А лишь заменяется низкоуровневый формат. А протокол, т.е пилотон, синхробайт, байты D9, имя файла и т.п - всё остаётся как и ранее. Т.е можно также выводить и по W и по O и затем соответственно грузить по R или I.

А на слух после нажатия на НР+F3 просто меняется звук, вместо шипа идет более приятный тональный сигнал. Но MSX двухчастотный формат несмотря на всю известность менее надёжный, чем двухфазный и ничуть не быстрее. Точнее при одной и той же скорости передачи MSX требует более высокого качества лентопротяга и ленты и вдвое большей полосы канала.

Что меняется оттого, что одна подпрограмма вывода байта заменяется на другую подпрограмму вывода байта? Причём так можно менять на любой формат, в том числе и проводной программный и проводной аппаратный (это с ВВ51). А т.к точки входа LDBYTE/SVBYTE не меняются, то если перехватывать именно эти точки, то ничего больше делать не надо.

загрузились все образцы wav-файлов как в формате по "I", так и по сбросу, кроме SP-COPY. Там какой-то свой формат записи - надо смотреть, почему не грузится

Смотреть не надо... Точнее это бесполезно. Никогда по такому алгоритму эмуляции не загрузить программу защищённую от копирования. B2M кстати тоже нихрена не грузит, а вот проверьте на реале и убедитесь, что всё грузится.

Там только первые блоки идут в стандартной кодировке. Первый блок первичный загрузчик грузится в экран и выводит мигающую надпись "DO NOT STOP TAPE !". Второй блок - это основной загрузчик, он тоже грузится ещё в двухфазной кодировке. А следующий блок идёт уже в двухчастотной кодировке, причём не в той же самой, что прошита в мониторе, а в вариации - на слух то же самое, но байты не грузятся стандартной подпрограммой. Обычно также используются ухищрения - типа загрузка кода в обратном порядке, т.е от старших адресов к младшим, с перестановкой байтов с шагом 2 или 4 и XOR-ом вводимых байтов с E6.

Поэтому самОй SP-COPY её саму не скопировать. Этот копировщик берёт только двухфазный формат. Но он позволяет легко копировать примитивные защиты, что были в ходу в начальные годы. Защита была основана на том, что первый блок после загрузки и автостарта меняет константу ввода перед вводом второго блока и считает паузу до начала второго блока. Время паузы является ключом при декодировании второго блока. Это самая простая, но вполне эффективная защита и эмуляторы её тоже не берут.

Такой формат никак не скопировать вручную. А SP-COPY делал идентичную копию таких программ. Он запоминал константы ввода для каждого блока и паузы между блоками. Но есть некопируемая разновидность этого метода, когда константа ввода меняется прямо в ходе загрузки, изменясь при вводе очередных 128-ми байтов плавно или по случайному закону.

SP-COPY работает из экрана, отдавая под буфер ввода все 36 кб. А орионовская версия имеет буфер в 48 кб. Но гораздо круче копировщик работающий с электронным диском. Он грузит не в ОЗУ, а сразу во внешний эл.диск и позволяет копировать многоблочные программы любого размера.

У меня было много защищённых от копирования программ СПЕЦИАЛИСТА, в т.числе и ценные. Они не сохранились, сохранились лишь те, к которым я имел авторский инсталятор. Так пропали адаптации ZX-игр. Инсталяторы тоже, кстати, нихрена не работают в эмуляторах, т.к в них не используются стандартные подпрограммы вывода.

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

Это не позволит грузить многоблочные программы, т.к между загрузками блоков нет вызовов подпрограмм опроса клавиатуры (особенно C803, C81B ещё может быть для контроля на аборт), а программы написанные виртуозами не используют для опроса клавиш стандартные подпрограммы.

[Pyk]

Смотреть не надо... Точнее это бесполезно. Никогда по такому алгоритму эмуляции не загрузить программу защищённую от копирования.

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

Это не позволит грузить многоблочные программы, т.к между загрузками блоков нет вызовов подпрограмм опроса клавиатуры (особенно C803, C81B ещё может быть для контроля на аборт), а программы написанные виртуозами не используют для опроса клавиш стандартные подпрограммы.

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

[uart]

Смотреть не надо... Точнее это бесполезно. Никогда по такому алгоритму эмуляции не загрузить программу защищённую от копирования. B2M кстати тоже нихрена не грузит, а вот проверьте на реале и убедитесь, что всё грузится.

Можно wav с такой программой? Вообще не вижу чем загрузка на реале отличается от загрузки на эмуляторе...