Можно ли это обойти настройкой флюксы ?

1) вроде последний софт умеет и так:

--input.flux.drive.sync_with_index=true|false

Wait for an index pulse before starting to read the disk. (Ignored for write operations.) By default FluxEngine doesn’t, as it makes reads faster, but when diagnosing disk problems it’s helpful to have all your data start at the same place each time.

2) я для чтения таких дисков делал прошивку FPGAшной части флюксы, которая просто делением тактовой генерировала себе на вход индекса импульсы заданной частоты.

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

Сегодня закончил анализ нескольких образов 140к. Результаты любопытные:
1) Флюкса вроде как имеет декодер "apple2" , но он почему-то даёт не всегда 140кб, иногда образы получаются 280кб, иногда - что -то ещё неясное, чуть ли не мб. Но странно, что даже 140кб образы у неё совсем не похожи на то, что ожидается. Либо декодер не отлажен или я чего-то не понимаю.

2) Не смотря на то, что на моих дисководах с платой SCP не удавалось получить корректный поток со 140ки (похоже на недостаточную полосу пропускания сигналов дисковода), у Игоря, на его дисководах, с флюксы удалось вытащить вполне корректный поток 140ок.

3) Я пытался как для 840ок так и для 140ок оценить качество снятия на скоростях SD и HD (200 и 166мс на оборот), но вывод только один: в природе есть дисководы, которые одинакого хорошо читают на любой из скоростей. Но это не значит, что в природе не существуют дисководы, которые предпочтительнее использовать на низкой скорости.
Игорь использовал два дисковода. Один из них даёт слабо различимые результаты в зависимости от скорости (если смотреть в абсолютных количествах успешно прочитанных секторов), возможно даже предпочитает высокую скорость. Второй дисковод давал на разных дисках различные результаты: чаще на высокой результаты были хуже, но один раз - лучше, причем с большим перевесом.

4) Алгоритмы ФАПЧ ведут себя совсем не так, как с 840кой: если у 840ки, как правило, наилучшие результаты давал алгоритм "мягкой" коррекции, то у 140ки он стабильно идёт в аутсайдерах. Наилучшие (и, практически, идентичные) результаты даёт "жесткая" ФАПЧ: наиболее жесткая почти всегда выигрывает, остальные сходные алгоритмы идут ноздря в ноздрю. Очень редко это правило нарушается. Также дело обстоит и с мостом: он практически не проигрывает флюксе, а изредка и выигрывает, вероятно, когда чтению может помочь возможность сдвинуть голову чуть в сторону от дорожки (a'la COPYTRACK).

Любопытно, что хотя, теоретически (да и для "хороших" дисков - практически) 140ка мало чувствительна к ошибке скорости "читающего" дисковода, но когда дело доходит до плохо читающихся секторов, даже сдвиг скорости на пару процентов может повлиять на результат.

5) Здесь опять вылез тот факт, что 140ка иногда даёт ложноположительную проверку CRC: данные, полученные со одной из мильона попыток чтения могут быть неверны, но расчитанняа CRC будет совпадать с прочитанной. Не пойму, почему этой же проблеме не подвержены 840ки (во всяком случае я не имею примеров) ? Возможно, 140ка, при выпадении одного бита из потока или возникновении одного лишнего бита, с большей вероятностью получит какой-то приемлимый итоговый результат (неправильно декодированные байты + неправильно прочитанная CRC).

6) Флюкса отказалась читать вторую сторону диска при его переворачивании.
Скорее всего, дело в отсутствии индексных сигналов от дисковода.
Можно ли это обойти настройкой флюксы ?

Прочитать вторую сторону второй головкой невозможно: голова 1 сдвинута относительно головы 0 на 4 трека к центру диска. Т.е. не будут прочитаны треки стороны B:0..3.

Стал разбираться, посмотрел таблицу распределения интервалов в зависимости от угла поворота диска, оказалось, что часть трека записалась как бы с "растягиванием" интервалов - как будто дискета "ускорилась" при записи или "притормозилась" при чтении. Не знаю, как это могло произойти, я пробовал всё с 3.25'', у которых шпиндель жестко цепляется к диску (кстати, вообще разброс интервалов, особенно на внешних дорогах у этих дисководов явно лучше, чем у 5.25, хотя не знаю - в дисководе дело или в дискетах).

В общем, на двух секторах произошел сдвиг скорости (остальная дорога читалась без проблем).

Сперва я попробовал сделать специальную таблицу с "жесткой" фапч, но это мало помогло: интервалы сильно "ушли", хотя таблица ошибок интервалов всё же явно показывала, что 1001 легко отличаются от 10001 (пока только "глазами", алгоритм чтения не мог этого сделать). Статистика ошибок по этому треку (цилиндр 70 сторона 0, в агатовской нумерации - трек 140):
{
В таблице есть три главных строки: 1z, 2z, 3z.
Импульсы в MFM кодировании должны следовать с определёнными  интервалами: примерно 4, 6 или 8 мкс. Но они так не следуют, интервалы всё время немного скачут. Т.е. импульс может прибыть не через 4 мкс, а через 4.5 или 4.8 мкс или 3.5 мкс - будем это считать интервалом 101 (1z).  Соответственно, если импульс придёт через 5..7 мкс - считаем это интервалом 1001 (2z). И 7..9 мкс - интервалом 10001 (3z).

Теперь если разделить интервал 3..5 мкс на 16 частей (3.000..3.125, 3.125..3.250, ....)
то можно посчитать: сколько всего считанных с диска интервалов между импульсами укладывается в ту или иную 1/16 часть. Получаем распределение интервалов по времени.
Например, если интервал между импульсами попал в диапазон 3.125..3.250 мкс, то плюсуем 1 ко второй колонке в строке 1z.

Именно эти цифры приводятся в последующих таблицах.

В идеале импульсы должны попадать примерно в центр (точнее колонку, отмеченную знаком "+").
}

Index start
25003 mks
ERRORS: underrun = 0, overrun = 0 (sector 0/8)
1z:     0     0     0     0     0    31    71  1241  2619+   109     4     0     0     0     0     0 
2z:     0     0     0     0     0     0     0    61    80+   455   196    75     0     0     0     0 
3z:     0     0     0     0     0     0     0    49   347+    35    29    37    14     0     0     0 
50003 mks
ERRORS: underrun = 0, overrun = 0 (sector 1/8)
1z:     0     0     0     0     0    33   112  1599  1788+    36     0     0     0     0     0     0 
2z:     0     0     0     0     0     0     1    64   161+   702   122    24     0     0     0     0 
3z:     0     0     0     0     0     0     6   101   365+    55    62    27     0     0     0     0 
75005 mks
ERRORS: underrun = 0, overrun = 0 (sector 2/8)
1z:     0     0     0     0     1    65   138  1559   754+    28     0     0     0     0     0     0 
2z:     0     0     0     0     0     0     0   113   258+   818    73     8     0     0     0     0 
3z:     0     0     0     0     0     0    15   146   602+    95    94    24     4     0     0     0 
100004 mks
ERRORS: underrun = 0, overrun = 172 (sector 3/8)
1z:     5    15    19    47    34    78   125   860   363+   100   112    70    75    79    49    15 
2z:    18     7     0     0     3     9    19   123   213+   439    36    25    30    67    63    14 
3z:    26    55    49    31    19     7    11    89   369+    78   131    63    74    63    51    50 

Здесь анализатор нашел индексную метку где-то на середине оборота (от неё начинается анализ статистики) и видно, что в нулевом секторе (сектор здесь геометрический - это 1/8 оборота, т.е. 45 градусов),
распределение длительностей интервалов "красивое" (всё лежит вокруг колонок, помеченных "+" - точка захвата ФАПЧ) и только в 3 секторе картина вдруг смазывается: строка 1z просто размыта (это одиночные интервалы 101), но она немного залазит на 2z. На строке 2z (интервалы 1001) первые две колонки - это ещё тянется на самом деле интервал 1z, третья и четвёртая колонка - нули - это на самом деле "водораздел", который показывает что граница между интервалами есть и она отчётливая, но далеко сдвинута от своего места.

Интервал 1001 тоже залазит на строку 3z (10001), но уже сильнее, водораздел пришелся на колонку со значением 7. Не очень чёткая граница, но пусть так. А вот дальше видно, что самая правая колонка строки 3z содержит аж число 50 - т.е. скорее всего есть много импульсов большей длительности.
Это показывает строка "overrun = 172" - обратите внимание, что она имеет нулевое значение в остальных секторах.

Это распределение получилось при работе "мягкой" инерционной ФАПЧ. Обычно она даёт лучшие результаты.
Теперь что происходит, если посмотреть "жесткую" безинерционную ФАПЧ:

Index start
25003 mks
ERRORS: underrun = 0, overrun = 0 (sector 0/8)
1z:     0     0     0     0     0    64   107  1445  2459+     0     0     0     0     0     0     0 
2z:     0     0     0     0     0     0     0    60    71+   455   196    85     0     0     0     0 
3z:     0     0     0     0     0     0     0    44   338+    19    47    25    23    15     0     0 
50003 mks
ERRORS: underrun = 0, overrun = 0 (sector 1/8)
1z:     0     0     0     0     0    64   127  1713  1664+     0     0     0     0     0     0     0 
2z:     0     0     0     0     0     0     1    65   138+   719   123    28     0     0     0     0 
3z:     0     0     0     0     0     0     1    72   350+    65    94    26     8     0     0     0 
75005 mks
ERRORS: underrun = 0, overrun = 0 (sector 2/8)
1z:     0     0     0     0     1   111   161  1584   688+     0     0     0     0     0     0     0 
2z:     0     0     0     0     0     0     0   108   218+   860    75     9     0     0     0     0 
3z:     0     0     0     0     0     0     0   104   580+   118   145    18    12     3     0     0 
100004 mks
ERRORS: underrun = 0, overrun = 95 (sector 3/8)
1z:     0     0     0     0     0    71   100   885   492+   162   345    16     0     0     0     0 
2z:     0     0     0     0     0     0     0   108   178+   450    23    82    56   176   107     0 
3z:    33    14     0     1     0     0     0    52   359+   110   281    87   117    27     4    19 

Водоразделы резко улучшились, но overrun всё равно ужасен.

Тогда я ввёл в декодер возможность ручной коррекции скорости и при значении примерно 1.10 и "жесткой" фапч внезапно получил отчётливо прочитавшиеся ОБА сектора (1.10 - множитель базового интервала - т.е. алгоритм считает, что дискета вращается медленее чем нужно примерно на 10 %):

"Мягкая" фапч, коррекция скорости 1.10:

Index start
27503 mks
ERRORS: underrun = 1222, overrun = 0 (sector 0/8)
1z:   168   709   375   861   349   704    60    44    10+    24    39    28     8    31    80    61 
2z:    44   115   138    72    67   168    59     6    15+    18    38    53    32    38    36    22 
3z:    24    43    62    28    45    41    43    23    25+    10     9     1     0     0     0     0 
55000 mks
ERRORS: underrun = 932, overrun = 0 (sector 1/8)
1z:   125   499   306   600   347   421   100    61    17+    30    60    33    13    37   130   103 
2z:    41   134   181    86   147   158    28    16    31+    33    74    73    74    83    73    21 
3z:    35    54    76    62    57    53    55    61    42+    20     8     6     0     0     0     0 
82502 mks
ERRORS: underrun = 749, overrun = 0 (sector 2/8)
1z:   101   304   302   407   311   245    85    57    37+    36    45    38    17    63   143   110 
2z:    28   189   189   117   188   151    24    27    45+    45    75    78    76   106   128    30 
3z:    33    61   107    80    73    62    67    77    74+    33    20     6     0     0     0     0 
110006 mks
ERRORS: underrun = 344, overrun = 0 (sector 3/8)
1z:    84   201   221   269   329   378   365   105    24+    23    33    15     8    28    71    71 
2z:    31   143   117   118   151   143   154   157   136+    93    37    30    48    53    81    39 
3z:    49    67    89    87    84    85   102    79    65+    57    43    34    11     2     0     0 

"Жесткая" фапч, коррекция скорости 1.10:

Index start
27503 mks
ERRORS: underrun = 0, overrun = 0 (sector 0/8)
1z:     0     0     8   172   457  3571   380     0     0+     0     0     0     0     0     0     0 
2z:     0     0     0    60    75   503   298     3     0+     0     0     0     0     0     0     0 
3z:     0     0   261   142    22    57    24    15     0+     0     0     0     0     0     0     0 
55000 mks
ERRORS: underrun = 0, overrun = 0 (sector 1/8)
1z:     0     0    21   216   542  2638   112     0     0+     0     0     0     0     0     0     0 
2z:     0     0     1    79   168   815   163     0     0+     0     0     0     0     0     0     0 
3z:     0     1   437   247    74    72     9     1     0+     0     0     0     0     0     0     0 
82502 mks
ERRORS: underrun = 0, overrun = 0 (sector 2/8)
1z:     0     0    23   277   554  1802    55     0     0+     0     0     0     0     0     0     0 
2z:     0     0     0   143   270   948    67     0     0+     0     0     0     0     0     0     0 
3z:     0     0   567   329   114    77    11     2     0+     0     0     0     0     0     0     0 
110006 mks
ERRORS: underrun = 0, overrun = 0 (sector 3/8)
1z:     0     0     6   153   277   967   583   388    16+     0     0     0     0     0     0     0 
2z:     0     0     0    68   138   387   245   256   130+   180    72    13     1     1     0     0 
3z:     0     0   107   137   136   293   198    63     9+    50    46     4     9    18     3     0 

Видно, что на первых секторах есть сдвиг от центра, "водоразделы" (колонки с нулями)
проходят по краям - т.е. алгоритм будет правильно различать 101 - 1001 - 10001.
И он их различает!

Более того, rawedit обнаружил даже по две копии ранее не читавшихся секторов (информационных) в декодированном потоке, и обе копии были им декодированы без ошибок. Т.е. скорее всего проблема была именно при записи, а не при чтении.

На другой дороге при этом вылезла ошибка в одном из секторов (где-то у 20 цилиндра), но это не важно: все, кроме 70й дороги, без проблем вытянулись на "стандартных" настройках.

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

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

в статье, о которой я упоминал чуть выше, автор очень чётко сообщает, что на входе канала чтения контроллера ОБЯЗАН стоять резистор номиналом около 150-300...ну максимум 1-2 кОм, второй лапой зацепленной на питание. Это нагрузка выходного каскада флопика и нужна она для подавления отражений или согласовании волнового сопротивления шлейфа, ... в общем что-то такое полезное.

На мой взгляд, этот резистор не слишком важен. Он, безусловно уменьшает "звон" на линии данных. Однако у всех более-менее серьезных схем вход выглядит как на рисунке 8 из статьи (2 триггера и элемент И-НЕ). Эта схема работает как ФВЧ и импульсы короче периода FCLK просто убирает из входного сигнала. А поскольку звон - это обычно колебания с частотой десятки мегагерц, то они тоже успешно убираются.

Такая же схема, кстати, есть в контроллере 140 К. И, что интересно, резистора на линии данных нет вообще. Сигнал заходит прямо в ИР13. Причем, если в Apple ][ резистор есть хотя бы на плате дисковода, то в ЕС-5088 его, похоже, потеряли. Я недавно чинил контроллер 140 К, заметил, что резистора нет, и попробовал его добавить на плату дисковода. Звон уменьшился, но к какому-то заметному изменению качества чтения это не привело.

Вот над чем я раздумывал уже пару дней: моделирование агатовского ФАПЧ всё время приводило к плохим результатам. Более простые и очевидные схемы давали лучший результат.
А дело было вот в чём:

В программе секвенсора очень много строк примерно такого вида:

строка 14 if ИМПУЛЬС тогда goto строка 05
строка 15 if ИМПУЛЬС тогда goto строка 05

Так как для большинства фаз первая цифра номера строки соответствует номеру фазы,
а вторая - шагу внутри фазы (т.е. фаза - это как раз кусок программы, обрабатывающая один интервал времени длинной около 2 мкс), то goto ШАГ 05 означает переход в другую фазу (из N1 в N0), но на тот же интервал.

Я рассуждал как обычный программист: если у нас есть ИМПУЛЬС то на строке 15 номер интервала не меняется - был 5 и остаётся 5. Поэтому я думал, что интервал 5 - это точка захвата ФАПЧ (нумерация интервалов [0..7]).

Но здесь это не так: GOTO занимает по времени один такт. И переход на следующую строку (16), если импульса нет - это тоже один такт. Получается, что если имульса нет автомат уйдёт на строку 16, а если есть - то на 05 и следовательно, такой переход, фактически, сдвигает анализа на 1 назад.

Т.е. центральный интервал, к которому стремиться автомат - это интервал 4 на строке 14: с него без импульса мы попадаем на 15, а с импульсом - на 05 - т.е. даже при появлении импульса автомат не корректирует номер интервала.

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

И это всё сильно изменило поведение модели.
Результаты почти совпали с мостом (остальное можно списать на количество оборотов, на случайности...). Но самое интересное: если таблицу интерполировать с 8 на 16 интервалов на фазу - процент ошибок ещё заметно падает. А если её поправить по рекомендациям из статьи (фактически, максимально задрать инерцию ФАПЧ) то ошибки снижаются ещё сильнее. Но и это ещё не всё: если потом сравнить результаты работы разных таблиц уже на уровне декодированных секторов (т.е. выбрать сектора с корректными CRC) - это ещё немного снижает процент ошибок, причём без коллизий (не образуются сектора с одинаковыми адресами и с корректными CRC, но не совпадающие по содержимому).

Я также проделал ряд статических исследований: меня интересовало распределение ошибок (смещение импульса от ожидаемого интервала внутри фазы) в зависимости от номера трека, от угла поворота диска, от размера интервала между импульсами (101, 1001, 10001) - там всё красиво получается: теория очень наглядно ложится на практику. Заодно подтверждая, что трехзонная предкомпенсации записи у агата работает очень неплохо.
Но это много букв, цифр и таблиц.

А вот в агатовском контроллере он как раз есть. И триггер Шмита тоже есть.

Как-то это нехорошо... Но не знаю - на сколько. Вероятно, зависит от длины кабеля.
Я бы его укрепил там. На всякий случай, ом 300-500.

Тут интересный обзор работы вг93 с кучей разнообразного обвеса.

О, кто-то догадался собрать все части журнальной статьи вместе. Я это читал в сканах журнала "Радиолюбитель - ваш компьютер".

ВГ93 - это аналог WD1773. Семейство WD177x было разработано в 1976-1977 годах, тогда за каждую лишнюю тысячу транзисторов на кристалле шла борьба. Так что встроенный сепаратор просто не уместился.

http://emuverse.ru/wiki/%D0%9A%D0%BE%D0 … 1%82%D1%8B

Тут интересный обзор работы вг93 с кучей разнообразного обвеса.

Выходит так, что агатовская 840ка где-то на 4+ сделана. Можно было ещё чуть лучше, например, тактирование 8 МГц и поточнее корректор ФАПЧ при чтении, но это уже граничит с голой теорией, без практики. Многие и до сюда не добирались.

Но надо дальше изучать, что-то ещё не всё сходится.

Понемногу почитываю эту статью:
http://emuverse.ru/wiki/%D0%9A%D0%BE%D0 … 1%82%D1%8B

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

"Вечером перелистывала Вольтера. Нашла 1000 рублей. Всё таки гораздо больше открывается при повторном прочтении." (C) КВН (Парма, Жанка и Светка)

Автомат идёт с шагом 0.245нс (~4МГц), на каждый таймслот 8 шагов [0..7].
После синхросбоя автомат стремиться загнать новый импульс на шаг 5 и отчётливо видно, что именно шаг 5 ему больше всего нравиться для корректного потока, хотя шаг 6 тоже неплох.
Но, всё же, в зависимости от количества нулей между единицами, коррекция меняется:

  101: 33445566  (принимается цепочка кодированных единиц)
  101: S3445567 (принимается цепочка кодированных нулей)
 1001: S3445567 (принимается кодированная цепочка 100100 или 110110110)
10001: 34445556 (принимается 01010101 или синтетический синхросбой)
сбои другие: 223334444, xx445555, 22333444, 344445556.

Тут 8 цифр: это шаг, на который автомат перейдёт в следующем таймслоте, если в текущем словит импульс (единицу).

Например: 33445566 - это значит, что если импульс произойдёт в нулевом шаге, то автомат сразу перейдет на следующий таймслот в шаг 3 (т.е. на 3 шага ускориться), если на первом шаге - автомат ускориться на 2 шага, ... если на шаге 6, то коррекции не будет, если на шаге 7 - автомат замедлиться на шаг.

S - это особый случай: автомат слетит в ошибку (возможно, поднимет флаг "сбой синхро").
Это произойдёт, если вылезут две единицы в соседних таймслотах, но появление S в таблице коррекций означает, что "запрещённая зона" (таймслот, в котором обязан быть 0) расширяется с 8 до 9 шагов.

"Сбои другие" - это ситация, когда либо пришли две единицы в соседних таймслотах либо даже две единицы в одном таймслоте. Но тут всё понятно: автомат пытается загнать импульс в 5 фазу: всё дело в том, что это почти всегда переход в таймслот 0, а этот таймслот так хитро устроен, что за 1-2 шага всё равно загонит импульс в пятый шаг, в общем-то не важно, куда там передавать управление.

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

Тем не менее, общая схема ясна:
1) Автомат легко допускает "сближение" импульсов. Он считает более вероятным сближение, чем разбег. Т.е. если принимается 101, то автомат допускает интервал между импульсами от 11-12 до 18 шагов, хотя идеальный интервал - 16 шагов.
2) Ошибка или хитрость, но различия между вариантами коррекции состоит только в крайних состояниях. При ошибке в [-3..+1] шага коррекции всегда одинаковые. Только большой интервал (10001) корректируется немного жестче.
3) Любая ошибка (лишняя 1) приводит к жесткой синхронизации. Впрочем, возможно, что из-за фильтров в дисководе слишком близких единиц быть вообще не должно ?

--

А почему вообще ВГ93 требует настолько замороченный внешний сепаратор ?
Почему его не сделали частью кристалла ?

а как с этим обстоит дело в других системах, читающих MFM?
Если там есть ФАПЧ, то как она устроена (какой алгоритм её работы) ?

Вообще, в каком-то виде ФАПЧ есть почти везде. В схемах с КР1818ВГ93 часто это просто счетчик, который ловит импульс синхронизации и подстраивает по нему границы таймслота, в котором ловится импульс данных. Есть варианты вообще с полностью аналоговой ФАПЧ - там есть управляемый напряжением генератор, который подстраивается по импульсам синхронизации. Но чаще всего используется какой-то вариант цифровой ФАПЧ.
Алгоритмы работы в каждом случае отличаются.

....I... ....I... ........ ...I....

Самое простое, если они сидят все в одном отрезке.
Но они суетятся и сидеть не хотят.
Но нам нужно по положению этого или следующего импульса (если в текущем таймслоте нет импульса) понять, где проходит граница таймслота ?
Сейчас я сделал простой алгоритм: оцениваю интервал между текущим и следующим импульсом и, в зависимости от его длительности, регистрирую последовательность 10, 100 или 1000.
Но тщательно думая над тем, что мост читает явно лучше чем флюкса с моим декодером, я вспомнил, что в микрокоде 840ки логика регистрации сложнее: там реализовано что-то вроде программного ФАПЧ.
Т.е. там программно учитывается длительность предыдущего интервала при анализе последующего: если очередной импульс прибежал близко к началу таймслота (т.е. случился немного раньше, чем его ожидали), то для последующего импульса даётся фора в ожидании. Но фора всегда немного меньше, чем ошибка положения.

Я хотел бы спросить: а как с этим обстоит дело в других системах, читающих MFM?
Если там есть ФАПЧ, то как она устроена (какой алгоритм её работы) ?

Теперь про саму железку. Сразу скажу, про диски 140кб я даже не думал, задача была дампить диски 840кб.

1) Раньше, снимая диски с помощью МОСТ840, я по ходу пьесы понимал - как идет дело.
Т.е. такие вещи как "отошел проводок",  "слетела пружинка с головы",  "диск закусывает", "записан на флопе с смещенной головой" и т.д. можно было просечь прям на ходу и принять меры.

Понятно, что используя МОСТ я находился в "тепличных" условиях, созданных для меня VOLDEMARом.
Ну точнее не лично для меня, а просто потому что он всегда так вот, фундаментально и качественно исполняет.
Т.е. все настраивается как надо и визуализируется как следует.

Попробовав Flux я пока немного растерялся от увиденного.
Поскольку отдельного модуля для Агатовских дисков в нём нет, приходится снимать сырые данные (и потом декодировать).
А это значит что снимаем "в слепую". Т.е. он там чего-то читает, но все что я вижу это номер текущего трека, пользы от этого нет.

В чём собственно неудобство: скажем у нас есть 50 дисков, дампим потихонечку. И вот 15-й попадается с "пачкающимся" магнитным слоем. Остаток треков этого диска, и все последующие диски будут читаться с кучей ошибок, если вообще будут читаться.
С МОСТ840 я это вычислю мгновенно "онлайн" если слежу за процессом, или, если отходил хлебнуть чайку, увижу сообщение о косяках по завершению чтения диска.
И вторым проходом, с чистыми головами, он как миленький все вычитает.
Примеров много, жизнь уже учила, и пружинка на голове прослабла или диск закусывает в конверте немного, да мало ли чего бывало, опыт есть.

А вот читая без визуализации, можно обнаружить, дочитав последний диск, что половина образов пустышки бЭдные. И поехали по новой тоже самое и не один раз. Без контроля каждого диска - беда и разруха.

Собственно хорошим решением бы было добавление в штатную программу Flux режима Агат.
По хорошему в сырье читать удобно только когда сортируешь огромную кучу дисков от разных ЭВМ (а именно такое месиво обычно и присылают). А потом, разложив их по стопочкам - читать на чистовую соответствующими модулями.

Но я не знаю как правильно обратится к автору, какую линию поведения нужно иметь, и какая информация ему нужна для решения этого вопроса. Очень надеюсь на подсказку  или помощь в решении проблемы от DK_SPB . Поскольку у него уже был удачный опыт по этому вопросу: http://cowlark.com/fluxengine/doc/disk-mx.html

2) Теперь самое хреновое. Получается так, что один и тот же диск читается Flux-ом значительно хуже чем МОСТ840. Ошибок получается в разы больше. Остальные условия специально те же, т.е. дисковод и питающий его БП конкретно те же самые.
Перевод дисковода, при чтении Flux-ой, в режим HD, несколько улучшает ситуацию, но до МОСТ840 не дотягивает сильно.

Не известно точно, в чём причина. Алгоритм декодирования известен, но либо повторен с какой-то неточностью либо сама флюкса неправильно измеряет время. Может там джиттер слишком большой. Почему - не знаю. Предполагают, что сам процессор может быть не рассчитан на 5 вольт интерфейс, может быть в ПО проблемы. Факт в том, что стоит чуть-чуть сдвинуть пороги декодера, по которым он отличает количество нулей между единицами и тут же сильно меняется процент ошибок. Причем некоторая часть дорог читается лучше с одними интервалом, часть - с другим. И это странно.

Так что пока, не очень всё вышло.

Т.е. никакой определенности нет.

Определенность есть и разработчик устройства возможно где-то ее прописал и даже слепил и выложил готовый драйвер. Но мог и полениться, его право. Есть еще пара моделей поведения, но речь не об этом:)
Обычно для простых проектов используют winUSB, а zadig это прога для его простой установки. Во всяком случае большая часть китайских поделок его используют. Попробуй следующую последовательность действий.
0. отключаем все лишнее юсбишное
1. запускаем zadig
2. если в верхней строчке пусто или ничего знакомого, жмем options - list all devices
3. выбираем наше устройство
4. ниже слева показывается установленный драйвер и id устройства, у тебя в поле driver, если еще ничего не устанавливал, будет NONE.
5. правее выбираем что установить.
6. жмем instal driver
7. работает не трогаем, иначе идем в 5.

Я так  и не понял, что выбирать под стрелкой, выбирал сперва "Install WCID Driver", она че-то сопела, говорила "драйвер не найден". Тогда я потыкал вариант "Install driver" и она установила некий "libusbK"
После этого я ещё раз пощёлкал стрелки и выбрал "libusb-win32 (v1.2.6.0)" и ещё раз "Install driver". Вот после этого в
диспетчере устройств всё стало вроде бы правильно.

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