КР1818ВГ93 изнутри ...

[Vadim]

В e-zine DejaVu была схема переделки BDI в составе Пентагона под дискеты высокой плотности HD

А как насчет программной поддержки? Аппаратно то, ясен пень сделать несложно, а вот будут ли работать программы? Если добавить кол-во секторов на треке (это как бы самый правильный вариант), то очень много программ не запустятся, они считают что секторов то 16, на трек. Если попробовать сделать пересчет и увеличить кол-во треков, то тогда может что и получится.

Команда Read Track по документации должна считывать всю дорожку от индексного импульса до индексного,

Когда я писал первые процедуры для работы с диском на Профи, в ЦПМ, то начинал сначала разбираться с командами имея на руках скудное описание. Доступ к ВГ93 на профи полный, порты открыты. Делал и чтение дорожки. Дорожка читается, вся. Вероятность рассихнронизации выше чем хуже читается дискета, и чем хуже дисковод. Если мы только что отформатили дискету на FD-55 то команда чтение дорожки с вероятностью 70-80% прочитает весь трек верно. Если дискета писана другим дисководом то вероятность падает до 5-10%. Причем сбой синхры может начаться где угодно, в любом месте диска.

Помню, что делал в обход этого глюка защиту для Софтстаровской версии Street Fighter'а,

На профи многие программы которые продавал Кондор (в режиме ЦПМ) имели защиту. Сделана была именно таким вышеописанным способом. Читался весь трек командой "чтение дорожки", потом в определенном месте, в межсекторном промежутке, искалась определенная сигнатура, скажем:
+0 A
+1 B
+5 C
+7 D

Если сигнатура не найдена, то производится несколько попыток, после чего программа говорит что копия нелиц. Ни один копировщик на спектруме не преодолел эту защиту. Пробовал я копировать и на ПЦ через FDA - эффект аналогичный, межсекторные данные все копировщики откидывали, заменяя их стандартными пробелами.

[psb]

Если мы только что отформатили дискету на FD-55 то команда чтение дорожки с вероятностью 70-80% прочитает весь трек верно.

если мы на дорожку записали определенные байты, то 100% именно в этом месте будет рассинхронизация. на любом дисководе, на любой дискете. перепроверено в свое время 100500 тыщ млн. раз.

[spensor]

А как насчет программной поддержки? Аппаратно то, ясен пень сделать несложно, а вот будут ли работать программы? Если добавить кол-во секторов на треке (это как бы самый правильный вариант), то очень много программ не запустятся, они считают что секторов то 16, на трек. Если попробовать сделать пересчет и увеличить кол-во треков, то тогда может что и получится.

Ну насчет пня и несложно вопрос зыбкий, переделка там основательная и не на всякий клон нахлобучишь, но в целом задача решаемая. А насчет программной поддержки это действительно сложно - для использования таких дискет требуется загрузить коммандер с обычной дискетки (ну или HDD и тому побобного) и уже в коммандере пользоваться, в нынешних реалиях как минимум глупо. И второй вариант патчить TR-DOS, причем там совсем не все гладко, как минимум загрузчики программ не должны иметь оторжения ситуаций когда номер сектора >16. А если принять во внимание что от правила "16 секторов" прыгают все процедуры в TR-DOS, те же FORMAT, MOVE то пределка совсем нетривиальная получается.

если мы на дорожку записали определенные байты, то 100% именно в этом месте будет рассинхронизация. на любом дисководе, на любой дискете. перепроверено в свое время 100500 тыщ млн. раз.

Именно так, в теме которую я указывал выше, Lion17 дал исчерпывающий ответ по этой проблеме http://zx.pk.ru/showpost.php?p=16970. Вопрос только остался за тем почему так, и можно ли побороть схемной обвязкой.

[Titus]

Именно так, в теме которую я указывал выше, Lion17 дал исчерпывающий ответ по этой проблеме http://zx.pk.ru/showpost.php?p=16970. Вопрос только остался за тем почему так, и можно ли побороть схемной обвязкой.

Поискал в старых тетрадках и нашел комбинацию из 9 бит, которая гарантированно дает сбой при чтении трека на ВГ, и при отсутствие которой, трек читается гарантированно правильно. И эта комбинация000101001, что в просторечии можно представить, как 0x029. Но еще раз замечу, что эта комбинация не из 8 бит, а из 9.

Подробности механизма сбоя не помню, но очень так на вскидку мне кажется, что есть два режима чтения MFM-последовательности. Первый - это внутри блоков данных и заголовков, когда контроллер уже правильно синхронизирован на MFM-данные, и просто их читает. Второй режим, это когда контроллер может правильно синхронизирован, может нет, но готов синхронизироваться по первой последовательности 0100010010001001 (MFM). В режиме чтения дорожки целиком, контроллер всегда находится во втором режиме, в результате чего не только правильно синхронизируется в нужных местах, но в том числе и сбивает синхронизацию о комбинации 000101001, если они встречаются внутри блоков данных. Причем, если сбился, то перепутывает тактовые биты MFM кода и собственно биты данных, в результате чего на выходе MFM-декодера имеем абакадабру. Ну это так, чисто теоретически на вскидку.

[ZXMAK]

Помню, что делал в обход этого глюка защиту для Софтстаровской версии Street Fighter'а, где как раз использовалось чтение всей дорожки целиком. Т.е. информация на диске была записана не в виде секторов, а в виде единого сплошного потока бит. Но, чтобы сбоя не было, я исключал из потока данных комбинацию, приводящую к сбою. Сейчас уже не помню, какую )

эту? (cм.аттачмент)

с этой защитой интересная ситуация вышла, когда писал эмулятор ВГ93 для первого ZXMAK (в нем используется довольно глубокая эмуляция для ВГ93).

Деталей сейчас точно не помню, но суть примерно следующая.
Игрушка почемуто не хотела работать если сектор читался с неправильным CRC (а именно с неправильным CRC она и была записана на дискете), но читалась и работала если ВГ сигналила о правильном CRC.
Такая парадоксальная ситуация привела меня в замешательство. Так и не понял почему игра работает с правильным сигналом CRC, хотя реально записана с неправильным. А с неправильным при этом работать отказывается...

В итоге я временно залочил эмулятор ВГ93 так, чтобы он всегда правильное CRC давал. Таким образом эта игрушка грузится нормально, но эмуляция ВГ93 некорректная Так все и осталось.

В Unreal к сожалению эмуляция ВГ не такая детальная. Там до таких деталей не доходит - проскакивает т.к. эмулятор не анализирует реальные CRC.
Эмуляцию ВГ93 для дотнет версии ZXMAK я писал на основе кода Unreal, т.к. эмуляция первого ZXMAK получилась слишком сложная, лень было столько кода переводить

может где-то сохранились исходники или описание защиты этого загрузчика?

[Titus]

эту? (cм.аттачмент)

Конечно эта, раз там написано Титус )

Поищу исходники.

Кстати, Спектакулятор этот образ прочитал хорошо и запустил игру.

[Titus]

Вот нашел какие-то исходники.
Судя по всему там копировщик для стритфайтера и форматтировщик.

[lisica]

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

Не обязательно.

И второй вариант патчить TR-DOS,

А это зачем?????


Всего лишь научить контроллер обращаться к первой половине секторов 1-16 как к дисководу "А", а вторую 32-64 как "В" и всё. Форматировщик есть, в виде плагина к реалкому, даже реформатит.
Схема такого бди тож есть и 10(десять) лет успешно используется до сих пор.
Получается на одной дискете два дика, типа "А" и "В".
Вот, с ПИСИ не пробовал состыковать...

[spensor]

Всего лишь научить контроллер обращаться к первой половине секторов 1-16 как к дисководу "А", а вторую 32-64 как "В" и всё.

И какой в этом резон? Идея ноухавная, но вещь в себе.

[lisica]

И какой в этом резон?

Две дискеты умещаются на одной. И с ними работаешь как с обычными дискетами даже перевтыкать не надо. Всё на одном дисководе.

Получается на одной дискете два дика, типа "А" и "В".

Извиняюсь, поправлю "А" и "С". "В" всегда 720кб