uart, я так понимаю, что вот эти из архива "tape for check":
SP-COPY (auto)' EXE.wav
SP-COPY (auto) EXE.wav
Не грузятся ни в моем эмуляторе, ни в твоем. С jet-set на первый взгляд проблем нет (у меня vmWare зависает в процессе загрузки).
uart, я так понимаю, что вот эти из архива "tape for check":
SP-COPY (auto)' EXE.wav
SP-COPY (auto) EXE.wav
Не грузятся ни в моем эмуляторе, ни в твоем. С jet-set на первый взгляд проблем нет (у меня vmWare зависает в процессе загрузки).
jet-set.wav загрузился, а с этими что-то не так.
И в эмуляторе от b2m тоже не грузятся.Сообщение от Pyk
Похоже, что в этих эмуляторах нет честной работы в реальном времени. Возможно там и при вводе WAV какая-то "химия", основанная на перехвате известных входов в подпрограммы, а не работа в реальном времени. А если с лентой работает другая подпрограмма с другими входами, тут эмуляторы обламываются.
Хотя при вводе WAV-файла казалось бы всё должно быть честно. Иначе почему не грузит WAV-записи в другом низкоуровневом формате. И не выгружает - инсталяторы, которые пишут защищённые от копирования программы тоже не работают.
В EMU80 от Pyk вообще нет записи WAV-файла. А в EMU от b2m якобы что-то пишется в WAV, но файл оказывается тишиной. Пока в EMU80 не проверить ввод WAV-файла и неизвестно сделан там ввод WAV-файла честно или тоже "химия" на перехвате входов.
А вот мой MSDOS эмулятор на тормозной 386SX33, что в 500 раз тормознее современных PC все защищённые МГ-программы грузились прямо с реального магнитофона. Потому что там все команды ввода/вывода на МГ-порт 8-ми разрядки переадресовывались на реальный ВВ55, стоящий на самодельной платке втыкаемой в ISA-слот. И через обычный МГ-адаптер всё читалось. Можно и без платки c ВВ55, а читать всё через бит параллельного LPT-порта. Но это не работает на ПЕНТИУМЕ, даже на самом медленном, т.к там даже без Windows прерывания от интегрированных устройств на плате рвут прогон программы в реальном времени.
А вообще-то и прекрасно, что эмуляторы нихрена не читают WAV-файлы в реальном времени. Это значит, что как и в 80-тые можно делать МГ-программы которые будет сложно кракнуть, просто потому, что их не ввести в эмулятор, чтобы воспользоваться волшебной кнопкой и слить всё ОЗУ с регистрами в RSS-файл. Т.е получается и на реале не кракнуть и в эмуляторе не обмануть.
Вы хотите сказать, что по окончании загрузки первого блока путём вставки фиктивного пилотона большой длины, пользуясь тем, что нет чтения клавиш (что служит у Вас признаком конца МГ-ввода) Вы предотвратите закрытие файла. Верю.Как раз наоборот, если для многоблочной программы записать все блоки в один файл, то он будет успешно грузиться
Но первый блок начинает работу с того, что ждёт начало пилотона второго блока и программно считает время паузы. Дождавшись пилотона, он фиксирует время паузы и стартует программа определения константы ввода. А у Вас это вообще не сработает, потому что подпрограмма определения константы ввода сама лезет в порт МГ, а не получает уже готовые байты из подпрограммы LDBYTE.
Кстати именно поэтому ленинградский монитор ничерта не работает в EMU80, но работает с EMU от b2m. Это из-за автонастройки на скорость записи. Монитор просто виснет в подпрограмме автонастройки ожидая фронтов на МГ-входе, а в эмуляторе EMU80 фронты на входе МГ не эмулируются. Вот оттого ленинградский монитор и виснет в процедуре автонастройки. Вскоре попробую отключить автонастройку на скорость, тогда будет работать.
А грамотно надо перехватывать не входы в подпрограмму LDBYTE, а команду КР580 читающую из МГ-порта ! Т.е честно эмулировать прогон программы в реальном времени. С таким алгоритмом эмуляция магнитофона будет 100% точно соответствующей реалу.
Вообще-то, раз хоть одна многоблочная программа уже пошла грузиться, то значит WAV более менее честно читается, т.к первый блок всех многоблочных программ всегда содержит процедуру автонастройки на скорость записи, определяя скорость ввода второго блока.
Но при вводе не WAV, а RKS (т.е готовых кодов) объединение блоков в сплошной массив не поможет. Ведь суть много блочной программы заключается в том, что блоки стартуют. По концу загрузки первого блока он сразу стартует и начинает выполнять программу по загрузке второго блока. А если вы перехватите ввод в начале ввода первого блока, то вы просто сольёте в ОЗУ весь массив блоков, а что это даст? А надо, чтобы сразу по окончании ввода первого блока он стартанул. В концепции b2m с перехватом точки выхода из LDBYTE, это сработает, а с Вашей "химией" не сработает.
Я пытался кракнуть некоторые подобные программы. Но там не только защита ввода МГ-форматом, но и запутывание дешифровщика с помощью недокумментированных команд. Отладчик не помогает, приходится дешифрировать вручную, а код специально так запутан, как побочный эффект ставит флаги, которые проверяются после. Причём и изменить ни одного байта в коде нельзя.
Кстати, SP-COPY вообще не использует подпрограмм из ПЗУ, поэтому ПЗУ можно снять, а программа продолжит работать. Для крака в качестве ПЗУ ставится такое, что обеспечивает копирование кода SP-COPY из экрана на 0. Нажав сброс я получил сам код SP-COPY, но не знаю какая точка входа. В эмуляторе это узнать не проблема.
А JET-SET это не защищённая программа, это просто многоблочная программа в обычном двухфазном формате. Она копируется с помощью SP-COPY. Чужие программы от копирования не защищались. Все игры из пакета SP580 были переделаны под стандартный СПЕЦИАЛИСТ, а некоторые, что стоили того, были сделаны многоблочными. Защищались от копирования только авторские программы, которых ещё ни у кого нет.
Прилагаю инсталятор SP-COPY для ОРИОНА. Он работает на СПЕЦИАЛИСТЕ с ленинградским монитором 3.3 (!), но пишет на ленту защищённые копии для ОРИОНА. Нихрена не работает в эмуляторах. С орловским монитором работать не будет. т.к использует встроенный в ПЗУ драйвер MSX. Есть инсталяторы и других программ ОРИОНА. Кстати эти защиты программ для ОРИОНА форматом MSX никто так кракнуть и не смог. Надо на реальном СПЕЦИАЛИСТЕ сделать копию на ленту. Тогда это можно будет грузить на ОРИОН по I (управление вышибает).
Про многоблочные программы и SP-COPY можно прочитать здесь.
Последний раз редактировалось barsik; 28.12.2017 в 07:21.
Монитор где взять?
В вложении поста #216, в теме "Ленинградский монитор" или во вложении этого поста. В файле OOO.RAR также предыдущий монитор 2.7, он немного хуже, но в нём есть некоторые команды, которые иногда нужны при компоновке блочных программ (запись блока без адресов загрузки), а также запись в формате ZX. Описание команд монитора можно найти здесь. Перевложил сюда предыдущую выкладку монитора, там кажется исходники. Для эмулятора EMU от b2m файлы конфига переместите в каталог config, остальные файлы в каталог Specialist.
В минимуме достаточно 2 ПЗУ (C000...CFFF), но лучше 3 ПЗУ РФ2 (C000...D7FF). Остальное - редактор, ассемблер и RAMDOS факультативно. На месте RAMDOS D800...DFFF вставлены коды FF, т.к внешнего эл.диска на РУ7-мых ни у кого нет и в эмуляторах он не эмулируется (хотя это несложно сделать).
Попозже хотелось бы попробовать переписать RAMDOS так, чтобы носителем был не внешний эл.диск на РУ7-мых, а внутренний RAM-диск на базе запасных банок ОЗУ, коммутируемых портом F9. При переключении банки все 62 кб становятся ОЗУ другой банки. Но доступ в это ОЗУ только через п/п-ммы F836/39. Аппаратно это легко делается заменой РУ5 на РУ7, для чего ставится доп. КП12 и регистр номера банки на 155 ТМ2. Такой эл.диск в 186 кб больше, чем у ОРИОНА (60+60+48=168) и Корвета (144 кб).
- - - Добавлено - - -
Хотел бы сделать для проверки эмуляторов простую много блочную программу с простейшей защитой изменением скорости и паузами между блоками, но забыл где встречал программку для конверсии файлов .RKx в WAV. Если кто в курсе киньте, пожалуйства, ссылку.
По идее эмуляторы должны писать в WAV-файл, но что-то пока у меня не получилось. EMU80 вообще в WAV не пишет. А в EMU возможно конфиг не настроен на подпрограммы выхода из SVBYTE, вечером попробую из EMU с орловским монитором писать в WAV-файл.
Частично могут помочь программы вывода типа RKWIN.EXE, что выдают коды в WAV-формате на AUDIO-выход PC и мой магнитофон "Легенда-404" с пассиком из бытовой резинки. Но сначала надо как-то подготовить блоки в WAV-формате.
Можно было бы вывести звуки и на встроенный в мобильный телефон диктофон, подавая сигнал через разъём гарнитуры, но пока жалко ломать гарнитуру от телефона.
Можно также вывести звуки не в магнитофон, а в реальный ОРИОН с работающим на нём копировщиком SP-COPY прямо с выхода PC на его МГ-вход. Но как назло SP-COPY не может работать на Z80, т.к использует недокументированные команды КР580 для защиты от кракеров.
А для заставок при МГ-вводе нужны готовые заставки в формате экрана ZX-Spectrum. Есть подпрограмма вывода ZX-экрана на экран СПЕЦИАЛИСТА в монохроме. Но раз в эмуляторе есть цвет, то можно переделать её для вывода в цвете. Это не автоматизировать, раскраску картинок придётся делать вручную. Придётся написать специальную программку для раскраски, т.к цвет СПЕЦИАЛИСТА другой и сильно уступает в цветовых возможностях. Можно даже сделать, чтобы заставка при вводе с МГ грузилась также как на ZX, в виде неподряд выводимых линий.
Последний раз редактировалось barsik; 27.12.2017 в 15:57.
barsik, у меня в эмуляторе при загрузке wav-файла никакой "химии" нет - просто честно эмулируется железо. Если sp-copy грузится на реале, но не грузится в эмуляторе, возможно, есть какие-то погрешности в эмуляции.
Что же касается режима работы с перехватами, то я от него и изначально многого не требовал: грузятся большинство обычных файлов (без защиты и одноблочные) - уже хорошо. К сожалению, в Ленинградском Мониторе это не работает, надо подумать, что с этим можно сделать. Если есть какие-то предложения по реализации перенаправления магнитофона в файл - с удовольствием выслушаю.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Тут возник вопрос как грузить RKS и WAV-программы, что грузятся по сбросу в эмуляторах EMU80 и EMU. В реальности оказалось, что оба эмулятора не готовы грузить файлы по сбросу, хотя это самое врождённое свойство СПЕЦИАЛИСТА.
К эмулятору EMU от b2m претензий почти нет. Он по сбросу всё грузит, - и RKS и WAV. Но для ввода WAV надо знать маленький нюанс.
А EMU80 пока вообще "вне игры" до выхода нового релиза. WAV-файлы EMU80 по сбросу просто не грузит. RKS-сбросовые файлы теоретически грузит, если ему поставить оригинальный (МК 05.1987) или зверковский (МК 04.1988) загрузчик вместо того слегка кастрированного, что идёт в дистрибутиве.
Но лишь теоретически. Точнее можно было бы пользоваться EMU80 с ленинградским монитором, но увы, он виснет на процедуре автонастройки на скорость. А с базовым загрузчиком вообще возникла проблема. Не смог в нём выйти в монитор. В базовом загрузчике выход в монитор делается так - нажимаем на <STOP>, затем на <ВК>. C ленинградским монитором, в который встроен выход отовсюду, - вообще проще. Если программа хоть как-то читает клавиатуру (а это - 90% программ, 10% это игры со своей программой сканирования клавиш), то для выхода в монитор достаточно ввести НР+F9 (нажать F9 удерживая клавишу НР). А для выхода из загрузки в реале достаточно просто нажать на любую функциональную клавишу.
В ленинградском мониторе удобны клавиатурные прерывания вызываемые по НР+F1...F9, хотя без ПЗУ D000 они не работают. Это очень удобно, например, если начался ввод на оригинальном загрузчике, то его уже никак не прервать, причём даже тайм-аут сигнала не обрабатывается. А с ленинградским монитором, если надо прервать ввод с МГ или вообще любую программу, нажимает НР+F9 и мы в мониторе.
Так вот, с некастрированным загрузчиком RKS-файлы по сбросу можно загрузить и они автостартуют. Но ведь в большинстве случаев нам надо просто выйти в монитор, а не автостартовать по сбросу. Как указано выше, достаточно нажать на <STOP>, затем на <ВК> и мы окажемся в мониторе. Но, во первых, как сходу найти эту кнопку <STOP>, т.к никакого окна с картинкой клавиатуры, как есть на многих эмуляторах ни в EMU80, ни в EMU не предусмотрено. Но проблема даже не в этом, а в том, что уйдя в окно ввода файла с винчестера по первому же вызову CALL LDBYTE (C377) в эмуляторе EMU80 уже нельзя выйти в монитор.
Это происходит потому, что в EMU80 эмулируется ввод целого блока, а не ввод байта как в эмуляторе от b2m. Когда работает подпрограмма C3F9 в ПЗУ, что и делает ввод блока с ленты, то её работа может быть прервана нажатием на <STOP> или на любую функц.клавишу.
А EMU80 этот код вообще не прогоняет, а просто игнорирует, - по первому же CALL LDBYTE прерывает прогон (эмуляцию команд КР580) и возвращается к эмуляции кода 8-ми разрядки только когда произойдёт CALL на опрос клавиатуры. Мне вообще кажется этот метод дико некорректным, потому что существование стека просто игнорируется. Т.е программа может делать CALL F803 находясь в подпрограмме, а куда мы тогда вернёмся по RET, если в стеке нет адреса возврата, т.к CALL не прогонялся.
По этой причине и пришлось кастрировать загрузчик, забив в нём загрузку по сбросу. Если нажать "отмена", то так и остаётся висеть надпись "ПРОГРАММА ?" и на клавиши не реагирует. Потому единственный способ выйти в монитор это написать программу из одной команды JMP C800 и, оформив её как RKS-файл, стартовать по сбросу всякий раз. Вот полный код этого RKS-файла: 00,00,02,00,C3,00,C8,8B,C3.
Таким образом, совершенно очевидно, что концепция эмуляции ввода целого блока, полностью игнорируя весь программный код начиная с первого же CALL LDBYTE до последующего первого вызова опроса клавиатуры, - глубоко порочен. Это "химия" даже более высокого порядка, чем просто подмена вызова LDBYTE с возвратом каждого байта из дискового файла. Эта "химия" и не позволяет грузить программы по сбросу и не допускает загрузку многоблочных программ. Это и объясняет почему в эмуляторе EMU80 не нужен реально нужный программам первый синхробайт E6. Поэтому-то Вы его исключили из формата RKS. Конечно такая "химия" в реализации очень проста, но она сработала только потому, что на РК86, ОРИОНЕ и СПЕЦИАЛИСТЕ мало многоблочных и коммерческих программ, но они всё-же есть.
Гораздо более правилен алгоритм подмены не ввода целого блока, а только единственной подпрограммы LDBYTE. Для чего достаточно отлавливать всего 2 точки - это вход в подпрограмму и выход из неё по RET. Именно так и сделано в эмуляторе от b2m. Там тоже по первому же вызову CALL LDBYTE открывается окно запроса имени файла, затем при последующих CALL LDBYTE программе выдаётся 256 нулей, синхробайт E6, и только потом начинается чтение байтов из файла RKS. Совершенно очевидно, что логично было бы и все байты пилотона и байт E6 тоже иметь в файле. Это бы жёстко фиксировало формат, упростило бы эмуляторы и позволяло бы простую конверсию файла кодов в файл звуков и наоборот. А закрытие файла делается автоматически после прогона тысячи команд КР580 без вызова CALL LDBYTE. Это проще и эмулятору не надо отлавливать подрограммы опроса клавиатуры, чтобы сделать вывод о конце ввода с ленты и закрыть файл.
Чтобы было идеально, т.е с точностью реального времени, эмулировать надо фронты на МГ-входе. Тогда по открытию файла, ориентируясь на число машинных тактов прогнанных команд и константу ввода (из ячейки 8FFF), ну например, через 3000 машинных тактов меняется фронт на входе МГ, естественно, в соответствии с двухфазной кодировкой, т.е нулевой бит кодируется как 1,0, а единичный бит как 0,1. А ещё лучше сразу закодировать данные в файле точно также как они идут в реальной записи. Это увеличит размер файла всего лишь вдвое. Впрочем, концепции применённой в эмуляторе EMU от b2m с заменой подпрограмм LDBYTE/SVBYTE вполне достаточно. Более точная эмуляция не даст решающих преимуществ.
А загрузки WAV-файлов по сбросу в эмуляторе EMU80 вообще нет, только сбросовый формат RKS. Итак, с загрузкой по сбросу на EMU80 разобрались, - её пока нет ни в каком виде.
Но и с EMU от b2m для загрузки по сбросу тоже есть нюансы. Проблемка возникает из-за того, что по нажатию на красную кнопку СБРОС останавливается магнитофон, что делает загрузку по кнопке СБРОС невозможной. Надеюсь когда-нибудь b2m это исправит.
По счастью в ленинградском мониторе на этот случай предусмотрена директива B. Она не особо сложная и состоит всего из одной команды JMP C000 и служит для того, чтобы введя в строку букву 'B', можно было бы нажать на <ВК>, как только послышится пилотон. Дело в том, что изредка встречаются образцы плат в которых кнопка СБРОС иногда приводит к порче ОЗУ. Вот чтобы этого уж точно избежать и была введена эта команда.
Тогда в эмуляторе B2M набираем команду B, запускаем магнитофон, выбираем автостартующую или многоблочную программу и нажимаем <ВК>. Можно нажимать даже раньше, чем пошёл пилотон, т.к в эмуляторе шумов в линии, что в реале иногда могут вызвать ложный захват синхробайта, уж точно нет, т.к с ленты просто ничего не читается, а читаются уже готовые байты из дискового файла.
Если же используется не ленинградский монитор, а или родной (на 8D00) или орловский, в которых директива B отсутствует как класс, то тоже есть выход. Набираем команду GC000 (в родном мониторе это JC000) и после "включения магнитофона" нажимаем на <ВК> (это клавиша Enter).
Ленинградский монитор не работает из-за того, что перед запуском процедуры поиска синхробайта, с чего начинается любая загрузка, он делает CALL CONST - вызов подпрограммы настройки на скорость. Эта подпрограмма не вызывает LDBYTE, а сама лезет в МГ-порт считывая фронты, а на выходе просто подставляет вычисленную константу в ячейку CLD (8FFF). Если настройку на скорость не вызывать, то константа CLD останется стандартной. А т.к фронтов на порту PB0 ППА Вы не эмулируете, то процедура настройки зависает навечно тщетно ожидая прихода хоть какого-то фронта на МГ-вход. Т.к автонастройка предшествует всем вводам с ленты, то возможно поможет если делать перехват на этом CALL. Но достаточно в коде ПЗУ этот CALL CONST забить. Например байт 0CDH заменить на 21H или просто забить 3 байта нулями.
Да, а в самом эмуляторе надо менять алгоритм работы с магнитофоном, сделать также как это в эмуляторе EMU - отлов входов и выходов п/п-рамм LDBYTE/SVBYTE.
Последний раз редактировалось barsik; 28.12.2017 в 09:42.
barsik, спасибо за отзыв. Я, конечно, про все эти проблемы знаю. Более того, надеюсь, что бо̒льшую часть их мне удалось уже решить - на днях будет новый релиз.
Но, к сожалению, вы не везде сделали правильные предположения о причинах этих проблем, поэтому небольшие комментарии:
Как я уже говорил, это неверно.
Это тоже неверно.
Естественно, существование стека не игнорируется.
Еще раз - это неверно. О том, как на самом деле это работает, я уже писал выше в посте № 217: перехват ввода опроса клавиатуры используется только для определения момента, когда пора закрывать файл.
Можно сделать опционально. Насколько я помню, я даже пробовал такой вариант еще в первых версиях эмулятора, но для типичных случаем реализованный в настоящее время вариант мне понравился больше, его и оставил.
Pyk, а эмуляцию компьютеров "лик" и "спектр001" увидим в новом релизе ?
Ещё из пожеланий - было бы здорово увидеть виртуальную клавиатуру.
Чтобы забить в ленинградском мониторе автонастройку на скорость надо поставить в начале подпрограммы настройки на скорость (это метка @KNSRD в исходнике C800) код команды RET. Это подпрограмма вызывается из многих мест, поэтому лучше забить именно здесь. Кстати, напоминаю ленинградские ПЗУ С000 и C800 это единая программа, а не отдельно загрузчик и монитор, нельзя подменить ПЗУ C000 на загрузчик Зверкова или Волкова или ПЗУ C800 на монитор Орлова, - там это отдельно загрузчик и монитор, здесь же это одна единая программа с перекрёстными вызовами.
Итак, чтобы забить автоопределение константы ввода, чтобы не было зависа на ожидании фронтов на МГ-входе, надо в ROM-BIOS версии 3.3 (но не 3.4) заменить байт E5
по адресу CEDF: E5 на байт C9 (т.е команду PUSH HL на RET). После этого зависа в эмуляторе при директивах R и I не будет.
После такой переделки ПЗУ эмулятор EMU80 стал работать с ленинградским монитором, исчез завис при запуске магнитофоных команд и стало наконец открываться окно выбора файла после нажатия <ВК> в МГ-директивах R и I. Т.о эмулятор стал наконец грузить с магнитофона файлы в формате RKS (хотя что считать форматом RKS не ясно), точнее идёт загрузка как по директиве I, так и по директиве R. Расширение у файлов одинаковое, а вот формат заголовка разный, из-за чего постоянно приходится смотреть дампы файлов, чтобы узнать в каком они формате.
Надо вводить новое расширение для файлов, чтобы не было путаницы или вводить возможность загрузки в эмулятор файла с любым расширением, тогда уж каждый сам переименует, как ему нравится. Пока приходится выкручиваться маркируя файлы регистром букв в имени.
Но вот, что совершенно непонятно, так это почему у эмулятора EMU от b2m не было никаких проблем с ленинградским монитором из-за процедуры настройки на скорость. Из-за этого я и решил, что EMU работает в реальном времени, а не "химическим" способом и при вводе готовых кодов из файлов RKS (т.е не звуков из WAV-файлов, там поятно, что ввод в реальном времени). Теперь уже и не знаю чего думать.
Значит у Вас тоже обычная химия, а не химия более высокого порядка. Это успокаивает.
Читается не сразу весь блок, а по каждому CALL LDBYTE читается один байт из дискового файла. Но вот куда Вы дели байт Е6 ? Это и вводит в заблуждение. Ведь только по его прочтению, начинается собственно ввод файла. А раз программа его не получает, значит и ввод программой 8-ми разрядки не происходит. И ещё вводит в заблуждение, что у Вас нет критерия для определния выхода из п/п-мм LDBYTE/SVBYTE. Как Вы тогда узнаёте конец ввода/вывода байта?
Если у кого проблемы с редакцией кодов (нет ни UltraEdit, ни HEX-Edit) и для тех кто не разбирается в конфиг-файле эмулятора, вкладываю изменённый монитор и конфиг-файл для EMU80. Скопируйте их в папку \EMU80\SPEC\ (это папка Специалиста, а не спека ZX-Spectrum).
Последний раз редактировалось barsik; 28.12.2017 в 11:37.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
