Gaps

[vak]

Доделываю в утилите floppy поддержку формата файлов IMG. Утилита уже умеет писать IMG на флопик и читать IMG с флопика. Но дьявол в деталях: разные форматы флопиков имеют разные "gaps", то есть зазоры, пустые места на дорожке.

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



Критичные зазоры здесь: gap2 и gap3. От их величины зависит стабильность обмена с флопиком на разных флоповодах. Gap4a и gap1 всегда одинаковые, а gap4b просто дополняет дорожку до нужного размера (до следующего индекса).

Вот зазоры gap3 для стандартных форматов, в строке Gap Length (Format). Это из описания чипа флопового контроллера FDC37C65C. Там же указано, что gap2 для всех форматов должен быть 22, а для 2.88M увеличенный до 41.



Зазоры для нестандартных форматов придётся смотреть в линуксном драйвере floppy.c. Полезно и в FreeBSD заглянуть, sys/fdcio.h.

Comments

[spamsink]

А где на cхеме (**) Special C2-marker-pattern?

[vak]

Я его стёр, а примечание забыл. На писишных флопиках маркер индекса это физическая дырка. Нет необходимости писать его на дорожку.

[vak]

В этом была моя ошибка, насчёт ненужного маркера индекса. Пришлось мучительно вспоминать. Как выяснилось, я с БК-шкой спутал. Там действительно маркер индекса прописывать не следует. А на писишке как раз он требуется. Вернул маркер индекса - всё заработало.

[ufm]

Читаю про то, как ты влзишься с флопиками и получаю постоянные флешбеки, как я в 88-89 году делал защиту от копирования с привязкой к флопику.Из того что осталось в памяти - я форматировал одну дорожку нестандартно - у последнего сектора на ней был размер в два раза больше. За счёт этого, во первых удавалось читать gap (у меня там хранилось число копий), во вторых - при копировании, даже если копировщик разбирался с нестандартными размерами, он всё равно в процессе убивал эту дорожу - перезаписывал первый сектор.
И что особо сурово - я делал это посредством штатного биоса.
Единственное - по моему на IBM PCjr были какие-то проблемы с этим. Он таких извратов не поддерживал...

[vak]

Ага, значит ты знаешь про флопики больше чем я. 😀
Нестандартное форматирование через биос это не фунт изюму.

[ufm]

"знал" :)
И, с другой стороны, я извратами через биос занимался потому что не нашёл информацию как это через порты делать. :)
Да и на сколько я помню - на самом-то деле там ничего особо сложного. Всего лишь в какой-то момент задался вопросом "а что будет, если передать вот такие парамеры".
Вобщем "А-а-а-а, бля, сказали суровые сибирские мужики" в чистом виде. :)

[vak]

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

[ircicq]

Интересно, что подобные защищённые диски можно было копировать например на компьютере "Поиск".
Там для дешевизны FDD контроллер не умел работать с секторами.
BIOS управлял каждым байтом вручную: Gap, Sector Header...

[ufm]

Ну против настолько умных тоже есть способ. Берётся иголка и протыкается диск. :)

[ircicq]

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

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

[ufm]

Прокол с точки зрения программы - битый сектор. Программа форматирует дорожу и проверяет наличие битого сетора (причём не абы какого, а конкретного)

[ircicq]

Если программа с точностью до сектора определяет - это легко воспроизводится.

Копировщик также отформатирует эталонную защищенную дискету,
Выдаст карту битых секторов
И дальше человек с линейкой и циркулем проткнёт новую дискету в нужных местах

[ufm]

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

[borisk]

Как в своё время говорили — российские программы это развитые системы защиты от копирования, которые иногда выполняют и другие полезные функции ;)

[vak]

Прокол виден как нарушение кодирования в первую очередь. Потом уже как неверная контрольная сумма и вследствие отсутствующий или битый сектор. Копировщики флопиков отлично копировали все нарушения кодирования. Защита проколами от них не спасала.

[ufm]

"программа форматирует дорожку". Т.е. если там нет дырки, то после форматирования не будет битого сектора. :)

[vak]

Низкоуровневый копировщик не форматирует дорожку. Он копирует сигнал намагниченности на физическом уровне.

[ufm]

Еще раз.
Ты запускаешь программу. Программа форматирует дорожку. После этого читает сектор, который должен быть битым. Если он не битый - это копия и программа выходит. Из себя. :)

[vak]

А, ну это да, конечно. Но тогда программа не сможет запускаться с защищённого от записи флопика.

[ufm]

Ну там никто и не обещал. :)

[b0p0h0k]

Равно этим занимался, и в то же время.

[vak]

Тоже на писишке? На сане ведь тоже были флопики.

[b0p0h0k]

На писишке, конечно. Это ж халтура была.

[chabapok]

В разметке флопиков положения секторов не строго фиксированны, их можно немножко двигать туда-сюда, уменьшая или увеличивая gap-ы. Там еще у 1818вг93 есть такая фишечка, что в разметке встречаются двух-байтовые маркеры. А двух-байтовый маркер это как utf-8: если ты прочитал первый байт - то очень-очень хочешь второй, даже если этот второй за пределами буфера. У железа этот баг тоже присутствовал, и можно было с какой-то попытки (примерно с третьей) подгадать gap-ы так, что вг-шка была слишком занята вычитыванием двухбайтового маркера - и "не видела" датчика конца/начала дорожки. Дорожка, записанная таким образом, выглядела для вг-шки как бесконечная. Посекторно ее читать можно было - но в режиме raw read биос не мог остановиться, читал, забивал всю память, и потом все по кругу с аддреса 0. На этом эффекте тоже защиты делали: посекторное копирование не приведет к тому, что копия будет рабочей, а скопировать сырую дорожку не получится - попробуй сначала прочти такое. Читалось это серией каких-то хитрых финтов, уже не помню как. Ну или биосом своим, у которого есть ограничение на длину. Это все было на zx-спектрумах.

Сейчас я это расцениваю как плохое явление. В то время я чувствовал себя обладателем секретного знания, а это необоснованно поднимает ЧСВ, логика примерно такая "я обладатель секретного знания => я сверхчеловек". Но это же явление ставит твои мозги определенным образом: ты начинаешь думать, что выход за пределы стандартов это хорошо и полезно. То есть, ты заведомо плохое считаешь заведомо хорошим.

[vak]

Кто ж так криво сляпал тот 1818вг93. Бомба замедленного действия.

[chabapok]

Помню, что там есть два режима записи - raw (считайте - низкоуровневое форматирование) и запись данных посекторно на уже отформатированный диск.

Причем, при форматировании записать сразу данные можно, но почему-то такой способ чаще дает сбои. Там видимо эти перемагничивания какие-то неполные. Так же, если дист на 1.44 отформатировать как 720, а потом снова на 1.44, то потом он будет чаще сбоить. (это касается 1818вг93, и было проверено на определенном количестве разных компов у разных людей)

У вас, судя по тому, что вы написали, утилита работы с картинками лезет на тот уровень, о котором ей ненадо что-то знать.

[vak]

В фразе "там есть два режима записи" давайте сначала разберёмся, что такое "там". 😀
Есть чтение-запись через биос - то, чем занимается MSDOS и все обычные программы. Работает только посекторно на уже отформатированный диск.

Низкоуровневое форматирование возможно минуя биос, через прямое программирование регистров флопового контроллера. Тут уже доступно много чего, но не всё. Возможности чипа контроллера тоже ограничены. Да и чипы бывали разные.

В моём случае и про чип флопового контроллера можно не париться. Я работаю ещё ниже, непосредственно с сигналами намагниченности. Которые из флопового драйва торчат как два провода:

/Read Disk Data - Raw serial bit stream from the disk drive. Each falling edge represents a flux transition of the encoded data.

/Write Data - Encoded data to the disk drive. Each falling edge causes a flux transition on the media.

Утилита работы с картинками видит весь сигнал намагниченности.

Про "сбои перемагничивания" - вы вероятно имеете в виду порчу флопиков 360K в флоповодах 1.2M. Была такая проблема, вызванная разницей в ширине магнитной головки и силе намагниченности. Подробности по ссылке.

https://chatgpt.com/share/69682c38-f478-8001-b41e-0d0695aec5dc

Между 1.44M и 720K такой проблемы не было. Или может просто разброс параметров 1818вг93 и некачественные советские флопики.

[chabapok]

у меня в 90ых был спектрум с флоповодом, на базе 1818вг93

Беру дискету 1.44, которая не сбоит. Формачу ее под 720 - и потом опять под 1.44. Такой пользоваться можно - но сбоит иногда. Почему так - я не знаю.

что там в msdos, я вообще без понятия.

> Утилита работы с картинками видит весь сигнал намагниченности.

это как-то совсем уже неправильно. Что вообще у вас там творится?

[vak]

Я вчера попробовал сформатировать флопик 1.44 как 720 на i486-м компе под MS-DOS. Фиг вам говорит, дискета непригодна. Записал этот флопик через Greaseweazle в формате 720 - не читается на писишке. Дело в том, что магнитное покрытие у флопов HD и DD разное. Соответственно магнитная головка для них работает в разных режимах. И если флопик HD писать/читать как DD, оно то ли недомагничивает, то ли перемагничивает.

Попробую добыть флопики именно на 720, поиграюсь.

> это как-то совсем уже неправильно. Что вообще у вас там творится?

Что же такого неправильного. Берём сигнал /RDD прямо с ножки флоповода и разворачиваем построчно. Как в старом добром телевизоре.

[chabapok]

На х86 есть немаскируемые прерывания. Плюс - работа кеша плохо прогнозируется. То есть, одни и те же инструкции могут "как бы" исполнятся разное количество тактов, из за прерываний и кэша. Не говоря про желание ОС свопить (старое железо вроде так не делало?). А сигналом с головки надо управлять в риалтайме, с определенной погрешностью. Вылезет ли за пределы погрешности программа - я без понятия, но ни разу не слышал, чтобы прямо с компа управляли прямым сигналом с головки. Может на х86 это норма? Не знаю.

На спектрумах так нельзя было. Там вся работа шла через микросхему, и прямого сигнала с головы не было.

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