26 Ответ от Voldemar0 Отредактировано Voldemar0 (26-04-2021 20:45)

  • Voldemar0
  • Voldemar0
  • Участник
  • Неактивен

Re: SuperCard Pro, FluxEngine и прочее для сдампливания АГАТовских дисков

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

Стал разбираться, посмотрел таблицу распределения интервалов в зависимости от угла поворота диска, оказалось, что часть трека записалась как бы с "растягиванием" интервалов - как будто дискета "ускорилась" при записи или "притормозилась" при чтении. Не знаю, как это могло произойти, я пробовал всё с 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й дороги, без проблем вытянулись на "стандартных" настройках.

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

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

27 Ответ от Voldemar0 Отредактировано Voldemar0 (26-06-2021 21:10)

  • Voldemar0
  • Voldemar0
  • Участник
  • Неактивен

Re: SuperCard Pro, FluxEngine и прочее для сдампливания АГАТовских дисков

Переходим к снятию флюксой 140ок.

Сегодня закончил анализ нескольких образов 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.

28 Ответ от dk_spb Отредактировано dk_spb (27-06-2021 19:32)

  • dk_spb
  • Участник
  • Неактивен

Re: SuperCard Pro, FluxEngine и прочее для сдампливания АГАТовских дисков

Voldemar0 пишет:

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

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шной части флюксы, которая просто делением тактовой генерировала себе на вход индекса импульсы заданной частоты.

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

Post's attachments

Attachment icon idx_sensor_disconnect.jpg 966.09 kb, 84 downloads since 2021-06-27 

Attachment icon new_connect.jpg 1.02 mb, 78 downloads since 2021-06-27