И в эмуляторе от 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 можно прочитать здесь.
Ответить с цитированием
Размещение рекламы на форуме способствует его дальнейшему развитию 
