Чтение дисков без АГАТа

[GARNIZON]

А, так тут все практики, а я-то куда в этот калашный ряд

Денис, ну зачем ты так! я же лучше других знаю сколько (дикое кол-во образов которых без тебя просто никогда бы не было в инете) ты всего снял от разных ЭВМ. И твой способ вероятно оправдан для ДВК, ЕС и прочих, тут тебе лучше знать, в них ты практик а я только теоретик. Я же именно про агатовские говорю, и тут я собаку то скушал.

Мысль которую ты хочешь донести понятна: «мне дали на пол часа диски, и надо вычитать так чтоб КС сошлись, иначе если я этого не дождусь в дампах может не оказаться нормального прохода а диски уже тю-тю». А я тебе говорю, что с агатовскими дисками это дохлый номер, проходили, Кс сошлась а в дампе мусор. А вот 5-6 проходов полных в сырье дадут возможность анализа (на это есть софт классный) . Акцентирую внимание (статистика) : Больше 5-6 проходов смысла нет делать на агатовских дисках.
На РС у меня такой номер почти каждый раз срабатывает (бывало на 25 попытку как подменили - взял и прочитался), на агате ни разу.

[Advertiser]

[dk_spb]

Ты забываешь что кроме Агата есть еще другие системы. И делать железку ТОЛЬКО под Агатовские диски - неинтересно. Как минимум должна быть возможность потом добавлять форматы.

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

И пусть у нас будет дорожка с какими-то ошибками. Да, можно её прочитать несколько раз, чтобы небольшие ошибки устранить анализом нескольких копий. Но без начальной верификации ты несколько раз можешь прочитать и сохранить мусор, где не только КС данных не сошлись, но даже КС заголовков ни у одного сектора не совпали или даже синхробайты не находятся. И что тебе даст анализ этого мусора?

- - - Добавлено - - -

Денис, ну зачем ты так!

Просто пытаюсь свести переходы "что может сказать теоретик об искусстве Герберта фон Караяна " в шутку ;-)

[Wierzbowsky]

Ппц, и что, мятую как из жопы дискету тоже реально прочитать!?

Мужики, вы неконструктивны. Хорошо, что Агатовские темы вновь ожили, но не стоит тут начинать холивар по поводу опыта. У каждого он свой и неповторимый.

[LeoN65816]

ага, суперски написано, четко и с точностью в деталях

А мне так не показалось, особенно с точностью в деталях...
Начиная с логических уровней и активного состояния сигналов.
Затем правило MFM-кодирования, где каждый бит данных кодируется в два полуинтервала (смена направления тока в головке, именно при смене тока дисковод выдает импульсы). Посмотрите здесь, здесь и в "хорошей статье на эту тему от инженеров компании Shugart Associates". Затем посмотрите в его доке на пример, как байт данных $C5 кодируется в MFM-последовательность, и опять взгляните на мои ссылки... Может я и ошибаюсь, но это не "по-фэншую".
Затем пресловутый (в ВГ93) $A1 - это и есть уже MFM-последовательность полуинтервалов, в которых идут подряд 4 одинаковых полуинтервала (4 нуля), что есть невалидная MFM-последовательсть, то есть синхросбой. Но в АГАТе нет "desync 0xA1" (как указано у него), тем более не MFM, а именно "desync 0xA1-данных". Здесь (4.7.2), здесь (пункт 16) и здесь говорится об этом. Последний (младший) бит от $A4 (бит данных равный 0) дает два одинаковых полуинтервала, затем задержка на один полуинтервал в 2 мкс, затем один такой же полуинтервал от старшего бита следующего байта $FF (бит данных равный 1), итого 4 одинаковых полуинтервала - синхросбой.
Не исключаю, быть может это я неправильно "вкурил" про MFM-кодирование...

[GARNIZON]

От Володи письмо: "



> Плюс, честно говоря, FM мне совершенно не интересен...

Неверно. Контроллер 140ки вообще не занимается модуляцией-демодуляцией.
При записи он только сдвигает полученный от ЦП байт в дисковод.
Формат записи может быть, таким образом, различный. Можно даже MFM замутить,
если сильно надо. Стандартный же формат следующий: GAP вообще не кодируется
(просто константа АА, которую при сбое синхро можно прочитать как 55),
прологи-эпилогий полей - тоже константы, адресное поле - FM, поле данных
- GRC.

GRC - групповое кодирование. Решает ту же задачу, что и MFM, только с бОльшими
затратами рессурсов (ОЗУ и ЦП). И примерно так же эффективно по плотности.

Принципиальное отличие тут только в том, что в 140ке частичная синхронизация происходит
на каждом байте (байт записывается как 10 бит, два последних - нули), а в MFM
- только на поле синхросбоя.

Из-за этих двух нулевых бит дорожка 140ки - всего 16 секторов против 21 у 840ки.
Если бы было FM - там бы, наверное, секторов 10 поместилось, не больше.

А разница в объёмах дисков идёт из-за ширины и количества дорожек
- 35 против 160.


-=-=-

RAW-споры:

Давайте называть поток бит от дисковода до контроллера RAW-bit, а поток байт
от контроллера к ЦП - RAW-byte. Чтобы однозначно.

AIM и EIM - это RAW-byte.
Поток, который наши мосты гоняют по LPT - это RAW-byte + служебка (состояния контроллера).

Почему не RAW-bit ?

1) Исторически, RAW-bit просто был не нужен для эмуляторов.
Проги обмениваются данными с контроллером, а не дисководом. Таким образом, больше
информации, чем может прочитать контроллер, нам уже просто не нужно.

2) Потому что битрейт (если, действительно, семплировать каждый импульс от флопаря
с частотой раза в 4-8 большей, чем длительность импульса) будет велик. Но бессмысленнен.
Чтобы обработать такой битрейт проц уже должен быть заметно более мощным.
Контроллеры, что 140, что 840 - уже имеют на борту соответствующий аппаратный анализатор.
Он же есть и в мосту-140. Я не вижу возможности его как-то улучшить за счёт программной
обработке на PC или в каком-то современном контроллере, поэтому пусть он сразу и
конвертирует RAW-bit в RAW-byte.

3) В сущности, конвертация RAW-bit в RAW-byte в 140 очень проста: очередной байт
начинает читаться после прохождения последовательности "001". Собственно, секвенсор
её ищет, это является синхронизацией и все последующие биты просто собираются в
байт, с некоторой фазовой автоподстройкой. Так что глядя на RAW-byte легко представить
и как выглядел RAW-bit.

4) Копаться в RAW-bit, как и в RAW-byte, вручную на практике почти нет смысла.
Например, я могу найти в GCR-последовательности сбойный байт, где явно затесался лишний
ноль. И что дальше ? Мне его заменить на единицу или просто удалить?
И есть уверенность, что последовательность затем соберётся без ошибок?
Это маловероятно. Ведь повреждение записи - это проблемы поверхности. Они вряд ли
будут размером с 1 бит. Пару секторов - да, это бывает. А чтобы стабильный 1-бит - почти нет.

5) Гораздо чётче работают две другие схемы восстановления: найти такой же файл на другом диске и объединить
две копии посекторно. И переснять другим дисководом этот же диск. 3-4 разных дисковода
и больше половины проблемных дисков читаются.


Зачем же тогда нужен RAW-byte?

1) Ключи защиты от копирования. И всякие хитромудрые форматы, типа один сектор
размером во всю дорожку. Этого добра на 840ке хватает...

2) Всё таки восстановление чего-то очень интересного. В RAW-byte несложно нарисовать
запорченное адресное поле или проигнорировать CRC. Или расчитать его по особому алгоритму.
Но подгонять каждый бит на всех непрочитавшихся дискетах - это перебор.

3) А откуда я знаю, что Игорь накопает в очередной раз... ?
Не забывайте о том, что мы работаем вдвоём, но разделены приличным расстоянием.
Так же будет и если устройство для чтения будет выпущено серией: железка отправится
по разным пользователям, но глубокий анализ вряд ли кто-то из них возьмётся сделать.
Так что проще вытащить весь поток и потом уже, если он окажется чем -то странен -
копать уровень RAW-byte.


-=-=-

Спор насчёт EIM vs DSK

Не совсем понял, почему вы их противопоставляете?

Что, собственно, мешает, контролировать CRC и перечитывать вопросные зоны сразу,
но в файл сохранять именно RAW-byte? У нас именно так работают оба моста.
Да, RawEdit потом заного всё анализирует, по более замороченным алгоритмам, кой где.
Однако он пока не жаловался, что его заставляют второй раз делать уже выполненную работу.
У нас и для dsk есть две разные проги - одна быстрая, другая - въедливая. Есть и прямо
прога, которая выводит каталог диска, вообще ничего никуда не сохраняя.

Вообще, при чем тут формат ?... EIM или DSK - это вообще дело не аппаратуры, а
софта. Коего можно понаписать позднее просто сколько угодно.
Мне кажется, его сейчас очень рано обсуждать. Если только:

> Ты забываешь что кроме Агата есть еще другие системы. И делать железку ТОЛЬКО под Агатовские диски - неинтересно. Как минимум должна быть возможность потом добавлять форматы.

Потому что тема начиналась вот этой фразой:

> Здесь Игорь озвучил мысль о реальной необходимости современного и мобильного средства снятия образов АГАТовских дисков.

Так надо решить: вы (не знаю кто, но кто-то) делает строго железку под агат,
пусть даже это будет коммерческой разработкой или вся работа - "на интерес"?
/Озвучивайте суммы, не стесняйтесь - если работа будет хорошая, можно и оплатить её/

Потому что до сего момента я считал, что речь идёт именно и только об агате.
Если нет - то это надо ясно обозначить.

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


-=-=-

Как я вижу конечное устройство для 840ки, работу над ним и вопросы:

1) Сейчас уже два человека расковыряли формат 840ки. Один из них даже опубликовал
на гитхабе. Статья классная (!), сегодня читал (ну может есть какие-то ошибки, но то что я знаю - похоже).
Проблема только в том, что оба они анализировали битовый поток, а не схемотехнику
контроллера. В результате оба не описали поведение секвенсора при генерации
и анализе синхросбоя. А это не такая простая штука. Как минимум, насколько я понимаю,
поведение контроллера будет менятся в зависимости от предшествующего синхросбою байта
(при записи) и не знаю чему - при чтении.

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

2) С другой стороны - анализ контроллера мог бы способствовать воссозданию
секвенсора для будущей железки. Как это было сделано для 140ки. ATmega16 просто
бы не вывезла такой семпл-рейт, который там молотят 4-5 копеечных микросхем.
Наверное, это же можно сделать на простой ПЛИСКЕ-ПЛМке. Но я не умею.

3) Почему USB-интерфейс? Я бы, наравне с ним, использовал и синий зуб.
Сейчас андроидов полно, бывает что у чела и ноута -то может не быть, а
планшет у детей занять можно.
А может быть предусмотреть Ethernet ? Вроде сейчас есть готовые платы
с контроллером, который - с одной стороны - смотрит в витуху, а другой -
в любую 8-битку?

4) Для питания предусмотреть на плате несколько разных разъёмов от БП распространённых
ноутов. И с него уже конвертировать в +12 +5 и что ещё надо. Для особой электромагнитной
эстетики можно даже конвертировать линейными регуляторами.

5) Экран и флешки точно не надо. Это компактно, но всё таки проще отлаживать бОльшую
часть кода на PC чем в контроллере. И экран ноута заметно удобнее, и клавиатура.
А главное - можно напрограммить много разных управляющих прог для разных задач.
У нас мосты, например, кроме прочего, могут измерять скорость дисководов, вручную
можно управлять головками (при ремонте удобно), выводят статус датчика нуля,
самотестирование, тестирование интерфейса с компом...

6) Минимум кабелей. Пусть будет только какой нибудь стандартый miniusb с одной стороны
и флоп-разъём с другой. И посередине питание.

7) Запись данных вторична, в первую очередь обкатать чтение.

8) USB-порт на контроллере или USB-конвертор, что нибудь вроде cp2102 ? У него скорость высокая,
стоит вроде не дорого? Не знаю.

9) Насколько сложно сделать буфер дорожки (внешнее озу), чтобы не зависеть
от сбоев PC ? Именно мало памяти на ATmega вынудило на заморочки с DOS и LPT - чтобы
иметь со стороны PC быстрый отклик без задержек.


"

[dk_spb]

Ну как-то всё сильно в "терминах" Агатовского железа.
На самом деле raw-bit нужен как раз для того, чтобы "вытягивать" raw_byte. В том числе программной ФАПЧ.
Видел сорцы как раз конвертилки raw-bit в raw-byte от kryoflux - так там даже методы ФАПЧ можно менять.

Про противопоставление EIM-DSK вообще ничего не понял. Железка+софт должны уметь писать все (raw-bit; raw-byte=EIM; dsk).

И мне лично крайне не нравятся все эти дискуссии про всякие atmeg'и. Ну давайте еще на 155 серии сделаем ;-)
Я думал сделать такой проект (не только для Агата) в виде дочки к BBB, точнее к BBG (BareBone Black Green). При этом от дочки нужны практически только разъемы и пару м/c "адаптеров" сигналов логики 3,5V-5V. И тогда получается чисто софтовый проект. Сейчас у меня такое железо (не моей разработки софт и "дочка") работает универсальной читалкой HDD MFM. То есть нужно, в некотором роде, "задаунгрейдить" софт и добавить анализатор агатовского формата. За 35 евро на борту и SD и USB и Ethernet. Внутри Linux с компилятором C. Для realtime обработки данных с дисковода- встроенный спецпроцессор. Дискетный битрейт - почти из пушки по воробьям. Но времени совсем нет :-(

- - - Добавлено - - -

Принципиальное отличие тут только в том, что в 140ке частичная синхронизация происходит на каждом байте (байт записывается как 10 бит, два последних - нули), а в MFM- только на поле синхросбоя.

Я не специалист в кодировании и передаче информации, но, насколько я понимаю, синхросбой нужен для синхронизации начала потока информации. Грубо для того чтобы в MFM потоке типа 10101010 понять с какого бита начинается байт. То есть в предлагаемых терминах это уже работа с raw_byte.
Еще нужно получить поток MFM типа 101010 из такого сигнала ----____----____----___, который по факту может быть и ------__----__-_----___ . И вот именно для этого и нужен raw-bit, который обрабатывается программно.

- - - Добавлено - - -

Контроллеры, что 140, что 840 - уже имеют на борту соответствующий аппаратный анализатор.
Он же есть и в мосту-140. Я не вижу возможности его как-то улучшить за счёт программной
обработке на PC или

В том-то и дело что в железке, которую планируется сделать, его нет (хотя бы потому что желзки еще нет). И тут и возникает вопрос: делать "соответствующий аппаратный анализатор" или делать это программно. Для меня в данном случае программно - значит с большими вариантами и возможностями спасти плохочитаемую информацию.
Хотя опять же была мысль сделать два канала: читать чистый сигнал с дисковода и, параллельно уже после какого-нибудь сепаратора с ФАПЧ (например, WD92C32). А потом сравнить. Но аппаратные сепараторы я видел только для FM/MFM. Для GRC не видел.

- - - Добавлено - - -

Ведь повреждение записи - это проблемы поверхности.

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

[LeoN65816]

http://yadi.sk/d/e46aIhNZ8qFTQ - что то я совсем запутался...

[dk_spb]

(По тексту возможны ошибки, не так давно работаю с Агатом.)

Цитата из статьи:
2.2 Address field:
0x95, 0x6A (2 byte address field mark),
volume number (1 byte, default 0xFE),
Track number (1 byte 0x00 - 0x14),
Sector number (1 byte),
Который из них номер сектора, а который -дорожки? Если верить тексту "Track number (1 byte 0x00 - 0x14)" получается что максимум 0x14=21 дорожка? Или 21 сектор?

[sintech]

Цитата из статьи:
2.2 Address field:
0x95, 0x6A (2 byte address field mark),
volume number (1 byte, default 0xFE),
Track number (1 byte 0x00 - 0x14),
Sector number (1 byte),
Который из них номер сектора, а который -дорожки? Если верить тексту "Track number (1 byte 0x00 - 0x14)" получается что максимум 0x14=21 дорожка? Или 21 сектор?

Конечно Track 0x0-0x9F (159), а Sector 0x00-0x14 (21). Опечатка в спецификации kapitan-u.
Наверное я сделаю свою, обновленную версию спецификации, с правильным Desync и диапазонами значений дорожки и сектора.

[GARNIZON]

Володя:

"

Ну как-то всё сильно в "терминах" Агатовского железа.
На самом деле raw-bit нужен как раз для того, чтобы "вытягивать" raw_byte. В том числе программной ФАПЧ.
Видел сорцы как раз конвертилки raw-bit в raw-byte от kryoflux - так там даже методы ФАПЧ можно менять.

А польза от чередования разных алгоритмов есть?
Есть ли алгоритмы, использующие, например, статистический анализ дорожки или сектора? Или всё сводится только к состоянию последних 2-4 бит?

Про противопоставление EIM-DSK вообще ничего не понял. Железка+софт должны уметь писать все (raw-bit; raw-byte=EIM; dsk).

Был выше спор о том, кто что проходил и что надо сразу писать в DSK (при считывании диска).

И мне лично крайне не нравятся все эти дискуссии про всякие atmeg'и. Ну давайте еще на 155 серии сделаем ;-)

Я больше скажу - у нас ещё и 531 серия используется на мостах. А в чём проблема -то?
Задачу они решают, стоят копейки.

Но времени совсем нет :-(

Так если нет времени - зачем мы тогда здесь собрались?
Игорь сказал, что тут есть те, кто хочет сейчас и здесь сделать реальное устройство, но не имеет некоторых данных, по форматам и ещё чему-то.

Для меня в данном случае программно - значит с большими вариантами и возможностями спасти плохочитаемую информацию.

Программно надо делать либо если есть избыточные вычислительные мощности либо если есть идеи по модификации этой программы во время отладки.
У меня нет ни того ни другого. Я разбирал логику 140го секвенсора и экспериментировал с прогой от разработчиков агата и от Возняка - разница есть, но не очень значительная.
Поэтому, возможно, если разобрав логику 840го секвенсора я увижу в ней какие-то возможности для расширения, тогда сделаю так же как сделано в 140ке: несколько
разных программ в ПЗУ секвенсора и чередование их в случае неуспеха. Но сохранять в файлы RAW-bit мне кажется уже перебором. Просто из практики работы с агатовскими дисками.

Если найдется какой-то явно лучший способ RAW-bit -> RAW-byte конвертации, чем анализ последних пары бит - я им заинтересуюсь.

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

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

"