Никаких попыток расширять форматы образов под этот случай не было. Сейчас нет под рукой базы с этой прогой, но, вероятно, выехали на том, что эмуль, при попытке выехать за 34-й трек, не двигает виртуальную головку, а значит, если адресные поля в nib на 34-м треке переделать в поля 35-го трека, защита будет вполне довольна.

В Освободителе защита простая, не помню о ней никаких подробностей, а значит он заработал на эмулях сам по себе. Это возможно, если защита построена на модифицированных номерах томов или на нестандартных
первых байтах GAP полей. Такая инфа может, при обработке образов, сразу передаваться от сырых образов в nib-файл.

Номер тома легко проверить в любых более-менее стандартных драйверах, обычно это предусмотрено в их API.
Так что это часто использовалось. Номера томов, как правило, не копируются копировщиками и не входят в DSK-образы.

С GAP-полями немного сложнее, это уже чуть-чуть модифицировать драйвер дисковода. Но тоже бывали случаи применения.

1) Если это агатовский диск 140ка, то там либо агатовский же продукт, а без файловой системы на 140ке - это не особо много программ. ALV Graf, Школьница, BTK, Агат-Отладчик, Агат-Ассемблер, может быть ещё с десяток крупных пакетов; в основном для семёрки. Почти никто из них не защищён.

В чистом виде не имеет файловой системы только ALV Graf. Остальные не используют ФС в областях загрузки, но каталог присутствует, файлы записывать можно.

Но как раз для этого случая сложность будет в том, что эти проги, как правило, не поддерживают 840ку и её формат файловой системы. А значит, их удастся загрузить с 840ки, но не полноценно использовать. Всё таки переработать поддержку файловой системы - задача много более сложная, чем просто заменить драйвер.

Драйвера, как правило, имеют сходные, довольно простые, интерфейсы и сходно организованный код.

2) Либо это эпловская игра, перенесённая на Агат, но тогда защит там почти наверняка не будет (их уже отломали или их там и не было).

> без файловой системы

Так что только замена драйвера (или драйверов, если их там больше одного) в самом простом случае.
Данные перенести по тем же адресам, что в исходном диске.

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

Если задача просто взять файлы или программы с диска 140Кб и перенести их на диск 840Кб, то наверно обычного копирования хватит. Конечно, при условии, что программы не хранят каких-то данных по абсолютным адресам на диске и не пытаются использовать свою собственную копию RWTS.

Если программы что-то такое делают, то надо лезть внутрь каждой такой программы и патчить код. Например, искать и менять адреса данных на диске или менять код RWTS.

Хуже всего, если диск загрузочный. Хотя код загрузчика может и не придется менять, но вот тот код, который этот загрузчик загружает, работать не сможет. Его придется переделывать.
То есть, если с диска грузится ДОС, то она конечно ждет дисковод 140 Кб и ее надо будет патчить, чтобы она смогла работать с дисководом 840 Кб. Но это более простой вариант - все-таки вариантов ДОС не так много.
Хуже, если там не ДОС, а полнодисковая игра. Там, скорее всего, будет какой-то огрызок от ДОС, который может работать с диском по каким-то своим правилам. Патчить его будет труднее всего.

Короче, простого универсального метода тут быть не может.

Вот мы же видели как например "Алиса" устраивает эмулятор 140кб диска на поверхности 840. При этом используя только 16 секторов на треке. Знаем про 4-х томную систему. Видели что в девятке эпловские игрушки занимающие целый диск 140 кучами переносят на 840.

Какие есть варианты? Поделитесь мыслями и идеями.